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

SOAPInput node

Use the SOAPInput node to process client SOAP messages, so that the broker operates as a SOAP Web Services provider.

This topic contains the following sections:

Purpose
Using this node in a message flow
Connecting the terminals
Terminals and properties

Purpose

The SOAPInput node is typically used with the SOAPReply node, which can be included in the same message flow, or a different flow in the same integration server.

You can connect a SOAPReply node to the Out terminal to handle successful responses. If you also want your message flow to handle reply processing after a timeout, connect a SOAPReply node to the HTTP Timeout terminal.

You cannot use an HTTPReply node to respond to a Web service request that is received by a SOAPInput node; the broker raises an exception when the reply is attempted.

Start of change If your message flow uses HTTP transport, you can configure security for the SOAPInput node by using either Basic-Auth, or Integrated Windows Authentication (NTLM, SPNEGO or Kerberos). For more information about IWA, see Authenticating incoming requests with IWA on Windows and Authenticating incoming requests with IWA on Linux or UNIX. End of change

If you are using SOAP nodes and HTTP nodes in message flows on a single broker, you can choose to handle HTTP messages by using either the broker listener or embedded integration server listeners. If a listener in your configuration receives messages that both SOAPInput and HTTPInput nodes might get, you must carefully check the URL specifications in these nodes. If both URL specifications match an incoming message, the wrong type of node might get the message, and processing might fail or produce unexpected results. This situation occurs if you specify identical values for the Path suffix for URL properties of the HTTPInput node and the SOAPInput node. It can also occur if you use wildcards in either or both specifications, and an incoming message matches both properties.

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

SOAPInput node icon

Using this node in a message flow

The SOAPInput node can be used in a message flow that accepts and processes SOAP messages. The node is configured using deployable WSDL. Look at the following sample to see how to use this node:

SOAP Nodes

A client can send an HTTP GET to the web service endpoint exposed by the SOAPInput node, suffixed with a query string ?wsdl, and receive a response with the WSDL definition used to configure the flow; see Configuring message flows by using a WSDL.

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.

A client can send a request that has a Content-Encoding of gzip or deflate. When such a request is received the content is decoded and the Content-Encoding header is removed.

You can configure WS-RM (reliable messaging) for inbound messages that are processed by the SOAPInput node. For further information, see Web Services Reliable Messaging.

You can choose between the broker-wide listener and the integration server listener to manage HTTP messages; SOAP nodes use the integration server listener by default. For more information, see HTTP listeners.

Connecting the terminals

The SOAPInput node routes each message that it retrieves successfully to the Out terminal. If message validation fails, the message is routed to the Failure terminal; you can connect nodes to this terminal to handle this condition. If you have not connected the Failure terminal, the message is discarded, the Maximum client wait time expires, and an error is returned to the client.

If the message is caught by this node after an exception has been thrown further on in the message flow, the message is routed to the Catch terminal. If you have not connected the Catch terminal, the message is discarded, the Maximum client wait time expires, and an error is returned to the client.

If the Maximum client wait time expires, by default, the listener sends a SOAP fault message to the client, indicating that its timeout has expired. If you have connected the HTTP Timeout terminal, and you are using the HTTP transport, the SOAP Fault message is propagated through the HTTP Timeout terminal. You must include a SOAPReply node in the sequence of nodes connected to the HTTP Timeout terminal and this node must send a valid SOAP Fault message. The listener waits again for the interval defined by the Maximum client wait time (sec) property, or for 10 seconds, whichever is the shorter interval:

If a response is received before this second interval expires, the listener propagates the response to the client.
If a response is not received before this second interval expires, the listener sends a SOAP fault message to the client, indicating that its timeout has expired.

Because the listener waits for only a brief interval after the message has been propagated through the HTTP Timeout terminal, you must ensure that the sequence of nodes that you connect to the HTTP Timeout terminal includes a SOAPReply node, which sends a response before this interval expires. If you have connected the HTTP Timeout terminal, but you are not using the HTTP transport, the message is not propagated through the HTTP Timeout terminal. The listener sends a SOAP fault message to the client, indicating that its timeout has expired.

