Skip to Content
avatar image
Former Member

Maintaining transport request move sequence

Dear All,

Wish you happy new year.

We have one development server (Sandbox), Quality Server then training server and finally production server.

suppose I Developed an application (ALV Report) in development server , then transported it to quality server for testing the same, and again due to some error or change in requirement modified the same  2 -3 times and transported it back into quality server. Now finally solution is accepted by functional person.

here My question is : do I need to keep track of all the Transport Requests from creation of the program to final version. is all the transport request move sequence is required to move the same program into production server.

if yes then from where I can get it as I copied it from SE09. but I feel this is not the correct way to maintain please share if any template or tcode which give u all the sequence of the transport requests for a particular program.

thanks in advance

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

4 Answers

  • Best Answer
    Jan 02, 2015 at 07:24 AM

    Vinay Kr Chowdhary wrote:

    here My question is : do I need to keep track of all the Transport Requests from creation of the program to final version. is all the transport request move sequence is required to move the same program into production server.

    Essentially yes. The contents of transport requests are deltas just the changed objects/subobjects/components from the previous version. So for programs, after the initial transport, you only get the actual components touched recorded in a transport.

    There are various ways of managing this, which can be automated to an extent. For example:

    1. Create a transport

    2. Do your work

    3. Make a Transport of Copies (ToC) from the transport at 1.

    4. Transport the ToC to test. (Never to production).

    5. Make fixes (your transport at 1 is still open, so everything can go against that).

    6. Go through 3-4 until the testers are happy

    7. Release the transport at 1, import into test, import into production.

    Message was edited by: Matthew Billingham - removed "delta" from the explanation

    Add comment
    10|10000 characters needed characters exceeded

    • Volker Wegert wrote:

      However, I would suggest to never call this a delta because it's always an entire program, include, class or whatever other object that is transported.



      I agree that delta is not the best description. Perhaps "the changed object/subobject" would be better. Because it isn't the entire program. You create a new report Z_MY_NEW_PROGRAM with include Z_MY_INCLUDE. The entry is

      R3TR PROG Z_MY_NEW_PROGRAM

      You release that transport and modify the include source code. The new transport contains

      LIMU REPS Z_MY_INCLUDE

      If you only import into production the second transport, you don't have the complete object.

      Similarly with classes, function groups, modules etc.

  • Jan 02, 2015 at 06:09 AM

    Hi Vinay,

    Basically we use the SE03 T-Code to get the all TR information of any of the object.

    But is display the TR of based on the entered single object.

    But in your case, scenario could be different, for the easy solution I can say,

    1. Take the Initial TR of the Program (Which Contains the all Programs, Include & other related objects).

    2. Then Take the all Final or Last TR of the all objects (if Object had been changed while doing correction).

    3. Send the all above TR's in sequence in PRD or Sandbox client.

    Note: If any DD (Data Dictionary) object created, then DD respective TR's should be send first.

    Regards.

    Praveer.


    Add comment
    10|10000 characters needed characters exceeded

  • Jan 02, 2015 at 06:09 AM

    Hi Vinay,

    First of all, whenever we use to make changes in the program, we always keep in our mind that, the TR needs to moved to production system. So the remote comparison in TR should be done before releasing the TR from Dev system. Before releasing the TR, we should merge the recent TR's which is not included in production system.

    If proper merge done , then we won't face the problem during importing the TR in PRD System.

    In your case, we can use Transport of Copies option to merge the existing TR from Dev. Then we can import the Single TR to production system.

    Regards

    Rajkumar Narasimman

    Add comment
    10|10000 characters needed characters exceeded

  • Jan 02, 2015 at 10:10 AM

    If you want to keep it safe and simple for smaller developments, then keep track of all transport requests related to your development and have them imported into production at the same time (STMS will ensure the correct import sequence).

    For larger developments, the Transport of Copies approach described by Matthew should be considered.

    Further reading:Transport Management with Transports of Copies

    Thomas

    Add comment
    10|10000 characters needed characters exceeded