SAP Support Pack: Accurate, Complete Interrogation and Diagnostics

SAP Support Packs:

After making extensive investments to create a stable, functioning SAP environment, most companies are understandably reluctant to introduce changes, even necessary SAP support packs, because of many associated risks. Documentation is often sparse and testing guidance negligible. Different support packs can be invalidated by improper sequencing, custom changes and other modifications. The availability of skilled personnel to properly perform rigorous regression testing is often limited. Installing periodic support and legal change packs from SAP can destabilize critical production systems.

Companies recognize these risks and it's no wonder that many have a backlog of uninstalled support packs. However, SAP support packs must be installed in order to ensure future performance and serviceability of an SAP environment.

This white paper provides an overview of SAP support packs, associated challenges faced by companies of all sizes and an easy to use application that automates most of the analysis that needs to take place prior to application in the Production environment.

ABAP Support Packs:

ABAP support packs provide patches and updates for the ABAP components of SAP. Each update is designed to be sequentially installed. If you apply support pack 12 without applying all those prior, it will not work. ABAP support packs address a variety of SAP modules, including HR (previously known as legal change patches), Components (BW, APO, etc.) and Add-Ons (plug-ins and third party solutions). In addition, there are ABAP support packs for conflict resolution transports, which are applied when an add-on modifies an object within SAP and causes a conflict with other core objects. Finally, there are ABAP support packs that provide updates to SPAM.

JAVA Support Packs:

Java support packs contain corrections and updates to Java components. They are delivered in the form of Software Component Archives (SCA). Unlike ABAP packs, Java support packs always contain the complete version of the development components for the application and are independent of other support packs. Meaning, only the latest version needs to be applied. Java support packs are applied using the Software Delivery Manager (SDM).

Customers apply a combination of support packs and individual patches when updating the SAP landscape, which can cause conflict if they are not installed in correct sequence. To encourage the concept of timely installations, in 2003 SAP introduced quarterly support pack stacks, which aim to help overcome some of the challenges and risks associated with applying multiple updates.

A support pack stack is a single package of packs and patches that is applied as a single update. Problems within a support pack stack are reduced because the interdependencies of the components should have already been extensively tested by SAP. During SAP's testing, any restrictions or complications are identified and documented as part of installation guidelines. Customer risk is reduced as SAP support packs and patches no longer need to be randomly combined. It also takes less time to apply a support pack stack, which results in less production downtime. SAP has enhanced online support to make it easier to download the support pack stacks.

While this is a helpful improvement, the support pack stack strategy has not eliminated the need for individual packs and patches to resolve specific lifecycle issues, particularly where no work around is available. In addition, each pack or stack contains changes to functionality that the customer isn't likely to use. Finally, packs and patches inevitably affect custom code in ways that SAP cannot anticipate through internal testing.

SAP Support Pack Implementation Tips:

The first step in pack, stack or patch implementation is to review the release notes. While these notes are not complete, they do highlight some of the objects that are contained in the pack, stack or patch. Understanding the affect these objects have on standard and custom functionality is the key to establishing an effective and efficient regression test plan.

Recognize that the application of the support pack is blind: it doesn't inherently look to see if an object to be changed has been already been changed by something else, which results in considerable risk that manually applied OSS notes and customizations will be lost. Therefore, it is essential to confirm if the applied OSS notes are, or are not, a part of the support pack. If not, they may need to be re-applied once the installation is complete.