配接器處理概觀

配接器採用 IBM 對「Java 訊息服務 (JMS)」的 WebSphere MQ 實作方式。 JMS 是一項開放標準的 API,用來存取企業傳訊系統。設計讓商業應用系統可非同步地傳送並接收商業資料與事件。

配接器不會直接與 WebSphere Business Integration Message Broker 相互作用。

您可以在配置連接器時,將 WebSphere MQ 佇列設定為 WebSphere Business Integration Message Broker 訊息流程的輸出及輸入節點。 配接器會與控管訊息分配管理系統的 WebSphere MQ 佇列管理程式 (已部署訊息流程) 進行通訊。

訊息要求

圖 2 解說連接器 (配接器的執行時期元件) 的訊息要求通訊。 當 doVerbFor() 方法收到來自協同作業的商業物件時,連接器會將商業物件傳送到資料處理常式。

資料處理常式將商業物件轉換成適合的訊息,再發送至佇列。

因此,JMS 層會執行適當的呼叫以開啟佇列階段作業來遞送訊息。 您可以配置連接器,以非同步方式發出要求 (發動即忘)。

或者,您也可以配置連接器內容,來啟用同步要求處理程序。

圖 2. 訊息要求處理程序


連接器依據每一個商業物件的動詞來處理協同作業傳送給它的商業物件。

連接器使用商業物件處理常式和 doVerbFor() 方法來處理連接器支援的商業物件。連接器支援下列商業物件動詞:

註:
搭配 Create、Update 及 Delete 動詞的商業物件可同步或非同步地發出。 預設模式為非同步。 對於具有 Retrieve、Exists 或 Retrieve by Content 等動詞的商業物件,連接器不支援非同步遞送。

因此,對於 Retrieve、Exists 或 Retrieve by Content 動詞,預設模式為同步。

Create、update 及 delete

對於搭配 create、update 及 delete 動詞的商業物件, 其處理程序視物件是同步或非同步發出而定。

非同步遞送

這是具有 Create、Update 及 Delete 動詞之商業物件的預設遞送模式。

訊息是透過資料處理常式從商業物件中建立,然後寫入輸出佇列中。 如果順利遞送訊息,則連接器傳回 SUCCESS,否則傳回 FAIL。

註:
連接器無從驗證訊息是否已被收到或是否已採取動作。

同步遞送

若連接器特有內容中已定義 ReplyToQueue,且 responseTimeout 存在於商業物件的 Meta 物件轉換內容中,則連接器會以同步模式來發出要求。

然後,連接器將等待回應以驗證接收之應用程式已採取適當的動作。

對於 WebSphere Integration Message Broker,連接器最初發出的訊息含有表 2 顯示的標頭。

