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>
5.0 KiB
ADR-002 — On-stack first: RAP approval domain + Fiori app in the tenant; side-by-side reduced to a connectivity worker
Date: 2026-09-04 · Status: Superseded by ADR-004 (2026-09-29) (amended ADR-001)
Superseded 2026-09-29. The customizing tenant
my429480(client 100) supports key-user extensibility only, so the RAP business object below has no home there;my429480andmy431353are the starter system's customizing and development tenants, not a development and a productive system. V-1 below, "confirm developer-extensibility access on my429480", was unanswerable as written. See ADR-004.
Context
The decisive test came from outside: the showcased UI apps present the data well, but they are invisible from inside S/4HANA — not in the Fiori launchpad, not discoverable in the Custom CDS Views app, reachable only via standalone Cloud Foundry URLs behind an ad-hoc route structure with weak access control. For an S/4HANA user, an application that cannot be found in the tenant does not exist.
ADR-001 correctly rejected the Express shape but still assumed a side-by-side BTP application (CAP) as the rebuild target. That assumption fails the same test: a CAP app on BTP is still a standalone URL outside the tenant.
S/4HANA Cloud Public Edition offers two in-tenant extensibility tiers, both verified against SAP documentation (2026-09-04, via sap-docs MCP):
- Developer extensibility: upgrade-stable ABAP Cloud development directly on the stack (ADT against the development tenant) — CDS entities, RAP business objects with behavior, custom Fiori apps deployed into the tenant, authorization via IAM app → business catalog → business role.
- Key-user extensibility: Custom Business Objects, Custom CDS Views (on released C1 view entities), Custom Analytical Queries, and Business Configuration maintenance via the Custom Business Configurations app.
The estate's standing rule already says extensibility-first: check what the tenant can host before building side-by-side.
Decision
I move the application into the tenant and shrink the side-by-side footprint to what genuinely cannot run there:
On-stack (developer extensibility, ABAP Cloud / RAP):
- A custom RAP business object for the Arena change approval domain — staging data, approval state machine (pending → approved/rejected), audit fields — persisted in the tenant.
- A Fiori Elements List Report / Object Page on that BO, deployed to the tenant's Fiori launchpad; approve/reject as RAP actions.
- IAM app, business catalog, and business roles as the only access control — no user-facing custom URLs anywhere.
- Custom CDS views over the approval BO (joinable with released views such as I_Product) so the data is discoverable in the Custom CDS Views app and usable in analytical queries — the discoverability test that triggered this ADR.
- Business mappings evaluated as Business Configuration maintenance objects (Custom Business Configurations app) instead of JSON files in git.
Side-by-side (one hardened TypeScript worker, no UI, no user URLs):
- Arena connectivity only: webhook receipt, delta polling, session management (25-min TTL, login race), file streaming.
- Initially also the sync executor: on approval, it calls the released OData APIs (Product/BOM/ChangeMaster/Attachment) exactly as the predecessor did — every KNOWLEDGE.md tombstone stays valid unchanged.
- It exchanges data with the tenant through the approval BO's service binding exposed via a custom communication scenario/arrangement with a technical user.
CAP exits the architecture: with the domain, UI, and persistence on-stack, the remaining side-by-side piece is a pipeline, and per the two-archetype standard a pipeline is a worker, not a CAP service. This resolves ADR-001's deferred question and PRD OQ-1 through OQ-4 in one move.
Consequences
- The Fiori launchpad becomes the application's only front door; the shared BTP gateway, XSUAA role juggling, and standalone routes disappear from this package entirely.
- Persistence and audit live in the tenant — the predecessor's lost-on-restart approval queue defect is solved structurally, not patched.
- The toolchain shifts: ABAP Cloud + RAP + Fiori Elements, so the MCP loadout moves to sap-docs / abap-docs / sap-released-objects / fiori / ui5, and cap-mcp-server leaves the loadout.
- Verification items before build (POC gates):
- V-1: confirm developer-extensibility access on my429480 (development tenant reachable via ADT, developer business role assigned).
- V-2: confirm a custom communication scenario can expose the approval BO's OData service to the worker's technical user.
- V-3: evaluate on-stack Application Jobs vs the worker for Arena delta polling; and Business Configuration objects vs config files (ARN-004).
- Fallback recorded: if developer extensibility proves unavailable on this tenant, the key-user tier (Custom Business Object with generated UI) is the degraded-but-still-in-tenant variant; side-by-side is no longer the fallback.