When will it be possible?
Since Solution Manager SP15 (MOPZ) and Netweaver 7.0 SP14 (SLM) for all customers of business suite is possible first part of automated scenario, providing only download from Service Marketplace (SMP). In the mentioned versions download with SLM is only optional to main possibility with well known download basket.
The second step is automated deployment/import of already downloaded support package stacks, including only ABAP and Java components. This will be available with Solution Manager SP18 and Netweaver 7.01. The common missing functionality in the scenario is missing kernel update, which is result of lack of information about OS and DB.
With Netweaver 7.02 the kernel will provide the missing information about OS and DB and therefore automated kernel update will be integrated as well. This will be available most probably for Business Suite 2009.
What is automated?
Download – with download basket is required manual control on the process, with MOPZ/SLM only support package stack is selected and download is fully automated for all files of selected stack. As additional benefit SLM will detect and download the latest available at SMP patch for each archive.
Deployment/Import – currently downloaded archives of support packages should be deployed (Java) or imported (ABAP) via low level logistic tools (JSPM/SPAM/SAINT). With SLM the deployment/import after download will be done automatically. No more need of specific knowledge for different tools.
Self-update of logistic tools – currently before deployment with JSPM for example to be done is required the version of JSPM to be updated according to the version of running Netweaver. The same is true also for all other logistic tools. With SLM self-update of tools is integrated into the whole procedure and customer should not bother about their versions.
Update in big landscape – currently in case the landscape contains many systems all of them should be maintained locally, by using local for the system tools. With MOPZ/SLM there is only one MOPZ and only one SLM responsible for maintenance of all systems in the whole landscape. Control and monitoring of maintenance process is centralized.
How it works?
The big picture of the whole process looks like:
The order of execution is the following:
• Each software component installed at system in the landscape reports about its version and installed support package to Software Landscape Directory (SLD) on regular basis automatically. For ABAP component is used transaction RZ70, and for Java components is used SLD Data Supplier (configured via Visual Administrator or Netweaver Administrator). Also in SLD is reported information about available application systems – ABAP (BCSystem) and Java (J2EEEngineCluster)
• SMSY transaction use the information from SLD about systems and installed components and support packages
• MOPZ (transaction dswp) provides user interface for selecting by customer the desired support package stack on target system in the landscape. The information about systems and software components is read from SMSY repository.
• MOPZ sends the collected information via RFC call to Global Support Backbone for so called queue calculation. The calculation uses input provided by MOPZ and information from Product and Production Management System (PPMS) about support packages of each component included in support package stack. That is very important step, because it guaranties that proposed support packages for currently running products will remain to work in the future and will not compromise the running applications. The result is stack XML
• MOPZ using stack XML and selected by customer OS/DB specific archives filter the initial XML accordingly
• MOPZ provides the final stack XML to SLM and delegates the logistic operations to it. Communication between MOPZ and SLM is performed via web service provided by SLM, where MOPZ calls different methods and SLM reacts by controlling and monitoring remotely different tools in the landscape. For executing remote connection is used web service SAPControl, which allows execution of OS processes remotely. On each system in the landscape there is a Software Logistic Controller (SLC) responsible for logistic operations on that host and SID. Actually SLM communicates only with SLC, and SLC itself controls and monitors low level tools like JSPM and SPAM/SAINT. The other important functionality provided by SLC directly is downloading.
• SLM using XML stack collects all needed support packages and using web service provide by Global Support Backbone (SMP) receives URLs of all archives at SMP for downloading
• SLM starts SLC on central system and providing list of all archives with their URLs executes download from Service Marketplace (SMP).
• SLM executes self-update of all logistic tools (SLM, SLC, JSPM, SPAM/SAINT) on central and all remote systems involved in the maintenance process currently. The self-update is executed by providing by SLM the list of tools and their respective versions to responsible SLC. Then SLC communicates with affected low level logistic tool and each tool self-updates itself.
• SLM executes update of all application components on system in landscape in the right order. Firstly is updated kernel, then SAP_BASIS component and finally Java and ABAP components in parallel. The update is executed by providing the list of respective component from SLM to responsible SLC, and then SLC starts low level tools (JSPM and SPAM), which do actually the job. The whole process is controlled and monitored by SLM.
• MOPZ controls and monitors SLM during the whole process. In case something goes wrong customer will be notified in MOPZ user interface, and after correcting the issue the process can continue. The benefit is that all situations which require manual action will display the issue centralized. For example if SPAM stops for some reason, the error message will be send to SLC, then SLC will resend it to SLM and finally MOPZ will be notified and will display the information in it’s user interface.
5 Comments
