IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

SOAPAsyncRequest node

Use the SOAPAsyncRequest node with the SOAPAsyncResponse node to construct a pair of message flows that call a Web service asynchronously.

This topic contains the following sections:

Purpose
Using this node in a message flow
Using WSDL with the SOAPAsyncRequest node
Terminals and properties
LocalEnvironment overrides
Working with WrittenDestination data

Purpose

The SOAPAsyncRequest node can use HTTP or JMS transport. It is linked as a pair with a SOAPAsyncResponse using a unique identifier, and optionally WS-Addressing, to correlate response messages with the original request. The SOAPAsyncRequest and SOAPAsyncResponse nodes cannot be used with one-way operations.

The SOAPAsyncRequest node sends a Web service request, but the node does not wait for the associated Web service response to be received. This asynchronous functionality enables multiple outbound requests to be made almost in parallel because the outbound request is not blocked waiting for the response. The Web service response is received by the SOAPAsyncResponse node, which can be in a separate message flow. The nodes are used as a pair, and correlate responses against the original requests.

The SOAPAsyncRequest node supports two methods of asynchronous requests when using HTTP transport:

Using WS-Addressing to direct the response to the paired SOAPAsyncResponse node. The SOAPAsyncRequest node waits for the HTTP 202 acknowledgment before continuing with the message flow, and the SOAPAsyncRequest node blocks if the acknowledgment is not received. A new HTTP connection is made by the backend server to reply to the SOAPAsyncResponse node. This is the default behavior.
Using HTTP asynchronous request-response. When the SOAPAsyncRequest property Use HTTP asynchronous request-response is selected, the SOAPAsyncRequest node passes the HTTP socket to the paired SOAPAsyncResponse node to allow the backend server to reply using the same socket. When this option is selected, WS-Addressing headers are sent, but are not required to be understood by the backend server. The WS-Addressing headers are not marked as mustUnderstand, and the replyTo header is set to anonymous. The node therefore uses asynchronous HTTP socket handling instead of WS-Addressing to make HTTP requests and receive an asynchronous response.

For more information, see Choosing asynchronous behavior for the SOAPAsyncRequest node.

The diagram shows the relationship between the SOAPAsyncRequest and SOAPAsyncResponse nodes, and is described in the text.

The SOAPAsyncRequest node is the first half of the asynchronous request and response node pair. The SOAPAsyncRequest node calls a remote SOAP-based Web service. The request is sent by the SOAPAsyncRequest node, but the SOAPAsyncRequest node does not receive the response. The response is received by a SOAPAsyncResponse node that is running on a different thread. The SOAPAsyncResponse node is typically at the beginning of a different message flow; however, it must be in the same integration server as the SOAPAsyncRequest node.

The SOAPAsyncRequest node is WSDL-driven, in a similar manner to the SOAPRequest node.

The SOAPAsyncRequest node is contained in the Web Services drawer of the palette, and is represented in the IBM® Integration Toolkit by the following icon:

The image shows a SOAPAsyncRequest node icon.

Using this node in a message flow

A SOAPAsyncRequest node is linked as a pair with a SOAPAsyncResponse using a unique identifier to correlate request and response messages.

The following sample demonstrates how to use the asynchronous SOAP nodes when you call a Web service. The Web service simulates an order service, and the client shows how existing WebSphere® MQ interfaces can be extended to make Web service requests.

Asynchronous Consumer

You can view information about samples only when you use the product documentation that is integrated with the IBM Integration Toolkit or the online product documentation. You can run samples only when you use the product documentation that is integrated with the IBM Integration Toolkit.

Using WSDL with the SOAPAsyncRequest node

A SOAPAsyncRequest node must be associated with a WSDL file unless it is operating in gateway mode. For more information about gateway mode, see Gateway operation mode for SOAP nodes.

In WSDL mode, when you select a WSDL file for the WSDL file name field, the WSDL is validated to ensure that it is WS-I compliant. If the WSDL uses a SOAP/JMS transport URI it is not WS-I compliant, but by default no error is shown. To enable strict WS-I validation and display a warning when a SOAP/JMS transport is used, click Window > Preferences > Integration Development > WSDL > Validation and clear the WS-I BP 1.1: Allow SOAP/JMS as transport URI check box.

