On the following pages, you can find some information what has to be configured

if you would like to use the Change and Transport System (CTS) of AS ABAP to
transport your components developed with SAP NetWeaver Development
Infrastructure (NWDI) e.g. from your development to your test and productive
runtime systems.
1
Here you see the situation of ABAP transport landscapes and J ava landscapes
with NWDI before CTS provided the option to transport J ava components
developed by the help of NWDI. Two separate tools and transport landscapes had
to be used one for the J ava parts (CMS) and one for the ABAP parts (TMS).
2
Since SAP NetWeaver 7.0 SP14 a tight integration for NWDI into CTS is possible.
During the assembly step, the assembled SCA file will be automatically attached
to a TMS transport request if the respective track is configured to be used with
CTS.
If you are using Dual Stack systems, changes to ABAP and J ava objects can be
transported together with TMS in one single tool, in one transport request.
3
To be able to use CTS for J ava, some configuration steps are required. You can
find the details on the SAP Help Portal. On the CTS system, you have to configure
the Deploy Web Service and activate the Transport Organizer Web UI. In addition,
you have to create representations of your runtime systems and connect them by
the help of transport landscapes. This is done in transaction STMS. On the NWDI,
you have to configure a destination which establishes the connection to the CTS
system. In addition, you have to configure the tracks which you would like to use
with CTS. The following slides show some details.
4
Starting with SAP NetWeaver 7.0 including enhancement package 1, you have to
maintain the destination in the NetWeaver Administrator on the NWDI system. You
can only maintain one destination. This means that you use your NWDI with one
CTS system. The destination has to be named
sap.com/com.sap.tc.di.CTSserver.
5
In releases prior to SAP NetWeaver 7.0 including enhancement package 1, you
have to maintain the destination in the Visual Administrator on the NWDI system.
You can only maintain one destination. This means that you use your NWDI with
one CTS system. The destination has to be named
sap.com/com.sap.tc.di.CTSserver.
6
If you use CMS with CTS, the connection to CTS is done in the assembly step. In
TMS, you have to create a landscape consisting of the representations of your
runtime systems and transport routes between them. The example above shows a
three system landscape consisting of a development, a test and a productive
system. When you assemble an SCA, you can attach it to a transport request for
EPD in our example.
7
If you would like to use a certain track with CTS, you have to configure this in the
track data. Enable the option Connect to CTS and name your runtime system
which is used for development (=the first system in your transport landscape in
TMS) as CTS Upload System (if no cons runtime system is used).
8
9
These screenshots show how the integration of CTS in CMS looks like. In the top
right corner of the transport studio, the user can find a link to the Transport
Organizer Web UI. He can use it e.g. to check the available transport requests,
create a new one or check the import status of already released transport
requests. When the user clicks on Assemble Component(s)a new window
opens up to set the Assembly Options. On this screen, the user can decide about
the transport request to be used. A link to the Transport Organizer Web UI is
provided as well. In addition, the user can add some documentation to the
transport request via the input field Note.
10
Now lets have a short look at the development process within a track. A
developer imports the development configuration of the stage Development into
his Developer Studio. Here he starts development and every change is recorded
within DTR activities. With the CheckIn, he decides to store it in the DTR
workspace to make it visible for all other developers working in that track. With the
Activate step he starts the central build process on CBS to see if his coding works
together with the active changes of all other project team members. With a
successful activation the buildspace is updated with the new archives and the
deployment to the Development System is triggered. Here the developer can test
if his application is running. After that first integration test, he can release his
changes. With the release he hands-over to the administrator. The Change list is
now waiting for import into the Consolidation system. The developer can now
perform the import. With the import the DTR workspace and CBS buildspace of
the Consolidation Development Configuration are updated and if everything
worked fine, the deployment is triggered to the Consolidation system. After that
the Software Component can be assembled a SCA file is created. Now the SCA
file can be imported (deployed) to a Test and after a successful testing phase the
changes can be approved and imported to the Production System.
11
Test and Production in a CTS-integrated scenario are configured as TMS non-
ABAP systems. That means there is no runtime system configured for TEST and
PRODUCTION within the CMS track.
12
Starting with SAP NetWeaver 7.0 including enhancement package 1 it is possible
to configure a Single System Track, where the Consolidation system is deleted.
13
A Single System Track can be configured in the CMS Landscape Configuration
Track Data. Note: there is no way back - once you changed a track to be a Single
System Track. After you checked the checkbox Development System only, the
development configuration, workspaces and buildspace for the Consolidation
system are deleted. The tab Consolidation is no longer available in the Transport
Studio of CMS for this track.
14
Compared to the development process before, the import to the consolidation
system is of course not needed anymore in a Single System Track. Therefore the
integration to CTS takes place earlier and the CMS administrator just assembles
and attaches the SCA file.
Note: In a single system track the assembled SCA will contain the sources of the
dev/active workspace and the archives of the development system buildspace.
In NWDS the developer still needs to Release his changes. This is especially
required if you use repair connections (between several tracks if the single system
track is the source track).
15
16
17
18