Terminals and properties

The SOAPInput node terminals are described in the following table.

Name	Type	Description
Failure	Output data	The output terminal to which a SOAP message is routed if a failure is detected when the message received is propagated to the Out terminal (such as a message validation failure).
Out	Output data	The output terminal to which the SOAP message is routed when it is received successfully and if further processing is required in this message flow. If no errors occur in the input node, a valid SOAP message that is received from an external resource is always sent to the Out terminal first.
HTTPTimeout	Output data	The output terminal to which a timeout SOAP fault message is routed if the SOAPReply node that is connected to the Out terminal does not respond within the time interval specified by the Maximum client wait time property. This terminal is used only if the message is sent across the HTTP transport, and WS-RM is not being used. If a broker-wide listener is configured for SOAP nodes, this terminal has no effect.
Catch	Output data	The output terminal to which the message is routed if an exception is thrown downstream and is caught by this node.

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 SOAPInput 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 following Retry properties are no longer available on the SOAPInput node:

Retry mechanism
Retry threshold
Short retry interval
Long retry interval

When a SOAP over HTTP message fails, a SOAP fault is sent back to the client; the message exchange pattern is complete and no message exists to retry. When a SOAP over JMS message fails, retry processing is handled according to the backout properties defined on the JMS Transport tab.

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

Property	M	C	Default	Description
Node name	No	No	The node type; SOAPInput	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 SOAPInput node Basic properties are described in the following table.

