![]() 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. Such a small difference! How will it help? 3 ToC with SAP Solution Manager However, when you import this transport to QA1 it does not go to the import buffer of 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. Once imported in QA1, transport is now available in the import buffer of PA1 for import in PA1. If you create a workbench request in DA1 system and release it, it goes to import buffer of QA1. What does this mean? Let’s say I have three system landscape for my ECC system: DA1 -> QA1 -> PA1. Beauty with this type of transports is, it dies in the next target system. This is a type of transport similar to customizing and workbench with its different behavior. Transport of copies option is available in each SAP system. Let’s see in detail how transport of copies work. 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. 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. However, no improvement in optimization of transports and minimize risk. It was a great improvement in terms of centralizing transport movement activities and control over changes. In SAP Solution Manager, SAP was providing a transaction type SDMI for managing the transports pertaining to a given release cycle. With SAP Solution manager, SAP has started centralizing the transport creation/ movement/ control via Change Request Management and CTS, then CTS+. This one of the main reasons that minimization of transports is needed in the system. ![]() 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. Multiple movements of changes between Dev and QA environments cause the similar buffer entry for production import queue. 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. Even sometimes poor development may cause rework on the activity already performed. 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. Nowadays with volatile market situations, high business expectations and budget constraints companies are trying to reduce project/ release timelines. However with this approach we are just able to reduce the unnecessary transports only during initial development activities. If in this way transports are used, we are manually able to minimize the possible number of unnecessary TRs in the system. ![]() He can then finally release the main change request to move to quality system and subsequently to production. ![]() Releases of all the tasks indicate the transport owner, completion of the change. As a member releases his/her task, objects move to the higher level and get consolidated in the change (transport) request. This indicates completion of his/her part of the work. Once a member completes his/ her activities, is needed to release the assigned task. For this reason SAP provides second level called task. This in turn may require several employees (members) to work on accomplishing the complete change. This means an object container with its owners name for completion of a logically complete activity. This change (transport) request follows two level hierarchy:Īs per standard SAP, a change (transport) request must have a unique owner. Let us start the discussion with one of the most basic things that an SAP consultant uses while working in SAP system- Transports.Ī transport request is a request carrying changes done in the system also called as change request, in technical terminology. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |