Flex Gateway新着情報
Governance新着情報
Monitoring API ManagerFlex Gateway新着情報
Governance新着情報
Monitoring API Manager2.x
Mule 4
3.9
1.1
2.x
1.2
7.x
3.0 (Mule 4)
3.9 (Mule 3)
1.0 (Mule 4)
1.3 (Mule 4)
1.0 (Mule 4)
1.0 (Mule 4)
2.2 (Mule 4)
1.0 (Mule 4)
1.0 (Mule 4)
1.0 (Mule 4)
1.0 (Mule 4)
3.0 (Mule 4)
1.0 (Mule 4)
1.0 (Mule 4)
1.0 (Mule 4)
1.0 (Mule 4)
3.9 (Mule 3)
1.0 (Mule 4)
1.1 (Mule 4)
6.0 (Mule 4)
2.3 (Mule 4)
3.9 (Mule 3)
1.0 (Mule 4)
1.2 (Mule 4)
3.9 (Mule 3)
1.0 (Mule 4)
1.0 (Mule 4)
2.0 (Mule 4)
3.2 (Mule 4)
2.1 (Mule 4)
1.0 (Mule 4)
3.9 (Mule 3)
3.9 (Mule 3)
3.9 (Mule 3)
1.0 (Mule 4)
1.0 (Mule 4)
3.0 (Mule 4)
1.0 (Mule 4)
1.1 (Mule 4)
3.1 (Mule 4)
3.9 (Mule 3)
3.9 (Mule 3)
1.0 (Mule 4)
1.0 (Mule 4)
1.0 (Mule 4)
3.9 (Mule 3)
1.1 (Mule 4)
1.0 (Mule 4)
1.2 (Mule 4)
1.3 (Mule 4)
1.0 (Mule 4)
3.9 (Mule 3)
1.0 (Mule 4)
2.0 (Mule 4)
1.2 (Mule 4)
2.0 (Mule 4)
1.0 (Mule 4)
3.9 (Mule 3)
1.0 (Mule 4)
1.0 (Mule 4)
メッセージ肯定応答の管理
メッセージ肯定応答の管理
JMS 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>
xml
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>
xml
以前と同じように、セッションのリカバリーに使用する接続は、メッセージを受信したときに使用した接続と同じでなければなりません。