Information about deciding which nodes to use.
Read the concept topic about message flow nodes.
WebSphere Message Broker includes a large number of message processing nodes that you can use within your message flows. It also provides an interface that you can use to define your own nodes, known as user-defined nodes.
Your decision about which nodes to use depends on the processing that you want to perform on your messages.
The use of message flows that contain MQeInput nodes in WebSphere Message Broker Version 6.0 is deprecated. Redesign your message flows to remove the MQe nodes and replace them with MQ nodes that are configured to your own specifications and coordinated with your MQe Gateway configuration. For more details, see Migrating a message flow that contains WebSphere MQ Everyplace nodes.
The Real-timeInput node is an input node and the Real-timeOptimizedFlow node is a complete message flow that provides a high performance publish/subscribe message flow.
An instance of the Input node represents an In terminal. For example, if you have included one instance of the Input node, the subflow icon shows one In terminal, which you can connect to other nodes in the main flow in the same way that you connect any other node.
To deploy a message flow, it must have at least one input node. If your message flow does not contain an input node, you are prevented from adding it to the broker archive file. The input node can be in the main flow, or in a message flow that is embedded in the main flow.
You can use more than one input node in a message flow. For more information, see Using more than one input node.
The use of message flows that contain MQeOutput nodes in WebSphere Message Broker Version 6.0 is deprecated. Redesign your message flows to remove the MQe nodes and replace them with MQ nodes that are configured to your own specifications and coordinated with your MQe Gateway configuration. For more details, see Migrating a message flow that contains WebSphere MQ Everyplace nodes.
An instance of the Output node represents an Out terminal. For example, if you have included two instances of the Output node, the subflow icon shows two Out terminals, which you can connect to other nodes in the main flow in the same way that you connect any other node.
The WebSphere Adapters input nodes monitor an EIS for a particular event. When that event occurs, business objects are sent to the input node. The node constructs a tree representation of the business objects and propagates it to the Out terminal so that the data can be used by the rest of the message flow.
The WebSphere Adapters request nodes can send and receive business data. They request information from an EIS and propagate the data to the rest of the message flow.
Most enterprises have applications that have been developed over many years, on different systems, using different programming languages, and different methods of communication. WebSphere Message Broker removes the need for applications to understand these differences by providing the ability to configure message flows that transform messages from one format to another.
For example, personal names are held in many forms in different applications. Family name first or last, with or without middle initials, upper or lower case: these are just some of the permutations. Because you can configure your message flow to know the requirements of each application, each message can be transformed to the correct format without modifying the sending or receiving application.
You can work with the content of the message to update it in several ways. Your choices here might depend on whether the message flow must handle predefined (modeled) messages, self-defining messages (for example, XML), or both.
A message flow can completely rebuild a message, convert it from one format to another (whether format means order of fields, byte order, language, and so on), remove content from the message, or introduce specific data into it. For example, a node can interact with a database to retrieve additional information, or to store a copy of the message (whole or part) in the database for offline processing.
The following examples show how important message transformation can be:
You can also create message flows that interact with each other using these nodes. Although the default operation of one message flow does not influence the operation of another message flow, you can force this by configuring your message flows to store and retrieve information in an external source such as a database.
Use the ESQL editor to create an ESQL module, specific to this node, that contains the statements defining the actions to perform against the message or database. Do not use the ESQL code that you develop for use in a Compute node in any other type of node.
You can control the way in which the database is accessed by this node by specifying user and password information for the data source that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
If your message manipulation requirements are complex, perform these within a single Compute node. Fewer, more complex Compute nodes perform better than a larger number of simpler nodes because the broker parses the message on entry to each Compute node.
You can control the way in which the database is accessed by this node by specifying user and password information for the data source that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
Using the Mapping editor, you can develop mappings to perform simple manipulations on predefined messages. Do not use the mappings that you develop for use in a Mapping node in any other type of node.
Use the Extract node to create a new output message from specified elements of the input message. You can extract parts of the message, and optionally change their content, to create a new output message that is a partial copy of the message received by the node. The Extract node handles only predefined messages.
Using the Mapping editor, you can develop mappings to perform simple manipulations on predefined messages in the Extract node. Do not use the mappings that you develop for use in an Extract node in any other type of node.
This node provides a very flexible interface with a wide range of functions. It also has properties that you can use to control the way in which the interaction participates in transactions.
You can control the way in which the database is accessed by this node by specifying user and password information for the data source that you specify in the node properties. Use the mqsisetdbparms command to initialize and maintain these values.
You can update only databases from this node; you cannot update message content. If you want to update message content, use the Compute or Mapping node.
The DataDelete, DataInsert, and DataUpdate nodes handle only predefined messages. Use a mapping editor to develop mappings to perform these functions. Do not use the mappings that you develop for these nodes in any other type of node. These nodes also let you control the transactional characteristics of the updates that they perform.
You can control the way in which the database is accessed by this node by specifying user and password information for the data source that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
You can update only databases from these nodes; you cannot update message content. If you want to update message content, use the Compute or Mapping node.
You can control the way in which the database is accessed by this node by specifying user and password information for the data source that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
You can update only a database from this node; you cannot update message content. If you want to update message content, use the Compute or Mapping node.
The Xalan-Java transformation engine (Apache Xalan-java XSLT processor) is used as the underlying transformation engine. For more information about XML Transformations link to the W3C specification of the syntax and semantics of the XSL Transformations language for transforming XML documents into other XML documents, see W3C XSL Transformations.
You can deploy style sheets and XML files to broker execution groups, to help with style sheet and XML file maintenance.
The JMSMQTransform node can be used to send messages to legacy message flows and to interoperate with WebSphere MQ JMS and WebSphere MQ Publish/Subscribe.
The MQJMSTransform node can be used to send messages to legacy message flows and to interoperate with WebSphere MQ JMS and WebSphere MQ Publish/Subscribe.
Use the MQOptimizedFlow node to replace a publish/subscribe message flow that consists of an MQInput node connected to a Publication node and that uses the JMS over WebSphere MQ transport. The MQOptimizedFlow node cannot be used on z/OS systems.
Use the MQOptimizedFlow node to improve performance, particularly where a single publisher produces a persistent publication for a single subscriber.
For example, if your node accesses a database, include a user-defined node to interact with the database. You can control the way in which the database is accessed by this node by specifying user and password information for the data source that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
The following table summarizes what you can update in these nodes.
Node | Update database? | Update message? | Update LocalEnvironment? | Message set required? |
---|---|---|---|---|
Compute | Yes | Yes | Yes | No |
Database | Yes | No | Yes | No |
DataDelete | Yes | No | Yes | Yes |
DataInsert | Yes | No | Yes | Yes |
DataUpdate | Yes | No | Yes | Yes |
Extract | Yes | Yes | Yes | Yes |
Mapping | Yes | Yes | Yes | Yes |
Warehouse | Yes | No | Yes | Yes |
You can use nodes that determine the order and flow of control within the message flow in various ways to make decisions about how messages are processed by the flow. You can also use nodes (TimeoutControl and TimeoutNotification) that determine the time, and frequency of occurrence, of events within the message flow. Routing is independent of message transformation, although the route a message takes might determine exactly what transformation is performed on it.
For example, a money transfer application always sends messages to one other application. You might decide that every message with a transfer value of more than $10,000 must also be sent to a second application, to enable all high-value transactions to be recorded.
In another example, a national auto club offers a premier service to specific members for orders above a threshold value. Most orders are routed through the usual channels, but, if the membership number and order value meet certain criteria, the order gets special treatment.
You can also establish a more dynamic routing option by building additional routing information into the message when it is processed. Optional sets of rules are set up to receive messages according to values (destinations) set into the message. You can establish these rules such that a message is processed by one or more of the optional sets of rules, in an order determined by the added message content.
Use the following nodes to make decisions about the route that a message follows through the message flow:
The Validate node replaces the Check node which is deprecated in WebSphere Message Broker Version 6.0 and subsequent releases. The Validate node works in the same way as the Check node, but it has additional Validation properties to allow the validation of message content by parsers that support that capability.
The node's terminals are True, False, Unknown, and Failure; the message is propagated to the True terminal if the test succeeds, and to the False terminal if it fails. If the statement cannot be resolved (for example, it tests the value of a field that does not appear in the input message), the message is propagated to the Unknown terminal. If any other error is detected, the message is propagated to the Failure terminal.
The test in the ESQL statement can depend on message content, database content, or a combination of these.
If you reference a database, you can control the way in which it is accessed by this node by specifying user and password information for each data source defined in the registry on the broker system. Use the mqsisetdbparms command to initialize and maintain these values.
Use this node in preference to the Compute node to provide message selection and routing; the Filter node is more efficient for this task.
More than one TimeoutControl node can be associated with each TimeoutNotification node.
Use the AggregateControl, AggregateReply, and AggregateRequest nodes to collate related requests and responses. Use these nodes to generate several requests in response to one input message, to control and coordinate the responses that are received in response to those requests, and to combine the information provided by the responses to continue processing.
Use the following nodes to affect error handling and reporting: