Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Verification in the Maintenance Planner – Part II: How-to & Examples

wolf_hengevoss
Active Participant
‎05-04-2018 10:01 AM

Introduction


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:

  1. 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.

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

Superfluous SCs


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.

  • Problem cause:
    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:

  • Recommended solution:
    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.




Missing SCs



  • 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.

  • Recommended solution:

    1. Fill up with a fitting product by selecting it from the list of offered product versions.
      Note      : Adding products / product instance may affect licensing.

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



  • Problem:
    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.

  • Solution:
    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



  • Problem:
    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.

  • Recommended Solution:
    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:



  1. De-activate the Data Supplier of the system in question
    (otherwise, changes might be overwritten in the middle of the process).

  2. Change the meta data describing the system’s software in the LMDB manually, so that CISI process can start.

  3. Upload the system’s data (and check them in the Maintenance Planner)

  4. Create the CISI.xml file in the verification in Maintenance Planner for the erroneous system

  5. Apply the CISI.xml to the erroneous system using SUM

  6. 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


The Maintenance Planner now allows to change meta data on software installed on technical systems in its verification function.
Note that this is an expert function. For details, refer to SAP Note 2523380 - Improvements to Rectify Erroneous Systems in Maintenance Planner.

  1. Enable the edit mode of verification in the Personalize settings:

  2. Select a technical system and start the editing using the Verify - this will even work if the status is OK (green):

  3. You'll see the UI to edit software information on the chosen technical system:


 

Further Information



SAP Support Portal page Landscape Management Process contains details regarding SAP’s product model and links you to all related tools including a best practices guide.
Labels in this area
Popular Blog Posts