Show TOC

Exporting and Backing Up Your SLD InformationLocate this document in the navigation structure


All SLD data is stored in the AS Java database and is therefore automatically backed up during the database backup. However, there are scenarios where it is useful to export SLD-specific data. SLD provides different mechanisms for these purposes:

  • Producing unversioned backups

  • Performing versioned exports of specific export lines

  • Selectively exporting individual objects stored in SLD

The following table gives an overview of typical scenarios. More details are explained in subsequent chapters below.

Scenario or Use Case

Proposed Procedure

Backup of all SLD data

(before installing updates or patches, before updating the Software Catalog, etc.)

Unversioned backup of All CIM Instances .

SLD system copy:

Setup of a new SLD system with initial content from an existing system.

Import an unversioned backup of All CIM Instances from the source system into the new system.

Synchronization of all content:

Regular transports of all changes between different SLD systems.

Versioned exports of All CIM Instances .

Alternative: SLD Content Synchronization

Synchronization of partial content:

Regular transports of content changes between different SLD systems for parts of SLD data.

Versioned exports of required export line, for example Landscape Directory, to transport system data only.

Alternative: Automatic forwarding of system registrations to other SLDs.

Selective copy of SLD data

Example: Export a business system from one SLD and import it into another one.

Export Lines of SLD Data

Depending on the subset of SLD data you want to export or back up, you can select from the following export lines defined in SLD:

  • All CIM Instances

    This line encompasses all data stored in SLD (see scenarios 1, 2, and 3).

  • Landscape Directory

    This line is used for landscape data only. This includes technical systems, business systems, and so on (see scenario Synchronization of partial content ).

  • Component Repository

    This line includes all Component Repository data (software components, products, and so on). This means it includes both SAP Component Repository content as well as any of your own products and software components you may have defined.

  • Name Reservation

    This line is used for name reservation data only.

In general, different export lines are independent of each other. However there are some things to consider when working with different lines:

  • Data exported or backed up using the Landscape Directory line depends on Component Repository content present at the time of export. Therefore you should take care when importing such data into another SLD, as the target SLD should contain the same or a newer version of the Component Repository content to avoid import errors due to missing component repository objects.

  • Because exports of All CIM Instances contain all data, this line is incompatible with all other lines. This means that you should not import data of subset All CIM Instances into a target system that already contains imports of other data (or vice versa). During the import checks you will get an appropriate warning and should cancel the import.

  • In particular, SAP Component Repository content must not be imported into target systems of export lines that already include this content. This means that any system you use for versioned imports of All CIM Instances or Component Repository must not be updated directly with SAP Component Repository content.

Unversioned Backups

Unversioned backups contain a snapshot of the current state of the SLD. You can use them to copy an SLD system or to restore it after a crash. Backups themselves are not stored in the database; they are saved by the user after the backup is finished. In contrast to versioned exports they cannot be used to transport changes regularly.

Various options for backups are available:

  • Back Up All Instances

    Produce a snapshot of all data currently stored in SLD. This is the most commonly used option for backups (see scenario 1).

  • Back Up Model

    Back up the SLD data model. Together with Back Up All Instances this can be used to import a snapshot of both data model and instance data into a new system.

  • Back Up Instances by Export Line

    You can use the same export lines that are available for versioned exports to produce an unversioned backup of data belonging to each export line. This option is used rarely, but may be useful if you want to back up data of a specific line only, for example Landscape Directory.

  • Back Up Instances by Class

    You can back up instances of selected classes of the SLD data model. This option is used rarely.

To ensure consistency, the backup namespace is locked against concurrent changes while a backup is running.

For more information about how to perform a backup, see Producing Unversioned Backups .

Versioned Exports

Versioned exports are used to transport updates of data from one SLD to another regularly. They contain information about additions, modifications, and deletions. Exports are directly related to a specific export line and provide a history of content versions for the selected export line. The history of every line starts with an initial full export containing all data for this line at the time of export. Later incremental exports only contain changes, including additions and removals that occurred since the last export.

Next shows a typical scenario where all changes of a source SLD are transported to a target SLD (see scenario 3 above). In this case SAP CR content must be imported into the source SLD only, not into the target SLD. Initially the target SLD should not contain any SAP CR content or the same version of SAP CR content that is delivered with the initial full export. Otherwise there will be content mismatches that will lead to import errors.

