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>
116 lines
6.4 KiB
Markdown
116 lines
6.4 KiB
Markdown
## Application Details
|
|
| |
|
|
| ------------- |
|
|
|**Generation Date and Time**<br>Mon Sep 14 2026 12:49:13 GMT-0700 (Pacific Daylight Time)|
|
|
|**App Generator**<br>SAP Fiori Application Generator|
|
|
|**App Generator Version**<br>1.32.0|
|
|
|**Generation Platform**<br>Visual Studio Code|
|
|
|**Template Used**<br>List Report Page V4|
|
|
|**Service Type**<br>File|
|
|
|**Metadata File**<br>metadata.xml|
|
|
|**Module Name**<br>app|
|
|
|**Application Title**<br>Arena PLM Engineering Changes Approval Flow|
|
|
|**Namespace**<br>com.minicircuits|
|
|
|**UI5 Theme**<br>sap_horizon|
|
|
|**UI5 Version**<br>1.152.0|
|
|
|**Enable TypeScript**<br>True|
|
|
|**Add Eslint configuration**<br>True, see https://www.npmjs.com/package/@sap-ux/eslint-plugin-fiori-tools#rules for the eslint rules.|
|
|
|**Main Entity**<br>ChangeApprovals|
|
|
|
|
## Service binding (live, reconciled 2026-09-16 - PRD V-2)
|
|
|
|
The app binds to the RAP **UI** service binding, not the A2X binding the worker uses.
|
|
The single source of truth for the service identity is the live `$metadata` of the published
|
|
binding, captured 2026-09-16 as `docs/v2/zui_arena_change_appr_o4.metadata.xml` (repo root).
|
|
`webapp/localService/mainService/metadata.xml` is a **byte-identical copy** of it, so the mock
|
|
server serves the real contract. Refresh both together; never hand-edit the copy.
|
|
|
|
| Item | Value |
|
|
|---|---|
|
|
| Service binding (OData V4 - UI) | `ZUI_ARENA_CHANGE_APPR_O4` |
|
|
| Service definition | `ZUI_ARENA_CHANGE_APPROVAL` |
|
|
| Service URL | `/sap/opu/odata4/sap/zui_arena_change_appr_o4/srvd/sap/zui_arena_change_approval/0001/` |
|
|
| Schema namespace / alias | `com.sap.gateway.srvd.zui_arena_change_approval.v0001` / `SAP__self` |
|
|
| Entity type / entity set | `ChangeApprovalType` / `ChangeApproval` |
|
|
| Bound actions | `approve`, `reject(RejectReason)`, `retrySync` |
|
|
|
|
Only the first URL segment comes from the service **binding** name. The schema namespace comes
|
|
from the service **definition** name, and the entity type carries a `Type` suffix without an
|
|
underscore (live `$metadata`, 2026-09-16; see `KNOWLEDGE.md`). The pre-V-2 assumption of a
|
|
binding-derived namespace and a `_Type` suffix was wrong.
|
|
|
|
`webapp/manifest.json` (`sap.app.dataSources.mainService.uri`), `ui5-mock.yaml` /
|
|
`ui5-local.yaml` (`sap-fe-mockserver` `urlPath`) and `webapp/annotations/annotation.xml`
|
|
(`edmx:Reference`, every `Annotations Target`, every `DataFieldForAction.Action`) must stay in
|
|
sync with it. JSON cannot carry comments, so the manifest references this note instead.
|
|
|
|
**Annotation layering.** The backend metadata extension already emits most UI annotations
|
|
(LineItem, HeaderInfo, Facets, FieldGroups, Identification, SelectionFields, SemanticKey,
|
|
`Status` text with `TextOnly`). An annotation in `annotation.xml` replaces the backend annotation
|
|
with the same term + qualifier on the same target, and deleting it there makes the backend one
|
|
effective again [source: fiori-mcp-server "Visualizing and Managing Annotations with SAP Fiori
|
|
Tools - Service Modeler", verified 2026-09-16].
|
|
|
|
**Backend for a non-mock run: not configured.** `ui5.yaml` and `ui5-local.yaml` carry
|
|
`fiori-tools-proxy` with `backend: []`, and `npm start` is a generator placeholder. When a live
|
|
preview is added, the backend recorded for the client 080 track is the **UI host**
|
|
`https://my431353.s4hana.cloud.sap`, never the `-api` host: a business-user call there is blocked
|
|
by UCON (live 2026-09-16, `KNOWLEDGE.md`). That tenant — the starter system's development tenant —
|
|
is **parked as of 2026-09-29**, so this binding is a reference point, not a live target; the
|
|
working target is the starter system's customizing tenant `my429480` (client 100).
|
|
|
|
## Status model and actions
|
|
|
|
`Status`: `PENDING -> APPROVED -> EXECUTING -> SYNCED | FAILED`; `REJECTED` is terminal;
|
|
`FAILED -> retrySync -> APPROVED`. `approve`/`reject` are enabled only for `PENDING`,
|
|
`retrySync` only for `FAILED`. The backend owns enablement: RAP emits
|
|
`Core.OperationAvailable Path="_it/__OperationControl/<action>"` for the `( features : instance )`
|
|
actions (PRD RAP-1), and the app keeps no local `OperationAvailable`, which would replace it
|
|
[source: fiori-mcp-server "Action Control for Context-Dependent Actions (SAP Fiori Elements)",
|
|
verified 2026-09-16]. `IsApprovable` / `IsRetriable` are still in the service but hidden, and
|
|
nothing in the app binds to them.
|
|
Actions are offered on the object page header only; the list report table is display-only
|
|
(`selectionMode: "None"`).
|
|
|
|
## Launchpad
|
|
|
|
`sap.app.crossNavigation.inbounds` declares the intent `ArenaChangeApproval-manage`; on
|
|
deployment to the ABAP environment the launchpad app descriptor item (target mapping + tile) is
|
|
generated from it, and an IAM app / business catalog / business role make it visible
|
|
[source: sap-docs /btp-cloud-platform/30-development/sap-fiori-applications-in-the-abap-environment-1d9deef, verified 2026-09-14].
|
|
`sap.fiori.registrationIds` stays empty: it holds SAP Fiori IDs of SAP-delivered apps and is not
|
|
required for a custom app (only `archeType` is mandatory)
|
|
[source: sap-docs /sapui5/04_Essentials/manifest-descriptor-for-applications-components-and-libraries-be0cf40, verified 2026-09-14].
|
|
|
|
Dev server: `npm run start-mock` / `npm run int-test` bind to port **8082** (8080 is taken on
|
|
the dev host). Mock data lives in `webapp/localService/mainService/data/ChangeApproval.json`
|
|
(`generateMockData: false`), 8 rows covering every status. Each row carries every live property:
|
|
`StatusText` / `StatusCriticality` as `ZR_CHANGEAPPROVAL` computes them, `__OperationControl`
|
|
consistent with the status, `LocalLastChangedAt`, and `SAP__Messages: []`. Initial CHAR values are
|
|
`""`, not `null`, on `Nullable="false"` properties. The mock server does not execute bound
|
|
actions (see `KNOWLEDGE.md`), so status transitions show only against the live service.
|
|
|
|
## app
|
|
|
|
An SAP Fiori application.
|
|
|
|
### Starting the generated app
|
|
|
|
- This app has been generated using the SAP Fiori tools - App Generator, as part of the SAP Fiori tools suite. To launch the generated application, run the following from the generated application root folder:
|
|
|
|
```
|
|
npm start
|
|
```
|
|
|
|
- It is also possible to run the application using mock data that reflects the OData Service URL supplied during application generation. In order to run the application with Mock Data, run the following from the generated app root folder:
|
|
|
|
```
|
|
npm run start-mock
|
|
```
|
|
|
|
#### Pre-requisites:
|
|
|
|
1. Active NodeJS LTS (Long Term Support) version and associated supported NPM version. (See https://nodejs.org)
|
|
|
|
|