Skip to Content

Introduction

Products and Product Instance are used to describe software that SAP delivers. It’s also these elements that you need to understand to maintain your systems. In the 2nd part of this blog on landscape descriptions, we talked about these entities in some detail, showing that there is a certain level of complexity to handle. To keep your landscape description in a good condition, you need to maintain these data. This also includes manual steps and requires technical knowledge.

Installing the entities of Products on the hardware creates Technical Systems, which you have to address, so you need to make sure they are listed correctly in your landscape description. To handle Technical Systems taking into account their role in your business processes requires the definition of Product Systems. Here are the steps…

Handling Products and Their Elements

The overall process comprises the following tools and steps:

tools_&_steps_in_landscape_data_mgmt.png

Figure 1: Processes, landscape data, and tools in landscape data management in the application life-cycle

Data Flow of Landscape Data – Data Sources and Tools Involved

This shall give you an overview of the state in SAP Solution Manager 7.1 SP4.

  • Installation tools add Technical Systems to your landscape.
  • Technical Systems’ data is gathered in the System Landscape Directory (SLD) and handed over to different “client applications”:
    • The SLD allows registration of Technical Systems via their Data Supplier.
      • For newer releases this data already contains the Product, Product Version, and Product Instances installed.
      • For older releases, the data on Product, Product Version, and Product Instances needs to be added to the Technical System in the LMDB.
    • The SLD provides system data to applications in the landscape requiring system data such as Web Dynpro for Java, Process Integration, and NWDI need system information and read this from the SLD directly. To make this info available in other SLD (for example in the development area), the system data from the central SLD is replicated by forwarding into other SLD systems (for details see the blog on SLD Topology).
    • The SLD provides system data for the SAP Solution Manager, which reads system data from the (central) SLD is read and enhanced or aggregated into landscape data (such as Product Systems, Technical Scenarios) in the SAP Solution Manager.
  • The Landscape Management Database (LMDB) is connected to an SLD (preferably just one SLD, and in that case, usually the central SLD in the productive area of your landscape) in your landscape acting as a single source of truth for system data in SAP Solution Manager:
    • Reading the SLD by full automatic synchronization
    • Enhancing Technical Systems’ data where required (including manual creation of new Technical Systems, where – currently – not Data Supplier is available)
    • Providing client application in the SAP Solution Manager (such as the SMSY and Monitoring) with system data.
  • Based on the Technical System, in SAP Solution Manager the following is done:
    • Define Product Systems for the Maintenance Optimizer (MOpz) and Logical Components in transaction SMSY – required Technical Systems’ data is synced from the LMDB automatically (replacing this part of the landscape fetch job, which retrieved the data from SPA Solution Manager’s local SLD in release 7.0)
    • Define Technical Scenarios for Monitoring Applications in the LMDB.
  • Use Product Systems and Technical Scenarios in maintenance and monitoring. Changes in the Technical Systems are updated automatically by their data suppliers (where this is not available, it needs to be done manually.)

Check List on Landscape Data Management

To run software products install the software on hardware (we’ll come the hardware later) – this leads to creation of Technical Systems. This created the landscape you need to describe correctly, to be able to keep it up-to-date and in good shape.

You can see figure 1 as a big picture of check list. This is the explanation of the steps, their purpose, and prerequisites:

  1. To be able to address the Technical Systems, you need to have their data. This data is best gathered automatically:
    1. On each Technical System configure Data Suppliers to send Technical Systems’ data to the SLD (System data in the SLD is used by applications, e.g. SAP NetWeaver PI, Web Dynpro Java). Prerequisites for successful use of the SLD are described in the SCN.^
    2. Set up the SLD topology according to SAP’s recommendations.
    3. Keep CIM Model / CR Content in the SLD systems up-to-date (see SAP Note 669669).
    4. Configure the Data Suppliers of your Technical Systems.
  2. Products are installed on more than one Technical System in many cases, therefore from Technical Systems’ data a landscape description has to be derived, describing the dependencies between the Technical Systems.  This is done in Product Systems:
    1. Create Product Systems and assign Technical Systems along their Product Instances.
    2. Use Landscape Verification [LINK] to check the quality of your landscape description
  3. For monitoring purposes, you can gather Technical System in Technical Scenarios to monitor groups of Technical Systems that belong together either technically (as in a Dual-Stack) or because of being used in the same business process.
    1. Install or check the Agents Installation
    2. Perform the Managed System Configuration step in transaction SOLMAN_SETUP

These are the big steps you need to be able to perform monitoring, maintenance, update, and upgrade in your landscape using the monitoring applications and the Maintenance Optimizer in combination with the update/upgrade tools and the SAP Service Marketplace.

Additional Information

You’ll find parts I and II of this blog series and links to tools and application dealing with them on a dedicated page called Landscape Descriptions.

To report this post you need to login first.

1 Comment

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

Leave a Reply