The WebSphere Message Broker Toolkit

When you start the WebSphere Message Broker Toolkit, a single window is displayed.This window is the WebSphere Message Broker Toolkit, which contains one or more perspectives.

A perspective is a collection of views and editors that you use to complete a specific task, or work with specific types of resource. The two significant perspectives in the WebSphere Message Broker Toolkit are the Broker Application Development perspective for application development, and the Debug perspective for debugging message flows. The first time that you start the WebSphere Message Broker Toolkit, the Broker Application Development perspective is displayed.

An additional stand-alone component, the WebSphere Message Broker Explorer, is supplied for advanced administrative users, and enables additional administration tasks that you cannot perform in the WebSphere Message Broker Toolkit.

Components of WebSphere Message Broker

WebSphere Message Broker is comprised of two principle parts, a development environment for the creation of message flows, message sets, and other message flow application resources; and a runtime environment, which contains the components for running those message flow applications that are created in the development environment.
Development environment
The development environment is where the message flow applications that provide the logic to the broker are developed. The broker uses the logic in the message flow applications to process messages from business applications at run time. In the Message Brokers Toolkit, you can develop both message flows and message sets for message flow applications.

Message flows

Message flows are programs that provide the logic that the broker uses to process messages from business applications. Message flows are created by connecting nodes together, with each node providing some basic logic. A selection of built-in nodes is provided with WebSphere Message Broker for performing particular tasks. These tasks can be combined to perform complex manipulations and transformations of messages.
A choice of methods is available for defining the logic in the message flows to transform data. Depending on the different types of data or the skills of the message flow application developer, the following options are available:
=>Extended Structured Query Language (ESQL)
=>Java
=>eXtensible Style sheet Language for Transformations (XSLT)
=>Drag-and-drop mappings
The nodes in the message flows define the source and the target transports of the message, any transformations and manipulations based on the business data, and any interactions with other systems such as databases and files. For an example message flow, see the simple ESQL message flow shown in below figure.

To build the ESQL_Simple message flow:
1. Make sure that the Selection button (at the top of the node palette) is highlighted so that you can select nodes from the node palette.
2. Click the MQInput node to select it from the node palette, then click
somewhere on the canvas (the white area to the right of the node palette) to start creating the message flow. The MQInput node is added to the canvas.
3. Add a Compute node and an MQOutput node to the message flow.
4. Rename each node as shown :

a. Right-click the MQInput node, then click Rename.... The Rename Node dialog opens.
b. Type ESQL_SIMPLE_IN then click OK (Figure Below). The node on the canvas is renamed to ESQL_SIMPLE_IN. ESQL_SIMPLE_IN is also the name of the queue from which the MQInput node will get messages. Using the same name for both the queue and the
node makes it easier for you to keep track of what queue to put the input
message on when you are testing the message flow.
c. Rename the Compute node and the MQOutput node.
5. Define the order in which the nodes process an input message by connecting them together as shown in Below:
a. Right-click the ESQL_SIMPLE_IN node, then click Create Connection.
The Select Terminal dialog opens.
b. In the Select Terminal dialog, click Out, then click OK. An arrow from the
ESQL_SIMPLE_IN node follows the mouse pointer when you move the mouse because you have not specified which node to connect to.

c. Click the Compute node. The arrow connects the ESQL_SIMPLE_IN node to the Compute node.
d. Connect the Out terminal of the Compute node to the ESQL_SIMPLE_OUT node. Ensure that you select the Out terminal on the Compute node and not, for example, Out1 or Out2.

Message sets

A message set is a definition of the structure of the messages that are processed by the message flows in the broker. As mentioned previously, in order for a message flow to be able to manipulate or transform a message, the broker must know the structure of the message. The definition of a message can be used to verify message structure, and to assist with the construction of message flows and mappings in the Message Brokers Toolkit.
Message sets are compiled for deployment to a broker as a message dictionary,which provides a reference for the message flows to verify the structure of messages as they flow through the broker.
Broker Application Development perspective
The Broker Application Development perspective is the part of the Message Brokers Toolkit that is used to design and develop message flows and message sets. It contains editors that create message flows, create transformation code such as ESQL, and define messages.
Runtime environment
The runtime environment is the set of components that are required to deploy and run message flow applications in the broker.
Broker
The broker is a set of application processes that host and run message flows. When a message arrives at the broker from a business application, the broker processes the message before passing it on to one or more other business applications. The broker routes, transforms, and manipulates messages according to the logic that is defined in their message flow applications. A broker uses WebSphere MQ as the transport mechanism both to communicate with the Configuration Manager, from which it receives configuration information, and to communicate with any other brokers to which it is associated. Each broker has a database in which it stores the information that it needs to process messages at run time.
Execution groups
Execution groups enable message flows within the broker to be grouped together. Each broker contains a default execution group. Additional execution groups can be created as long as they are given unique names within the broker.
Each execution group is a separate operating system process and, therefore, the contents of an execution group remain separate from the contents of other execution groups within the same broker. This can be useful for isolating pieces of information for security because the message flows execute in separate address spaces or as unique processes.
Message flow applications are deployed to a specific execution group. To enhance performance, the same message flows and message sets can be running in different execution groups.
Configuration Manager
The Configuration Manager is the interface between the Message Brokers Toolkit and the brokers in the broker domain. The Configuration Manager stores configuration details for the broker domain in an internal repository, providing a central store for resources in the broker domain.
The Configuration Manager is responsible for deploying message flow applications to the brokers. The Configuration Manager also reports back on the progress of the deployment and on the status of the broker. When the Message Brokers Toolkit connects to the Configuration Manager, the status of the brokers in the domain is derived from the configuration information stored in the Configuration Manager’s internal repository.

Broker domain

