How does version management work in Enterprise Service Repository/Integration Repository?

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.