SUPPORT PACKAGES

Support Packages, also known as OCS (Online Correction Support), are a set of bug fixes that eliminate errors in the SAP system. SAP introduced Support Packages as of SAP R/3 release 3.0A as an addition to release upgrades. Since SAP R/3 3.0A, the delta upgrade has been replaced by the so-called “repository switch” method.

However, applying Support Packages can be compared with a delta upgrade, although you don’t change the SAP release.

In the early days of Support Packages, when they were still called Hot Packages, SAP never added new functionality into it. Today, additional functionality may be added to a Support Package. The entire Euro Conversion kit was shipped through Support Packages.

Support Packages are bound to the SAP release and add-ons used in the system. Fixes in Support Packages, however, are not necessarily bound to SAP R/3 release; it can happen that a certain bug resides in several R/3 releases and therefore needs to be fixed in all those releases. This means that if you upgrade an R/3 4.6C Support Package level 20 system to R/3 4.72 Support Package level 5, you might partially downgrade the system.

Figure 4.32 illustrates the location of a certain bug fix in several different Support Package bundles, each belonging to a specific SAP R/3 release.

Individual bug fixes are also described in OSS notes, which are known as Source Code Corrections. These ABAP source code corrections can be applied manually using the SE38 ABAP editor. However, it’s more efficient to use “SNOTE – Note Assistant” or wait until SAP releases a new bundle of Support Packages.

Figure 4.32: Bug fixes can reside in several Support Packages.

4.7.1 Support Package Types

SAP has released several different kinds of Support Packages: Hot Packages (HP), Legal Change Packages (LCP) and Conflict Resolution Transports (CRT). Since SAP R/3 4.6A even more Support Packages have been introduced: SAP_BASIS, SAP_

APPL, SAP_ABAP, and SAP_HRP. And last but not least, with the introduction of SAP R/3 4.7 Enterprise, the Support Package structure has changed again.

(1) Hot Packages – This type of Support Package was introduced in SAP R/3 3.0A and covers all functional and Basis modules. Has been replaced by SAP_APPL, SAP_BASIS, and SAP_ABAP.

(2) Legal Change Packages – This type of Support Package is only applicable for an R/3 system running the HR module. It was introduced in SAP R/3 3.1H and has been replaced by SAP_HRP packages.

(3) Conflict Resolution Transports – This Support Package is basically a fix for modifications of standard SAP. When a customer uses a certain R/3 add-on, such as IS-Oil or IS-Hospital (IS-Heath), these add-ons may modify certain core R/3 objects, such as adding additional screens, programs, or table fields.

Normal Support Packages are not aware of these modifications and will overwrite them. CRTs are additional transports that need to be added to the Support Packages in order to prevent such overwrite.

(4) SAP_APPL – This Support Package type contain fixes for all SAP R/3 modules except HR (Human Resource).

(5) SAP_BASIS – This Support Package type contains only fixes that belong to the Basis layer, such as fixes for the Batch Engine, CCMS, and User Management.

(6) SAP_ABAP – This type of Support Package type contains only fixes that are related to the ABAP Development Workbench and other development tools;

so all SE-related transactions.

(7) SAP_HRP – This Support Package type contains only fixes for the HR module and is therefore the successor of the LCP Support Package type.

4.7.2 SAP Patch Manager

The SAP Patch Manager, also known as SPAM, can be invoked by using transaction code SPAM. This tool is used to implement Support Packages in all ABAP-related SAP applications; whether it’s R/3, BW, CRM, or APO.

This toolset, as of now called SPAM, provides the ability to load all kinds of Support Packages from various sources, such as CD-ROMs, file systems, the Internet, and desktop into the SAP system. SPAM has a variety of tools to accommodate the load of Support Packages:

(1) EPS – Electronic Parcel Service, can be used to download Support Packages from OSS or the SAP Support Marketplace. The EPS stores all downloaded SAR (SAP archive format) files in “/usr/sap/trans/EPS/in.”

