Value-Added Resellers (VARs) are working with SAP’s customers providing services at several levels varying from incident management to offering system maintenance. VARs therefore need to handle landscape data of multiple customers.

To gather the correct landscape data, the following questions need to be answered:

  • What data sources are available for which kind of landscape data?
  • Which kind of landscape data is required for each scenario?
  • What are the best practices for setting up landscape data management?

Background information about LMDB and SMSY

There are different landscape entities in the system landscape; the following are mentioned in this document (for details, see Landscape Descriptions / White Paper: SAP Solution Landscape):

  • The technical system (SAP NetWeaver AS ABAP,AS  Java, …)
  • The product system, which groups one or more technical systems according to the installed software. (Very often, a product system only
    contains one ABAP technical system.)
  • The logical component which groups product systems according to installed software and business need.

In Solution Manager 7.1, SAP has introduced the Landscape Management Database (LMDB) as editor and store for landscape data, which works very closely with the System Landscape Directory (SLD). With Solution Manager 7.1 SPS10, SMSY is reduced to a read-only store for landscape data (see Evolution of Landscape Data Management – Part II: What’s better with LMDB in SAP Solution Manager 7.1, SPS10?). 1)

1) As one of the differences between LMDB and SMSY for ABAP systems: SMSY does not differentiate between the technical and the product system – you will see both aspects in the same UI. In SMSY, a technical system of type ABAP exists only as product instance which has been marked as “relevant”, while in LMDB you clearly select either the technical system or the product

The function of the LANDSCAPE FETCH batch job has been reduced (SAP note 1802717) and the former SMSY RFC data provider for AS ABAP has been replaced by the SLD data supplier in AS ABAP (RZ70). This change typically implies the use of SLD at VAR side, which is on one side tangible effort, but enables on the other side the automation of landscape management beyond SAP NetWeaver AS ABAP.

Figure 1 shows the origin and use of landscape data. Installation of SAP software on hardware creates technical systems. Technical systems register their data in the System Landscape Directory (SLD), which hands over all its technical system data to SAP Solution Manager LMDB, where landscape data for projects (such as Change Request Management (ChaRM)), software maintenance (product systems), and system monitoring (technical scenarios) are created:


Figure 1: The flow of landscape data – data source, tools, and use of landscape data. Technical systems write their data into the SLD; data is automatically synced into the LMDB (and SMSY) and provided for maintenance, monitoring and project management .This can be done via a central SLD or a local SLD in SAP Solution Manager 7.1. Note, that only 1 SLD should be connected to the LMDB (also see section SLD and LMDB Topology on valid and invalid connections between SLD and LMDB).

Data Handling

Processes described here are mostly of a generic kind, important for all parties dealing with landscape data – these are given by references to blogs in the SCN or other documentation – you’ll find the links provided. Those, which are specific for you as a VAR are explained in this document.

Getting Data

In principle, ways of getting technical systems’ data can be differentiated as follows:

  • Automatic data retrieval – this is recommended compared to manual data creation:
    • Technical systems’ data sent from the systems’
    • Download of data from the SAP Support Backbone
  • Manual data creation:
    • Manual creation of technical systems data in the LMDB:
      This is a lot of effort, and data will get out-of-date soon in case of a systemupdate

Note: Higher level landscape data such as product systems, logical components and technical scenarios need to be defined manually in the LMDB.

Figure 2 shows landscape items, tools and sources of information VARs have to deal with – here SAP Solution Manager 7.1 is shown – including the ways to get landscape data. In the VAR’s SAP Solution Manager, data is synced into the LMDB. Landscape data such as product systems is created manually if needed. Consuming applications using LMDB data are shown:


Figure 2: The VAR landscape – customers owning landscapes send to the VAR via their own or the VAR’s SLD.

As you can see, in this picture the automatic delivery of data is shown:

  • Data stems from the SLD
    • The SLD is either available at the customer or
    • Customer’s technical systems’ data suppliers target an SLD provided by the VAR
  • Or data is retrieved from theSAP Support Backbone

Therefore, you need to deal with data written into the same SLD/LMDB from other SLD or the SAP Support Backbone in the end from different landscape: Check the recommendations to guarantee uniqueness of data at the end of this document.

General Recommendation

In the recommended process, technical systems’ data are registered in the SLD and synced into LMDB. In the LMDB, landscape data such as product systems, logical components, and technical scenarios are created manually.

So keep in mind:

  • Technical systems’ data should come from the System Landscape Directory (SLD) and product systems should be
    created in the Landscape Management Database (LMDB) based on SLD data
  • Support Backbone data should be fetched regularly to keep data up-to-date.

SLD and LMDB Topology

