SLD-LMDB Topology – Connections, Valid, and Invalid Data Exchange Between SLD and LMDB of SAP Solution Manager
Last update: 29th of July 2019
Landscape data and landscape descriptions are the basis for business processes and ALM processes alike.Landscape data is gathered by the SLD and retrieved by the LMDB as a basis of the landscape descriptions in the SAP Solution Manager 7.1. So the LMDB will not work without an SLD – even the software catalog and CIM model /CIM / CR Content) are read from the SLD. There are some updates to topology-recommendations if you use the LMDB. This blog gives an overview of what to take care of when connecting SLD and LMDB. The following scenarios will be discussed in some detail:
- Synchronization between SLD and LMDB in General
- Connecting SLD & LMDB – using more than 1 SLD connected to 1 LMDB
- Connecting SLD & LMDB – using 1 SLD for more than 1 LMDB
- SLD & LMDB – avoid using single export/import of automatically created data
- Using the Local SLD of SAP Solution Manager 7.1
- It also in the Further Information section at the end links to
- SAP Process Integration specific info
- Info on the use of SLD/LMDB data in the Customer Profile – mainly for Maintenance Planner
Synchronization Between SLD and LMDB
Synchronization Between SLD & LMDB
In the case of the LMDB we have to duplicate data from the SLD to be able to change them in the SAP Solution Manager. The connection between LMDB and SLD works as follows: The LMDB retrieves all data from the SLD by Full Automatic Synchronization (FAS – also called Content Sync in the LMDB) so that all data of the SLD are sent to LMDB immediately. This comprises CIM/CR Data also, which can only be loaded from an SLD and technical systems’ data sent via a Data Supplier, which cannot be targeted at the LMDB directly.
Figure 1a: Default scenario and data sent: All systems report to 1 central SLD, where additional information is entered manually or imported from other SLDs.
All central SLD’s data is synced into the LMDB including CIM Model and CR Content. Landscape data such as product systems are created in the LMDB based on technical systems’ data.
Whenever there is a synchronization of data, it is best practice to have them stored once – a single-source-of-truth approach. If you need to duplicate data and send it from one storage place to another, make sure that they follow one defined path so that the same data does reach a new storage from two sides in parallel – the unique-path-principle. In the following parts you’ll learn how to apply this to divers topologies of SLD & LMDB.
New Option for Landscapes without SLD Client Applications
To describe the simplest scenario first, – which is not the most important or most often used -, with SAP Solution Manager 7.2 SPS09, in case no SLD client applications are used /such as SAP PI, or NWDI) – using an SLD becomes optional:
- You can still use it as a target for SLD Data Suppliers and as a CIM/CR source for the LMDB
- You can use the LMDB as a Data Supplier Target combining it with the new CIM/CR import to the LMDB
The following figure shows both options:
Figure 1b: SLD/LMDB topology options as of SAP Solution Manager 7.2 SPS09 – no SLD client apps.
In case, no SLD is available in the landscape, the LMDB needs to be updated with manual or automatic import of CIM/CR content to be configured in SAP Solution Manager transaction SolMan_Setup. For details see How to Reduce Manual Effort in CIM model and CR Content Update of SLD Systems.
Landscape with SLD Client Applications
If there are SLD client apps in use, a topology as described in the following will be required.
SLD and LMDB – Using More than 1 SLD Connected to 1 LMDB
For several reasons, in most IT-landscapes more than one SLD is available, to improve availability of SLD data, separate applications or system states (DEV/QA/PRD) from each other, etc. To be able to handle scenarios, where data is distributed over several SLD systems that shall not be connected (for example in a hoster scenario with separate customers), LMDB can have content sync connections to more than one SLD system. Even if this is not recommended in the default landscape, if you have to use this option, you need be aware of how to do it.
This leads to point where you need to plan your SLD-LMDB topology wisely, so that the unique-path-principle is not be violated. Two types of data need to
be discussed: CIM/CR Content and all the other data, which are mainly technical systems, business systems, manually created products and software components.
CIM Model and CR Content
You have CIM and CR Content in every SLD. This would lead to problems. Therefore a in the setup of LMDB content synchronization you’ll find a filter only accept CR Content from one SLD only.
SLD systems connected to the same LMDB must not contain the same technical systems or business systems. The reason is, that changes of data (e.g. of a technical system’s after an upgrade) might reach both source SLDs in the wrong sequence, leading to a wrong sequence in the update of LMDB.
For business systems the same rule applies. More than that, you need to take care that Business Systems’ names are unique in your landscape: If you are using one PI landscape this will be handled automatically, if you have several and combine their data in one SLD or LMDB, identical names will clash, overwriting existing data with newly sent data.
Valid and Invalid Topologies of SLD Systems with Content Sync Connection to the Same LMDB
In principle, even if this is not recommended as a default, one LMDB can read data from more than one SLD system:
Figure 2: Schemes of more than one SLD in sync with LMDB following and violating the unique-path-principle: Note that SLD systems MUST NOT exchange data when both have a content sync connection to the same LMDB.
Also see Planning Guide – System Landscape Directory -> Synchronization of one LMDB with more than one SLD System.
Connecting SLD & LMDB – Using 1 SLD for more than 1 LMDB
Using the SLD-LMDB connection the other way round is much simpler: In case you have more than one LMDB (for example an SAP Solution Manager QA and PRD system or separated SAP Solution Manager systems for different parts of your company), that shall get data from the same SLD, simply create connections from both LMDB systems to the same SLD.
Figure 3: Valid schemes of one SLD in sync with LMDB. Note that SLD read by the LMDB may exchange data other SLD systems and distribute its information to more than one LMDB.
SLD & LMDB – Avoid Using Single System Export/Import of Automatically Created Data
While there is – usually – only one LMDB in most landscapes, there often are several SLD systems, used in DEV/QA/PRD environment, SLD systems dedicated to one big SAP NetWeaver Portal system, etc.
In this case it is necessary and recommended using manual export and import of data. But as soon as the data is needed in the LMDB, use this
export/import function only for manually created data, such as business systems for SAP NetWeaver Process Integration. Note that manually create data is not as complete as Data Supplier data: Use Data Suppliers whenever possible. Otherwise you might need to add data in the LMDB manually too; manually added data of course will not be automatically updated.
Do not export/import automatically delivered data; most importantly these are technical systems’ data sent via Data Supplier. When exported and imported, some details are missing that are not needed by an SLD’s client applications (such as Process Integration) but which are required by the LMDB. It is possible to use a delta export of LD data instead. Using the export/import of LD data (a full export first, delta exports later) works well for automatically delivered data.
Figure 4: Valid and invalid schemes of one SLD in content sync with LMDB: Note that the SLD read by the LMDB can
exchange data other SLD systems but MUST NOT get import automatically data from other SLD systems.
So simply follow the default recommendation using bridge forwarding for all technical systems’ data and transport manually created data as needed. For details, see SAP Note 1805109.
Using the Local SLD of SAP Solution Manager 7.1 as Source for the LMDB
You can still use the local SLD of SAP Solution Manager in the following scenarios:
- There is no use of SLD data by application other than those of the SAP Solution Manager.
You do not use SAP NetWeaver Process Integration (PI) or SAP NetWeaver Portal for example. In that case, data suppliers can address the local SLD of SAP Solution Manager 7.1 and LMDB can read this SLD.
- You use the local SLD as a CR Content Source only.
This can be helpful, if you are using for example a central SLD associated to or running with SAP NetWeaver Process Integration and are not willing to do the CR Content Updates in that SLD as required by the LMDB.
Note that the LMDB reads all data from the SLD including manually created data. This is needed for example for business systems of SAP NetWeaver Process Integration, which are needed for PI Monitoring. It is therefore necessary transporting such information by export/import: The local SLD of SAP Solution Manager 7.1 is running on SAP NetWeaver 7.0; it therefore cannot be the target of a full automatic content synchronization.
Also, there shall not be run-time dependencies from productive applications. Because of this if PI is used the local SLD of SAP Solution Manager 7.1 shall not be used as the central one.
Upload of data to SAP Support Portal and processing in the Support Backbone, was part of the process with SAP Solution Manager Maintenance Planner already. Therefore, a solution has been described already in SAP Note 1781148 – LMDB and SLD in a high-security environment. It tells you, how to run two SAP Solution Manager systems in a high-security environment.
The note tells you that “[…] Depending on SAP Solution Manager usage, you may have to create the product systems in both [SAP Solution Manager systems][…]. With the Maintenance Planner if only the technical system data is needed, you can create product maintenance dependencies instead in case you do not need product systems in the SAP Solution Manager System uploading to the SAP Support Portal.
Process Integration – PI Monitoring
If you are using SAP Process Integration (PI), data from the SLD is required. Usually, this is sent by an SLD containing PI data by full automatic sync. More information is available in SAP Notes:
- SAP Note 1631346 – SAP Solution Manager 7.1 and 7.2: SLD configuration for PI monitoring
- Now, there is an additional way available described in SAP Note 1816997 – Setting Up Process Integration Monitoring in Solution Manager 7.2 SPS01. Note that SAP Solution Manager 7.2 is currently in ramp-up. It therefore only applies to ramp-up customers and those getting this version when and if it is made available after a successful ramp-up.
Info on Data in SLD and LMDB
- SLD topology, see section SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?
- For mechanisms to exchange data between SLD Systems, see blog post SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?
- How to Reduce Manual Effort in CIM model and CR Content Update of SLD Systems
- Landscape data in general: Landscape Descriptions (http://scn.sap.com/docs/DOC-8935)
- SAP Note 1781148 – LMDB and SLD in a high-security environment
Info on the Upload and Use of Data from SLD and LMDB in the SAP Support Portal
- Topology of SLD, LMDB, and Customer Profile – How to Get Reliable Landscape Data in SAP Support Portal as a Basis for Planning
- Uploading, Accessing, and Trouble-Shooting System Data in the Customer Profile Used for Planning Changes in Your IT Landscape
Very Very informative document!!
Thank you for the information. We're in the process of defining our SLD topology and want to get it set up correctlty now to avoid issues down the road. Without going in to too much detail about our system landscape, is it possible to have two LMBD connect to two SLD?
From the section above Using More than 1 SLD Connected to 1 LMDB we are wondering if we can (1) connect our development/qa Solution Manager to our non-prod SLD and our production SLD? and (2) connect our production Solution Manager to our non-prod SLD and our production SLD? The two SLD would never sync/share data.
Not having a complete picture, I understand your setup as follows:
If there is no overlap in SLD data (apart from CR content, which is used from one SLD only if an LMDB has more than one SLD connected), you can use multiple SLD systems
as source for the LMDB. I recommend using such a setup only if absolutely necessary, since switching technical systems data suppliers to a different SLD might cause problems… I usually recommend keeping things as simple as possible. One way to achieve a simpler picture, you could forward information between SLD systems and connect just one SLD to each LMDB.
Please make sure to follow all requirements in the blog SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape? as well…
I hope that helps,
Very informative blog. But I still have a question when we have 3 individual PI local SLD's running on DEV/QA/PRD and 1 LMDB in the landscape. Also planning to setup one central SLD.
*All these 3 SLD's talk to each other and exchange data - for example if we have to create transport group for source and target business systems we will have to export/import the systems into each other SLD's.
1) Is it fine if we Export LD data of DEV, QA and Import into PI PRD SLD and then do a full content synch with central SLD and further to LMDB. But the questions is - it will also bring unwanted SCV's of some development stuff into production? Alternatively doing Bridge forward will not totally bring PI associations which is again another issue.
2) Or can I connect individual SLD's directly to central SLD using uni direct content sync and from there further to LMDB. I'm not sure about this though it is technically possible , SAP states about the unique path principle. In this case, all 3 SLD's will be exchange data with other which is violation right?
Any input is highly appreciated.
Dear Durga Gidugu
These are my thoughts:
Especially, merging two or more source SLDs into a target SLD via full automatic sync is not a supported scenario because the unique path principle cannot be fulfilled for SAP CR content. (The sync with more than 1 SLD into the LMDB is possible, because the LMDB filters the CR Content using only one SLD as CR source – this feature is not available in the SLD.)
Thanks, very good knowledge base document great additions guys
Brahama J. Kroma
Question! We and isue where a system is getting overwritten in SLD after system copy.
Source and target has same SID but all hostnames has been changed on target
Source is a HANA ERP system with a windows Central instance.
Target is a Cluster solution with a virtuel server in front of 2 HANA DB instance and 2 Linux SCS/EQ instances with 4 linux application servers.
"Problem is that the teknical system in SLD is overwritten so insted of getting two teknical systems we get what looks like a mix of the two systems (the application servers are kept both when we publish target and source.
What could be the solution to this (I did look for notes ut with out luck)
thanks a lot 😉 - as for your question, please have a look at "How to Deal with Landscape Data Created during System Copy".
(This, btw., has now been made available in a newly designed SLD page at the SAP Support Portal)
Should that not help, please open an incident.
Hope that helps!