SOAP Adapter Concepts

Topics:

SOAP Specifications

The following specifications are supported:

SOAP 1.2
WS-I Security (for SSL, TLS, and ciphers)
SOAP 1.1 binding for MTOM
WS-Addressing
WS-Security Username Token

Transport Layer Security Version Support

Specifying the transport Layer Security (TLS) version of the target server is supported. The TLS protocol provides privacy and data integrity between two communicating computer applications. See Configure Connection Properties.

Version Suppression of the Timestamp in the WS-Security Header

Version suppression of the timestamp in the WS-Security header is supported. Suppression applies to the Username Password Token security policy in the invoke (outbound) direction. In secure Web Services transactions, a WS-Utility (WSU) timestamp can be inserted into a WS-Security header to define the lifetime of the message in which it is placed. See Configure Connection Properties.

Ability to Specify if the Timestamp is Not Required in the Response Message

You can specify if the timestamp is not required in the response message. See Configure Connection Properties.

SOAP Action Validation Disabling for Inbound Requests

Disabling SOAP action validation for inbound requests on the Operations page of the Adapter Endpoint Configuration Wizard is supported. This is useful for environments in which your WSDL includes custom code and you want to bypass validation. See Invoke Operation Page and Callback Integrations Fail with a Configured SOAP Action Mismatch Error.

Asynchronous Callback Response Support in the Invoke (Outbound) Direction

An asynchronous callback response in the invoke (outbound) direction is supported. This feature is enabled when the WSDL used in the connection defines a one-way operation in the selected service/port. The callback response endpoint must be specified through a different integration flow. The callback endpoint can be secured with any policy supported by the SOAP Adapter on the trigger side.

Based on the operation selection, if it is a one-way operation, you are asked to select the expected response type (no response or delayed response) on the Callback Operation page of the Adapter Endpoint Configuration Wizard.

No Response: One-way invocation.
Delayed Response: Specify the callback port type, operation, callback flow identifier, and version.

The callback flow identifier and version are used to determine the callback endpoint and sent in the ReplyTo header while sending a request to the outbound endpoint.

Support for Adding Standard and Custom SOAP and HTTP Headers

Adding standard and custom SOAP and HTTP headers to outbound and inbound requests and handling the responses with headers to propagate back to the user are supported. This configuration enables header configuration for the inbound service and header propagation for the outbound service. WS-Addressing headers propagation is not supported (for example, MessageId, ReplyTo, FaultTo, and so on). All header information and body elements are encapsulated under a single element so the mapper can display request and response information. See Add the SOAP Adapter Connection to an Integration.

Support for Multiple Part Messages in Document-Style WSDLs

Note:

The SOAP Adapter does not support RPC-style WSDL bindings. Only document-style WSDL bindings are supported.

Multiple part messages in document-style WSDLs is supported. The support is provided for both inbound and outbound adapter configurations.

Standard SOAP headers can be defined in a WSDL in two ways:
- Implicit headers:
  
  With this type, the request header and body part are in different message types. In the binding section of the WSDL, the header uses the part name within the message type and message type name. The body does not have any part names explicitly defined in it.
```
<wsdl:message name="CreateUserRequestHeader">
<wsdl:part name="requestHeader" element=" tns:UserCreate"/> 
</wsdl:message> 
<wsdl:message name="CreateUserRequest"> 
<wsdl:part element="tns:UserCreateHeader" name="parameters"/> 
</wsdl:message> 
<wsdl:binding name="UserBinding" type="tns:UserEndPoint"> 
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> 
<wsdl:operation name="CreateUser"> 
<soap:operation soapAction="http://example.com/CreateUser" /> 
<wsdl:input> <soap:body use="literal" /> 
<soap:header use="literal" part="requestHeader" message="tns:CreateUserRequestHeader"/> 
</wsdl:input> 
<wsdl:output> 
<soap:body use="literal" /> 
</wsdl:output> 
</wsdl:operation> 
<wsdl:binding/>
```
- Explicit headers:
  
  With this type, there are multiple parts in a single message type in the WSDL: one for the header and one for the body payload. The header is specified by its part name. The body uses its own name.