Property	M	C	Default	Description
Operation mode	Yes	Yes	Specify WSDL interface to expose	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. Specify WSDL interface to expose 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. Operate in gateway mode 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. 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; for more details, see Importing from WSDL and Message Sets: Importing WSDL definitions from the command line. message set project, or the WSDL file was not imported correctly; for more details, 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	The first Port type found in the WSDL file (that has an associated HTTP binding with it).	This property lists all the port types that are 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. This property takes a string value. The following situation causes an error condition: The selected Port type does not contain at least one operation. When you save the message flow file, validation of some of the WSDL-related properties occur to ensure that: The WSDL file exists in the message set. The selected Port type, Binding operation, and Service port are all valid in the content of the selected WSDL file. If one or more of these conditions are not met, an error is generated, and you cannot add a message flow that contains this SOAPInput node to a broker archive (BAR) file. WSDL properties are disabled when the node is configured to act in gateway mode.
Imported binding	Yes	No		The Imported binding property lists the imported SOAP bindings associated with the selected port type. Only HTTP or JMS transport is supported. When you select a binding, the property tab for the associated transport is enabled; otherwise, it is disabled. Bindings are listed in the order in which they are displayed in the WSDL file. By default, the first imported binding that implements the operation, and has an associated service port, is selected. This property is updated every time the Port type value changes. This property type is String. The following situations cause an error condition: No imported SOAP bindings (with HTTP or JMS transport) in the WSDL file are associated with the Port type. The selected binding does not have any operations. WSDL properties are disabled when the node is configured to act in gateway mode.
Service port	Yes	No		The Service port field lists all the service ports that point to the selected binding. By default, the first service port for the binding is selected. This property is updated every time the selected binding value changes. This property type is String. The following situation causes an error condition: No ports point to the selected binding. WSDL properties are disabled when the node is configured to act in gateway mode.
Target namespace	Yes	No		This property displays the namespace of the selected WSDL file. This property type is String. WSDL properties are disabled when the node is configured to act in gateway mode.
Transport	No	No		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 if one is selected; 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 SOAPInput 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
Path suffix for URL	Yes	Yes	None	Path suffix for URL is the HTTP path selector on which the node accepts inbound messages. This property is set automatically from the `<soap:address>` element of the selected Service port. Whenever the selected port is updated, URL Selector is updated accordingly. However, if you override this value, your value persists, and the URL is no longer updated from the service port. If you choose to override this property, you must specify the [<path>]. If you configure the same HTTP path for nodes in multiple message flows, an inbound request to that endpoint might be processed by any of those message flows. If the message flows are configured differently, they process the message differently and so this can lead to unpredictable behavior. If you require additional resources for a single HTTP path, you can configure additional instances instead of creating multiple message flows. For more information, see Configurable message flow properties.	urlSelector
Use HTTPS	No	Yes	Cleared	This property type is Boolean and is configured automatically from the `<soap:address>` element of the selected Service port. If the address contains an HTTPS URL, the check box is selected; otherwise it is cleared. However, if you manually override this property value, it is no longer updated from the corresponding service port. To enable the HTTPS protocol when this property is selected, perform the following steps: Create a new key store of type "jks" and choose a password. Create a new self signed certificate with a label of your choice. Run the following command: `mqsichangeproperties brokername -o BrokerRegistry -n brokerKeystoreFile -v keystoreFile` Run the following command: `mqsichangeproperties brokername -o BrokerRegistry -n brokerTruststoreFile -v keystoreFile` Run the following command: `mqsisetdbparms brokername -n brokerKeystore::password -u na -p keystorePassword` Run the following command: `mqsisetdbparms brokername -n brokerTruststore::password -u na -p keystorePassword` Deploy your message flow to the broker. This process uses TLS rather than SSL. To enable SSL, run the following command: `mqsichangeproperties brokername -e integrationServer -o HTTPSConnector -n sslProtocol -v SSL`. If your flow uses a SOAPRequest node, you should also change the value of the Protocol property on the SOAPRequest node.	useHTTPS
Maximum client wait time (sec)	Yes	Yes	180	The time that the client waits for a remote server to respond with a "message received" acknowledgment. The valid range is zero (which means a short wait) through (2³¹)-1. This property specifies the maximum length of time that the TCP/IP listener that received the input message from the Web service client waits for a response from a SOAPReply node. If a response is received within this time, the listener propagates the response to the client. If a response is not received in this time, a SOAP fault message is generated indicating that the timeout has expired. This fault message is either sent by the listener or when using the HTTP transport, the timeout terminal processing. See the Connecting the terminals and Terminals and properties sections for more information on the HTTP Timeout terminal.	maxClientWaitTime
Enable support for ?wsdl	N	Y	Cleared	If this property is selected, the broker returns WSDL and XML Schema information relating to this endpoint in response to an HTTP GET request with a `?wsdl` query string. This allows you to control the distribution of your WSDL. For a full description, see Configuring message flows by using a WSDL. This property is disabled when the node is configured to act in gateway mode.

The SOAPInput 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
Source	Yes	No	None	The name of the queue from which the node receives incoming messages. 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. Source 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.
JMS provider name	Yes	No	WebSphere MQ	Select a JMS vendor name from the list, or enter a name of your choice. 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. The name must match the name of a configurable service that is defined for the broker to which you deploy the message flow.
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 SOAPInput 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 SOAPInput 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 classpath. 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 SOAPInput 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
Backout destination	No	Yes		The SOAPInput node sends input messages to this destination when errors prevent the message flow from processing the message, and the message must be removed from the input destination. The backout destination name must exist in the bindings file.	backoutDestination
Backout threshold	No	Yes	0	The value that 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 input destination and is sent to the Backout destination. A SOAP fault is sent only when the backout threshold has been reached. See Configuring the backout threshold property.
JNDI context parameters	No	No		A table that maps JNDI context parameters to their type. These properties are initially configured from the imported WSDL. These properties take their initial values from any W3C-style WSDL properties starting with jndi-. IBM-style WSDL URIs do not support JNDI context parameters, but you can set these properties on the node.

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

For a description of how to construct the JMS message selector, see JMS message selector.

