そこで、処理セグメント間のバッキング ストアとして SQS を使用して、いくつかの短いフローを作成しました。基本的な流れは次のとおりです。
RestController -> SQS Queue1 OCA
SQS Queue1 MDCA -> Service-Adapter -> SQS Queue2 OCA
SQS Queue2 MDCA -> Service Adapter
ただし、いくつかの問題が発生しました...「SQS Queue1 MDCA」は、AWS 固有のメッセージヘッダーを使用してキューからメッセージを読み取り、キュー 2 に書き込む送信アダプターに到達します。これらのメッセージ ヘッダーは、AWS_queue 名、aws メッセージ ID などを指定し、メッセージが queue1 に再配信されるようにします。
これらのヘッダーを除外すると (単純なカスタム トランスフォーマーを使用してこれをテストしました)、outbound-channel-adapter の属性が期待どおりに機能し、QueueMessagingTemplate がメッセージを適切なキューに配信します。
そこで、spring-int と spring-aws の専門家への私の質問は、「既存の SQS ヘッダーを除外して、ダウンストリームの SQS 処理によって検出されないようにする適切な場所はどこだと思いますか?」というものです。基本的な spring-aws-messaging 呼び出しに関連する可能性があるため、SQSHandler でそれを実行したいと思うように思えます。
補足として、メッセージが SQS ICA から作成され、オブジェクトから json へのトランスフォーマーがフローに含まれているため、12 個のメッセージ ヘッダーが作成されました。これは、SQS で許可されている数よりも 2 個多い (メッセージ配信失敗する）。
無実のキューを保護するためにヘッダーがわずかに変更されたサンプルメッセージ...ご覧のとおり、aws_queue、宛先などが「wrench_workflow-mjg」から読み取られないようにメッセージ内に残っているため、次のキューに配信しようとすると、ヘッダーは spring-int xml 構成の構成を上書きし、次のキューに配信されませんでした。メッセージは、SQS キュー「wrench_workflow-mjg」を循環し続けました (10 を超える属性の問題を修正した後)。
GenericMessage [payload={"eventId":"event-1","eventStartDateTime":1476127827.201000000},
headers={aws_messageId=db9b6cc0-f133-4182-b79c-4d5d9717a3a9, ApproximateReceiveCount=1,
SentTimestamp=1476127827803, id=0b662b72-f149-a970-5e63-64a1b28290fb,
SenderId=AIDAJOYV7TECZCZCOK22C,
aws_receiptHandle=AQEBdaToWo9utbjBwADeSuChX/KrY3l8eoSBMZ0RMmbI8ewjJQw6tV74RwSYxWPKZBSzgJhCmfJ8AUX+
reOy2yGrmefULU7NS8nqYTdMW6BB4Ug2+mHIY+8Tze+2ws15FB5t96q3iJO8+tP5pl/xuo+CiTDv+
L1rlYkVODD0Yv1zosGKx48IhGOXdL8nJ4Im8bujcUNLJy/vEYD8Qcfsi6NHOF3Qn0A4Xw+Nva0wp86zfq,
aws_queue=wrench_workflow-mjg,
lookupDestination=wrench_workflow-mjg,
ApproximateFirstReceiveTimestamp=1476127827886, timestamp=1476127836254}
必要に応じて例をまとめることができるかもしれませんが、私が何をしているのか理解していただければ幸いです。