Released APIs vs Direct Table Access

Explanation

In ECC custom code, developers often read or update SAP tables directly. In S/4HANA Clean Core design, released APIs and released views are preferred because SAP can keep them stable across upgrades. Direct table access may still exist in on-premise support, but it should be reviewed carefully, especially when tables are replaced by compatibility views, data model changes or new business APIs. For write operations, direct updates to SAP standard tables should be avoided. Use released APIs, BAPIs, RAP BOs or business services where available. Clean Core means reducing fragile dependencies on SAP internal implementation.

Code example

* Weak Clean Core pattern:* Direct update to SAP standard table is risky and usually not acceptable.* It can bypass business checks, authorization, locks and update logic. UPDATE vbak  SET zz_status = 'A'  WHERE vbeln = lv_vbeln. * Better pattern:* Use released API/BAPI/service class if available.* This preserves business validation, locks and standard update flow. DATA(lo_order_service) = NEW zcl_released_order_api_wrapper( ). lo_order_service->update_order_status(  EXPORTING    iv_vbeln  = lv_vbeln    iv_status = 'A'  IMPORTING    et_return = DATA(lt_return) ). IF line_exists( lt_return[ type = 'E' ] ).  * Return controlled error to caller instead of corrupting data.ENDIF.

Real project scenario

A custom program directly updated a status field in a standard table. During S/4HANA conversion, the team replaced it with a released business API so future upgrades would not break the process.

Common mistakes

- Directly updating standard tables. - Using unreleased function modules without review. - Assuming ECC table access is safe in S/4HANA. - Ignoring standard locks and validations.

Best practices

- Prefer released APIs for write operations. - Use released CDS views for read scenarios where possible. - Avoid direct standard table updates. - Document unavoidable direct access with risk.

Interview angle

Interviewers may ask why direct table update is bad. Mention upgrade risk, bypassed checks, data consistency and released APIs.