Property	M	C	Default	Description	mqsiapplybaroverride command property
Application property	No	Yes		The message selector that filters messages according to the application property value. If the JMS provider is required to filter messages, based on message properties that are set by the originating JMS client application, enter a selector string for Application property, specifying both the property name and the selection conditions; for example, `OrderValue > 200`. Leave Application property blank if you do not want the input node to make a selection based on application property.
Timestamp	No	Yes		The message selector that filters messages according to the JMSTimestamp. If the JMS provider is required to filter messages that have been generated at specific times, enter a selector string for Timestamp, where the value is an unqualified Java millisecond time; for example, `105757642321`. Qualify the selector with operators, such as `=`, `BETWEEN` or `AND`. Leave Timestamp blank if you do not want the input node to make a selection based on the JMSTimeStamp.
Delivery mode	No	Yes	All	The message selector that filters messages according to the message delivery mode. If the JMS provider is required to filter messages based on the JMSDeliveryMode header value in the JMS messages, select an option for Delivery mode from the list: Select Non Persistent to receive messages that are marked as non-persistent by the originating JMS client application. Select Persistent to receive messages that are marked as persistent by the originating JMS client application. Select All to receive both persistent and non-persistent messages. (This value is the default.) 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.
Priority	No	Yes		The message selector that filters messages according to the message priority. If the JMS provider is required to filter messages based on the JMSPriority header value in the JMS message, enter a selector string for Priority. Valid values for Priority are from 0 (lowest) to 9 (highest). For example, enter `= 5` to receive messages of priority 5, `> 4` to receive messages with a priority greater than 4, or `BETWEEN 4 AND 8` to receive messages with a priority in the range 4 - 8. Leave Priority blank if you do not want the input node to make a selection based on the JMSPriority. 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.
Message ID	No	Yes		The message selector that filters messages according to the message ID. If the JMS provider is required to filter messages based on the JMSMessageID header, enter a selector string for Message ID. For example, enter `> WMBRK123456` to return messages where the Message ID is greater than `WMBRK123456`. Leave Message ID blank if you do not want the input node to make a selection based on JMSMessageID.
Redelivered	No	Yes		If the JMS provider is required to filter messages based on the JMSRedelivered header, enter a selector string for Redelivered: Enter = FALSE if the input node accepts only messages that have not been redelivered by the JMS provider. Enter = TRUE if the input node accepts only messages that have been redelivered by the JMS provider. Leave Redelivered blank if you do not want the input node to make a selection based on JMSRedelivered.
Correlation ID	No	Yes		The message selector that filters messages according to the correlation ID. If the JMS provider is required to filter messages based on the JMSCorrelationID header, enter a selector string for Correlation ID. For example, `= WMBRKABCDEFG` returns messages with a Correlation ID that matches this value. Leave Correlation ID blank if you do not want the input node to make a selection based on JMSCorrelationID.
Target service	No	No		This property is configured from the value of the targetService property found in the JMS endpoint location URL that is contained in the port section of the WSDL. The SOAP/JMS message will be read from the source queue only if the message has a targetService value that matches the value defined on the node. This value is used by the server component to determine the port component to which the request is dispatched. This property takes its initial value from the targetService WSDL property.	targetService

The SOAPInput node Transactions properties are described in the following table. This setting does not apply when the node is using HTTP transport.

Property	M	C	Default	Description
Transaction Mode	Yes	No	No	This property controls whether the message is received under a JMS transaction. Valid values are Yes and No. Select No to receive 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. See Configuring for coordinated JMS transactions. The value set for Transaction mode on the SOAPInput node is inherited by nodes downstream in the message flow that have their Transaction mode set to Automatic. Other resources that perform work within the message flow, such as DB2® or WebSphere MQ, use transactions regardless of the node's Transaction mode setting, and commit their transaction after the message is processed.

Property

Default

Description

Transaction Mode

Yes

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

Select No to receive 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.

See Configuring for coordinated JMS transactions.

