Skip to Content

Customers some times run into issues with transporting object from one system to another.

For example:

  •      The change in the transported object does not get reflected on the target system.
  •       The transported object does not appear in the target system at all even thought the transport finished successfully.
  •       Transport resulted in a cyclic conflict that can’t be resolved by the conflict editor.

The Integration Builder manages version info of every object in a tree structure.

When you create an object and activate it, there would be 1 node in the tree:

(V1)

By editing the object and activating it, a new version(node) will be added into the tree:

(V1)

  |

(V2)

By transporting the object from one system to another, only the latest version would be transported.

Source system               Target System

        (V1)

           |

        (V2)              ->             (V2)

If you change an object on a system which is not the original system where the object was created, a new branch would be created.

Non-Original system

         (V1)

                  \

                    (V2′)

Conflict will occur if the transported version is not in the same branch as the latest version in the target system

Source system               Target System

        (V1)                              (V1)

           |                                       \                        

        (V2)              ->                     (V2′)

The tree would look like:

         (V1)

           |     \

         (V2)    (V2′)   

You would have to choose which version(the current active version V2′ or conflicting version V2) you want to use as the latest/active version.

Then the system would discard the branch you don’t choose:

If you choose the active version:                         

         (V1)

           X     \

         (V2)    (V2′)   

Later on if you try to transport this object again from the source system to the target system:

Source system               Target System

        (V1)                              (V1)

           |                                  X    \                      

        (V2)              ->             (V2)    (V2′)

As the branch is already discarded on the target system, version V2 will not become the latest version.

That’s why the “change” does not seem to get reflected. So how to transport version V2 to the target system?

It’s easy: Creating a new version on the source system by a dummy change(e.g., change the description) and transport again:

Source system               Target System

        (V1)                              (V1)

           |                                  X    \                      

        (V2)                              (V2)    (V2′)

           |                                   |

        (V3)              ->             (V3)

This would result in a new version conflict and you can choose the conflicting version this time.

The situation is almost the same for the case which the transported object does not appear at all.

The important thing to know is that deleting an object will not actually delete it but create a new version(a deleted version).

It’s most likely that the object has been deleted on the target system.

Source system               Target System

        (V1)                              (V1)

                                                  \                      

                                                   (V2′) -> The deleted version

The solution is the same: create a new version on the source and transport it to the target:

Source system               Target System

        (V1)                              (V1)

           |                                       \                       

        (V2)              ->                     (V2′)

The cyclic conflict occurs when you have three different system:

Source system               Target System 1              Target System 2

        (V1)                              (V1)                                 (V1)

           |                                   |     X                               X    \

        (V2)                              (V2)      (V2′)                     (V2)    (V2′)

Conflict occurred on both target system 1 and 2 and you chose different version in conflict editor.

Now if you transport the object again from system 1 to 2 or 2 to 1, the cyclic conflict will occur.

This kind of conflict can’t be resolved by the conflict editor and has to be fix by modifying the DB directly.

SAP recommends developing ESR objects in one system only and transport them into different landscape.

This can avoid all the issue mentioned above and is the ideal way for version management.

P.S. Unlike version management in ESR, the transport of object in Integration Directory will always create a new version on the target system.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Georgia Komianou

    Many thanks for this post!!  I had this problem recently when moving a few SWC changes into a development environment (we have 2 dev environments due to current landscape requirements and the SWC had already been manually changed previously in the target environment).  

    I ended up deleting the target SWC and re-importing the entire thing rather than just the changes.  This fixed the issue but I was still unclear as to what had happened.

    (0) 
  2. Apu Das

    Thanks a lot for the following document. This document is really very helpful to find out the real problem of transportation from development to quality or in production . Sometimes its very difficult to find out the  actual problem .

    (0) 
  3. Shawn Tan

    Hi Daniel,

    I came across your and find very informational. I need your advice and i hope you can share some light with me. Currently, we are migrating from SAP PI 7.11 to SAP PO 7.4. Please see the steps taken by as me below. Hope you can help me. Thanks.

    Steps:

    1. Export the ESR content from Dev Server in SAP PI 7.11 and import it to Dev Server SAP PO 7.4 using file transport.
    2. Made some changes to the Service Interface in the Dev Server SAP PO 7.4.
    3. Decided to revert back the changes. Therefore, i export the ESR content from the Prod Server SAP PI 7.11 and import it to the Dev Server SAP PO 7.4 using file transport. However, the changes was not reflected in the Dev Server SAP PO 7.4.

    Regards,

    Shawn

    (0) 
    1. Daniel Li Post author

      Hi Shawm,

      If you want to revert back to the version when you first transport the object from 711 to 740, simply select the version from the history and edit it to make it the latest version.

      Regards,

      Daniel

      (0) 
  4. Siva Reddy Chintakuntla

    Hi Daniel,

     

    Glad to see your more informative article, thanks for it!

    however i currently running after the same issue but mine is with integration Directory. Recently we start building a new PI systems by copying existing production ( Production -> D0 -> D2) ¬†for various projects. Unfortunately i got an issue while activating few of the objects in D2 (It’s a copy of D0 and D0 is copy of production) and the error is (The following objects have previous versions that are no longer active:
    Receiver Determination TSR | STS_TSR | TOTALSData_Out | * | *

    Open these objects in the editor and perform a conflict resolution
    See error logs for details¬†) but i don’t see any editor (may be conflict Tab) . Can you please advise is there any way to resolve it? Appreciate your quick help.

     

    Regards,

    Siva.

    (0) 

Leave a Reply