Applying support packages (SPAM, SAINT)

 Applying Support Packages in SAP Basis is a critical and recurring task for any Basis administrator. It ensures that your SAP system is up-to-date with bug fixes, performance improvements, legal changes, and new functionalities. The primary tools for this are SPAM (Support Package Manager) and SAINT (SAP Add-On Installation Tool).

Here's a detailed breakdown of the process, important steps, and considerations:

Understanding Support Packages, SPAM, and SAINT

• Support Package (SP): A collection of corrections and enhancements for a specific SAP software component (e.g., SAP_BASIS, SAP_APPL, SAP_HR). They address reported bugs, legal requirements, and provide minor functional improvements. Each SP is version-specific and has dependencies on previous SPs.
• Support Package Stack (SPS): A predefined, tested collection of Support Packages for all relevant software components within a specific SAP product version (e.g., SAP ERP 6.0 EHP8 SPS 15). SAP recommends implementing SPSs to ensure consistency and avoid compatibility issues.
• SPAM (Support Package Manager - Transaction SPAM): The tool used to import Support Packages into an ABAP system. It manages the queue of SPs, handles dependencies, and guides you through the import process.
• SAINT (SAP Add-On Installation Tool - Transaction SAINT): The tool used to install and upgrade SAP Add-Ons (e.g., IS-U, APO, CRM, BI Content). SAINT can also manage the import of Support Packages that are prerequisites for or delivered with an Add-On. Essentially, SAINT uses SPAM's capabilities for its core functionality.

Naming Conventions (Examples):

• SPAM/SAINT Update: SAPK<version>SPAM (e.g., SAPK750SPAM0006 for NetWeaver 7.50, SPAM 6).
• SAP_BASIS: SAPKB<release_version><package_number> (e.g., SAPKB7400015 for SAP_BASIS 7.40, SP 15).
• SAP_ABA: SAPKA<release_version><package_number> (e.g., SAPKA7400015 for SAP_ABA 7.40, SP 15).
• SAP_APPL: SAPKH<release_version><package_number> (e.g., SAPKH6050012 for SAP_APPL 6.05, SP 12).
• SAP_HR: SAPKE<release_version><package_number> (e.g., SAPKE6000001 for SAP_HR 6.00, SP 1).

Prerequisites and Planning (Before the Technical Steps)

This is the most crucial phase to ensure a smooth and successful support package application.

1. Understand the Need: Why are you applying SPs? Bug fixes, new functionality, compliance, security?
2. System Landscape: Identify the system (Development, Quality, Production) and instance where SPs will be applied. Always start in DEV, then QAS, then PRD.
3. Maintenance Planner (SAP S/4HANA & Newer Systems):
   • For S/4HANA, Suite on HANA, and newer NetWeaver releases, the Maintenance Planner (MP) is mandatory.
   • It's a cloud-based tool on the SAP Support Portal.
   • You register your systems in an SLD/LMDB and sync this data to MP.
   • MP calculates the required Support Package Stack, considering all dependencies (components, kernel, database, OS).
   • It generates an XML stack file which is then used by the Software Update Manager (SUM) or SPAM/SAINT for the actual import.
   • MP also adds the necessary files to your download basket.
4. Download Support Packages:
   • Go to SAP Support Portal (support.sap.com/patches).
   • Search for the calculated SPS/individual SPs.
   • Download all .SAR files (and .CAR files for older versions). These files are archives containing the actual transport data.
   • SAPCAR utility: Ensure you have the latest SAPCAR utility available on your OS to decompress these files.
5. Disk Space:
   • Ensure sufficient free disk space in the /usr/sap/trans directory (or the equivalent configured transport directory on Windows/Unix). This is where the uncarred packages (.PAT, .ATT files) and transport logs reside.
   • Ensure enough space in the database (particularly for PSAPTEMP and rollback segments/undo tablespaces).
6. Backup Strategy:
   • FULL DATABASE BACKUP: Absolutely mandatory before starting. This is your lifeline if anything goes wrong.
   • SAP Profile Backup: Back up instance and start profiles.
   • Kernel Backup: Back up the current kernel (exe directory).
