SAP S/4HANA package v1.0.0

Credentials of an inbound communication user on the customer's own S/4HANA Cloud tenant, held in the client's own secret manager. The stored material must be the complete Authorization header value (scheme included): 'Basic', one separating space, then the base64 of 'user:password' — 'Basic <base64>'. An external deployment process creates the communication user and the Communication Arrangements that publish these services (for example SAP_COM_0008 for the business partner service), rotates the password, and stores the renewed header value; the executor injects the stored value verbatim and performs no credential lifecycle itself. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only.

Passwords expire under the tenant's password policy and a communication user can be locked or deleted at any time, which revokes access; an expired or revoked value fails closed.

Least privilege: assign the user only the communication scenarios that publish the services this pack registers, and nothing more. Authorization granularity: a communication scenario publishes its services to the assigned inbound user, and the operation-level authority the user then holds is whatever the scenario's business catalogs and authorization objects grant — scenario assignment alone does not deny individual CRUD or release operations inside a published service.

The deployment must therefore verify the residual authority of the assigned scenarios (for example, whether the purchase order scenario also authorizes the update and delete operations this pack does not register) rather than assume exclusion by registration; residual authority the scenario cannot remove is a reviewed deployment risk, not a pack control. This registration stores a Basic header; certificate-based or OAuth 2.0 inbound authentication, where the deployment supports it, is a separately reviewed authentication change, not an interchangeable alternative to this credential contract.

Review rotation cadence before enabling.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The endpoint host 'sap-instance.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own S/4HANA Cloud tenant host before enabling, in every endpoint, in every resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step — the reserved host being allowlisted does not make an unsubstituted pack safe to enable.

This pack registers only endpoints SAP's official documentation for SAP S/4HANA Cloud describes: the OData V4 Purchase Order API (service group api_purchaseorder_2, repository srvd_a2x, service purchaseorder, version 0001) for purchase order read and create, and the OData V2 services SAP documents for business partners (API_BUSINESS_PARTNER), supplier invoices (API_SUPPLIERINVOICE_PROCESS_SRV) and journal entry items (API_JOURNALENTRYITEMBASIC_SRV). SAP deprecated the OData V2 purchase order API in favour of the OData V4 service, which is why the purchase order capabilities register the V4 path; this pack makes no claim that OData V4 equivalents of the other three objects do not exist — it registers the services SAP documents for them.

All reads are collection reads only: single-record reads (A_BusinessPartner('...'), A_SupplierInvoice(SupplierInvoice='...',FiscalYear='...'), PurchaseOrder(PurchaseOrder='...')) exist in the APIs and are deliberately not registered.

Documented exclusions, framed as what this pack does not register: business partner create, update and delete (the Business Partner (A2X) service documents full CRUD); supplier invoice create, release and the single-invoice deep read (the Supplier Invoice service is documented as Create, Read, Release, Reverse with POST on A_SupplierInvoice); purchase order update and delete (SAP documents the V4 service as create, read, update and delete — this pack registers create and read only); journal entry posting (the SOAP service JournalEntryBulkCreationRequest_In and any other posting API); and every other OData service on the tenant.

The services are exposed through Communication Arrangements on the tenant, and each arrangement's inbound communication user carries only the authorizations of the scenarios it is assigned: the registration records the endpoint, not the tenant's authorization decision — a capability works only if the communication user is permitted the operation. Modifying requests against SAP Gateway require an X-CSRF-Token: the deployment's HTTP adapter must fetch one (x-csrf-token: Fetch) against the same service root before issuing the registered POST, and that adapter wiring is a deployment step, not something this pack performs.

Approval classification: the collection reads sit at the minimum R0 tier of read. The purchase order create is registered at R3 declaring create and send: SAP documents that a purchase order subject to a release procedure cannot be outputted (printed or transmitted directly to the vendor) before release, but output determination and dispatch timing are tenant configuration, so on a tenant whose output management dispatches immediately on save with no release procedure the create can transmit the order to the supplier — the send effect is declared rather than assumed away.