使用WMBV6.1中的新数据库和路由节点简化路由和传输

Stephen Rea, 软件工程师顾问，WebSphere Message Broker 开发团队, IBM

转自：http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0906_rea/0906_rea.html

简介

随着 IBM® WebSphere® Message Broker V6.1（后来称为 Message Broker）的发布，消息路由和传输又多了一些选择。新的 Route、DatabaseRoute 和 DatabaseRetrieve 节点使消息流开发人员能够使用消息流中的 XPath 表达式快速对消息执行操作。这三个节点都是非编程节点，这意味着它们可以用在消息流中，而不需要编写任何处理节点（ESQL 或 Java）。这三个节点在 Message Broker 的通用消息模型中使用，如果需要，甚至可以在同一个消息流中同时使用这三个节点，具体情况可以参考 Message Broker Toolkit 中 Samples Gallery 的 Simplified Database Routing 样例。本文描述每个节点的功能和限制，以及它们的典型用法。要理解并使用这些新节点，您只需要有一些基本的 SQL 和 XPath 知识。

1. 多语言节点属性字段

Message Broker V6.0 将 ESQL 和 Java 作为它的两种消息处理传输语言。如今 Message Broker V6.1 在选择处理语言时支持在节点属性字段中使用表达式项。Message Broker V6.1 为流开发人员引入了一个机制，可以选择在此类字段中输入 ESQL 或者 XPath 表达式。也就是说，Message Broker 中的新节点能够接受节点应用的路由决策中使用的表达式，也能够用作消息传输处理活动的一部分。

这些表达式现在作为属性值，通过新的多语言节点属性字段收集。这些字段已经在设计和构建时配置好了，以接收一种或者多种消息处理语言。通常，这意味着它们可以接受纯 ESQL 表达式、纯 XPath 表达式或者同时接受两者（多语言支持）。在后一种情况下，可以确保流开发人员有能力使用任何一种语言表示表达式，并且可以保留语句和节点行为，无论流开发人员使用的是哪种语法。

记住，工具箱中新的参考设置已经可以使用。这样可以跨所有此类多语言字段实施语法限制。当应用语法限制时，所有之后输入的有效表达式都可以使用任何一种语言表示。要实现这一点，必须对两种语法同时应用限制，在属性验证时执行。这样一来，使用其中任何一种语言的遵从表达式都可以顺利地迁移到该字段支持的另一种语言。

Message Broker Toolkit 提供了一个选项 “Use XPath and ESQL equivalent grammar（使用 XPath 和 ESQL 等效语法）” 来限制 XPath 语法，以便将 XPath 用户限制在等效 ESQL 表达式支持内。为了支持表达式在语言之间的双向迁移，受限制的语法模型也可以对 ESQL 语法产生一定的限制作用，以适应 XPath。请参见 选择语法模型。

默认情况下，用户将在受限制的语法模型下进行操作，因此支持迁移。在该模型中，字段值限制在适合输入特定字段的子集内。但是，如果这对于消息流开发人员来说限制太多，那么他们可以取消该首选项设置，以支持适合输入特定字段类型的无限制语法。仍然要验证表达式的语法是否适合字段类型的上下文，但这时的语法可以是运行时支持的所有语法。

XPath 语言映射（通过语言限制）到以下基本 ESQL 功能：

1. 路径位置 —— 返回一个元素，如果不可修改的树中不存在该元素，则返回 null。
2. 路径位置 —— 如果不存在，则创建指向目标元素的导航路径上的所有祖先元素，并返回可修改树的目标元素。
3. 表达式 —— 仅检查返回表达式结果的树内容（元素值）。

因此 Message Broker Toolkit 中包含属性编辑器类型，以支持现在 Message Broker 引入的新元节点中使用的多语言字段，这些类型分类如下：

