Both options framed for OQ-11 failed the deciding criterion: whether the
next person finds the thing inside the platform. A CAP service or a
hardened worker on Cloud Foundry is discoverable only to whoever already
knows the route to it, which is ADR-002's original objection relocated
rather than answered.
The integration is now Integration Suite native. Nothing on Cloud
Foundry, nothing in ABAP:
- Arena connectivity as a custom adapter built with the Adapter SDK —
sender adapter with the webhook endpoint and delta scheduler, cluster
lock for single-flight login, ADK persistency for the delta cursor,
tenant user credentials for Arena secrets.
- Movement as iFlows to the released Product / BOM / ChangeMaster /
Attachment OData APIs.
- Human approval in SAP Build Process Automation (entitled in the global
account, not yet assigned).
Decisive: every mechanism hand-rolled in worker/ has a first-class ADK
facility, so the adapter deletes that custom infrastructure rather than
merely relocating it; and the ADK's Java/Maven/OSGi toolchain is not a
new cost here, because the AS/400 FetchAPI servlets are already Java and
Java developers can be staffed in-house.
worker/ is reclassified from deliverable to specification: its 137 tests
describe the Arena session, delta-cursor and webhook behaviour the
adapter must reproduce. app/ has no target service under ADR-005 and is
kept as reference, unrepointed.
ADR-004's "side-by-side runtime" is narrowed to mean "in Integration
Suite". New verification items V-5 (can an ADK adapter hold an Arena
session under cluster lock — the first build) and V-6 (where SBPA tasks
surface for a business user).
No SAP tenant or BTP artifact was modified.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
alexzandClaude Opus 5