(2) SPAM Queue – This queue needs to be prepared before the actual load of the Support Package occurs. The queue can contain a mix of different Support Package types, such as SAP_BASIS, SAP_APPL, SAP_HRP, and CRTs.

TIP Always check the appropriate OSS notes on the exact SPAM Queue layout. There are restrictions around certain combinations of Support Packages. In other words: not all Support Packages can be combined in one queue.

(3) Import Tool – The actual tool that does the load of the Support Packages into the SAP system.

(4) SPAM Update Manager – This tool is used to patch the SAP Patch Manager itself.

TIP Always update your SAP Patch Manager with the latest SPAM update before you apply new Support Packages into your SAP system.

4.7.3 Conflict Resolution Transports

If your SAP system also contains add-on components, such as Industry Solutions, you need to take care of Conflict Resolution Transports, or CRTs for short. CRTs contain corrections on top of Support Packages that apply to add-on modifications made to standard SAP.

Figure 4.33 CRT prevents overwriting of add-on modifications.

Figure 4.33 illustrates the modification of Core R/3 by an add-on, such as IS-Oil. This “regular” Support Package, however, will overwrite this modification. To prevent that from happening, the CRT will correct this.

TIP Always check whether a system contains any add-ons by using transaction SE16, Table Browser, and then check the table “AVERS” (add-on version table). Also, check all OSS notes related to any add-on described in this table. SAP has introduced many more add-ons besides Industry Solutions.

As of SAP ERP2005 or ERP 6.0, all industry solutions are embedded in the core release of SAP. Therefore, CRTs are no longer required.

4.7.4 Support Package Import Phases

After downloading Support Packages from either a CD-ROM or the Internet (using the SAP Download Manager) into the EPS directory, the import queue can be defined. The import phases will use this import queue as the source for all Support Package imports. SPAM executes the following phases during the import of Support Packages:

(1) PROLOGUE – During this phase, certain checks are done, such as authorization checks, and a check if previous Support Packages are “confirmed.”

(2) CHECK_REQUIREMENTS – During this phase, the transport tool “tp”

checks whether it is able to connect to the database.

(3) DISASSEMBLE – In this phase all EPS packages, located in “/usr/sap/trans/

EPS/in,” are extracted into individual transport files (both co- and data-files) and stored in “/usr/sap/trans/cofiles” and “/usr/sap/trans/data.”

TIP Be sure that your “/usr/sap/trans” filesystem is large enough to hold both EPS and extracted co- and datafiles. Certain Support Package bundles can become very big.

(4) DISASSEMBLE_PATCH – During this phase, “tp” will create co-files of every datafile shipped with the Support Package. The exact statement is:

“ tp createcofile –s <datafile> ”

(5) ADD_TO_BUFFER – In this phase, all transports shipped with the Support Packages are added to the transport buffer. The exact statement is:

“ tp addtobuffer <change request>”

(6) TEST_IMPORT – During this phase, all open repairs and change requests are checked for objects that will be replaced during the import.

(7) IMPORT_OBJECT_LIST – During this phase, a list of all objects that are shipped with the Support Packages are imported in the system. The list is used to check whether there are conflicts between modifications, add-ons, and these shipped objects.

(8) OBJECT_LOCKED_? – This phase checks if objects that will be replaced are locked in a transport request.

(9) SCHEDULE_RDDIMPDP – This phase will check whether RDDIMPDP is scheduled as a periodic job. If not, it will schedule this job.

(10) ADDON_CONFLICTS_? – In this phase, the list, created in “IMPORT_

OBJECT_LIST,” is used to check for conflicts between import objects and any of the installed add-ons.

(11) SPDD_SPAU_CHECK – During this phase, a list of modification adjustments is made and stored in a table that is later presented in transactions SPDD (for Data Dictionary modifications) and SPAU (for ABAP modifications).

(12) DDIC_IMPORT – In this phase, “tp” will import all Data Dictionary objects into the system.

(13) DELETE_FROM_BUFFER – This phase will clean up import buffers.

(14) AUTO_MOD_SPDD – During this phase, SPAM will check whether certain Data Dictionary object modifications can be adjusted automatically.

