Subflows can be included in your message flows in exactly
the same way as you include built-in or user-defined nodes.
You can also connect subflows to
other nodes in the same way. You can define a subflow once, and use
it in more than one message flow (and even in more than one message
flow project), so a subflow can provide the following benefits:
- Reusability and reduced development time.
- Consistency and increased maintainability of your message flows
(consider a subflow as analogous to a programming macro, or to inline
code that is written once but used in many places).
- Flexibility to tailor a subflow to a specific context (for example,
by updating the output queue or data source information).
However, 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 define a subflow that provides a common sequence
of actions that applies to several message flows if an error is encountered;
for example, you might have a common error routine that writes the
message to a database through the Warehouse node, and puts it
to a queue for processing by an error recovery routine. The use of
this routine in multiple message flows, or in several places within
one message flow, provides an efficient and consistent use of resources
and avoids reinventing such routines every time an error is encountered.
- You might want to perform a common calculation on
messages that pass through several different message flows; for example,
you might access currency exchange rates from a database and apply
these to calculate prices in several different currencies. You can
include the currency calculator subflow in each of the message flows
in which it is appropriate.
Use the
Passthrough node
to enable version control of a subflow at run time. The
Passthrough node allows you
to add a label to your message flow or subflow. By combining this
label with keyword replacement from your version control system, you
can identify which version of a subflow is included in a deployed
message flow. You can use this label for your own purposes. If you
have included the correct version keywords in the label, you can see
the value of the label:
- Stored in the broker archive (BAR) file, using the mqsireadbar command
- As last deployed to a particular broker, on the properties of
a deployed message flow in the Message Brokers Toolkit
- In the run time, if you enable user trace for that message flow
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 demonstrated in the following samples:
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.
You can view samples only when you use the information
center that is integrated with the Message Brokers Toolkit.