You can also connect them to other nodes in the same way. Because you can define a subflow once, and use it in more than one message flow (and even in more than one message flow project), a subflow can provide benefits:
However, you must remember that a subflow is not a single node, and its inclusion increases the number of nodes in the message flow, which might affect its performance.
Consider these examples of subflow use:
You can use the Passthrough node in a subflow
as the first node that follows the Input node to identify the subflow in which
it is included. You can specify an identifier (Label) in whatever way meets
your requirements, for example to identify the level or version of the flow
in which it is configured. The Passthrough node does not process the message
in any way. The message that it propagates on its out terminal is the same
message that it received on its in terminal. For example, if you develop an
error processing subflow to include in several message flows, you might want
to modify that subflow. However, you might want to introduce the modified
version initially to just a subset of the message flows in which it is included.
Set a value for the instance of the Passthrough node that identifies which
version of the subflow you have included.
The use of subflows is illustrated in the following sample:
The use of subflows is demonstrated in the Error Handler sample and the Coordinated Request Reply sample. The Error Handler sample uses a subflow to trap information about errors and store the information in a database. The Coordinated Request Reply sample uses a subflow to encapsulate the storage of the ReplyToQ and ReplyToQMgr values in a WebSphere MQ message so that the processing logic can be easily reused in other message flows and to allow alternative implementations to be substituted.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac00370_ |