訊息確認通知

每一個未交易的階段作業都有確認通知模式，可決定如何確認應用程式收到的訊息。 有三種確認模式可用，而選擇確認模式會影響應用程式的設計。

只有在應用程式連接至 IBM® MQ 佇列管理程式或 WebSphere® Application Server 服務整合匯流排時，本主題中的資訊才相關。 此資訊與分配管理系統的即時連線無關。

XMS 使用相同的機制來確認 JMS 使用的訊息接收。

如果階段作業未進行交易，則由階段作業的確認模式決定應用程式收到訊息的確認方式。 下列段落說明三種確認模式:

XMSC_AUTO_認可

階段作業會自動確認應用程式收到的每一則訊息。

如果訊息同步遞送至應用程式，階段作業會在每次「接收」呼叫順利完成時確認收到訊息。

如果應用程式順利接收訊息，但失敗阻止確認通知發生，則訊息會再次變成可供遞送。 因此，應用程式必須能夠處理重新遞送的訊息。

XMSC_DUPS_OK_認可

階段作業會確認應用程式在選取時所收到的訊息。

使用此確認模式可減少階段作業必須執行的工作量，但阻止訊息確認的失敗可能會導致多個訊息重新可供遞送。 因此，應用程式必須能夠處理重新遞送的訊息。

XMSC_CLIENT_認可

應用程式會呼叫 Message 類別的 Acknowledge 方法來確認它收到的訊息。

應用程式可以個別確認接收每一個訊息，或者它可以接收一批訊息，並僅針對它接收的最後一個訊息呼叫 Acknowledge 方法。 當呼叫 Acknowledge 方法時，會確認自前次呼叫方法以來收到的所有訊息。

與任何這些確認模式一起使用時，應用程式可以透過呼叫「階段作業」類別的「回復」方法，停止並重新啟動階段作業中的訊息遞送。 重新遞送其回執先前未確認的訊息。 不過，它們可能不會以先前遞送的相同順序來遞送。 同時，較高優先順序的訊息可能已到達，部分原始訊息可能已過期。 在點對點網域中，部分原始訊息可能已由另一個應用程式耗用。

應用程式可以檢查訊息的 JMSRedelivered 標頭欄位內容，來判斷訊息是否正在重新遞送。 應用程式透過呼叫 Message 類別的 Get JMSRedelivered 方法來執行此動作。