As shown in figure 1, especially you as a VAR can face the need to deal with a complex topology of SLD and LMDB systems – some customers may have SLD systems of their own, others don’t, you may have more than one Solution Manager System, etc. Two blogs describe the principles that help you find a valid topology:

The SLD at VAR site in figure 2 is either filled directly by SLD data suppliers or indirectly by an SLD at customer site forwarding data supplier packages (SLD bridge forwarding). Both is done via the Internet, and therefore needing enhanced topology considerations.
For direct access by the AS ABAP data supplier (RZ70), using a saprouter in your DMZ is recommended (SAP note 1669729). For direct access by all other data suppliers and SLD bridge forwarding, using a Web dispatcher in your DMZ is recommended.

Not using SLD data suppliers as main data source for technical systems typically does not work in practice. A completely manual system creation can be considered as alternative if Incident Management is the only supported scenario. This is described in detail in the next chapter.

Scenarios and Required Data

This description takes into account (only) those VAR setups that make use of SAP Solution Manager including the LMDB. We focus on SAP Solution Manager 7.1. You will find a description, which landscape data is required depending on the use case and services provided – you can spare the effort to handle or create data in the LMDB that you do not need but must avoid the error to work on incomplete or wrong data.

For the required VAR scenarios there are some prerequisites regarding landscape data that need to be fulfilled. For example: Incident Management needs License data in LMDB and IBase entry.

We’ll discuss the following scenarios here, which are available for use by VARs (see > How to set up a PCoE):

  • Solution Documentation – Technical Landscape Documentation (SMSY > LMDB)
  • Incident Management
  • License Management
  • Early Watch Alert (EWA)
  • Maintenance Management using Maintenance Optimizer (MOpz)

In the section following the description of the scenarios, you will be learn in detail about how and where to get the required data.

Prerequisites of SAP Solution Manager Scenarios in 7.1

In this section we describe the landscape data prerequisite for each of the scenarios, which are available for use by VARs. Details on how to get the data is described in the next section.

See figure 3:


Figure 3 – SAP Solution Manager Scenarios in 7.1, SPS05+ without using an SLD: CRM Service – IBase Master Data. You use this source of
information to load master data for installed bases and installed base components.

Incident Management:

Data Required

Incident requires only basic system data. Knowing the existence, respectively the SID, client (AS ABAP), system- and installation number is sufficient.

Data Source

Incident Management stores this data in an iBase iObject. These iObjects are usually created from technical systems in the LMDB. However, as license data from SAP Support Backbone is sufficient to create these iObjects, too this scenario also works without technical systems in LMDB.

Data is retrieved from SAP Support Backbone.

  • License data in LMDB: It is sufficient to download the license data from SAP Support Backbone via REFRESH_ADMIN_DATA_FROM_SUPPORT
  • IBase entry: Automaticallyprovided; IObjects are created in the Solution Manager. After the license data has been downloaded into LMDB, the IObjects are created automatically in theIBase


For operating an Incident Management scenario there is no disadvantage in just using system data from SAP Support Backbone. An SLD can be considered as optional.

You can create the technical system and product system from license data using the license data UI. (> use transaction LMDB > technical system > Downloaded License Data from SAP Support Portal)

License Management

Data Required

License Management receives license and maintenance certificate information from managed systems on a regular basis. For systems based on AS ABAP, this data is retrieved via RFC.  In order to create the required RFC-destination during the managed system setup the message server host (including routing path), the instance number and the target client are required. In addition product version and instance(s) installed on the systems must be known. 

Data Source

The system data mentioned above gets defined during the installation process or during the SAP Router configuration.  All system data is supplied by the SLD data supplier of technical system automatically and sent to LMDB via the full automatic sync (see section “SLD and LMDB Topology”).
If a routing path is needed to access the managed system, this cannot be determined automatically and therefore has to be maintained manually in the
LMDB host editor (as previously done in SMSY).

If no SLD infrastructure is present, technical systems can be created semi-automatically by completing system data from SAP Support Backbone.  Figure 3 shows license data downloaded from LMDB. To create a system, select one entry and click Create System Description – see figure 4:


Figure 4: Create System Description from license data in the LMDB.


Using an SLD infrastructure is recommended. This can mean to set it up in case that you do not have it. It may even be simpler and mean less effort to set up the SLD infrastructure than to maintain all required data manually.

Early Watch Alert

Data Required

As in license management, SAP Solution Manager fetches Early Watch Alerts from managed systems via RFC. Therefore, the same discussion
applies. Additionally Early Watch Alerts are scheduled for production systems only. Production systems are grouped in the default SAP Solution (if they are
not yet in another solution).  Production systems are determined based on the systems role in the logical component used to assign a system to its solution.