```
<wsdl:message name="CreateUserRequest"> 
<wsdl:part element="tns:UserCreateHeader" name="parameters"/> 
<wsdl:part name="requestHeader" element=" tns:UserCreate"/> 
</wsdl:message> 
<wsdl:binding name="UserBinding" type="tns:UserEndPoint"> 
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> 
<wsdl:operation name="CreateUser"> 
<soap:operation soapAction="http://example.com/CreateUser" /> 
<wsdl:input> <soap:body use="literal" /> 
<soap:header use="literal" part="requestHeader" message="tns:CreateUserRequest"/> 
</wsdl:input> 
<wsdl:output> 
<soap:body use="literal" /> 
</wsdl:output> 
</wsdl:operation> 
<wsdl:binding/>
```
  Note:
  Without specifying a header, multiple parts in a document-style WSDL are not supported.
When you invoke the Adapter Endpoint Configuration Wizard to configure the SOAP Adapter as a trigger or invoke, the Operations page detects that the WSDL includes defined SOAP request and/or response headers and automatically enables the button to configure SOAP headers for the endpoint. You can select No to remove the headers for the endpoint. You cannot modify these headers. The subsequent Request Header and Response Header pages of the WSDL load and show the specific headers defined in the WSDL. See Add the SOAP Adapter Connection to an Integration.

Two-Way SSL Support for Outbound Connections

The use of two-way SSL for outbound communications is supported. This feature enables an integration to invoke web services hosted on a two-way, SSL-enabled server and receive a response in return.

You must satisfy the following requirements to use this feature:

Upload the following certificates in the Upload Certificate dialog in Oracle Integration. See Upload an SSL Certificate.
- Upload a two-way SSL identity certificate type. This certificate is created from the client server on which two-way SSL must be enabled
- Upload a trust certificate type for the outbound call. This is the certificate for the client server that hosts your web service.
Specify a WSDL URL with secure HTTP (https) on the Connection Properties dialog. This WSDL must use the web service URL hosted on the two-way, SSL-enabled server.
Two-way SSL is only supported with the JCA transport mechanism of the SOAP Adapter. The HTTP transport mechanism of the SOAP Adapter is not supported.
Configure the server that hosts the web service for two-way SSL communication.
Configure the SOAP Adapter as both a trigger and invoke. When you create the integration, you configure this same SOAP Adapter connection as both the trigger and invoke.

SAML Policy Security Support in the Trigger (Inbound) Direction

The Security Assertion Markup Language (SAML) is an XML-based, open-standard data format for exchanging authorization and authentication information between two different systems, typically an identity provider and a service provider. A SOAP Adapter trigger-specific connection can be configured to protect inbound SOAP endpoints using SAML token-based authentication. This configuration can be used to implement use cases that involve receiving callback messages from Oracle ERP Cloud upon completion of file-based data import (FBDI) jobs and upon completion of asynchronous operations in any Oracle ERP Cloud application, such as fusion order management (FOM). However, any client that supports SAML bearer token authentication can use this policy.

OAuth 2.0 Policy Security Support in the Trigger (Inbound) Direction

Integrations exposing SOAP endpoints using the SOAP Adapter as a trigger connection can be OAuth 2.0-protected. OAuth 2.0 is an industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications.

Asynchronous Trigger Support in Orchestrated Integrations

When a call is made to an asynchronous service, the response is expected at a later time and possibly to a different endpoint. If the response is expected at a different endpoint, the endpoint information must be passed to the asynchronous service during the request using the WS-Addressing ReplyTo header. In this case, the Oracle Integration endpoint with the SOAP Adapter configured as the (trigger) inbound connection acts as an asynchronous service. Oracle Integration determines if the selected operation is asynchronous and then enables you to provide callback endpoint details through a ReplyTo standard header and to use this information to invoke the callback response.

The following requirements must be satisfied to use this feature:

This feature is only available when the SOAP Adapter is included in orchestrated integrations.
The asynchronous service uses only the SOAP Adapter-supported OWSM policies. The callback endpoint being specified in the ReplyTo header must support one of the security policies available on the Connections page for the invoke-only role.
The corresponding callback invoke must also be configured when the trigger is configured for an asynchronous response.
The request payload contains a Reply-To header that contains the value of the endpoint to which to send the asynchronous response.

In the trigger direction, you must configure the Adapter Endpoint Configuration Wizard as follows:

On the Callback Operations Page, you select Delayed Response because a callback response is expected.
On the Headers page, the Do you want to configure headers for this Endpoint option is automatically enabled. The SOAP Headers option is automatically selected in the Request Headers section and cannot be changed.
On the Request Headers page, the WS-Addressing ReplyTo, MessageID, and Action headers are automatically populated in the Standard SOAP Headers tab.

