Lesson 3 of 5
SOAP and enterprise services
10 min
Listen to this lesson
SOAP services are older than OData in the SAP world but far from gone. SAP S/4HANA still offers many SOAP-based services for business-to-business and application-to-application integration, often asynchronous, and plenty of customer and partner integrations depend on them. A SOAP test has the same goal as any service test: prove the contract and the business result. The tooling is just more formal.
The contract: WSDL and schema
A SOAP service is described by a WSDL: its operations, the messages they exchange and the XML schema of each message. That makes SOAP the most contract-driven of the three interface styles, and your tests should use it. Generate request templates from the WSDL, validate every response against the schema, and keep the WSDL under version control next to the tests so that a changed contract is visible as a diff. SAP's own eCATT does exactly this for its WEBSERVICE command: it generates an ABAP proxy class from the WSDL, and if the service changes you regenerate the proxy.
- WSDLImport the service description; store it with the tests.
- Request templateGenerate the request from the schema; fill it with test data.
- SendCall the endpoint over HTTPS with the configured authentication.
- Schema checkValidate the response or confirmation message against the schema.
- Business checkRead the resulting document in the system and compare with the expected result.
Endpoints and logical ports
In an ABAP system, SOAP services are configured in SOAMANAGER, where service endpoints and consumer logical ports are maintained. The eCATT documentation describes how a test can point a web service call at a target system through an HTTP destination, temporarily overriding the URL of the logical port. The general lesson for any tool: never hard-code the endpoint URL in the test. Keep it in environment configuration so the same test runs against CMQ today and a sandbox tomorrow.
Faults are part of the contract
SOAP 1.2 defines a standard Fault element in the response body with a mandatory Code and Reason and an optional Detail for application-specific information. The standard codes distinguish a Sender fault, where the message was wrong and should not be resent unchanged, from a Receiver fault, where processing failed for reasons unrelated to the content and may succeed later. Your negative tests should check that a bad request produces the expected fault and detail, not just "some error". Many SAP business services also report business errors inside a normal response or confirmation message log rather than as a fault, so read the service documentation and assert on the right place.
| Result type | Where it appears | What to assert |
|---|---|---|
| Success | Response or confirmation message with document IDs | Schema valid; document exists in S/4HANA with expected values |
| Business error | Message log in the response or confirmation (service-specific) | Expected message type and text; no document created |
| Sender fault | SOAP Fault with Code Sender | Malformed or incomplete request is rejected with a useful reason |
| Receiver fault | SOAP Fault with Code Receiver | Infrastructure problem; test should fail, not pass |
Synchronous versus asynchronous
A synchronous service answers in the same HTTP exchange. An asynchronous service accepts the message and processes it later, sending a confirmation through another channel or making the result visible only in the system. For asynchronous services, the test cannot assert on the HTTP response alone. Poll for the outcome with a timeout: look for the document by a unique reference you sent, or check the message monitoring in the system, exactly as you would wait for a Fiori screen to settle. Log the message ID so a failure can be traced in the monitor.
What would you do?
A SOAP test for the journal entry service passes: the response is schema-valid and has no fault. Dan finds that the entry was never posted because the period was closed. What should the test have done?
- The WSDL is the contract: generate requests from it, validate responses against it, version it with the tests.
- Keep endpoints in environment configuration (SOAMANAGER logical ports, destinations), not in test code.
- SOAP faults have Code, Reason and Detail; Sender and Receiver faults mean different things.
- Business errors may arrive in a normal response or confirmation; assert on the posted document.
- For asynchronous services, poll for the outcome by a unique reference with a timeout.
Check your understanding · not graded
Lesson check
1. What should a SOAP test use as its contract?
2. In SOAP 1.2, what does a Sender fault indicate?
3. How should a test verify an asynchronous SOAP service?
4. Where are SOAP service endpoints and logical ports configured in an ABAP-based system?