Flex Gateway新着情報
Governance新着情報
Monitoring API ManagerJMS Connector には、いくつかの異なる肯定応答設定があります。
AUTO ackMode
を ibm-mq:listener
コンポーネントで使用することにより、フローの実行が正常に完了した場合に限って、受信したメッセージが自動的に肯定応答されます。
フロー実行中にエラーが発生して早期に終了した場合、メッセージは肯定応答されず、再配信が行われます。
AUTO
と似たもう一つの ackMode
に DUPS_OK
があります。DUPS_OK
を使用すると、フロー実行が正常に完了した時点で自動的にメッセージが肯定応答されますが、処理がゆっくり行われるため、肯定応答を待たずにメッセージが再配信されてしまい、重複が発生する可能性があります。
ibm-mq:listener
または ibm-mq:consume
のいずれかの操作で ackMode
を IMMEDIATE
に設定すると、メッセージがコンシュームされたらすぐに、アプリケーションによってメッセージの処理が行われる前に自動的に肯定応答されます。
メッセージの受信後に自動的に肯定応答すると、メッセージの処理中にエラーが発生してもメッセージが再配信されないため、デッドレターキューのようなアプリケーションロジックを作成して、メッセージを失わずにエラーを処理する必要があります。
ご推察の通り、MANUAL
ackMode
は、メッセージの肯定応答の責任をすべてアプリケーションロジックに委ねます。
この設定を使用すると、listener
または consume
のいずれかの操作で受信したすべてのメッセージでは Mule メッセージ attributes
に ackId
が含まれています。メッセージはそれによって特定の接続で一意に識別されます。
メッセージを識別する ackId
は ibm-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>
以前と同じように、セッションのリカバリーに使用する接続は、メッセージを受信したときに使用した接続と同じでなければなりません。