After a valid WSDL file is selected, the message set project to which WSDL file belongs is added as a referenced project to the corresponding flow project, if the reference does not exist. If the WSDL file is not valid, or an incorrect file name is entered, an error message is displayed in the Properties view and all WSDL properties are blank.

If the node was created by dropping a WSDL file from a message set onto the message flow editor, this property is preset to the name of the WSDL file. If the name of the WSDL file is not preset, you can set this property in one of the following ways.

If you have Deployable WSDL, you can select from the Deployable WSDL files by clicking Browse.
If you have WSDL definitions, but no message set, then you can create a message set:
1. Click Browse to open the WSDL Selection window.
2. Click Import/Create New to open the Import WSDL file wizard.
3. Enter the message set name and message set project name. Click Next.
4. Select the relevant option:
  - If your WSDL file exists in your workspace, select Use resources from the workspace, and select the WSDL file.
  - If your WSDL file is in the file system, select Use external resources. Select the WSDL file. Click Next.
5. Select the WSDL bindings to import. Any warnings or errors are displayed in the wizard banner.
6. Click Finish. Result: Creates a new message set project and message set, with message definitions. The WSDL definitions are added to the Deployable WSDL folder.
7. You can now select the WSDL file from the WSDL Selection window. Click OK.
If you have a message set but no WSDL definition, you must generate a WSDL definition. See Message Sets: Generating a WSDL definition from a message set.
Drag a WSDL file from a message set onto the node.
Type in a file name that is relative to the message set project in which the deployable WSDL file exists.

When you save the flow file, it is validated that the WSDL file name exists in the message set. If it is does not, an error is generated, and you will not be able to add a flow that contains this SOAPAsyncRequest node to the broker archive (BAR) file.

Terminals and properties

The SOAPAsyncRequest node terminals are described in the following table.

Terminal	Description
In	The input terminal that accepts a SOAP request message for dispatch to the target by the node.
Failure	The output terminal to which the message is routed if a failure is detected when the SOAP request message is dispatched to the target (such as a message validation failure).
Out	The output terminal to which the message is routed if it has been successfully dispatched to the target, and if further processing is required within this message flow. The message that leaves the Out terminal is the same as the message that arrived at the In terminal.

The following tables describe the node properties. The column headed M indicates whether the property is mandatory (marked with an asterisk if you must enter a value when no default is defined). The column headed C indicates whether the property is configurable (you can change the value when you add the message flow to the BAR file to deploy it).

Some SOAPAsyncRequest node properties are initially set from properties in the imported WSDL. These properties are parsed differently depending on which URI format is used by the address element in the WSDL. For details, see WSDL URI formats for JMS.

The SOAPAsyncRequest node Description properties are described in the following table.

Property	M	C	Default	Description
Node name	No	No	The node type	The name of the node.
Short description	No	No	None	A brief description of the node.
Long description	No	No	None	Text that describes the purpose of the node in the message flow.

The SOAPAsyncRequest node Basic properties are described in the following table.

