クレームチェック

前のセクションでは、メッセージにデータが欠落している状況に対処するのに役立つコンテンツエンリッチャーコンポーネントをいくつか取り上げました。また、メッセージからデータ項目を削除できるコンテンツフィルタリングについても説明しました。ただし、データを一時的に非表示にする場合があります。例: 分散システムでは、非常に大きなペイロードを持つメッセージを受信する場合があります。一部の断続的なメッセージ処理ステップはこのペイロードへのアクセスを必要とせず、一部は特定のヘッダーへのアクセスのみを必要とする場合があるため、各処理ステップで大きなメッセージペイロードを運ぶとパフォーマンスが低下し、セキュリティリスクが発生し、デバッグが困難になる場合があります。

ライブラリへの格納 (英語) （またはクレームチェック）パターンは、データを既知の場所に格納し、そのデータの格納場所へのポインタ（クレームチェック）のみを保持するメカニズムを表します。このポインタを新しいメッセージのペイロードとして渡すことで、メッセージフロー内の任意のコンポーネントが、必要なときにすぐに実際のデータを取得できるようになります。このアプローチは、書留郵便のプロセスに非常に似ています。書留郵便では、郵便受けにクレームチェックが届き、その後、郵便局に行って実際のバゲッジを受け取る必要があります。また、フライト後やホテルでのバゲッジ受取にも同様の考え方が当てはまります。

Spring Integration は、2 種類のクレームチェックトランスフォーマーを提供します。

  • 受信クレームチェックトランス

  • 発信クレームチェックトランス

便利な名前空間ベースのメカニズムを使用して構成できます。

受信クレームチェックトランス

受信クレームチェックトランスフォーマーは、message-store 属性によって識別されるメッセージストアにメッセージを格納することにより、受信メッセージを変換します。次の例では、受信クレームチェックトランスを定義しています。

<int:claim-check-in id="checkin"
        input-channel="checkinChannel"
        message-store="testMessageStore"
        output-channel="output"/>

上記の構成では、input-channel で受信されたメッセージは、message-store 属性で識別され、生成された ID でインデックス付けされたメッセージストアに保持されます。その ID は、そのメッセージのクレームチェックです。クレームチェックは、output-channel に送信される新しい（変換された）メッセージのペイロードにもなります。

ある時点で実際のメッセージにアクセスする必要があると仮定します。手動でメッセージストアにアクセスしてメッセージの内容を取得するか、同じアプローチ（トランスフォーマーの作成）を使用して、送信クレームチェックトランスフォーマーを使用してクレームチェックを実際のメッセージに変換することもできます。

次のリストは、受信クレームチェックトランスの利用可能なすべてのパラメーターの概要を示しています。

<int:claim-check-in auto-startup="true"             (1)
                    id=""                           (2)
                    input-channel=""                (3)
                    message-store="messageStore"    (4)
                    order=""                        (5)
                    output-channel=""               (6)
                    send-timeout="">                (7)
    <int:poller></int:poller>                       (8)
</int:claim-check-in>
1 アプリケーションコンテキストの起動時にこのコンポーネントを起動する必要があるかどうかを示すライフサイクル属性。デフォルトは true です。この属性は、Chain 要素内では使用できません。オプション。
2 基礎となる Bean 定義（MessageTransformingHandler）を識別する ID。この属性は、Chain 要素内では使用できません。オプション。
3 このエンドポイントの受信メッセージチャネル。この属性は、Chain 要素内では使用できません。オプション。
4 このクレームチェックトランスによって使用される MessageStore への参照。指定しない場合、デフォルトの参照は messageStore という名前の Bean になります。オプション。
5 このエンドポイントがチャンネルのサブスクライバーとして接続されている場合の呼び出しの順序を指定します。これは、そのチャネルが failover ディスパッチ戦略を使用する場合に特に関連します。このエンドポイント自体がキューを持つチャネルのポーリングコンシューマーである場合、効果はありません。この属性は、Chain 要素内では使用できません。オプション。
6 このエンドポイントによって処理された後、メッセージが送信されるメッセージチャネルを識別します。この属性は、Chain 要素内では使用できません。オプション。
7 応答メッセージを出力チャネルに送信するときに待機する最大時間 (ミリ秒単位) を指定します。デフォルトは 30 秒です。この属性は、Chain 要素内では使用できません。オプション。
8 ポーラーを定義します。この要素は、Chain 要素内では使用できません。オプション。