In the invoke direction, you must configure the Adapter Endpoint Configuration Wizard as follows:

On the Welcome page, select Yes to configure the SOAP Adapter as a callback invoke.
On the Operations page, the list of port types is displayed (instead of the service and port). You must select the callback port type and callback operation. The Callback Operations page is disabled as it is not an outbound asynchronous case.
On the Headers page, the headers configuration option is automatically enabled. The SOAP Headers option is automatically selected in the Request Headers section and cannot be changed.
On the Request Headers page, the WS-Addressing ReplyTo, MessageID, Action headers are populated in the Standard SOAP Headers tab.

During integration creation, you must explicitly map the WS-Addressing headers from Inbound Request to Callback Invoke Request in addition to the other required mapping options. During runtime, when Oracle Integration is invoked with the request having a wsa:ReplyTo header, the service invokes the endpoint sent in the header with the response.

Note:

You cannot switch from an asynchronous trigger/callback invoke to nonasynchronous trigger/invoke.

Support for Invoking Co-located SOAP Endpoints

You can propagate the subject between co-located modules (for example, Integrations to Processes and Processes to Integrations). This enables the module to provide custom features and restrictions based on the current subject.

Oracle Integration can automatically determine if an outbound (invoke) SOAP endpoint being invoked by an integration is local (co-located) or remote to Oracle Integration and then optimize the invoke call to the endpoint. Co-located means the integrations are running on the same host instance or in the same domain. If the outbound endpoint is co-located, the endpoint is invoked using an optimized HTTP request using a JSON Web Token (JWT) token for authorization. The optimized HTTP request is a plain HTTP request (non-SSL) sent directly to the managed server. The currently configured security policy is overwritten by a JWT token. JWT is a JSON-based open standard (RFC 7519) for creating access tokens that assert some number of claims. For example, a server can generate a token that has the claim "logged in as admin" and provide that to a client. The client can then use that token to prove that it is logged in as admin. The tokens are signed by the server's key. Therefore, the client and server can both verify that the token is legitimate.

Support for Uploading a WSDL with Schemas in a ZIP File

When creating a connection, you can upload a ZIP file with a WSDL and dependencies such as other WSDLs and XSDs nested inside the ZIP. This can be useful in scenarios in which you adopt the standard canonical model (OAGIS) in integrations. If you upload a ZIP, you must ensure that the WSDLs are available in the top two directory levels. This makes the WSDLs available for selection in the Service WSDL dropdown list on the Connections page. There can be any number of WSDLs at these two levels. Any WSDLs below these levels do not appear for you to select in the Service WSDL dropdown list.

The following use cases are supported:

The ZIP file contains the main WSDL (for this example, named SalesOrderEBSV2.wsdl) in the immediate folder and its dependencies (EBM, other XSDs, and so on) nested deeply inside a folder.

Description of the illustration soap_case_1.png
For this example, the main WSDL reference must be corrected to reference EnterpriseObjectLibrary as shown.
```
<xsd:import namespace="http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/SalesOrder/V2" schemaLocation="./EnterpriseObjectLibrary/Core/EBO/SalesOrder/V2/SalesOrderEBM.xsd"/>
<xsd:import namespace="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2" schemaLocation="./EnterpriseObjectLibrary/Core/Common/V2/Meta.xsd"/>
```
The ZIP file contains a main WSDL (for this example, named service.wsdl) and references another WSDL and XSDs:

Description of the illustration soap_case_2.png
The ZIP file contains a WSDL (for this example, named service.wsdl) and any number of XSD dependencies in the same directory.

Description of the illustration soap_case_3.png

Support for Using MTOM to Transfer Large Binary Payloads

Message Transmission Optimization Mechanism (MTOM) support is provided. MTOM is a W3C Message Transmission Optimization Mechanism, a method for efficiently sending binary data to and from web services. Binary objects in SOAP are represented as base64 encoded messages, which essentially expands the data by about 33%. For large payloads, this can significantly impact performance and transmission time. MTOM provides a solution to transfer a large binary payload using optimization. MTOM/XOP optimizes a SOAP message and the XOP processing serializes it into a MIME multipart/related message. The XOP processing extracts the base64-encoded data from the SOAP message and packages it as separate binary attachments within the MIME message. See Configure MTOM Support in the SOAP Adapter.