Brokers are grouped together in broker domains. The brokers in a single broker domain share a common configuration that is defined in the Configuration Manager. A broker domain contains one or more brokers and a single Configuration Manager. It can also contain a User Name Server. The components in a broker domain can exist on multiple machines and operating systems, and are connected together with WebSphere MQ channels. A broker belongs to only one broker domain.
User Name Server
A User Name Server is an optional component that is required only when publish/subscribe message flow applications are running, and where extra security is required for applications to be able to publish or subscribe to topics. The User Name Server provides authentication for topic-level security for users and groups that are performing publish/subscribe operations.
Broker Administration perspective
The Broker Administration perspective is the part of the Message Brokers Toolkit that is used for the administration of any broker domains that are defined to the Message Brokers Toolkit. This perspective is also used for the deployment of message flows and message sets to brokers in the defined broker domains. The Broker Administration perspective also contains tools for creating message broker archive (bar) files. Bar files are used to deploy message flow application resources such as message flows and message sets. The Broker Administration perspective also contains tools to help test message flows. These tools include Enqueue and Dequeue for putting and getting messages from WebSphere MQ queues.

WebSphere Transformation Extender - WTX

WTX Map node overview

The WTX Map node is a component of WebSphere TX for Message Broker, which is packaged with WebSphere TX for Integration Servers and is available for use in Message Broker message flows. It runs a WebSphere TX map within a message flow. The WTX Map node uses one or more Message Broker message trees as its input, runs a WebSphere TX map that you specify, and creates one or more Message Broker message trees as its output.

The map run by the WTX Map node can be either a compiled map that is pre-deployed to the broker, or a source map that is compiled when the message flow is added to a broker archive (BAR) file and deployed as part of broker archive deployment. The map can have multiple input cards, but the WTX Map node only has a single input terminal. The message arrives at the input terminal and then the proper pre-assigned input card picks up the message internally and maps it.

If the message tree that arrives at the input terminal consists of a single message, the input card that receives the message must be chosen. If the arriving message tree is a message collection containing multiple messages, then each message in the collection is delivered to the appropriate input card. Then the WTX Map node runs the map.

WebSphere TX comes from a different background and has different strengths compared to Message Broker. Its heritage is in processing large file structures, and it can provide complex data transformation capabilities for all structured and semi-structured data formats, including mixed types. Also, WebSphere TX is better suited to handling custom tagged message formats or mixed tagged and binary. Finally, it is well suited for large file structures. Together, WebSphere TX and Message Broker provide a combination unique in the marketplace for its breadth and depth.

Using the WTX Map node within a message flow

When you develop a message flow, you can set up a WTX Map node that runs a map that has a single input card or multiple input cards. The activities for using a WTX Map node within a message flow include:

•Creating a Map
•Developing a message flow that uses the WTX Map node
•Deploying the message flow
◦Creating and building a BAR file
◦Deploying the BAR file
◦If you are using a precompiled map, deploying the map
•Running your message flow
After the message flow is deployed, Message Broker starts the message flow automatically, and the following actions result:

•The message flow runs when an input node receives an input message bit stream.
•A parser parses the input bit stream into an input message tree.
•A WTX Map node receives the input message tree and runs the map.
•The map transforms the data in the input message tree and creates one or more output message trees.
•The output message trees can be processed by other nodes in the message flow.

Creating a map

Figure 1. WebSphere TX development perspective selection

Introduction to the Map Designer
Use the Map Designer through the WebSphere TX development perspective (shown below) to develop maps that define input and output specifications and mapping rules for data transformation:

The Map Designer uses the definitions of data stored in the type trees (created using the Type Designer) to specify the transformation logic in the form of map rules. Map rules operate on input data objects and build output data objects. The map can be built for specific platforms, and then run on that platform to perform data transformation.

Using the Map Designer

To use the Map Designer, you must already have the type trees that define your data. The Map Designer uses the data object definitions stored in those type trees. The Map Designer is used to:

•Create maps to specify the logic to transform the input data to the desired output data.
•Identify the source and data objects of the input data.
•Validate and resolve the source data type properties defined in the Type Designer.
•Identify the target and data objects of the output data.
•Specify and build the output data according to the map rules.
•Provide information about data validation by generating trace files.
•View the run results of the map execution.
Figure 2. Map Designer in Message Broker Toolkit.

Figure 3. Example map design of input card

Figure 4. Example map design of output card

After defining data objects and their properties in the Type Designer, you define a map in the Map Designer, where map cards specify the input source and the output target.

Developing a message flow using the WTX Map node

In a message flow, there are several different ways to use the WTX Map node:

With a source map and a single input
Develop a message flow with a WTX Map node specified with a source map that, at run time, is triggered to run by a single input.
With a precompiled map and a single input
Develop a message flow with a WTX Map node specified with a precompiled map that, at run time, is triggered to run by a single input.
With a source map and multiple inputs
Develop a message flow with a WTX Map node specified with a source map that, at run time, is triggered to run by multiple inputs.
With a precompiled map and multiple inputs
Develop a message flow with a WTX Map node specified with a precompiled map that, at run time, is triggered to run by multiple inputs.
Message flow development

Using the WTX Map node with a source map and a single input

The map can have many input cards, but only one nominated card receives data from the message flow, while each of the other cards pulls data directly from their adapter. The map can also have many output cards. Cards that are connected to the message flow propagate data to the flow, while each of the unconnected cards send data directly to their adapter. To develop a simple message flow that demonstrates this scenario, use the following steps. They assume that you used Map Designer to create a source map (.mms) file containing an executable map with one or more input cards, and one or more output cards.

1.Create a new message flow project in the Message Broker Application Development perspective.
2.Create a new message flow in the project: select Use default broker schema or provide your own schema name to qualify the message flow name.
3.Drag a WTX Map node from the palette onto the canvas for your message flow. The node initially has no output terminals, and one failure terminal. The WebSphere TX Drawer and WTX Map node palette are shown in Figure 5:
Figure 5. WTX Map node in Message Broker Toolkit

4.Navigate to the Properties view, shown in Figure 1 above.
5.On the Basic tab of the WTX Map node, select the source map.
6.On the Input tab of the WTX Map node, select the map card that receives the input. Important properties of the WTX Map node are shown in Figure 6:

Figure 6. Properties of WTX Map node