表 2.
要求訊息描述子標頭 (MQMD)
欄位 說明
Format
格式名稱 Meta 物件轉換內容中所定義的輸出格式,並截斷成 8 個字元以符合 IBM 基本需求 (例如:MQSTR
MsgType
訊息類型 MQMT_DATAGRAM*
Report
所要求之報告訊息的選項。 當期望有回應訊息時,將此欄位輸入資料如下:MQRO_PAN* 表示如果順利完成,則需要正面動作報告。MQRO_NAN* 表示如果處理失敗,則需要負面動作報告。MQRO_COPY_MSG_ID_TO_CORREL_ID* 表示已產生之報告的相互關係 ID 應該等於最初所發出之要求的訊息 ID。
ReplyToQ 回覆佇列的名稱 當預期為回應訊息時,此欄位中會輸入連接器內容 ReplyToQueue 的值。
Persistence
訊息持續性 MQPER_PERSISTENT*
Expiry
訊息生命週期 MQEI_UNLIMITED*

* 表示 IBM 所定義的常數。

表 2 所說明的訊息標頭後面接著訊息主體。訊息主體為已透過資料處理常式來序列化的商業物件。

Report 欄位的設定指出預期從接收之應用程式傳回正面和負面的動作報告。發出訊息的執行緒將等待回應訊息, 此回應訊息指出接收之應用程式是否能夠處理要求。

當應用程式收到來自連接器的同步要求時,它會處理商業物件,並發出報告訊息, 如表 3表 4表 5 所說明。

表 3.
回應訊息描述子標頭 (MQMD)
欄位 說明
Format 格式名稱 轉換內容中所定義的 busObj 輸入格式。
MsgType 訊息類型 MQMT_REPORT*

* 表示 IBM 所定義的常數。


表 4.
回應訊息的個體群
動詞 回饋欄位 訊息主體
Create、update 或 delete

SUCCESS

VALCHANGE

(選用)反映變更的序列化商業物件。

VALDUPES

FAIL

(選用)錯誤訊息。


表 5. WebSphere Integration Message Broker 回饋碼及 WebSphere Business Integration 系統回應值
WebSphere Integration Message Broker 回饋碼 相等的 WebSphere Business Integration 系統回應*
MQFB_PANor MQFB_APPL_FIRST SUCCESS
MQFB_NANMQFB_APPL_FIRST + 1 FAIL
MQFB_APPL_FIRST + 2

VALCHANGE

MQFB_APPL_FIRST + 3

VALDUPES

MQFB_APPL_FIRST + 4

MULTIPLE_HITS

MQFB_APPL_FIRST + 5

FAIL_RETRIEVE_BY_CONTENT

MQFB_APPL_FIRST + 6

BO_DOES_NOT_EXIST

MQFB_APPL_FIRST + 7 UNABLE_TO_LOGIN (導致立即終止連接器代理程式)
MQFB_APPL_FIRST + 8 APP_RESPONSE_TIMEOUT

*詳細資料請參閱 Connector Development Guide

若可處理商業物件,則應用程式會建立報告訊息, 並將回饋欄位設為 MQFB_PAN (或特定的 WebSphere Business Integration 系統值)。(可選用的)應用程式將於訊息主體中輸入含有任何變更的序列化商業物件。 若無法處理商業物件,應用程式則會建立報告訊息, 並將回饋欄位設為 MQFB_NAN (或特定的 WebSphere Business Integration 系統值), 然後在訊息主體中選擇是否併入錯誤訊息。 於任何一種情況下,應用程式會將訊息的 correlationID 欄位設為連接器訊息的 messageID,並發出至 ReplyToQueue 欄位所指定的佇列。

在擷取回應訊息時,依預設連接器會比對回應的 correlationID 與要求訊息的 messageID。 然後,連接器會通知發出要求的執行緒。依據回應的回饋欄位,連接器會預期訊息主體中包含商業物件或錯誤訊息。若原預期為商業物件,但訊息主體中並未輸入資料,則連接器只是傳回 InterChange Server 最初發出的相同商業物件來滿足「要求」作業。若原預期為錯誤訊息,但訊息主體中並未輸入資料, 則一般錯誤訊息伴隨著回應碼會傳回至 InterChange Server。 然而,您還可以使用訊息選取元,以識別、過濾或控制配接器如何為給定的要求識別回應訊息。此訊息選取元功能是一個 JMS 特性。它僅應用於同步的處理程序,說明如下。

Retrieve、exists 及 retrieve by content

具有 Retrieve、Exists 及 Retrieve By Content 動詞的商業物件僅支援同步遞送。連接器處理這些動詞的商業物件,就如同處理 create、update 及 delete 定義的同步遞送一樣。 然而,使用 Retrieve、Exists 及 Retrieve By Content 動詞時,responseTimeoutreplyToQueue 是必要的。 再者,對於 Retrieve By Content 和 Retrieve 動詞,訊息主體中必須輸入序列化的商業物件才能完成交易。

表 6 顯示這些動詞的回應訊息。

表 6. 回應訊息的個體群
動詞 回饋欄位 訊息主體
Retrieve 或 RetrieveByContent

FAIL FAIL_RETRIEVE_BY_CONTENT

(選用)錯誤訊息。

MULTIPLE_HITS SUCCESS

已序列化的商業物件。
Exist

FAIL

(選用)錯誤訊息。

SUCCESS


事件處理程序

圖 3 解說連接器事件處理程序。pollForEvents() 方法從輸入佇列中擷取下一個可用的訊息。

訊息將堆積於進行中佇列內,直到處理完成為止。

使用連接器 Meta 物件時,連接器首先會判斷訊息類型是否受支援。 若受支援,連接器會將訊息傳送至已配置的資料處理常式, 由這個處理常式將訊息轉換成商業物件。已設定的動詞會反映針對訊息類型所建立的轉換內容。 然後,連接器再判斷商業物件是否被協同作業所訂閱。若有訂閱,gotApplEvents() 方法會將商業物件遞送至整合分配管理系統, 且進行中佇列會移除訊息。

在事件通知方面,配接器會偵測應用程式而非資料庫觸發所寫入佇列中的事件。當應用程式或其他可啟用 MQ 的軟體產生 WebSphere MQ 訊息並將它們儲存在 MQ 訊息佇列上時,便會發生事件。

圖 3. 應用程式與連接器的通訊方法:訊息回傳


擷取

連接器使用 pollForEvents() 方法來定期輪詢 MQ 佇列中的訊息。

當連接器找到訊息時, 就從 MQ 佇列中擷取訊息並查驗以判斷其格式。如果在連接器 Meta 物件中已定義格式,連接器會使用資料處理常式, 來產生具有動詞的適當商業物件。有關於事件失敗情況,請參閱"錯誤處理概觀"

連接器在處理訊息時,首先會開啟對輸入佇列的交易式階段作業。若連接器順利地送出商業物件,但無法確定佇列中的交易, 則可能導致商業物件遞送兩次到協同作業,而此交易式方法可儘量避免這種情形。為避免此問題,連接器將所有訊息移至進行中佇列。

訊息保留於此處,直到處理完成為止。 如果連接器在處理期間非預期地關閉,則訊息會保留在進行中佇列內,而不會復原到原始的輸入佇列中。

註:
對 JMS 服務提供程式的交易式階段作業需要先執行並確定佇列上每一個所要求的動作, 才能夠從佇列中移除事件。因此,當連接器從佇列擷取訊息時,在發生下列三件事之前並不會確定擷取: 1) 訊息已轉換成商業物件;2) 商業物件已由 gotApplEvents() 方法遞送至 InterChange Server;3) 收到回覆值。