7. System Health Check:
   • No Open Transports: Ensure no unreleased transport requests are in the system, especially for Workbench objects. SPDD and SPAU adjustments require open transports to record changes.
   • No Active Users (except Administrator): Log off all users from client 000 and other relevant clients.
   • Stop Background Jobs: Temporarily stop all scheduled background jobs (SM37).
   • Check SM13 (Update Requests): Ensure no pending update requests.
   • Check SM21 (System Log): Resolve any critical issues.
   • Check ST22 (ABAP Dumps): Resolve any recent dumps.
   • Check Transport Queue (STMS_IMPORT): Ensure no imports are running or stuck. The system must be in a stable state.
   • RDDIMPDP Job: Ensure the RDDIMPDP background job is running in client 000 (SM37). This job is crucial for triggering post-import methods. If not scheduled, schedule it via SE38 -> RDDNEWPP.
   • Kernel Update: It's often recommended to update the kernel to the latest compatible patch level before applying SPs, as some SPs may require a minimum kernel version.
8. User Authorizations: Log on to Client 000 with a user having SAP_ALL or equivalent Basis administrator (DDIC/SAP*) authorizations. Support packages must always be applied in client 000.

II. Applying Support Packages using SPAM / SAINT - Step-by-Step

A. Initial Setup and Preparation

1. Login to Client 000: Use DDIC or SAP* (if SAP* is enabled) or your Basis user with SAP_ALL.
2. Uncar Support Package Files:
   • Copy all downloaded .SAR files to the usr/sap/trans/EPS/in directory (or the in subdirectory of your transport directory).
   • Navigate to this directory at the OS level.
   • Use the SAPCAR command to uncar them:
     Bash

     sapcar -xvf <package_name>.SAR
     

     This will extract .PAT and .ATT files into the same directory. Alternatively, newer SPAM versions can uncar directly from the EPS/in directory after loading.

B. Update SPAM/SAINT Tool Itself

This is a mandatory step before any major SP application, as SAP regularly updates these tools with new functionalities and bug fixes.

1. Download the latest SPAM/SAINT Update package from the SAP Support Portal (e.g., SAPK-xxxxYSAPBASIS.SAR).
2. Uncar it into usr/sap/trans/EPS/in.
3. Go to SPAM transaction.
4. From the menu, choose "Support Package" -> "Import SPAM/SAINT Update".
5. Confirm the import. SPAM will update itself and restart. Verify the new SPAM version in the status bar or via "Help -> About Support Package Manager".

C. Load Support Packages into SPAM Buffer

1. Go to SPAM (or SAINT for Add-Ons).
2. From the menu, choose "Support Package" -> "Load Packages" -> "From Application Server".
   • (Alternatively, "From Front End" for smaller packages, but "From Application Server" is recommended and necessary for large packages).
3. SPAM will read the EPS/in directory and load the packages into its internal buffer. You should see a list of available packages.

D. Define the Support Package Queue

1. Click "Display/Define" button (or F6).
2. SPAM displays a list of installed software components (e.g., SAP_BASIS, SAP_ABA, SAP_APPL).
3. Select the desired Software Component (e.g., SAP_BASIS).
4. SPAM will automatically propose a queue based on the loaded packages and existing system levels. It considers dependencies and applies packages in the correct order.
   • Crucial: Review the proposed queue carefully. Ensure it includes all necessary packages for your target SPS level and that there are no gaps.
   • If you're applying an SPS, ensure all components of that stack are included.
5. If the queue is correct, click "Confirm Queue".
   • SPAM checks for prerequisites (dependencies, open repairs, etc.). If any issues are found, it will stop and display an error. Resolve these before proceeding.

E. Import the Queue

1. Once the queue is defined and confirmed, click "Import Queue" button (or F7).
2. A dialog box will appear allowing you to select Start Options.
   • Test Import: (Recommended before actual import in DEV). Performs all checks but doesn't actually import data. Useful for identifying potential issues (e.g., objects in open repair) beforehand.
   • Import in Background: Recommended for large queues. The import runs as a series of background jobs (check SM37 for RDDIMPDP and related jobs).
   • Downtime-Minimized Import: (Requires specific setup and careful planning, usually for very large stacks or upgrades). It tries to import as much as possible during system uptime, reducing the actual downtime. This involves "Inactive Import" and "Active Import" phases. Not the default for routine SP application.
   • No. of Background Processes: You can define how many background processes SPAM can use for the import. Default is usually sufficient, but can be increased for faster imports if resources allow.
