關於 Error Handler 範例

Error Handler 範例係以需要處理交易的企業想要開發錯誤處理常式的實務為基礎。這個範例示範如何使用 IBM Integration Bus 中所提供的某些特性。

銀行之類的企業要確定交易會被處理且只會處理一次，且如果發生任何錯誤，都會有相關記錄。在 Error Handler 範例中，您會將員工編號相關的訊息放到訊息流程中，該訊息流程會以這項資訊更新資料庫。如果您放置的是具有無效之員工編號的訊息，您就可以觀察錯誤處理常式如何運作。

Error Handler 範例會示範下列作業：

如何使用錯誤處理常式來設陷錯誤的相關資訊，並將該資訊儲存在 WebSphere MQ 佇列上。範例中所使用的錯誤處理常式是一個子流程，不需變更即可新增至任何訊息流程中。
如何配置訊息流程來控制交易功能。特別是，這個範例會示範如何使用全面協調的交易來確保整體資料的完整性，其乃在 z/OS 上預設的作業模式。在分散式平台上，全面協調需要特定的配置步驟，並利用 XA 通訊協定來實作。
在本例中，範例中的主訊息流程會以員工編號的相關資訊更新資料庫。錯誤處理子流程會在佇列發生處理程序錯誤的位置輸出任何訊息。主流程中的資料庫更新作業係在交易式控制之下，因此如果發生錯誤，且訊息係由錯誤處理子流程來處理，則和員工編號相關的資料庫更新作業就會回復而不會確定。錯誤處理常式子流程中的佇列更新作業係位於交易式控制之外，以確保錯誤的相關資訊不會回復，因為該資訊必須確定以提供錯誤記錄。

訊息

這裡提供兩個輸入訊息，以供執行 Error Handler 範例使用：

一個訊息包含有效的員工序號
一個訊息包含無效的員工序號

有效的員工訊息會顯示在下列的 XML 程式碼中：

<Staff>
   <StaffNumber>1</StaffNumber>
   <NameInfo>
      <LastName>Smith</LastName>
      <FirstName>Jack</FirstName>
   </NameInfo>
</Staff>

無效的員工訊息會顯示在下列的 XML 程式碼中：

<Staff>
   <StaffNumber>99</StaffNumber>
   <NameInfo>
      <LastName>Doe</LastName>
      <FirstName>Jane</FirstName>
   </NameInfo>
</Staff>

訊息流程

下列圖解顯示主訊息流程。

主訊息流程的畫面擷取

下列圖解顯示錯誤處理子流程。

錯誤處理子流程的畫面擷取

下表列出 Error Handler 範例中所使用的節點類型。Subflow 節點在技術上並不是節點，而且也不在節點選用區中；Subflow 節點代表在主訊息流程中呼叫 Error_Handler.msgflow 子流程的位置。

節點類型	節點名稱
MQInput	STAFF_IN
MQOutput	STAFF_FAIL; STAFF_OUT; STAFF_UPDATE_ERROR
Compute	Copy Message; Create Message for Output
Filter	Check Valid Staff Number; Check Backout Count
Throw	Throw; Throw to Complete Rollback
TryCatch	TryCatch
Subflow	Error_Handler

如需相關資訊，請參閱 IBM Integration Bus 文件中的內建節點與使用子流程。

有效員工訊息所採取的路徑

當您將有效的員工訊息放到輸入佇列時，該訊息會在節點中傳送。如果停用任何佇列，則該訊息無法遵循這個路徑。

在主訊息流程中：
1. STAFF_IN 節點。這個節點會從輸入佇列中取得輸入訊息。
2. Error_Handler 節點。這個節點代表錯誤處理子流程。訊息會離開主訊息流程，並進入子流程。
在子流程中：
1. Start Subflow 節點。訊息會傳給流程中的下一節點。
2. Check Backout Count 節點。這個節點會檢查取消次數是否為零。因為這是輸入訊息第一次透過這個節點傳遞，所以這個次數目前為零，且訊息會傳給下一節點。如果次數大於零，訊息會被捨棄。
3. TryCatch 節點。由於員工編號是有效的，因此訊息會傳給 Back To Main Flow 節點。如果訊息中的員工編號無效，且訊息的處理程序已發現這個無效的員工編號，則訊息會傳遞至 Copy Message 與 STAFF_UPDATE_ERROR 節點。
4. Back To Main Flow 節點。訊息會離開子流程，並回到主訊息流程。
在主訊息流程中：
1. Check Valid Staff Number 節點。由於員工編號是有效的，因此訊息會傳給 Update Staff Database 節點。
2. Update Staff Database 節點。STAFFDB 資料庫會以訊息中的員工詳細資料來更新。
3. STAFF_OUT 節點。這個節點會將訊息放在 STAFF_OUT 佇列上。
4. 如果您沒有資料庫，則訊息仍會透過 Failure 端放到佇列上。這個實務是在不使用資料庫的情況下示範此範例，不可用於正式作業。

無效員工訊息所採取的路徑

當您將無效的員工訊息放到輸入佇列時，該訊息會在節點中傳送，如本節稍後所述。如果停用任何佇列，則該訊息無法遵循這個路徑。如需每一個節點作用為何的相關資訊，請參閱 IBM Integration Bus 文件中的內建節點。

