- SAP Managed Tags:
Introduction
When the Maintenance Planner was introduced, SAP Solution Manager 7.1 was well established in the market. Also, functions important for the maintenance planning landscape changes where already available in Solution Manager Landscape Management Database (LMDB):
- Definition of product systems to be able to keep versions of backend and front-end system of the same product installation in sync – see:
- Product Systems and Maintenance Planner in SAP Solution Manager 7.1
- Landscape Entities & Maintenance Planner in SAP Solution Manager 7.2
- Verification of systems
Entities of Verification
SAP (software) products are installed on computers. In the on-premise case, you call these technical systems. Keep in mind that each installation is of one specific product version.
The units of delivery are called software components (SC); some SCs need to run together on the same technical system. Again, on the technical system, what you see are software component versions.
To ensure that each SC can connect to such SCs required on the same system, product instances define such groups of SCs that need to run together. The exact software components and versions depend on the installed product instance version. Each (software) product version of SAP has one or many product instances.
The fact that in a product version a set of product instances is used, each of which contains a set of SCs - the target of support packages, is why you in most cases deal with well-defined support package stacks.
Figure 1: An example of a standalone and add-on product version installed on A01 shown in the LMDB.
While the upcoming changes of handling product systems has been described in detail, here is how to deal with verification in the Maintenance Planner.
How Does Verification Work in Principle?
Verification checks, if the software listed for a system is a valid a valid combination of versions. This is done by checking, if all SCs found on a specific system are covered by a set of product instances. So there may be missing or superfluous software components (SCs), wrong product version assignments, etc. By the way – many or most errors stem from changes of the system without precise calculation and without describing the new system state in a stack.xml. That is why investment in this area is so important.
But first let’s deal with the improvements coming with the Maintenance Planner.
Simplification of Dependency Definition
The best approach when it comes to error-handling is to avoid them: The most important case of verification is the former product system or now maintenance dependency.
Figure 2: The creation of a product system in the LMDB compared to a maintenance dependency in the Maintenance Planner. You see that some product instances running on P00 need to be assigned to E00.
In a product system as well as in a maintenance dependency in the Maintenance Planner product instance versions of the same product are assigned to technical systems. The big difference is that In the product system you needed to deal with product instances, which was error-prone, while with the Maintenance Planner you simply assign the dependent technical system – in figure one the portal front-end to the ERP backend system. If you pick two technical systems that do not have a product in common (like E00 and P00 both have parts of SAP ERP 6.05 installed), you will not be allowed to create a maintenance dependency.
Evolution of the Verification Process and Checks
Maintenance Planner with SAP Solution Manager 7.1
Currently, there are two combinations possible, since Maintenance Planner works with SAP Solution Manager 7.1 and 7.2. This section shall help you understand the differences – and how the unification in verification has improved with SAP Solution Manager 7.2.
Let’s have a look at the verification checks in detail:
- Verification in the on-premise installation of SAP Solution Manager:
- LMDB sends data to the PPMS, which offers a service in the SAP Support portal, where system data is checked against SAP’s product model.
- Maintenance Optimizer (MOpz) adds checks of licensing
- Verification of the same data in the Maintenance Planner
- Checks running in the system itself are performed by the SL Tools, mainly the SUM.
These checks are not just a 3rd time check of the same data but concentrate on other data such as OS/DB versions. As an example:
A product version selected for the update may require an additional update of operation system or database version, which is not part of the calculation in Maintenance Planner or MOpz.
Note: You would expect identical results in both cases, and in most cases they are. In fact both verification implementations in the LMDB and the Maintenance Planner are connected to the PPMS calculation service. However, the handling of results in the Maintenance Planner has evolved higher, and therefore the verification results in Maintenance Planner and LMDB may look different.
Figure 3 shows the situation with the Maintenance Planner and SAP Solution Manager 7.1 – connections used for checks and verification are shown in green:
Figure 3: Verification (shown in light green including connections between tools involved).
If you compare this with figure 2 showing the situation with SAP Solution Manager 7.2, you’ll see, how the process has been simplified.
Maintenance Planner with SAP Solution Manager 7.2
This changes with SAP Solution Manager 7.2: The Maintenance Planner is mandatory with that version and the process has been consolidated: The verification in LMDB is no longer present:
Figure 4: Verification is only done in the Maintenance Planner; additionally, there are system checks SL Tools.
You only find 2 checks:
- The verification based on the product model plus license checks in the Maintenance Planner
- Checks on the systems in the SL Tools
Further Information
- For handling landscape data, see Data and Topology of SLD, LMDB, and Customer Profile – How to Get Reliable Landscape Data in SAP Sup... @ the SCN
- For the complete process on planning changes and all related tools, see Landscape Management- the Process @ the SCN
.
.
.
