arena-plm-fiori/docs/adr/ADR-004-back-out-of-on-stack-rap.md

ADR-004 — Back out of on-stack RAP: side-by-side against released APIs

Date: 2026-09-29 · Status: Accepted (supersedes ADR-002; partly revives ADR-001)

Context

ADR-002 moved this package on-stack: a RAP approval business object and a Fiori Elements app inside the tenant, with side-by-side reduced to a connectivity worker, and CAP written out of the architecture. I built that. On the starter system's development tenant my431353 (client 080) the approval business object is complete and active — 19 objects in ZARENA_PLM, ATC clean, the UI service published on 2026-09-16 — and the Fiori Elements app in app/ is built against a mock of it.

Two facts have since changed the ground under that decision.

The tenant I work in cannot host it. my429480 and my431353 are two tenants of the same starter system: my429480 is its customizing tenant (client 100) and my431353 is its development tenant (client 080). The customizing tenant supports key-user extensibility only — no ABAP, no RAP; developer extensibility exists only on client 080 [source: fiori-tools-samples misc/s4hana/README, "Tenant Types", verified 2026-09-29]. ADR-002 was written believing my429480 offered developer extensibility, and this package compounded the error by recording my429480 as "productive". Both readings were wrong.

I am not carrying the ABAP build. The RAP route costs more than this package can justify: every source has to be pasted into an editor by hand, because no agent-side ABAP authoring path exists (V-4, answered 2026-09-15: no; SAP's editing tool is planned for Public Edition 2702), and the one workaround I tried — reentrance-ticket login for a community ADT server — was built, tested and rejected on evidence (2026-09-18). Outside advice is that no ABAP is needed for this integration. Nothing I built on-stack ever reached a business user: ARN-007 (IAM app, business catalog, business role) was never started, and the business object still runs authorization master ( none ).

Decision

I withdraw the on-stack RAP route. The application moves back out to a side-by-side runtime consuming released OData APIs, with the customizing tenant my429480 (client 100) as the sync target and configuration home.

I park the development tenant my431353 rather than clean it: all 19 objects stay active in ZARENA_PLM, and their sources stay in docs/handover/rap/. Parking costs nothing — the package carries no transport recording and the tenant is non-productive — and it keeps the route reversible if the constraint or the advice changes.

I do not decide the replacement host here. That is OQ-11: key-user extensibility in the customizing tenant (custom business object plus a low-code UI) versus a CAP service side-by-side on BTP. My recommendation is CAP, because the connectivity worker has to live side-by-side whatever else happens, and one runtime beats two. No build starts until OQ-11 is closed.

Consequences

Kept, unchanged in value:

• the connectivity worker (worker/) — built, 137 tests green, never deployed; it is the only encoding of the Arena session, delta-cursor and webhook logic outside the Express predecessor, and it is needed under either OQ-11 option;
• the Fiori Elements app (app/) — repointable, because 35 of its 58 annotations are already local rather than backend-owned (OQ-10);
• the RAP sources and the live objects, as reference and as a reversible route.

Withdrawn or weakened:

• the acceptance test's "finds its data in the Custom CDS Views app" clause — unreachable from client 100; what survives is launchpad reachability and governance by business roles, and launchpad reachability now becomes a federation question rather than a native one;
• ADR-002's claim that "CAP exits the architecture" — ADR-001's CAP-first direction is, in effect, back on the table.

Parked with this decision, not closed: V-2, V-3, OQ-5, OQ-8, OQ-9, OQ-10 — all scoped to the parked development tenant. Each returns only with the RAP route.

Unrelated to the decision but blocking any verification against the customizing tenant: the only AZ_API_USER credential for my429480 in my estate is rejected (HTTP 401), the Cloud Foundry token is expired, and the client certificate path has no certificates. One of those has to be restored before I can read that tenant at all.