- Additional Instances
- This property specifies the number of additional threads that
the integration node can use to service the message flow. These additional
threads are created only if there are sufficient input messages. You
can use up to 256 threads. The default value is 0. Additional threads
can increase the throughput of a message flow but you must consider
the potential effect on message order.
If the message flow processes WebSphere® MQ messages, you can configure
the message flow to control the message order. Set the Order Mode property on the MQInput node accordingly. You
might also need to set the Commit
by Message Group and Logical
Order properties.
An MQInput node opens the input
queue with MQOO_INPUT_AS_Q_DEF, which uses the DEFSOPT property of
the input queue. Therefore, you must ensure that the input queue has
been defined with DEFSOPT(SHARED) and with the SHARE property set
to enable multiple integration node threads to read from the input
queue. If these properties are not set in this way, the message flow
threads report that the queue is in use (MQRC=2042), and the message
flow might stop processing messages on the input queue.
If
you have multiple input nodes in your message flow, the available
additional threads might not be allocated evenly between the different
input nodes. In an extreme case, all the threads might be allocated
to a single input node, and only one aspect of message flow throughput
is improved. To avoid this problem, you can use the Additional Instances Pool property,
together with the Additional Instances property,
to allocate a pool of additional instance threads for each input node.
- Start Additional Instances When Flow Starts
- This property specifies whether all additional instance threads
are to start when the flow starts. Both flow and node-scope instances
will start if this option is set to true. The default value is false.
- Commit Count
- This
property specifies how many WebSphere MQ input
messages are processed per message flow thread before a sync
point is taken (by issuing an MQCMIT command). For example;
with 5 message flow instances, and a Commit Count of 20,
there could be a total of 100 (20*5) messages on the input queue
under 5 sync points. Therefore, increasing the number of message
flow instances, and raising the value of Commit
Count will increase queuing performance.
The default
value of 1 is also the
minimum permitted value. Change this property to avoid frequent
MQCMIT calls when messages are being processed quickly and
the lack of an immediate commit can be tolerated by the receiving
application.
Use the Commit
Interval to ensure that a commit is performed periodically
when not enough messages are received to fulfill the Commit Count.
This
property has no effect if the message flow does not process WebSphere MQ messages.
- Commit Interval
- This property specifies the maximum time interval between the
last WebSphere MQ message being received,
and a sync point being taken. If no message is received in the specified
time interval, a sync point is taken (by issuing an MQCMIT command),
even if the number of messages processed does not fulfill the value
of the Commit Count property.
The time interval is specified in seconds, as a decimal number
with a maximum of three decimal places (millisecond granularity).
The value must be in the range 0.000 through 60.000. The default value
is 0.
This property has no effect if the message flow does not
process WebSphere MQ messages,
or if the value of the Commit Count is
1
- Consumer policy set
- This property specifies the consumer policy to use to authenticate,
encrypt, and sign messages for the SOAPRequest, SOAPAsyncRequest, and SOAPAsyncResponse nodes.
- Consumer policy set bindings
- This property associates a policy set binding with a consumer
policy set and contains information that is specific to the environment
and operating system, such as information about keys.
- Coordinated Transaction
- This property controls whether the message flow is processed as an
XA coordinated transaction, coordinated by WebSphere MQ. Such a message flow is
said to be fully XA coordinated. The default value is No.
Use coordinated transactions
only where you need to process the message and any database updates
that are performed by the message flow in a single unit-of-work, using
a two-phase commit protocol. In this case, both the message is read
and the database updates are performed, or neither is done.
If
you change this value, ensure that the queue manager for the
integration node is configured correctly. If you do not set
up the queue manager correctly, the integration node generates a message
when the message flow receives a message to indicate that,
although the message flow is to be XA coordinated,
the queue manager configuration does not support coordination.
See
IBM® Integration Bus system
requirements for information about
which databases are supported as participants in an XA
coordinated transaction, and the System Administration section
of the
WebSphere MQ Version 7.5 product documentation
online for
how to configure WebSphere MQ and
the database managers.
This property has no effect if
the message flow does not process WebSphere MQ messages.
- Monitoring profile name
- This property specifies the name of the monitoring profile configurable
service to apply to one or more message flows in a BAR file. The monitoring
profile is used to configure your message flows to emit monitoring
events.
For more information, see Configuring monitoring event sources by using a monitoring profile.
- Provider policy set
- This property specifies the provider policy to use to authenticate,
encrypt, and sign messages for the SOAPInput and SOAPReply nodes.
- Provider policy set bindings
- This property associates a policy set binding with a provider
policy set and contains information that is specific to the environment
and operating system, such as information about keys.
- Security profile name
- This property specifies a security profile that has authorization
enabled so that a message flow can complete authorization with Tivoli® Federated Identity Manager
(TFIM). You can set a security profile on a message flow or on individual
input nodes. If no security profile is set for the input nodes, the
setting is inherited from the setting on the message flow.
For
more information, see Configuring authorization with TFIM V6.1.
- Start mode
- This property specifies the default behavior of message flows
and applications when you deploy or restart an integration server.
For example, you might have a message flow that creates resources
that are required by other message flows. Therefore, you might want
to start one message flow before all others when the flows are deployed,
or when the integration node, integration server, or containing application
are started. You can set one message flow to start automatically,
then set other message flows to require a manual restart.
You can
set the Start Mode property to one of the following values:
- Maintained
- This value is the default, and indicates that the flow or application
is started when deployment is complete, and remains running until
a stop command is issued. After a stop command has been issued, the
flow or application remains stopped until a start command is issued.
The state of the flow or application remains unchanged after redeployment,
or after the integration node, integration server, or containing application
has been restarted.
- Manual
- This value indicates that the flow or application must always
be started manually after deployment or after the integration node,
integration server, or containing application has been restarted.
The flow or application is in stopped state after deployment or redeployment,
and after the integration node, integration server, or containing
application is restarted, even if the flow or application was running
before the deployment or restart.
- Automatic
- This value indicates that the flow or application is always started
automatically after deployment, redeployment, or after the integration
node, integration server, or containing application is restarted.
You can set this property for message
flows and applications. The state of an application overrides the
state of any message flows that it contains. For example, if an application
is stopped, no flows in that application can run, even if they have
been set to start automatically.
For more information, see Configuring the start mode of flows and applications at development time.
- User-defined properties
- The initial value of a user-defined property (UDP) can be modified
at design time by the Message Flow editor, or overridden
at deployment time by the BAR file editor. The
advantage of UDPs is that their values can be changed by operational
staff at deployment time. If, for example, you use UDPs to hold
configuration data, you can configure a message flow for a particular
computer, task, or environment at deployment time, without having
to change the code at the node level. You can
also query and set the values of user-defined properties at
run time by using the IBM Integration
API.
For example, a systems monitoring tool might use the IBM Integration
API to modify the value
of a user-defined property at run time to change the behavior
of the message flow.
For introductory information about UDPs
and dynamic UDPs, see User-defined properties in ESQL and User-defined properties.
For information about configuring
UDPs at deployment time, see Configuring a message flow at deployment time with user-defined properties.
For information about configuring UDPs at run time, see Setting message flow user-defined properties at run time by using a custom integration application.
You can view and update other configurable properties
for the message flow. The properties that are displayed depend on
the nodes within the message flow; some have no configurable properties
to display. The node properties that are configurable are predominantly
system-related properties that are likely to change for each integration
node to which the message flow is deployed. These properties include
data source names and the names of WebSphere MQ queues
and queue managers. For full details of configurable properties for
a node, see the appropriate node description.