Introduction

With the release of IBM® WebSphere® Message Broker V6.1 (hereafter called Message Broker), options for message routing and transformation have expanded. The new Route, DatabaseRoute, and DatabaseRetrieve nodes enable message flow developers to quickly manipulate messages using XPath expressions inside the message flow. All three nodes are non-programming nodes, which means that they can be used in a message flow and made available for use without the need to write any processing code such as ESQL or Java. The three nodes work within the common message model in Message Broker, and all of them can be used within the same message flow if required, as illustrated in the Simplified Database Routing sample in the Samples Gallery in the Message Broker Toolkit. This article describes the capabilities and limitations of each node and their typical usage patterns. To configure and use these new nodes, you need only a basic understanding of SQL and XPath.

1. Multi-language node property fields

Message Broker V6.0 supported and maintained ESQL and Java as its two message processing transformation languages. Now Message Broker V6.1 supports the entry of expressions in a choice of processing languages, from within node property fields. Message Broker V6.1 introduces the provision for flow developers to have the choice to enter either ESQL and or XPath expressions within such fields. That is, new nodes in Message Broker are capable of accepting expressions used in the routing decisions applied by nodes or used as part of their message transformation processing activities.

These expressions are now gathered as property values, collected through new multi-language node property fields. These fields have been configured, at the time they where designed and constructed, to accept either single or multiple message processing languages. Typically this means they can accept either ESQL only expressions, XPath only expressions or both (multi-language support). In the latter case there is a desire to ensure flow developers have the ability to represent an expression in either language, where its semantic and therefore the nodes behaviour is capable of being preserved regardless of which grammar is used by the flow developer.

With this in mind, new preference settings within the toolkit have been made available. These permit grammar restrictions to be enforced across all such multi-language fields. When restrictions are applied, all valid expressions entered thereafter can be represented in either language. To make this possible restrictions are applied to both grammars, which are enforced during property validation. Compliant expressions in either language then facilitate the smooth migration to the other language which may also be supported by the field.

The Message Broker Toolkit provides an option -- Use XPath and ESQL equivalent grammar - to restrict XPath grammar in order to limit XPath users to equivalent ESQL expression support. In order to support expression migration in both directions between languages, restricted grammar mode also subtly restricts the ESQL grammar to fit XPath. See Selecting the grammar mode.

By default, users will operate in restricted grammar mode thus supporting migration. In this mode field values are restricted to a subset of the grammar appropriate for input in a specific field. However, if this is too restrictive for the message flow developer, then they can uncheck this preference setting to allow unrestricted grammar appropriate for input in a specific field type. Expressions are still validated for syntax appropriate in the context of the field type, but can be in the full range of grammar as supported by the runtime.

The XPath language maps (through language restrictions) to the following basic ESQL functionality:

1. Path location -- Returns an element or null if it doesn't exist in a non-modifiable tree.
2. Path location -- Creates all ancestors on the navigation path to a target element if they don't exist and returns the target element for a modifiable tree.
3. Expression -- Only examines tree content (element values) returning the result of the expression.

Therefore the types of property editors present in the Message Broker Toolkit, to support the multi-language fields now used in new primitive nodes introduced in Message Broker, are categorized as follows:

1. Category (a) path location field, which has the following new property field support in the tooling:
1. Fixed -- ESQL read-only path (field reference) field property.
2. Fixed -- XPath read-only path (path location) field property.
3. Mixed -- ESQL or XPath read-only path location field property.
2. Category (b) path location field, which has the following new property field support in the tooling:
1. Fixed -- ESQL read-write path (field reference) field property.
2. Fixed -- XPath read-write path (path location) field property.
3. Mixed -- ESQL or XPath read-write path location field property.
3. Category (c) expression field, which has the following new property field support in the tooling:
1. Fixed -- XPath expression field property.

2. Route node

This section describes the Route node and its capabilities and usage patterns.

Dynamic terminals -- The Route node can have further dynamic output terminals. Not all dynamic output terminals that are created on a Route node need to be mapped to an expression in the filter table. For unmapped dynamic output terminals, messages are never propagated to them. Several expressions can map to the same single dynamic output terminal. No static output terminal exists to which the message is passed straight through.