Data Source

With respect to technical system data, the same discussion as for license management applies. Creating logical components and product systems, respectively assignment to solutions always happens in SAP Solution Manager. There are no different requirements for VAR compared to all other use cases.


Using an SLD infrastructure is recommended. This can mean to set it up in case that you do not have it. It may even be simpler and mean less effort to set up the SLD infrastructure than to maintain all required data manually.

If you already have used the EWA in 7.01, after upgrade you may have some “old systems” in SMSY. For the “old” system in the SMSY we advise you to create the technical systems and product systems from the license data, which is downloaded from SAP Service Marketplace. The UI will propose a database server and name for the system (based on the data received from SMP). You can change and correct these entries according to your needs (e.g. the Extended-SID).

Maintenance Using Maintenance Optimizer (MOpz)

Data Required

In order to correctly calculate correct system changes (download basket), maintenance optimizer (MOpz) requires a complete description of all installed software, i.e. product version(s), product instance(s), software components and support packages as well as kernel information. Further dependencies between technical systems should be described in product systems.

Data Source

Installed software information originates from installation/upgrade processes and is stored directly in the system. SLD Data supplier sent this information to SLD/LMDB automatically. Product systems are created in SAP Solution Manager using the LMDB product system editor.  The product system creation is supported by integrated verification checks executed in the SAP Support Backbone.


Maintaining detailed information about installed software is considered impracticable, especially for a large amount of systems. Using SLD data suppliers to provide this data is highly recommended.

Best Practices

Uniqueness of Landscape Data

Here, we can differentiate between two cases:

  • Uniqueness of data of several customers
  • Uniqueness and unambiguity of data of each customer

Uniqueness of Landscape Data of all Customers – Across Landscapes

As discussed in the topology blogs, especially when combining data of several independent landscapes, special attention needs to be paid to the uniqueness of landscape data.

To be able to differentiate between technical systems, the SLD takes into account the SID and the DB Host and the system type (AS ABAP, AS
Java, etc.). Usually, this is sufficient, because you cannot in one landscape a 2nd system having all three parameters set identically with an existing one.

Its also important to know, how to connect the right SLD, can I change SLDs in between?

The SLD connection in SAP Solution Manager is set up in TA SOLMAN_SETUP -> System Preparation -> Prepare Landscape Description -> Select SLD and Set Up LMDB.

Connecting several SLDs to one SAP Solution Manager LMDB is not recommended. If you need to do so, you MUST make sure that any piece of information gets to the LMDB only via one SLD. Data on two or more SLDs must not overlap.

To ensure consistent CR content, you can only select one SLD as a CR source. For all other data (SIDs of tech. systems, business systems, host names, servers, etc.) you MUST install processes to fully separate the names (by naming conventions) and the data flow (by complete separation of SLD systems) to keep the unique-path-principle for data.

So, technical systems’ data from different customers may clash (see SAP Note 1052122). In case of clashing SIDs and host names, the result in the SLD is a merged system description with no value. The recommended way to avoid this is an organizational agreement with all customers about separation of host names, for example by customer individual prefixes.

Uniqueness of Landscape Data of all Customers – in the Landscape

By changes to the landscape, duplicate data can occur also in an SLD that only gets data from one landscape, because the SLD only adds data and does not delete them automatically.

The following blogs describes how to deal with duplicates:

Handling duplicates in the SLD:

How-to Manage House-Cleaning in the System Landscape Directory – Duplicate System Entries.

Another case can occur after a Dual-Stack split:

Dual-Stack Split – How to Ensure Correct Technical System Data in SLD and LMDB after the Split 

Also, some manual work may be required in the LMDB:

How to Ensure Your Landscape Data is Up-to-Data – House-Keeping in the LMDB.

Export / Import of Data

Note the following:

[…], you could supplement the bridge forwarding of Data Supplier data with regular export/import of manually entered data from SLD A to SLD B. Attention: Using export/import for automatically delivered data can lead to problems if the data is read by the LMDB, so DO NOT use export for technical systems data sent via a data supplier. For more information again see SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?

The reason for this recommendation is that the export is not complete, especially information about installed product instances is missing. If you need to use the data with MOpz, add the product instance information manually in the LMDB.

To be Avoided


Security is an important topic, especially, if connections are used to exchange information with parties outside the company. See figure 5 for an explanation of connections and their types:


Figure 5: Security settings for SLD connections.

Additional Information

You’ll find the blog series and links to landscape entities and tools dealing with them on a dedicated page called Landscape Descriptions at the SDN.




