Configurable message flow properties

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

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 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 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 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.

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 IBM Integration API (also known as the CMP). For example, a systems monitoring tool might use the CMP 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.