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).
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.
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.
CTS+
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.
Revtrac
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.
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:
| Strategy | Benefits | Risks |
| 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.
|
|
|
| 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. |
|
|
* 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.
2 Comments