The value set for Transaction mode on the SOAPInput node is inherited by nodes downstream in the message flow that have their Transaction mode set to Automatic.

Other resources that perform work within the message flow, such as DB2® or WebSphere MQ, use transactions regardless of the node's Transaction mode setting, and commit their transaction after the message is processed.

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

Property	M	C	Default	Description
SOAP 1.1 actor (SOAP 1.2 role)	Yes	No	Ultimate Destination (Ultimate Receiver)	Use this property to configure the SOAP actor (SOAP 1.1 protocol) or SOAP role (SOAP 1.2 protocol) that is performed by the SOAPInput node. The default value is Ultimate Destination (Ultimate Receiver). (Ultimate Destination relates to SOAP 1.1 and Ultimate Receiver relates to SOAP 1.2). You can enter any predefined or user-defined value. Predefined roles are specified in the respective SOAP 1.1 or SOAP 1.2 specifications, and are used to process SOAP headers that are targeted at the specific role. If you select empty, an error occurs when the message flow is validated. This property takes a string value.
Set destination list	No	No	Selected	This property specifies whether to add the method binding name to the route-to-label destination list. If you select this check box, the method binding name is added so that you can use a RouteToLabel node in the message flow after the SOAPInput node. This property type is Boolean.
Label prefix	No	No	None	The prefix to add to the method name when routing to label. Add a Label prefix to avoid a clash of corresponding label nodes when you include multiple input nodes in the same message flow. By default, no label prefix exists; therefore, the method name and label name are identical. The default prefix is an empty string so that the operation name and the label name are identical, but the field displays the user instruction: <enter a prefix if required>. This property is enabled only if the setDestinationList property is enabled.
Route inbound processing failures to failure terminal	No	Yes	Cleared	Select this check box to send any fault to the Failure terminal during inbound SOAP processing. If this property is selected, in a situation during inbound SOAP processing that results in a SOAP fault, instead of immediately sending the SOAP fault back to the client, the fault is sent to the Failure terminal instead to allow logging and recovery processing. In this situation, an exception list is sent to the Failure terminal with the inbound message as a BLOB. By default, this check box is cleared.	sendProcessingFaultsToFailure
WSDL defined SOAP headers	No	No		This table is read-only and is populated by the SOAP headers that are defined in the output part of the selected operations. The table is updated automatically when the selected operation is updated. By default, the check boxes in the second column of the table are cleared for all entries in the WSDL-defined table. You must select the check boxes for those headers that you want to add to the must understand headers list. 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 have to add must understand headers for WS-Addressing and WS-Security because these elements are understood if you configure WS Extensions. This property is generated in the CMF file. 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 headers	No	Yes	None	You can add custom headers in this table. Use the Add, Edit and Delete controls to manipulate rows in this table. You must ensure that the check box for the custom header you have added is selected (in the second column of the table), so that the header is added to the must understand headers list. This property is generated in the CMF file. When the node is configured to act in gateway mode, with no WSDL required, custom headers in this table have their Operation set to *. The original values of these fields are restored if the operation mode of the node is changed back to WSDL mode.

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

Property	M	C	Default	Description
Use WS-Addressing	No	No	Cleared	This property indicates whether to engage WS-Addressing on the SOAPInput node. By default, this check box is cleared. If this property is selected, a reply can be sent back to a different web service client as specified in the WS-Addressing properties. The reply can be sent using a transport that is different than the one used for the incoming message.
Place WS-Addressing headers into LocalEnvironment	No	No	Cleared	This property specifies whether the node puts WS-Addressing headers received in the message into the local environment tree. WS-Addressing headers are not accessible to the flow if this check box is cleared because, by default, all headers are processed and removed.
WS-Security	No	Yes		This complex property is in the form of a table and consists of 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 that is referenced by the XPath Expression. You can use the Add, Edit and Delete controls in this table.

The SOAPInput node Input Message Parsing properties are described in the following table.