2.1. Multi-language node properties

The following table outlines the multi-language property fields supported by the Route node. Specifically where they exist within the property viewer, the type of multi- language fields provided and the name of defined variable references supported in XPath expressions, which may be entered in the field properties concerned.

2.2. Node capabilities

You can use the Route node to dynamically route one or more copies of a given message down different legs of a message flow based on user provided expressions which are applied to incoming message content. Each expression is associated with a specific dynamic output terminal.

1. You can use the Route node to check that the inbound message meets some criterion. For example, that a required field is set. If the criterion is not met you can raise an exception using the Throw node.
2. The Route node lets different messages take different paths. For example, a message might need forwarding to different service providers based on the request details.
3. You can use the Route node to bypass unnecessary steps. You can test if certain data is in a message, and only perform say a database retrieve operation if the data is missing.
4. When used in combination with a DatabaseRetrieve node, the Route node can direct messages based on the contents of an independently administered lookup table. For example, you could route a message based on customer status even if the inbound message contained only the customer identifier.
5. By configuring this node to propagate messages to all matching terminals, you can trigger multiple events each requiring different conditions. For example, you could log requests relating to a particular account identifier and send requests relating to a particular product to be audited.

Typically this node allows the incoming message to be routed based on its content, where XPath is used as the expression language to query the content (message processing routing language).

Of course it can be argued that constructing query expressions using XPath is in fact programming, but the intention is that an XPath expression is significantly simpler than an ESQL, Java or the mapping programming environment and allows users to control processing using simple expressions which may reference values acquired from trees present in the incoming message assembly for this node.

The XPath query syntax is described in the W3C recommendation at: http://www.w3.org/TR/xpath.

As detailed in this node’s description, provided in the product information center, this node has a mandatory filter table property which must contain at least one row representing a routing decision. Each row specifies a user defined routing expression and a dynamic terminal to propagate the node’s incoming message assembly to (if on evaluation of the expression its result when cast as a Boolean resolves to true).

When the node’s Distribution Mode property is set to All, each and every row in the table is guaranteed to be processed synchronously, in the order given. A copy of the node’s input message assembly is propagated down each row’s user defined dynamic output terminal, where it’s routing expressions resolves to true. Otherwise the node’s input message assembly is propagated down the static output terminal named Default.

When the node’s Distribution Mode property is set to First, each row in the table is processed synchronously, in the order given, until a routing decision is met. For routing expressions resolving to true, a copy of the node’s input message assembly is propagated down the row’s user defined dynamic output terminal. Otherwise the node’s input message assembly is propagated down the static output terminal named Default.

Next we will look at three usage patterns for the Route node.

2.3. Usage scenario (replacement for FlowOrder node)

You can configure the route node to operate and act as a FlowOrder node.

As described above, the Route node evaluates an expression, the result of which is then cast as a Boolean to produce a true or false test condition. Only if the final result is true does the node propagate the message to the expression's matching output terminal. By setting the distribution mode to All and entering two or more routing decisions that always resolve to true, this node offers equivalent behaviour to that of the FlowOrder node.

The FlowOrder node always propagates the message tree to each of its terminals (provided they are connected). The main differences between the Route and FlowOrder nodes is the number of output terminals supporting synchronous branch execution and possibly performance.

1. Number of Output Terminals -- The FlowOrder node is limited to two fixed static output terminals, providing only two branches to synchronously order downstream flow activities through. The Route node has an unlimited number of dynamic output terminals through which flow processing activities may be executed.
2. Performance -- In the case where you wish to sequence processing down only two branches at a specific point within a flow, then the FlowOrder node may be marginally faster. However, if you wish to sequence down say four branches then this would require three FlowOrder nodes chained together and it’s highly likely that in this situation using the Route node will prove more efficient in terms of performance.

We will now look at an example of how the Route node can be used instead of multiple FlowOrder nodes. The setting for example is the the sequential processing of order items for a new customer of a furniture company. Consider Figure 2, which illustrates the message flow when the FlowOrder node is used.