To report this post you need to login first.


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

  1. Massimiliano De Mola

    Hi Wolf Hengevoss,

    as VAR partner, we have to configure customer systems on our VAR Solution Manager (Release 7.1 SP 8).

    First of all, centralized SLD in VAR Solman is provided. All customer systems will send data to VAR SLD.

    Therefore I should setup remote connection beetween VAR solman and customer site as suggested in your blog post to send data from SLD suppliers: we have setup an internet connection beetween customer saprouter in DMZ and VAR saprouter in DMZ to send data from abap system to SLD; we have a web dispatcher in DMZ at VAR site to receive data from customer java systems data suppliers.

    Then I should follow all steps in transaction solman_setup – ‘Manage system configuration’ in VAR Solution manager to configure customer systems.

    I have to connect java and BO systems at customer site.I’m afraid that connection from VAR Solution manager and single Java system is necessary, else i am not able to connect solman to introscope EM.

    In fact http connection to load balancer host of managed system is required.

    Therefore i should ask to our customers to setup a remote connection beetween single system at customer site and VAR solution manager.

    It’s correct?

    Kind regards,


    1. Wolf Hengevoss Post author

      Dear Massimiliano,

      Thanks for your Feedback. Regrettably, this is not an answer that can be answered by settings in LMDB or SLD, because it depends on the application used for diagnostics. I propose to address it in that area.

      Best Regards,

      Wolf Hengevoss

      SAP SE

  2. Uwe Helms


    Found this good article through a SAP Call 🙂

    we plan to set up a new SM 71 as an Upgrade don’t clear the old garbage of the last Years (Old Server, not longer needed Logical components, …). Also a Process redesign is part of this Project.  It is planned to build up the new SM Landscape in Parallel with the same SID’s. Then we want switch the processes from old to the new one.

    But for a limit Time both Landscapes will run in Parallel and will use the same SLD and the same TMS (But 2 Domains).

    Is this Possible or will we run into serious problems by running two SM with same SID’s in one System landscape?

    Kind Regards

    Uwe Helms

    T-Systems International GmbH

    1. Wolf Hengevoss Post author

      Dear Mr. Helms,

      thansks fpor your feedback! – regarding your interesting question I got the following impression in discussions – please check, if they may help you:

      From an SLD/LMDB point of view 1 SLD sending data to 2 SAP Solution Manager systems are not a problem; 2 SAP Solution Manager systems with the same SID are not a problem in the SLD if the host is different. In LMDB (and SMSY) systems with identical SID will be separated by the ExtSID (SID00001, for example). But there are some applications not using the ExtSID, and I think CTS is one of them – this could probably be solved if ExtSID = SID for the SAP Solution Manager systems, e.g:

      ExtSIDs in SAP Solution Manager1:

      Solman1 = SMP

      Solman2 = SMP00001 (or other extension)

      ExtSIDs im SAP Solution Manager2:

      Solman1= SMP00001 (or other extension)

      Solman2= SMP


      From a Maintenance Planner point of view, we just introduced, (as consuming landscape data uploaded to the SMP) supply it’s sufficient – we implemented the active/inactive switch in case more than one SAP Solution Manager is uploading data.

      Related blog posts:

      Topology of SLD, LMDB, and Customer Profile – How to Get Reliable Landscape Data in SAP Support Portal as a Basis for Planning


      SLD-LMDB Topology – Connections, Valid, and Invalid Data Exchange Between SLD and LMDB of SAP Solution Manager

      I hope that helps.

      Best Regards,

      W. Hengevoss

      SAP SE

      1. Uwe Helms


        thank you for the Hints.

        The CTS I think is in our case not an main Issue because during the Parallel run Time we want to create 2 Transport Domains for ChaRM and other Projects with only running on the New Solman. The System from the “Old” should follow later Line by Line. Because of this we should not have two Systems with same SID in the new LMDB.

        But I’m not 100% sure about the SLD Sync. The Plan is 2 SLD. PRD and DEV.

        All Systems should be connected to the PRD SLD except Sandbox Systems. All Sandbox Systems should be connected to the DEV SLD for Testing. If I understand it right the Complete Sync (Unidirect) overwrites all Existing Data? Or would only new Data put additional to the Target SLD.

        Thank you in advance

          Uwe Helms

          T-Systems International GmbH

  3. Ning Tong

    Hello Wolf,

    Thanks a lot for your detailed explaination about landscape data for VAR.

    I have a question:

    If customer do not have a SLD, can we finished the above 5 scenarios by using the following SAProuter path (DAA is registered in the VAR SLD, does RFC working in the following path):

    customer system -> customer SAProuter -> VAR SAProuter -> VAR SLD?




Leave a Reply