Property	M	C	Default	Description	mqsiapplybaroverride command property
Unique identifier	Yes	No		This property is the unique identifier that links a pair of SOAPAsyncRequest and SOAPAsyncResponse nodes. When using HTTP transport, this identifier is used as a unique URL fragment to identify incoming response messages for the SOAPAsyncResponse node. When using JMS transport, this property is used as a unique identifier only if the Get Response By Correl ID property is checked. If the Get Response By Correl ID property is cleared and JMS transport is used, the Reply To Destination queue acts as the unique identifier instead, and therefore must be unique to this pair of nodes.	asyncResponseCorrelator
Operation mode	Yes	Yes	Invoke a specific web service defined by a WSDL interface	This property allows you to specify the operation mode of the node, which determines whether it acts in WSDL mode or in gateway mode. In WSDL mode, the node performs operations according to the WSDL it is configured with. However, gateway mode allows you to configure your flow to handle generic SOAP request/response and one-way messages, or to act as a façade between multiple web services clients and multiple back-end web services providers. Invoke a specific web service defined by a WSDL interface Configure the node with a deployable WSDL by setting the WSDL file name property or by dragging a WSDL onto the node. This is the default option. Invoke a generic web service Configure the node to act in gateway mode with no WSDL required. See Gateway operation mode for SOAP nodes for a fuller explanation of gateway mode.
WSDL file name	Yes	No	None	This property indicates the location of the WSDL file that you want to use to configure the node. Enter the full path to the WSDL file, or click Browse to locate the WSDL file in your workspace. When you select a WSDL file for the WSDL file name property, the WSDL is validated to ensure that it is WS-I compliant. If the WSDL has a binding using SOAP/JMS which is not WS-I compliant, by default no error is shown. To enable strict WS-I validation and display a warning when a SOAP/JMS transport is used, click Window > Preferences > Integration Development > WSDL > Validation and clear the WS-I BP 1.1: Allow SOAP/JMS as transport URI check box. Only deployable WSDL files can be used to configure the SOAP nodes. After a valid WSDL file is selected, the message set project to which the WSDL file belongs is added as a referenced project to the corresponding application or library, if the reference does not exist. If the WSDL file is not valid, or an incorrect file name is entered, an error message is displayed in the Properties view and all WSDL properties are blank. If the node was created by dropping a WSDL file from a message set onto the Message Flow editor, this property is preset to the name of the WSDL file. This property takes a string value. The following situations result in an error condition: The WSDL file does not belong to an application or library, or the WSDL file was not imported correctly; see Importing from WSDL and Message Sets: Importing WSDL definitions from the command line. The WSDL file contains no HTTP or JMS bindings. The WSDL file contains no port type. The WSDL file that is specified in the field does not exist. WSDL properties are disabled when the node is configured to act in gateway mode.
Port type	Yes	No	By default, the first Port type found in the WSDL file, that has an associated HTTP or JMS binding with it, is selected.	This property type is String. This field lists all the port types defined by the specified WSDL file. By default, the first port type found in the WSDL file that has an associated HTTP or JMS binding is selected. When you save the flow file, it is validated that the selected Port type is valid within the content of the selected WSDL file. If it is not valid, an error is generated, and you will not be able to add a flow that contains this SOAPAsyncRequest node to the broker archive (BAR) file. Error Conditions: Selected Port type does not contain at least one operation. WSDL properties are disabled when the node is configured to act in gateway mode.
Imported binding	Yes	No		This property type is String. The Imported binding box lists all the SOAP bindings associated with the selected port type. Only HTTP or JMS transport is supported. Bindings are listed in the order that they are displayed in the WSDL file. By default, the first binding that implements the operation and has an associated service port is selected. This property is updated every time the Port type value changes. Error Conditions: No SOAP bindings (with HTTP or JMS transport) in the WSDL file are associated with the Port type. Selected binding does not have any operations. WSDL properties are disabled when the node is configured to act in gateway mode.
Binding operation	Yes	No		This property type is String. The Binding operation box contains all the operations defined by the selected binding. The first operation in the list is selected by default. This property is updated every time the selected binding value changes. When you save the flow file, it is validated that the selected Binding operation is valid within the content of the selected WSDL file. If it is not valid, an error is generated, and you will not be able to add a flow that contains this SOAPAsyncRequest node to the broker archive (BAR) file. WSDL properties are disabled when the node is configured to act in gateway mode.
Service port	Yes	No		This property type is String. The Service port box lists all the service ports that point to the selected binding. The first service port for the binding is selected by default. This property is updated every time the selected binding value changes. When you save the flow file, it is validated that the selected Service port is valid within the content of the selected WSDL file. If it is not valid, an error is generated, and you will not be able to add a flow that contains this SOAPAsyncRequest node to the broker archive (BAR) file. Error Conditions: No ports point to the selected binding. WSDL properties are disabled when the node is configured to act in gateway mode.
Target namespace	No	No		This property type is String. Target namespace displays the namespace of the selected WSDL file. WSDL properties are disabled when the node is configured to act in gateway mode.
Transport	No	No	HTTP	This property is set automatically when the Imported binding property is selected. The value of this property shows the transport used by the selected WSDL binding; for example, HTTP or JMS. If you choose to switch the transport from JMS to HTTP, a dialog box displays, which allows you to reset the JMS-specific properties. You must reset the JMS properties to deploy the message flow to a runtime environment version prior to fix pack V7.0.0.1.