回復

在起始設定時,連接器會檢查進行中佇列是否有尚未完全處理的訊息 (假設是由於連接器關閉所造成)。連接器配置內容 InDoubtEvents 可讓您指定四種選項的其中一種來處理這些訊息的復原: 啟動時失敗、重新處理、忽略、記載錯誤。

啟動時失敗

透過啟動時失敗選項,若連接器於起始設定期間發現進行中佇列含有訊息,則記載錯誤並立即關閉。使用者或系統管理者有責任查驗訊息並採取適當的動作, 不論是完全刪除這些訊息,或移至不同的佇列。

重新處理

透過重新處理選項,如果連接器在起始設定期間發現進行中佇列含有任何訊息,則會在後續的輪詢期間優先處理這些訊息。當進行中佇列內的所有訊息皆已處理完畢時,連接器就開始處理輸入佇列中的訊息。

忽略

透過忽略選項,如果連接器在起始設定期間發現進行中佇列含有任何訊息,連接器將忽略它們,但不會關閉。

記載錯誤

透過記載錯誤選項,如果連接器在起始設定期間發現進行中佇列含有任何訊息,則會記載錯誤,但不關閉。

保存

如果已指定連接器特有內容 ArchiveQueue,且識別有效的佇列,則連接器會將所有順利處理的訊息複本放入保存佇列中。

如果未定義 ArchiveQueue,則訊息在處理之後就會捨棄。 如需保存未訂閱或錯誤訊息的詳細資訊, 請參閱"錯誤處理概觀"

註:
根據 JMS 使用慣例,擷取的訊息無法立即送到另一個佇列。 為了保存和重新遞送訊息,連接器會先產生第二個訊息,這個訊息會複製原始訊息的主體和標頭 (如果有的話)。為了避免與 JMS 服務提供程式發生衝突,僅重複 JMS 必要的欄位。因此,對於要保存或重新遞送的訊息,format 欄位是唯一會複製的額外訊息內容。

Copyright IBM Corp. 1997, 2004