Three FlowOrder nodes have been chained together in order to provide four branches of execution within the flow, to guarantee that four separate activities within the company’s purchasing process for a new customer are performed in the correct order. The sequence is:

1. Create a new customer record in the customer table within the company’s database.
1. FlowOrder (output terminal: First) => CreateNewCustomer (DataInsert node, input terminal: In)
2. FlowOrder (output terminal: Second) => FlowOrder1 (input terminal: In)
2. Raise a new furniture order, by creating a new order record in the order table within the company’s database.
1. FlowOrder1 (output terminal: First) => CreateFurnitureOrder (DataInsert node, input terminal: In)
2. FlowOrder1 (output terminal: Second) => FlowOrder2 (input terminal: In)
3. Update the customer record in the customer table, within the company’s database, with their payment method and details.
1. FlowOrder2 (output terminal: First) => UpdateCustomerPaymentDetails (DataUpdate node, input terminal: In)
2. FlowOrder2 (output terminal: Second) => DespatchOrder (MQOutput node, input terminal: In). Dispatch the order to the company’s order processing department’s work flow.

To perform an identical customer ordering process to the above, replacing the FlowOrder node with the Route node, consider the message flow in Figure 3:

This results in a much simpler message flow structure. Using a single Route node, the sequence is:

1. Create a new customer record in the customer table within the company’s database.
1. Route (dynamic output terminal: Match1) => CreateNewCustomer (DataInsert node, input terminal: In)
2. Raise a new furniture order, by creating a new order record in the order table within the company’s database.
1. Route (dynamic output terminal: Match2) => CreateFurnitureOrder (DataInsert node, input terminal: In)
3. Update the customer record in the customer table, within the company’s database, with their payment method and details.
1. Route (dynamic output terminal: Match3) => UpdateCustomerPaymentDetails (DataUpdate node, input terminal: In)
4. Dispatch the order to the company’s order processing department’s work flow.
1. Route (dynamic output terminal: Match4) => DespatchOrder (MQOutput node, input terminal: In).

In order to configure the Route node to mimic the behaviour of the FlowOrder node the routing expressions being evaluated must always resolve to true. Rather than using the built in XPath function true(), it is more efficient to simply enter the numeric value 1. As all expressions are cast as a Boolean and so '1' would return true. To mimic a four branch FlowOrder node, the filter table for the Route node in the previous flow (Figure 3) would be as depicted in Figure 4:

2.4. Usage scenario (routing regardless of message body parser)

You can configure the Route node to direct the incoming message assembly down a given path in a flow if a specific named element in the message tree exists, regardless of the parser in use for the message tree body. For example consider the Route node filter table outlined below in Figure 5:

From the settings above, we can see that the Route node will only propagate one copy of the incoming message assembly down the Match1 dynamic output terminal on the first occurrence of any of the routing decisions resolving to true. In this scenario we are looking for the occurrence of a field named FirstName, forming part of a customer’s details, being present in the body of the incoming message tree. Here we cater for the situation where the message domain may be either MRM or XMLNSC. If the message body is owned by the XMLNSC parser then we expect to find this field under an outer top level tag called - CustomerDetails. However if the message body is owned by the MRM parser, then we wouldn't expect to find this field under this outer tag, as this parser removes outer tags.

2.5. Usage scenario (complex routing expressions)

Routing decisions entered in the Route node’s filter table as filter patterns may be any well formed category (c) XPath general expression. As a result, decision logic may be sophisticated. For example consider the Route node filter table outlined below in Figure 6:

From the settings above, we can see that the Route node will only propagate one copy of the incoming message assembly down the Match1 dynamic output terminal if the single routing decision resolves to true.

In this scenario we are processing the body of the incoming message, which is expected to be the XML based instance document: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#po.xml, which matches the International Purchase Order Instance Document format: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#ipo.xsd

