The SLD – not everyone likes it, but everyone needs it. Presumably, the latter is the reason why SAP has managed to make the SLD an integral part of every SAP system landscape as part of its recent product range. Here is a brief overview of the background and concepts.
SLD – what for
The SLD was introduced to provide centralized information about the SAP landscape and your systems. This includes technical names, hosts and releases as well as application names and component versions. As a consumptive system, the SLD receives data from its system components. So-called SLD data providers collect data in the individual subsystems at regular intervals and send it to the directory.
The SLD in turn makes this information available to other applications, such as the Solution Manager, the PI integration platform, or the Netweaver Development Infrastructure.
And the LMDB in SolMan.
… is one of those things. SAP is continuously developing its products – on the one hand, this is good news, but on the other hand, it also means that there are always new surprises – after all, you are settling into the status quo to some extent. However, the ideal solution between SolMan’s own system landscape overview (today: LMDB) and the SLD has still not been found.
SAP recommends to continue using the SLD despite LMDB according to the current recommendations and to synchronize the data fully automatically into the LMDB. If no SLD exists (also because e.g. no PI exists) the SolMan SLD should be used to have an endpoint for the SLD supplier.
There can be only one?
One SLD alone is often not enough to map the system landscape in a meaningful way. Therefore, numerous integrative and infrastructural considerations intrude when an SLD needs to be set up.
Separation of the SLD function in your company
- by region (one SLD for APA, one for EMEA, etc.)
- by system type (one for non-production systems only, one for production systems only)
- by function (one test SLD, one production SLD)
- by availability requirement (keyword SLD Data Clients)
distribution of SLD data
- fully automatic synchronization (supplied and manually maintained data, as of NW7.1)
- Bridge Forwarding of Data Supplier (only delivered data)
- Manual via export or CTS+
The fully automatic synchronization would be a nice way to change the SLD release, for example. After sync, only the connection of the data supplier to the new SLD has to be established (reconfiguration / hostname swap with flushdns).
Space is in the smallest hut….
The simplest configuration is : no PI, no NWDI – only one SLD is needed, and that gladly integrated in an existing application. In small SAP infrastructures it is a good idea to look for a way to avoid another dedicated SAP system. The Solution Manager is often used here, of course SLD-capable and even landscape manager of the first hour – often even already designed highly available.
Above a certain size, however, it makes sense to provide a dedicated SLD. This has to do with availability on the one hand and SLD service consumers on the other – those who use the entire SAP product range (NWDI, SAP PI, Java WebDynpro, ACC) will tend to have higher requirements for SLD availability, and will not be able to take a maintenance window for each (of the very frequent) SolMan patches.
The benefits of dedicated SLD in detail :
- the hardware costs (and requirements) are manageable (even HA)
- You are independent from downtimes and disturbances of another application
- you can flexibly schedule SLD downtimes
- You do not have to keep the SLD release status in sync with an application
There must be order – structure of multiple SLD instances
The structure of an „SLD landscape“ is characterized by various considerations. For example, there is a recommendation to decouple an existing design time (e.g. for NWDI) SLD-side from the runtime (for production, then on the SolMan) for non-PI landscapes. This way the non-productive development SLD does not influence the productive processes.
The two directories are then synchronized at design time using automatic forwarding.
If a PI exists, the Data Suppliers must all report to a PI Runtime SLD, since the PI must always read current and complete landscape information. SolMan SLD and DesignTime SLD are then supplied with current data by the runtime „backwards via forwarding“. If, on a case-by-case basis, new objects occur in the two receivers, these are manually brought into the Runtime SLD.
SLD planning therefore involves one or two deeper considerations. Coordinating with your customers (keyword DSAG and other customer associations) and, of course, with the relevant departments / developers can provide you with valuable impulses.
This applies both to the current situation and to looking into the future – be prepared for the (foreseeable) future.
The obligatory
This documentation is a collection of empirical values, and has not been tested or released in any form by the product manufacturers (SAP, Oracle, ..). No liability can be assumed for damages resulting from (partial or complete) following of this documentation.
Of course I am happy about questions, comments or additions.
