About this task
When you design a message flow, consider the following
questions and options:
- The mode that your integration node is working in can
affect the types of message flow node that you can use and the number of message flows you can
deploy. For more information, see Restrictions that apply in each operation mode.
- Which message flow 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 message flow 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. For more
information, see Defining input message characteristics.
- Whether to determine the path that a message follows through the
message flow, based on the content or the characteristics of
the message. Several message flow nodes provide checks or examination
of the message, and have output terminals that can be connected
to direct certain messages to different message flow nodes. For more
information, see Using nodes for decision making.
- Whether it is appropriate to split message flow processing between different locations. A
message flow can call another flow directly. You can deploy both flows to IBM Integration Bus, IBM Integration
Bus on Cloud, or IBM App Connect on IBM Cloud. You can also deploy one flow to IBM Integration Bus and one flow to IBM Integration
Bus on Cloud or IBM App Connect on IBM Cloud. Callable flows also facilitate reuse because they can be
called by multiple message flows. For more information, see Splitting the processing of message flows.
- 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 in the same message flow. For more information, see 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 resources for message flow development.
- Whether you can use the destination list in the local environment that is associated with the
message to determine the processing in the message flow (for example, by 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 integration nodes, databases, and database connections
to enable this function, as described in Working with databases.
You must also configure your message flows; see Accessing databases from message flows.
If you include message flow nodes
that use ESQL, for information about how to code the appropriate
statements, see Accessing databases from ESQL. If
you want to access databases from Java™ nodes
by using JDBC, see Interacting with databases by using the JavaCompute node or Extending the capability of a Java message processing or output node.
- Whether your message flows access data in files. By using the FileInput and FileOutput
nodes, your message flows can read messages from files and write messages to files in the local file
system, or on a network file system that appears local to the integration node. For more
information, see Connecting client applications.
- Whether your messages must be handled in a transaction. You can set the properties of some
built-in message flow nodes to control how transactions are managed, and how messages are processed
in a transaction. For more information, see Configuring transactionality for message flows.
If you want to
include JMSInput and JMSOutput nodes in your message flow transactions, you must
consider the additional information in Configuring JMS and SOAP nodes to support globally coordinated transactions.
- Whether you want your messages to go through data conversion.
For information about the available options, see Configuring message flows for data conversion.
- Whether you want to use the MQGet node. For more
information about how messages are processed by the MQGet
node, and a description of request-reply scenarios that uses this node, see Working with WebSphere MQ.
- 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 in the message flow. You can use the facilities
provided by the integration node 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.
- Whether you want a systems monitoring tool to be able
to query, discover, and set certain user-defined properties at run
time. For more information, see Setting message flow user-defined properties at run time by using a custom integration application.