My experience with cCTS ChaRM
Few months back we have decided to implement ChaRM with cCTS and I was looking eagerly for some blogs which talks about good and bad of it, but I was not able to find much. Then I thought I should write one when I have good understanding on this.
To start with we have followed the below how to guide of cCTS.
To understand the simple flow setup this is enough but if your landscape is complex then it’s difficult to manage with this little piece of info.
The landscape where we have started is an ECC dual track (Maintenance and Development) and singe track BI for both maintenance and development.
As its being a dual track customer wants us to setup enhanced retrofit as well. The systems in the landscape are as below:
Points to be noted during clustering:
As per the how to guide all similar role systems should be made as one cluster e.g. all DEV systems in one cluster and all test systems in one cluster. If we can take the above landscape as a use case there should be three DEV systems in one cluster.
The clustering is closely associated to logical component in a project, systems must be even in all the logical components of a project else clustering is not possible.
Not necessarily all systems have to be in cluster e.g. retrofit.
Problems in clustering:
1. If one system is down in your cluster we cannot move transports to any other systems in the same cluster. E.g. In the above landscape quality cluster is having three systems two of ECC and one of BW and the project QAS system is down for maintenance then we cannot move transports to QAS of Maintenance or BW.
So plan you clusters properly so that there will not be any dependencies.
2. As retrofit is involved we have added the post processing system in logical component so the logical component will have five systems but in clustering you still have only four clusters (CD1, CQ1, CPR1, CP1) in this case systems will not be able to identify the clusters.
To make this work define another logical component with only post processing system, as this logical component is not even this will not be considered during clustering.
3. In a project we have defined DEV, QAS, PPD, PRD in logical component and in cluster we have made only three cluster DEV as cluster one, QAS and PPD as cluster two and PRD as cluster three. In this case as preprod is also kind of a test system so we can club both systems into one cluster.
Real scenario: A new development is started in project A and was tested well in QAS now it is yet to be moved to PPD system. Later there is a change in plan and these changes are decided to be moved as part of project B, when you try to change the project assignment of this change document system give message that TR’s are not moved to all the systems in the cluster hence you cannot change the project assignment or decouple the TR’s from this change document till its moved to all the systems in the cluster.
Hence plan your clusters properly considering multiple use cases.
4. In ChaRM without cCTS if you have to stop the TR movement to next system we can delete the TR from the import queue before the import all job run. But in cCTS this is not possible even after deleting the TR and transport collection, changes will still move to next systems.
5. In cCTS ChaRM projects sometimes the TR will not move to the next system even after the import all job run. In these cases we have to check the log of transport collection which will give you the clue of what went wrong.
6. In some cases the transports will move to the next system but the TR will have a message “return code unknown” because of unknown return code it gets into the import queue again and again currently I didn’t find any way out for this.
Hope the above information will help in design your clusters well.