Solution Manager consulting is made up of a cacophony of strategic and tactical decisions, technical nuance, and downright finesse. Customer landscape drawings and data models often remind me of snowflakes -- no two solutions are ever alike. Despite their unique differences, however, no SAP landscape discussion is complete without establishing the locations of both the LMDB and/or its corresponding SLD(s).
...Until now.
To review, the SLD is a repository of technical systems, applications and attributes that provides a real-time overview of your entire SAP landscape. Short for System Landscape Directory, the SLD contains both native and third-party application data and is considered essential to the successful management of any SAP solution implementation.
Enter the SLD’s (not-so) little cousin -- The Landscape Management Database, or LMDB for short. The LMDB, part of Solution Manager itself, receives its information from Host and Diagnostic Agents and even one or several SLDs (collectively known as Data Suppliers). This data repository contains the nuts and bolts of your entire SAP installation and is a critical component of any SAP solution architecture.
The LMDB and SLD both use what is called the CIM Model, or Common Information Model, as their data classification backbone. This model is a standard of the Distributed Management Task Force and is an object-oriented approach to modeling both hardware and software components. All synchronization components should follow the unique-path principle; that is, each data source should follow one defined path so that the same dataset does not arrive in the LMDB from multiple locations.
To recap, the LMDB receives its landscape information by default via automatic system registration from the SLD and its Data Suppliers. This process, known as content synchronization or Full Automatic Synchronization, is the default (and still highly recommended) process for creating system information in the LMDB. As of Solution Manager 7.20 SP06, however, we can bypass the SLD altogether by sending information to the LMDB directly via the managed systems themselves… if our proposed environment warrants such a solution.
Keep in mind, however, that this does NOT mean that we can go without the SLD entirely as CIM/CR data itself can only be read via the SLD. In other words, you cannot point your CIM/CR data to the LMDB directly; it HAS to be read from the SLD. What we CAN do in certain situations, however, is relieve the SLD’s role as a data supplier itself and let the managed systems do the work.
To recap, Solution Manager 7.2 SP06 now offers a solution known as Data Supplier Processing, enabling us to effectively remove the SLD as a data supplier of managed system information itself. There are some drawbacks and limitations to this approach, however. Below are some thoughts to consider that will help you determine if a faux-SLD-less SAP solution is right for you:
If your answer to any of the above questions is YES, then carry on, my wayward son! A traditional managed systems->SLD->LMDB configuration is the right one for you.
...But what if you answered each question with a resounding NO? What if you want to give this new SLD-less SLD configuration a try? As uncommon as this solution may be, it’s not as hard to implement as one may think.
In the steps that follow, I’ll walk you through enabling data supplier processing in both Solution Manager and the managed systems that report to it. Once these steps are completed, simply enable a few options regarding CR content in solman_setup and boom, your SLD is relieved of its traditional duties as a managed system data supplier. Let’s begin!
In Your Solution Manager system (the one where your LMDB is located):
1.If needed, create a technical user as described in the SAP Solution Manager Secure Configuration Security Guide:
This user will be needed later in transaction RZ70 of your managed system(s).
2. Activate the Internet Connection Framework (ICF) in transaction solman_setup->Basic Configuration:
3. Check the ICF service in transaction SICF->Execute. All services under /default_host/sap/bc/cim should be activated in the service hierarchy:
4. Choose External Aliases-> /sld/ds and /lmdb/ds and then click Test External Alias:
If successful, the following screen appears:
(Yes, this screenshot is tiny.) Be sure to write down the host and port you see in the URL as they are very important!
On the managed system(s) side:
See SAP Note 2183995 for more information.
Next up -- adding, removing, or modifying your SLD as a data supplier to the LMDB:
You’ll see that the primary difference between the two options is whether or not you wish to update CR content manually. SAP gives explicit instructions on the business requirements for each scenario as well.
The first option enables a full, automatic synchronization of your CIM and CR content. The pros of this option include:
The cons include:
Please see the following blog post for more information on the CIM Model in this scenario.
The second option entails manually downloading content updates from the Support Portal and uploading them into the LMDB directly. The pros of this option include:
Remember that all data suppliers) MUST be configured to report their data directly to the LMDB in either scenario.
To recap the steps above, configuring your landscape to directly register each managed system into the LMDB versus via the SLD requires:
In summary, if there are no managed systems that must report to a system landscape directory due to business function or technical design, we can now consider removing the SLD as a data supplier itself as the managed systems can now be configured to report to the LMDB directly
Want more information or assistance with the above? Feel free to contact me and my team at www.benimbl.com.
Happy landscape managing!
...Until now.
To review, the SLD is a repository of technical systems, applications and attributes that provides a real-time overview of your entire SAP landscape. Short for System Landscape Directory, the SLD contains both native and third-party application data and is considered essential to the successful management of any SAP solution implementation.
Enter the SLD’s (not-so) little cousin -- The Landscape Management Database, or LMDB for short. The LMDB, part of Solution Manager itself, receives its information from Host and Diagnostic Agents and even one or several SLDs (collectively known as Data Suppliers). This data repository contains the nuts and bolts of your entire SAP installation and is a critical component of any SAP solution architecture.
The LMDB and SLD both use what is called the CIM Model, or Common Information Model, as their data classification backbone. This model is a standard of the Distributed Management Task Force and is an object-oriented approach to modeling both hardware and software components. All synchronization components should follow the unique-path principle; that is, each data source should follow one defined path so that the same dataset does not arrive in the LMDB from multiple locations.
To recap, the LMDB receives its landscape information by default via automatic system registration from the SLD and its Data Suppliers. This process, known as content synchronization or Full Automatic Synchronization, is the default (and still highly recommended) process for creating system information in the LMDB. As of Solution Manager 7.20 SP06, however, we can bypass the SLD altogether by sending information to the LMDB directly via the managed systems themselves… if our proposed environment warrants such a solution.
Keep in mind, however, that this does NOT mean that we can go without the SLD entirely as CIM/CR data itself can only be read via the SLD. In other words, you cannot point your CIM/CR data to the LMDB directly; it HAS to be read from the SLD. What we CAN do in certain situations, however, is relieve the SLD’s role as a data supplier itself and let the managed systems do the work.
To recap, Solution Manager 7.2 SP06 now offers a solution known as Data Supplier Processing, enabling us to effectively remove the SLD as a data supplier of managed system information itself. There are some drawbacks and limitations to this approach, however. Below are some thoughts to consider that will help you determine if a faux-SLD-less SAP solution is right for you:
- Does my solution require landscape forwarding and/or multiple SLDs?
- Does my solution require automatic synchronization of data?
- Does my solution require NWDI, Process Integration, Process Orchestration, or other Netweaver Portal components?
If your answer to any of the above questions is YES, then carry on, my wayward son! A traditional managed systems->SLD->LMDB configuration is the right one for you.
...But what if you answered each question with a resounding NO? What if you want to give this new SLD-less SLD configuration a try? As uncommon as this solution may be, it’s not as hard to implement as one may think.
In the steps that follow, I’ll walk you through enabling data supplier processing in both Solution Manager and the managed systems that report to it. Once these steps are completed, simply enable a few options regarding CR content in solman_setup and boom, your SLD is relieved of its traditional duties as a managed system data supplier. Let’s begin!
In Your Solution Manager system (the one where your LMDB is located):
1.If needed, create a technical user as described in the SAP Solution Manager Secure Configuration Security Guide:
This user will be needed later in transaction RZ70 of your managed system(s).
2. Activate the Internet Connection Framework (ICF) in transaction solman_setup->Basic Configuration:
3. Check the ICF service in transaction SICF->Execute. All services under /default_host/sap/bc/cim should be activated in the service hierarchy:
4. Choose External Aliases-> /sld/ds and /lmdb/ds and then click Test External Alias:
If successful, the following screen appears:
(Yes, this screenshot is tiny.) Be sure to write down the host and port you see in the URL as they are very important!
On the managed system(s) side:
- Each AS ABAP system MUST use HTTP(s) as its data processing protocol within RZ70 -- RFCs are no longer supported. You must download and implement SAP Note 2188401 in order to support this change.
- Regarding Web Dynpro- or other non-ABAP managed systems, you’re in luck! These systems are already configured to use HTTP(s) for data processing. Simply define the URL of your LMDB Data Supplier Processing URL in each managed system configuration of Solution Manager. For reference, an updated RZ70 transaction will look like the following:
See SAP Note 2183995 for more information.
Next up -- adding, removing, or modifying your SLD as a data supplier to the LMDB:
- Log into Solution Manager if you have not already and execute transaction SOLMAN_SETUP->Infrastructure Preparation->Step 1 (assuming all previous steps are fully completed).
- Ensure you are in edit mode and read the first two options carefully (Under Manage Import of Model CR Content):
You’ll see that the primary difference between the two options is whether or not you wish to update CR content manually. SAP gives explicit instructions on the business requirements for each scenario as well.
The first option enables a full, automatic synchronization of your CIM and CR content. The pros of this option include:
- All content data is included in the transfer
- This is the fastest solution for synchronizing content
- This is the recommended solution if you do not have any content synchronization from the SLD to the LMDB using namespace ACTIVE
The cons include:
- All content data is included in the transfer (no filtering mechanisms exist)
- No control is given regarding the point in time in which the content data is synchronized
Please see the following blog post for more information on the CIM Model in this scenario.
The second option entails manually downloading content updates from the Support Portal and uploading them into the LMDB directly. The pros of this option include:
- This is the recommended solution if you are installing a new Solution Manager instance without an SLD dependency
- This is the recommended solution if you also do NOT have a reliable Support Portal connection for automation
Remember that all data suppliers) MUST be configured to report their data directly to the LMDB in either scenario.
To recap the steps above, configuring your landscape to directly register each managed system into the LMDB versus via the SLD requires:
- Registering the LMDB as an external alias in transaction SICF in Solution Manager
- Adding the http(s) destination of each managed system via RZ70 (if ABAP)
- Adding the http(s) of the SLD_DataSupplier of each managed system via the SLD Data Supplier Connection (if Java)
- Registering each managed system within Solution Manager manually using an OS-level connection (see SAP Note 2836143).
In summary, if there are no managed systems that must report to a system landscape directory due to business function or technical design, we can now consider removing the SLD as a data supplier itself as the managed systems can now be configured to report to the LMDB directly
Want more information or assistance with the above? Feel free to contact me and my team at www.benimbl.com.
Happy landscape managing!
- SAP Managed Tags:
3 Comments
