Skip to Content
Technical Articles

Transport Request Check Tool


While many of us would like to simulate/check our transport request for error before we import the changes into production system, it becomes almost a necessity during big Go-Live’s / Release Management phase to sequence the transport request and check dependency between requests.

Although there are lot of solutions already been implemented like the followings

Home Made Transport Sequencer
Transport Checking Tool Object Level
Program to Simulate Transport Request

it is always best to use tools provided by SAP.


With ST-PI component, SAP has delivered tcode /SDF/TRCHECK (program: /SDF/CMO_TR_CHECK) which makes sure errors of transport request gets detected before TR is imported to production system.

Refer to program documentation for details.

Lot more details can be found in

Note: 2475591
TR check tool


Given that we have a solution doesn’t mean we end up using it to the best of its value. Hence it will be great to integrate this with SE10. ๐Ÿ˜‰

I implemented BADI: CTS_REQUEST_CHECK to execute report: /SDF/CMO_TR_CHECK before releasing the transport request (method: CHECK_BEFORE_RELEASE) and then giving a pop-up to decide if I wish to continue to release the transport request.

Also I created a custom SET/GET parameter to ensure BADI calls report only when the user parameter is set to X.

To conclude:

Results are good ๐Ÿ™‚

Identifies if objects are missing in production system.

Catches missing transport request.

Can be a life saver ๐Ÿ™‚

You must be Logged on to comment or reply to a post.
  • I really need to add that I like this transport checker, but in my opinion it’s something which need to be integrated in a process and not at such a place.

    When people really care about releases and transports the tool is something which just make sure for the quality manager everything is really fine.

    Because just releasing the transport does not save you via “STMS”, and that’s just one example ๐Ÿ˜‰

    • With before_release method, we can identify errors before releasing the TR and stop the release. Then we can make corrections before releasing the TR itself.

      It might save from “STMS” in this case.

  • We are currently experimenting with /SDF/CMO_TR_CHECK as well but are looking for another option:

    • We usually have one transport day per week where changes make it into the productive systems.
    • Developers have to have those of their transports they want to have imported released from the QA-system by (high)noon on that day.
    • Shortly after noon a batch job fills the import queues
    • we have set up a batch job which runs shortly afterwards and executes /SDF/CMO_TR_CHECK following a step for program RSTMSCOL to refresh the queues (it would actually be good if the ST-PI program did just that at the beginning – or have the option to trigger it e.g. via another checkbox on the selection-screen)
    • The plan is to then have developers use program /SDF/CMO_TR_CHECK_HISTORY to look at the results and if need be provide missing transports to be manually added to the queue
    • The first imports into production happen 2 to 3 hours later into a system for Asia-Pacific countries giving us some wiggle-room for corrective measures.

    While experimenting with the program, we noticed that it did catch some issues which could then be corrected before hitting production.



  • Today I learned that /SDF/TRCHECK exists. ๐Ÿ™‚ We have a home-grown program with similar purpose but I’ve had some issues with it recently as it doesn’t seem to work with the classes and SE91 messages. So this should be useful, I hope.

    Thanks for sharing!

  • Hello Rameez,

    Thanks for the blog.

    Two findings uptill now:

    1. The TR input field needs to have some validations, once i mistakenly inputed a 8 digit Transport Request (TR), the report till runs successfully and gives the output… raising eyebrows, how did it check a TR which has only 8 digits, also if a TR doesnt exists in the source system the report still runs.
    2. Sometimes if the RFC to source and target doesn’t works it dosent reports and still runs giving wierd results, but if I go back to SM59 and check the RFC, its actually not working…… but the report fails to give an error providing misleading results.

    So after these experiences I still dont totally depend on this program or have to double check the results manually to be 100% sure…hope SAP will fix these with upcoming patches or notes.

    Another points worth mentioning:

    1. whenever the report is executed manually and for e.g: we have 20 TRs to check, the input of these TRs should be provided in the sequence it was imported in the source/previous system (assuming all 20 TR will be imported together as part of a release cycle) to get the proper output.
    2. The configuration table /SDF/CMO_TR_CONF helps to set parameters for eg: PERIOD (Number of days in analysis period) for this report /SDF/CMO_TR_CHECK.



    • Nice findings. Don’t hesitate to open tickets at SAP to inform of these issues so that they are corrected. That will benefit to everyone.

  • Thanks Abhijit for sharing information with us..

    We have also asked our team to note down the points related to this report.

    One of the points that I noted is that in a standard table if .INCLUDE structure is not yet implemented then the report gives error of object does not exist in target system which is quite confusing.

    Currently our plan is to observe report for a while and the we can submit all findings to SAP at once.