7.Drag an input node such as a FileInput node or an MQInput node to the left of the WTX Map node, and connect the out terminal of the input node to the in terminal of the WTX Map node. The message from the input node overrides the adapter of the map's selected input card.
8.Configure the input node with the necessary transport-related properties.
9.On the Input Message Parsing tab of the input node, configure the message template properties to describe the format of the input message. Select the domain from the list of supported message domains.
10.Drag an output node such as a FileOutput node or an MQOutput node to the right of the WTX Map node, and connect one of the output terminals of the WTX Map node to the in terminal of the output node. Connecting the output terminal overrides the adapter of the corresponding output card.
11.Configure the output node with the necessary transport-related properties.
12.On the Outputs tab of the WTX Map node, configure properties to describe the format of the output message propagated by the output card:
1.Click Add to add a set of properties. The Add Properties entry dialog opens.
2.Enter values for Card Number, Message Domain, Message Set, Message Type, Encoding, and Coded Char Set Id, and then click OK. Message Domain must be one of the supported message domains.
13.Repeat steps 10 through 12 for each output terminal that you want to connect.
14.Press Ctrl+S to save the message flow.
Using the WTX Map node with a precompiled map and a single input

The map can have many input cards. Only one nominated card receives data from the message flow, while each of the other cards pulls data directly from their adapter. The map can also have many output cards. Cards that are connected to the message flow propagate data to the flow, while each of the unconnected cards send data directly to their adapter. To develop a simple message flow that demonstrates this scenario, use the following steps. They assume that you used Map Designer to create a source map (.mms) file containing an executable map with one or more input cards and one or more output cards, and that you compiled the map for a target platform, creating a compiled map (.mmc) file.

1.Create a new message flow project in the Message Broker Application Development perspective.
2.Create a new message flow in the project. Select Use default broker schema, or provide your own schema name to qualify the message flow name.
3.Drag a WTX Map node from the palette onto the canvas for your message flow. The node initially has no output terminals and one failure terminal.
4.Navigate to the Properties view.
5.On the Basic tab of the WTX Map node, select the precompiled map.
6.On the Input tab of the WTX Map node, select the map card that receives the input.
7.Drag an input node, such as a FileInput node or an MQInput node, to the left of the WTX Map node, and connect the out terminal of the input node to the in terminal of the WTX Map node. The message from the input node overrides the adapter of the map's selected input card.
8.Configure the input node with the necessary transport-related properties.
9.On the Input Message Parsing tab of the input node, configure the message template properties to describe the format of the input message. Select the domain from the list of supported message domains.
10.Drag an output node, such as a FileOutput node or an MQOutput node, to the right of the WTX Map node, and connect one of the output terminals of the WTX Map node to the in terminal of the output node. Connecting the output terminal overrides the adapter of the corresponding output card.
11.Configure the output node with the necessary transport-related properties.
12.On the Outputs tab of the WTX Map node, configure properties to describe the format of the output message propagated by the output card:
1.Click Add to add a set of properties. The Add Properties entry dialog opens.
2.Enter values for Card Number, Message Domain, Message Set, Message Type, Encoding, and Coded Char Set Id, and then click OK. Message Domain must be one of the supported message domains.
13.Repeat steps 10 through 12 for each output terminal that you want to connect.
14.Press Ctrl+S to save the message flow. Figure 7 below shows one of the possible Message flows that takes single input:

Figure 7. Simple Message Flow with WTX Map node entertaining single Input.

Using the WTX Map node with a source map and multiple inputs

Develop a message flow with a WTX Map node specified with a source map, that at run time, is triggered to run by multiple inputs. The WTX Map node is used with a native Collector node, which gathers the multiple inputs and, when specified event criteria are satisfied, propagates the messages to the WTX Map node in the form of a message collection. For information about the Collector node and message collection.

The map can have many input cards. Any number of cards can receive data from the message collection, while any cards that do not receive data pull data directly from their adapter. The map can have many output cards. Cards that are connected to the message flow propagate data to the flow, while each of the unconnected cards sends data directly to their adapter. To develop a simple message flow that demonstrates this scenario, use the following steps. They assume that you used Map Designer to create a source map (.mms) file containing an executable map with two input cards, and one or more output cards.

1.Create a new message flow project in the Message Broker Application Development perspective.
2.Create a new message flow in the project. Select Use default broker schema, or provide your own schema name to qualify the message flow name.
3.Drag a WTX Map node from the palette onto the canvas for your message flow. The node initially has no output terminals and one failure terminal.
4.Navigate to the Properties view.
5.On the Basic tab of the WTX Map node, select the source map.
6.Drag a Collector node to the left of the WTX Map node.
7.Drag an input node, such as a FileInput node or an MQInput node, to the left of the Collector node.
8.Configure the input node with the necessary transport-related properties.
9.On the Input Message Parsing tab of the input node, configure the message template properties to describe the format of the input message. Select the domain from the list of supported message domains.
10.Right-click the Collector node and select Add Input Terminal. Enter the name of a new input terminal, which must match the card name of the input card in the map that receives the input message. The new input terminal is added to the Collection Definition table on the Basic tab. The broker's trace file lists any Collector input terminals that cannot be matched to input cards.
11.On the Basic tab, configure the required event criteria properties for the new input terminal, namely Quantity, Timeout, Correlation Path, and Correlation Pattern.
12.Connect the out terminal of the input node to the new input terminal on the Collector node.
13.Repeat steps 7 through 12 for each different input that the map requires from the message flow.
14.On the Basic tab of the Collector node, configure the Collection Name and Collection Expiry properties. In particular, specify a Collection Expiry value.
15.Connect the out terminal from the Collector node to the in terminal of the WTX Map node. Messages from the propagated message collection override the adapters of the map's input cards.
16.Connect the expiry terminal from the Collector node to the in terminal of the WTX Map node, to handle incomplete message collections.
17.Drag an output node, such as a FileOutput node or an MQOutput node, to the right of the WTX Map node, and connect one of the output terminals of the WTX Map node to the in terminal of the output node. Connecting the output terminal overrides the adapter of the corresponding output card.
18.Configure the output node with the necessary transport-related properties.
19.On the Outputs tab of the WTX Map node, configure properties to describe the format of the output message propagated by the output card:
1.Click Add to add a set of properties. The Add Properties entry dialog opens.
2.Enter values for Card Number, Message Domain, Message Set, Message Type, Encoding, and Coded Char Set Id, and click OK. Message Domain must be one of the supported message domains.
20.Repeat steps 17 through 19 for each output terminal that you want to connect.
21.Press Ctrl+S to save the code. An Unconnected catch terminals warning message appears, which you can ignore.
Using the WTX Map node with a precompiled map and multiple inputs