発信クレームチェックトランス

送信クレームチェックトランスフォーマーを使用すると、クレームチェックペイロードを持つメッセージを、ペイロードとして元のコンテンツを持つメッセージに変換できます。

<int:claim-check-out id="checkout"
        input-channel="checkoutChannel"
        message-store="testMessageStore"
        output-channel="output"/>

上記の構成では、input-channel で受信したメッセージには、ペイロードとしてクレームチェックが必要です。発信クレームチェックトランスフォーマーは、提供されたクレームチェックによって識別されたメッセージをメッセージストアに照会することにより、元のペイロードを持つメッセージに変換します。次に、新しくチェックアウトしたメッセージを output-channel に送信します。

次のリストは、発信クレームチェックトランスの利用可能なすべてのパラメーターの概要を示しています。

<int:claim-check-out auto-startup="true"             (1)
                     id=""                           (2)
                     input-channel=""                (3)
                     message-store="messageStore"    (4)
                     order=""                        (5)
                     output-channel=""               (6)
                     remove-message="false"          (7)
                     send-timeout="">                (8)
    <int:poller></int:poller>                        (9)
</int:claim-check-out>
1 アプリケーションコンテキストの起動時にこのコンポーネントを起動する必要があるかどうかを示すライフサイクル属性。デフォルトは true です。この属性は、Chain 要素内では使用できません。オプション。
2 基礎となる Bean 定義（MessageTransformingHandler）を識別する ID。この属性は、Chain 要素内では使用できません。オプション。
3 このエンドポイントの受信メッセージチャネル。この属性は、Chain 要素内では使用できません。オプション。
4 このクレームチェックトランスによって使用される MessageStore への参照。指定しない場合、デフォルトの参照は messageStore という名前の Bean になります。オプション。
5 このエンドポイントがチャンネルのサブスクライバーとして接続されている場合の呼び出しの順序を指定します。これは、そのチャネルが failover ディスパッチ戦略を使用している場合に特に重要です。このエンドポイント自体がキューを持つチャネルのポーリングコンシューマーである場合、効果はありません。この属性は、Chain 要素内では使用できません。オプション。
6 このエンドポイントによって処理された後、メッセージが送信されるメッセージチャネルを識別します。この属性は、Chain 要素内では使用できません。オプション。
7true に設定されている場合、このトランスフォーマーによってメッセージは MessageStore から削除されます。この設定は、メッセージが一度しか「要求」されない場合に便利です。デフォルトは false です。オプションです。
8 応答メッセージを出力チャネルに送信するときに待機する最大時間 (ミリ秒単位) を指定します。デフォルトは 30 秒です。この属性は、Chain 要素内では使用できません。オプション。
9 ポーラーを定義します。この要素は、Chain 要素内では使用できません。オプション。

クレーム 1 回

場合によっては、特定のメッセージは一度だけクレームする必要があります。例として、飛行機の手荷物の取り扱いプロセスを考えてみましょう。出発時に手荷物をチェックインし、到着時に受け取ります。一度受け取った手荷物は、再度チェックインしない限り、再度受け取ることはできません。このようなケースに対応するため、claim-check-out トランスフォーマーに remove-message ブール属性を導入しました。この属性はデフォルトで false に設定されています。ただし、true に設定すると、クレームされたメッセージは MessageStore から削除され、再度受け取ることができなくなります。

この機能は、特にメモリ内の Map ベースの SimpleMessageStore の場合、ストレージスペースの点で影響があり、メッセージを削除しないと最終的に OutOfMemoryException につながる可能性があります。複数のクレームが行われないと思われる場合は、remove-message 属性の値を true に設定することをお勧めします。次の例は、remove-message 属性の使用方法を示しています。

<int:claim-check-out id="checkout"
        input-channel="checkoutChannel"
        message-store="testMessageStore"
        output-channel="output"
        remove-message="true"/>

メッセージストアの言葉

クレームチェックの詳細については（それらが機能する限り）あまり気にしませんが、Spring Integration の実際のクレームチェック（ポインター）の現在の実装では、一意性を確保するために UUID を使用します。

org.springframework.integration.store.MessageStore は、メッセージを保存および取得するための戦略インターフェースです。Spring Integration は、2 つの便利な実装を提供します。

  • SimpleMessageStore: インメモリ、Map ベースの実装 (デフォルト、テストに適しています)

  • JdbcMessageStore: JDBC 上でリレーショナルデータベースを使用する実装