Skip to Content

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.

.

SLD-LMDB_Sync_Default.PNG

Figure 1: 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.

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:

More_than_1_SLD_connected_to_1_LMDB.png

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.

1_SLD_synced_to_more_than_one_LMDB.png

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.

1_SLD_synced_to_1_LMDB_Import-Export.png

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:

 

Info on Data in SLD and LMDB

Info on the Upload and Use of Data from SLD and LMDB in the SAP Support Portal

.

.

.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Shawn Grant

    Hi Wolf,

    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.

    Thanks,

    Shawn

    (0) 
    1. Wolf Hengevoss Post author

      Dear Shawn,

       

      Not having a complete picture, I understand your setup as follows: 

      • SLD (DEV/QA) connected to LMDB (DEV/QA) and LMDB (PRD)
      • SLD (PRD) connected to LMDB (DEV/QA) and LMDB (PRD)

      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,

      Best Regards,

      Wolf Hengevoss

      SAP AG

      (0) 
      1. durga gidugu

        Hi Wolf,

        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.

        (0) 
        1. Wolf Hengevoss Post author

          Dear Durga Gidugu

          These are my thoughts:

          1. If you are using DEV/QA/PRD SLD system, you cannot use full automatic content sync – this mechanism would immediately transport all changes so that there would be no difference between the connected SLDs as you already assume – only using exports you will have the control over the change process (see SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?)
          2. You’re right, data of the same system/SCV/etc. may not go into one (e.g. the central) SLD via 2 different paths.
            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.)

          Best Regards,

          Wolf Hengevoss

          SAP SE

          (1) 

Leave a Reply