SOAP
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.
Use SOAP when integrating with systems or middleware that require it, or where a formal contract and WS-* capabilities matter.
- SOAP services exchange XML messages defined by a WSDL contract, offering strong typing and formal contracts suited to enterprise…
- SOAP services are configured and managed with SOAMANAGER (endpoints, bindings, security).
- 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.