Specialized Development Client – CTS/TMS perspective:
SAP recommends that both Customizing and development be performed in the same client. It is more efficient to have changes and documentation supporting an SAP implementation originate from a single source.
However, developers often demand a separate client in which they can develop their programs in isolation from the Customizing environment. They want a more stable client where the Customizing does not change every hour. Because each additional client in your system landscape requires increased administrative effort to ensure that all clients are updated regularly with the latest Customizing efforts, other alternatives should be tried. First, you should try a single CUST client. If that does not suffice, try using a combination of two TEST clients, one for Customizing and one for development. Only if these alternatives do not provide your developers with satisfactory results should you consider creating a unique
development client.
In SAP Solution Manager Change Request Management (ChaRM) there is no use for two clients. It will only lead to extra maintenance and governance work.
Advantage of separate client – people that do Workbench want to play with Customization and want to see how it works in their program. Solution SCC1 makes an automatic TOC from 1 client to another in the same system. So recommendation is to have another/multiple clients within this instance and use SCC1 to test the customization and then once it is affirmative, move it to the source client in charm.
In chaRM as such there are no best practice documents. But the above info can be found in the book: “SAP Change and Transport Management“ (Page73).
Below is the recommendation from ChaRM perspective:
Disadvantages of using a multiple DEV clients –
Technical Challenges
1.Transports are supported in the standard transport layer of each client. When you configure transport routes, note that only consolidation routes that are assigned to the standard transport layer of the relevant exporting client are taken into consideration. For each exporting client, exactly one target client and one target group are permitted. We recommend that you assign exactly one development system to a production system, and that these two systems are connected by exactly one unique transport track. If there are 2 source clients then that means 2 logical components must be created in SMSY and the transport path has to be adjusted with two client specific transport layers. This is what we call a merged route as the changes go to the same PRD system, this is not recommended in charm but the TMS configuration can be done.
2. Possible scenario – sometimes configuration maybe based on the ABAP development. For example, your developer created some ABAP changes. Then some configuration was made based on these changes. It's quite possible that the ABAP changes are still being tested in the quality assurance system while the configuration was considered fine and delivered to the production system. The processor could hardly manage this when the changes are too many. If this kind of transport sequence problem happens, SAP cannot provide further support as the inconsistency maybe too complicated. This is a possible scenario and not that it will happen.
3. ChaRM is triggering the "tp import transport request of a CTS project" if you are using two development clients that will come into the same target system, one QA and one PRD system for example, then you can face dependences issues between the transport requests of these two different CTS projects. These need to be handled manually.
- 4. If customers plans to use Urgent change in charm eventually, it uses only 1 active track for the whole project and so it will not take into consideration the second source client.
Administrative Challenges :
1.More governance and effort involved in monitoring the two tracks in the projects.
2.Testing and documentation for users takes more effort.
3.Most customers using charm move towards one source client. It is easier for users to adapt to same.
4.SAP should always suggest to set up only one development client to avoid inconsistences in the follow up systems, and avoid making the whole scenario more complex. "Merged" transport routes, I mean two development clients pointing to the same target, are not SAP recommended best practice TMS configuration.
How to transition from two source clients to one source client?
I think it would be best to keep the workbench client to be the new overall DEV client, like this you can keep the originality of the workbench objects.
All customizing objects you have to collect in the old customizing DEV client and re- register them to a transport from the new overall DEV client. Of course the change has to be imported first, maybe SCC1 is a good option.
To make things more easy it might be beneficial to merge all transports into one consolidated.
