Skip to Content

How to manage Error Free Transports


                  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”.

DSO Collection.JPG

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.

DSO Active status.JPG

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.

Trans collection.JPG

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.

Trans collection1.JPG

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 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

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.

Query collec.JPG

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


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.

You must be Logged on to comment or reply to a post.
  • In lot of threads we noticed lately that people have issues with transports and its related objects so these documents will come handy for sure.

    Seems cool idea to cater their needs with your wonderful blog.

    When i was at initial stage of my career,i used to read lot of blogs and documents and still following it.I used to wonder who has all the time in this world to give this much of write up with proper screenshot but people were there,they are and they will make this happen

    So keep blogging to help others. 🙂



    • It seems you are very impressed by my blog today 🙂 . Even I use to collect and read so many docs in my initial stages. I think almost on evry topic, there is a doc available on SCN. Again time to thank SCN platform now 🙂 .

      Now a days, guys are trying to answer the queries with screen shots only. It’s all depends on how best you are able to make the readers understand about the concept. I basically like presentations, which drives me to write blogs on untouched topics. I feel Transports are the easiest task in BW. I just follow all the above mentioned steps..

      • This blog actually addresses no less than 10 issues related to transport so next time if any one faces issue regarding the same,i just have to make them refer this blog. 🙂

        I have so many documents and blogs bookmarked,means you name it and i have it and what we do not have you guys are covering it.

        So keep up the good work..I ll still focus more on BEx workarounds that’s more of my cup of tea. 😉



  • My rating is exceptional 🙂 🙂 , this document is very helpful for error free transporting. 😉 😉

    i Have one question for all these,  Grouping : May vary for collecting a request for transformation and collecting others (In Dataflow Before/after) which Flow we need to put. 😉 😉



    • Always use “Only necessary objects” under Grouping. 🙂 . I have mentioned about grouping in the blog. Please go through it once again.Thanks for your amazing rating

  • Suman,

    good document. One important point  which can be added here is We can use option Package option in the transport connection screen where you can verify what are the elements that are selected below saving in to the transport.


    • Hi Bhaskar,

      Yeah, after collecting we have to click on Truck button, then it will ask you to change to the right package. As I told in the beginning, this blog is not to explain standard steps. It is to play tricks. Thanks for your feedback 🙂

  • Hi Suman,

    I am new to ABAP and i don’t have any real time experience. Actually my question is,Suppose  one ABAPER working on real time object in an organization. So for each object under one project he has to create new transport request ? Or for every object under one project he is bound to use only one transport request that created initially.



    • Hi Ajit,

      Better to check ABAP forum. because BW transport are different compare to ECC(


      As per the module wise you can create one custom package/project. all developed objects related application can saved under custom package.Transport request can used for every changes.


    • Hi Ajit,

      ECC developments(ABAP) transports have to be handled with care. Yeah, each object under a project has will be asked for a TR. So other users who wants to work on the same object changes will be recorded in to your request with a new task. Make sure  you don’t have any requests in SE09 modifiable. Then, automatically it will ask you to create new TR when you work on any ABAP object.

      • hI Ajit,

        Always keep an eye while saving your objects into available requests. Workbench requests can be shared by all. But it is very difficult while transporting.

  • Hi Suman,

    my greatest respect for your structured blog in relation to the BW transport management.

    It´s very useful for the daily work.

    Many thanks for sharing!



      • Hi Suman,

        I have one specific question.

        My scenario looks like as follow: Assuming I have imported 10 transports from development system to quality system during the development phase of the bw project solution. A few weeks later, after the quality assurance, it´s time for the production startup (going live). For a structured import of the tested developments I want to import the transports in production system in a consolidated way.

        What´s your suggestion or your experiences? Should I create a single transport of copies and take up my other transports. So as the result I have one single transport with all necessary BW objects for the forthcoming import into the production system?

        Many thanks for your suggestions!



        • Hi Michael,

          As you say your transports were successfully imported in Qua, you will have to move the same TRs with a same sequence to Prod. You should not create any new TR now. You just have to move the same TRs (which were moved to Qua) to Prod.



          • Hi Suman,

            thanks for your comment!

            Yes, that´s right! But during the development time it´s normal that a couple of transports imported into Quality (day by day). At the going live date (day x), I think it´s look´s like nice, if we have one single import with all relevant objects to bring it into production system. 🙂

            Thanks and regards,


          • It would be nice if it can happen that way. But unfortunately, it cannot be done. You have to move all the required TRs in Dev and move to Prod. What is your path D->q->P or D->Q and D->P?

            If you want to freshly create new Trs for all your objects in Dev system, you can do that. But import to Qua again and then import in Prod. This would be perfect.



          • Hi Suman,

            the path is D->Q->P

            The developments from D are imported in Q (in total 10 Transports), so as result in the Import Queue of P are also the High Number of Transports.



          • Yes, of course, but can I not collect the successful imported 10 transport requests in one single request to Import into P? I think, it would be a consolidated way.

          • No Way, Not Possible. if you need all request in request, you may need to collect at dev only. In Q you won’t change any thing about objects/transports.Whatever you have at Q, same Transports need to move P. You can’t club as you need.

          • No. You should not create new TRs in target systems like Qua. You should import all 10 in P too. Don’t ever think to collect all into one, which is not possible, because al transports have to be imported in sequence only, but not all in one shot.

            That’what i discussed in my blog most common mistakes. Please go through them again..

  • Hi Suman,

    Really a good one for those who new to BI,I like to add up few Points,

    Better to capture Info Areas,Info Objects,DSO,CUBE,Transformation,DTP’s in seperate TR.

    It might be seems to be more TR’s for single flow,But incase of TR failure easy to Analys.



    • hi Shakthi,

      My whole objective of the blog is to collect everything in sepaarte TRs. I just took some examples. Your point has already considered in the whole theme of blog. Anyway thanks..

  • Thanks for sharing a precious blog.It’ll be very useful , while delivering the objects .

    I’d like to clarify my doubt , how can we manage a change request?


    B Devi

  • Very helpful.. Just to add here.. before transporting, we can check for inconsistencies using ABAP program : RSO_TLOGO_CHECK_REQUEST.


    Ramya Dwarapu

  • Dear Suman,

    Thanks for this great blog!
    I have an inquiry and I will be grateful if you guide me..

    One of my x-colleagues has activated the BI content objects in the dev system by using Before and After grouping option, and based on that he collected the objects in the transport requests. So what he did was selecting all the infocubes for a particular module (Ex: for SD), choose “Before and After” and activate them, and collect them in a single request called “Inforcubes for SD”.

    So for each Module/Area, there is a TR which includes all the cubes with their complete  flow (Before and After).

    Anyway, as I am now responsible for transporting the requests to the QA system. I found that it is too risky to transport those TRs as they were created module wise.
    Also when I checked each TR, I found that some Objects are missing and are exist in the $TMP package.

    My inquiry is, how to re-organize all this mess? Should I remove all the exist TRs in the Dev and re-collect the objects again using the object wise approach?
    I know how to collect the objects (sequence, and the dependencies), but my concern is only about the exist TRs and what the consequences of removing them as I never had to do that before.

    Pooja 🙂

    • Hi Pooja Singh ,

      Glad to receive your valuable feedback and inquiry 🙂

      I understand your concern. As your X-Colleague had already collected module wise data flows, I suggest you to experiment with one TR to get to know the issues. Take one TR and cross check whether whole data flow objects have been collected under that. If not, please change the package from $TMP to your package and make sure all objects under this TR and move to Qua and check thoroughly. If you are successful, you may continue all other TRs as well in the same fashion.

      Otherwise, you have to follow object wise approach as per my blog.



      • Thanks Suman for your suggestion!

        In case I want to start the object wise approach from the beginning, should I remove all the exist TRs in the system?

        Some of the TRs are too huge and full of objects! Is there any best practice to deal with this issue?

        I appreciate you guide and help 🙂

  • Nice & very useful blog.

    I would like to add one point may not be significant, but I personally feel using following setting makes collection more easy:

    “Display” –> “List” instead of tree.

  • Hey Suman,
    Good to see such a helpful blog. Although the primary objective of the blog is to avoid transport failure I would like to share few quick thoughts if it is helpful..

    If we come across a failure in any of our transport while importing fron Dev to QA.. as we collect the correction I believe it will always be safer to do an Object Directory Entry of the previously failed transport to the newer one.

    For, example often we forget to collect RKFs, CKFs while collecting queries or we collect the query first and then create new RKFs and CKFs with changes. Once we realise the mistake we can collect RKFs and CKFs and just do object directory entry of previously failed transport. ( In case we want to find which RKFs. CKFs, Variables we forgot to collect use SE38 program CHECK_MISSING_ELEMENTS in target system)

    For a fresh development it is always advisable if we grup the objects as below–

    1) Data source in BW and Infopackage in a single tranport.

    2) Infocube, DSO.. other data targets, Multiproviders in one single tranport,

    3) Transformations and DTPs in one single transport.

    4) Queries in a single tranport

    5) Process chain related stuff in single transport and so on..

    and maintain the dependencies while importing.

    Also, while sending a correction to the transformation, we may not require to collect the DTP again if there is no change in the DTP, as upon execution of the DTP, if the transformation is active DTP will automatically get activated in target system. However, this holds true when there is no change in the DTP itself.

    Always do a check of your task through program RSO_TLOGO_CHECK_REQUEST before we release it. We can also check for inactive object, Object syntax check through menu path in SE01.

    If any object is changed in quality directly, then before sending them again from dev after correction we should always RESET the repair flag from SE03 from menu “Display Repaired Objects”.

    Hope this adds value.



    • Hi Sourav,

      Good points ! Thank you for sharing here!!

      As I mentioned in the beginning of the blog, I did not want to discuss on standard collecting procedure for a fresh development.