Extended SAP CTS Management also for SAP Cloud ALM
Blog from 8/12/2018
Full CTS control also for SAP Cloud ALM, even on the client level
In general, transport management systems (TMS) offer two methods for controlling transports - classic transport control and extended transport control. The former principally constitutes a compatibility layer for TMS configurations of 3rd and early 4th releases of SAP.
Which version of transport control is used is determined by the CTC (Client Transport Control) transport profile parameter. If this has a value of “0”, then the classic transport control method is used, whereas the value “1” activates the extended transport control mechanism.
So what is the difference between these two versions of transport control? Essentially, the classic method of transport control is concerned solely with connecting individual SAP systems in the system landscape. But it gives no consideration to the client. When the extended transport control method is used, the approach is augmented to the effect that consideration can also be given to clients.
The following specific enhancements were incorporated from SAP for this purpose:
• The import queue was extended with an additional field for the target client. Requests can thus appear in the import queue multiple times, provided that the corresponding entries relate to different target clients. A new file format for the import queue is used in order to achieve this. Upon activation of the extended transport control mechanism, the existing import queues in the old format will automatically be converted, and there is a function for the mass maintenance of missing client details.
• The transport routes were enhanced in order to support clients. Consolidation routes now have a target client, and delivery routes have a source as well as a target client.
• Transport target groups no longer collate a large quantity of target systems, but instead combine a number of target clients (on different systems if necessary).
• The standard transport layer is maintained on the client level. As such, various clients can also use different standard transport layers, whereby individual clients can have different transport routes for customizing.
• If a transport containing non-client-specific objects is imported into several clients, only the non-specific objects imported into the first client will be considered. In doing so, clients can be transferred downstream (even in the development system), without the need to “roll back” cross-client objects to a previous status.
Based on my experience in client projects, I would generally advise that you activate the extended transport control system. This removes the need to enter client details with each import, which can often lead to mistakes. If, for example, a Workbench request with both client-specific and non-client-specific objects is imported into a system in the working client and in the other system into the client 000, the client-specific objects in the working client will not be present in the second system. This configuration often appears in the context of external deliveries, which contain both ABAP coding and roles in one and the same request. Moreover, the extended transport control method can be used to model much more precisely the actual usage of clients. It is thereby possible to supply transports to several clients of the same system simultaneously or even consecutively without any additional manual work. Delivery of the clients via transport routes is carried out along the same lines as delivery in SAP systems.