MTOM is currently supported only on the invoke connection in an integration.

Note:

MTOM upload/download cannot be invoked asynchronously with a large payload and high concurrency. This scenario can result in an out-of-memory error depending upon payload size and concurrency. Take care in your design. For example, in a scheduled orchestrated integration with scheduling set to every 10 minutes, four flows can run consistently with 512 MB payload every 10 minutes on a two-node Oracle Integration cluster without any out-of-memory errors.

Support for Dynamic Endpoints

The SOAP Adapter supports the dynamic discovery of endpoints. This is useful for scenarios in which the endpoint that the SOAP Adapter invokes must be dynamically configured based on runtime logic. This feature is applicable for both new integrations and existing integrations (edited to add new invokes) that include the SOAP Adapter as an invoke connection. The endpoint invoked must support the same security policies as supported in Oracle Integration. However, WS-Addressing is not used. Instead, two types of properties in the mapper are provided for configuring dynamic invocation. These properties are used during runtime to override the properties configured on the Connections page during design time.

Endpoint Properties: Override the endpoint details.
- EndpointURI: Replaces the existing endpoint URI specified on the Connections page before invoking the endpoint.
- SoapAction: Replaces the existing SOAP action validation setting before invoking the endpoint.
Security Properties: Override the endpoint credential details, if required.
- If the connection uses Username Password Token:
  - Username: Replaces the username credentials before invoking the endpoint.
  - Password: Replaces the password credentials before invoking the endpoint.
  - ignoreNonce: Accepts a boolean true/false value. The default is false. Setting this value to true in the request prevents the Nonce and Created headers from being sent in the Username Password Token.
  - ignoreCreated: Accepts a boolean true/false value. The default is false. Setting this value to true in the request prevents the Nonce and Created headers from being sent in the Username Password Token.
  For Username Password Token, Oracle Integration supports the WS-Security 2004 version (SOAP Message Security 1.0 specification) in the outbound direction. This contains a SOAP message security header:
```
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
         <wsu:Timestamp wsu:Id="TS-910919AD52F5349E1B16034288264664">
            <wsu:Created>2020-10-23T04:53:46.466Z</wsu:Created>
            <wsu:Expires>2020-10-23T04:54:46.466Z</wsu:Expires>
         </wsu:Timestamp>
         <wsse:UsernameToken wsu:Id="UsernameToken-910919AD52F5349E1B16034288238563">
            <wsse:Username>username</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>
            <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">VG04/faWm6rFXSuu8kBGJg==</wsse:Nonce>
            <wsu:Created>2020-10-23T04:53:43.856Z</wsu:Created>
         </wsse:UsernameToken>
      </wsse:Security>
```
  The specification says Nonce and Created are optional and useful to avoid distributed denial-of-service (DDOS) attacks. To support endpoints that only support Username Password Token without Nonce and Created, the ignoreNonce and ignoreCreated connectivity properties are provided in the outbound request mapper for SOAP Adapter connections that use Username Password Token.
- If the connection uses Basic Authentication Security:
  - Authorization: Replaces the authorization header before invoking the endpoint.
The following dynamic properties are visible for configuration in the mapper and used during runtime to override the properties configured during design time.
- Sample outbound request: The ConnectivityProperties section and the Headers and/or Body sections are displayed with properties for configuration. The ConnectivityProperties section is not visible if this is a callback invoke request.
  
  Description of the illustration soap_headers_mapper.png
  
  When expanded, ConnectivityProperties shows the following for an outbound request.
- Username Password Token security policy: The EndpointProperties section and SecurityProperties section are visible with properties for configuration under the main ConnectivityProperties section.
- Basic Authentication security policy: The EndpointProperties section and SecurityProperties section are visible with properties for configuration under the main ConnectivityProperties section.
  
  Description of the illustration basic_auth.png
- No security policy: The EndpointProperties section is visible with properties for configuration under the main ConnectivityProperties section.
  
  Description of the illustration no_security.png

Note:

Overriding security properties with the dynamic endpoint invocation feature logs the details mapped when trace is enabled during activation of the integration.
When using dynamic endpoints with the SOAP Adapter, be aware that if you activate an integration using this feature with Enable tracing and Include payload selected, the password used in the payload during runtime is exposed in clear text in the log file.