See information about the latest product version
Configurable message flow properties
When you add a message flow to a broker archive (BAR) file in preparation for deploying it to a broker, you can set additional properties that influence its run time operation. These properties are available for review and update when you select the Manage and Configure tab for the broker archive file.
- Additional Instances
- This property specifies the number of additional threads that
the broker 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 broker 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
- For WebSphere MQ messages, this property
specifies how many input messages are processed by a message flow
before a sync point is taken (by issuing an MQCMIT command).
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 broker is configured correctly. If you do not set up the queue manager correctly, the broker 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 Supported databases 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 Information Center 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 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 execution group. 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 broker, execution group, 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 broker, execution group, 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 broker, execution group, or containing application has been restarted. The flow or application is in stopped state after deployment or redeployment, and after the broker, execution group, 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 broker, execution group, 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 Broker Archive 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 Message Broker API (also known as the CMP API). For example, a systems
monitoring tool might use the CMP 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 in a CMP 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 broker 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.