Connecting on-prem SAP S/4HANA
Daslab talks to S/4HANA through SAP's released OData APIs — the same interfaces SAP's own cloud products use. They ship with every S/4 system, cloud or on-premise, so connecting an on-premise system needs no custom development on either side. Two things have to be true: Daslab can reach your system over HTTPS, and there is a user allowed to call the APIs. This guide covers both.
What to send your Basis team
Your Basis team activates the OData services and creates a technical user. This is routine integration work, usually about a day; you can forward this section as-is.
First, activate the ICF node /sap/opu/odata (transaction SICF). Then register these services in /IWFND/MAINT_SERVICE:
| Service | Used for |
|---|---|
API_BUSINESS_PARTNER | Customers and suppliers |
API_SALES_ORDER_SRV | Sales orders |
API_PRODUCT_SRV | Products and materials |
API_PURCHASEORDER_PROCESS_SRV | Purchase orders |
API_SUPPLIERINVOICE_PROCESS_SRV | Supplier invoices |
API_BILLING_DOCUMENT_SRV | Billing documents |
Add the delivery, material-document, and process-order APIs if you use the manufacturing flows. Activate only what you need — it keeps the authorization role tight.
Then create a technical user (System type), for example DASLAB_ODATA, with a role limited to the activated services via S_SERVICE, plus display authorizations on the business objects behind them. Read-only for everything except the flows Daslab should write, such as creating sales orders. Basic auth over TLS is normal for a pilot; OAuth with principal propagation can come later in production.
HTTPS terminates on ICM (port 443xx), often behind SAP Web Dispatcher. When this is done you have the two things Daslab needs: a service URL and a user.
How Daslab reaches the system
Your S/4 sits in a private network, so traffic needs a path in. Three patterns, in the order most teams should try them:
An outbound tunnel — the usual choice for a pilot. A small service inside your network dials out on port 443 and relays requests to the SAP host: no inbound firewall change, nothing exposed publicly. SAP Cloud Connector is the SAP-standard version — free, runs on any small VM, exposes only the URL paths you whitelist, and your security team will recognize it; the connection then runs through a BTP subaccount, which matches Daslab's OAuth mode. A cloudflared-style tunnel is the vendor-neutral version — runs on any machine in the network, you point Daslab's Service URL at the tunnel hostname and protect it with access tokens or mTLS; live in a day, no BTP needed, matches Basic auth. A site-to-site VPN — the classic corporate answer and the heaviest: IPsec between networks, routing agreements, security review on both sides. Weeks rather than days; keep it for production if your IT mandates it. A DMZ reverse proxy exposing Gateway publicly is technically possible, but SAP recommends against it and most security teams will refuse. Don't lead with it.Enter it in Daslab
On the Connect SAP S/4HANA sheet, pick the mode that matches your path:
- OAuth Client Credentials — Cloud Connector and BTP. Paste the BTP service-key JSON to fill the fields, and set the Service URL to your destination host.
- Basic Auth — the tunnel pattern, or any directly reachable host. Enter the technical user, its password, and the Service URL.
- Sandbox — SAP's public API Business Hub, for trying the integration before your own system is reachable.
Check that it works
Pin a business partner and open their sales orders — if that round trip works, the connection is good. If a query fails, ask the agent what's missing: it can list the services your system actually exposes and compare them against the table above.