Explain SAP Support Packages, Kernel Upgrades & SPAU/SPDD in SAP

19 / 65

Basisintermediate

SAP Support Packages, Kernel Upgrades & SPAU/SPDD

Applying software maintenance (support packages, kernel patches) and resolving modification conflicts during upgrades.

SAP delivers corrections in three sizes, and they are applied by different tools with different risk.

Applying a support package is like your phone getting an OS update - if you never modified the phone's system files it installs cleanly, but if you rooted it and hand-edited system files yourself, the update installer stops and asks you, file by file, whether to keep your hack or take Apple's new version.

Key Concepts

    SAP Note        one specific fix          SNOTE      lowest risk
    Kernel patch    the executable layer      OS level   low risk, quick
    Support package a bundle of corrections   SPAM       higher risk, planned

The kernel is not ABAP. It is the C executable layer underneath — the runtime, database connectivity, operating system interaction. It is patched independently and more often, usually by replacing files and restarting, and it is generally the least disruptive of the three.

SNOTE is the first response to a known bug. When you hit an SAP bug and find the Note, SNOTE applies that correction now, rather than waiting for the support package containing it. It also records which Notes are applied, so the next support package knows what to supersede.

SNOTE

Support packages come per software component — SAP_BASIS, SAP_APPL and others — and are applied with SPAM, in a stack whose components must be at compatible levels.

SAP_BASISSAP_APPLSPAM

The genuinely hard part: modification adjustment. If somebody changed an SAP standard object, and SAP's new version also changes that object, the two must be reconciled by hand.

    SPDD   dictionary objects — during the upgrade, before the
           database is adjusted
    SPAU   everything else: programs, function modules, screens —
           after the technical upgrade

The order is not arbitrary. SPDD comes first because table structures must be consistent before the database conversion runs. Handling a dictionary conflict wrongly at that point can cost data, which is why that phase is on the critical path and done carefully.

SPDD

For each conflicting object you decide: keep the modification, take SAP's new version, or merge the two by hand. Taking SAP's version is usually right unless the modification exists for behaviour SAP's change does not provide.

Why this is the question that shows experience. The effort in SPAU scales directly with how many SAP objects were modified. A system with clean enhancements — BAdIs, customer exits, enhancement points — has almost nothing to adjust. A system where developers edited standard code for ten years has hundreds of conflicts, each needing a developer who understands why the change was made.

SPAU

That backlog is often the reason an upgrade is postponed for years, and the postponement makes it worse.

So the real answer to "how do you handle SPAU" starts earlier: do not modify standard objects. Every modification is a debt payable at every upgrade, by someone who may not know why it exists.

On the planning side, modification adjustment sits inside the downtime window, so its size is a project scheduling question, not just a technical one. That is why upgrade projects begin by counting modifications.

What the interviewer is probing.1. "What are SPDD and SPAU for?" Probing: the purpose. Stalls: "Adjustments." Moves up: SPDD adjusts modified dictionary objects during the update and SPAU adjusts modified repository objects after — both exist only because of modifications.

2. "Why is a kernel upgrade usually low risk?" Probing: the distinction. Stalls: "It is high risk." Moves up: it replaces executables without touching the database content, so it is reversible by swapping the kernel back.

3. "What is the order of a maintenance window?" Probing: planning. Stalls: "Apply and test." Moves up: backup, apply in development, adjust modifications, transport and test through the landscape, then production with a rollback plan.

4. "What does the maintenance planner do for you?" Probing: tooling. Stalls: "Nothing." Moves up: it calculates a consistent stack of component versions and produces the download, which avoids an incompatible combination.