Stop Using SOAP Adapters for Modern S/4HANA Integrations

I've debugged the same Integration Suite issue on three different LATAM projects this quarter: teams defaulting to SOAP adapters when REST would do the job in half the time.

The pattern I keep seeing

A developer needs to call an S/4HANA API from BTP Integration Suite. They see "adapter" in the palette, spot SOAP first, and think "enterprise integration means SOAP." Two days later, they're wrestling with WSDL imports, namespace mappings, and SOAP envelope structures that add zero business value.

The reality: most modern S/4HANA APIs expose OData services over REST. Using a SOAP adapter for these is like bringing a forklift to move a chair.

When SOAP actually makes sense

Don't misunderstand — SOAP isn't dead, just overused. You need it when:

• Legacy systems require WS-Security — think older on-premise SAP systems with certificate-based authentication baked into SOAP headers
• Existing WSDL contracts are mandatory — some enterprises have governance requiring WSDL-first design for audit trails
• Transaction coordination matters — WS-AtomicTransaction and similar protocols, though rare in cloud scenarios

If none of these apply, you're adding complexity for nostalgia.

The REST adapter setup that works

Here's the configuration I use on every S/4HANA integration where SOAP isn't technically required:

Connection settings:

• Address: https://your-s4-system.com/sap/opu/odata/sap/API_BUSINESS_PARTNER
• Authentication: OAuth2 Client Credentials
• Token Service URL: from your S/4HANA communication arrangement
• Response Format: application/json

Error handling specifics: This is where most guides stop, but production integrations need different retry logic for different failure modes:

• 4xx errors (client errors) — don't retry, log to message monitoring, send to exception subprocess. The request is malformed; retrying won't fix it.
• 5xx errors (server errors) — enable exponential backoff with 3 retries. S/4HANA might be temporarily overloaded or restarting.

Add a script step after the HTTP call:

def statusCode = message.getHeaders().get("CamelHttpResponseCode")
if (statusCode >= 500) {
    message.setHeader("RetryEligible", true)
} else if (statusCode >= 400) {
    message.setHeader("RetryEligible", false)
    message.setProperty("ErrorCategory", "ClientError")
}

Testing advantage: REST adapters let you test directly in Postman or curl before deploying to Integration Suite. With SOAP, you're hunting through SoapUI or building test harnesses. I've cut integration testing time by 40% just by choosing REST where possible.

Real project example

Last month in São Paulo: a team spent four days building a SOAP-based supplier onboarding integration. The S/4HANA Business Partner API they were calling had been OData REST since 1909 release. We switched to REST adapter, OAuth2, and the same integration worked in six hours — including proper error handling.

The SOAP version would have worked eventually. But "eventually" matters when you're billing by the day and the client is waiting to go live.

Performance differences

REST with JSON typically runs 15-20% faster than equivalent SOAP XML in my load tests — not because REST is magic, but because:

• Smaller payload sizes (JSON is more compact)
• No envelope parsing overhead
• Native JSON-to-object mapping in Groovy scripts
• Better caching at HTTP level

Not earth-shattering, but when you're processing 10,000+ messages daily, it compounds.

Key takeaways

• Default to REST for S/4HANA OData APIs unless you have a specific reason for SOAP
• Configure OAuth2 client credentials, not basic auth, for production
• Split error handling: don't retry 4xx, do retry 5xx with backoff
• Test REST endpoints outside Integration Suite first — saves deployment cycles

SOAP made sense when systems had no other standard. Now it's a choice, not a default. Choose deliberately.

---

If you're building SAP BTP integrations and want a second opinion on architecture decisions, book a 30-minute discovery call at markus-mildner.com — I review integration designs weekly for teams across LATAM and Europe.