SOAPInput node
Use the SOAPInput node to process client SOAP messages, so that the integration node operates as a SOAP web services provider.
- Developer
- Application Integration Suite
- Standard
- Advanced
- Express
- Scale
- Adapter
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 integration node raises an exception when the reply is attempted.
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.
If you are using SOAP nodes and HTTP nodes in message flows on a single integration node, you can choose to handle HTTP messages by using either the integration node 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:
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 by using deployable WSDL files.
A client can send an HTTP GET message to the web service endpoint that is exposed by
the SOAPInput node, suffixed with a query string
?wsdl
, and receive a response with the WSDL definition that is used to configure
the flow; see Message flow configuration with a WSDL file.
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 integration node 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 the Failure terminal is not connected, 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 the Catch terminal is not connected, the message is discarded, the Maximum client wait time expires, and an error is returned to the client.
- 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.
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 an integration node 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.
- Retry mechanism
- Retry threshold
- Short retry interval
- Long retry interval
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. |
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. This property takes a string value. To use a WSDL file in a shared library, the container that contains your message flow must
reference that shared library. When the SOAPInput node uses a
WSDL file in a shared library, the shared library name is specified; for
example:
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 WS-I BP 1.1: Allow SOAP/JMS as transport URI check box. and clear the Only deployable WSDL files can be used to configure the SOAP nodes. If the WSDL is in a shared library, the name of the shared library is specified in the WSDL file name property. If the WSDL file is in a message set project, the message set project 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. The following situations result in an error condition:
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:
When you save the message flow file, validation of some of the WSDL-related properties
occur to ensure that:
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:
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:
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 properties in a BAR file. |
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:
|
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
(231)-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 integration node 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 Message flow configuration with a WSDL file.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
|
|
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 integration node 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 This property takes its initial value from a WSDL URI property, depending on whether the WSDL
|
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:
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 |
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 |
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. If the Backout threshold is set to 0, redelivery is not attempted. Set the threshold according
to the capabilities of the JMS provider.
A SOAP fault is sent only when the backout threshold has been reached. |
|
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, 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,
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:
This property takes its initial value from a WSDL URI property, depending on whether the
WSDL |
|
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 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 |
||
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 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:
|
||
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 JMS and SOAP nodes for local 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:
|
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 model | Yes | No | Set automatically from the WSDL file name property. | The name or location of the message model schema file in which the incoming
message is defined. When a WSDL file is associated with the node, this property is automatically set
to the location of the WSDL file. If the WSDL file is in a shared library, this field specifies the
name of the shared library in braces, {}. If you set this property, then later update the project dependencies to remove this message model reference, a warning is issued. Either update the Message model property, or restore the reference to this message model. Input message parsing properties are disabled when the node is configured to act in gateway mode. |
Message | No | No | The name of the incoming message. The node detects the message type automatically. You cannot set this property. | |
Physical 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.
|
|
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 |
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 by using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled check box. |