Demo project — fictitious code, with the engine’s reading on every stage and no model drafts or test runs. Nothing you do here is saved. A demo run is never signed. No signed run, no audit pack and no export comes out of this screen — a signature says a named account analysed a named source, and none of that happened here.Nothing here counts against your five free analyses: the demo is the same for every account, and what you change lives in this browser only.Try an example or your own code

AnalyzeDesignTransformationDocumentationTestingEconomicsDelivery

Next: Analyze — Reads the code and signs a run — every other figure starts here. The other tools need a signed run first.

What the marks mean:donestartedout of date

DemoRoute proposed

Demo · Z_MM_PO_APPROVAL — Design

In-App (ABAP Cloud) proposed from the evidence. Confirming it here changes this browser and nothing else.

Route

In-app · RAP

Reconstructedconfidence 65

Target context

Not determined

SAP Cloud ERP Private assumed

Released successors

6 · 9 uses

Sign-off

Not confirmed

Target architectureReconstructed· from contract AC-1

click a box to see its evidence

ABAP Cloud on the stackin-app developer extensibility

RAP business objectABAP Cloud · runtime stipulated by the route

Custom tables — customer namespaceZMM_PO_APPR · ZMM_PO_ATTACH · ZMM_VEND_BLOCK · ZMM_DEPT_HEAD · ZMM_NOTIFY_CFG

Released APIs only

SAP S/4HANASAP Cloud ERP Private assumed · the demo has no run to bind it

CLEAN CORE BOUNDARY

ODATAAPI_PURCHASEREQUISITION_SRVEBAN Source line 61 Source line 106 Source line 240 · curated
ODATAAPI_BUSINESS_PARTNERLFA1 Source line 154 · curated
CDSI_SUPPLIERPURCHASINGORGLFM1 Source line 161
CDSI_CostCenterCSKS Source line 192 · curated
CDSI_PurchasingInfoRecordEINA / EINE Source line 254 Source line 262 · curated
CDSI_ProductPlantMARC Source line 274 · curated

Curated mapping compiled for 2024.FPS02, reviewed 2026-10-12; not synced from SAP

No released successorME21N · T16FS · PA0105

OData APICDS viewwritenot determinedclean core boundary

Decision

Where should this code run?

Recommended

Reconstructed

Developer Extensibility (RAP / ABAP Cloud)

Detected 2 write(s) to custom database persistence. In SAP Cloud ERP Private this is on-stack developer extensibility, not a reason to leave the stack: the table is a Dictionary object in the customer namespace and a RAP business object is built on it. Writing to your own table is not a clean core violation — writing to SAP's is. The explicit COMMIT WORK (2×) conflicts with the RAP transaction lifecycle: it has to be removed and the transaction boundary left to the RAP save sequence before the code runs on ABAP Cloud. The 1 direct write(s) to SAP standard tables are not clean core in any edition: each is replaced on-stack by a released write API, a BAPI or a RAP action. The BDC screen automation (1×, from line 515) does not run in ABAP Cloud, and the screens it drives carry no stability contract. It is replaced on-stack by the released API of the same business object; where SAP has released none, by a wrapper around the classic API, released for use in ABAP Cloud, together with an influence request to SAP for a released API. A side-by-side service would need the same released API, so the automation forces no side-by-side split. The frontend file upload (GUI_UPLOAD, from line 129) reads a file from the user's PC: a RAP business object takes a file as a large object (attachment) field from S/4HANA 2022 on, so the upload alone forces no side-by-side split — a side-by-side service needs a requirement the code does not show, such as external users, files arriving from several systems, or a volume the S/4HANA stack should not carry. SAP_WAPI_CREATE_EVENT, BAPI_PO_CREATE1 are classic APIs SAP does not release for ABAP Cloud: on this route their calls are replaced by the released API of the same business object, or kept in classic ABAP behind a wrapper. Part of the program was not read. Include Z_MM_PO_NOTIFY was not uploaded — what it does is not determined. Include Z_MM_PO_LOG was not uploaded — what it does is not determined. Key-user extensibility: 3 of 6 part(s) are key-user candidates (Custom Business Objects (configuration)), each with its limit; 3 stay code, and part of the program was not assessed by the engine. The program splits: only the code part is built.

