S/4HANA Clean Core
Architect / Cross-trackAdvanced

SAP Clean Core Risks: Modifications, Enhancements and Unreleased APIs (Part 7)

Key takeaway

Identify the highest Clean Core risks by dependency type: direct SAP modifications, implicit source enhancements, unreleased APIs and direct writes to standard tables create more upgrade exposure than custom-code volume alone.

Explanation

Clean Core risk is primarily about how custom code depends on SAP internals. A direct modification to an SAP-owned object is high risk because upgrades can overwrite or conflict with the changed source. Implicit enhancements are less invasive than modifications but can still depend on private variables and source positions that SAP may change.

Unreleased classes, function modules or CDS objects are another major risk. They may work technically but carry no stable compatibility contract for external custom consumption. Direct INSERT, UPDATE or DELETE on standard application tables is especially dangerous because it bypasses validations, change documents, locks and dependent updates.

Risk assessment should therefore record dependency type, productive usage, business criticality and change frequency. A heavily used object on released APIs may be safer than a tiny rarely touched enhancement in an internal standard include.

Remediation options include standard configuration, released BAdIs, released APIs, RAP or ABAP Cloud extension points, or side-by-side BTP architecture.

Where no supported alternative exists, document the exception and regression-test it explicitly during upgrades rather than pretending the risk is absent.

Code example

ABAP Code
"High-risk patterns"- SAP standard modification"- undocumented implicit enhancement"- direct write to SAP standard table"- unreleased FM/class/CDS dependency"- coupling to internal table structure "Target patterns"- configuration"- released BAdI/API/CDS"- ABAP Cloud extensibility"- side-by-side released integration

Real project scenario

A pricing implicit enhancement depended on a local standard variable whose meaning changed during an upgrade. The enhancement still activated but produced incorrect results, illustrating source-coupling risk.

Common mistakes

  • Measuring Clean Core by number of Z objects.
  • Treating implicit enhancement as upgrade-safe by definition.
  • Using unreleased APIs because they are visible in ADT.
  • Writing standard tables directly.
  • Leaving unavoidable risks undocumented.

Best practices

  • Classify dependencies, not just objects.
  • Eliminate direct standard-table writes.
  • Prefer released contracts.
  • Document unavoidable exceptions.
  • Regression-test high-risk areas every upgrade.

Interview angle

Explain which custom-code patterns create the greatest Clean Core risk and why released contracts matter more than object count.

Practice this lesson

Quick check

1. In the lesson "Clean Core Risk: Modifications, Implicit Enhancements and Unreleased Objects", consider this project situation: A pricing implicit enhancement depended on a local standard variable whose meaning changed during an upgrade. Which statement is correct?

2. Which custom code pattern is high risk for Clean Core?

3. Why are unreleased SAP objects risky in custom code?

Interview questions

1. Using this SAP project situation — A pricing implicit enhancement depended on a local standard variable whose meaning changed during an upgrade — explain Clean Core Risk: Modifications, Implicit Enhancements and Unreleased Objects. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

2. ATC shows usage of unreleased SAP objects in custom code. What would you do?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics