Clean core, RAP and SAP BTP

What clean core means

ECC customisations (modifications, exits, direct table reads) turned every upgrade into a repair project. Clean core keeps S/4HANA standard and builds extensions only on released interfaces, in ABAP Cloud (an ABAP version that allows only released objects) or on SAP BTP. SAP's clean-core level model has been revised; check the current guide before quoting it.

Choosing the extension option

MDG keeps its own frameworks (data model, BRFplus, BAdIs such as USMD_RULE_SERVICE). Clean core doesn't remove them: use released interfaces where they exist and document where they don't.

Try it: which extension tier?

The RAP stack

The ABAP RESTful Application Programming Model (RAP) adds behavior (create, update, validations, determinations, actions) to CDS views, with locking, drafts and authorisation from the framework. Managed RAP writes the table for you; unmanaged wraps existing save logic. Read an unfamiliar object in order: data model, behavior, projection, service.

A behavior definition, read slowly

A small custom object that tracks data-quality issues found by the lesson 3-1 views:

• managed: the framework does create, update, delete and the DB writes.
• validation … on save: rejects bad data before commit, like an MDG check rule.
• determination … on modify: derives values, like an MDG derivation.
• action: a named operation exposed to the UI and the API.

managed implementation in class zbp_i_dqissue unique;
strict ( 2 );

define behavior for ZI_DQIssue alias DQIssue
persistent table zdq_issue
lock master
authorization master ( instance )
{
  create; update; delete;
  field ( readonly, numbering : managed ) IssueUUID;
  field ( mandatory ) BusinessPartner, IssueType;
  validation validateBusinessPartner on save { create; field BusinessPartner; }
  determination setStatusNew on modify { create; }
  action markResolved result [1] $self;
}

Try it: call the object with EML

Code inside the system uses EML (Entity Manipulation Language) instead of direct table updates, so the same validations and authorisation checks run as in the UI.

______COMMIT ENTITIESCREATEINSERT INTOUPDATEMODIFY ENTITIESCOMMIT WORKREAD ENTITIESFAILED OF zi_dqissue
  ENTITY DQIssue
    ______COMMIT ENTITIESCREATEINSERT INTOUPDATEMODIFY ENTITIESCOMMIT WORKREAD ENTITIESFAILED FIELDS ( BusinessPartner IssueType )
    WITH VALUE #( ( %cid            = 'issue1'
                    BusinessPartner = '1000123'
                    IssueType       = 'TAX_MISSING' ) )
  MAPPED   DATA(mapped)
  ______COMMIT ENTITIESCREATEINSERT INTOUPDATEMODIFY ENTITIESCOMMIT WORKREAD ENTITIESFAILED   DATA(failed)
  REPORTED DATA(reported).

______COMMIT ENTITIESCREATEINSERT INTOUPDATEMODIFY ENTITIESCOMMIT WORKREAD ENTITIESFAILED.

Classic versus clean-core habits

SAP BTP around S/4HANA and MDG

SAP BTP hosts side-by-side extensions: the ABAP environment (with a free trial), SAP Build, Integration Suite, and AI services such as AI Core, the generative AI hub and Joule. MDG cloud edition runs there too. Names and bundles change often; confirm on SAP's BTP pages.

Why this changes the MDG role

An agent that helps stewards never writes to BUT000. It reads through a CDS-based OData service and submits fixes through a RAP action or MDG change request, so validation, approval and audit still apply. Designing these doorways is the technical MDG job ahead.

Try it: give the agent access

Check yourself