3. Click "Continue" to start the import.

F. Monitoring the Import Process (Phases)

SPAM/SAINT imports support packages in distinct phases. The status bar will show the current phase. You can also view logs (see section III).

Key Phases (Simplified):

• Preparation Module: Checks authorizations, system requirements, unpacks files, adds to buffer, schedules RDDIMPDP.
  • PROLOGUE: Authorization check.
  • CHECK_REQUIREMENTS: Basic system checks (e.g., tp connection).
  • DISASSEMBLE: Unpacks .PAT, .ATT files.
  • ADD_TO_BUFFER: Adds packages to transport buffer.
  • TEST_IMPORT: Performs a test import to identify conflicts.
• Import 1 Module: Imports object lists, DDIC objects.
  • CREATE_VERS_BEFORE: Creates versions of objects before modification (if enabled).
  • SPDD_SPAU_CHECK: Checks if SPDD/SPAU adjustments are required.
  • DDIC_IMPORT: Imports ABAP Dictionary objects.
  • RUN_SPDD_?: STOP POINT! If modifications exist for DDIC objects, SPAM pauses and prompts you to perform SPDD adjustments.
    • Log in to client 000, run SPDD. Adjust or reset modified DDIC objects. Crucial to do this correctly, as errors here can lead to system instability.
    • Once done, confirm in SPDD, then in SPAM.
• Import 2 Module: Imports repository objects, executes XPRAs, activates objects.
  • DDIC_ACTIVATION: Activates the imported DDIC objects.
  • IMPORT_PROPER: Imports Repository objects and table entries.
  • XPRA_EXECUTION: Executes after-import methods (ABAP programs that run after import, e.g., to adjust data).
• Clean Up Module: ABAP generation, SPAU adjustments, cleanup.
  • ABAP_GENERATION: Generates runtime objects for imported ABAP programs and screens. This can be time-consuming.
  • RUN_SPAU_?: STOP POINT! If modifications exist for Repository objects, SPAM pauses and prompts you to perform SPAU adjustments.
    • Log in to client 000, run SPAU. Adjust or reset modified Repository objects.
    • Once done, confirm in SPAU, then in SPAM.
  • EPILOGUE: Final checks and completion.

G. Confirm the Queue

1. After the import is finished, SPAM's status will turn yellow, indicating that the queue needs confirmation.
2. Go to "Support Package" -> "Confirm Queue".
3. This finalizes the import and updates the system's component levels. The status should turn green. It is essential to confirm the queue; otherwise, you cannot apply future support packages.

III. Post-Import Activities

1. Check Logs:
   • Import Log: SPAM -> GoTo -> Import log -> Queue. This provides a detailed log of all phases and any errors/warnings.
   • Action Log: SPAM -> GoTo -> Action log. Provides a more detailed breakdown of actions within each phase.
   • SM21 (System Log): Check for any critical messages during the import time.
   • ST22 (ABAP Dumps): Check for any new short dumps.
   • ST11 (Developer Traces): If a specific phase or program failed, check relevant dev_w* traces.
2. Kernel Update (if applicable): If the SPS or new functionality requires a specific kernel patch, perform the kernel update now.
3. ABAP Load Generation:
   • After major SP applications, it's good practice to regenerate ABAP loads (programs, screens) to optimize performance.
   • Run SGEN transaction. Select "Generate all objects of selected software components." Select the components you updated.
   • Run this as a background job during off-peak hours as it can be very CPU intensive.
4. Database Statistics:
   • Update database statistics (DB02/DB20) after major object changes to ensure the optimizer has accurate information for query execution.
5. Test System Functionality:
   • Basis Tests: Verify STMS, SM50, SM66, SM21, ST22, RFC connections, print functionality.
   • Functional Tests: Critical business processes must be thoroughly tested by functional teams in all impacted clients. Focus on areas related to the applied SPs.
   • Interface Tests: If interfaces are impacted.
   • Authorization Tests: If authorization objects were changed.
6. Client-Specific Regenerations: For certain components (e.g., BW, CRM), client-specific regenerations or post-processing steps might be required as per SAP notes.
7. Documentation: Document the entire process, including start/end times, any issues encountered, and the final status.