(15) RUN_SPDD? – This phase will prompt you in case adjustments need to be made in transaction SPDD.

(16) IMPORT_PROPER – This phase, with the longest elapse time, will do the import of all Support Packages. This phase is primarily executed by “tp” and follows the same steps as an “ordinary” import request:

(a) Command File import (b) DDIC import

(c) Activation (d) ADO imports

(e) Conversions

(f ) Version updates (g) Execution of XPRAs

(h) Generation of ABAP programs and screens

(17) AUTO_MOD_SPAU – Same phase as AUTO_MOD_SPDD, except this time it’s for ABAP programs and screens.

(18) RUN_SPAU? – This phase will prompt you when modifications to ABAP programs and screens need to be adjusted. However, due to the fact that ABAP objects can be handled with versions, you may ignore this phase and sort this out at a later stage.

(19) EPILOGUE – In this phase, some administration and control tables are updated with the correct version information.

After applying the Support Packages using SPAM, the administrator needs to

“confirm” the patch queue. The only remaining task is to sort out the SPAU list.

Figure 4.34: Transaction SPAM (Support Package Manager). ©Copyright SAP AG.

4.7.5 Support Packages in R/3 Enterprise

SAP has changed the way modules are organized in R/3 Enterprise. Certain functionality has been moved from core R/3 into the so-called “Extensions.” These extensions are grouped into “Extension Sets.” Therefore, by disconnecting certain functionality from Core R/3, a new group of Support Packages is introduced as well.

Figure 4.35: Different Support Packages in SAP R/3 Enterprise.

Figure 4.35 shows the different component layers of an SAP R/3 4.7 Enterprise system. The second box illustrates the different Support Packages and their interrelationship with SAP R/3 4.7.

Besides these new extensions, the number of plug-ins has also been increased.

Because applying Support Packages to an SAP R/3 Enterprise system has become more complex, SAP has developed the SPAM Queue Calculator. This tool will calculate the ideal combination of Support Packages in order to prevent conflicts.

The second new feature of SPAM in R/3 Enterprise is the “Support Package Shadow Import.” This feature will reduce the SAP application downtime caused by the import of Support Packages. The idea behind this feature is to import, activate, and convert all objects belonging to the Support Package into a shadow repository and, at the end of all phases, switch to the new coding.

Figure 4.36: SAP Support Package Shadow Import. ©Copyright SAP AG.

This new feature provides the ability to reduce SAP application downtime during import of Support Packages by about 60% when compared to the old

method. Downtime savings are achieved, especially when the Import Queue contains all kinds of CRTs for plug-ins and other add-ons. Due to this significant savings, SAP has decided to downgrade the functionality to SAP R/3 4.6C as well.

This is shipped as part of a SPAM update.

The method is relatively easy and based on a set of tables that form the so-called “shadow repository” and are created in parallel to the existing “repository.”

After the entire Support Packages are imported into the “shadow repository”, the system will switch from the “existing repository” to the new “shadow repository”.

This switch is the only phase that requires application downtime. The method described here is similar to what we know from SAP release upgrades as the

“Repository Switch.”

4.7.6 Support Package Stacks

The SP (Support Package) Stacks are sets of Support Packages and patches for the respective SAP release and must be used in the given combination. SAP recommends implementing these SP Stacks regularly. The technology for applying Support Packages and patches will not change. SP Stacks should be seen as an entity unto themselves – customers must obtain the minimum requirements and dependencies between individual components, and apply the Support Packages and patches specified in the SP Stack together. The intention of SP Stacks is to offer better mechanisms to apply support packages to complex systems that contain a lot of different components. Therefore, SP stacks are released synchronously.

Figure 4.37: SAP Support Package Stacks. ©Copyright SAP AG.

4.7.7 Support Packages as of NetWeaver 7.0