1. 类别 (a) 路径位置字段，工具支持以下新的属性字段：
   1. Fixed —— ESQL 只读路径（字段引用）字段属性。
   2. Fixed —— XPath 只读路径（路径位置）字段属性。
   3. Mixed —— ESQL 或 XPath 只读路径位置字段属性。
2. 类别 (b) 路径位置字段，工具支持以下新的属性字段：
   1. Fixed —— ESQL 读-写路径（字段引用）字段属性。
   2. Fixed —— XPath 读-写路径（路径位置）字段属性。
   3. Mixed —— ESQL 或 XPath 读-写路径位置字段属性。
3. 类别 (c) 表达式字段，工具支持以下新的属性字段：
   1. Fixed —— XPath 表达式字段属性。

2. Route 节点

本节描述 Route 节点及其功能和使用模式。

图 1. 消息流编辑器中的 Route 节点按钮



Route 终端规范

终端名	描述
In	接受消息以供节点处理的静态输入终端。
Match	处理成功完成后可以将原消息路由到的动态输出终端。您可以创建其他动态终端；请参见 “动态终端”。
Default	没有筛选表达式解析为真时路由消息的静态输出终端。
Failure	处理过程中检测到失败时路由消息的静态输出终端。

动态终端 —— Route 节点还有更多的动态输出终端。并非所有在 Route 节点上创建的动态输出终端都需要映射到筛选表格的表达式。对于没有映射的动态输出终端，消息绝不会传播到这些终端。一些表达式可以映射到同一个动态输出终端。不存在可以直接传递消息的输出终端。

2.1. 多语言节点属性

下表列出了 Route 节点支持的多语言属性字段。具体给出了它们在属性查看器中的位置、多语言字段的类型，以及 XPath 表达式支持的定义变量引用，该引用可以输入相关的字段属性。

Route 的多语言属性规范

位置	字段类别	支持的变量
Properties Viewer>Basic tab => Filter table => filterPattern	C	Root、Body、Properties、LocalEnvironment、DestinationList、ExceptionList、Environment

2.2. 节点功能

可以使用 Route 节点，根据用户提供的应用于输入消息内容的表达式，动态将一个或多个给定消息的副本路由到消息流的不同路径。其中每个表达式都与特定的输出终端关联。

1. 您可以使用 Route 节点检查入站消息是否满足某些条件。例如，是否设置了需要的字段。如果不满足条件，您可以使用 Throw 节点引发一个异常。
2. Route 节点允许不同的消息使用不同的路径。例如，根据请求的详细内容，消息可能需要转发到不同的服务提供商。
3. 您可以使用 Route 节点绕过不必要的步骤。您可以测试消息中是否包含特定的数据，如果数据丢失，则可以执行数据库检索操作。
4. 当与 DatabaseRetrieve 节点配合使用时，Route 节点可以独立管理的查询表内容控制消息。例如，您可以根据客户状态路由消息，即使入站消息只包含客户标识符。
5. 通过配置该节点将消息传播到所有匹配的终端，您可以触发多个事件，而每个事件都需要不同的条件。例如，您可以记录与特定帐户标识符相关的请求，还可以发送与要审计的特定产品相关的请求。

通常，该节点允许根据内容路由输入消息，其中使用 XPath 作为表达式语言来查询内容（消息处理路由语言）。

当然，有人会争辩说，使用 xPath 构建查询表达式实际上就是编程，但我们的目的在于，使用 XPath 表达式要比 ESQL、Java 或映射编程环境简单的多，允许用户使用简单的表达式（可能引用从组成该节点的输入消息树中获取的值）控制处理过程。

XPath 查询语法可参见 W3C 推荐，地址：http://www.w3.org/TR/xpath。

正如产品信息中心对该节点的详细描述一样，该节点包含一个强制筛选表格属性，其中必须包含至少一个表示路由决策的行。每个行都指定一个用户定义的路由表达式和一个传播节点输入消息组件的动态终端（如果对表达式求值时，它强制转换为布尔值的结果为真）。

当节点的 Distribution Mode 属性设置为 All 时，表格中的每个行都保证能够按照给定的顺序同步进行处理。节点输入消息组件的副本传播到每个行中用户定义的动态输出终端，其中路由表达式解析为真。否则，节点的输入消息组件将传播到名为 Default 的静态输出终端。

当节点的 Distribution Mode 属性设置为 First 时，表格中的每个行都是按照给定的顺序同步处理的，直到满足路由决策。对于解析为真的路由表达式，节点输入消息组件的副本将传播到行中用户定义的动态输出终端。否则，点的输入消息组件将传播到名为 Default 静态输出终端。

接下来我们将讨论 Route 节点的使用模式。

2.3. 使用场景（替代 FlowOrder 节点）

您可以配置 Route 节点按照 FlowOrder 节点的方式操作。

如上所述，Route 节点对表达式求值，结果将强制转换为布尔值，以生成真或假的测试条件。只有在最后结果为真时，节点才会将消息传播到表达式的匹配输出终端。通过将分发模式设置为 All 并输入两个或多个总是解析为真的路由决策，该节点可以提供等效于 FlowOrder 节点的行为。

FlowOrder 节点总是将消息树传播到它的每个终端（假设它们相连）。Route 节点和 FlowOrder 节点之间的主要区别在于，支持同步分支执行的输出终端数不同，性能方面也可能不同。

1. 输出终端数量 —— FlowOrder 节点限制为两个固定的静态输出终端，只提供两个分支来安排下游流活动的同步通过顺序。Route 节点中，执行处理活动可以使用的动态输出终端数是无限的。
2. 性能 —— 如果在流的特定点只需要顺序处理两个分支，那么 FlowOrder 节点可能相对较快。但是，如果需要顺序处理 4 个分支，那么将需要链接 3 个 FlowOrder 节点，在这种情况下使用 Route 节点更有可能提供更高的性能。

下面我们将介绍如何使用 Route 节点代替多个 FlowOrder 节点的示例。示例的设置是顺序处理一家家具公司新客户的订单。请参见图 2，其中演示了使用 FlowOrder 节点时的消息流。

图 2. 使用 FlowOrder 节点处理客户订单

三个 FlowOrder 节点链接在一起提供流中的 4 个分支执行，以保证按照正确的顺序执行公司采购流程的 4 个独立活动。顺序如下：

1. 在公司数据库的客户表中创建一个新的客户记录。
   1. FlowOrder（输出终端：First） => CreateNewCustomer（DataInsert 节点，输入终端：In）
   2. FlowOrder（输出终端：Second） => FlowOrder1 （输入终端：In）
2. 增加一个新的家具订单 —— 在公司数据库的订购表格中创建一个新的订单记录。
   1. FlowOrder1（输出终端：First） => CreateFurnitureOrder（DataInsert 节点，输入终端：In）
   2. FlowOrder1（输出终端：Second） => FlowOrder2 （输入终端：In）
3. 更新公司数据库客户表格中的客户记录，记下支付方式和详细内容。
   1. FlowOrder2（输出终端：First） => UpdateCustomerPaymentDetails（DataUpdate 节点，输入终端：In）
   2. FlowOrder2（输出终端：Second） => DespatchOrder（MQOutput 节点，输入终端：In）。 将订单分配到公司订单处理部门的工作流。

如果使用 Route 节点替代 FlowOrder 节点来执行与上文相同的订购流程，请考虑图 3 中的消息流：

图 3. 使用 Route 节点处理客户订单

结果是一个简单很多的消息流结构。如果使用一个 Route 节点，则顺序如下：

1. 在公司数据库的客户表中创建一个新的客户记录。
   1. Route （动态输出终端：Match1） => CreateNewCustomer（DataInsert 节点，输入终端：In）