The expression: sum($Body/ipo:purchaseOrder[1]/items[1]/*/USPrice[1]) < 200 is evaluated by the runtime XPath engine, where it first generates a node-set (element list) based on the content of the body of the incoming message tree.

The path location expression $Body/ipo:purchaseOrder[1]/items[1]/*/ navigates first to the last child (Body) of the root element in the incoming message tree.

It then steps into the outer most top level tag; matching on the first occurrence of an element whose namespace URI equals http://www.example.com/IPO and whose element name equals purchaseOrder. It then steps into the first and only occurrence of the element named - items. Within items, the path location expression then uses an asterisk to perform a wildcard NameTest to match on all child elements below - items.

At this point we would expect the result so far generated by the runtime XPath engine to consist of a node-set containing two elements both named - item. To complete the evaluation of the entire path location expression, each of these elements will be stepped into and the first occurrence of an expected child element named - USPrice matched on.

Hence the final result would be a node-set containing two value elements named -- USPrice, where both hold a numeric value in the form of a string literal.

The XPath library function sum is called, which returns the sum of all nodes (elements) contained in the generated node-set. Here the value of each element is the result of converting its string-value to a number.

Finally the result of the left hand argument sum($Body/ipo:purchaseOrder[1]/ items[1]/*/USPrice[1]) (in our example resolving to 188.93) is compared to see if it’s less than the constant numeric value 200. In this example the comparison test resolves to true and so the incoming message assembly is propagated down the dynamic output terminal Match1.

Here the routing decision is used to make processing decisions on incoming purchase orders for a company. Those orders whose total cost, for all items quoted adds up to less than two hundred dollars, do not require management approval and so are separated from those that are equal to or above this limit.

3. DatabaseRoute node

This section describes the DatabaseRoute node and its capabilities and usage patterns.

Dynamic terminals -- The DatabaseRoute node can have further dynamic output terminals. Not all dynamic output terminals that are created on a DatabaseRoute node need to be mapped to an expression in the filter table. For unmapped dynamic output terminals, messages are never propagated to them. Several expressions can map to the same single dynamic output terminal.

3.1. Multi-language node properties

The following table outlines the multi-language property fields supported by the DatabaseRoute node.

3.2. Node capabilities and usage scenarios

You can use the DatabaseRoute node to pass messages straight through it and or route its messages. XPath routing decisions within this node can use information gathered from a user-supplied database in addition to that which may be queried from the node’s incoming message assembly content. Hence this node extends the capabilities offered via a Route node. However, this node should only be used when one or more routing decisions are required in which information is sourced from a database lookup. This node can lookup a collection of named column values from a located database row. It can then synchronously apply one or more user supplied XPath expressions to these acquired values. Each named column is represented as a named external variable binding (variable reference - $tableName_columnName), whose value is assigned based on the result set value retrieved from the database query for the column value of the same name.

1. You can use the DatabaseRoute node to dynamically route one or more copies of a given message down different flow legs based on a user provided expression applied to values retrieved from a specified data source.
2. It is often useful to combine the DatabaseRoute node with other nodes. For example, you might use an XSLT node to manipulate data, before or after the DatabaseRoute node is invoked.
3. In addition to performing routing decisions based of information acquired from a database lookup, this node may also in conjunction, perform equivalent routing behavior offered through the Route node where incoming message content information is evaluated.
4. Again, like the Route node this node may also simulate FlowOrder node capabilities where the incoming message assembly is always passed through (propagated on) to specific out bound dynamic terminals via expressions that always resolve to true.

As detailed in this node’s description in the product information center, this node also has a mandatory filter table property like the Route node which must contain at least one row representing a routing decision. Each row specifies a user defined routing expression and a dynamic terminal to propagate the node’s incoming message assembly to (if on evaluation of the expression its result when cast as a Boolean resolves to true). Like the Route node, this node too makes use of the Distribution Mode property to determine how routing decisions are handled. Unlike the Route node, this node also has a mandatory query elements table property which must contain at least two rows, one representing a table qualified column name and one representing a test condition. Together information contained in both rows provides enough detail to generate a well formed SQL select statement, which will be executed against the nodes specified data source. The row specifying the column is used to populate the SELECT, FROM and ORDER BY clauses of the SQL select statement. This statement is then completed by the row specifying the test condition, which is also used to populate the FROM clause and additional the WHERE clause so forming a predicate. We will now look at two usage cases for the node.

3.3. Usage scenario (filtering result set)

The DatabaseRoute node is used primarily to perform routing decisions based on information it has sourced from a database lookup. A collection of named column values from a specified database row are referenced within one or more synchronously processed XPath expressions. The SQL select statement specified in the query elements property of the DatabaseRoute node, when executed against the node’s defined data source, may produce inadvertently or otherwise more than one matching row in the result set. In all cases all matches are returned in the result set. For example consider the contents of the EMPLOYEE database table:

Now consider the example SQL select statement, expressed in the DatabaseRoute node’s query elements table (located of the Basic tab in the Properties viewer) illustrated:

The above query elements property table would produce the following SQL select query:

SELECT EMPLOYEE.FIRSTNAME, EMPLOYEE.LASTNAME
FROM EMPLOYEE
WHERE EMPLOYEE.LASTNAME = 'SMITH'
ORDER BY EMPLOYEE.FIRSTNAME ASC, EMPLOYEE.LASTNAME ASC

The result set produced by executing the above query against the database table EMPLOYEE would contain the following two rows of results:

For the DatabaseRoute node, it only makes sense for the node to act out its routing decisions based on column values relating to a specific single row match, built from one or more tables in the target database (as described in the on-line product information centre documentation, for this node inner-join syntax is supported allowing the concatenation of column data spanning across multiple tables within a given database). For the DatabaseRoute node it is always the values located in the first row within the result set that are acted upon. So for the results above, the named external variable bindings and associated assigned values, retrieved from the database query above, would be:

However what if you intended to work against values associated with John Smith rather than Adam Smith. We could add further predicates in the select query to test on first name in addition to last name, but tuning test conditions to get the desired results is time consuming and problematic, in that further refinements of the query still might return multiple rows and knowledge of stored columns and their values is also necessary.

To assist in this area, queries produced by both the DatabaseRoute and DatabaseRetrieve nodes have been provided with extra support in order to enable fine grain filtering or ordering of multi-row result sets, so that the message flow developer has greater certainty and control over which matching row will appear first in the result set. This control is provided in the form of the ORDER BY clause in conjunction with the order in which table qualified column names appear in the query elements table. The row order in the query elements table in which columns are defined determines their left to right sequence within the ORDER BY clause, which in turn determines their sorting priority.

So the first ORDER BY column defines the primary order of rows and subsequent columns within the ORDER BY clause further refine the order of rows i.e. any rows with matching first column values are further ordered by the second column specified and so on.

To mark a row within the query elements table as a column definition, the Operator choice for the row must be either ASC for ascending or DESC for descending. These operator choices provide further sorting control and accompany a given column in the ORDER BY clause.

Continuing with the example above, if we wished to apply routing decisions to row values associated with John Smith rather than Adam Smith, rather than add further predicates we can simply alter the ORDER BY clause. Consider Figure 9:

The above query elements property table would produce the following SQL select query:

SELECT EMPLOYEE.FIRSTNAME, EMPLOYEE.LASTNAME
FROM EMPLOYEE
WHERE EMPLOYEE.LASTNAME = 'SMITH'
ORDER BY EMPLOYEE.FIRSTNAME DESC, EMPLOYEE.LASTNAME ASC

The result set produced by executing the above query against the database table EMPLOYEE would contain the following two rows of results:

As you can see the row order is reversed with John now appearing in the first row. So for the results above, the named external variable bindings and associated assigned values, retrieved from this second database query, would be:

3.4. Handling NULL values in the result set

The DatabaseRoute node is used primarily to perform routing decisions based on information it has sourced from a database lookup. A collection of named column values from a located database row are referenced within one or more synchronously processed XPath expressions. For the DatabaseRoute node it is always the named column values located in the first row within the result set that are referenced and acted upon in these XPath routing expressions.

Each named column is represented in XPath as a named external variable binding (variable reference - $tableName_columnName), whose value is assigned based on the result set value retrieved from the database query for the column value of the same name.

In the case where a retrieved column has a value of SQL NULL, then no XPath variable reference expression is assigned to such a value. This is because the XPath runtime engine in Message Broker 6.1 (inline with the W3C XPath specification) doesn't support the concept of a NULL data type. Rather only values of type: Boolean, Double, String, MbElement and finally an array or list of MbElements may be assigned to a variable reference.

Therefore flow developers should not use routing decisions in which variable reference expressions map onto name columns whose values may be NULL. If you do not follow this recommendation and a retrieved column value is NULL and is referenced in a routing decision, then the runtime evaluation of the expression will fail, as the variable reference and its associated value will be unknown to the engine.

4. DatabaseRetrieve node

This section describes the DatabaseRetrieve node and its capabilities and usage patterns.

4.1. Multi-language node properties

The following table outlines the multi-language property fields supported by the DatabaseRetrieve node.

4.2. Node capabilities and usage scenarios

As with the DatabaseRoute node, you can use the DatabaseRetrieve node to retrieve data from one or more database tables. Again an SQL select statement can be built up according to one or more predicates (possibly established from primary keys in the incoming message, as identified by XPath expressions).

This new node makes it easier to retrieve data stored in one or more tables within a targeted database, which may be selected using incoming message content as a qualifier. Through this node such data retrieval capabilities can be achieved without the need for expert messaging or SQL programming knowledge. This node allows retrieved values from one or more tables within a database to be inserted into new or existing tree elements located in the outgoing message assembly. This node uses XPath exclusively for its message processing transformation language.

1. You can use the DatabaseRetrieve node to ensure information in a message is up-to-date.
2. You can use the DatabaseRetrieve node to add information to a message, using a key contained in a message. For example, the key could be an account number.
3. It is often useful to combine the DatabaseRetrieve node with other nodes. For example, you might use an XSLT node to manipulate data, before or after the DatabaseRetrieve node is invoked.
4. You can route a message to the same location whether or not a query is successful against a given database. To do this you wire both of the non-failure output terminals to the same output location

As detailed in this node’s description in the product information center, like the DatabaseRoute node this node also has a mandatory query elements table property which must contain at least two rows, one representing a table qualified column name and one representing a test condition. The information in both rows provides enough detail to generate a well formed SQL select statement, which will be executed against the nodes specified data source.

Like the DatabaseRoute node, this node looks up a collection of named column values from the located database. It then synchronously applies one or more user supplied XPath expressions to these acquired values. In the case of the DatabaseRetrieve node, the expressions take the form of XPath read-write path location expressions. These are used to indicate a target element in the out going message assembly, where an acquired value should overwrite the existing value (in the case where the element already exists in the tree). These path location expressions are entered in the mandatory Data elements table property of the Data Element Table tab in this node’s Properties viewer. In this table for each row, there is both a path location expression and an associated named column. The value associated with the named column is inserted into the element as described in the path.

If the Multiple rows option is selected for this node, then for each row in the result set the entries in the Data elements table are executed. This will result in multiple new value elements, with matching names, being appended at a given tree location. Each new element will hold a different value matching the named column value for the result set row concerned.

4.3. Handling NULL values in the result set

The DatabaseRetrieve node is used primarily to perform transformation logic based on information it has sourced from a database lookup. A collection of named column values from a located database row are inserted into one or more value elements as described through a set of XPath read-write path location expressions described in the data elements table. For the DatabaseRetrieve node, unless the Multiple rows option is selected, it is always the named column values located in the first row within the result set that are referenced and acted upon in these XPath message transformation expressions. Again, each named column is represented in XPath as a named external variable, whose value is assigned based on the result set value retrieved from the database query for the column value of the same name.

For this node the case where a retrieved column has a value of SQL NULL is supported, provided the target element (as specified in the Message element field within the Data elements property table) does not already exist and is therefore created as a new value element. In this case, by default, the value of the new element is deemed to represent a value of NULL.

In the case where the described target element already exists in the out going message assembly, then the element is left untouched. That is the retrieved NULL value for a named column is ignored and not used to update the out going message assembly for the element concerned. Hence, it is safe for message flow developers to insert named columns (whose values may be NULL) into an outgoing message assembly tree, if it is known that the target message element location will not exist in the tree concerned.

Where the target element location may already exist, then it may not be appropriate to attempt to insert values for named columns which may resolve to NULL. However the flow developer may wish to do this if they intend to treat known non modified values as the value NULL downstream in the flow.

Conclusion

This article described provided usage scenarios for the new Route, DatabaseRoute, and DatabaseRetrieve processing nodes in WebSphere Message Broker V6.1. The nodes support multi-language property fields, which let you choose in which language you would like to specify selection statements. You can easily express routing and transformation logic in either XPath or ESQL, letting business users with minimal knowledge of these languages use them for message flow formation. The business control and manipulation of managed data can now focus on the goal rather than on on the technology to achieve it, so that Message Broker users can accomplish more with less knowledge.

Resources

• WebSphere Message Broker developer resources page
  Technical resources to help you use WebSphere Message Broker for connectivity, universal data transformation, and enterprise-level integration of disparate services, applications, and platforms to power your SOA.
  
  
• WebSphere Message Broker product page
  Product descriptions, product news, training information, support information, and more.
  
  
• WebSphere Message Broker information center
  A single Web portal to all WebSphere Message Broker V6 documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere Message Broker environment.
  
  
• WebSphere Message Broker documentation library
  WebSphere Message Broker specifications and manuals.
  
  
• WebSphere Message Broker forum
  Get answers to your technical questions and share your expertise with other WebSphere Message Broker users.
  
  
• WebSphere Message Broker support page
  A searchable database of support problems and their solutions, plus downloads, fixes, problem tracking, and more.
  
  
• Redbook: Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB
  Patterns for e-business are a group of proven, reusable assets that can be used to increase the speed of developing and deploying e-business applications. This Redbook shows you how to use WebSphere ESB together with WebSphere Message Broker to implement an ESB within an SOA. Includes scenario to demonstrate design, development, and deployment.
  
  
  
  
• WebSphere Message Broker Route node
  Node description, purpose, and configuration from the product information centre.
  
  
• WebSphere Message Broker DatabaseRoute
  Node description, purpose, and configuration from the product information centre.
  
  
• WebSphere Message Broker DatabaseRetrieve
  Node description, purpose, and configuration from the product information centre.
  
  
• Developing XPath under WebSphere Message Broker page
  Shows you how to use XPath as your message flow development language, which is relevant for certain properties used in the above nodes to manage routing or transformation.
  
  
• Performance report for WebSphere Message Broker on Windows
  A description of processing costs on Windows for the three nodes described in this article.
  
  
• Performance report for WebSphere Message Broker on Linux on System x
  A description of processing costs on Linux for the three nodes described in this article.
  
  
  
  
• WebSphere SOA solutions developer resources page
  Get technical resources for WebSphere SOA solutions.
  
  
• developerWorks SOA and Web services zone
  Technical resources for evaluating, planning, designing, and implementing solutions that involve SOA and Web services.
  
  
• developerWorks WebSphere application connectivity zone
  Access to WebSphere application connectivity (formerly WebSphere business integration) how-to articles, downloads, tutorials, education, product info, and more.
  
  
• developerWorks WebSphere business process management zone
  Access to WebSphere BPM how-to articles, downloads, tutorials, education, product info, and other resources to help you model, assemble, deploy, and manage business processes.
  
  
• WebSphere business process management products page
  For both business and technical users, a handy overview of all business process management products.
  
  
  
  
• WebSphere forums
  Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
  
  
• Most popular WebSphere trial downloads
  No-charge trial downloads for key WebSphere products.
  
  
• Technical books from IBM Press
  Convenient online ordering through Barnes & Noble.
  
  
• developerWorks technical events and Webcasts
  Free technical sessions by IBM experts that can accelerate your learning curve and help you succeed in your most difficult software projects. Sessions range from one-hour Webcasts to half-day and full-day live sessions in cities worldwide.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• 1. Multi-language node property fields
• 2. Route node
• 3. DatabaseRoute node
• 4. DatabaseRetrieve node
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Message Broker
• Webcast: WebSphere Message Broker: Converting Maps to ESQL using Support Pac IA9Y
• Briefing: WebSphere flexible business processes for a smarter planet
• Buy: WebSphere Message Broker

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers