當 MQ Workflow UPES
將要求公佈至連接器輸入佇列時,會發生事件。連接器輪詢輸入佇列來偵測事件。本節說明「事件處理」程序。
偵測到事件之後,連接器會執行以下所述的步驟。
- 連接器將 XML 訊息載入 DOM 剖析器。
- 連接器驗證出這是 WfMessage 並檢查辨識的範本。
- 識別訊息中包含的輸入資料結構之後,連接器會建立類型為
<boprefix><資料結構名稱>
的商業物件。例如,如果連接器配置內容 boprefix 的值為
WfRequest_, 且連接器收到包含名為 MyCustomer
之資料結構的訊息,則連接器會預期該結構符合最上層商業物件
WfRequest_MyCustomer 的子項。連接器使用 XML 資料處理常式,將 XML
資料結構轉換成商業物件。
- 連接器在 WfMessage 中尋找元素 ProgramParameters。ProgramParameters
欄位包含使用者在實際 MQ Workflow 中指定的應用程式參數。
- 如果未對資料處理常式建立的商業物件指定動詞,則連接器會使用要求訊息之
ProgramParameters 部分中指定的資料來設定動詞。
- 為判斷 MQ Workflow 是否預期其要求有回應,連接器會評估 XML 文件之儲存區
WfMessageHeader 中的元素 ResponseRequired, 以取得值
yes、no 或 iferror。值 yes 指出 MQ
Workflow 正積極等待來自連接器的回應訊息, 提供要求狀態的資訊。
- 註:
- ResponseRequired 元素對應至「MQ Workflow 建置時期」配置之程式活動內容中的模式
(請參閱圖 22 中的「定義工作流程伺服器」)。如果您指定非同步模式,則
ResponseRequired=no;如果您指定同步模式,則
ResponseRequired=yes。
- 如果預期回應 (ResponseRequired=yes),則連接器會評估指定在
WfMessage 中 ProgramParameters 元素內的資料,以決定如何處理要求。
- 如果協同作業是指定在 ProgramParameters 中,則連接器會使用
executeCollaboration()
方法將要求傳送至協同作業。因為此方法是協同作業的同步要求,
因此從方法呼叫傳回可能需要點時間。方法會使用其引數傳回回應物件。連接器會輸入回應物件以產生回應訊息,然後將回應傳送至
MQ Workflow 伺服器。
- 如果未在 ProgramParameters 中指定協同作業,則連接器會使用 gotApplEvent()
方法將要求公佈至所有的訂閱協同作業。連接器將包含「MQ Workflow 活動」資訊 (如
ActImplCorrelID) 的 Meta 物件,輸入 gotApplEvent()
方法之引數中顯示的商業物件。該方法將要求公佈至協同作業,
以便連接器能立即收到方法呼叫的傳回。因為方法呼叫未傳回回應物件,所以就不會產生回應訊息或將回應訊息傳送至
MQ Workflow 伺服器。相反地,
協同作業必須使用服務呼叫要求,將對應的回應物件傳送至 MQ Workflow
伺服器。回應物件必須包括包含「MQ Workflow 活動」資訊 (如 ActImplCorrelID) 的
Meta
物件。然後,連接器會根據服務呼叫要求來建構適當的回應訊息。回應訊息包含「MQ
Workflow 活動」資訊、協同作業的回覆碼及回應商業物件。回應訊息會傳送至 MQ
Workflow 伺服器。如果因與訊息之商業內容不相關的問題而在上述步驟 8 或 9
發生錯誤,則連接器會記載錯誤且不產生回應 WfMessage。
- 訊息會選擇性地保存在保存、錯誤或未訂閱的佇列中。
連接器會定期輪詢其輸入佇列,以取得訊息。當連接器找到訊息時,會從佇列中擷取該訊息,並傳遞至
DOM 剖析器與 XML 資料處理常式,以取得 WfMessage 內容。連接器使用從
WfMessage
擷取的資料結構,來產生具有動詞的適當商業物件。有關事件失敗情況,請參閱"錯誤處理"。
連接器在處理訊息時,首先會對輸入佇列開啟交易式階段作業。若連接器順利地送出商業物件,但無法確定佇列中的交易,
則可能導致商業物件遞送兩次到協同作業,此交易式方法便可儘量避免這種情形。
為避免此問題,連接器將所有訊息移至進行中佇列。訊息保留於此處,直到處理完成為止。
如果連接器在處理期間非預期地關閉,則訊息會保留在進行中佇列內,而非復原到原始的輸入佇列中。
- 註:
- 發生下列事件之前,連接器不會將訊息從進行中佇列移除:1)
訊息已轉換成商業物件 2) 商業物件遞送至 InterChange Server,以及 3)
收到回覆值。
在起始設定時,連接器會檢查進行中佇列是否有尚未處理完全的訊息
(假設是由於連接器關閉所造成)。連接器配置內容 InDoubtEvents
可讓您指定四種選項的其中一種來處理這些訊息的復原:
啟動時失敗、重新處理、忽略、記載錯誤。
如果是 FailOnStartup
選項,如果連接器在起始設定期間發現進行中佇列含有訊息,則它會記載錯誤並立即關閉。使用者或系統管理者要負責查驗訊息並採取適當的動作,
可以選擇是完全刪除這些訊息,或是將其移至另一個佇列。
如果是重新處理選項,如果連接器在起始設定期間發現進行中佇列含有任何訊息,則會在後續的輪詢期間優先處理這些訊息。當進行中佇列內的所有訊息皆已處理完畢時,連接器就開始處理輸入佇列中的訊息。
忽略選項,如果連接器在起始設定期間發現進行中佇列含有任何訊息,連接器會忽略該訊息,但不會關閉。它會開始處理輸入佇列中的訊息。
透過記載錯誤選項,如果連接器在起始設定期間發現進行中佇列含有任何訊息,則會記載錯誤,但不關閉。它會開始處理輸入佇列中的訊息。
如果已指定連接器內容
ArchiveQueue,且其識別有效的佇列,則連接器會將所有順利處理的訊息複本放入保存佇列中。如果未定義
ArchiveQueue,則在訊息順利處理完成後即會將之捨棄。如需保存未訂閱或錯誤訊息的詳細資訊,請參閱開發商業物件的錯誤處理。