The SOAPAsyncRequest node HTTP Transport properties are described in the following table. These settings are used only when the node uses HTTP transport.

Property	M	C	Default	Description	mqsiapplybaroverride command property
Web service URL	Yes	No		This property type is String. This property is automatically derived from the `<soap:address>` element of the selected Service port. Whenever the selected port is updated, the Web service URL is updated accordingly. However, if you override the value then your value persists and the URL is no longer updated from the service port. If you choose to override this property you must specify it in the form http://<hostname>[:<port>]/[<path>] where: http://<hostname> must be specified. <port> has a default of 80. If you specify a value, you must include the colon (`:`) before the port number. <path> has a default of forward slash (`/`). If you specify a value, you must include the forward slash (`/`) before the path. For more details of how to override this property, see Changing the default URL for a SOAPRequest node or a SOAPAsyncRequest node request.	webServiceURL
Request timeout (in seconds)	No	Yes	120	This property type is Integer. This property has the value of the wait time for the remote server to respond with an acknowledgment that the message has been received. If you select the property Use async socket, the value of Request timeout instead refers to the value of the wait time for the remote server to send a response to the SOAPAsyncResponse node. The time in seconds that the node waits for a response from the Web service. The valid range is 1 to (2³¹)-1. You cannot enter a value that represents an unlimited wait.	requestTimeout
HTTP(S) proxy location	No	Yes		This property type is String. The location of the proxy server to which requests are sent. This value must be in the form hostname:port.	httpProxyLocation
SSL Protocol (if using SSL)	No	Yes	TLS	This property type is Enumerate. The SSL protocol to use when making an HTTPS request. Valid values are: SSL This option attempts to connect by using the SSLv3 protocol first, but the handshake can fall back to the SSLv2 protocol where the SSLv2 protocol is supported by the underlying JSSE provider. SSLv3 This option attempts to connect with the SSLv3 protocol only. The handshake cannot fall back to SSLv2. TLS The default. This option attempts to connect with the TLS protocol only. The handshake cannot fall back to SSLv3 or SSLv2. TLSv1 This option attempts to connect with the TLS v1.0 protocol only. Fallback to SSLv3 or SSLv2 is not allowed. TLSv1.1 This option attempts to connect with the TLS v1.1 protocol only. Fallback to SSLv3, SSLv2, or TLSv1.0 is not allowed. TLSv1.2 This option attempts to connect with the TLS v1.2 protocol only. Fallback to SSLv3, SSLv2, TLSv1.0, or TLSv1.1 is not allowed. SSL_TLS This option enables all SSL v3.0 and TLS v1.0 protocols. Fallback to SSLv2 is not allowed. SSL_TLSv2 This option enables all SSL v3.0 and TLS v1.0, v1.1, and v1.2 protocols. Fallback to SSLv2 is not allowed. Both ends of an SSL connection must use the same protocol. The protocol must be one that the remote server can accept.	sslProtocol
Allowed SSL ciphers (if using SSL)	No	Yes	Empty	This property type is String. A comma-separated list of ciphers to use when making an SSL request. This setting enables you to specify a single cipher (such as SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA), or a list of ciphers that are the only ones used by the connection. This list of ciphers must include one or more that are accepted by the remote server. The default value is an empty string, which allows the node to use any, or all, of the available ciphers during the SSL connection handshake. This method enables the greatest scope for making a successful SSL connection.	allowedSSLCiphers
Use compression	No	No	None	This property controls whether the content of the HTTP request is compressed. Valid values are none, gzip, zlib (deflate) and deflate. If the request is compressed, the Content-Encoding header is set to indicate that the content is compressed. zlib (deflate) represents RFC 1950 + RFC 1951 combined. deflate represents RFC 1951 only.	requestCompressionType
Accept compressed responses by default	No	Yes	Cleared	This property indicates whether the request accepts compressed responses. If this option is selected, it is possible for the request to receive responses with a Content-Encoding of gzip or deflate. If such a response is received the content is decoded and the Content-Encoding header is removed. If the Request Header does not contain an Accept-Encoding header then selecting this option sets the Accept-Encoding header to "gzip, deflate".	acceptCompressedResponses
Enable SSL certificate hostname checking	No	Yes	No	This property specifies if the host name of the server that is receiving the request must match the host name in the SSL certificate.	hostnameChecking
Use HTTP asynchronous request-response	No	No	Cleared	Setting this property specifies that the SOAPAsyncRequest node passes the HTTP socket to the paired SOAPAsyncResponse node to allow the backend server to reply using the same socket. This property configures the node to use asynchronous HTTP request-response handling instead of asynchronous WS-Addressing. When Use HTTP asynchronous request-response is selected, the WS-Addressing headers are not marked as mustUnderstand, and the replyTo header is set to anonymous. Select this option if your backend server cannot make outbound requests on a new connection. For more information, see Choosing asynchronous behavior for the SOAPAsyncRequest node.
SSL client authentication key alias	No	Yes	"" (empty string)	This property specifies an SSL authentication alias for the client-side of an SOAPAsyncRequest connection. Taking the default value means that the first appropriate key is chosen for you automatically.	keyAlias
Enable certificate revocation list checking	No	Yes	Not selected	This property specifies whether CRL checking should be enabled for SSL connections	enableCRLCheck

