Within the Bridge, it is important to differentiate between the following scenarios:
- a SOAP call via an adapter within a service (see SOAP Adapter)
- the called SOAP service itself
In this section you will find information on the called SOAP service itself.
The Bridge supports SOAP version 1.1, and SOAP version 1.2 for document-literal encoded services.
The Bridge supports SOAP 1.1. as well as SOAP 1.2, whereas SOAP 1.2 is only supported for document-literal encoded services. Which version to use for your web service is your choice. However, be aware of the fact that using document-literal encoded operations you will have to directly edit the SOAP request in test cases of the SOAP Test Tool and the E2E Analyzer to provide input parameters.
SOAP messages are mapped to UML classes as described on XML - UML Class Mapping.
SOAP Service and HTTP Support
Runtime 2019.9 Bridge xUML services read the following incoming HTTP headers containing correlation information: These headers will be all logged to the transaction log. Having this information, you can use this for error analysis or usage metrics.
This header identifies the transaction the call belongs to. You can set the transaction id manually with setTransactionID. If not set, the Runtime will generate one.
This header will be passed through the callstack to identify all service calls that belong to a transaction.
This header should identify the unique request.
These headers should contain the sender host resp. the sender service.
Runtime 2019.9 Bridge xUML services read the following incoming HTTP headers containing correlation information:
These headers will be all logged to the transaction log. Having this information, you can use this for error analysis or usage metrics.Refer to HTTP Header Support regarding general information on HTTP protocol support in this context.
X-Transaction-ID corresponds to SOAP header TransactionID, and X-Request-ID corresponds to SOAP header CorrelationID. The SOAP header overrules the HTTP header if set.
Runtime 2020.12 If the standard HTTP header handling does not meet your needs, you can take control of the header handling by defining your own header roles.
Refer to HTTP Header Support > Overwriting the Standard HTTP Headers for a detailed explanation of how to use this feature.
Additionally, any client calling an xUML SOAP service can specify the following HTTP header:
This header will change the HTTP status code in case of error:
- SOAP call without error
No change, HTTP status code 200 (as expected).
SOAP call with error
HTTP status code 200 (instead of 500).
The response body does not change in this case and will still report the error details.
- No labels