With the introduction of SAP NetWeaver 7.0, which is based on SAP Application Server 7.00, SAP introduced a new concept for deploying Support Packages. In the past, Support Packages were directly downloaded through the SAP Support Marketplace, either by Internet Explorer or by the SAP Download Manager. The only requirement was to have access to the download section. However, due to the complexity and number of different Support Packages, SAP has decided to control the download through the SAP Solution Manager. This is done through a tool called the Maintenance Optimizer.

Now that all the industry solutions are embedded in our SAP ECC 6.0 system, the number of components has grown significantly. The SAP ECC 6.0 component, which is the central core component of the SAP ERP 2005 Business Suite, consists of a core system (formerly known as R/3) and various add-ons and industry solutions. With the options of embedded installations (also known as MCOS – Multiple Components in One System) you can expand the installation functionality even more.

Figure 4.38: SAP ERP 2005 components. ©Copyright SAP AG.

Once these components are activated or added to the SAP system they become subject to patch and change management. The implementation of Support Packages to an SAP ECC 6.0 system can be quiet complex. Therefore, SAP has decided to help administrators in this task by supplying tools. Both the SAP Maintenance

Optimizer and the SAP SLM (Software Lifecycle Manager) are examples of such tools.

Figure 4.39: mySAP ERP 2005 Business Suite Support Package Stacks.

©Copyright SAP AG.

4.7.8 Tables Used with SPAM

The SAP Patch Manager uses various tables to keep track of progress, status of each step, and history of all applied patch bundles. The tables are in the PAT*-name range:

Table Name Table Description

PAT00 Patch steps

PAT01 Patch status

PAT02 Conflicts between patches and add-ons PAT03 Patch directory

PAT07 Patch prerequisites

PAT09 Patch history

TEPSIN EPS bundle inbox

TIP These tables contain some nice information you can use in case of problems, however, it is strongly recommended not to change the contents of these tables yourself.

4.7.9 SPAM Queue Conflicts

Not all Support Packages can be combined in one single queue for import. The reason for this is caused by the way SPAM works. All import steps are performed in sequential order for all objects in the queue. This means that for all included Support Packages, all objects are first imported into the SAP system. Secondly, all objects are activated and at last all data for these objects is imported. So each step is only executed once, regardless of the number of Support Packages.

However, it is possible that changes or modifications to certain objects are included more than once. Assume we have a table TABX that is modified in SP1 by adding a new field to it. This extra field, however, is removed again in SP2.

Because SP2 is applied after SP1, the table will lack the “new” field. As soon as the TABIM (table import) phase starts, it will first import all SP1-specific data and then import SP2-specific data. The SP1-specific TABIM phase, however, expects this “new” field to be there. So the “INSERT” statement will fail due to a missing table field.

Figure 4.40: Error in TABIM phase due to missing fields.

In this example the error occurs in the TABIM phase, although in most cases the error occurs in the ACT phases when there is an incompatibility between domain definitions, data elements, and table fields.

This can all be prevented upfront by importing all Support Packages in batches, which do not have conflicts. Information about possible conflicts between Support Packages can be found in the relevant OSS notes. Search for the term OCS or OSS to find all these relevant notes.

4.7.10 SAP Download Manager

There are several ways to obtain the Support Packages: (1) using transaction SPAM, (2) by connecting to the OSS SAP system in Walldorf, or (3) by requesting for the so-called OCS Bundle CD-ROMs. In order to save costs on CD-ROM media, SAP has introduced a third source for your OCS bundles: “The Internet.”

The SAP Download Manager is a J2SE (Java 2 Standard Edition) based tool that runs on your PC and connects to SAP through the Internet using HTTPS.

You first need to add the requested OCS packages to the “download basket.”

This basket is part of the OCS Patch area on the SAP Service Marketplace. So first use the “ordinary” Microsoft Internet Explorer Web interface for selecting the packages and add them to the download basket, and use the separate SAP Download Manager to really download them to your PC. With the introduction of NetWeaver 7.0, this process has changed (see Section 4.8).

Figure 4.41: Screen-shot of SAP Download Manager.

Besides Support Packages and kernel patches, entire installation and upgrade kits can be obtained using the SAP Download Manager.

In document Upgrading SAP (Page 72-83)