How to manage Error Free Transports

Introduction

                  This blog is going to explain you about “Managing Transports by using common sense”. I am not going to talk about standard Steps to be carried out.

Common Mistakes :

1. We tend to collect multiple(too many) objects in a single TR
2. We collect our objects in other’s transport requests via separate tasks without our/their knowledge
3. We collect different types of objects in a single TR. Eg: Transformations and DTPs together
4. We overlook dependent objects while collecting our objects
5. We do not know whether RSLOGSYSMAP table has got right entries in Target systems or not.
6. We don’t bother about dependent objects are active in Target Systems or not
7. We don’t bother to drop data in Infoproviders in target systems when we want to transport any structure changes

How to use our common sense while managing transports

Scenario : In our projects, we use some standard infoobjects like 0plant, 0Division, 0material etc., Please observe all these standard infoobjects belongs to their respective standard Infoareas and Application Components.

How to handle above scenario?

We need not to collect their respective Infoareas and Application Components every time. Because these standard Infoareas and Application Comps will be already available in target systems.

How to transport DSOs/Infocubes first time to the target systems?

As we might have already moved our infoobjects, we just need to collect only DSOs/Infocubes and move to target systems. We need not to collect any underlying infoobjects it is pointing  to, like below. The infoobjects which has Expand icon can be collected with “Do not Transport Any below”. This will reduce the burden on the TR. Note : It’s better to use “Only Necessary Objects” and Collect Automatically”.

What to do when DSOs/Infocubes becomes inactive target systems?

Just collect the active version of DSOs/Infocubes and move to target systems. You need not to collect anything below.

How to transport Transformations and DTPs first time to the target systems?

We all are aware that Transformations are between Source and Target. That’s exactly is the reason to collect Source and Target along with Transformation like below. We need not to collect all infoobjects of our Cubes and DSOs, because those objects have already been moved. Same explanation applies to DTPs also.

How to transport Transformations and DTPs after the first time to the target systems?

We just need to collect the active version of Transformation and DTP. It’s not required to collect Source and Target as they are already actively available in Target systems. This procedure can avoid running RDG_TRFN_ACTIVATE program directly in Target systems. You can run this program if you want to activate Transformations/DTPs in mass.

Tips to consider while managing Transports

We tend to collect multiple(too many) objects in a single TR

We should not collect too many objects under one TR. Eg: 1) 30+ Queries 2) 10+ Process Chains etc., We will not be able to have a control on all objects. If you collect few and make them successful in Target systems, it gives you a great idea on our transports.

We collect our objects in other’s transport requests via separate tasks without our/their knowledge

This is not really a big mistake. But there is a dependency here. Unless all the tasks of different users gets finished, you cannot release the main Request No. This will delay your work. To avoid all this mess, you should create your own TR and collect all your objects under it and release it.

Sometimes the other developer would have developed some objects and saved in his task. When you take up that work and start working on them, all your changes will get merged with the existing request and task. You will be confused finally, what is your changes and their’s ? That’s why you have to collect freshly just before you are ready to transport all your objects. Never transport the older requests, as you don’t know exactly what are all changes have been done.

We collect different types of objects in a single TR. Eg: Transformations and DTPs together

This is a biggest mistake we generally do. When we start our developments in our BW Dev system, we might create one TR in the beginning and start saving all our work in that. Finally we land up in multiple errors while importing in target systems. Eg : (1 Infopackage, 1 DTP, 2 Transformations, 3 DSOs ) All in one TR.

My tip here is, you can still work on single TR, but finally unlock all your objects with the help of my other blog http://scn.sap.com/docs/DOC-31394. Collect again freshly object wise from RSA1–>Object types in individual requests. Be clear on object wise here. Eg: Cubes- 1 TR, DSOs- 1 TR, Chains- 1 TR, Transformations- 1 TR, DTPs- 1 TR

We overlook dependent objects while collecting our objects

We should always cross check in target systems (before transporting our objects), whether dependent objects are active in Target systems or not. Eg : Datasource Replicas, Transformations, DSO/Cubes etc..

We do not know whether RSLOGSYSMAP table has got right entries in Target systems or not

Logical system conversions are must to be maintained in target systems , while transporting Transfer rules, Infosources, Datasource Replicas,Transformations etc. They basically check “Source System Reference” in target systems.

You can maintain them with my other blog http://scn.sap.com/community/data-warehousing/netweaver-bw/blog/2013/09/29/clients-and-logical-systems

We don’t bother to drop data in Infoproviders in target systems when we want to transport any structure changes

If we don’t drop data before importing a TR, that would fail saying it cannot add/remove a Char/KF as the target contains already contains data with them. So we should drop the data in Target systems before moving. Database inconsistencies will arise after that. We can resolve them by RSRV.

How to collect Data flow Migration work

This is a very sensitive task while collecting. All your sequence of steps have to be collected on the spot. Treat these TRs with special care. Don’t allow any other changes to get saved under it other than migration activities. It is not as easy as unlocking from the old request and collect again in new Request from RSA1–>Object Types.

How to collect a BEx Query

You have to select the tick boxes like below and cross check whether all the query elements have been collected or not. You need to select the Infoproviders, as they will be already available in Target systems.

How to set your system Transport Request settings

Goto RSA1–>Transports Tab–>Follow below image

If you switch on standard, then every activity will ask you for transport request through a pop up instantly.

If youSwitch -off standard, then all your activities will get saved in to local objects. Finally you will have to collect from RSA1–>Transprt tab–>Object types

Object Changeability

You can observe this functionality in above image. This can be used to provide a privilege for us to edit the objects directly in Target Systems. Eg: Queries, Web Templates, DTPs, Infopackages etc. This setting has to be done in Target systems

Conclusion

Transporting is an easy task if you organize things properly in a systematic manner. Maintain your own excel sheet with all your Transports. This will help you any time if you want to cross check.