Deciding which nodes to use

WebSphere Business Integration Event Broker includes a large number of message processing nodes that you can use within your message flows. Start of changeYou can also choose from user-defined nodes that have been created and supplied by users, or other vendors and companies.End of change

Your decision about which nodes to use depends on the processing that you want to perform on your messagesStart of change. 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 areEnd of change:

Input and output
Input and output nodes define points in the message flow to which clients send messages (input nodes such as MQInput) and from which clients 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 node.
  • If you are creating a message flow that you want to deploy to a broker, you must include at least one input node to receive messages. The input node that you choose depends on the source of the input messages and where in the flow you want to receive the messages: Start of change
    MQInput
    If the messages arrive at the broker on a WebSphere MQ queue and the node is to be at the start of a message flow.
    MQeInput
    If the messages arrive at the broker from WebSphere MQ Everyplace clients.
    SCADAInput
    If the messages are sent by a telemetry device.
    Real-timeInput or Real-timeOptimizedFlow
    If the messages are sent by a JMS or multicast application.
    Start of changeUser-defined input nodeEnd of change
    Start of changeIf the message source is a client or application that uses a different protocol or transport.End of change
    Input node
    If you are creating a message flow that you want to embed in another message flow (a subflow) that you will not deploy as a standalone message flow, you must include at least one Input node to receive messages into the subflow.

    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.

    End of change 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.

  • If you want to send the messages produced by the message flow to a target application, you can include one or more output nodes. The one that you choose depends on the transport across which the target application expects to receive those messages:
    Publication
    If you want to distribute the messages using the publish/subscribe network for applications that subscribe to the broker across all supported protocols. A Publication node is an output node that use output destinations that are identified by subscribers whose subscriptions match the characteristics of the current message.
    MQOutput
    If the target application expects to receive messages on a WebSphere MQ queue, or on the WebSphere MQ reply-to queue specified in the input message MQMD.
    MQReply
    If the target application expects to receive messages on the WebSphere MQ reply-to queue specified in the input message MQMD
    MQeOutput
    If the target application expects to receive messages through WebSphere MQ Everyplace
    SCADAOutput
    If a telemetry device is the target of the output messages, and the Publication node is not suitable
    Real-timeOptimizedFlow
    If the target application is a JMS or multicast application
    Start of changeUser-defined output nodeEnd of change
    Start of changeIf the target is a client or application that uses a different protocol or transport

    The UDPSend node is a working sample of a user-defined node that provides this function.

    End of change
    Output node
    If you are creating a message flow that you want to embed in another message flow (a subflow) that you will not deploy as a standalone message flow, you must include at least one Output node to propagate messages to subsequent nodes that you connect to the subflow.

    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.

XMLTransformation

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 (http://xml.apache.org/xalan-j) is used as the underlying transformation engine. For details about XMLT, refer to http://www.w3.org/TR/xslt.

You can deploy style sheets and XML files to broker execution groups, to facilitate style sheet and XML file maintenance.

Related concepts
Message flows overview
End-user application support
Related tasks
Setting up DB2
Designing a message flow
Creating a message flow
Defining message flow content
Deploying
Related reference
Built-in nodes
End-user application support