On this page, get an overview of the process to plan a strategy for the system landscape directory of SAP NetWeaver, as described in the Planning Guide - System Landscape Directory.
Process to Define Your SLD Landscape Strategy
You can introduce and run SLD in your SAP NetWeaver landscape in many different ways. Each of these ways has different advantages and disadvantages. Therefore, you should plan the introduction of SLD properly according to your landscape requirements.
Learn SLD Concepts
First, you should familiarize yourself with fundamental concepts of SLD by reading the corresponding sections of the planning guide:
- How SLD receives data from so-called SLD data suppliers; these are programs inside of SAP systems that gather information (like installed software, host and database information, etc.) and send it regularly to the SLD.
- Distribution options (that is, either have a single central SLD or several distributed SLDs) and possible reasons to have more than one SLD (for example, if you have geographically distributed locations with local administration groups that want to see only their local systems in the system landscape directory, to provide different views in the SLDs, to improve availability of SLD data, or to have a sandbox SLD system to test changes before performing them in the system landscape directory used for your production environment). The most straightforward scenario is the use of a single SLD. However, depending on organizational, operational, or security reasons, it is also possible to have more than one SLD distributed over the system landscape. For all landscape scenarios, the use of DNS aliases to address SLD makes it possible to switch SLD hosts very easily.
- Synchronization options (that is, how you can synchronize the content of several SLDs). For this, we offer automatic bridge forwarding and a manual export/import procedure of the SLD. While automatic bridge forwarding only synchronizes certain data stored in SLD (exactly that data that is received by SLD data suppliers, but not data entered manually into SLD - such as business systems used for SAP NetWeaver Process Integration), export/import requires regular manual effort.
In addition, we plan to provide a full automatic synchronization mechanism for all SLD data (that is, data received by data suppliers + data entered manually into SLD) with the upcoming release of SAP NetWeaver. The planning guide provides more information about this feature as well, so you should consider it for your mid- and long-term SLD strategy. - Also, you will get an overview of applications that are using the SLD (the so-called SLD clients).
- In addition, you will get information about what aspects concerning release compatibility play a role when running an SLD in your landscape. Here, you will learn how SLDs with different releases can cooperate, if SLD can receive data from a data supplier running on a different version, and if an SLD client can run against an SLD system with a different version.
- Finally, you will see that SLD provides flexibility so that you can change your SLD landscape also in the future – that is, we provide information how to merge or split SLDs in your landscape.
Decide How Many SLDs You Require
You decide how many SLDs you require. For this, get a clear picture of the requirements that your system landscape/environment demands concerning the data stored in SLD, for example in terms of:
- Applications that rely critically on SLD in your system landscape, required availability of SLD and impact on your system landscape if SLD would temporary not be available
- Required performance for accessing SLD (for example, affected by network lags due to a large physical distance between an SLD client and your SLD itself or improper hardware performance of the host on which you run your SLD)
- Technical constraints of your system landscape (such as networks, firewalls, message volumes, hardware, high availability)
- Visibility and changeability of certain data stored in SLD (for example, you might have the requirement to isolate the data of production systems so that developers can not access them)
- Legal constraints (such as sensitivity of data, retention periods, country specific laws)
- Company rules, organizational structures or governance models
To help you in this step, the planning guide provides information about best practice scenarios that outline some typical use cases for the system landscape directory (such as having a separate SLD for DEV/QA and for PROD or having a dedicated SLD in the role as name server for the SAP NetWeaver Development Infrastructure).
As a result of this step, you should get an idea if a central SLD fits your requirements or how many distributed SLDs you require.
Synchronization
If you require more than one SLD, you have to think about synchronizing the SLD data stored in your SLDs. For this, create a model to understand which data is required in which of your planned SLDs. In addition, you might want to restrict the forwarding of certain data to certain SLDs in your landscape to generate different views. For example, you maybe do not want to forward data of your production systems into a development SLD.
If manual synchronization is required, we recommend that you create some kind of operation manual that helps to establish a process when and how synchronization should be performed by whom.
As a result of this step, you should receive a synchronization strategy for your SLDs.
Where To Run SLD in Your Landscape?
You decide on which system(s) you want to run your SLD(s).
You could either run SLD on a separate AS Java system or run it together with other central shared services or business functions (for example, your SAP NetWeaver Process Integration system) on an existing system.
To a certain degree, this also results from the requirements you are facing in your landscape concerning SLD (for example, high availability features, planned/unplanned downtime, load of the corresponding host, network connection).
The planning guide provides guidance to decide where to run your SLDs in your landscape and corresponding recommendations.
