alexzandClaude Opus 5
ffd33f4ec0
Both tenants belong to the same starter system: my429480 is its customizing tenant (client 100, key-user extensibility only, no ABAP) and my431353 is its development tenant (client 080). This package had recorded my429480 as "productive" and ADR-002 had assumed it offered developer extensibility; both were wrong. - ADR-004 withdraws the on-stack RAP route and moves the application to a side-by-side runtime against released OData APIs. ADR-002 marked superseded. - Development tenant my431353 parked: all 19 ZARENA_PLM objects left active, sources kept in docs/handover/rap/ as reference, so the route stays reversible. - Replacement host left open as OQ-11 (key-user extensibility vs CAP side-by-side); recommendation recorded as CAP. No build starts until OQ-11 is closed. - RAP-dependent items V-2, V-3, OQ-5, OQ-8, OQ-9, OQ-10 parked rather than closed. - Tenant references corrected across CLAUDE.md, KNOWLEDGE.md, app/README.md, the RAP handover README, the rap-developer agent and the reentrance-login helper README. No SAP tenant was modified. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
81 lines
4.3 KiB
Markdown
81 lines
4.3 KiB
Markdown
# 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.
|