Practical overview of central Change and Transport System (cCTS)
It is not a surprise how complex SAP project can be. When we think about release management, software logistics, and all other complex activities related to the deployment of the releases, the scenario hardly ever gets simpler. Additionally, if complex landscapes are needed, many activities will demand special attention and the complexity increases even more.
In order to support many faced complexities and provide more flexibility to the overall process of Change Control Management, SAP provides a very interesting tool called central Change and Transport System (cCTS). even though the usage of cCTS is optional, it cannot be used as a stand-alone tool and it must be used together with Change Control Management tools, such as QGM or ChaRM.
To increase the understanding around this component, this document will describe the basic functionalities of cCTS with ChaRM projects.
cCTS and Change Cycles
During the implementation of cCTS, Clusters are used to encapsulate the managed systems.
The clusters use the concept of Collection that provides one more level of abstraction on the top of the regular Transport Requests that we usually know. This concept is transparent for the users, but technically, it is possible to have transport requests from different development systems inside of a collection.
Because of the adjustments of the transport landscape, the Change Cycles must be defined with the activation of cCTS in mind.
The next steps will clarify how to create a new change cycle with cCTS activated:
- Access the Change Cycle and redefine the actual system landscape.
- On the second step, you have the option to activate the cCTS for this Change Cycle.
- On step 3 can only be accessed when cCTS is activated. Here you will define the Clusters you have customized during the implementation of cCTS.
- In the Transport Track Overview, you can see that the associated clusters are also defined in the systems landscape.
Task List and Change Documents
- After the definition of the new system landscape, the Task List will also present some differences. The clusters will be available and the Transports can be controlled by clusters as well.
- From the processual point of view, cCTS does not change how the Change Documents in the ChaRM are processed. The collection will be visible in the Transport Management assignment block.
Assignment of external transports
Transport requests originated from other systems can be assigned to change documents and transported following all the release definitions by ChaRM.
- External transport request imported into de development system.
- Assignment of a request from SMD into FSB.
Decouple/Assignment of released transports
With cCTS it is possible to reassign released transport requests to other Change Documents.
- Release transport request with no assignment of the project.
- Assignment of the transport request.
Import transport request for the Clusters
With cCTS activated, the import job can be executed for the clusters.
- In the Task List, you can also execute the job “Import Transport Request for Cluster”.
- The transport should be executed as usual.
- The transport history can be tracked in the Transport Request Log.
With many different tools being offered, it gets quite complex to get up-to-date with some modules. For this reason, I was motivated to write this post. I hope it helps to clarify the basic question around cCTS and how its main functionalities work.
Thank you very much Rafael.
This is a very good practical overview!
Hi, thanks for this nice overview.
is this possible with external Transport of Copies too?
Because I cant find any external ToCs.
Hi Thomas, thanks for your question.
I would consider that ToC is meant to be used for testing modifications. So, in this case, I would think that you want to transport only completed and tested external transports through your system landscape.
Why do you plan to use ToC as external transports?
thanks for quick responds.
Use Case is that we get external Transports as "Transport of copies" instead of Transport Requests.
So after we implement the external toc in Dev System, we cant assign the toc to a Normal Change (Change Document).
I read that assignment is only possible with customizing and workbench Transport requests and not Transport of copies.
So we Need external Transport requests (Cust or Workbench) for Transport via solman. Isnt it?
I believe you are correct. In ChaRM, you are not allowed to attach ToC to a Change Document.
In the Transport Management assignment block, the only allowed Transport Request types are Customizing and Workbench.
I never thought about using Repacking in your context, but it could support you.
Please, take a look on this page:
I hope it helps you.
we're about to start with cCTS in ChaRM.
Setup is done but there may be still some misunderstandings.
We have around 10 different SAP landscapes in CahRM (Solman 7.2 10 (12/2019) FPS).
Each has his own phase cycle for maintenance and maybe other for projects or new features.
Each uses an own cycle because after a while with many transport requests in a cycles we experienced performance problems (maybe in the past...)
We thought we'll use cCTS for all these 10 different landscapes but it seems to turn out that cCTS works only for a change control landscape across all its logical component groups that are part of this change control landscape.
Is that right?
Does that mean we must create one change control landscape for all logical component groups together?
Because each logical component group has a different maintenance cycle for support packages and we feel we get performance problems if even more transport requests are handled by one big change control landscape for all SAP Landscapes.
Are there any best practices roughly how many transport requests can handle one change control landscape without performance issues?
We're also thinking about what if we have import problems into PROD systems, lets say in 2 or more landscapes at the same time because our cluster import is set to parallel import. Then we have to fix these issues at the same time.
Up to now we import one cycle and if that is OK we start the next.
What is in case the Solution Manager is down and we must release a transport request?
Could you help to clarify this?
I would imagine for this scenario that you will need to create a new cycle containing all the systems.
I consider that the Task List created for different Cycles will not refer the systems accordingly. But, you could test if it is possible and let us know.
One last thing you could also try it to use Focused Build Import report and check if it works with cCTS. You can use this report to trigger imports automatically and it can be configured as Task List independent.