Skip to Content

How-to store dependencies between transport requests

I’ve always found it annoying that SAP does not provide any functionnality to check transport request dependencies before importing them to a target system (even limited to the obvious ones). And at least we would expect the possibility to record those dependencies manually. Which unfortunately you cannot do unless you are working with “transport control using projects”, and trying to set dependencies between requests belonging to different projects…

See online help for more information in this area:

Would be great to know why SAP decided to limit this very cool feature so much. I mean: if it is a best practice to re-use abap objects, then it shoudn’t be that unusual to develop a program which uses data elements created for another program whithin the same project (and you cannot put both programs into the same transport request for whatever reason…).

So if you ever faced a situation where you developped something new (which you included in transport request ZZ) and knew at the time of coding that transport request XX should be transported beforehand because you were re-using some of its components, but couldn’t save this dependency anywhere which resulted in error status 8 when transport request ZZ was imported to QA system (because your colleague forgot to transport XX before going on holidays), you migth be interested in the following trick…

Open the transport organizer (tcode SE03) and click the “Display/Change request attributes” button under the “Administration” folder:


Create a new attribute that you will use to record the ID of any transport request (XX in the above example) that needs to be transported before the one selected (ZZ):



Now if you create/change a transport request (tcode SE01), the attribute that you’ve just created can be filled in on tab “properties” with any dependent request:


You’re done.

When you (or any other person) release this transport request, it is very easy to check that every request under the “ZPREV_REQUEST” attribute is already imported to your target system. And an even better option would be to automate this check in badi CTS_REQUEST_CHECK…

Part II: On my way to resolve transport request dependencies

Part III: How-to check dependencies between transport requests

You must be Logged on to comment or reply to a post.
  • Thanks for the blog post Nicolas.

    You know what, I never really gave this much thought but it is always a pain when transporting objects, transports fail due to objects your development is reliant upon not being in the target system.

    As someone who works with BW quite a lot this happens on just about every decent size project I’ve worked on. BW is a little bit different in that it does have its own transport organiser, but it would be great if the people moving BW objects could check transports automatically in a source system such as ECC prior to moving the transport to the next system in the transport route.

    I guess this is where some custom BADI coding would come in.



    • Hi Pete,

      Thanks for sharing your thoughts. Actually a friend of mine has been working on a “transport sequencer” program the past weeks… and I’m looking forward to seeing his project in the code exchange section soon 🙂

      It follows a very simple logic: you select a transport request, and the program will scan every ‘Z’ object (function module, method, include, etc.) to check if every component used in the code is already included in a released request (we assume every released request is transported for now). It relies on regular expressions, so every statement like DATA, CALL FUNCTION, CALL METHOD, etc. is easily traced down recursively…

      In the end the program gives you the correct sequence to release/import your requests. We’ve been using it for a couple of weeks and I must admit that it successfully prevented many transport failures…

      Hope to see it soon on SDN so the community migth help us improve it. I’ll update this post with the corresponding link once the nugget is available.



  • Hello Nicolas,

    In my previous project we used TR attributes extensively, but i feel that this feature is not very widely known. Thanks for sharing this info 🙂

    I have an observation – i’m on ECC5.0 & the TR attributes administration is available in SE03 trxn & not SE09. May be you made a typo!



  • Thanks for your blog, Nicolas.

    With high interest I read your article and comments about SAP’s change and transport system (CTS) and possible dependencies between transport requests. The desired dependency check is indeed an important topic and SAP is currently working on it.

    We’re planning to provide a “dependency- and downgrade-check” for transport requests.

    This check can be executed before importing the requests into the target system.

    Currently SAP is focusing on syntactical dependencies, which can be calculated without semantical knowledge. In this way the right order and consistency of the imports can be ensured.

    Further details will be published here on SCN in the context of the “Software Logistics Toolset 1.0” – the continuous delivery of SL tools. It is planned for one of the upcoming Support Packages of the “SL Toolset 1.0”.

    Best regards,

    • Dear Willi,

      Thanks a lot for this valuable piece of information !!

      Indeed I’m still working on this “transport request sequencer”… but I totally changed the way to find those dependencies, and instead of making use of regular expressions to parse the source code, I decided to make use of the “test import” functionnality :

      But I’m looking forward to seeing what will be delivered through this SL Toolset !

      Thanks again for sharing this information with us.

      Best regards,


  • Hello Nicolas,

    We have the same problem with the transport(XX) dependencies, when we try to release a transport it says that is dependent with another transport(YY). But the transport YY we will not Release it. Everytime when we release the transport XX it is dependent with YY and will have the status PROTECTED.

    Do you have any ideea about this? How can we release the transport XX?

    Thanks in advance,


    • Hi Florin,

      Sorry but I have no clue: as far as I know there is no such check in SAP standard TMS unless you assign your transport requests to different project and fill-in the corresponding dependencies manually… So you may have some custom code that is doing this dependency check for you: some debugging will probably help.



  • Hi Nicolas,

    The transports are in the same project, but inside the transports we had the same Object Name and for this appears the dependency. For the transport that we don’t need we also deleted the dependent Object, but with no success.

    When we try to Release it the same dependency appears and the transport that we want can not be released.



    • Hi Florin,

      are you using the project settings in CTS for this?

      It is quite difficult to judge from a distance what is going wrong here.

      I would suggest that you open a customer message for us (SAP) in the component BC-CTS-ORG and open the connection to your system so that my colleagues doing customer support could take a look

      Thanks and kind regards


  • Hi Karin,

    Thanks for the answer, we already did an OSS ticket and got an answer. We saw that there where some bugs in the dependent transport and we fixed them, after this we could release the transport.

    Thanks and kind regards,