Skip to Content

Realizing CMS Track Connections with CTS+

If you are working with CMS (Change Management Service) of NWDI (SAP NetWeaver Development Infrastructure), you might use track connections for very different scenarios. One reason for using track connections might be that you would like to split the deployment of different software components to different systems at a certain point in our landscape. So you would use only one development system where you develop different software components. After that some components should be deployed to one system and some to another one. Take a look at the following example:


The basic idea of this scenario is that you are using different systems for your intranet or corporate portal (COT, COP) and for the internet (INT, INP). Assume that these systems are portals. Both in the corporate portal and in the internet you would like to provide custom developed applications. But these applications are different for the corporate portal and for the internet. For the internet, you need the application represented by the green SCA, for the corporate portal environment, the SCA shown in orange in the picture above is needed. In addition, you would like to set up only one development and one quality assurance system. All applications are developed in the DEV System and then for a first test, all of them are deployed on the QAL system. After a successful test in QAL, the green application should be deployed to INT to perform integration test for the internet and the orange application should go to the corporate portal. After that, there is an additional transport required to deploy the green SCA to the productive internet system and the orange one to the productive corporate portal so that the end users can profit from it.

Assume now that your company decided to use CTS+ for transporting applications through a system landscape instead of CMS. It is now your task to provide the same process for transports that you had for CMS by the help of CTS+.

The main tasks are:

  1. Create the system landscape described above in TMS.
  2. Make sure that the green SCA goes to the systems for the internet and that the orange one is deployed to the corporate portal.

Create the system landscape described above in TMS

In TMS, it is no problem at all to create a landscape like the one described above in task 1. Just go to transaction STMS, create the portals as non-ABAP systems and create the consolidation and delivery routes. Your landscape would the look like the following:



Make sure that the green SCA goes to the systems for the internet and that the orange one is deployed to the corporate portal.

But how to make sure that the green SCA is deployed to the internet systems and the orange one to the corporate portal systems? If you used a transport landscape like the one above, all transport requests would be imported into each system and you won’t have a chance to differentiate what should go were without looking into the details of the transport request.

This can be solved by using projects in TMS.

In the transaction SPRO_ADMIN, you can create new projects. For our example, we have to create one project for the corporate portal stuff (CORPPORTAL) and one for the internet (INTERNET).


You can use any setting for the project that you like (e.g. validity) but make sure that it is open and that you activate the CTS functionality on the tab Transp.Request as shown in the following picture.


Now, you can use the projects when creating a transport request or assign a project to an existing request in the Transport Organizer Web UI:


After you released the transport request, you will see it in the queue of the following system.


For our quality assurance system, we don’t need the projects as everything should be imported into this system. So here, you can do an Import all either on a scheduled basis or manually. After that, you will find all of the transport requests in the queues both of INT and COT.


Now, we would need a project specific import as only the transport requests belonging to project M43_P00001 (which is our project for the internet) should be imported into INT. – If you double clicked on the project number, you would be able to see the details of this project.
You now have to use filters before starting an import. To do so, you have to mark the column Project and then click on the icon for filtering:


In the pop-up, you can select a project.


After you clicked on the green hook, the list of transport requests will be filtered. Only the requests that are assigned to the selected project are visible.


Now, you can click on Import all. Only the requests that are visible in the queue after having set the filter will be imported. All other requests will remain in the queue.

To get rid of these requests, you can use the report rstms_del_project_from_queue. It will help you deleting the un-needed requests belonging to other projects from the queue.
To do so, open transaction SA38 (ABAP: Program Execution) and enter the name of the report.


Start the program and enter the SID of the system for which you would want to delete transport requests. In the same screen, you can name projects. The transport requests belonging to these projects will be deleted from the queue of the respective system.


By the help of this report, you can delete transport requests assigned to one or several projects from the queue of a certain system.

Making Projects mandatory

If you would like to make sure that a project is assigned to each transport request, you can define this attribute as mandatory. To do so, open transaction SE03 and double-click on Display/Change request Attributes as shown in the following picture


You will the see a list of the existing attributes and how they are currently used. To make using projects mandatory, you can mark the attribute SAP_CTS_PROJECT and click on change. You can find details in the documentation on SAP Help Portal.


The disadvantage of using this approach to replace track connections is:

  • It is the task of the developer to make sure that his transport request is assigned to the right project – or you have to create standard transport requests for each developer containing the correct project assignment beforehand.

The advantages of this approach are

  • You can use the same set-up if you start developing applications that should go both to the internet and the corporate portal systems. The only thing is that you have to create a third project named e.g.  ‘Common’. You would then use this project for transport requests that should go into all systems.
  • You can make use of CTS+ as one central transport tool both for ABAP and non-ABAP transports

Related Links

You must be Logged on to comment or reply to a post.
  • Hi Karin Sudrow,
    In Our Landscape SAP EP Portal [DEV,QUA,PROD] And BI Portal [DEV,QUA,PROD ]Systems.Currently NO NWDI Setup in existing Portal Installation in Both EP Portals and BI Portals.

    1.One NWDI Server seperate Instance is enough for all Collabarate Devlopmen in Both BI Portals and EP Portals Including DEV,QUA,PROD.

    2.If we go for 1 NWDI Server for all What is the Hardware requirement is needed .

    3.If we go for 1 NWDI Server If More Deployments We will do for SAP ESS/MSS And SAP MI And BI Related Development is any Performance Issues We are facing.

    4.If 1 NWDI Server is enough for seperate installtion in Template What are The Componnets We need to select.

    If You have any Proper Documnet on NWDI Installation and Configuration and How To Use NWDI While using Developer In NWDS To NWDI.

    Can You Provide Documents for helpful installation and configuration and Transport Movemnet in Landscape.My Mail id is

    Please Do needful