An import into a target system or namespace always starts with a full import. Afterwards updates are applied by incremental imports in the same order as they were produced. To facilitate transports into a new system without having to import a long history of versioned exports, new full exports can be produced at any point during the version history. A full export of this type is always accompanied by a corresponding incremental export containing the same end state. The initial full export is the only export that has no related incremental export.


You never import more than one full export of a given export line into a target system. Once the full import is finished, only incremental imports are used. Later full exports are only used for new systems that have not yet received any previous data of the corresponding export line.


All versioned exports are stored in the database and can be downloaded whenever necessary at a later time by choosing Start of the navigation path Administration Next navigation step Export  Next navigation step  Administrate Incremental Exports End of the navigation path.

To simplify the import of multiple incremental exports it is possible to aggregate them into a single file. An aggregate export contains multiple consecutive incremental export versions (incremental aggregate). The first version in an aggregate export may also be a full export (full aggregate).


For example, consider an export system where you have performed an initial full export 1.0 and incremental exports 1.1 through 1.5. Now you can produce an aggregate export containing versions 1.0 through 1.5. This export can be used as an initial import into a new system because it starts with a full export. After the import the new system will contain version 1.5. Alternatively, this aggregate can be used to update any target system to version 1.5 that contains any previous version 1.0 through 1.4.


Note that aggregate exports starting with a full export are only supported by version 7.10 and above. Imports into older SLD releases are able to process incremental aggregate exports only.


Updates of the Software Catalog are created as exports from an SAP master system. The files published on SAP Service Marketplace are full exports providing initial content for setting up new systems and incremental aggregate exports containing updates.

To produce incremental exports, information from the SLD change log is used. Therefore change log entries must not be deleted when they may still be required for future incremental exports. You will be warned about this situation when you try to remove required change log entries using the SLD UI.


You should never produce a full versioned export when you do not intend to start regular transports to another system. Use an unversioned backup instead. Otherwise you are forced to keep any change log entries starting from the time of the full export.

To ensure consistency, the export namespace is locked against concurrent changes while an export is running.

For more information about how to perform a versioned export, see Producing Versioned Exports .

Special Exports

At different locations in the SLD Web user interface you can export individual objects.

You can use the individual export option on the Landscape and Software Catalog pages for selective distribution of technical or business systems and products or software components.

These partial exports typically contain associations to objects not being exported themselves (called "external references"). For example, a business system export does not include the underlying technical system. Thus external references cannot be imported if referenced objects are missing in the target system. You may repair this loss of data by transporting or creating missing objects and repeating the import. In the example mentioned before, you have to import the technical system first if it does not exist in the target SLD yet.

The following table displays the various types of special export objects and their possible dependencies:

Type of speci al export objects


Technical systems

Products / software components

Business systems

Technical systems and products / software components

Non-SAP products / software components

Other products / software components


Note that manually creating the same software component or the same PI business system in another SLD will create a different GUID. As a result, these objects are not identical even though their names are the same. Hence, use the individual export option to distribute this data. Do not enter it manually in multiple systems.

Synchronizing Content of SLD Server Instances

Versioned exports can be used to synchronize content of different SLD instances.

In the most typical scenario export line All Instances is used for this purpose (see figure above). Because this export line contains all data, the export system becomes the exclusive supplier for following systems. Therefore SAP Component Repository content must only be imported into the export system. It is distributed from there along with any other data.


An example of this is the use of separate production and non-production SLD instances. Typically you will need to transport changes from the non-production SLD to the production SLD, not vice versa. As a result all systems are displayed in the production SLD, whereas the non-production SLD does not contain data about productive systems.

If you want to include an additional SLD instance in the transport route that already contains Component Repository content independently of the exclusive supplier, you must first update this SLD instance to the same Component Repository content version as the one installed on the supplier system.


Note that the synchronization of all data of different SLD systems can also be achieved using SLD Content Synchronization without the need for regular manual exports and imports. In contrast to versioned exports, content synchronization also supports bidirectional synchronization.

There are other ways of synchronizing SLD instances, but these are limited to specific applications. For example, the SAP Component Repository content can be updated separately in different systems, while only Landscape Directory data is distributed by means of exports and imports. This is a useful configuration if no customer development is performed. Alternatively, you may want to distribute landscape data by forwarding reporting systems to secondary SLD instances automatically. This can be configured on the Data Supplier pages.

More Information

You can import both exports and backups into another SLD system.

More information: Updating the Software Catalog .

More information about import error handling: SAP Note 1045423 Information published on SAP site.