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 built-in nodes can be considered in several categories, and are displayed in the workbench grouped in those categories (although this grouping has no effect on their operation). You can also categorize user-defined nodes in the same way. The categories are:
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.
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 that you can connect to other nodes in the main flow in the same way that you connect any other node.
You can deploy only message flows that 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 that you can connect to other nodes in the main flow in the same way that you connect any other node.
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 because it provides 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. Surname 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 (modelled) messages, or 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 datasource that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
You can control the way in which the database is accessed by this node by specifying user and password information for the datasource that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
If your message manipulation requirements are complex, complete 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 datasource that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
Using a mapping editor, you can develop mappings to perform simple manipulations on predefined messages in the Mapping node. Do not use the mappings that you develop for use in a Mapping node in any other type of node.
Using a 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 datasource that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
You can only update a database from this node; you cannot update any 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 datasource that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
You can only update databases from these nodes: you cannot update any 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 datasource that you specify in the node property. Use the mqsisetdbparms command to initialize and maintain these values.
You can only update a database from this node; you cannot update any message content. If you want to update message content, use the Compute or Mapping node.
If you want to transform an input XML message into another format using XMLT style sheets, use the XMLTransformation node. It is imperative that the data can be parsed into a XML message. The result of the transformation is output as a BLOB message. The style sheet, using the rules defined within it, can sort the data; select data elements to include or to exclude based on some criteria, and transform the data into some other data format.
The Xalan-Java transformation engine (Apache Xalan-java XSLT processor) is used as the underlying transformation engine. For details about XMLT, refer to W3C XSL Transformations.
You can deploy style sheets and XML files to broker execution groups, to facilitate 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 Message Broker publish subscribe.
The MQJMSTransform node can be used to send messages to legacy message flows and to interoperate with WebSphere MQ JMS and WebSphere Message Broker 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.
You can control the way in which the database is accessed by this node by specifying user and password information for the datasource 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. On distributed systems, use the mqsisetdbparms command to initialize and maintain these values.
On z/OS, use the broker started task ID to access the database.
Use this node in preference to the Compute node to provide this function; although you can configure the Compute node to control message selection and routing, the Filter node performs better.
You might want a batch job to run every day at a specific time, or you might want information to be processed and published at fixed intervals (for example, currency exchange rates are calculated and sent to banks), or you might want to take a specified recovery action if certain transactions are not completed within a defined time. For all these cases two timeout nodes (TimeoutControl and TimeoutNotification) are provided.
More than one TimeoutControl node can be associated with each TimeoutNotification node.
You can collate related requests and responses using the AggregateControl, AggregateReply, and AggregateRequest nodes. Use these nodes to generate several requests in response to one input message, and 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.
You can use nodes that affect error handling and reporting:
With the exception of the Compute, Extract, and Mapping nodes, the input message received by a node and the output message sent on by the node are identical.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac00330_ |