Skip to content

SAP OData

DataMaker speaks SAP OData natively. Point it at any V2 or V4 service (S/4HANA Cloud, S/4HANA on-prem via SAP Cloud Connector, BTP services, or a third-party SAP) and you get:

  • $metadata discovery: every entity set, every property, with types and Nullable flags.
  • Auto-CSRF: we fetch the x-csrf-token and replay it on every modifying request.
  • $filter queries: pull existing rows out for regression datasets.
  • Direct POST: push generated data into entities, batch-aware.
  • No Z-customisations needed: we use the standard A2X services.

This is the same connection that powers the SAP regression and SAP TDMS alternative flows.

Create a SAP OData connection

Project → Connections → New → SAP OData. Fill in:

  • Name: e.g. S/4 Sandbox.

  • Service URL: root of the OData service. Examples:

    • S/4HANA Cloud: https://my-tenant.s4hana.cloud.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER_SRV
    • On-prem via Cloud Connector: https://my-cc.example.com/sap/opu/odata/sap/API_BUSINESS_PARTNER_SRV
    • BTP destinations: paste the destination URL.
  • OData version: V2 or V4 (auto-detected from $metadata if you leave it on Auto).

  • Auth: basic, oauth2-client-credentials, or destination (BTP).

Click Verify. We fetch $metadata, parse it, and list the entity sets we found.

What $metadata discovery gives you

After verification, the connection knows about every entity set:

Discovered 47 entity sets:
• A_BusinessPartner (28 properties)
• A_BPAddress (43 properties)
• A_BPBankDetails (16 properties)
• A_BPRole (5 properties)
...

Each property carries:

  • Its OData type (Edm.String, Edm.Decimal(15,2), etc.).
  • Nullable flag.
  • For string types, MaxLength.
  • For navigation properties, the related entity set.

The template builder uses this to validate generated data against the entity definition before you try to POST.

Auto-CSRF

OData V2/V4 modifying requests need a CSRF token. The flow is:

  1. GET / with X-CSRF-Token: Fetch → response carries a token in X-CSRF-Token.
  2. Subsequent POST/PUT/PATCH/DELETE requests include X-CSRF-Token: <that-token>.
  3. The token has the same lifetime as the auth session.

DataMaker handles all of this transparently. You never see a 403 because of CSRF.

Push a generated set into an entity

Pushing into SAP is agent-driven: describe it in chat and the agent uses its SAP tools with the connection you configured above:

Generate 25 Business Partners from the Business Partner template and POST them to the A_BusinessPartner entity on the S/4 Sandbox connection.

Behind the scenes DataMaker:

  • fetches a CSRF token (and reuses a cached one),
  • POSTs each row to /A_BusinessPartner,
  • maps your template fields to the OData properties (saved per template per connection),
  • reports per-row status, including the BusinessPartner ID SAP returns.

Fetch existing records ($filter)

For regression workflows, ask the agent to pull existing rows that match a filter; it has the SAP fetch tools:

Pull existing A_BusinessPartner records from S/4 Sandbox where Country = DE and Industry = HIGH_TECH. Return BusinessPartner, BusinessPartnerName, and TaxNumber1, top 200.

You get back a set of rows you can feed into the rest of the flow: build a template from them, mask sensitive fields, push them into a different connection, and so on.

Batch processing

For large pushes, OData V2 and V4 both support $batch (with different shapes). DataMaker batches rows into multipart $batch requests and handles CSRF, errors, and ChangeSet boundaries per the OData spec, so you don’t wire it up per call.

Auth: BTP destinations

If you’re on SAP BTP, the cleanest auth path is a destination. In the connection form:

  • Pick Auth → BTP destination.
  • Provide the destination’s tenant URL and the destination name.
  • Authenticate via OAuth2 client credentials against the destination service.

DataMaker resolves the destination at use-time and uses whatever auth the destination is configured for (BasicAuthentication, OAuth2SAMLBearer, OAuth2UserTokenExchange…).

OData V4 vs V2

We handle both. Notable differences our connection abstracts away:

  • V2 uses $inlinecount=allpages, V4 uses $count=true.
  • V2 wraps responses in d.results, V4 uses value.
  • Date/datetime types differ (Edm.DateTime vs Edm.DateTimeOffset).

In your template, just pick “Date” and DataMaker emits the right format on the wire.

Troubleshooting

  • 403 CSRF token validation failed → the connection’s session expired between fetch and POST. We’ll retry; if it persists, check your auth.
  • 400 Property X is required → your template is missing a non-nullable property. Open the entity in the metadata view and look for Nullable=false properties without defaults.
  • 500 Business Partner type ... not allowed → SAP-side validation; this isn’t a DataMaker bug. Check your BusinessPartnerCategory and BPRole values.

For more, see Troubleshooting → CSRF & auth.