OOP ABAP Part 10: OOP in S/4HANA, RAP and Clean Core

📌 KEY POINTS
✅ In S/4HANA, extensions are object-oriented: BAdIs are interfaces, RAP behaviour is implemented in classes, and released APIs are classes/interfaces.
✅ Clean core: use released objects (C1 contract) and wrap unreleased functionality in your own class when needed.
✅ RAP behaviour pools are global classes with local handler classes (lhc_…) and saver classes (lsc_…).
⚠️ In ABAP Cloud (language version 5), classic FORMs, WRITE lists, direct SAP table access and unreleased FMs are not allowed.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–9 built OOP skills. This lesson connects them to what you meet in S/4HANA projects today — while classic ECC and on-premise code still runs in the same system.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 1. BAdIs = INTERFACES\nA new BAdI implementation (SE19/ADT) is a class implementing the BAdI interface (IF_EX_… classic, IF_BADI_… new). The framework instantiates it (GET BADI / CALL BADI). Everything from Part 3 and 8 applies: interfaces, factories, polymorphism.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 2. RELEASED APIs AND WRAPPERS\n• SAP marks objects as released (API state C1 for use in cloud development).

• In ABAP Cloud you may use only released CDS views, classes and interfaces (e.g. XCO library, CL_ABAP_CONTEXT_INFO instead of sy-uname in some cases).
• If you need unreleased functionality on-premise, create a wrapper class in a classic (standard ABAP) package, release it yourself for your cloud-ready code, and keep the dependency in one place.

━━━━━━━━━━━━━━━━━━━━
▶ 3. RAP BEHAVIOUR POOLS

• The behaviour definition points to a class ZBP_…; its global part is empty.
• Local classes inside it: lhc_booking INHERITING FROM cl_abap_behavior_handler with methods FOR VALIDATE, FOR DETERMINE, FOR MODIFY (actions); lsc_booking INHERITING FROM cl_abap_behavior_saver for save.
• Business logic can live in separate reusable classes called from the handlers — classic OOP design inside RAP.

━━━━━━━━━━━━━━━━━━━━
▶ 4. CLEAN ABAP FOR CLASSES

• Small classes with one responsibility; FINAL by default.
• Prefer instance methods and interfaces; inject dependencies.
• Raise exceptions, don't return error codes.
• Use meaningful names; avoid Hungarian prefixes overload (team decision).
• ATC with the cloud readiness / clean core checks.

━━━━━━━━━━━━━━━━━━━━
▶ 5. CLASSIC CODE IN S/4HANA ON-PREMISE
Existing reports, FORM-based exits and FMs still run. New code: classes; changed code: refactor step by step (move logic into classes, keep the old entry points). Tier model: tier 1 cloud-ready, tier 2 wrappers, tier 3 classic (to be reduced).

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Open a RAP behaviour pool (ZBP_…) and identify lhc_ and lsc_ classes.
2. Implement a BAdI and note the interface it implements.
3. Create a wrapper class for an unreleased FM, as in the code example.

✅ CHECKPOINT: you can see where your OOP knowledge fits in S/4HANA extension and RAP development.

During an S/4HANA conversion, a team wanted new approval logic to be cloud-ready, but it needed material texts read by an unreleased function module. Calling the FM directly would have failed the clean core ATC checks for the new package.
They created a wrapper class ZCL_MATERIAL_READER with an interface in a classic package and used only the interface in the new RAP-based approval logic. When SAP later released a CDS view for material texts, only the wrapper implementation changed.

• Calling unreleased SAP objects directly from cloud-ready code.
• Putting all business logic inside RAP handler methods.
• Treating BAdI implementations as places for huge procedural code.
• Ignoring ATC clean core findings.
• Rewriting all classic code at once instead of step by step.

• Use released APIs; wrap unreleased ones in a single class.
• Keep RAP handlers thin; call reusable classes.
• Apply Clean ABAP: small FINAL classes, interfaces, exceptions, DI.
• Run ATC with cloud readiness checks.
• Refactor classic code gradually behind stable entry points.

Questions: "How is OOP used in S/4HANA and RAP?", "What is a wrapper class in clean core?", "What is not allowed in ABAP Cloud?"
Strong answer: BAdIs are interfaces implemented by classes; RAP behaviour pools use local handler/saver classes inheriting from CL_ABAP_BEHAVIOR_HANDLER/SAVER; clean core uses released APIs, and unreleased functionality is wrapped in own classes (tier 2); ABAP Cloud forbids unreleased objects, WRITE lists, dynpros and direct SAP table access; business logic in reusable classes.