Confidence 65 — the router’s, not a proof.

Numbered on the canvas

Alternatives at a glance

SAP standardNot determined
Key userRejected on evidence
In-app ABAP Cloud / RAPRecommended
Side-by-side CAPRejected as a setting

Sign-off

Not confirmed. In the demo, confirming is a switch in this browser — no name is recorded, nothing is stored, and it binds no run.

Cover the requirement with SAP standard — build nothingNot determined
Not assessed here. The router can see the code, not the business capability; whether SAP standard already covers the requirement is answered by the standard-coverage analysis against scope items, with its own evidence levels.
Key user extensibilityRejected on evidence
Rejected on the evidence: 26 finding(s) exceed what key-user tooling can express, among them EBAN (line 61), EBAN (line 106), Authorization Check (AUTHORITY-CHECK) (line 116).
Source line 61Source line 106Source line 116
In-app developer extensibility — ABAP Cloud / RAP on the stackRecommended
Detected 2 write(s) to custom database persistence. In SAP Cloud ERP Private this is on-stack developer extensibility, not a reason to leave the stack: the table is a Dictionary object in the customer namespace and a RAP business object is built on it. Writing to your own table is not a clean core violation — writing to SAP's is. The explicit COMMIT WORK (2×) conflicts with the RAP transaction lifecycle: it has to be removed and the transaction boundary left to the RAP save sequence before the code runs on ABAP Cloud. The 1 direct write(s) to SAP standard tables are not clean core in any edition: each is replaced on-stack by a released write API, a BAPI or a RAP action. The BDC screen automation (1×, from line 515) does not run in ABAP Cloud, and the screens it drives carry no stability contract. It is replaced on-stack by the released API of the same business object; where SAP has released none, by a wrapper around the classic API, released for use in ABAP Cloud, together with an influence request to SAP for a released API. A side-by-side service would need the same released API, so the automation forces no side-by-side split. The frontend file upload (GUI_UPLOAD, from line 129) reads a file from the user's PC: a RAP business object takes a file as a large object (attachment) field from S/4HANA 2022 on, so the upload alone forces no side-by-side split — a side-by-side service needs a requirement the code does not show, such as external users, files arriving from several systems, or a volume the S/4HANA stack should not carry. SAP_WAPI_CREATE_EVENT, BAPI_PO_CREATE1 are classic APIs SAP does not release for ABAP Cloud: on this route their calls are replaced by the released API of the same business object, or kept in classic ABAP behind a wrapper. Part of the program was not read. Include Z_MM_PO_NOTIFY was not uploaded — what it does is not determined. Include Z_MM_PO_LOG was not uploaded — what it does is not determined. Key-user extensibility: 3 of 6 part(s) are key-user candidates (Custom Business Objects (configuration)), each with its limit; 3 stay code, and part of the program was not assessed by the engine. The program splits: only the code part is built.
Side-by-side on SAP BTP — CAPRejected as a setting
Rejected as a setting, not on evidence: no construct of this run requires a decoupled runtime, and a separate SAP BTP runtime adds a lifecycle, a network hop and a licence for work the stack already carries. Nothing in the code rules it out.

The demo stops where the model begins. On a real project a model writes the design document against this contract — Architecture overview, Project blueprint, API endpoints, SAP standard API mapping, Cloud services, Data sync pattern, Security hardening, Roadmap, Non-functional requirements. A demo makes no model call, so there is none here, and writing a convincing one by hand is the one thing this product may never do. The canvas, the contract and the alternatives are what the deterministic engine produced; they carry the line numbers.

AC-1 · draft— On-stack ABAP Cloud with RAP on a target that was not bound. Side-by-side on SAP BTP with CAP rejected.

Target contextNot determined

The run bound no target deployment, so there is no target context to state. It is not defaulted to the public edition, which would be the most permissive answer and therefore the wrong one to guess.

Blocks: The run recorded no input manifest, so this contract cannot say what it was derived from. A contract that names inputs the run never had is the defect the manifest exists to prevent.

RuntimeReconstructed

ABAP Cloud on the S/4HANA application server: RAP behaviour and service definitions in the customer namespace, released APIs only. Target artifact: RAP Business Object.

PersistenceProven

