Where every request actually goes.
Three paths leave the browser. Two of them never leave your landscape, and the third carries no record data at all. This is the page to send an integration architect.
Everything inside the dashed frame is yours — your FSA tenant, your BTP subaccount, your S/4 system, your credentials. The only path that leaves it carries a licence key and an account id, and comes back with a list of entitlements.
The three paths
Browser to your FSA cluster
The extension runs inside the FSA Shell and calls the FSA APIs directly, with the access token the Shell already issued it. Service calls, activities, business partners and your user-defined objects all travel this way. Nothing proxies it.
Browser to your engine, and your engine to S/4
Anything involving S/4 goes to the engine you deployed into your own BTP Cloud Foundry space. It holds your S/4 connection, reaches the system through SAP Cloud Connector or a Communication Arrangement, and answers the browser. Both ends of that path are infrastructure you own.
Browser to our licence service
On load, the extension asks Altiwerk whether this tenant's licence is valid and what it covers. It sends an account id and a licence key, and gets back a verdict and a list of entitlements. That is the entire conversation, and the answer is cached for an hour.
The parts worth arguing about
S/4 sees the technician, not a service account
The engine propagates the caller's identity to S/4 rather than replacing it with one shared technical user. What a technician can read and change is exactly what S/4 already says they can — the authorisation work your team has already done is the authorisation model here too.
This matters more than it sounds. A connector with a service account is a connector where every user effectively has the union of everyone's rights, and where an audit cannot tell you who changed a record.
It learns your system instead of assuming it
Entity types, sets, keys, navigation properties and which fields are filterable are read from the service's own metadata document. There is no shipped map of “what S/4 looks like” to fall out of date, which is why a service you activate next quarter needs no release from us.
The same mechanism formats keys and filters correctly per service version. Dates, GUIDs and numbers each have a form the service in front of you expects — getting it wrong is the difference between a record and an HTTP 400, and it is not the same answer for V2 and V4.
Writes are opt-in, and never silent
The engine can only write to entities that have been explicitly allowed. It is not a permission it can grant itself, and it is not a default.
Every write carries a concurrency check. If someone changed the record first, the user is shown the conflict and decides — a write is never quietly applied over someone else's. A rejected batch is re-planned into the smallest units that can succeed, so one bad field does not cost the other forty rows.
Both S/4 deployment shapes work
On-premise systems are reached through SAP Cloud Connector; cloud systems through a Communication Arrangement. The engine does not care which — it is the same OData either way, and the difference is a connection setting rather than a different product.
On start-up it probes the S/4 host and reports what it found, so a private certificate authority or a self-signed test system is a known state rather than a mystery failure at the first request.
Send this to your architect.
We will answer the follow-up questions in writing, including the ones about identity propagation and write scope.