Live S/4 data inside FSA. On your BTP, not ours.
Live, on-demand S/4 data inside your extensions — running on your own BTP, not ours. It is a service you deploy into your own Cloud Foundry space, so your S/4 credentials and your S/4 traffic never leave your landscape — and the technician's own authorisations are what S/4 sees.
- V2 + V4
- one client, both OData generations
- 13
- curated S/4 mappings
- 4
- sync patterns
- 3
- of our products run on it
Your integration platform is not doing this job — and should not be.
CPI, PCC and MDI move bulk master data between FSA and S/4 on a schedule.
The engine moves live, contextual, record-scoped data inside extensions and UDOs, on demand.
Different quadrant, different buyer, no channel conflict. If your middleware already replicates master data on a schedule, keep it. This answers the other question — the one a technician asks about this record, right now, where a copy taken last night is simply the wrong answer.
Every integration people actually ask for, in four shapes
Which one you want is a question about the data, not about the technology. All four are configuration.
Live read-through
The extension reads S/4 each time it renders. Nothing is stored in FSA.
Reach for it when: Stock levels, warranty, credit status — anything that is wrong the moment it is copied.
On-demand pull into a UDO
A user or an event pulls a snapshot of an S/4 record into an FSA object.
Reach for it when: Attaching an S/4 document to a job, or giving the field an offline fallback.
Push back to S/4
Edits go back as PATCH or POST with ETag concurrency, and a conflict is surfaced rather than silently overwritten.
Reach for it when: Readings, confirmations and corrections captured in the field.
Event-triggered
An FSA event fires any of the above with no button to press.
Reach for it when: Refresh on activity open, or push on status change.
20 things you would otherwise build yourself
Speaks your system's OData, whichever generation it is
OData V2 and V4 in one client
SAP is migrating services from SEGW V2 to RAP V4. The same screen configuration works against either, so a service that moves underneath you does not become a project.
Driven by $metadata, not by hard-coding
Entity types, sets, keys, navigations and filterability are read from the service itself. The connector learns your system instead of shipping a fixed map of it.
Correctly typed keys and filters
Dates, GUIDs and numbers are formatted the way your service version expects them — the difference between a record and an HTTP 400.
One filter language, compiled per service
Filters are authored once as structured criteria and compiled into $filter for the version and types in front of them.
Discovery
Point it at a system and it reports what is actually exposed: services, entity sets, fields, value helps and which fields are required.
Writes safely, or not at all
ETag concurrency and 412 handling
Every write carries If-Match. If someone changed the record first, the user is told and shown the difference — nothing is overwritten quietly.
Writes are opt-in, per entity
The engine can only write to entities that have been explicitly allowed. It cannot write what you did not turn on.
Deep insert
A header and its items are created in a single call, so a half-written document is not a state you can reach.
Batch
Related reads and writes travel together instead of as a burst of round trips.
Runs in your landscape
Self-hosted on your own BTP
The engine is a Node service you deploy to your own Cloud Foundry space. Your S/4 credentials and your S/4 traffic stay inside your landscape — they never transit ours.
The technician's own authorisations
Identity is propagated to S/4 rather than replaced by a shared service account, so what a user can see and change is what S/4 already says they can.
On-premise or cloud S/4
Reached through SAP Cloud Connector or a Communication Arrangement — both deployment shapes work.
TLS sorted at boot
The engine probes your S/4 host on start-up: a verified certificate stays verified, a private CA or self-signed rehearsal system just works, and it says which it found.
Is my engine current?
One health request answers it — version, commit and build time, so a stale deployment is visible rather than suspected.
Fits whatever you already build with
The contract is plain HTTP
Angular, React or plain JavaScript; npm, pnpm or Yarn; monorepo or not. Nothing about the engine assumes your toolchain, because the only interface is a URL.
Optional client SDKs
If you want the sugar, there is a thin client and a UI kit with a refresh and push control, a status badge and a conflict dialog. If you do not, a few fetch calls are the whole integration.
Curated mapping templates
Verified mappings for the most-used S/4 objects, so the first screen starts from something that already works.
Mappings are validated against the live service
A mapping can be checked against the system's own $metadata, which catches a broken binding before a user does.
Licensed, and enforceable
Two gates on every request
The engine checks that it is itself licensed, then that the caller is a tenant that licence covers. Both are signed, and neither can be talked around from the browser.
Survives an outage, still ends on time
The engine's licence renews on an hourly lease and is verified offline, so a network problem never stops a field team — but a contract that genuinely ends is enforceable without a redeploy.
Systems of record it reaches today
SAP S/4HANA
from SAP Field Service and Asset Management
Read live, snapshot into FSA, and write back with concurrency checks. Thirteen curated mappings for the most-used objects, and discovery for everything else.
Any system exposing OData V2 or V4 services, reached through SAP Cloud Connector or a Communication Arrangement — on-premise and cloud alike.
Which release of S/4 do we need?
There is no version floor to check. If your system exposes the OData service — V2 from the older gateway, or V4 from RAP — and your engine can reach it, the connector reads it. That covers S/4HANA Cloud and on-premise alike, because the question it asks is about the service, not the release.
The interface is a URL
Our own products are just the first consumers. The contract between an extension and the engine is plain HTTP — no shared framework, no build-time coupling, no opinion about your toolchain. Angular, React or fifty lines of fetch; npm, pnpm or Yarn; your monorepo or ours, which is to say neither.
If you want the sugar there are thin client and UI packages — a refresh-and-push control, a status badge, the conflict dialog — and if you do not, ignoring them costs nothing, because they are a convenience over the same URLs you would have called.
Two gates on every request
- 1The engine proves it is licensed — a signed token it verifies offline and renews on a short lease, so a network problem never stops a field team.
- 2The caller proves it is a tenant that licence covers. A browser cannot talk its way past either one.
Between them, an engine you run yourself is still an engine whose contract can end on time — without anyone asking you to redeploy anything.
Where the data goesBring your integration architect.
We will walk them through the request path, the write safety and the licence gates, and answer the awkward questions in writing.