The SOAPAsyncRequest node JMS Transport properties are described in the following table. These settings are used only when the node uses JMS transport.

Property	M	C	Default	Description	mqsiapplybaroverride command property
Destination	Yes	Yes	None	The destination to which the node sends outgoing messages. If the SOAPAsyncRequest node is to be used to send point-to-point messages, enter the Destination queue name for the JMS queue name that is listed in the bindings file. This property takes its initial value from a WSDL URI property, depending on whether the WSDL `address` URI is formatted in the W3C (standards) style, or the IBM (proprietary) style. Destination is set to the value of destinationName found in the WSDL if a W3C-style URI is found, or destination if an IBM-style URI is found.	jmsDestination
Reply To Destination	Yes	Yes	None	The name of the JMS destination to which the receiving application must send a reply message. For a reply message to be returned to this JMS destination, the JMS destination name must be known to the domain of the JMS provider that is used by the receiving client. If the Get Response By Correl ID property is cleared, this queue uniquely identifies messages destined for the paired SOAPAsyncResponse node. If the Get Response By Correl ID property is checked, this queue can then be shared between multiple nodes. This property takes its initial value from a WSDL URI property, depending on whether the WSDL `address` URI is formatted in the W3C (standards) style, or the IBM (proprietary) style. Reply To Destination is set to the value of replyToName found in the WSDL if a W3C-style URI is found, or to the first of replyToName, replyTo, replyToDestination, or replyDestination if an IBM-style URI is found. If any of these other properties are present, they display as a name-value pair in the User Parameters table.	jmsReplyToDestination
JMS provider name	Yes	No	WebSphere MQ	Select a JMS vendor name from the list, or enter a name of your choice. The name must match the name of a configurable service that is defined for the broker to which you deploy the message flow. When you select a name from the list, the Initial context factory property is updated automatically with the relevant Java™ class. If you enter your own JMS provider name, you must also enter a value for the Initial context factory.
Initial context factory	Yes	Yes	com.sun.jndi.fscontext. RefFSContextFactory	The starting point for a JNDI namespace. A JMS application uses the initial context to obtain and look up the connection factory and queue or topic objects for the JMS provider. If you select a JMS provider name from the list in JMS provider name, the Initial context factory property is updated automatically with the relevant Java class. If you enter your own JMS provider name, you must also enter a value for the Initial context factory. The default value is `com.sun.jndi.fscontext.RefFSContextFactory`, which defines the file-based Initial context factory for the WebSphere MQ JMS provider. This property takes its initial value from a WSDL URI property, depending on whether the WSDL `address` URI is formatted in the W3C (standards) style, or the IBM (proprietary) style. Initial context factory is set to the value of jndiInitialContextFactory found in the WSDL if a W3C-style URI is found, or initialContextFactory if an IBM-style URI is found.	initialContextFactory
JNDI URL bindings location	Yes	Yes		The system path or the LDAP location for the bindings file. The bindings file contains definitions for the JNDI administered objects that are used by the SOAPAsyncRequest node. This property is disabled when the Initial context factory is com.ibm.mq.jms.Nojndi. When you enter a value for JNDI URL bindings location, ensure that it complies with the following instructions: Construct the bindings file before you deploy a message flow that contains a SOAPAsyncRequest node. Do not include the file name of the bindings file in this field. If you have specified an LDAP location that requires authentication, configure the LDAP principal (userid) and LDAP credentials (password) separately. These values are configured at broker level. For information about configuring these values, see mqsicreatebroker command and mqsichangebroker command. The string value must include a supported URL prefix that has a URL handler that is available on the class path. For information about constructing the JNDI administered objects bindings file, see the JMS provider documentation. This property takes its initial value from a WSDL URI property, depending on whether the WSDL `address` URI is formatted in the W3C (standards) style, or the IBM (proprietary) style. JNDI URL bindings location is set to the value of jndiURL found in the WSDL if a W3C-style URI is found, or jndiProviderURL if an IBM-style URI is found.	locationJndiBindings
Connection factory name	Yes	Yes		The name of the connection factory that is used by the SOAPAsyncRequest node to create a connection to the JMS provider. This property is initially configured from the imported WSDL. This name must exist in the bindings file. The Connection factory name must be a JMS QueueConnectionFactory. This property takes its initial value from a WSDL URI property, depending on whether the WSDL `address` URI is formatted in the W3C (standards) style, or the IBM (proprietary) style. Connection factory name is set to the value of jndiConnectionFactoryName found in the WSDL if a W3C-style URI is found, or connectionFactory if an IBM-style URI is found.	connectionFactoryName
User Parameters	No	No		This table describes user properties that will be sent in the requestURI property of the outgoing request message. The properties are name-value pairs that exist in the WSDL and are not used by other properties of the SOAPAsyncRequest node.
JNDI parameters	No	No		A table mapping JNDI context parameters to their type. These properties take their initial values from any W3C-style WSDL properties starting with jndi-. IBM-style WSDL does not support JNDI parameters, but you can set these properties on the node.
Get Response By Correl ID	No	Yes	Cleared	If this property is checked, the SOAPAsyncRequest node sends the request message with the Correl ID specified in the Unique identifier property, and the SOAPAsyncResponse node receives only response messages that match that Correl ID. This allows a single Reply To Destination queue to be shared between several pairs of SOAPAsyncRequest and SOAPAsyncResponse nodes, if this property is checked for all those nodes. This functionality works only with web service providers that support reading the Correl ID from the request message and using it as the Correl ID in the response message.
Backout destination	No	Yes		The SOAPAsyncResponse node sends response messages to this destination when errors prevent the response message flow from processing the response message. The message is removed from the reply to destination. The backout properties are set by the SOAPAsyncRequest node, but used only by its paired SOAPAsyncResponse node.	backoutDestination
Backout threshold	No	Yes	0	This value controls when a message is put to the backout destination. For example, if the value is 3, the JMS provider attempts to deliver the message to the input destination three times. After the third attempted delivery, the message is not rolled back to the reply to destination and is sent to the Backout destination. The backout properties are set by the SOAPAsyncRequest node, but used only by its paired SOAPAsyncResponse node. See Configuring the backout threshold property.