Develop a message flow with a WTX Map node specified with a precompiled map, that at run time, is triggered to run by multiple inputs. The WTX Map node is used with a native Collector node, which gathers the multiple inputs and, when specified event criteria are satisfied, propagates the messages to the WTX Map node in the form of a message collection. For information about the Collector node and message collection.

The map can have many input cards. Any number of cards can receive data from the message collection, while any cards that do not receive data pull data directly from their adapter. The map can have many output cards. Cards that are connected to the message flow propagate data to the flow, while each of the unconnected cards send data directly to their adapter. To develop a simple message flow that demonstrates this scenario, use the following steps. They assume that you used Map Designer to create a source map (.mms) file containing an executable map with one or more input cards and one or more output cards, and that you compiled the map for a target platform, creating a compiled map (.mmc) file.

1.Create a new message flow project in the Message Broker Application Development perspective.
2.Create a new message flow in the project. Select Use default broker schema or provide your own schema name to qualify the message flow name.
3.Drag a WTX Map node from the palette onto the canvas for your message flow. The node initially has no output terminals and one failure terminal.
4.Navigate to the Properties view.
5.On the Basic tab of the WTX Map node, select the precompiled map.
6.Drag a Collector node to the left of the WTX Map node.
7.Drag an input node, for example, a FileInput node or an MQInput node, to the left of the Collector node.
8.Configure the input node with the necessary transport-related properties.
9.On the Input Message Parsing tab of the input node, configure the message template properties to describe the format of the input message. Select the domain from the list of supported message domains.
10.Right-click the Collector node and select Add Input Terminal. Enter the name of a new input terminal, which must match the card name of the input card in the map that receives the input message. The new input terminal is added to the Collection Definition table on the Basic tab. The broker's trace file lists any Collector input terminals that cannot be matched to input cards.
11.On the Basic tab, configure the required event criteria properties for the new input terminal, namely Quantity, Timeout, Correlation Path, and Correlation Pattern.
12.Connect the out terminal of the input node to the new input terminal on the Collector node.
13.Repeat steps 7 through 12 for each different input the map requires from the message flow.
14.On the Basic tab of the Collector node, configure the Collection Name and Collection Expiry properties. In particular, you should specify a Collection Expiry value.
15.Connect the out terminal from the Collector node to the in terminal of the WTX Map node. Messages from the propagated message collection override the adapters of the map's input cards.
16.Connect the expiry terminal from the Collector node to the in terminal of the WTX Map node, to handle incomplete message collections.
17.Drag an output node, such as a FileOutput node or an MQOutput node, to the right of the WTX Map node, and connect one of the output terminals of the WTX Map node to the in terminal of the output node. Connecting the output terminal overrides the adapter of the corresponding output card.
18.Configure the output node with the necessary transport-related properties.
19.On the Outputs tab of the WTX Map node, configure properties to describe the format of the output message propagated by the output card:
1.Click Add to add a set of properties. The Add Properties entry dialog opens.
2.Enter values for Card Number, Message Domain, Message Set, Message Type, Encoding and Coded Char Set Id, and click OK. Message Domain must be one of the supported message domains.
20.Repeat steps 17 through 19 for each output terminal that you want to connect.
21.Press Ctrl+S to save the code. An Unconnected catch terminals warning message appears, which you can ignore. Figure 8 below shows one of the possible message flows that takes multiple input:

Deployment on Message Broker runtime

When you deploy message flows that contain WTX Map nodes, you must also deploy the associated WebSphere TX maps, and any files that the maps require. If the map is deployed to the broker in a map archive (MAR) file, you must make sure that any required files reside in the same project as the map, so they are automatically included in the MAR file. If the map is manually deployed to the broker, you must also manually deploy any required files to the broker. In particular, if your data is XML, and you have imported an XML Schema (.xsd file) when creating a type tree validated using Xerces, or have used an XML Schema directly when creating a map card, then the .xsd file is required by the map, and it must be deployed to Message Broker for use at run time in either of the following cases:

•If the data is being received from the message flow in the BLOB domain
•If the data is being received from a WebSphere TX adapter
At design time, you can specify the following map information on the WTX Map node. The two alternative map deployment mechanisms are described below:

•Using a source map with a WTX Map node
◦When Message Broker adds the message flow containing the WTX Map node to a BAR file, the specified executable map is compiled automatically to create a compiled map (.mmc) file.
◦The compiled map, and other files in the project, is zipped into a MAR file, which is added to the BAR file. The map is, therefore, automatically deployed to the broker when you deploy the message flow.
•Using a precompiled map with a WTX Map node
◦When Message Broker adds the message flow containing the WTX Map node to a BAR file, the map is not automatically compiled, and is not added to the BAR file.
◦You must manually deploy the map to the location that you specified.
At deployment time, you can specify the location of a compiled map by using the Configure tab in the Properties view, which is under the Manage tab in the Broker Archive editor. This setting overrides the map that you specified at design time.

At run time, your message flow can dynamically specify the location of a compiled map and pass it to the WTX Map node by using the Local Environment message tree. This setting takes precedence over any of the other methods.

Running the message flow

You can run the message flow by sending one or more messages through it. The message flow receives a message in an input node, which parses the message bit stream using the specified parser, creating a broker message tree. The resulting message tree is propagated down the flow. When a WTX Map node receives a propagated message tree, it runs the associated map and creates output messages.

