SOAP Adapter Capabilities

The SOAP Adapter can consume an external SOAP API in an integration in Oracle Integration Cloud Service. The message received from Oracle Integration Cloud Service can be passed as payload to an external SOAP endpoint by the SOAP Adapter. Any response received from the endpoint can be sent to the next action in the integration for further processing.

The SOAP Adapter can expose inbound SOAP endpoints for accepting SOAP requests that are addressed to a specific URI. The request body is passed to the next activity present in the integration as the message payload, along with the SOAP and HTTP headers.

Note:

The SOAP Adapter treats all endpoints as they are exposed. The SOAP Adapter does not filter or change any of the APIs exposed by the application to which you are connecting. If there is a native adapter for the application to which you are connecting, use that adapter instead. If you choose to use the SOAP Adapter instead of the native adapter, the API restrictions and deprecation policies apply as specified in the respective application’s documentation.

To connect to the Oracle HCM Cloud SOAP APIs, see Oracle HCM Cloud Adapter Capabilities.

The SOAP Adapter provides the following capabilities:
  • SOAP Adapter capabilities when configured as a trigger:

    • Allows configuring only HTTPS protocol-based SOAP endpoints for accepting incoming SOAP requests.

    • Supports configuring the inbound SOAP endpoints using the following security policies: HTTP Basic Authentication, WS-Username token-based authentication, and Security Assertion Markup Language (SAML) (see SAML Policy Security Support in the Trigger (Inbound) Direction).

    • Supports accessing of standard and custom SOAP/HTTP header properties present in the incoming SOAP request and making them available as part of an Oracle Integration Cloud Service message for any processing in subsequent actions (see Support for Adding Standard and Custom SOAP and HTTP Headers).

    • Enables you to implement the following message exchange patterns on the inbound SOAP endpoint: synchronous request/response, one-way request, and asynchronous request with callback support.

  • SOAP Adapter capabilities when configured as an invoke:

    • Allows invocation of an HTTPS protocol-based external SOAP endpoint, thereby encrypting the communications using transport layer security (TLS) (see Transport Layer Security Version Support).

    • Allows invocation of HTTP protocol-based SOAP endpoints.

    • Allows invocation of external SOAP endpoints that are unprotected and protected using HTTP Basic Authentication and WS-Username token-based authentication.

    • Allows invocation of external SOAP endpoints hosted on TLS servers v1, v1.1, and v1.2.

    • Supports invocation of two-way, SSL-enabled external SOAP endpoints (see Two-Way SSL Support for Outbound Connections).

    • Supports configuration of standard and custom SOAP/HTTP header properties available to the outbound SOAP request (see Support for Adding Standard and Custom SOAP and HTTP Headers).

    • Supports invocation of external SOAP endpoints that implement the following message exchange patterns: synchronous request/response, one-way request, and asynchronous request with callback support (using WS-Addressing) (see Asynchronous Callback Response Support in the Invoke (Outbound) Direction).

The following sections describe these capabilities in more detail:

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 Configuring 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 Configuring 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 Configuring 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 What You See on the SOAP Adapter Trigger Operations 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 Adding the SOAP Adapter Connection to an Integration.

Support for Multiple Part Messages in Document-Style WSDLs

  • 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 Adding 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 Cloud Service. See Uploading 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) security policy is used to configure the SOAP Adapter as a trigger to enable asynchronous invocation and callback authentication from ERP/DOO services primarily. However, any client that supports SAML Bearer Token authentication can use this policy. 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. This security policy is available for selection on the Connections page when you configure the SOAP Adapter.

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 Cloud Service endpoint with the SOAP Adapter configured as the (trigger) inbound connection acts as an asynchronous service. Oracle Integration Cloud Service 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 Cloud Service 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.