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