Property	M	C	Default	Description
Message domain	No	No	SOAP	The domain that is used to parse the incoming message. By default, the message that is propagated from the SOAPInput node is in the SOAP domain. You cannot specify a different domain. Input message parsing properties are disabled when the node is configured to act in gateway mode.
Message set	Yes	No	Set automatically from the WSDL file name property.	The name of the message set in which the incoming message is defined. This value is set automatically to the message set that contains the WSDLfile when the WSDL is associated with the node. If you set this property, then later update the project dependencies to remove this message set reference, a warning is issued. Either update the Message set property, or restore the reference to this message set project. Input message parsing properties are disabled when the node is configured to act in gateway mode.
Message type	No	No		The name of the incoming message. The node detects the message type automatically. You cannot set this property.
Message format	No	No		The name of the physical format of the incoming message. You cannot set this property.

The SOAPInput node Parser Options properties are described in the following table.

Property	M	C	Default	Description
Parse timing	No	No	On demand	This property controls when an input message is parsed. Valid values are On demand, Immediate, and Complete. The default value, On demand, causes parsing of the message to be delayed. For a full description of this property, see Parsing on demand.
Build tree using XML Schema data types	No	No	Selected	This property controls whether the syntax elements in the message tree have data types taken from the XML Schema. This property is cleared and disabled when the node is configured to act in gateway mode.
Retain mixed content	No	No	Cleared	This property controls whether the XMLNSC parser creates elements in the message tree when it encounters mixed text in an input message. If you select the check box, elements are created for mixed text. If you clear the check box, mixed text is ignored and no elements are created.
Retain comments	No	No	Cleared	This property controls whether the XMLNSC parser creates elements in the message tree when it encounters comments in an input message. If you select the check box, elements are created for comments. If you clear the check box, comments are ignored and no elements are created.
Retain processing instructions	No	No	Cleared	This property controls whether the XMLNSC parser creates elements in the message tree when it encounters processing instructions in an input message. If you select the check box, elements are created for processing instructions. If you clear the check box, processing instructions are ignored and no elements are created.
Opaque elements	No	No	Blank	This property is used to specify a list of elements in the input message that are to be parsed opaquely. Opaque parsing is performed only if validation is not enabled (that is, if Validate is None); entries that are specified in Opaque Elements are ignored if validation is enabled.

The SOAPInput node Validation properties are described in the following table. See Validation properties.

Property	M	C	Default	Description	mqsiapplybaroverride command property
Validate	No	Yes	Content and value	This property controls whether the SOAP parser validates the body of each input message against XML schema generated from the message set. Valid values are None, Content and value, and Content. The SOAP parser invokes the XMLNSC parser to validate the XML body of the SOAP Web Service. If a message is propagated to the Failure terminal of the node, it is not validated. For more details, see Validating messages and Validation properties. Validation properties are disabled, and the Validate property is set to None, when the node is configured to act in gateway mode.	validateMaster
Failure action	No	No	Exception	This property controls what happens if validation fails. You can set this property only if you set Validate to Content or Content and value. Valid values are User Trace, Local Error Log, Exception, and Exception List. Validation properties are disabled when the node is configured to act in gateway mode.

The SOAPInput node Instances properties are described in the following table.

Property	M	C	Default	Description	mqsiapplybaroverride command property
Additional instances pool	No	Yes	Use Pool Associated with Message Flow	This property specifies whether additional instance threads are allocated from a thread pool for the whole message flow, or from a thread pool for use by that node only. If you select Use Pool Associated with Message Flow, additional instances are obtained from the message flow value. If you select Use Pool Associated with Node, additional instances are allocated based on the number specified in the Additional instances property.
Additional instances	No	Yes	0	The number of additional instances that the node can start if the Additional instances pool property is set to Use Pool Associated with Node. By default, no additional instances are given to the node.	additionalInstances

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.

ac56170_.htm |

Last updated Friday, 21 July 2017