配接器依據每一個商業物件的動詞來處理協同作業實例傳送給它的商業物件。 配接器使用商業物件處理常式和 doForVerb() 方法來處理配接器支援的商業物件。 配接器支援下列商業物件動詞:
對於搭配 create、update 及 delete 動詞的商業物件, 其處理程序視物件是同步或非同步發出而定。
對於搭配 create、update 及 delete 動詞的商業物件,其預設的遞送模式為非同步。 訊息是透過資料處理常式從商業物件中建立,然後寫入輸出佇列中。 若訊息順利遞送,則配接器傳回 BON_SUCCESS,否則傳回 BON_FAIL。
若連接器內容中已定義 replyToQueue,且 ResponseTimeout 存在於商業物件的轉換內容中,則配接器會以同步模式來發出要求。 然後,配接器將等待回應以驗證 WebSphere Commerce 已採取適當的動作。
配接器最初發出的訊息含有表 1 顯示的標頭。
欄位 | 說明 | 值 |
---|---|---|
Format
|
格式名稱
|
轉換內容中所定義的輸出格式,並截斷成 8 個字元以符合 IBM 基本需求
(例如:MQSTR)
|
MessageType
|
訊息類型
| MQMT_DATAGRAM* |
Report
|
所要求之報告訊息的選項。
|
當預期為回應訊息時,此欄位中輸入的值如下所示: MQRO_PAN* 表示如果順利處理,則需要正面動作的報告。 MQRO_NAN* 表示如果處理失敗,則需要負面動作的報告。 MQRO_COPY_MSG_ID_TO_CORREL_ID* 表示已產生之報告的相關
ID 應該等於最初所發出之要求的訊息 ID。
|
ReplyToQueue
|
回覆佇列的名稱
|
當預期為回應訊息時,此欄位中會輸入連接器內容 ReplyToQueue 的值。
|
Persistence
|
訊息持續性
|
MQPER_PERSISTENT*
|
Expiry
|
訊息生命週期
|
MQEI_UNLIMITED*
|
* 表示 IBM 所定義的常數。
|
表 1 所說明的訊息標頭後面接著訊息主體。 訊息主體為已透過資料處理常式來序列化的商業物件。
Report 欄位的設定指出預期從 WebSphere Commerce 傳回正面和負面的動作報告。 發出訊息的執行緒將等待回應訊息,此回應訊息指出 WebSphere Commerce 是否能夠處理要求。
當 WebSphere Commerce 收到來自配接器的同步要求時,
就處理商業物件的資料,並發出表 2、表 3 及表 4 說明的報告訊息。
欄位 | 說明 | 值 |
---|---|---|
Format
|
格式名稱
|
轉換內容中所定義的 busObj 輸入格式。
|
MessageType
|
訊息類型
|
MQMT_REPORT*
|
* 表示 IBM 所定義的常數。
|
動詞 | 回饋欄位 | 訊息主體 |
---|---|---|
Create、Update 或 Delete
|
SUCCESS VALCHANGE
|
(選用)反映變更的序列化商業物件。
|
|
VALDUPES FAIL
|
(選用)錯誤訊息。
|
表 4. WebSphere MQ 回饋碼及 ICS 回應值
WebSphere MQ 回饋碼 | 同等的 ICS 回應* |
---|---|
MQFB_PANor MQFB_APPL_FIRST
|
SUCCESS
|
MQFB_NAN或 MQFB_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(導致立即終止連接器)
|
MQFB_NONE
|
當回應訊息中未指定回饋碼時,連接器所接收的回應
|
* 詳細資料請參閱 Connector Development Guide。
|
若可處理商業物件,則應用程式會建立報告訊息, 並將回饋欄位設為 MQFB_PAN(或特定的 ICS 值)。 (可選用的)應用程式將於訊息主體中輸入含有任何變更的序列化商業物件。 若無法處理商業物件,應用程式則會建立報告訊息, 並將回饋欄位設為 MQFB_NAN(或特定的 ICS 值), 然後在訊息主體中選擇性地併入錯誤訊息。 於任何一種情況下,應用程式會將訊息的 correlationID 欄位設為配接器訊息的 messageID,並發出至 replyTo 欄位所指定的佇列。
在擷取回應訊息時,配接器會比對回應的 correlationID 與要求訊息的 messageID。 然後,配接器會通知發出要求的執行緒。 依據回應的回饋欄位,配接器會預期訊息主體中包含商業物件或錯誤訊息。 若原預期為商業物件,但訊息主體中並未輸入資料,則配接器只是傳回 InterChange Server 最初發出的相同商業物件來滿足「要求」作業。 若原預期為錯誤訊息,但訊息主體中並未輸入資料, 則一般錯誤訊息伴隨著回應碼會傳回至 InterChange Server。
您可指定連接器內容 FeedbackCodeMappingMO,延伸 WebSphere MQ 回饋碼來置換表 4 中顯示的預設解譯。 這個內容可使您建立一個 meta 物件,其中所有特定 ICS 傳回狀態值皆對映至 WebSphere MQ 回饋碼。
指定給回饋碼的傳回狀態會傳送至 InterChange Server。 如需詳細資訊,請參閱"FeedbackCodeMappingMO"。
搭配 retrieve、exists 及 retrieve by content 動詞的商業物件僅支援同步遞送。 連接器處理這些動詞的商業物件,就如同處理 create、update 及 delete 定義的同步遞送一樣。 然而,使用 retrieve、exists 及 retrieve by content 動詞時, responseTimeout 和 replyToQueue 是必要的。 再者,對於 retrieve 和 retrieve by content 動詞, 訊息主體中必須輸入序列化商業物件才能完成交易。
表 5 顯示這些動詞的回應訊息。
動詞 | 回饋欄位 | 訊息主體 |
---|---|---|
Retrieve 或 RetrieveByContent
|
FAIL FAIL_RETRIEVE_BY_CONTENT
|
(選用)錯誤訊息。
|
|
MULTIPLE_HITS SUCCESS
|
已序列化的商業物件。
|
Exist
|
FAIL
|
(選用)錯誤訊息。
|
|
SUCCESS
|
|