saptutorials in Blog

SPDD and SPAU in SAP Upgrade Projects: A Guide for Smooth Transitions

SAP upgrades involve several critical steps, but two of the most important transactions are SPDD and SPAU. These transactions deal with changes in dictionary and repository objects during an upgrade. Knowing when and how to use them can prevent significant disruptions and ensure your system operates smoothly after the upgrade. This blog will dive into the technical details and best practices surrounding SPDD and SPAU.

Table of Contents

Toggle

What is an SAP Upgrade?

SAP upgrades come in two primary forms:

Technical Upgrade: Focuses on upgrading the system software while keeping functionality unchanged.
Functional Upgrade: Adds new functionalities or improves existing ones.

While the Basis Team generally handles the system preparation, technical stack upgrade, and overall system upgrade, the ABAP and Functional Teams are involved in the crucial phases of SPDD and SPAU.

Critical Phases in an Upgrade Process

The upgrade process typically follows these steps:

System Preparation and Stack Level Patch Upgrade—Handled by the Basis team.
SPDD Phase – Managed by ABAP and Functional teams.
Upgrade of the System—Managed by the Basis team.
SPAU Phase – Managed by ABAP and Functional teams.
DBACOCKPIT for Indexing – Involves both ABAP and Functional teams for issue resolution and error tracking.
Custom Program Corrections – Ensures corrections in obsolete function modules and other objects.
SPDD Phase: Managing Dictionary Objects
The SPDD transaction deals with dictionary objects like tables, structures, and views. When upgrading a system, such as from CRM 4.0 to CRM 7.0, the SPDD transaction compares these dictionary objects between the old and new systems.

The comparison happens under two main categories:

With Modification Assistant: Displays modification logs and allows users to track and manage changes.

Without Modification Assistant: Does not maintain modification logs, requiring manual inspection of changes.

Steps for Handling SPDD:

Accessing Object Comparison: Click on each object in SPDD, which will take you to SE11 (SAP’s Data Dictionary). From here, use Utilities → Versions → Version Management to compare different object versions.

Version Comparison: You will compare the current SAP version with previous or modified versions. In most cases, this involves comparing two versions—the latest SAP version and the modified version from your previous system.

Delta Comparison: SAP offers a ‘Delta Comparison’ to easily view changes between the two versions. This feature highlights the differences and helps developers decide whether to keep SAP’s version or retain modifications made in the previous system.

Reset to Original vs. Adapt Modification:

Reset to Original: If a developer opts for “Reset to Original,” the system will overwrite custom changes with the SAP standard.

Adapt Modification: Retaining custom modifications can sometimes result in conflicts with the upgraded system. For instance, if SAP adds new fields, but the system uses the modified version, the absence of those fields could cause a short dump.

Best Practice: Always analyze whether the custom modifications are still necessary or if resetting to the SAP standard will prevent issues in the upgraded environment. For example, in the case of tables like MARA, where new fields may be added, it’s often advisable to reset to the SAP version to prevent errors.

SPAU Phase: Handling Repository Objects

While SPDD deals with dictionary objects, the SPAU transaction handles repository objects, such as programs, reports, screens, and messages. SPAU is crucial for ensuring that custom changes made in the previous system don’t conflict with the new SAP version.

Key Steps in SPAU:

Object Comparison: Like SPDD, you start by comparing objects through Version Management. Decide whether to Reset to Original or Adapt Modification based on the differences observed.

Code Adaptation in Without Modification Assistant Objects: For repository objects such as function modules and programs, SPAU provides an empty space where developers can write custom code. This is known as “Adapt Modification,” and it allows you to retain your custom logic while merging it with the latest SAP code.

Modifications in With Modification Assistant Objects: In this case, SPAU offers a greyed-out program code where developers can insert, delete, or modify code by pressing relevant buttons, similar to modifying standard SAP code with an access key.

Timely Processing: SAP allows about 15-20 days to complete SPAU activities before locking the objects. After this period, you’ll need an access key to modify the objects further.

Best Practice: Complete all SPAU activities within 10-15 days to avoid delays or complications requiring an access key. Also, as a general recommendation, use only one transport request for all SPAU objects to simplify the process.

Case Study: Managing SPDD and SPAU in a Real-World SAP Upgrade

In a recent CRM upgrade project from version 4.0 to 7.0, the ABAP team encountered a situation where a table in SPDD had two new fields in the latest SAP version. After careful analysis, they decided to reset the table to SAP’s standard (using the “Reset to Original” option) rather than keeping the custom version. This decision was made to prevent short dumps, which could have occurred if the system tried to read or write to the new fields not in the custom version.

During the SPAU phase, custom reports required modification. The team used the “Adapt Modification” function to integrate custom business logic with SAP’s new code, ensuring that custom functionality remained intact without causing errors in the upgraded system.

By following best practices and adhering to the time window, the team successfully completed both SPDD and SPAU phases without encountering access key issues, ensuring a smooth and error-free upgrade.

Conclusion

SPDD and SPAU are two of the most critical transactions during an SAP upgrade. SPDD handles dictionary objects, while SPAU focuses on repository objects. Ensuring that these transactions are processed correctly will prevent system errors and ensure smooth functionality after the upgrade. By following the steps outlined above, and incorporating lessons learned from real-world projects, teams can efficiently manage the complexities of an SAP upgrade.

Key Takeaways:

Always compare versions and analyze the impact of resetting to the SAP standard versus retaining custom modifications.
Complete the SPAU phase within 10-15 days to avoid the need for access keys.
Use a single transport request for all SPAU changes to streamline the process.
These practices will lead to a more manageable upgrade process, minimizing disruptions and ensuring that custom developments remain functional after the upgrade.

You might also like the below articles.

saptutorials: We are a group of SAP Consultants who want to teach and make studying tough SAP topics easier by providing comprehensive and easy-to-understand learning resources.