Show TOC

SLD Content SynchronizationLocate this document in the navigation structure


In your system landscape, you might face the requirement to run more than one SLD system and to transport (or synchronize) content between these different SLD systems. In the past, this could only be done by the following processes:

  • SLD bridge forwarding: You can configure an SLD to transport data received from SLD data suppliers automatically to other SLD systems - manually entered data can not be transported automatically with SLD bridge forwarding.

  • Incremental exports and imports (a process with which you can transport all SLD data, but you have to perform it manually).

With SLD content synchronization, it is now possible to define the required transport topology and perform automated synchronization of all content changes without regular manual operations.

The following figure shows an example for a global or widely distributed IT landscape. More than a single central SLD may be required because it is expected that an SLD is available locally but that it provides a more than a local view. This and other examples can be found in the Planning Guide - System Landscape Directory at .

Content synchronization is configured on the level of CIM namespaces. This means changes in one CIM namespace are transported to another CIM namespace. Both namespaces can reside in the same SLD system (local synchronization), but will typically reside in two different SLD systems (remote synchronization). For simplicity reasons, this documentation only describes remote synchronization between different SLD systems. However, all considerations equally apply for local synchronization.

Properties and Features

SLD content synchronization has the following properties and features:

  • Content synchronization can be configured for unidirectional or bidirectional use. Unidirectional synchronization is used for transport topologies where changes are only transported from the source to the target system. Bidirectional synchronization is employed when changes need to be transported mutually between systems.

  • Changes are synchronized using a "publish and subscribe" mechanism. Listener systems can either periodically poll for changes or they can be notified of changes, or both.

  • Changes are recorded synchronously in the SLD system where they are applied (in the SLD change log).

  • The content synchronization process is performed asynchronously. Thus, participating SLD systems can be unreachable temporarily (for example, due to network or system downtime) without disrupting the overall synchronization process.

  • Reconciliation of conflicts (due to conflicting parallel changes) is done automatically, no user interaction is required. For this purpose, you need to assign a rank to each participating SLD namespace during configuration. This rank defines the outcome of reconciliation: Changes of a higher ranking namespace override conflicting changes of a lower ranking namespace. This implies that a change in a lower ranking namespace is an "optimistic write".

  • Content synchronization is only possible for the whole content of participating namespaces; filtering of namespace content to be synchronized is not supported.

  • All communication related to content synchronization between SLD systems is based on HTTP or HTTPS. This simplifies configuration of firewalls, for example.

  • The SLD content synchronization is fully supported by AS Java 7.1 and above. Additionally, an SLD of version 7.0 SP12 and above can be used as source system for unidirectional synchronization only. Systems with version 7.0 do not support the notification of listener systems.

Usage Rules

To ensure correct synchronization, certain rules must be adhered to when defining a content synchronization topology:

  • Each SLD system participating in a landscape must have a unique object server name to correctly identify the origin of changes. However, this is not specific to content synchronization, but is recommended for any SLD system.

  • Each namespace included in a synchronization landscape should have a unique rank. Otherwise conflicts may not be resolved correctly because none of the conflicting changes has a higher rank, leading to an unsynchronized differing end state in different namespaces.

  • In a complex landscape (with more than two synchronized namespaces or systems) the synchronization topology should adhere to the unique path principle. This means that a change in an origin system A must only have one transport path to any listener system B. Otherwise subsequent changes in A could travel over different paths to and be processed out of order by B, leading to an erroneous end state in B. The following figure shows an example for a violation of the unique path principle, where changes from A can travel to B either directly or via C. The bidirectional synchronization between A and B does not violate the unique path principle for the opposite direction from B to A.

Once your content synchronization topology is defined and active, model or content updates only need to be applied to one specific SLD from where they will be forwarded to other participating SLD systems. Select the SLD system to update according to the following rules:

  • If possible, updates should be applied to the SLD with highest rank. This ensures updates are accepted by all other SLD systems and avoids unnecessary overhead during propagation of these changes.

  • For a unidirectional synchronization, updates must be applied at the source of the unidirectional path to reach all participating systems. If updates are not meant to reach all participating SLD systems on purpose, they may be applied to a system anywhere in a unidirectional path. However, these updates must not violate the unique path principle. For SAP CR content updates (see SAP Note 669669 Information published on SAP site) this means that they must be applied at the source, and only at the source, of the unidirectional path. Otherwise, the target SLD would receive CR content updates by direct import and via synchronization from the source.

Typical Scenarios

Various reasons can lead to the use of multiple SLD systems and requirements for content synchronization between them. These can be legal constraints, company rules, availability considerations, network constraints (such as firewalls) or the possibility to provide different views of SLD data (for example, to hide productive systems from the DEV landscape). As a result, some typical use cases for content synchronization are:

  • Transport topology for a landscape like DEV - TEST - PROD.

  • Managing complex landscapes distributed over multiple computer centers and/or optimized for decentralized use.

    For more information, see the Planning Guide - System Landscape Directory at .

  • SLD migration

    A new SLD system can be installed in parallel to an old one. Using content synchronization and host name virtualization (for example, by DNS aliasing), continuous availability can be reached for all software life-cycle tasks (such as applying patches, performing upgrades and hardware relocation).

  • Namespace copy

    A second namespace with the same content can easily be set up by configuring an appropriate (most likely unidirectional) synchronization. This has some advantages over using backup or full and incremental exports. Other than a backup or an export, content synchronization does not lock the source namespace against concurrent changes. Later changes in the source namespace are easily transported to the copied namespace as long as desired until the synchronization is removed or deactivated.