メッセージ肯定応答の処理

JMS コネクタには、いくつかの異なる肯定応答設定があります。

成功時の自動肯定応答

AUTO ackModeibm-mq:listener コンポーネントで使用することにより、フローの実行が正常に完了した場合に*限って*、受信したメッセージが自動的に肯定応答されます。 フロー実行中にエラーが発生して早期に終了した場合、メッセージは肯定応答されず、再配信が行われます。

AUTO と似たもう一つの ackModeDUPS_OK があります。DUPS_OK を使用すると、フロー実行が正常に完了した時点で自動的にメッセージが肯定応答されますが、処理がゆっくり行われるため、肯定応答を待たずにメッセージが再配信されてしまい、重複が発生する可能性があります。

即時の肯定応答

ibm-mq:listener または ibm-mq:consume 操作で ackModeIMMEDIATE に 設定すると、メッセージがコンシュームされた時点で、アプリケーションによるメッセージの処理が行われる前に、自動的に肯定応答されます。 メッセージの受信後に自動的に肯定応答すると、メッセージの処理中にエラーが発生してもメッセージが再配信されないため、デッドレターキューのようなアプリケーションロジックを作成して、メッセージを失わずにエラーを処理する必要があります。

手動肯定応答

ご推察の通り、MANUAL ackMode は、メッセージの肯定応答の責任をすべてアプリケーションロジックに委ねます。

この設定では、listener または consume 操作で受信したすべてのメッセージが Mule メッセージ attributesackId を持ち、 このメッセージを特定の接続において一意に識別します。

メッセージを識別する ackIdibm-mq:ack 操作に渡されます。

<flow name="consumerWithManualAck">
    <ibm-mq:consume config-ref="JMS_config" destination="openTickets" ackMode="MANUAL"/>

    <!--Do message processing-->
    <logger message="#[payload]">

    <ibm-mq:ack ackId="#[attributes.ackId]"/>
</flow>

手動セッションリカバリ

MANUAL ackMode を使用した場合、ブローカーは、受信されていても肯定応答されていないすべてのメッセージを再配信しません。 メッセージの処理中にエラーが発生して肯定応答ができない場合は、ユーザが recover-session 操作を使用して、再配信する必要のあるセッション中のすべてのメッセージを手動でリカバリする責任を負います。

<flow name="consumerWithManualAck">
    <ibm-mq:consume config-ref="JMS_config" destination="${destination}"
                 ackMode="MANUAL" target="consumedMessage" targetValue="#[message]"/>

    <!--Do message processing-->
    <logger message="#[payload]">

    <ibm-mq:ack ackId="#[vars.consumedMessage.attributes.ackId]"/>

    <error-handler>
        <on-error-propagate>
            <!--In case of error, recover the session-->
            <ibm-mq:recover-session ackId="#[vars.consumedMessage.attributes.ackId]"/>
        </on-error-continue>
    </error-handler>
</flow>

以前と同じように、セッションのリカバリに使用する接続は、メッセージを受信したときに使用した接続と同じでなければなりません。

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub