As an SAP customer, we have lots of small development topics (change requests) every year. Most of the change requests are tested and then transported into the production system within a short time frame. However, there are always some change requests which “get stuck” for various reasons. Periodically, my colleagues in the Basis (administration) Team create a list of these “long running changes”, and ask the developers to either release them or decommission them (revert the objects to the original state, as in the productive system. If any native English speaker is reading this, and knows a better term than “decommissioning”, please let me know). This is unpleasant work for both the Basis colleagues and the developers.
To avoid this, we implemented a little report that automatically reverts the development and customizing objects in selected open transports to the state that they have in the production system.
It does this by creating a “mirror transport” in the production system.
Two pieces of coding are needed:
- An RFC function module in the production system, which is called with the object list, and adds them to the open transport of copies
- A small report for the development system, which performs some checks, creates backup versions of the objects, and then calls the function module
I attach the coding in “new” 7.40 SP08 syntax as text files. Of course, it can be rewritten to work on older ABAP versions as well. The function module logic is implemented in a local class, so the text file consists of 3 parts. In addition to the code, one message has to be created for the function module – see comment in code. There are 330 lines of code in total.
Besides executing the report, 4 manual steps are necessary. The sequence is:
- Manually: Create an empty "transport of copies" in the production system (P system), to use as a mirror transport. Target = development system + client (if you do not enter a target system, no transport file is created!)
- Using the new report, fill the "mirror transport" in the P system automatically. The report also releases all transport tasks that are not yet released, and creates versions of all objects
- Manually: Release the mirror transport in the P system. Ignore the warning message "Not all objects could be identified due to missing object catalog entry".
- Manually: Import the mirror transport into the Development system. You have to choose the "Overwrite originals" option (and if there are any modifications involved, "overwrite objects in repairs").
- Manually: Release and transport the original transport requests
Disclaimer: I have tested the process and code in our own systems, but of course I cannot guarantee that it is bug-free, works as specified, etc.