クレームチェック

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

ライブラリ内のストア (英語) （またはクレームチェック）パターンは、データのある場所へのポインター（クレームチェック）のみを維持しながら、よく知られた場所にデータを格納できるメカニズムを記述します。そのポインターを新しいメッセージのペイロードとして渡すことができます。これにより、メッセージフロー内のコンポーネントは、必要に応じてすぐに実際のデータを取得できます。このアプローチは、メールボックスでクレームチェックを取得し、実際のバゲッジを請求するために郵便局に行く必要がある認証メールプロセスに非常に似ています。また、フライト後またはホテルでのバゲッジ受取所と同じ考えです。

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 から削除されます。この設定は、メッセージを 1 回だけ「要求」できる場合に役立ちます。デフォルトは false です。オプション。
8 応答メッセージを出力チャネルに送信するときに待機する最大時間 (ミリ秒単位) を指定します。デフォルトは 30 秒です。この属性は、Chain 要素内では使用できません。オプション。
9 ポーラーを定義します。この要素は、Chain 要素内では使用できません。オプション。

クレーム 1 回

場合によっては、特定のメッセージを 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 上でリレーショナルデータベースを使用する実装