Monitoring subflows

A subflow is a section of a message flow that includes one or more message processing nodes. In general terms, a subflow can be any section of a message flow that can be separately identified. You can consider the message flow as being like a main routine and a subflow as being a subroutine. You can explicitly delineate the subroutine in the Message Brokers Toolkit by making a separate message flow, which is then embedded in the main flow (referred to here as Type I). Or, the message flow can have sections of nodes that you want to monitor as subflows, even though they are not explicitly delineated into a separate flow (referred to in this example as Type II).

When a message flow is deployed to a broker, the broker regards the entire message flow as a single entity. There is no obvious delineation in the broker for dividing the flow into separate subflows. The name assigned to a Type I subflow is not known to the broker (this entity is displayed only in the Message Brokers Toolkit and configuration manager). Any given message processing node is not aware of the other message processing nodes around it. Therefore, for the CandleMonitor node to be useful in monitoring both types of subflows, you must provide the required information by customizing the node.

To gather correct subflow statistics for either type of subflow, the subFlowOutput CandleMonitor node is required in the subflow; it is not optional, as is the case with the output node for a main message flow.

CandleMonitor node Statistics (the lowest level, most detailed report) combines data for all instances of the same node that are part of a subflow that has been embedded multiple times in the same message flow.

You can assign the subFlowName attribute to an input or output CandleMonitor node. When you use input and output node types in combination you do not need to insert two CandleMonitor nodes in a flow at the same position when a subflow comes either at a beginning or end of a message flow. The combination output node is probably used more, because a Type I subflow might have an output that is the destination for a message going through the whole message flow as well as through the subflow. (For a description of the effects of assigning a subFlowName attribute to a node type other than subFlowInput or subFlowOutput, see subFlowName.)