Verification of system data is needed to have a reliable basis for planning landscape changes, deployment of additional software, or system upgrades and conversions. Therefore, the verification status is integrated in the process of the Maintenance Planner: If the verification status is “Error”, prior to planning any change of the system, you need to successfully run the verification.
Entities of Verification
SAP (software) products are installed on computers. In the on-premise case, you call these technical systems. Note that in a concrete installation, we always need to think in product versions.
The units of delivery are called software components(SC). As with products, in any concrete installation what we have is software component versions(SCV).
Product instances define SCs that need to run together on the same technical system. Since there are, of course, version dependencies between these SCs, product instances ensure that the correct versions are used and, therefore, are the entity to describe a correct set of SCs. That is why having complete product instances versions is key in system verification.
For any product instance, in the system you find specific product instance versions (SCVs and sometimes even SCs will differ between different versions of the same product instance).
Each (software) product of SAP has one or more product instances, each product instance has one or many SCs. Verification checks, if
the software – all SCVs, specifically – found on a specific system are covered by a set of product instances versions and
product instances versions are complete, containing all defined SCVs and
If the versions of all elements is consistent.
Only such a system description is valid and verified with OK. Products are installed in a specific version, which also relates to the allowed versions of SCs and product instances.
The information on the system’s software is stated in three database tables for products, product instances and SCs. It is important to understand that SCs are what is most reliably detected on a system, because the information on SCs is delivered as part of the SCs. (In contrast to that, the information on products/product instances is delivered with the stack.xml only). Therefore, as a rule of thumb:
You shouldn’t manually change SC data
You should use a stack.xml when deploying software to your system (not only with the SUM, but also when using transactions SPAM or SAINT)
If there is an invalid system description, it will be detected in the Maintenance Planner.
For more information on the product model, see Landscape Descriptions > Overview Knowledge - SAP's Product Model and Landscape Entities @ the SCN.
Working with the Verification Function of the Maintenance Planner
The Maintenance Planner offers a verification function of the description or metadata in two ways in case of errors that must be solved prior to planning:
The recommended approach: You can verify the systems metadata describing the Installed Software Information, adjust them, and directly plan based on the corrected data using the same maintenance transaction (by simply going back to the plan step).
All corrections will be applied together with the intended change (an SPS update, for example); there is no more additional work.
The reasonable alternative, in case you want to correct the metadata in the system but do not plan a software change in the near future: You can verify the Installed Software Information, and – in case of problems – create a correction file to correct the metadata describing the software state in the LMDB called CISI.xml. (The whole procedure is named CISI, accordingly.)
The CISI.xml is applied to the system using the Software Update Manager (SUM) only correcting the system’s metadata.
In most cases, we recommend to use the 1st approach to combine the correction of metadata with what you really want to implement: Apart from stepping through the verification question, there are not steps in addition to what you need to do anyways during the update.
Since verification is key for successfully planning your landscape changes, verification is a mandatory process, fully integrated into the planning process in the Maintenance Planner. You can also filter for erroneous systems in the Explore Systems view to work on problems proactively:
Figure 1: List of erroneous systems in the Maintenance Planners System Overview.
So you can easily find systems where the description needs to be checked.
Note that there are also implicit checks of the system state: Erroneous systems for example cannot be added to a track.
To solve verification problems, you select a single system and open the verification dialog:
Figure 2: Verification status “Error” of a single system; the planning function is not available as long as a system is in an erroneous state.
Click Verify to start the dialog guiding you through the verification process.
Examples of Errors and Solutions
There are different types of errors, but they mostly have to do with product instances not covering exactly the number of SCs on the system:
Figure 3: Options offered in the verification dialog, if one or more SCVs that are not covered by a product instance version.
Incomplete Product Instances
This is the most common problem. There are several possible reasons for incomplete product instances: Software components (SCs) not needed have been added or installations have been done incompletely Note: Usually, such errors only happen, when deploying software without a proper stack.xml.
This problem in most cases will affect add-ons. But in some other cases, SCs may have been deployed on your system manually, but not as part of a valid product instance. It could then reside on the system, until it is detected by the verification function.
For some reasons – probably without using a stack.xml – an SCV, which is not needed, has been deployed. This is detected and needs to be solved prior to planning:
Check if an SC can be deleted – see SAP Note 2011192 - Uninstalling ABAP add-ons:
Yes: In the verification dialog choose to ignore: If the SC can be deleted, then one recommended approach is to have the same deleted, and system information newly uploaded again. If the SCV is ignored, then the end-user needs to provide a deletion ACP during the SUM execution in the IS_SELECT phase (as there might be no successor calculated for the current SC).
No: If SCs cannot be deleted, to come to a valid system state fill up with a fitting product or product instance by selecting (for example the smallest) one offered that cover the SC in question: Missing SCs will be added to the download basket and added product/product instances are stated in the stack.xml / CISI.xml and written to the appropriate table by the SL-Tool consuming the Maintenance Planner output.
Note: Adding or changing products / product instance may affect licensing.
Problem cause: For some reasons – again, without using a stack.xml – a product instance that is needed, was deployed incompletely but you want to use the function.
Fill up with a fitting product by selecting it from the list of offered product versions.
Note: Adding products / product instance may affect licensing.
In addition, the information on installed software needs to be updated in the system: This will be done by the stack.xml, when you implement the change.
Wrong Assignment of Product Versions
In a simple case let’s assume on a system that registers with SAP ERP 6.0, EHP5 an SAP NetWeaver 0 is in the system’s metadata.
If all other data is consistent (including the SC versions of SAP NetWeaver), the Maintenance Planner will automatically pick the correct version for SAP ERP 6.05, which is SAP NetWeaver 02.
Wrong Assignment of Products
In some cases, the only problem exists in the description of a system. You only have the required functions and all work, but you cannot update or upgrade the system due to verification errors.
In such cases, use the CISI process (Correct the Installed Software Information).
While in most cases, single product instances need to be corrected in some cases you may end up in verification where not even the correct product installed is offered.Example:
This may happen if a system is shown as an SAP CRM installation, while in reality it is an SAP Solution Manager (which, in fact, contains a part of SAP CRM).
In such a case it is not possible to calculate a useful maintenance transaction; therefore the metadata need to be corrected.Correction Procedure:If you do not plan a change and the required verification in one Maintenance Planner transaction, you can just add correct the erroneous system information. Use the verification as usual, but you need to handle the upload of a correction file, if you do not do a change using the stack.xml file:
De-activate the Data Supplier of the system in question
(otherwise, changes might be overwritten in the middle of the process).
Change the meta data describing the system’s software in the LMDB manually, so that CISI process can start.
Upload the system’s data (and check them in the Maintenance Planner)
Create the CISI.xml file in the verification in Maintenance Planner for the erroneous system
Apply the CISI.xml to the erroneous system using SUM
Re-activate the Data Supplier of the erroneous system.Note that if you add SCs during the verification, it needs to be deployed on the system – otherwise, after the next data-supplier run, the system will state again that the SC is missing.
Rectify Technical Systems' Data in the Maintenance Planner