Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
wolf_hengevoss
Active Participant
Last update: 25th of July 2019

Conflicts and Conflict Resolution


SAP NetWeaver System Landscape Directory as of SAP NetWeaver AS Java 7.1 features the Full Automatic Sync feature, which is also used to retrieve data from SLD systems into the LMDB (see Demo: The Full Automatic Sync Feature in the SLD of SAP NetWeaver 7.1.
This function allows you to connect systems to automatically update data incrementally when changes occur and provides automatic conflict resolution. But what is a conflict? We see it as a conflict if data of one object - for example the meta data of a technical system - is available in different versions (temporarily), and when both versions "meet" in one repository. Without further information, it cannot be decided automatically, which version to use because there is no clear sequence of these versions. Or to put it this way: To safely replace one version with another, the new version should be a direct successor of the version to be replaced.
Figure 1 shows a conflict between two versions in a repository:



Figure 1: How do conflicts originate? Two repositories are connected to transport versions from repository 1 to repository 2:

  1. In repository 1 version a1 is created.

  2. Version a1 is synced to repository 2.

  3. In both repositories changes lead to new versions:
    - Repository 1: Version a3 is the successor of version a2.
    - Repository 2: Version a2* is the successor of version a1.

  4. The sync from repository 1 to repository 2, causes a conflict, because there is not a clear sequence between a3 and a2*


 

 

 

How the conflict is handled depends on the repository.There are two different ways to solve such conflicts we should discuss here:

  • Let the user decide: Inform the user about them and let him choose how to handle the conflict (this is an approach you find in development repositories, for example, purely based on the sequence number of object, so that the conflict will also be detected if both versions a3 and a2* are identical).

  • Let the system decide: This approach is chosen for the System Landscape Directory: All systems in a synchronization connection have a rank. Systems with a higher rank accept changes from a lower ranked system only if there is no conflict.
    If there is a conflict, the higher-ranking system decides about the resulting state. Systems with a lower rank accept all changes from a repository with the higher rank. In contrast to the development repository described above, in Content Sync instead of comparing the sequence number only the versions' content is compared. (Normally, changes in 2 different repositories will not be identical therefore you will probably get a conflict in the scenario described.)


Scenarios in Full Automatic Content Sync


Sync connections can be unidirectional or bidirectional. Quite easily understandable in the first case one SLD updates the other, while in the second case both SLD systems mutually update each other incrementally once they are in sync.

The kind of connection and the way it is used influences the occurrence of conflicts. We find the following (main) use cases:

  • Unidirectional Content Sync: One reason to set up a uni-directional connection is a migration of an SLD system to another server. Content Sync is used to transfer all data to the new SLD before shutting down the old one. For other scenarios, this setup is not recommended between SLD systems since in many cases the forwarding of technical systems' data was sufficient, or the export/import of data was better suited because of the filtering it allowed and the control of the content and point in time when changes are transported.

  • Bidirectional Content Sync: The main scenario here is the set-up of a hot-backup SLD as described in SDN blogs "SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?" and "How to Ensure that SLD Data is Available during Maintenance".


Luckily, both these scenarios have in common you would not tend to run into conflicts. In the unidirectional Content Sync scenario you would probably maintain data in the old SLD until the system switch and then work in the new SLD, while with the bidirectional setup, with synchronization running constantly, all intermediate versions would be available on both systems, so every new version is a direct successor of all others.

Nevertheless: In case you use a unidirectional Content Sync in a setup, where both SLDs are working in parallel, conflicts will become a topic to be aware of. In a bidirectional setup conflicts only occur for nearly parallel and conflicting changes of the same object in different SLD systems.

Automated Conflict Handling in Unidirectional Content Synchronization


In case you use a unidirectional Content Sync, in scenarios other than migrating data once, you could run into the following situation (this in fact is the situation described generically in figure 1 in a life-like setup of landscape repositories in a landscape).

Figure 2 describes a scenario, where the best practices recommendation has not been followed: Instead of the source SLD the target SLD is ranking higher (Note: this was defined for means of discussion and should be avoided in the landscape if possible.)



Figure 2: Landscape repositories with unidirectional full automatic Content Sync. Conflict-free and conflicting update cases. Technical System "TS1" reports its data to the SLD 1; SLD 1 (low sync rank) updates the SLD 2 (higher sync rank) by Full Automatic Content Sync.
(Note that this is described for means of didcussion, and is not a recommended setup for SLD systems connected in your landscape)


  1. TS1 data becomes available in the SLD 1 in version 1 without problems.

  2. TS1 data are changed in SLD to version 2: This version is a direct successor of unchanged TS1 data version 1, so SLD 2 content is updated successfully.

  3. TS1 is changed in SLD 2 (version 3*); then in SLD 1 version 2 is changed to version 3: For these versions 3 and 3*, there is a conflict. Version 2* is not updated in SLD 2 by the Content Sync due to its higher rank.


 

Note that you can avoid conflicts, if you assign the higher rank to the source SLD.

So a system's rank defines if it accepts changes of a different system in case of version discrepancies: Versions created in a higher ranked system will not be replaced with versions from lower ranked systems in case of conflicts.  They will be accepted if the ranks are interchanged, but switching ranks is not a valid procedure.


Avoiding and Handling Conflicts - Best Practices


To avoid inconsistencies in SLD systems, follow the best practices:

  • Synchronizing landscape data by Full Automatic Synchronization requires you to set a rank for each system in such a  Full Automatic Content Sync connection.

  • Setting the higher rank in…

    • … SLD-SLD connection: Set the source System Landscape Directory of the synchronization to a higher rank (higher numerical value).

    • … SLD-LMDB connection: Set the LMDB system to the highest rank in the landscape; the reason is that the LMDB acts as a single source of truth in SAP Solution Manager so that manual changes in the LMDB shall not be overwritten by an SLD.



  • Only do changes on the source system (recommended) or on the target system (this should only be done, if no client applications use the source SLD) but never on both systems.

  • In case of an existing conflict, when the source system is on a lower rank, repeat the change manually in the source system in the identical way. (In our example, bring TS1 data in the source to 3* also, then future changes will be accepted. This is possible, because the versions' content is detected, and compare is not based on the sequence number.)


LMDB Change Log


Effects of changes can be identified in the LMDB change log:

  • Synchronization messages of Event=Create stem from sync conflicts: The state of the data from the SLD (User=SOLMAN_BTC) doesn’t fit the current state in the LMDB. Therefore, - due to the higher rank of the LMDB – the change is not accepted; the state of the LMDB is sent as a correction with event type Create, flagged as a synchronization message but not as a local change.

  • A „Resync from SLD“ would usually solve this conflict; but there are possible exceptions, for example: The „Description“ in the SLD is usually empty, in the LMDB you can maintain it. In such a case, the „conflict“ would still be there after a Re-Sync, because of the LMDB having „more “ data than the SLD.


See the following screenshot of a LMDB change log:



Figure: Change log of one CIM instance.

Related Links


For details on connections to exchange landscape data, refer to

For an overview, see Landscape Management Process section
2 Comments