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:

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

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:

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.

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).

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.

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:

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.

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.

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.