使用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 終端規範

動態終端 —— Route 節點還有更多的動態輸出終端。並非所有在 Route 節點上建立的動態輸出終端都需要對映到篩選表格的表示式。對於沒有對映的動態輸出終端，訊息絕不會傳播到這些終端。一些表示式可以對映到同一個動態輸出終端。不存在可以直接傳遞訊息的輸出終端。

2.1. 多語言節點屬性

下表列出了 Route 節點支援的多語言屬性欄位。具體給出了它們在屬性檢視器中的位置、多語言欄位的型別，以及 XPath 表示式支援的定義變數引用，該引用可以輸入相關的欄位屬性。

Route 的多語言屬性規範

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 的終端規範

動態終端 —— DatabaseRoute 節點還有更多的動態輸出終端。並非所有在 DatabaseRoute 節點上建立的動態輸出終端都需要對映到篩選表格的表示式。對於沒有對映的動態輸出終端，訊息絕不會傳播到這些終端。一些表示式可以對映到同一個動態輸出終端。

3.1. 多語言節點屬性

下表列出了 DatabaseRoute 節點支援的多語言屬性欄位。

DatabaseRoute 的多語言屬性規範

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

現在考慮使用 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 查詢生成的結果集

對於 DatabaseRoute 節點，它只有在根據與特定的一個行匹配相關的列值進行路由決策時才有意義，注意，這裡的行匹配是根據目標資料庫中的一個或多個表格構建的（正如線上產品資訊中心文件所述，該節點支援 inner-join 語法，允許連線給定資料庫中多個表格的列資料）。對於 DatabaseRoute 節點，它始終位於要操作的結果集第一行的值。因此對於上面的結果，指定的外部變數繫結和相關賦值（從上面的資料庫查詢檢索而來）是：

外部變數繫結和值

但是，如果您想處理與 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 出現在第一行。對於上述結果，指定的外部變數繫結和相關賦值（檢索自第二個資料庫查詢）是：

外部變數繫結和值

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 的終端規範

4.1. 多語言節點屬性

下表描述 DatabaseRetrieve 節點支援的多語言屬性欄位。

DatabaseRetrieve 的多語言屬性規範

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/，如需轉載，請註明出處，否則將追究法律責任。