When you design a message flow, consider
the following questions and options:
- Which nodes provide the function that you require. In many cases, you
can choose between several nodes that provide a suitable function. You might
have to consider other factors listed here to determine which node is best
for your overall needs. You can include built-in nodes, user-defined nodes,
and subflow nodes. For more information, see Deciding which nodes to use.
- Whether it is appropriate to include more than one input node. For more
information, see Using more than one input node.
- How to specify the characteristics of the input message.
See Defining input message characteristics for more details.
- Whether to determine the path that a message follows through
the message flow, based on the content or the characteristics of the message.
Several nodes provide checks or examination of the message, and have output
terminals that can be connected to direct certain messages to different nodes.
For more information, see Using nodes for decision making.
- Whether you can use subflows that provide a well-defined
subset of processing. You might be able to reuse subflows that were created
for another project (for example, an error processing routine). Or you might
create a subflow in your current project, and reuse it in several places within
the same message flow. For more information, see Using subflows.
- What response times your applications expect from the message flow. This
factor is influenced by several aspects of how you configure your nodes and
the message flow. For more information, see Optimizing message flow response times.
- Whether your message flow processing makes demands on system
resources such as stack size. For more information, see System considerations for message flow development.
- Whether you can use the destination list within the LocalEnvironment
that is associated with the message to determine the processing within the
message flow (using RouteToLabel and Label nodes), or the target for the output
messages (for example, by setting the Destination
Mode property of the MQOutput node to Destination
List). For more information, see Creating destination lists.
- Whether to use WebSphere MQ cluster queues.
For more information, see Using WebSphere MQ cluster queues for input and output.
- Whether to use WebSphere MQ shared queues
on z/OS. For more information, see Using WebSphere MQ shared queues for input and output (z/OS).
- Whether to validate input messages that are received by the
input node, or output messages that are generated by the Compute node, or
both. For more information, see Validating messages.
- Whether to view or record message structure in Trace node
output. For more information, see Viewing the logical message tree in trace output.
- Whether your message flows access data in databases. You
must configure message flow nodes, databases, and database connections to
enable this function, as described in Accessing databases from message flows.
If you include nodes that use ESQL, see Accessing databases from ESQL for
information about how to code the appropriate statements.
You can also
access databases through the Data perspective in the workbench;
see Connecting to databases using the Data perspective.
- Whether your messages must be handled within a transaction.
You can set the properties of some built-in nodes to control how transactions
are managed, and how messages are processed within a transaction. For more
information, see Configuring globally coordinated message flows.
If
you want to include JMSInput and JMSOutput nodes in your message flow transactions,
you must consider the additional information in Configuring JMSInput and JMSOutput nodes to support global transactions.
- Whether you want your messages to go through data conversion. The available
options are described in Configuring message flows for data conversion.
- Whether you want to use the MQGet node. Using MQGet nodes explains
how messages are processed by the MQGet node, and describes a request-reply
scenario using this node.
- How your message flows can benefit from user exits.
For more information, see Exploiting user exits.
- What steps to take to ensure that messages are not lost. For more information,
see Ensuring that messages are not lost.
- How errors are handled within the message flow. You can use the facilities
provided by the broker to handle any errors that arise during message flow
execution (for example, if the input node fails to retrieve an input message,
or if writing to a database results in an error). However, you might prefer
to design your message flow to handle errors in a specific way. For more information,
see Handling errors in message flows.
For a basic introduction to developing message flows, see the IBM
Redbooks publication WebSphere Message Broker Basics.
(This link works only if you are connected to the Internet.)