If your map is expecting multiple inputs, use a Collector node to gather those inputs. In this case, you must send as many messages as are needed to complete the message collection defined by the Collector node. The body of a message tree, propagated from an output terminal of a WTX Map node, is owned by the message domain that you specified on the output terminal. Any headers present in the input message tree that the map received, such as MQMD, will be preserved unchanged in the propagated message tree. If the map received a message collection as its input, the propagated headers will be those of the first message in the collection. Headers from other messages in the collection are discarded. The Environment, Local Environment, and Exception List trees from the input message are also propagated unchanged.

If a failure occurs when running a map, the failure is added to the Exception List, and the input message, Environment, Local Environment, and Exception List are propagated from the failure terminal, if connected. Otherwise, an exception is thrown. When the message tree reaches an output node, it is serialized into a bit stream by the owning parser.

Websphere Message Broker - Toolkit

Websphere Message Broker Built In Nodes

1.AggregateControl node
2.AggregateReply node
3.AggregateRequest node
4.Check node
5.Collector node
6.Compute node
7.Database node
8.DatabaseRetrieve node
9.DatabaseRoute node
10.DataDelete node
11.DataInsert node
12.DataUpdate node
13.EmailOutput node
14.EndpointLookup node
15.Extract node
16.FileInput node
17.FileOutput node
18.Filter node
19.FlowOrder node
20.HttpInput node
21.HttpReply node
22.HttpRequest node
23.Input node
24.Java Compute node
25.JMSInput node
26.JMSMQTransform node
27.JMSOutput node
28.JMSReply node
29.Label node
30.Mapping node
31.MQeInput node
32.MQeOutput node
33.MQGet node
34.MQInput node
35.MQJMSTransform node
36.MQOptimizedFlow node
37.MQOutput node
38.MQReply node
39.Output node
40.Passthrough node
41.PeopleSoftInput node
42.PeopleSoftRequest node
43.Publication node
44.Real-timeInput node
45.Real-timeOptimizedFlow node
46.RegistryLookup node
47.ResetContentDescriptor node
48.Route node
49.RouteToLabel node
50.SAPInput node
51.SAPRequest node
52.SCADAInput node
53.SCADAOutput node
54.SiebelInput node
55.SiebelRequest node
56.SOAPAsyncRequest node
57.SOAPAsyncResponse node
58.SOAPEnvelope node
59.SOAPExtract node
60.SOAPInput node
61.SOAPReply node
62.SOAPRequest node
63.Throw node
64.TimeoutControl node
65.TimeoutNotification node
66.Trace node
67.TryCatch node
68.TwineballInput node
69.TwineballRequest node
70.Validate node
71.Warehouse node
72.XSLTransform node
#########################################################

New Web services nodes :

•Provider nodes (SOAPInput, SOAPReply)
•Consumer nodes (SOAPRequest, SOAPAsyncRequest, SOAPAsyncResponse)
•Helper nodes (SOAPExtract, SOAPEnvelope)

WebSphere Service Registry and Repository :

•EndpointLookup
•RegistryLookup

Routing :

•DatabaseRetrieve -- to ensure that information in the message is up-to-date.
•DatabaseRoute and Route -- to direct messages down different paths of a message flow based on certain criteria.
•Collector -- to create a message collection from one or more sources based on configurable criteria.

WebSphere Adapter nodes :

•PeopleSoftInput
•PeopleSoftRequest
•SAPInput
•SAPRequest
•SiebelInput
•SiebelRequest

File nodes :

•FileInput
•FileOutput

Transport nodes

•JMSReply
•EmailOutput

=====================================================
Use the Check node to compare the structure of a message arriving on its input terminal with a message structure definition that you supply when you configure the Check node.

Use the Filter node to route a message according to message content.

A Compute node takes as input a message tree (called InputRoot) and outputs a different message tree (called OutputRoot). Notice that InputRoot is read-only and therefore cannot be modified in place.

HTTPin & HTTPout nodes allow the CGI world to talk to "c" programs.

SOAPin & SOAPreply nodes allow to talk to the WebServices world

Trace node : where to send its output ( diferent at Development and Production ). When the BAR file is generated, select the "Configure" bottom flap and enter the "File Path" property. If empty, does it mean "no trace" ?

Other nodes :

•SendMailPlugIn - support pack IA07.
A xml tag with the error message is added to the original message.
•z/OS File Adapter - support pack IA11.
MQ Output node + "Advanced" settings :
Select the Destination Mode from the drop-down list. This identifies the queues to which the output message is put.

•Queue Name. The message is sent to the queue named in the Queue Name property. The properties Queue Manager Name and Queue Name (on the Basic tab) are mandatory if you select this option. This is the default.
•Reply To Queue. The message is sent to the queue named in the ReplyToQ field in the MQMD.
•Destination List. The message is sent to the list of queues named in the LocalEnvironment (also known as DestinationList) associated with the message.

Providing input to a message flow
The type of input node that is used in a message flow depends on the type of application that sent the message to the broker:

•If the message flow gets the messages from the business application by means of a WebSphere MQ queue, use an MQInput node.
•If the messages are sent to broker by an MQe application, use an MQeInput node.
•If the messages are sent by a telemetry device, use a SCADAInput node.
•If the messages are sent by a Web services client, use an HTTPInput node.
•If the messages are sent by a JMS or multicast application, use a Real-timeInput node or a Real-timeOptimizedFlow node.
•If the message flow is to be reused as part of one or more other message flows, use an Input node.
•MQInput
•JMSInput
•HTTPInput
•SOAPInput
•SAPInput
•Timer node
MQInput Node Properties.

•Message Domain
•Message Set
•Message Type
•Message Format
•Topic
Each input node in a message flow causes the broker to start a separate thread of execution. Including more than one input node might improve the message flow performance.
Message Domain types
In Message Domain, select the name of the parser that you are using from the drop-down list.

•MRM
•XML
•XMLNS
•XMLNSC
•JMSMap
•JMSStream
•MIME
•BLOB (same as blank)
•IDOC
Body is equivalent to Root followed by the parser name (for example, Root.XML), which you can use if you prefer.


