When you design a message flow, consider several design factors
which include some or all of the following 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 you want 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 output terminals that can be connected to direct certain messages to different
nodes. This is further described in Using nodes for decision making.
- Whether you can make use of subflows that provide a well-defined
subset of processing. You might be able to reuse subflows created for another
project (for example, an error processing routine). Or you might want to 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
is influenced by several aspects of how you configure your nodes and the flow.
For more information, see Optimizing message flow response times.
- Whether you can use the destination list within the LocalEnvironment
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 you want to use WebSphere
MQ cluster
queues. For more information, see Using WebSphere MQ cluster queues for input and output.
- Whether you want to use WebSphere
MQ shared
queues on z/OS. Their use is described further in Using WebSphere MQ shared queues for input and output (z/OS).
- Whether you want to validate input messages received by
the input node, or output messages generated by the Compute node, or both.
For more information, see Validating messages.
- Whether you want to view or record message structure in
Trace node output. Information about how you can do this is provided in 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, as described in Accessing databases from message flows.
- Whether your messages must be handled within a transaction.
Some built-in nodes have properties that you can set to control how transactions
are managed, and how messages are processed within a transaction. For more
information, see Configuring coordinated message flows.
- Whether you want your messages to go through data conversion. The options
that you have are described in Configuring message flows for data conversion.
- What steps you can 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 are encountered 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 WebSphere Message Broker Basics IBM Redbook.