The application of Support Packages is one of the main software maintenance tasks, so is true with the maintenance of SAP systems. In addition, there are a lot of new terms, methods and system types which have emerged in the last few years. With this introductory article, we will start a series focusing on different subjects of the topic of applying Support Packages to SAP systems. Why apply a Support Package Stack as a whole?
In 2003, SAP introduced the so-called Support Package Stack (SP Stack) for the shipment of Support Packages for certain product versions, i.e. all new product releases which went to RTC (released to customers) since this point in time and some older releases. So you might raise the question what is the benefit of SP Stacks? The answer is quite simple, it's the reduction of TCO for customers of SAP products, because an SP Stack presents an optimal combination of Support Packages and patches of all components of a particular product release at a given time. Previously without SP Stacks, if you want to apply updates to your SAP system, you start with collecting all the appropriate Support Packages of the components, including ABAP software components, kernel patches etc. That was usually, if not error-prone, at least a toilsome task to gather the complete and functioning set of the required Support Packages. With SP Stacks you can simply launch the stack download page of the respective product release and specify the source and target SP level and some few others, after few clicks you get the complete set of the Support Packages of all involved components in a compatible and functioning combination for your platform. It's really cool, isn't it?
Furthermore, if you consider that the newer software systems in the Web Services and SOA era are no more a monolith like in the R/3 time. A state-of-art enterprise application involves most likely multiple systems each of which has a certain role in the system landscape and works more or less tightly with other systems of the application scenario. The challenge would be to find the appropriate Support Packages not only for the components of one single system, but for all involved systems. With the SP Stack concept, you can select the required SP Stack in a usage-oriented manner. For instance, if you want to download a certain SP Stack for the Enterprise Portal of SAP NetWeaver 2004s, the Search and Classification engine TREX is also provided in the corresponding SP version which is required in some of the portal-related scenarios. (By the way, if you don't have a TREX installation, you can exclude it from the download list.) Therefore, applying an entire SP Stack is the recommended way to update your SAP system.
How to apply a Support Package Stack?
So, if you are convinced of the advantages of applying a Support Package Stack as a whole, you should be interested in the how-question. Actually there is no magic about it, all tools you have used so far to import Support Packages remain the same for applying SP Stacks, because a SP Stack is nothing other than a qualified combination of ordinary Support Packages. Nonetheless, the process has been evolving fairly rapidly during the last few years. New tools have been introduced for new system types like Java systems etc. New techniques and best practices evolve in the sense of managing software maintenance more efficiently. Let’s turn to examining the aspects in more details. ABAP
ABAP is a mature technology. The tool pair SPAM/SAINT are still used to apply Support Packages of ABAP-based components and other Add-ons. The procedure consists of following steps: - Backup the system.
- Extract the bundles of the kernel patches – which normally consists of two files, one for database-independent (SAPEXE.SAR) and another the database-specific programs (SAPEXEDB.SAR) – as well as the patch file of IGS (igsexe.sar) to the central kernel directory.
- Restart the system.
- Apply the update of SPAM/SAINT if requested.
- Import the ABAP Support Packages.
What is less widely known is the downtime-minimized mode of both tools with which the overall production downtime can be reduced to a minimum when importing the Support Packages. It splits the import of the Support Packages into two separate phases, inactive import of the repository objects included in the SPs and activation of the new versions of the objects. The first phase does not affect the normal business operations so that the system remains productive until you explicitly start the second phase at the end. Thanks to this fact, you can slightly deviate from the above procedure and put off the kernel patch until the end of first phase and restart the system before you continue with the second phase of the SP import. In this way, all productive downtimes are aggregated to one time slot. Although this downtime-minimized procedure is sophisticated, it has one restriction. In rare cases, new kernel patch is prerequisite for the SP import which makes the downtime-minimized method impossible. But it is seldom that the essential kernel programs like disp+work is requisite before the import can take place! More often is the situation that new versions of some kernel programs like TP and R3Trans are required by the update of SPAM/SAINT. The patch of these programs can take place in the running system. (Don't forget the backup before you start the patch.)
There is another helpful tool which can be used after the SP import. You can run the transaction SGEN to regenerate all new objects before they will be invoked. Otherwise, the regeneration of the object execution code takes place only ad hoc when a particular piece code is being called. It costs some time and appears disturbing to some users.
Java
SAP introduced the Java-based system a few years ago which is compliant with SUN's Java Enterprise Edition. With the newest release of the SAP’s technology platform, SAP NetWeaver 2004s, and the applications of the SAP Business Suite 2005, SAP delivered the Java Support Package Manager (JSPM) for applying SPs to Java-based system is introduced. JSPM is the single valid tool for applying Java Support Packages, because it brings some essential features in comparison with the native Java deployment service like the Software Delivery Manager (SDM). For instance, JSPM performs a comprehensive validation of the SP Stack according to the SP Stack definition file and the runtime system to be updated before the actual update process can take place. Only if all conditions are fulfilled, JSPM will go on with the patch. This makes the update process more secure and reliable. Although the validation takes some time, it takes place completely during the production uptime. The downtime begins with your explicit confirmation once the validation is successfully finished. Another feature is, contrary to ABAP SPAM, that JSPM is able to apply kernel updates to the system. In most cases, manually applying kernel updates is no longer necessary, you can simply put the kernel update packages to the inbox of JSPM and the update will take place automatically. In some non-standard installation scenarios, the automated kernel update does not work. One of the next articles from this series will address this issue.
All concluded, the general procedure of applying an SP Stack to a Java system consists of following steps:
- Backup the system.
- Apply to update of JSPM using JSPM itself.
- After restarting the JSPM, apply the SP Stack using the option Support Package Stack.
There are two further blogs on SDN which provides deep insights to JSPM: Standalone Engines
Beside the ABAP or Java-based server systems, there are numerous standalone engines which are delivered with the SAP NetWeaver platform. Their updates can be applied separately to the corresponding entities. TREX and BI Accelerator
TREX is an application for search and classification of contents which is generally used by different components of NetWeaver, while the BI accelerator a special build of TREX for preconfigured 64-bit Linux machines which is only used in combination with Business Intelligence. The updates of both applications are quite straight forward. Their update packages contain executables for launching the update process. You just need to follow the steps and provide some system-specific information and the update will continue according your inputs. Gateway Server and Web Dispatcher
The SAP Gateway Server and SAP Web Dispatcher are two services which are normally installed with every SAP Web Application Server system (ABAP and Java) along with the kernel binaries. These affiliate services are updated along with the kernel patch, you don’t need to make any extra efforts. However, if these two services have been installed on separate hardware with their own system identifiers (SAPSID), the update will have to be conducted separately. The update is quite similar to the kernel update of an ABAP system. All you have to do is just extract the kernel patch bundle SAPEXE.SAR to the corresponding kernel directories and restart the systems. Last but not least ...
So far you have learned the essentials of the update processes for different types of SAP applications. For your practical work, there is an essential aid. It is the SAP NetWeaver Support Package Guide which is updated with each new SP Stack. You can download it at http://service.sap.com/maintenancenw2004s. The guide describes the update processes of all NetWeaver usage types in more details, from the planning throughout preparation and updating to post-configuration phases. It provides you component-specific and up-to-date information. Just take it as your guide for success!