2. 增加一个新的家具订单 —— 在公司数据库的订购表格中创建一个新的订单记录。
   1. Route（动态输出终端 ：Match2） => CreateFurnitureOrder（DataInsert 节点，输入终端：In）
3. 更新公司数据库客户表格中的客户记录，记下支付方式和详细内容。
   1. Route （动态输出终端：Match3） => UpdateCustomerPaymentDetails（DataUpdate 节点，输入终端：In）
4. 将订单分配到公司订单处理部门的工作流。
   1. Route（动态输出终端：Match4） => DespatchOrder（MQOutput 节点，输入终端：In）。

为了配置 Route 节点来模拟 FlowOrder 节点的行为，路由表达式求值必须始终为真。与其使用内置的 XPath 函数 true()，不如输入数值 1。由于所有表达式都强制转换为布尔值，因此 “1” 将返回真。要模拟 4 个分支 FlowOrder 节点，上一个流（图 3）Route 节点的筛选表格应该如图 4 所示：

图 4. Route 节点筛选表格和分发模式属性设置

2.4. 使用场景（与消息正文分析器无关的路由）

您可以配置 Route 节点将传入消息组件指向流中给定的位置（如果消息树中存在指定的名称元素），而无论消息树正文使用的是哪种分析器。例如，考虑下图 5 中描述的 Route 节点筛选表格：

图 5. Route 节点筛选表格和分发模式属性设置

从上面的设置我们可以看到，第一次出现的任何路由决策解析为真时，Route 节点只将一个传入消息组件的副本传播到 Match1 动态输出终端。在这种情况下，我们查找字段名 FirstName，该字段组成客户的详细信息，出现在输入消息树的正文中。这里我们考虑了消息域为 MRM 或 XMLNSC 的情况。如果消息正文归 XMLNSC 分析器所有，那么我们可以在名为 CustomerDetails 的外部顶级标记下找到该字段。但是，如果消息正文归 MRM 分析器所有，那么我们无法在该外部标记下找到该字段，因为该分析器移除了外部标记。

2.5. 使用场景（复杂路由表达式）

作为筛选模式输入 Route 节点的路由决策可以是任何组织良好的类别 (c) XPath 常规表达式。因此，决策逻辑可能非常完善。例如，考虑下图 6 中描述的 Route 节点筛选表：

图 6. Route 节点筛选表和分发模式属性设置

从上面的设置我们可以看到，Route 节点仅在单个路径决定解析为真时将一个传入消息组件的副本传播到 Match1 动态输出终端。

在这种情况下，我们要处理传入消息的正文，这应该是一个基于 XML 的实例文档：http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#po.xml，该文档匹配 International Purchase Order Instance Document 格式：http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#ipo.xsd。