2 write(s) to custom persistence — ZMM_PO_APPR (line 353), ZMM_PO_ATTACH (line 531); 1 write(s) to SAP standard tables — EBAN (line 240).

Qualifies: The engine did not assess 2 × local function-module call (from line 173), 2 × include whose source was not uploaded (from line 363), 1 × dynamic call or field access (from line 386), 2 × classic list output (from line 542). Every statement below describes the part that was read, not the whole object.

APIsImported

9 released successor(s) named by the catalog: EBAN → API_PURCHASEREQUISITION_SRV (OData API), EBAN → API_PURCHASEREQUISITION_SRV (OData API), LFA1 → API_BUSINESS_PARTNER (OData API), LFM1 → I_SUPPLIERPURCHASINGORG (CDS View), CSKS → I_CostCenter (CDS View).

Qualifies: No released successor is published for ME21N. The gap is SAP's publication, not an omission of this analysis; it is carried, not filled in.

PreconditionsModel proposal

SAP Cloud ERP Private selected as the target — where an API is not released, a wrapper plus an influence request to SAP is available. Direct writes to SAP standard tables are replaced with a released write API, a BAPI or a RAP action. A wrapper may encapsulate an unreleased object for use; it does not make a direct write supported. The BDC screen automations of this program are not yet replaced; what replaces them is said in the rationale. Beyond the findings, the engine did not assess 2 × local function-module call (from line 173), 2 × include whose source was not uploaded (from line 363), 1 × dynamic call or field access (from line 386), 2 × classic list output (from line 542).

Bound inputsNot determined

The run recorded no input manifest, so this contract cannot name what it was derived from.

Rejected alternativesReconstructed

Key user extensibility; Side-by-side on SAP BTP — CAP — rejected. 1 alternative(s) remain open: Cover the requirement with SAP standard — build nothing.

Qualifies: Whether SAP standard already covers the requirement is not assessed by the router; it is a question about the business capability, answered by the standard-coverage analysis with its own evidence. Covering the requirement without building anything therefore stays open here rather than being rejected.

SAP standardNot determined

Not assessed here. The router can see the code, not the business capability; whether SAP standard already covers the requirement is answered by the standard-coverage analysis against scope items, with its own evidence levels.

Key userRejected on evidence

Rejected on the evidence: 26 finding(s) exceed what key-user tooling can express, among them EBAN (line 61), EBAN (line 106), Authorization Check (AUTHORITY-CHECK) (line 116).

In-app ABAP Cloud / RAPRecommended

Side-by-side CAPRejected as a setting

Rejected as a setting, not on evidence: no construct of this run requires a decoupled runtime, and a separate SAP BTP runtime adds a lifecycle, a network hop and a licence for work the stack already carries. Nothing in the code rules it out.

Routing Rationale— Design ↔ Analyze Evidence Binding

Why This Architecture Was Chosen

Extensibility Route

ABAP Cloud (RAP)

Clean Core Score

40 of 100Far from clean core (5–59)

Target Deployment

SAP Cloud ERP Private

SAP reference— SAP reference pattern for the target, not a statement by SAP about this code

No SAP pattern
The Architecture Center does not cover in-app ABAP Cloud, RAP, released APIs or Level A–D; SAP’s Cloudification Repository is the source for this path.

Key Evidence Driving This Decision

Dynamic CALL FUNCTION / PERFORMPartial
Flagged with low-confidence warning; cannot resolve at parse time.

The analysis confirmed high standard-fit compatibility with no blocking constructs. An on-stack RAP extension maximizes reuse of existing CDS views, business logic, and transactional boundaries.

Requirements specification

Reconstructed· drafted from the code

The functional and non-functional requirements of the new solution, written down as one document an external implementer can build from — read from the signed code, completed by your decisions.

Every requirement with “The system shall …”, its reason, Given / When / Then criteria, Must · Should · Could and the code lines it comes from.
The targets the code cannot set — response times, retention, roles, cutover — as decisions with suggested answers.
A traceability matrix, and exports to Word, Markdown and Confluence.

Reading the code: no model call, no cost. Clearer wording by a model is optional, asked for inside — model call · not counted against analysis runs. Not part of the signed audit pack.

Specificationnot startedOpen the requirements workspaceDemo: read-only, nothing is saved.