Maintenance of system tracks with Maintenance Optimizer
Maintenance of SAP Landscapes / system tracks
The maintenance of SAP systems, especially the implementation of Support Packages, Support Package Stacks, SAP enhancement packages or upgrades, generally should be done with Maintenane Optimizer in SAP Solution Manager. This ensures that all necessary files for the maintenance activity are downloaded and can be applied. The results of a Maintenance Optimizer transaction are as follows:
- All required files are ready for download in the download basket of the SAP Service Marketplace
- An XML file (the so-called “stack configuration file”) is created. This file contains all the necessary information for the installation tools to properly apply the files calculated by Maintenance Optimizer.
Maintenance of system tracks in detail
For patching or upgrading a single product system, the Maintenance Optimizer guided procedure provides all the files and the stack configuration file, which then can be handed over to the appropriate installation tool to apply the files. This works for a single product system, but if you would like to maintain more than one product system (for example a system track consisting of a development, a quality assurance, a pre-production and a productive system), the following issues arise:
- The stack levels of the product systems inside a track might not be the same.
Most likely, the productive system is on the “oldest” level, because it is not updated that often. The stack level of a quality assurance system might be the same or higher as the productive system, and the development system will most likely have the highest stack level of the track – just because this is the system that gets patched and updated most often. The result of this “imbalance” is that the stack configuration file generated by Maintenance Optimizer for the DEV system is not necessarily identical to the stack configuration file generated for the quality assurance and / or the productive system if these files are generated separately from each other. Other selection options in the Maintenance Optimizer Guided Procedure then can also be different, i.e. the target selection.
- The number of activated Business Functions inside a track might not be the same.
This issue goes into the same direction as the first one – most likely, the smallest number of activated business functions can be found on the productive system, a higher number on the quality assurance system and an even higher number on the development system. From this issue, the same problem as above arises – the generated stack configuration file for the development system is not necessarily relevant for QAS or PRD.
These issues lead to a higher effort for maintaining system landscapes, especially if all systems of the track need to have the same stack level and the same business functions activated.
To maintain a system track consistently, the same stack configuration file needs to be applied on all systems of the track. This can be achieved by including all systems of one track into one maintenance transaction in Maintenance Optimizer. Maintenance Optimizer then creates a single stack configuration file for the whole track which ensures the consistency of the patch or upgrade process.
You can assign technical usages separately for each product system of the track during the maintenance transaction.
Important: Do not generate separate stack configuration file for every single product system of a system track if you plan to patch or upgrade the whole track.
SAP also does not recommend implementing Legal Change Packages during the patch phase of a system track. This could lead to inconsistencies between the different product systems of a track and therefore would invalidate the generated stack configuration file for the whole system track. Information about upcoming Legal Change Packages is provided using SAP Notes (“planned legal changes”). Take this information into account when planning the patch phase for a system track.
Copying Stack Configuration Files (only for identical systems)
To reproduce a calculated target constellation on another system, a copy report exists. If you must create exactly the same constellation of one system on a second system, the stack configuration file that has been created for one system can be copied to use it for another system.
Important: The copy report only works if the second system is on the same SP level as the system where the report originally has been created for. If this is not the case, create an individual maintenance transaction for the second system.
For the XML copy report, see SAP Note 1600302.
For information on landscape data needed as a basis for maintenance transactions and tools to handle them, see Landscape
Descriptions at the SCN: http://scn.sap.com/docs/DOC-8935.