表达式：sum($Body/ipo:purchaseOrder[1]/items[1]/*/USPrice[1]) < 200 由运行时 XPath 引擎求值，首先根据传入消息树的正文内容生成一个节点集合（元素列表）。

路径位置表达式 $Body/ipo:purchaseOrder[1]/items[1]/*/ 首先导航到传入消息树根元素的最后一个子元素（正文）。

然后，它步进到外部最顶层标记；匹配第一个名称空间 URI 等于 http://www.example.com/IPO 且元素名称等于 purchaseOrder 的元素。然后步进到第一个且只出现一次的元素 named - item。在 items 中，路径位置表达式使用星号作为通配符 NameTest 匹配所有子元素 below - item。

到目前为止，我们得到的结果（由运行时 XPath 生成）由一个包含两个元素的节点集组成，这两个元素都是 named - item。要完成整个路径位置表达式的求值，所有元素都必须步进，并匹配第一次出现的子元素 named - USPrice。

因此，最终结果应该是一个包含两个值元素 named - USPrice 的节点集，这两个元素都存有字符串参数形式的数值。

将调用 XPath 库函数 sum，该函数将返回生成的节点集所包含全部节点（元素）的和。在本例中，每个元素的值是将其字符串值转换为数字后所得的结果。

最后，比较左边参数 sum($Body/ipo:purchaseOrder[1]/ items[1]/*/USPrice[1]) 的结果（我们的示例中解析为 188.93），看它是否小于常数值 200。在本例中，比较测试解析为真，因此传入消息组件传播到动态输出终端 Match1。

这里使用路由决策处理公司传入的购买订单。这些订单的总成本（所有商品单价之和）小于 200 美元，因此不需要管理审批，于是将其与等于或大于 200 美元的订单区分开来。

3. DatabaseRoute 节点

本节描述 DatabaseRoute 节点及其功能和使用模式。

图 7. 消息流编辑器中的 DatabaseRoute 节点按钮



DatabaseRoute 的终端规范

终端名	Description
In	接受消息以供节点处理的静态输入终端。
Match	处理成功完成后可以将原消息路由到的动态输出终端。您可以创建其他动态终端；请参见 “动态终端”。
Default	没有筛选表达式解析为真时路由消息的静态输出终端。
KeyNotFound	没有匹配的数据库行时复制消息的静态输出终端。
Failure	处理过程中检测到失败时路由消息的静态输出终端。

动态终端 —— DatabaseRoute 节点还有更多的动态输出终端。并非所有在 DatabaseRoute 节点上创建的动态输出终端都需要映射到筛选表格的表达式。对于没有映射的动态输出终端，消息绝不会传播到这些终端。一些表达式可以映射到同一个动态输出终端。

3.1. 多语言节点属性

下表列出了 DatabaseRoute 节点支持的多语言属性字段。

DatabaseRoute 的多语言属性规范

位置	字段类别	支持的变量
PropertiesViewer => Basic tab => Query elements => Value（ValueType 列等于 Element 时使用）	C	Root、Body、Properties、LocalEnvironment、DestinationList、ExceptionList、Environment
Properties Viewer => Filter Expression Table tab => Filter table => filterPattern)	C	Root、Body、Properties、LocalEnvironment、DestinationList、ExceptionList、Environment

3.2. 节点功能和使用场景

您可以使用 DatabaseRoute 节点直接传递消息或路由消息。本节点中的 XPath 路由决策除了可以使用从节点输入消息组件内容查询到的信息之外，还可以使用从用户提供的数据库中收集的信息。因此，该节点扩展了 Route 节点提供的功能。但是，仅当需要其信息来自数据库查询的一个或多个路由决策时，才能使用该节点。该节点可以从特定的数据库行查找指定列值的集合。然后，它可以向找到的这些值同步应用一个或多个用户提供的 XPath 表达式。每个指定的列都可以表示为一个指定的外部变量绑定（variable reference - $tableName_columnName），赋给它的值根据从数据库检索同名列值所得的集合值确定。

1. 可以使用 DatabaseRoute 节点，根据用户提供的应用于指定数据源检索所得值的表达式，动态将一个或多个给定消息的副本路由到消息流的不同路径。
2. 将 DatabaseRoute 节点与其他节点配合使用往往很有用。例如，在调用 DatabaseRoute 节点之前或之后，可以使用 XSLT 节点操纵数据。
3. 除了根据数据库查询所得信息执行路由决策之外，该节点也可以结合使用，可以执行 Route 节点提供的等效路由行为，其中传入消息内容信息会被求值。
4. 同样，与 Route 节点相同，该节点也可以模仿 FlowOrder 节点功能，其中传入消息组件总是可以通过始终解析为真的表达式传递（传播）到特定的出站动态终端。

正如产品信息中心对该节点描述的一样，该节点跟 Route 节点一样，包含一个强制筛选表格属性，其中必须包含至少一个表示路由决策的行。每个行都指定一个用户定义的路由表达式和一个传播节点输入消息组件的动态终端（如果对表达式求值时，它强制转换为布尔值的结果为真）。与 Route 节点一样，该节点也利用 Distribution Mode 属性确定如何处理路由决策。与 Route 节点不同的地方在于，该节点还有一个强制查询元素表属性，其中必须包含至少两个元素，一个表示表格合格列名称，一个表示测试条件。加在一起，两个行中包含的信息为生成完整的 SQL select 语句提供了足够的细节，该语句将对指定数据源的节点执行。指定列的行用来组成 SQL select 语句的 SELECT、FROM 和 ORDER BY 子句。再加上指定测试条件的行，该语句就完整了，指定测试条件的行用来组成 FROM 子句以组成谓语。我们现在将介绍两个该节点的用例。

3.3. 使用场景（筛选结果集）

DatabaseRoute 节点主要用来根据从数据查询得到的信息执行路由决策。指定数据库中指定列值的集合在一个或多个同步处理的 XPath 表达式中得以引用。对节点的定义数据源执行时，SQL select 语句在 DatabaseRoute 节点的查询元素属性中指定，这可能导致疏忽或其他情况，使结果集中出现多个匹配行。无论是什么情况，结果集中将返回所有匹配行。例如，考虑 EMPLOYEE 数据库表的内容：

摘自数据库表 EMPLOYEE

EMPNUM	FIRSTNAME	LASTNAME
000010	ADAM	SMITH
000020	JOHN	SMITH

现在考虑使用 DatabaseRoute 节点的查询元素表表示的（位于 Properties 查看器的 Basic 选项卡）示例 SQL select 语句，如下所示：

图 8. DatabaseRoute 节点查询元素表属性设置

上面的查询元素属性表将生成以下 SQL select 查询：

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

对数据库表 EMPLOYEE 执行上面的查询生成的结果集将包含以下两个结果行：

数据库表 EMPLOYEE 查询生成的结果集

FIRSTNAME	LASTNAME
ADAM	SMITH
JOHN	SMITH

对于 DatabaseRoute 节点，它只有在根据与特定的一个行匹配相关的列值进行路由决策时才有意义，注意，这里的行匹配是根据目标数据库中的一个或多个表格构建的（正如在线产品信息中心文档所述，该节点支持 inner-join 语法，允许连接给定数据库中多个表格的列数据）。对于 DatabaseRoute 节点，它始终位于要操作的结果集第一行的值。因此对于上面的结果，指定的外部变量绑定和相关赋值（从上面的数据库查询检索而来）是：

外部变量绑定和值

XPath 变量名	值
$EMPLOYEE_FIRSTNAME	ADAM
$EMPLOYEE_LASTNAME	SMITH

但是，如果您想处理与 John Smith 而不是 Adam Smith 相关的值，那应该怎么办呢？我们可以在 select 查询中添加更多的谓语来测试姓和名，但是调整测试条件来获得所需的结果将很耗时，而且存在问题，因为进一步调整查询之后仍然可能返回多个行，因此了解存储的列及其值也是很必要的。

为了给这方面提供帮助，DatabaseRoute 和 DatabaseRetrieve 节点生成的查询都同时提供了额外的支持，以便支持细粒度多行结果集筛选或排序，从而消息流开发人员可以更加确认和控制结果集中将首先出现哪个匹配行。这种控制通过 ORDER BY 子句以及表合格列名称在查询列表格中出现的顺序实现。定义了列的查询元素表中的行顺序决定了它们在 ORDER BY 子句中从左到右的顺序，这又确定了它们的排序优先级。

因此，第一个 ORDER BY 列定义行的主要顺序，ORDER BY 子句中的后续列进一步细化行顺序，即任何匹配第一个列值的行都根据第二列进一步排序，依此类推。

要在查询元素表中将行标记为列定义，行的 Operator 选择对升序必须为 ASC，对降序必须为 DESC。这些操作符选择提供进一步的排序控制，伴随着 ORDER BY 子句中的给定列出现。

继续上面的示例，如果我们希望对与 John Smith 而不是 Adam Smith 关联的行值应用路由决策，我们不是再添加一个谓语，而是简单地更改 ORDER BY 子句。考虑图 9：

图 9. DatabaseRoute 节点查询元素表属性设置

上面的查询元素属性表应该生成以下 SQL 选择查询：

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

对数据库表 EMPLOYEE 执行上述查询生成的结果集将包含以下两个结果行：

数据库表 EMPLOYEE 查询生成的结果集

名	姓
JOHN	SMITH
ADAM	SMITH

正如您看到的，行顺序变了，现在 John 出现在第一行。对于上述结果，指定的外部变量绑定和相关赋值（检索自第二个数据库查询）是：

外部变量绑定和值

XPath 变量值	值
$EMPLOYEE_FIRSTNAME	JOHN
$EMPLOYEE_LASTNAME	SMITH

3.4. 处理结果集中的 NULL 值

DatabaseRoute 节点主要用于根据它从数据库查询中得到的信息执行路由决策。给定数据库行中的指定列值集合可以在一个或多个同步处理的 XPath 表达式中引用。对于 DatabaseRoute 节点，始终是结果集第一行中的指定列值被引用，并用于这些 XPath 路由表达式。

每个指定的列都可以表示为一个指定的外部变量绑定（variable reference - $tableName_columnName），赋给它的值根据从数据库检索同名列值所得的集合值确定。

如果检索到的列值为 SQL NULL，那么不会给此类值分配任何 XPath 变量引用表达式。这是因为 Message Broker 6.1（符合 W3C XPath 规范）中的 XPath 运行时引擎不支持 NULL 数据类型的概念。只有以下类型的值才能分配给变量引用：Boolean、Double、String、MbElement，最后还包括 MbElements 数组或列表。

因此，流开发人员不应该使用变量引用表达式映射到名称列可能为 NULL 的路由决策。如果无视该建议，在路由决策中引用了为 NULL 的检索列值，那么对表达式的运行时求值将失败，因为引擎无法识别该变量引用及其关联值。

4. DatabaseRetrieve 节点

本节描述 DatabaseRetrieve 节点及其功能和使用模式。

图 10. 消息流编辑器中的 DatabaseRetrieve 节点按钮



DatabaseRetrieve 的终端规范

终端名	描述
In	接受消息以供节点处理的静态输入终端。
Out	修改成功后路由输出消息的静态输出终端。
KeyNotFound	结果设置为空时不更改路由原消息的静态输出终端。
Failure	处理过程中检测到失败时路由消息的静态输出终端。

4.1. 多语言节点属性

下表描述 DatabaseRetrieve 节点支持的多语言属性字段。

DatabaseRetrieve 的多语言属性规范

位置	字段类别	支持的变量
Properties Viewer> Basic tab => Query elements => Value（ValueType 列等于 - Element 时使用）	C	InputRoot、InputBody、InputProperties、InputLocalEnvironment、InputDestinationList、InputExceptionList、Environment
Properties Viewer => Data Element Table tab => Data elements => Message element	B（仅支持 XPath）	OutputRoot、OutputLocalEnvironment、OutputDestinationList、OutputExceptionList、Environment

4.2. 节点功能及使用场景

与 DatabaseRoute 节点一起，您可以使用 DatabaseRetrieve 节点从一个或多个数据库表检索数据。同样，可以根据一个或多个谓语构建 SQL select 语句（根据 XPath 表达式的确认，还可以根据传入消息的主键建立）。

这个新节点使得检索目标数据库的一个或多个表格中的数据变得更加容易，目标数据库可以通过将传入消息内容作为限定符来选择。有了该节点，即使没有专业的消息传递或 SQL 编程知识，也可以实现这种数据检索功能。该节点可以将从数据库一个或多个表中检索到的值插入输出消息组件中的新树元素或现有树元素。该节点只使用 XPath 作为其消息处理转换语言。

1. 可以使用 DatabaseRetrieve 节点确保消息中的信息是最新的。
2. 可以使用 DatabaseRetrieve 节点使用消息中包含的键向消息添加信息。例如，键可以是一个帐户编号。
3. 组合 DatabaseRetrieve 节点与其他节点往往很有用。例如，在调用 DatabaseRetrieve 节点之前或之后，您可以使用 XSLT 节点操纵数据。
4. 不管对给定数据库的查询是否成功，您都可以将消息路由到同一个位置。要实现这一点，您需要将非失败输出终端连接到同一个输出位置。

正如产品信息中心对该节点的描述一样，该节点和 DatabaseRoute 节点一样，也包含一个强制筛选表格属性，其中必须包含至少至少两行，一个表示表格合格列名称，一个表示测试条件。两个行中包含的信息为生成完整的 SQL 选择语句提供了足够的细节，该语句将对指定数据源的节点执行。

与 DatabaseRoute 节点一样，该节点查询给定数据库的指定列值集合。然后向这些查询到的值应用一个或多个用户提供的 XPath 表达式。在 DatabaseRetrieve 节点中，表达式采用 XPath 读-写路径位置表达式的形式。这些表达式用于指示输出消息组件中的目标元素，其中获取的元素应该重写现有值（假如树中已经存在元素）。这些路径位置表达式输入到该节点 Properties 查看器 Data Element Table 选项卡的强制 Data 元素表属性中。在该表的每一行中，都有一个路径位置表达式和一个相关的指定列。与指定列关联的值被插入路径描述的元素中。

如果选择了该节点的 Multiple rows 选项，那么对于结果集中每一行，都将执行 Data 元素中的条目。这将得到多个新的值元素，这些元素具有匹配名称，并附加到给定的树位置。每个新元素都包含一个匹配相关结果集行的指定列值。

4.3. 处理结果集中的 NULL 值

DatabaseRetrieve 节点主要用于根据它从数据库查询中得到的信息执行路由决策。给定数据库行中的指定列值集合可以通过数据元素表中描述的 XPath 读-写路径位置表达式集合插入一个或多个值元素。对于 DatabaseRetrieve 节点，除非选择了 Multiple rows 选项，否则始终是结果集第一行中的指定列值被引用，并用于这些 XPath 路由表达式。同样，每个指定的列都可以在 XPath 中表示为一个指定的外部变量绑定，赋给它的值根据从数据库检索同名列值所得的集合值确定。

对于该节点，检索列的值为 SQL NULL 是受支持的，前提是目标元素（在 Data 元素属性表的 Message 元素中指定）不存在，并且因此创建了一个新的值元素。在这种情况下，新元素的值默认表示 NULL 值。

如果描述的目标元素已经存在于输出消息组件中，那么该元素保持不变。将忽略针对指定元素检索得到的 NULL 值，并且不使用该值更新相关元素的输出消息组件。因此，对于消息流开发人员来说，只要了解目标消息元素位置不存在于相关树中，让输出消息组件树插入指定列（值可以为 NULL）是安全的。

对于已经存在目标元素位置的情况，则不适合插入解析为 NULL 的指定元素值。但是，如果流开发人员故意将流中已知未修改的值视为 NULL，那么也可以这样做。

结束语

本文描述了 WebSphere Message Broker V6.1 中的新 Route、DatabaseRoute 和 DatabaseRetrieve 处理节点提供的使用场景。节点支持多语言属性字段，允许您选择用于指定选择语句的语言。您可以使用 XPath 或 ESQL 轻松表示路由和转换逻辑，使不是很了解编程语言的业务用户能够使用它们进行消息流格式化。业务控件和托管数据的操作现在可以关注目标而不是实现它的技术，因此 Message Broker 用户可以用更少的知识实现更多的功能。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-614788/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14789789/viewspace-614788/