----------------------------------------------------

Websphere Message Broker

IBM WebSphere Message Broker enables you to connect a wide range of applications using different interaction patterns, protocols, and message formats.

Supported interaction patterns include:

•One-way messaging
•Request/response
•Aggregation
•Publish/subscribe (pub/sub)

Message Broker supports the following protocols:

•WebSphere MQ
•HTTP
•Java™ Messaging Service(JMS)
•Real-time and multicast
•File
•User-defined

Message Broker enables you to model and transform a comprehensive set of message formats:

•Record-based (COBOL, C)
•Industry standard string-based (SWIFT, TLOG, EDIFACT)
•XML, including all schema artifacts
•User-defined
Messages that pass through Message Broker are potentially routed and transformed between different formats on the way to their destination. Message Broker provides a range of technologies for transforming messages, which can be used in accordance with the skill set of the integration developer:

•ESQL for users with relational database skills who prefer declarative rather than algorithmic forms to specify message transformation
•Java for programmers skilled in Java
•Graphical mapping for straightforward transformations that do not require programming
•XSLT for XML-based transformations based on an open standard

WebSphere Message Broker technical overview

WebSphere Message Broker enables information packaged as messages to flow between different business applications, ranging from large traditional systems through to unmanned devices such as sensors on pipelines.




Start Quick Tour Click on hyperlink

Our interactions with WebSphere Message Broker can be considered in two broad categories:

•

Application development, test, and deployment. You can use one or more of the supplied options to program your applications:

◦Patterns provide reusable solutions that encapsulates a tested approach to solving a common architecture, design, or deployment task in a particular context. You can use them unchanged or modify them to suit your own requirements.
◦Message flows describe your application connectivity logic, which defines the exact path that your data takes in the broker, and therefore the processing that is applied to it by the message nodes in that flow.
◦Message nodes encapsulate required integration logic, which operates on your data when it is processed through your broker.
◦Message trees describe data in an efficient, format independent way. You can examine and modify the contents of message trees in many of the nodes that are provided, and you can supply additional nodes to your own design.
◦You can implement transformations by using graphical mapping, Java™, PHP, ESQL, and XSL, and can make your choice based on the skills of your workforce without having to provide retraining.

•Operational management and performance.

◦An extensive range of administration and systems management options are available for developed solutions.
◦A wide range of operating system and hardware platforms are supported.
◦A scalable, highly performing architecture, based on requirements from traditional transaction processing environments.
◦Tightly integrated with software products, from IBM and other vendors, that provide related management and connectivity services.
WebSphere Message Broker is available in several modes, so that you can purchase a solution that meets your requirements.

Message Broker Explorer

DataPower B2B Appliance XB60

The IBM WebSphere DataPower B2B Appliance XB60 is a unique B2B appliance that delivers secure trading partner data integration tracking, routing, and security functions in a network device, while reducing operational costs and improving performance. The XB60 is a nondisruptive technology that allows organizations to extend their existing B2B implementations and internal integration infrastructure, thus delivering rapid return on investment and reduced total cost of ownership. Key features of the XB60 are as follows

WebSphere DataPower B2B Appliance XB60 benefits

Simplified deployment and ongoing management
Reduces need for in-house skills that are typically needed to deploy and manage a B2B solution. The XB60 is a hardened drop-in B2B appliance that is suitable for DMZ deployments. The XB60 uses dedicated, tightly optimized hardware and firmware, and has no software to install.
High security assurance Higher levels of security assurance certification available only with hardware, including Common Criteria Evaluation Assurance Level 4+ certification. Exceptional data security
and certificate management built into the appliance. Robust Authentication, Authorization, and Auditing (AAA) capabilities with built-in integration to external repositories.
High reliability and assured deliverySwappable redundant components, whole-box VRRP-style failover, RAID 1 for HDD
options, automated B2B data resends when using industry standard EDIINT protocols.
Manual B2B resends that can be initiated by your trading partners.
Auditability/monitoringRobust logging and support for saving logs to a large variety of log targets utilizing a broad
range of log formats. Real-time transaction monitoring of B2B transactions utilizing a
simple to use B2B Transaction Viewer, which can be configured to allow trading partners
to view their own transactions.
FlexibilitySupport for a wide range of protocols to allow flexibility to connect to as many trading
partners as possible. Many back-side protocols are supported to provide more options for integrating to back-end applications. Supported connection protocols include http(s),ftp(s), sftp, POP3, SMTP, MQ, JMS, AS1, AS2, AS3, NFS, IMS™ Connect, TIBCO EMS,
and ODBC (DB2®, Oracle, MS SQL).
Low total cost of ownershipDedicated B2B appliances have been shown to reduce deployment and operational costs
by as much as 50%. Dramatically decreases the testing time and amount of development
required to upgrade your environment; most policies are configuration-driven as opposed to development-driven.

Architecture of the WebSphere DataPower B2B Appliance

The XB60 builds on top of the DataPower Application Integration appliance by adding trading
partner profile management, B2B transaction viewing capabilities, and industry standards-based B2B messaging protocols to the already robust integration capabilities of the core appliance. These three key capabilities are at the heart of the B2B Appliance. They are designed in such a way that the B2B Appliance is positioned extremely well to handle simple partner connections with data passing through directly to end applications for further processing. If more complex data flows are required, the application integration capabilities of the XB60 can be used to perform data validation, transformation, rules-based enforcement, and content-based routing.
B2B Gateway ServiceThe B2B Gateway Service is a configuration object that is responsible for processing and routing B2B data.
Partner profilesPartner profiles are configuration objects that are capable of supporting multiple destinations; the profiles are associated with any number of B2B Gateway Services.
B2B Transaction ViewerThe B2B Transaction Viewer is used to view all transactions that pass through a B2B Gateway Service.
The components that make up the B2B functionality in the XB60 are depicted in Figure 1

MQ File Transfer

