Role of the SLD in PI Landscapes

The SLD is used in PI landscapes in the following way.

At design time, the SLD needs to be accessed for the following purposes: It provides a software catalog that stores information of products and software components. A software component is a shipment unit for design objects in the ES Repository, for example, integration scenarios or interface objects. When you create design objects in the ES Repository for productive usage, as a prerequisite you need to import an SLD-based software component into the ES Repository.

At configuration time and runtime, the SLD needs to be accessed for the following purposes: It stores information on business systems and technical systems. A business system represents a logical system that is used as sender or receiver of messages in an integration scenario. A technical system represents the physical system as identified by a server address and other attributes. When you configure an integration scenario for a specific system landscape using the Integration Directory as configuration tool, you rely on the SLD data. At runtime, the correlation between business systems and assigned technical systems also needs to be evaluated.

For performance reasons, relevant SLD data is hold in an SLD cache – to allow faster access from Integration Directory or runtime engines to SLD data. In order to allow SLD cache refresh, the availability of the SLD is critical.

SLD also contains the mapping of business system names as used in the development, test and productive landscapes. To evaluate this mapping, availability of the SLD is also critical when transporting Integration Directory content from a development to a test environment, for example.

To summarize, availability of the SLD is critical for the following activities:

Recommendations for SLD Landscapes

The general recommendation is to set up one (central) SLD for each productive PI landscape.

As availability of the SLD is critical for productive usage of PI, in a federated PI landscape you can set up additional (local) SLDs for each local PI instance.

In addition to that – depending on the individual requirements of your business – you can set up a separate SLD for each non-productive landscape like development or test landscape, for example.

In order to come to a final decision of your SLD landscape design, you need to trade the advantages of one single central SLD (low hardware requirements and low operation costs) off against the needs of high availability of SLD data.

More information: Planning Guide – System Landscape Directory available under http://www.sdn.sap.com/irj/sdn/nw-sld (How to Plan Your SLD System Landscape)