IV. Important Configuration Parameters / Settings in SPAM

While SPAM doesn't have many direct "configuration parameters" in the traditional sense, there are critical settings and considerations:

1. "Extras -> Settings" Menu in SPAM:
   • Import Queue Tab:
     • Import mode: Standard / Downtime-minimized: As discussed, choose based on your project requirements. Standard is default.
     • Generate ABAP loads: Controls when ABAP loads are generated (e.g., "Always," "During import," "Never"). "Always" is generally recommended to ensure all programs are in a consistent state.
     • Create transport request for SPAU/SPDD: Ensures that adjustments made in SPDD/SPAU are recorded in a transport request, allowing them to be transported to subsequent systems. This should always be active in development systems.
   • Package Attributes Tab: Allows you to view details of packages.
   • Log Files Tab: Configures logging behavior (usually default is fine).
   • User/Password for SAP Support Portal: (Legacy, usually not used now as Maintenance Planner handles download basket).
2. Profile Parameters:
   • While not directly SPAM parameters, sufficient work processes (especially background rdisp/wp_no_btc) and memory parameters (abap/heap_area_total, ztta/roll_area, rdisp/ROLL_MAXFS, rdisp/PG_MAXFS) are crucial for SPAM to run smoothly, especially during phases like ABAP_GENERATION. Adjust them via RZ10 if necessary before starting the import.
3. usr/sap/trans Directory Permissions: The SAPService<SID> user (Windows) or <sid>adm user (Unix/Linux) must have full read/write/execute permissions to this directory.
4. Database Connection: Ensure a stable and healthy database connection.

V. Special Considerations for Various SAP Basis Components

While the general process is the same, specific components might have nuances:

• SAP_BASIS & SAP_ABA: These are core components. They usually contain many objects and can take a long time to import. Their updates often require SPDD/SPAU adjustments. They are usually updated together as part of an SPS.
• SAP_APPL (Application Component): Contains the core functional modules. Can also be large and require SPDD/SPAU.
• SAP_HR (Human Resources): Often has legal changes. May involve specific post-import reports or adjustment requirements related to payroll or time management. Check specific HR notes.
• SAP_BW (Business Warehouse): May require specific post-import steps for BI content activation, data model adjustments, or query regeneration. Consult BW-specific notes.
• Industry Solutions (IS-U, IS-OIL, etc.): These are add-ons. Their support packages are often managed via SAINT and may have complex dependencies or require specific activation/deactivation steps. Conflict Resolution Transports (CRTs) might be needed if there are conflicts with other add-ons.
• PI_BASIS, ST-PI, ST-A/PI: These are common "plug-in" components for Solution Manager connectivity and monitoring. They usually have fewer complexities but still follow the standard SPAM process.

VI. Troubleshooting Common Issues

• Error in PROLOGUE / CHECK_REQUIREMENTS: Usually authorization or tp connectivity issues. Check SM21, STMS, tp logs.
• SPDD_SPAU_CHECK / RUN_SPDD_? / RUN_SPAU_? errors: Indicates pending modification adjustments. You must perform SPDD/SPAU at the prompted phases. Do not bypass these.
• Phase XPRA_EXECUTION errors: An after-import method (XPRAs) failed. Check the import log for the specific XPRA program and its error message. This usually requires ABAP developer intervention or an SAP Note.
• Transport Stuck/Hanging: Check SM37 for RDDIMPDP job, SM50/SM66 for tp processes, and OS-level resources (usr/sap/trans space/permissions, network).
• Memory-related Dumps (TSV_TNEW_PAGE_ALLOC_FAILED): Occurs often during ABAP_GENERATION. Increase relevant memory parameters (e.g., abap/heap_area_total, rdisp/PG_MAXFS).
• Component already at a higher level: You cannot apply an older SP on top of a newer one. Re-check your queue and download process.
• Missing Prerequisites: SPAM will usually stop if a required lower-level SP is missing. Ensure your stack is complete.

Applying Support Packages is a meticulous process that demands careful planning, execution, and thorough testing. Always refer to the latest SAP notes and guides for your specific release and SPS, as best practices and tool functionalities evolve.