alexzandClaude Opus 5
272a202152
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>
4.3 KiB
ADR-005 — OQ-11 closed: Integration Suite native — Arena ADK adapter + iFlows, approval in SAP Build Process Automation
Date: 2026-09-29 · Status: Accepted (closes OQ-11; narrows ADR-004)
Context
ADR-004 withdrew the on-stack RAP route and said the application moves to a side-by-side runtime against released APIs, leaving the host open as OQ-11: key-user extensibility in the tenant, or a CAP service on Cloud Foundry.
Both of those options failed the criterion that actually decides this. The test is not build cost — it is 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 the same objection that produced ADR-002 in the first place, merely relocated. Custom applications living outside the platform are not acceptable here.
Two findings then settled which native option to take.
The Adapter Development Kit already provides the infrastructure my worker
invented. Every non-trivial mechanism in worker/ has a first-class ADK
facility [source: SAP Help, Adapter Development Process, Cloud Integration,
verified 2026-09-29]:
Hand-rolled in worker/ |
ADK facility |
|---|---|
Promise lock so only one Arena login runs; correctness dependent on instances: 1 |
Managing Cluster Lock in Custom Adapters |
| Delta cursor persistence | Enabling ADK Persistency |
| Arena credentials in environment / a user-provided service | Accessing User Credentials |
| Delta poll timer | Enabling Scheduler Support for ADK Sender Adapter |
/api/health with ok/degraded |
Enabling Connection Status for Integration Flow |
| Structured logging | Enabling Tracing for Custom Adapter |
| Webhook ingress URL | Enabling Endpoint Visualization for Custom Adapter |
So the adapter does not merely present better — it deletes the custom infrastructure the worker existed to supply.
Java is not a new skill for this estate. The ADK is a Java, Maven and OSGi
toolchain, which I had recorded as the cost of this route. It is not a cost
here: the AS/400 FetchAPI servlets on mcl2000 are already Java, and Java
developers can be staffed from inside the company. One language and one team
therefore span both ends of the estate, and the ADK covers the on-premise leg
directly through Accessing On-Premise Application using Cloud Connector —
the sanctioned route to mcl2000, which retires the deleted Cloud Foundry
fetchapi-bridge pattern rather than rebuilding it.
Decision
The integration is Integration Suite native. Nothing runs on Cloud Foundry and nothing is written in ABAP.
- Arena connectivity is a custom adapter built with the Adapter SDK: a sender adapter carrying the webhook endpoint and the delta scheduler, using cluster lock for single-flight login, ADK persistency for the delta cursor, and the tenant's user credentials for Arena secrets.
- Movement is iFlows: Arena → the released S/4 OData APIs for Product, BOM, Change Master and Attachment.
- Human approval is SAP Build Process Automation, which is already entitled
in the global account (
process-automation,process-automation-service), so it requires assignment rather than procurement. - The S/4 target remains released OData APIs through the customizing tenant
my429480.
worker/ stops being a deliverable and becomes the specification: its 137
tests describe the Arena session, delta-cursor and webhook behaviour the adapter
must reproduce. That is worth more than its code, and it is why ADR-004 kept it.
Consequences
- ADR-004's phrase "a side-by-side runtime" is narrowed: there is no custom application runtime at all. Side-by-side now means "in Integration Suite", not "on Cloud Foundry".
- The Fiori Elements app in
app/has no target service under this decision. Approval screens come from SAP Build Process Automation. I keepapp/as reference rather than deleting it, on the same reasoning as the parked RAP objects, and I do not repoint it. - New verification items: V-5 (can an ADK adapter hold an Arena session under cluster lock) and V-6 (where SAP Build Process Automation tasks surface for a business user).
- The estate gains a second use for the same skill: adapters for
softco-apand the AS/400 legs can follow the same pattern.