IBM WebSphere MQ File Transfer Edition provides a reliable, managed file transfer solution for moving files—regardless of size—between IT systems. It enables files and documents to be transferred across a dual-purpose backbone that also handles messages.

Key features of WebSphere MQ File Transfer Edition are as follows:

> Provides reliable managed file transfer (MFT) using WebSphere MQ
> Enables consolidation of messaging and file transfers into single backbone
> Provides bulk transfer of files, regardless of size
> Records log of transfer activity for audit purposes to queues and external databases
> Automates and controls file movement between IT systems with scheduling, triggering, and directory monitoring
> Extends MQ Explorer graphical interface for remotely configuring transfers and monitoring progress
> Provides command line interface for programmatic control of transfers
> Provides scripting interface for XML definition of transfers using Apache Ant
WebSphere MQ File Transfer Edition provides an enterprise-ready managed file transfer
capability that is both robust and easy to use. WebSphere MQ File Transfer Edition exploits
the proven reliability and connectivity of WebSphere MQ to transfer files across a wide range
of platforms and networks. In addition to leveraging existing WebSphere MQ networks,
WebSphere MQ File Transfer Edition can be easily integrated with existing file transfer
systems, as illustrated in Figure 2.

WebSphere MQ File Transfer Edition benefits
The benefits provided by WebSphere MQ File Transfer Edition are described in this section.
AuditabilityWebSphere MQ File Transfer Edition provides full logging of transfers at both the source
and destination systems. File transfer audit logs are stored in WebSphere MQ queues and optionally in a relational database (SQL).
Ease-of-useUsing WebSphere MQ File Transfer Edition, file transfers can be initiated using the graphical user interface in WebSphere MQ Explorer, via command-line commands, and using scripts.
SimplicityWebSphere MQ File Transfer Edition has a low resource footprint, and apart from WebSphere MQ, has no other pre-requisite software.
SecurityAccess to files is controlled by file system permissions. File transfers can be protected using SSL encryption and authentication.
AutomationFile transfers can be set up to occur at specified times or dates, or repeated at specified intervals. File transfers can also be triggered by a range of system events, such as new files or updated files.

Architecture of WebSphere MQ File Transfer Edition

WebSphere MQ File Transfer Edition comprises four components, all supported by one or
more WebSphere MQ queue managers in the network. These components are:
AgentsFTE Agents are programs that perform the fundamental file transfer function; for example, they send and receive files from the local system.
Configuration commandsThese are commands that are used to control FTE from a command line. Configuration commands perform tasks such as creating and deleting agents.
Administration commandsAdministration commands perform tasks such as creating new file transfers.
Graphical user interfaceThis is a point-and-click interface used to configure and administer FTE.
The components of WebSphere MQ File Transfer Edition use WebSphere MQ to
communicate with each other, and the Agents in particular use WebSphere MQ to transport
the contents of files across the network to other Agents (Figure 3).

Sample deployment scenarios

In this section we outline a common business scenario for multi-enterprise file transfers. The
deployment scenario can support the use of any transport and B2B protocol that the
DataPower B2B Appliance XB60 has available; however, for the purpose of the two trading scenarios demonstrated in this guide (Inbound and Outbound) we are utilizing the most predominate B2B Messaging protocol: AS2. This allows us to demonstrate how the XB60 can use profile management to verify and validate the trading partners, B2B messaging to protect the payload data that is transferred between you and your partners, and provide non-repudiation of origin and receipt for the public side of the connection (Assured Delivery).
It also demonstrates how the XB60 integrates with WebSphere MQ File Transfer Edition to facilitate an intra-enterprise file transfer to any location inside your enterprise.

Scenario #1: File transfer inbound from an AS2 trading partner

In this scenario, illustrated in Figure 4, the trading partner sends an AS2 message containing
the secured payload to the HubOwner’s B2B Gateway (XB60). The file is then routed to a file system shared between the XB60 and AGENT01 and an XML command file is sent from the XB60 to MQ FTE instructing MQ FTE to pick up the file and send it to AGENT02.

1. The trading partner sends an AS2 document into the B2B Gateway over any supported
protocol. The B2B Gateway Service will use profile management to verify/validate the
partner. If a supported B2B Messaging protocol (AS1, AS2, AS3) is used, the B2B
Gateway Service ensures that the message adheres to the B2B standard, that data
security is appropriately applied, and then removes the B2B protocol packaging.
2. The payload is routed into a Multi-protocol Gateway Service, where we use a
Multi-protocol Gateway policy to facilitate integration to WebSphere MQ File Transfer
Edition.
3. The Multi-Protocol Gateway policy sends the payload to an NFS mount point that is
shared between the XB60 and MQFTE AGENT01.
4. The Multi-protocol Gateway policy sends an MQ FTE Command XML file to the MQ FTE
Command Queue; this file triggers the MQFTE transfer and tells AGENT01 where to find
the file on the file system and where to send it to over the MQ Network.
5. a: If using a B2B Messaging protocol, once the file has been written to the NFS mount
point and the XML command file has been delivered to the queue, the B2B Gateway
Service will generate a Message Disposition Notification (MDN) advising the successful
transfer of the file and send that MDN back to the trading partner.
b: AGENT01 will consume the XML command file and route the payload to the receiving
agent; AGENT02. AGENT02 will then write the file to the destination directory.
6. The back-end application will consume the payload that MQ FTE has transferred.

Scenario #2: File transfer outbound to an AS2 trading partner

In this scenario, shown in Figure 5, the HubOwner is the originator of the file. The back-end application places the file on the file system where AGENT02 can pick up the file when instructed to do so via the mechanisms available in MQFTE. AGENT02 sends the file over the WAN to AGENT01, which writes the file to a file location shared between AGENT01 and the XB60. The XB60 polls the directory on a scheduled polling cycle and picks up the file for processing. It parses the file for sender and receiver information and routes the file securely to the receiving trading partner based on information in the partner profile.

