SAP SOAP Web Services
SOAP web services are SAP’s XML-based, standards-driven interface for service-oriented integration, older than REST/OData but still used for enterprise integrations and where a WSDL contract is required.
SOAP in SAP exchanges XML messages against a WSDL contract, which gives strong typing and a formal agreement suited to enterprise SOA. SAP exposes function modules and BAPIs as SOAP services and consumes external ones through SOAMANAGER, which handles endpoints, bindings and WS-Security. OData is the direction for new work; SOAP stays where a partner or contract requires it.
- Format: SOAP is XML; OData is JSON.
- Watch out: Choosing SOAP for new lightweight integrations (prefer OData).
What SOAP provides
SOAP services exchange XML messages defined by a WSDL contract, offering strong typing and formal contracts suited to enterprise SOA. SAP can expose function modules/BAPIs as SOAP services (via SOAMANAGER) and consume external SOAP services. Middleware like SAP PI/PO heavily used SOAP.
SOAP vs REST/OData
- Format: SOAP is XML; OData is JSON.
- Contract: SOAP has a formal WSDL; OData has a metadata document.
- Style: SOAP is operation-centric; OData is resource-centric.
- Direction: new work favours OData; SOAP remains for legacy SOA.
Configuring SOAP in SAP
SOAP services are configured and managed with SOAMANAGER (endpoints, bindings, security). Both provider (SAP exposing a service) and consumer (SAP calling one) scenarios are supported. Security (WS-Security, transport encryption) and correct WSDL handling are key.
When to use it
Use SOAP when integrating with systems or middleware that require it, or where a formal contract and WS-* capabilities matter. For new, lightweight or UI integrations, prefer REST/OData.
Common pitfalls
- Choosing SOAP for new lightweight integrations (prefer OData).
- WSDL/contract mismatches.
- Weak SOAP security configuration.