ADR-004: back out of on-stack RAP; retarget to starter customizing tenant
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>
This commit is contained in:
Claude Opus 5
@@ -15,39 +15,63 @@ Views app, and access is governed by business roles** — with the side-by-side
|
||||
footprint reduced to the one thing that cannot run in the tenant: Arena
|
||||
connectivity.
|
||||
|
||||
**Amended 2026-09-29.** I wrote that acceptance test assuming I could build
|
||||
in the tenant. I cannot, in the tenant I am now working in: the starter
|
||||
system's customizing tenant `my429480` (client 100) supports key-user
|
||||
extensibility only, so "its data in the Custom CDS Views app" is not
|
||||
reachable there and the RAP half of the test is withdrawn (ADR-004). What I
|
||||
keep is the part that actually mattered: **a business user finds the
|
||||
application from the S/4HANA launchpad and access is governed by business
|
||||
roles.**
|
||||
|
||||
In scope: material, BOM, change-master, and document sync from Arena to
|
||||
S/4HANA, gated by a human approval workflow. Out of scope: every other package
|
||||
of the old estate — one package at a time.
|
||||
|
||||
## Target architecture (ADR-002, 2026-09-04)
|
||||
## Target architecture (ADR-004, 2026-09-29 — supersedes ADR-002)
|
||||
|
||||
The starter system's **customizing** tenant `my429480` (client 100) supports
|
||||
**key-user extensibility only** — no ABAP, no RAP. ABAP development requires
|
||||
the starter system's **development** tenant `my431353` (client 080), which I
|
||||
parked on 2026-09-29 [source: fiori-tools-samples `misc/s4hana/README`
|
||||
"Tenant Types", verified 2026-09-29]. The on-stack RAP business object of
|
||||
ADR-002 therefore has no home in the tenant I am now working in, and the
|
||||
application moves back out to a side-by-side runtime consuming released APIs.
|
||||
|
||||
```
|
||||
Arena PLM ──webhook + delta poll──▶ Connectivity worker (BTP CF, hardened TS)
|
||||
│ no UI, no user URLs; technical user
|
||||
reads approved / │ writes staged changes
|
||||
executes sync ▼ ▼ via approval BO service binding
|
||||
┌─ SAP S/4HANA Cloud Public (my429480) ─────────────────────────────────────┐
|
||||
│ Z RAP BO "Arena Change Approval" ← staging + state machine + audit │
|
||||
│ Fiori Elements List Report / Object Page ← in the tenant LAUNCHPAD │
|
||||
│ IAM app → business catalog → business roles ← the only access control │
|
||||
│ Custom CDS views over the BO (join I_Product, …) ← Custom CDS Views app │
|
||||
│ Released OData APIs (Product/BOM/ChangeMaster/Attachment) ← sync targets │
|
||||
│ built, 137 tests green, NOT deployed
|
||||
▼
|
||||
Approval store + state machine + audit
|
||||
(side-by-side — host is the open call, OQ-11)
|
||||
│
|
||||
Fiori Elements List Report / Object Page
|
||||
(`app/` — already built, service-repointable)
|
||||
│ released OData APIs, mc-s4hana
|
||||
┌─ Starter system · CUSTOMIZING tenant `my429480` (client 100) ─────────────┐
|
||||
│ Product / BOM / ChangeMaster / Attachment released APIs ← sync targets │
|
||||
│ Key-user extensibility + configuration only — no ABAP, no RAP │
|
||||
│ Launchpad reachability for the app: decided with OQ-11 │
|
||||
└───────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
parked 2026-09-29 ──▶ Starter system · DEVELOPMENT tenant `my431353` (080)
|
||||
19 RAP objects live in ZARENA_PLM, left in place
|
||||
```
|
||||
|
||||
**Build state (2026-09-14):** the Fiori Elements UI layer is scaffolded as
|
||||
`com.minicircuits.arenaplm` (List Report / Object Page, TS) in the structural `app/` subfolder
|
||||
(sibling to `worker/`), running on a **mock** OData V4 service — an interim, generator-iterable
|
||||
stand-in. The real on-stack RAP BO + service binding (ARN-002, V-2) and
|
||||
launchpad deployment (ARN-007) remain gated on developer extensibility (V-1).
|
||||
The predecessor `arena-plm` on CF is verified live (`/api/health` 200) and is
|
||||
the base of record for the domain/field shape until the RAP service exists.
|
||||
**Build state (2026-09-29).** What exists: the Fiori Elements UI
|
||||
`com.minicircuits.arenaplm` in `app/`, built and bound to a mock OData V4
|
||||
service; the connectivity worker in `worker/`, built with 137 tests green and
|
||||
never deployed (no deployment descriptor was ever written); and 19 activated
|
||||
RAP objects on the parked development tenant, with their sources kept in
|
||||
`docs/handover/rap/` as reference. Nothing from this package has ever been
|
||||
deployed to Cloud Foundry or reached a business user.
|
||||
|
||||
## Systems & boundaries
|
||||
|
||||
| System | Role | Boundary |
|
||||
|---|---|---|
|
||||
| SAP S/4HANA Cloud Public (`my429480`) | **Application host** (RAP BO, Fiori app, CDS views) and sync target | Developer extensibility (ABAP Cloud via ADT); released APIs only |
|
||||
| Starter system, **customizing** tenant (`my429480`, client 100) | **Sync target** and configuration home | Key-user extensibility only — no ABAP, no RAP; released OData APIs via `mc-s4hana` |
|
||||
| Starter system, **development** tenant (`my431353`, client 080) | **Parked 2026-09-29** — former RAP application host | Developer extensibility; 19 objects left active in `ZARENA_PLM`, no transport recording |
|
||||
| Arena PLM (`api.arenasolutions.com/v1`) | Source of items, BOMs, changes, files | REST; webhook + delta poll, handled by the worker |
|
||||
| Connectivity worker (BTP CF) | Arena connectivity + initial sync executor | Machine-to-machine only; technical user via communication arrangement |
|
||||
|
||||
@@ -105,7 +129,8 @@ once V-1 opens the development tenant.
|
||||
## Architecture decisions
|
||||
|
||||
- ADR-001 — toolchain-must-engage rebuild; Express predecessor reference-only. **Amended by ADR-002.**
|
||||
- ADR-002 — on-stack first: RAP + Fiori Elements in the tenant; side-by-side reduced to a connectivity worker; CAP exits the architecture.
|
||||
- ADR-002 — on-stack first: RAP + Fiori Elements in the tenant; side-by-side reduced to a connectivity worker; CAP exits the architecture. **Superseded by ADR-004.**
|
||||
- ADR-004 (2026-09-29) — I withdraw the on-stack RAP route and move the application back to a side-by-side runtime against released APIs. Two facts force it: the customizing tenant `my429480` (client 100) supports key-user extensibility only, and I am no longer willing to carry an ABAP/RAP build for this package. I park the development tenant `my431353` (client 080) with its 19 activated objects in place rather than delete them, so the route stays reversible. The replacement host — key-user extensibility in the tenant versus a CAP service side-by-side — is OQ-11; my recommendation is CAP, because the connectivity worker must be side-by-side regardless and one runtime beats two.
|
||||
|
||||
## Verification items & open questions
|
||||
|
||||
@@ -121,6 +146,8 @@ once V-1 opens the development tenant.
|
||||
| OQ-10 | Ownership of UI annotations: the backend metadata extension `ZC_CHANGEAPPROVAL` or the app's local `annotation.xml`. Today 35 of the 58 local annotations override a backend annotation with the same target, term and qualifier (layering rule [source: fiori-mcp-server "Visualizing and Managing Annotations with SAP Fiori Tools - Service Modeler", verified 2026-09-16]), so a DDLX change to those terms is invisible in the app. The local file adds i18n labels, action criticality, the `#Default` variants and the facet IDs the OPA journey relies on | Open (2026-09-16). Interim rule: a term defined locally is changed locally. I consolidate before launchpad deployment |
|
||||
| OQ-8 | Per-operation authorization for the approval BO. Today it is `authorization master ( none )`: any holder of the UI app can approve, reject and retry, and any tenant ABAP code can create and mark* through EML. SAP Help calls `( none )` "not recommended in real-world scenarios". The target is `( global )` with a `FOR GLOBAL AUTHORIZATION` handler and `AUTHORITY-CHECK OBJECT` on a custom authorization object: decisions for business roles, create/mark* for the communication role. First verify that custom authorization objects can be created on `my431353` [source: abap-docs /abap-docs-cloud/ABENBDL_AUTHORIZATION, ABAPHANDLER_METH_GLOBAL_AUTH; sap-docs sap-help loio 673c05562e144702a080c574c3da2da3, verified 2026-09-16 by my review] | Open (2026-09-16): does not block the dev-tenant UI POC; must close before any business role other than the developer's gets the app (IAM brief) |
|
||||
| OQ-7 | Tenant object naming and cleanup for the approval BO | **Closed 2026-09-16.** The package was deleted in ADT, contents and package itself (verified live through ADT MCP validation, 2026-09-16). I build from scratch, without the generator: table `ZCHANGEAPPROVAL`, `ZR_CHANGEAPPROVAL`, `ZBP_R_CHANGEAPPROVAL`, `ZC_CHANGEAPPROVAL`, SRVD `ZUI_ARENA_CHANGE_APPROVAL` with SRVB `ZUI_ARENA_CHANGE_APPR_O4`, and SRVD `ZAPI_ARENA_CHANGE_APPROVAL` with SRVB `ZAPI_ARENA_CHANGE_APPR_A2X`. Binding names follow SAP's 26-character limit (RAP-5). Entity set is `ChangeApproval`; the A2X projection and parameter entity names are unchanged |
|
||||
| OQ-11 | Where the approval store, state machine and audit live now that ADR-004 withdrew the RAP BO. Option A: key-user extensibility in the customizing tenant (custom business object + low-code UI) — stays in the tenant and in the launchpad natively, but the Arena connectivity still needs an outside worker, so the application ends up with two homes, and key-user objects are transport-bound. Option B: a CAP service side-by-side on BTP CF — one runtime with the worker, matches the archetype the rest of my estate already runs, and `app/` repoints to it cheaply because 35 of its 58 annotations are already local (OQ-10); the cost is BTP runtime and launchpad reachability becomes a federation question. | Open (2026-09-29). I recommend Option B. Decide before any further build. |
|
||||
| OQ-12 | The ABAP/RAP-dependent items V-2, V-3, OQ-5, OQ-8, OQ-9 and OQ-10 are all scoped to the parked development tenant. They are **parked with ADR-004**, not closed; each returns only if the RAP route is revived. | Parked (2026-09-29) |
|
||||
|
||||
## Status
|
||||
|
||||
@@ -130,8 +157,8 @@ once V-1 opens the development tenant.
|
||||
| Developer environment | Done (2026-09-04); MCP loadout revised to ABAP/RAP set (done 2026-09-04) |
|
||||
| Ground-truth enforcement kit (ADR-003 hooks) | Done (2026-09-04); hardened 2026-09-14 — Bash/MultiEdit/filesystem writes gated, grounding-only marker refresh, portable paths, fail-closed, 37 pipe-tests green |
|
||||
| Specialist agent roster (5 agents, docs/agent-roster.md) | Done (2026-09-04; all 5 files YAML-verified in .claude/agents/) |
|
||||
| V-1…V-3 verification POC | Planned — V-1 (ADT access on my429480) is the user-side gate for everything on-stack |
|
||||
| Fiori Elements app (`app/`, mock-bound) | Done for the mock stage (2026-09-14) — gateway service shape (binding-derived identity), six-state domain, polished List Report/Object Page, launchpad inbound `ArenaChangeApproval-manage`; SAP review findings closed. Deploy gated on V-1/V-2 (live `$metadata` reconciliation) |
|
||||
| RAP BO (approval domain) | In progress (2026-09-16): from-scratch build in package `ZARENA_PLM` (under `ZLOCAL`, no transport recording) under the clean names (OQ-7 closed). The handover in `docs/handover/rap/` has all pre-paste review fixes applied and was stable as of 02:45. Wave A (U1–U5: table, three parameter entities, root view) was created empty at 02:30. Its sources were pasted at 02:47, and all five activated at 02:49 with no errors, `preserving type` included. Wave B (U6 base BDEF, U10 root access control) was created empty at 02:50, its sources were pasted at 02:53, and both activated at 02:55 (BDEF through `.bdef.abdl`). Wave C (U7 behavior pool, U8 UI projection view) was pasted at ~03:00 and activated at 03:03 (U6 and U7 together, then U8), with no errors. It is not yet confirmed that the handler source sits in the class's Local Types include; until it is, activation does not prove the three flagged constructs. Wave D (U9 projection BDEF, U11 access control, U12 metadata extension, U13 UI service definition) was created empty at 03:05 and pasted at ~04:12. U9, U11 and U12 activated at 04:15. U13 activation failed, listing "Comments are not supported and will be deleted on save" (Ln 1) and "oData V4 services with no draft capability will be primarily READ-ONLY" (Ln 21, expected by design). After a comment-free re-save, U13 activated at 04:18. U14 binding `ZUI_ARENA_CHANGE_APPR_O4` (OData V4 UI) was created and activated. **The UI leg is active: all 14 objects; ATC 0 errors, 0 warnings, 43 infos.** **Published 2026-09-16 04:26** through the ADT Publish code lens: `https://my431353-api.s4hana.cloud.sap/sap/opu/odata4/sap/zui_arena_change_appr_o4/srvd/sap/zui_arena_change_approval/0001/?sap-client=080`, entity set `ChangeApproval` (`fetch_service_information`). The table is empty until the worker leg creates records, because the UI exposes no create. V-2 app reconciliation done. **Worker (A2X) leg ACTIVE 2026-09-16 06:37:** W1 view `ZC_CHANGEAPPROVAL_A2X`, W2 access control, W3 projection BDEF (create, markExecuting, markSynced, markFailed), W4 service definition `ZAPI_ARENA_CHANGE_APPROVAL` and W5 OData V4 Web API binding `ZAPI_ARENA_CHANGE_APPR_A2X` (unpublished, service `0001`). ATC on the 5 worker objects: 0 errors, 1 priority-3 warning (W607 on `ZC_CHANGEAPPROVAL_A2X`: `authorizationCheck: #CHECK` should be `#MANDATORY`), deferred to OQ-8. **The approval BO is complete on the development tenant (19 objects).** Next: expose W5 to the worker's communication user through a custom communication scenario (V-2 A2X half); IAM app, business catalog and role for the UI app (ARN-007); OQ-8 authorization before other business users. The table source goes into `.tabl.ddic`; `.tabl.json` holds only header metadata. (3) UI leg, 14 sources ending with binding `ZUI_ARENA_CHANGE_APPR_O4`: I create each object through the MCP, its source is pasted in the VS Code editor, and I activate it. The `markSynced`/`markFailed` parameter entities belong to this leg, because the base BDEF references them. (4) Publish the UI binding, then run V-2 reconciliation of the app against its live `$metadata`. (5) Worker (A2X) leg, 4 sources. Syntax proven only by tenant activation, still open: `OPTIONS PRIVILEGED ACCESS` in `checkDuplicate` (fallback `FROM … WITH PRIVILEGED ACCESS`), `%op-%action` on MODIFY response rows, `preserving type` on the U5 boolean casts |
|
||||
| V-1…V-3 verification POC | V-1 **Closed 2026-09-15** on the development tenant. V-2/V-3 **parked 2026-09-29** with ADR-004. The old note that V-1 meant "ADT access on my429480" was wrong: `my429480` is the customizing tenant and grants no developer extensibility at all |
|
||||
| Fiori Elements app (`app/`, mock-bound) | Done for the mock stage (2026-09-14) — gateway service shape (binding-derived identity), six-state domain, polished List Report/Object Page, launchpad inbound `ArenaChangeApproval-manage`; SAP review findings closed. Deploy gated on V-1/V-2 (live `$metadata` reconciliation) | **2026-09-29: still mock-bound and never deployed.** Its target service is now OQ-11, not the RAP UI binding |
|
||||
| RAP BO (approval domain) | **Parked 2026-09-29 (ADR-004).** Complete and active on the development tenant `my431353`: 19 objects in `ZARENA_PLM`, ATC 0 errors, UI service published 2026-09-16 04:26, A2X binding unpublished. I leave every object in place and keep the sources in `docs/handover/rap/`. Never reached a business user: no IAM app, no business catalog, no business role (ARN-007 never started), and `authorization master ( none )` throughout |
|
||||
| Connectivity worker | Review wave Done (2026-09-14) — TTL wiring, cursor-after-success, buffer-full = tick failure, health conformance, strict JSON-only validation, bounded buffer, graceful drain, HTTP timeout, fixed-phrase errors; 137 tests green incl. the schema-driven contract-conformance suite. Next: Arena client POC (live), executor leg gated on V-2. **Do not deploy the scaffold**: the ingest buffer has no consumer yet, so a long-running instance would answer 503 after `WEBHOOK_QUEUE_MAX_SIZE` events. Next: Arena client POC (live), executor leg gated on V-2 |
|
||||
| Worker API contract (`docs/api/worker.openapi.json`) | v0.2.1 Done (2026-09-14) — health enums/`degraded`/`poller`, strict `SyncRunRequest`, webhook 503, 413/415 + `default` on every operation, reserved 502, `DOCUMENTS` token; `x-sap-stateInfo: beta`, provisional webhook schema pending Arena POC |
|
||||
|
||||
Reference in New Issue
Block a user