1. The back-end application sends a file to a directory shared by AGENT02 and the file is routed to AGENT01.
2. AGENT02 sends the file across the WAN to AGENT01, which writes the file to an NFS
mount point that is shared between the XB60 and MQ FTE.
3. The B2B Gateway Service picks up the file from the shared NFS mount point, parses the file for sender and receiver information, and wraps the payload in an AS2 envelope using the attributes set up in the recipient’s Trading Partner Profile.
4. The B2B Gateway Service sends the file to the trading partner using the AS2 B2B Messaging Protocol.
5. The Trading Partner receives the AS2 message, processes it, and sends back an MDN to the XB60.

Creating MQ Objects:Queue Managers and Queues

A queue is a place to store messages until applications process them. A queue manager owns and manages queues. To create a queue manager and the queues needed for this article, start WebSphere MQ Explorer as follows: Start → All Programs → IBM WebSphere MQ → WebSphere MQ Explorer.
Figure 1 shows how WebSphere MQ Explorer looks when you start it.

Complete the following steps to create a queue manager with MQ Explorer:

1.In the Navigator view, right-click Queue Managers and then click New → Queue Manage. This starts the "Create Queue Manager" wizard.
2.On Step 1, enter "TestQM" as the queue manager name and click Next (see Figure 2).


3.Click Next on the wizard screens for Steps 2 and 3. At Step 4, make sure "Create listener configured for TCP/IP" is checked and the entered port number is free (see Figure 3), and then click Finish.

MQ -- Message Queuing

Creating a queue manager using the WebSphere MQ Explorer

1.Start the WebSphere® MQ Explorer from the Start menu.
2.In the Navigator View, expand the tree nodes to find the Queue Managers tree node.
3.Right-click the Queue Managers tree node, and select New->Queue Manager. The Create Queue Manager panel is displayed.
4.Complete the dialog (Step 1), then click Next>.
5.Complete the dialog (Step 2), then click Next>.
6.Complete the dialog (Step 3), ensuring that Start Queue Manager and Create Server Connection Channel are not selected, then click Next>.
7.Complete the dialog (Step 4), then click Finish.

Configuring WebSphere MQ with the WebSphere MQ Explorer

1.Before We use the WebSphere MQ applications, We must create a queue manager. The queue manager is a system program that is responsible for maintaining the queues and ensuring that the messages in the queues reach their destination. It also performs other functions associated with message queuing.

=>A queue is a named destination that applications use to PUT and GET messages. A queue name must be unique within a queue manager. Special queue types can be defined, such as transmission queues and dead letter queues.

=>A transmission queue is a queue that holds messages that will eventually be sent to a remote queue when a communication channel becomes available. Unless otherwise specified, these messages will be transmitted through the default transmission queue.

=>A dead letter queue is a local queue where messages that cannot be delivered are sent, either by the queue manager or an application. Some method should be in place in production environments to monitor and process messages in this queue.

1.From the WebSphere MQ Explorer window, expand the WebSphere MQ label, then right-click Queue Managers. Select New Queue Manager from the pop-up menu.

2.Enter the name for your queue manager. The name MYQMGR will be used in the following example. All names in WebSphere MQ are case sensitive. Using all capital letters for names helps avoid confusion. The names in the example are suggestions. You can use different names if you choose. Fill in names for the default transmission queue and dead letter queue. Check the box to make this your default queue manager.

Click Next to continue.
3.The next screen indicates the type of logging that the queue manager will perform, and the maximum number of log files that can be produced

Click Next to accept the suggested values and continue.
4.Verify that Start Queue Manager is checked.

Click Next to continue.

5.The following step enables the WebSphere MQ applications that are running on your machine to communicate with other machines. Make sure that Create listener configured for TCP/IP is selected, and enter 1414 for the port number. This is the default port number for WebSphere MQ. Check with your system administrator to verify that this is the correct port to use.

Click Finish to create your queue manager. It might take a minute to create and start the queue manager.

2.Create one or more local queues for exchanging messages on your queue manager. These are the queues that SAS applications will use to exchange messages with other applications. In the tree, find your newly created queue manager and click "+" to expand the menu. Right-click Queues, then select New Local Queue from the popup menu.

In the Queue Name field, enter the name of the local queue that you want to create. This queue name is specified in any application programs that use WebSphere MQ. On this screen, you might want to change the Default Persistence value from Not Persistent to Persistent. This enables messages to remain in the queue even if the queue manager is shut down. Click the various tabs to see the types of values that can be defined.


If you will be using high-volume messaging applications like scoring, you might want to change another default value. Click the Extended tab and increase the Maximum Queue Depth to 100,000 or more. This value represents the maximum number of messages that a queue can hold.


You can also change the properties after the queue has been defined. Click OK to create the queue. Repeat the process for any additional local queues that you want to create
Configuration Required for WebSphere MQ Client Access
IBM also provides a lighter client version of WebSphere MQ that can be installed and used separately from the full WebSphere MQ Base or server installation. The client can be installed on the same machine as the server, or on a separate machine. The client does not have its own queue manager, and must communicate over the network or within a machine to a queue manager that is defined elsewhere.

There are two requirements that must be completed before you can configure the client/server communication.

First, you must define a server connection channel on the queue manager that will provide support to the client. A channel is a definition that enables intercommunication between queue managers, or between clients and queue managers.

To define a server connection channel from the WebSphere MQ Explorer, click MYQMGR Advanced to expand the list. Right-click Channels, select NEW Server Connection Channel and enter the channel name (for example, SERVER.CHANNEL1).

MQ -- Messaging & Queuing

Message queuing is a method of program-to-program communication. Programs within an application communicate by
writing and retrieving application-specific data ( message) to/from queues, without having a private, dedicated, logical
connection to link them.

Messaging means that programs communicate with each other by sending data in messages and not by calling each other directly.

Queuing means that programs communicate through queues. Programs communicating through queues need not be executed concurrently.

Message Types

MQSeries knows four types of messages:
Datagram: A message containing information for which no response is expected.
Request: A message for which a reply is requested.
Reply: A reply to a request message.
Report: A message that describes an event such as the occurrence of an error or a confirmation on arrival or delivery.

Websphere ESB