How-To Handle Landscape Data as a Value-Added Reseller Using LMDB

Introduction

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?). ¹⁾

¹⁾ 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.

Uploading AS ABAP Based Technical Systems’ Data While Having Connection Problems

What should I do in case of problems with the connections described above? These could be

• Security policies in my organization prevent me from creating RFC connections to SAP Support Portal
• Problems in permissions or authentication

In such a case the technical system information for ABAP systems will be uploaded by generating a system_info.xml file from Support Package Manager (SPAM).
Prerequisite: This is supported on SPAM version 59 or latest. Please check and upgrade SPAM version to 59 before you proceed.Perform the following steps:

1.   In transaction SPAM, select Utilities -> Generate system info XML.
   Logging in to client “000” may be required
2.   Save the downloaded XML on your local system
3.   The system_info.xml file can be uploaded to the customer profile by choosing
   “Add  System” in the Explore Systems area.

NOTE:
This works for AS ABAP based systems only.
It should be regarded being a work-around: Data uploaded this way will not be updated automatically, so uploading data via the LMDB is highly recommend.

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:

• SLD Topology: How-To Gather and Distribute SLD-Data in Your IT-Landscape?
• SLD-LMDB Topology – Connections, Valid, and Invalid Data Exchange Between SLD and LMDB of SAP Solution Manager

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  http://sappartneredge.com/pcoe > 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

Recommendation

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.

Recommendation

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.

Recommendation

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.

Recommendation

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 2^nd 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.

• SLD-LMDB Topology – Connections, Valid, and Invalid Data Exchange Between SLD and LMDB of SAP Solution Manager
• SLD and LMDB Topology: Replacing the Source SLD for the LMDB
• To keep SLD content available for SAP Solution Manager during SLD maintenance, you can switch between different SLDs that are in sync. For more information, see Switching between 2 SLD Systems in Sync with an LMDB or a 3rd SLD.

…

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

• Migration of technical system data from SMSY into the LMDB:CAUTION: Migration must be used with care: If possible, avoid migrating data from SMSY.Migration is another option for those systems where a technical system really exists (i.e. a product instance is marked as “relevant”) and where the technical system has an installation number, a message server, a database, a database server, and a database manufacturer (for details refer to http://help.sap.com/saphelp_sm71_sp08/helpdata/en/45/51fbdbd4941803e10000000a1553f7/frameset.htm > Migrate System Information from SMSY to LMDB
  
• Do not download data from SMSY via RFC: Instead use SLD (also compare “How to avoid “Data Separation” in SMSY on solman SP08“)

Security

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.

.

.

.