The SOAPAsyncRequest node Message Delivery properties are described in the following table. This sub tab is enabled only if the selected binding in the Basic tab uses JMS transport.

Property	M	C	Default	Description	mqsiapplybaroverride command property
Target Service	No	No	None	Used by the SOAPAsyncRequest node when dispatching the service request. This property takes its initial value from the targetService WSDL property.	targetService
Delivery mode	No	Yes	Persistent	This property controls the persistence mode that a JMS provider uses for a message. Valid values are: Persistent: the message survives if the JMS provider has a system failure. Non Persistent: the message is lost if the JMS provider has a system failure. This property takes its initial value from a WSDL URI property, depending on whether the WSDL `address` URI is formatted in the W3C (standards) style, or the IBM (proprietary) style. Delivery mode is set to the value of deliveryMode found in the WSDL if a W3C-style URI is found, or to the first of deliveryMode or persistence if an IBM-style URI is found. If both these properties are present, the second property displays as a name-value pair in the User Parameters table.	deliveryMode
Message Priority	No	Yes	4	This property assigns relative importance to the message and can be used for message selection by a receiving web service. Select a value between 0 (lowest priority) and 9 (highest priority). The default value is 4, which indicates medium priority. Priorities in the range 0 - 4 indicate typical delivery. Priorities in the range 5 - 9 indicate faster delivery. This property takes its initial value from a WSDL URI property, depending on whether the WSDL `address` URI is formatted in the W3C (standards) style, or the IBM (proprietary) style. Priority is set to the value of priority found in the WSDL if a W3C-style URI is found, or to the first of priority or Priority if an IBM-style URI is found. If both these properties are present, the second property displays as a name-value pair in the User Parameters table.	messagePriority
Message Expiration (ms)	No	Yes	0	This property controls the length of time, in milliseconds, for which the JMS provider keeps the output JMS message. The default value, 0, is used to indicate that the message must not expire. This property takes its initial value from the timeToLive WSDL property.	messageExpiration
Message Type	No	Yes	bytes	Select a value from the list to configure the type of JMS message that is produced by the SOAPAsyncRequest node. Valid values are text and bytes.	messageType

