Deciding which nodes to use

IBM Integration Bus also provides an interface that you can use to define your own nodes, which are known as user-defined nodes.

The mode that your integration node is working in can affect the types of node that you can use; see Restrictions that apply in each operation mode.

Your decision about which nodes to use depends on the processing that you want to perform on your messages.

Input, output, and request nodes

Input and output nodes define points in the message flow to which client applications send messages (input nodes, such as MQInput), and from which client applications receive messages (output nodes, such as MQOutput). Client applications interact with these nodes by putting messages to, or getting messages from, the I/O resource that is specified by the node as the source or target of the messages. Although a message flow must include at least one input node, it does not have to include an output or request node.

An input node is different from other nodes because it controls when the rest of the message flow is triggered to do its processing. The input node is designed to check when there is data for the message flow to process, read that data from the transport or server, and present that data to the rest of the flow for processing. The other nodes do processing, but do not control when the flow gets invoked.

You can also use reply, request, and response nodes to interact with other applications from within a message flow; these types of node are supplied for a subset of protocols only.

• If you are creating a message flow for deployment to an integration node, you must include at least one input node to receive messages. The input node that you select depends on the source of the input messages, and where in the flow you want to receive the messages.
• If you want to send the messages that are produced by the message flow to a target application, you can include one or more output nodes. The output node that you select depends on the transport across which the target application expects to receive those messages.
• If you want to make a request, in the middle of your flow, to an external system, and put the result into the message tree, use a request node.

Nodes for manipulating, enhancing, and transforming messages

Most enterprises have applications that have been developed over many years, on different systems, using different programming languages, and different methods of communication. IBM Integration Bus 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. Surname first or last, with or without middle initials, uppercase or lowercase, 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 (for example, changing order of fields, byte order, or language), 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 the importance of message transformation:

• An order entry application has a part ID in the body of the message, but its associated stock application expects it in the message header. The message is directed to a message flow that knows the two different formats, and can therefore reformat the information as it is needed.
• A data-entry application creates messages containing stock trade information. Some applications that receive this message need the information as provided, but others need additional information added to the message about the price to earnings (PE) ratio. The stock trade messages are directed to a message flow that passes the message unchanged to some output nodes, but calculates and adds the extra information for the others. The message flow does this calculation by looking up the current stock price in a database, and uses this value and the trade information in the original message to calculate the PE value before passing on the updated message.

You can also create message flows that use these nodes to interact with each other. Although the default operation of one message flow does not influence the operation of another message flow, you can force this action by configuring your message flows to store and retrieve information in an external source, such as a database.

These nodes are supplied to transform messages.

Nodes for making decisions

You can use nodes that determine the order and flow of control in the message flow in various ways to decide 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 in the message flow. Routing is independent of message transformation, although the route that 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 typical 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 that is determined by the added message content.

These nodes are provided to decide about the route that a message follows through the message flow.

Nodes for controlling time-sensitive operations

You might want a batch application process 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; see Nodes for controlling time-sensitive operations.

Miscellaneous nodes

Other nodes exist to do the following tasks:

• Collate requests
• Create message collections
• Control the sequence of messages
• Handle and report errors
• Invoke the message flow security manager

See Miscellaneous nodes for details.