Transport of Copies and Version Management with ChaRM

The use of Change Request Management (ChaRM) in Solution Manager introduces the concept of transport of copies to many customers. While transport of copies are part of standard CTS processing, a lot of customers have not used transport of copies prior to implementing ChaRM to manage the development process.

The use of transport of copies has a number of benefits to the overall change management process. An overall reduction in the number of transports that move to production is realized.  Workbench locks are continuous for the entire development cycle until testing is complete and the change document set to the status of “Successfully Tested”.  This eliminates the scenario where multiple developers can change the same object without collaborating.  Continuous workbench locks will require the second developer that wants to change an object to consult with the owner of the workbench lock.

These benefits are very valuable. Reducing the number of transports in the go-live buffer at release time can bring about significant reductions in the time the import takes during go-live.  This can free up time for other activities during the release, and reduce the overall down time of the cutover.  Extending the workbench lock on an object results in better control of the object during development and a more stable go-live.

One aspect where the ChaRM process can create some confusion is the fact that with each status change to “To Be Tested”, a new version of every workbench object associated with the change document is generated. During the development and testing process, the change document can be passed back and forth between “In Development” and “To Be Tested” a few times or it may move back and forth many, many times.  There may be multiple objects assigned to an individual transport associated with the document.  There is no limit to the number of transports that can be assigned to the change document.  So each time the document is set to “To Be Tested”, a new transport of copies is generated and a new version of every workbench object associated with the change document is generated, regardless of the number of transports or workbench objects.  Each time the document is sent back to “In Development” there may only be one item on the document that is to be worked on or fixed.

This process is different from the scenario that plays out when a customer is not using ChaRM and not using transport of copies. Without ChaRM and transport of copies, only the changed object is added to a transport and released when ready for testing in the QA system.  New transports and versions are not created for the objects that are not changed.  As a result, there may be some confusion if there is a need to revert to a previous version of an object.  While it is possible to use the transport of copies description to distinguish between original transports and transport of copies, there is no easy way to determine which versions contain changes and which versions are duplicates because the change document was sent back to “In Development” and back to “To Be Tested” for a testing cycle.

The screen shot below is the version management listing for an object Z_PROG1.

The list of versions contains a dozen entries. Using the Request Text On/Off button will help indicate which versions are due to transport of copies.

Because ChaRM automatically creates the descriptions for the transport of copies with the string “Generated test transport” at the end, the TOCs can be quickly identified. What isn’t easy to identify are the transports that contain changes to the program.  In the non-ChaRM, non-TOC scenario, every version contains a change.  In the ChaRM scenario, many of the versions may actually be the same if the change document was moved to “To Be Tested” multiple times to test another object on the change document.

The example shown here is a contrived example where I have simply created a program and passed the change document back and forth between “In Development” and “To Be Tested” multiple times to show the versions that are generated. In a real example, the program may be active for years and may be many times due to many change requests.  In this case there could be dozens of versions that accumulate over time.  With the introduction of ChaRM and TOCs, the number of versions that can accumulate over time could be 5 or 10 times as many.  The volume of change requests and the efficiency of the developers and configuration users will interact to determine how many versions are ultimately created.

For those customers where the volume of versions due to the use of ChaRM and TOCs is a source of concern, there is a CTS parameter that can be set to eliminate the versions generated by the TOCs. The parameter VERS_AT_EXP can be set to the value NO_T.  This option dictates that a new version will only be generated when the original transports are released.  The NO_T value has been recently added to the CTS configuration.  Check SAP Note 2296271 to see if your system will support the new parameter.

To demonstrate this parameter a new program is created and saved to a transport on a ChaRM normal change document. When created, there is only the active version with no version history to confuse the issue.

The program is then cycled between “In Development” and “To Be Tested” several times.

The version management history shows that no additional versions have been created.

Only when the document is set to the status of “Successfully Tested” is the original transport released.

The version management screen shows the update to the version management area.

The purpose of this blog is not to encourage every customer to use the parameter. In cases where the developers often rely on the versions management to revert to previous versions generated by TOCs, this parameter will not be helpful.  If, however, the volume of versions generated begins to make the use of version management difficult to use, this parameter can be helpful.  If you are considering the use of the parameter you must consult SAP Note 2296271 to ensure your system will support the parameter.