ADR-005: OQ-11 closed — Integration Suite native (ADK adapter + iFlows + SBPA)

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>

CHANGELOG.md

@@ -2,6 +2,84 @@
 
 Append-only decision log for this package.
 
+## 2026-09-29 — ADR-005: OQ-11 closed. Integration Suite native — Arena ADK adapter + iFlows, approval in SAP Build Process Automation
+
+- What changed: I closed OQ-11 and wrote
+  `docs/adr/ADR-005-integration-suite-native.md`. The integration becomes
+  Integration Suite native: an Arena custom adapter built with the Adapter SDK
+  (sender adapter carrying the webhook endpoint and the delta scheduler), iFlows
+  for the movement to the released Product / BOM / ChangeMaster / Attachment
+  APIs, and human approval in SAP Build Process Automation. Nothing runs on
+  Cloud Foundry; nothing is written in ABAP. I rewrote the PRD's target
+  architecture accordingly and added V-5 and V-6.
+- Why: both options I had framed for OQ-11 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 — and 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.
+  Two findings then chose between the native options:
+  - Every mechanism I hand-rolled in `worker/` has a first-class ADK facility:
+    cluster lock for single-flight login, ADK persistency for the delta cursor,
+    user credentials for Arena secrets, scheduler support, connection status,
+    tracing, endpoint visualization, and versioning rules [source: SAP Help,
+    *Adapter Development Process*, Cloud Integration, verified 2026-09-29]. The
+    adapter does not merely present better; it deletes the infrastructure the
+    worker existed to supply.
+  - I had recorded the ADK's Java/Maven/OSGi toolchain as the cost of this
+    route. It is not a cost in this estate: the AS/400 FetchAPI servlets on
+    `mcl2000` are already Java, and Java developers can be staffed in-house. One
+    language and one team span both ends, and the ADK covers the on-premise leg
+    directly through *Accessing On-Premise Application using Cloud Connector* —
+    which retires the deleted Cloud Foundry `fetchapi-bridge` pattern instead of
+    rebuilding it.
+- Affected: PRD (target architecture, decisions, OQ-11 closed, V-5 and V-6
+  added), new ADR-005, ADR-004 narrowed. `worker/` is reclassified from
+  deliverable to specification; `app/` has no target service under ADR-005 and
+  is kept as reference, not repointed. No SAP tenant or BTP artifact was
+  modified.
+- Decision: ADR-005. I also correct something I asserted too confidently
+  earlier in the day: that SAP Build Process Automation tasks surface in the
+  Fiori launchpad. That is now V-6, unverified — what I can state is that the
+  service is entitled in the global account (`process-automation`,
+  `process-automation-service`) and therefore needs assigning, not buying.
+  First build is V-5: a minimal Arena sender adapter that logs in and holds the
+  session under cluster lock. Nothing else starts before it.
+
+## 2026-09-29 — Read access to the customizing tenant proven through `mc-s4hana`; the parked password is simply stale
+
+- What changed: nothing in the tenant — I established how to read it. Through
+  the BTP destination `mc-s4hana`, three read-only GETs against
+  `my429480` all answered 200: `API_BUSINESS_PARTNER/$metadata` (EDMX v1.0,
+  65 entity sets), `A_BusinessPartner?$top=1` (BusinessPartner `1710`), and
+  `api_product/srvd_a2x/sap/product/0002/$metadata` (EDMX 4.0, 39 entity sets).
+  I used the destination service instance `sap-apps-dest` and its existing
+  service key `dest-anywhere-dest-key`; I created no key and no instance.
+- Why: after retargeting, direct basic auth to the customizing tenant returned
+  401, and I needed to know whether the tenant was refusing the user or the
+  stored password was wrong.
+- Affected: no SAP object, no BTP artifact. Knowledge only.
+- Findings:
+  - `mc-s4hana` authenticates as **`BasicAuthentication` with the same user,
+    `AZ_API_USER`**, and succeeds. So the tenant accepts that user over basic
+    auth: the 401 was neither a lockout nor a user problem. The password in
+    `_shared/.env.starter-cust-my429480.bak` is stale, and the working value is
+    already held by the destination. No credential reset is needed.
+  - The destination's own description reads "SAP S/4HANA Public Cloud - MC
+    Production" while its URL is the starter customizing tenant — the same
+    mislabel this package carried, now visible in BTP as well. I left it alone;
+    it is shared, and a description is not worth an unrequested change.
+  - `default-env.json` alone does not work with SAP Cloud SDK v4:
+    `@sap-cloud-sdk/connectivity` 4.6.0 resolves bindings through `@sap/xsenv`'s
+    `filterServices()`, which reads `process.env.VCAP_SERVICES` and never loads
+    the file. `require('@sap/xsenv').loadEnv()` must run ahead of the SDK
+    requires (or `VCAP_SERVICES` be exported). The first attempt failed with
+    "Could not find service binding of type 'destination'".
+- Decision: I will not copy the working password out of the destination into
+  `.env`. The destination is the sanctioned path for this estate, so the fix is
+  to make the shared CLI destination-aware rather than to hold a second copy of
+  a credential. Until that is done, reads against the customizing tenant go
+  through a destination-based call, not through `sap-api`.
+
 ## 2026-09-29 — Tooling retargeted to the starter customizing tenant; its credential is rejected
 
 - What changed: