Skip to Content
Author's profile photo Former Member

Integrating Abap and Non-Abap CMS Processes – Revtrac Scenario

Common Scenario

Your have multiple methods of pushing transports through your portal and R/3 landscapes. You use STMS to move your ABAP transports, you use NWDI to move your java transports (SCA files) and you use the SAP Portal’s built-in transport organizer to move your portal iViews and Pages (EPA files).

Separate Processes

Each of these file types uses its own tool and thereby its own process for moving transports. When custom developments are being transported it is very common that there are dependencies between the Abap transport (e.g.: a function module) and a non-Abap type transport (eg: a web dynpro and an iView). The danger is that this dependency is not supported well by the various tools and processes because deployments are not synchronized across the other tools.

 You would like to streamline this into one single process, the ideal would be to use the tried and trusted Abap transport process for all types of files and it still must all work together with your Revtrac implementation for approvals.



CTS+ for Abap & Non-Abap transports

SAP offers a solution to the above scenario with CTS+ on SAP Solution Manager.  CTS+ allows you to attach Non-Abap objects to your Abap transport number. The term non-Abap is used because many other file types can be attached to a transport; it is not confined to Java [list of compatible file types]. It uses a web service to allow external programs like NWDI or the SAP portal to connect to CTS+ and attach a file to a transport.

Integrated Processes

The beauty of the solution is that it consolidates the various non-Abap transport processes into the existing Abap process and therefore the existing way of working remains unchanged. All of the objects relevant to your custom development are bundled together and are deployed at the same moment thereby contributing to the stability and integrity of your landscape.


When configuring CTS+ I recommend that you make use the very useful best practices and FAQs on the Enhanced Change and Transport System that SAP provides. The core task of the CTS+ configuration is definition of a System in the STMS transaction. Here you can specify that this is a non-Abap system and supply deployment information (e.g.: portals URL & SDM password). Thereafter you can define a transport path (Dev, Acc, Prd) for the non-Abap systems.

The external systems need to linked to the CTS Master to be able to upload their deployable content into a CTS transport. This is simple matter of defining an RFC connection and can be achieved with the Visual Administrator.

What I really like about this is that this is done using the existing toolset, and instead of having to learn new methods & transactions you change management team can work with non-Abap systems in the same uniform way that they do with their Abap systems.



You use Revtrac to manage your Abap transport workflow; can it also work with CTS+ transports that contain non-Abap objects?

You begin by defining a Revtrac Strategy for the transport route you defined in CTS+. You should define a Request Type and Target group and you should define a System in Revtrac, one for each non-Abap system you created in CTS+. Use the same SIDs.

Revtrac Strategy

At this point you can define new Revtrac statuses, but the best choice would be simply to reuse the statuses that you currently use for the Abap systems. This means that adopting these new systems into your CM organization is very smooth because is reapplies your current way of working.

Keeping track of the CTS+ transports from Revtrac

The choice on how to hang CTS transports onto a specific Revtrac number is a difficult one, this is unnecessary in the Abap world because all transports are automatically attached to a Revtrac number. The non-Abap world does not have this level of integration. I therefore propose the following options:




















Allow Revtrac to   generate a number of CTS transports for your new Revtrac number. The   developers then use this predefined list of transports and request more when   needed.





  •   Transport requirement is defined before/during Revtrac number   creation. Reduction of Revtrac numbers.


  •   Prevents ‘orphaned’ transports*



  •   Developers may nag the Revtrac coordinators for extra/unforeseen   transports



Allow developers to   generate CTS transports when they require it and manually attach the   transports into Revtrac when the developments are ready to be transported.



  •   Developer is unhindered in the need for transports





  •   Larger risk for orphaned transports* as development team may forget   transports.
      You can attempt to mitigate by creating a batch job to scan for orphans.




* forgotten transports unattached to a Revtrac

As this software continues to mature I expect the level of integration with external tools to improve and ultimately the level integration should at least equal that of what the Abap world currently enjoys.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      We just miss CTS+...

      Author's profile photo Former Member
      Former Member

      Hi Philippe,

      Thanks for your comment. A member of the Rev-Trac support team has raised a support case with yourself in relation to your question. Let us know if you need any further assistance.

      Vanessa Mason

      Digital Marketing Assistant

      Revelation Software Concepts