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:
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.
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:
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.
If there are SLD client apps in use, a topology as described in the following will be required.
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.
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.
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.
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.
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.
You can still use the local SLD of SAP Solution Manager in the following scenarios:
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.
.
.
.
Introduction
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.
Synchronization Principles
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.
Topology
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.
Other Content
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.
Further Information
Security Aspects
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 Port...
- Uploading, Accessing, and Trouble-Shooting System Data in the Customer Profile Used for Planning Cha...
.
.
.
- SAP Managed Tags:
8 Comments
