Integrations — Ingestion sources
NerveStax and SAP
Point an agent at your SAP OData service and it proposes the load as a pull request.
What we do
What NerveStax does with SAP
An agent connects to SAP over OData, reads the service, and proposes a load: which entity sets, which field to sync on, and how often. That proposal arrives as a pull request. This covers the common SAP extraction use case today, and the loading layer is built to take whatever else a system presents.
-
Reads your SAP OData service
An agent connects to the service, lists the entity sets it exposes and what each one carries, and reports what a load would involve before anyone commits to it. No hand-written spec needed.
-
Proposes the load as a pull request
The entity sets, the field to sync on and the cadence become configuration in your repository, reviewed like any other change. Nothing starts loading because an agent thought it should.
-
Covers the common SAP setups
Four authentication modes, including SAP Business One, so S/4HANA, ECC through the SAP Gateway and SAP's cloud services are reached the same way. Something unusual, we add the path for it.
-
Stays on the system you named
A guard holds every request to the SAP host you configured. A redirect or a crafted response cannot send a session or its token to another server.
-
Detects source schema changes
Added, dropped, renamed and retyped fields in an entity set are classified: informational, needs review, or needs a re-sync. A change reaches you as a decision, not a broken load.
-
Installing and running need approval
Installing, running, stopping or re-syncing a load stops for a person every time. These are irreversible actions, so they are refused rather than auto-approved when nobody is there.
Background
About SAP
SAP is the enterprise software that runs finance, supply chain and operations for many large businesses. Its data is reached through OData services, SAP's standard protocol for reading business objects out of S/4HANA, ECC and SAP's cloud products.
How it connects
What connecting it looks like
-
01
Choose an OData service
Point us at the SAP OData service that carries the data you need. Most SAP systems already publish them for reporting and extraction.
-
02
Add the connection
Host and credentials for one of the supported authentication modes. They are stored encrypted, and can be replaced but never read back.
-
03
Ask an agent to plan the load
It reads the service, lists entity sets, and proposes which to load, the field to sync on and a cadence, with what each choice means.
-
04
Review the pull request
The load is configuration in your repository. Approve it, then approve the install, and the first run is scheduled like anything else.
Scope
What this does not cover
- Loaded entity sets land in your destination as their own schema, declared as dbt sources, so the models built on them are ordinary code in your project.
- OData is the interface today — SAP's standard data-access protocol, which covers the common reporting and extraction needs across S/4HANA, ECC and SAP's cloud products. A system or interface we do not reach yet, you bring us and we add it.
- Change data capture is not built. A stream is incremental on a field you sync on, or a full copy, which is how most SAP extraction runs in practice.
Questions
SAP and NerveStax
Q01Which SAP systems does this work with?+
Any SAP product that exposes OData services, which is most of them: S/4HANA, ECC through the SAP Gateway, and SAP's cloud applications. Four authentication modes are supported, including SAP Business One. If your system presents data a way we do not reach yet, tell us and we add that path.
Q02What is the common use case you support?+
Extracting business data out of SAP over OData — finance, orders, master data, whatever an entity set exposes — into your warehouse as dbt sources, on a schedule, reviewed as a pull request. That covers most of what teams ask SAP ingestion for. Anything beyond it, we build to the specific system.
Q03Is it safe to connect to our SAP system?+
The connection reads data to load it; credentials are stored encrypted and never shown back. A guard holds every request to the SAP host you configured, so a redirect or crafted response cannot send a session or its token elsewhere. Installing or running a load always waits for a person.
Q04Can an agent start loading on its own?+
No. Installing an ingestion, running one, stopping one or re-syncing a stream each wait for a person, and they are the class of action that can never be auto-approved. The load configuration itself arrives as a pull request your team reviews first.
Q05Where does the data land?+
In your destination, in its own schema, declared as dbt sources so your models read it as normal. The model provider is not in the load path: it sees the plan and the entity-set and field names, not the rows that move from SAP to the destination.