# 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.