在主訊息流程中：
1. STAFF_IN 節點。這個節點會從輸入佇列中取得輸入訊息。
2. Error_Handler 節點。這個節點代表錯誤處理子流程。訊息會離開主訊息流程，並進入子流程。
在子流程中：
1. Start Subflow 節點。訊息會傳給流程中的下一節點。
2. Check Backout Count 節點。這個節點會檢查取消次數是否為零。因為這是輸入訊息第一次透過這個節點傳遞，所以這個次數目前為零，且訊息會傳給下一節點。請比較本節稍後的步驟 5b。
3. TryCatch 節點。訊息中的員工編號是無效的，但尚未被發現。輸入訊息會傳給 Back To Main Flow 節點，而非 STAFF_UPDATE_ERROR 節點。
4. Back To Main Flow 節點。訊息會離開子流程，並回到主訊息流程。
在主訊息流程中：
1. Check Valid Staff Number 節點。由於員工編號是無效的，因此訊息會傳給 Throw 節點，而非 Update Staff Database 節點。
2. Throw 節點。這個節點會停止訊息的處理程序，並將錯誤碼 "3001" 和文字「員工編號無效」5記錄到訊息內容中。系統會回復訊息，也就是說，訊息會傳送回控制點，在本例中，就是子流程中的 TryCatch 節點。
在子流程中：
1. TryCatch 節點。這個節點會識別出訊息的處理程序中發生異常狀況，並將訊息傳遞給 STAFF_UPDATE_ERROR 節點。
2. STAFF_UPDATE_ERROR 節點。訊息會傳送到 STAFF_UPDATE_ERROR 佇列。
3. Throw To Complete Rollback 節點。這個節點會停止訊息的處理程序，並將號碼 "3002" 和文字「來自 Error_Handler 訊息流程。」記錄到訊息內容中。這時訊息會傳送回控制點，也就是主訊息流程中的 STAFF_IN 節點。
  這個階段是捕捉處理程序的最終階段。它的影響是回復整個交易，包括原始嘗試路徑中交易式控制下的資料庫更新（亦即，主流程中的 STAFFDB 更新）。可是，在交易式控制之外的 STAFF_UPDATE_ERROR 更新仍然受到確定。
在主訊息流程中：
1. STAFF_IN 節點。因為訊息的處理程序中發生異常狀況，所以訊息會傳遞至 STAFF_FAIL 節點，而非再度傳到訊息流程中。
2. STAFF_FAIL 節點。這個節點會將訊息放在 STAFF_FAIL 佇列上。另外，如果 STAFF_FAIL 佇列已停用，訊息就不會停在這裡。訊息會傳回到 STAFF_IN 節點，然後傳到子流程。接著，訊息會到達 Check Backout Count 節點，其會檢查取消次數是否為零。因為訊息先前已傳經這個節點，因此取消次數不再是零，且該訊息會被捨棄。捨棄這個訊息可避免一種情況，那就是如果 STAFF_FAIL 佇列已停用，訊息會持續在流程中傳送。將此步驟與步驟 2b 做比較。

當您使用 TryCatch 節點時，或當您將節點連接到 MQInput 節點的 Catch 端時，如果節點配置正確，您可能會假設如果呼叫捕捉路徑，則不會確定發生在該嘗試路徑上的任何處理程序。這個假設是不正確的。比方說，如果資料庫是在交易式控制之下的嘗試路徑中更新，且呼叫的捕捉路徑正常完成，則資料庫更新仍會受到確定。

本例中的需求是讀取一個訊息、更新資料庫，並將訊息寫入另一個佇列中。如果發生錯誤，就會回復資料庫更新。捕捉處理程序會以錯誤的詳細資料更新錯誤資料庫，並將原始訊息寫入失敗佇列。以程式設計方面來看，下列範例顯示發生的過程：

BEGIN (Start 'outer' unit-of-work.)
MQGET (Get message from the input queue.)
TRY
   BEGIN (Start 'inner' unit-of-work.)
   Update database
   MQPUT (Put message onto the output queue.)
   IF ERROR
      ROLLBACK inner unit-of-work GO TO CATCH
   ELSE
      COMMIT inner and outer unit-of-work as one unit-of-work
   END IF
CATCH
   Send message to STAFF_UPDATE_ERROR queue
   MQPUT (Put message onto the failure queue.)
   COMMIT outer unit-of-work

可是，「XA 交易管理程式」和 WebSphere MQ 不支援同一應用程式中有兩層的工作單元。因此，Error Handler 範例會使用下列結構：

嘗試路徑中的資料庫 STAFFDB 更新是在交易式控制之內。
捕捉路徑中的佇列 STAFF_UPDATE_ERROR 更新是在交易式控制之外。
MQInput 節點的 Failure 端連接到指向失敗佇列的 MQOutput 節點。
捕捉處理程序的最終階段是使用 Throw 節點再度產生錯誤。
接著訊息會沿著失敗路徑回復到 MQInput 節點，再從該處回復到失敗佇列。

如需相關資訊，請參閱 IBM Integration Bus 文件中的訊息流程交易。

回到範例首頁