1 Introduction
Imagine completing an average six month SAP project or a big release cycle which includes several development activities with more than 50% reduction in transports (than the normal project or release cycle) moving to production yet executing everything same as in a normal SAP project. Seems weird! but is possible.
Let us start the discussion with one of the most basic things that an SAP consultant uses while working in SAP system- Transports.
A transport request is a request carrying changes done in the system also called as change request, in technical terminology. This change (transport) request follows two level hierarchy:
(Fig 1: Transport hierarchy)
As per standard SAP, a change (transport) request must have a unique owner. This means an object container with its owners name for completion of a logically complete activity. This in turn may require several employees (members) to work on accomplishing the complete change. For this reason SAP provides second level called task. Once a member completes his/ her activities, is needed to release the assigned task. This indicates completion of his/her part of the work. As a member releases his/her task, objects move to the higher level and get consolidated in the change (transport) request. Releases of all the tasks indicate the transport owner, completion of the change. He can then finally release the main change request to move to quality system and subsequently to production. If in this way transports are used, we are manually able to minimize the possible number of unnecessary TRs in the system. However with this approach we are just able to reduce the unnecessary transports only during initial development activities.
Nowadays with volatile market situations, high business expectations and budget constraints companies are trying to reduce project/ release timelines. This results in poor requirement gathering and blueprinting activity due to lack of time, thus resulting into actual requirement visibility at the time of testing when users see the actual output in the system. Even sometimes poor development may cause rework on the activity already performed. In such cases you may expect a lot of changes to the existing functionalities and thus creation of multiple change (transport) requests for the same object. Multiple movements of changes between Dev and QA environments cause the similar buffer entry for production import queue. Remember the fact that more the number of transports, more dependencies to check and thus higher risk in import of transports to production as you cannot remove unwanted TRs due to sequencing problems. This one of the main reasons that minimization of transports is needed in the system.
With SAP Solution manager, SAP has started centralizing the transport creation/ movement/ control via Change Request Management and CTS, then CTS+. In SAP Solution Manager, SAP was providing a transaction type SDMI for managing the transports pertaining to a given release cycle. It was a great improvement in terms of centralizing transport movement activities and control over changes. However, no improvement in optimization of transports and minimize risk. SAP then came up with a new concept Transport of Copies function with introduction of a new transaction type SDMJ in addition to the existing transaction type SDMI. For those who want to use this new transaction type can activate the BC set SOLMAN40_CHARM_TRANSTYPE_SDMJ and technical correction BC set SOLMAN40_CHARM_TRANSTYPE_SDMJ_01 to be able to use this new transaction type. Let's see in detail how transport of copies work.
2 Transport of Copies
Transport of copies option is available in each SAP system. This is a type of transport similar to customizing and workbench with its different behavior. Beauty with this type of transports is, it dies in the next target system. What does this mean??? Let's say I have three system landscape for my ECC system: DA1 -> QA1 -> PA1.
If you create a workbench request in DA1 system and release it, it goes to import buffer of QA1. Once imported in QA1, transport is now available in the import buffer of PA1 for import in PA1. But, if you create a Transport of Copy for the same transport in DA1 and release it, it will be in import queue of QA1. However, when you import this transport to QA1 it does not go to the import buffer of PA1.
Such a small difference! How will it help?
3 ToC with SAP Solution Manager
If you try to use the transport of copies explicitly in any SAP system, say you have created a transport request DA1K910001 in DA1 system and you want to copy this request in a ToC type transport so that you can move it to just the QA1 system. System will not allow you to put these objects in the ToC type transport unless you release transport DA1K910001 as the objects are locked under this transport request. So, you cannot create a ToC in ECC system for an unreleased transport.
3.1 Solution Manager: Task List
With introduction of SAP Solution Manager Change Request Management (1) SAP avails a task list (figure 2) containing several options for transport management activities start from transport creation till import to production and retrofit to other systems (Details on ChaRM basic setup can be found in (2)).
(Fig 2: Task list)
One of the available options in the task list for any development system is Create Transport of Copies. So, suppose you get a requirement of creating a particular form for invoice output (figure 3).
2. Complete the development and release all the tasks as detailed in section 1.
3. For unit testing let's not move the transport to QA1 system! Rather follow the instruction:
- Logon to SAP Solution Manager
- Go to transaction SCMA
- Choose the correct task list (say for an example M000001305)
- Right click on the create transport of copies option0.1. - Select schedule option
0.2. - In the popup, select TR DA1K910004
0.3. - Choose continue option
This schedules the job at background to create Transport of Copies for the selected TR. At the end of execution you can see in DA1 system a transport of copies: DA1K9005 with description DA1K9004: Generated test transport. Note that the scheduled job does following:
0.1.
- Creates a ToC with naming convention - <Original TR name>: Generated test transport0.1. - Copies objects from original TR to the corresponding ToC
0.2. - Release ToC
In this way at a time one or multiple ToCs can be created for the given system. Advantage in this process is that the main TR is still active and not released.
0.1.
4. You can then select the option under QA system in the same task list to schedule the import to QA system job to import the changes in QA1 system. 0.1. 5. If there is any change identified or a dump occurs due to movement of transport to QA1, you can perform the change in the same transport DA1K910004 and release the new task under same original transport DA1K900004.
0.2. 6. Same procedure can be repeated to move the corrections to QA1. This way the changes can be finalized under the same original transport.
0.3. 7. Once the development is completed and changes are accepted by business, the actual transport can be released and imported to QA1.
0.4. 8. This time the finalized transport will now be available in production import queue which can then be imported along with other change requests.
!https://weblogs.sdn.sap.com/weblogs/images/251932673/transportwithToC.jpg|height=403|alt=transport with ToC|width=617|src=https://weblogs.sdn.sap.com/weblogs/images/251932673/transportwithToC.jpg|border=0!</body>
6 Comments