The SOAPAsyncRequest node Transactions properties are described in the following table. This setting does not apply when the node uses HTTP transport.

Property	M	C	Default	Description
Transaction Mode	Yes	No	Automatic	This property controls whether the message is output under a JMS transaction. Valid values are Yes, No, and Automatic. Select No to output the message using a non-transactional JMS session. Select Yes to output the message using a transactional JMS session. The JMS transaction can be either local or XA coordinated. To use an XA coordinated transaction, using an XA JMS session, you must also select the message flow property Coordinated Transaction in the BAR file properties. Select Automatic if you want the message transactionality to be inherited from the Transaction mode setting on the Input node at the start of the flow. See Configuring for coordinated JMS transactions.

Property

Default

Description

Transaction Mode

Yes

Automatic

This property controls whether the message is output under a JMS transaction. Valid values are Yes, No, and Automatic.

Select No to output the message using a non-transactional JMS session.

Select Yes to output the message using a transactional JMS session. The JMS transaction can be either local or XA coordinated. To use an XA coordinated transaction, using an XA JMS session, you must also select the message flow property Coordinated Transaction in the BAR file properties.

Select Automatic if you want the message transactionality to be inherited from the Transaction mode setting on the Input node at the start of the flow.

See Configuring for coordinated JMS transactions.

The SOAPAsyncRequest node Advanced properties are described in the following table.

SOAP headers that are part of the must understand headers list are incorporated into the flow rather than causing a SOAP fault. Adding headers to the must understand headers list stops SOAP faults being generated by SOAP headers.

You do not need to add must understand headers for WS-Addressing and WS-Security because these are understood if you configure WS Extensions.

The must understand headers list that is configured on this node is applied to the corresponding SOAPAsyncResponse node when the SOAPAsyncResponse node receives the reply from the remote server.

Property	M	C	Default	Description
WSDL-defined SOAP response headers	No	No		The WSDL-defined SOAP response headers table is read-only, and is populated based on the SOAP headers defined in the output part of the selected operations. By default, the check boxes, in the second column of the table, are cleared for all entries in the WSDL-defined SOAP response headers table. You must select the relevant check box to add the header to the must understand headers list. When the node is configured to act in gateway mode, with no WSDL required, this table is cleared. The original values of these fields are restored if the operation mode of the node is changed back to WSDL mode.
User-defined SOAP response headers	No	No		You can add custom headers (headers that are not defined in the WSDL file) in the User-defined SOAP headers table. Use Add, Edit, and Delete for this table. You must select the relevant check box, in the second column of the table, to ensure that the newly added custom header is added to the must understand headers list.

