Architect / Cross-trackAdvanced

SAP Clean Core: Released APIs vs Direct Table Access (Part 5)

Key takeaway

Use released business APIs and CDS contracts instead of direct dependencies on SAP internal tables for new clean-core development, especially for updates where direct writes bypass application integrity.

Explanation

Direct table access couples custom code to SAP's persistence implementation. For reads, that can break when S/4HANA changes the storage model or moves semantics behind compatibility views or new business entities. For writes, direct INSERT, UPDATE or DELETE is far more dangerous because it bypasses authorization, locks, validation, change documents and dependent updates.

Released APIs, released CDS entities, BAdIs and RAP contracts provide a supported compatibility boundary. SAP can change internals while preserving the public contract according to the release model.

This does not mean every historic SELECT from an SAP table must be rewritten immediately. Brownfield remediation should consider usage, risk and whether a released alternative exists. New ABAP Cloud development, however, intentionally restricts access to released objects.

For business-object updates, always prefer the owning application API. A custom field physically stored on a standard table does not make direct table UPDATE a valid business operation.

When no released contract exists, document the gap and choose a governed extension or integration approach instead of silently creating an unsupported dependency.

Code example

ABAP Code

"Risky standard-table update"UPDATE vbak SET zz_status = 'A' WHERE vbeln = lv_vbeln. "Preferred patternDATA(lt_return) = zcl_released_order_api_wrapper=>update_status(  iv_vbeln  = lv_vbeln  iv_status = 'A' ). IF line_exists( lt_return[ type = 'E' ] ).  "Return controlled business errorENDIF.

Real project scenario

A custom program directly updated a standard order status field and left dependent processing inconsistent. Replacing it with the supported business API restored standard validations and change flow.

Common mistakes

Writing standard application tables directly.
Assuming a table read is a stable API.
Replacing all legacy reads without prioritizing risk.
Wrapping an unreleased internal FM and calling it clean core.
Ignoring authorization and locks when bypassing the application layer.

Best practices

Use released APIs for business operations.
Prefer released CDS for new read models.
Never directly update standard application tables.
Prioritize brownfield remediation by risk.
Document gaps where no released contract exists.

Interview angle

Explain why released contracts are more upgrade-stable than direct table access and why writes are especially risky.

Practice this lesson

Quick check

1. A review finds this recurring pattern around Released APIs vs Direct Table Access: "Ignoring standard configuration." Which principle should the team adopt?

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

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

Interview questions

1. Using this SAP project situation — A custom program directly updated a standard order status field and left dependent processing inconsistent — explain Released APIs vs Direct Table Access. 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. Using this SAP project situation — A company completed an S/4 migration with strict clean-core rules, but two years later dozens of new direct-table integrations had appeared — explain Clean Core Governance and Documentation. 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.

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.