The SOAPAsyncRequest node WS Extensions properties are described in the following table.

Property	M	C	Default	Description
Use WS-Addressing	No	No	Selected	You cannot edit this property. This property indicates that WS-Addressing is always engaged on the SOAPAsyncRequest node. For more details about WS-Addressing with the SOAPAsyncRequest node, see WS-Addressing with the SOAPAsyncRequest and SOAPAsyncResponse nodes.
Allow MTOM	No	Yes	No	This property controls whether MTOM is enabled for the parser. Valid values are Yes, No, and Force. For more information about using SOAP MTOM with the SOAPReply, SOAPRequest, and SOAPAsyncRequest nodes; see Using SOAP MTOM with the SOAPReply, SOAPRequest, and SOAPAsyncRequest nodes. For more information about MTOM, see SOAP MTOM. MTOM support is disabled when the node is configured to act in gateway mode.	allowMTOM
WS-Security	No	No		This table and features two columns: Alias XPath Expression You can add XPath expressions with an associated Alias value to the WS-Security table. The Alias is resolved in a Policy Set that is created by the administrator. The Policy Set resolves the Alias to either encrypt or sign the part of the message referred to by the XPath Expression. You can Add, Edit, and Delete in this table.

Property

Default

Description

Use WS-Addressing

Selected

You cannot edit this property. This property indicates that WS-Addressing is always engaged on the SOAPAsyncRequest node.

For more details about WS-Addressing with the SOAPAsyncRequest node, see WS-Addressing with the SOAPAsyncRequest and SOAPAsyncResponse nodes.

Allow MTOM

Yes

This property controls whether MTOM is enabled for the parser. Valid values are Yes, No, and Force.

For more information about using SOAP MTOM with the SOAPReply, SOAPRequest, and SOAPAsyncRequest nodes; see Using SOAP MTOM with the SOAPReply, SOAPRequest, and SOAPAsyncRequest nodes. For more information about MTOM, see SOAP MTOM.

MTOM support is disabled when the node is configured to act in gateway mode.

allowMTOM

WS-Security

This table and features two columns:

Alias
XPath Expression

You can add XPath expressions with an associated Alias value to the WS-Security table. The Alias is resolved in a Policy Set that is created by the administrator. The Policy Set resolves the Alias to either encrypt or sign the part of the message referred to by the XPath Expression. You can Add, Edit, and Delete in this table.

The Monitoring properties of the node are described in the following table.

Property	M	C	Default	Description
Events	No	No	None	Events that you have defined for the node are displayed on this tab. By default, no monitoring events are defined on any node in a message flow. Use Add, Edit, and Delete to create, change or delete monitoring events for the node; see Configuring monitoring event sources using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled check box.

LocalEnvironment overrides

You can dynamically override set values in the local environment in the same way as setting values in other elements of a message. For a full list of values you can override in the local environment, see Local environment overrides.

Working with WrittenDestination data

After the request has been made, the WrittenDestination folder in LocalEnvironment is updated with the WS-Addressing, compression details (if in use), and transport details. A WrittenDestination for a SOAPAsyncRequest node has the following format, with WS-Addressing and Compression present only if it is used:

WrittenDestination = (
   SOAP  = (
      Request = (
         WSA = (
            To = 'URI'
            ReplyTo = 'http://server:7800/reply'
            MessageID = 'id'
            Action = 'doAllTheStuff'
         )
         Transport = (
            HTTP = (
               WebServiceURL = 'http://server:8080/service'
               Compression   = (
                  OriginalSize   = 775
                  CompressedSize = 411
            )
         )
      )
   )
)

The following example uses JMS transport:

WrittenDestination = (
   SOAP  = (
      Request = (
         WSA = (
            To = 'URI'
            ReplyTo = 'http://server:7800/reply'
            MessageID = 'id'
            Action = 'doAllTheStuff'
         )
         Transport = (
            JMS = (
               Destination = 'jms:jndi:B2BQUEUEIN'
            )
         )
      )
   )
)

ac56200_.htm |

Last updated Friday, 21 July 2017