以下のパラメーターは、チェーンの内部および外部のすべてのルーターに有効です。

以下のパラメーターは、チェーンの外部にあるすべての最上位ルーターでのみ有効です。

次の例に示すように、PayloadTypeRouter はペイロード型マッピングで定義されたチャネルにメッセージを送信します。

PayloadTypeRouter の構成は、Spring Integration（Namespace Support を参照）によって提供される名前空間によってもサポートされます。PayloadTypeRouter の構成は、<router/> 構成とそれに対応する実装（<bean/> 要素を使用して定義）を単一のより簡潔な構成要素に組み合わせることにより、構成を本質的に簡素化します。次の例は、上記のものと同等ですが、名前空間サポートを使用する PayloadTypeRouter 構成を示しています。

次の例は、Java で構成された同等のルーターを示しています。

Java DSL を使用する場合、2 つのオプションがあります。

最初に、前の例に示すようにルーターオブジェクトを定義できます。

ルーターは @Bean にできますが、そうする必要はありません。@Bean でない場合、フローはそれを登録します。

次に、次の例に示すように、DSL フロー自体内でルーティング機能を定義できます。

HeaderValueRouter は、個々のヘッダー値マッピングに基づいてメッセージをチャネルに送信します。HeaderValueRouter が作成されると、評価されるヘッダーの名前で初期化されます。ヘッダーの値は、次の 2 つのいずれかです。

任意の値である場合、これらのヘッダー値からチャネル名への追加マッピングが必要です。それ以外の場合、追加の構成は必要ありません。

Spring Integration は、HeaderValueRouter を構成するための単純な名前空間ベースの XML 構成を提供します。次の例は、チャネルへのヘッダー値のマッピングが必要な場合の HeaderValueRouter の構成を示しています。

解決プロセス中に、前の例で定義されたルーターでチャネル解決エラーが発生し、例外が発生する場合があります。このような例外を抑制し、未解決のメッセージをデフォルトの出力チャネル（default-output-channel 属性で識別）に送信する場合は、resolution-required を false に設定します。

通常、ヘッダー値が明示的にチャネルにマッピングされていないメッセージは default-output-channel に送信されます。ただし、ヘッダー値がチャネル名にマップされているが、チャネルを解決できない場合、resolution-required 属性を false に設定すると、そのようなメッセージが default-output-channel にルーティングされます。

次の例は、Java で構成された同等のルーターを示しています。

Java DSL を使用する場合、2 つのオプションがあります。最初に、前の例に示すようにルーターオブジェクトを定義できます。

ルーターは @Bean にできますが、そうする必要はありません。@Bean でない場合、フローはそれを登録します。

次に、次の例に示すように、DSL フロー自体内でルーティング機能を定義できます。

ヘッダー値自体がチャネル名を表すため、ヘッダー値のチャネル名へのマッピングが不要な構成。次の例は、ヘッダー値をチャネル名にマッピングする必要のないルーターを示しています。

RecipientListRouter は、受信した各メッセージを静的に定義されたメッセージチャネルのリストに送信します。次の例では、RecipientListRouter を作成します。

Spring Integration は、次の例に示すように、RecipientListRouter 構成（名前空間サポートを参照）の名前空間サポートも提供します。

次の例は、Java で構成された同等のルーターを示しています。

次の例は、Java DSL を使用して構成された同等のルーターを示しています。

RecipientListRouter を構成する際のもう 1 つの便利なオプションは、Spring Expression Language（SpEL）サポートを個々の受信者チャネルのセレクターとして使用することです。これは、「チェーン」の先頭で「選択的コンシューマー」として機能するフィルターを使用することに似ています。ただし、この場合、次の例に示すように、すべてルーターの構成にかなり簡潔に結合されます。

上記の構成では、selector-expression 属性で識別される SpEL 式が評価され、この受信者を特定の入力メッセージの受信者リストに含めるかどうかが決定されます。式の評価結果はブール値でなければなりません。この属性が定義されていない場合、チャネルは常に受信者のリストに含まれます。

バージョン 4.1 以降、RecipientListRouter は、実行時に動的に受信者を操作するためのいくつかの操作を提供します。これらの管理操作は、RecipientListRouterManagement によって @ManagedResource アノテーションを介して提示されます。次の例に示すように、制御バスと JMX を使用して使用できます。

アプリケーションから simpleRouter を起動すると、channel1 受信者が 1 人だけになります。ただし、addRecipient コマンドの後に、channel2 受信者が追加されます。ある時点でルーターからのメッセージに関心がある場合、「メッセージの一部である何かに関心を登録する」ユースケースであるため、recipient-list-router にサブスクライブし、ある時点で、登録解除。

<recipient-list-router> のランタイム管理操作のため、最初から <recipient> なしで構成できます。この場合、メッセージに一致する受信者がいない場合の RecipientListRouter の動作は同じです。defaultOutputChannel が構成されている場合、メッセージはそこに送信されます。そうでない場合、MessageDeliveryException がスローされます。

XPath ルーターは XML モジュールの一部です。XPath を使用した XML メッセージのルーティングを参照してください。

Spring Integration は、ルーティングエラーメッセージ（payload が Throwable インスタンスであるメッセージとして定義される）のために、ErrorMessageExceptionTypeRouter と呼ばれる特別な型ベースのルーターも提供します。ErrorMessageExceptionTypeRouter は PayloadTypeRouter に似ています。実際、それらはほとんど同一です。唯一の違いは、PayloadTypeRouter がペイロードインスタンスのインスタンス階層（たとえば payload.getClass().getSuperclass()）をナビゲートして最も具象型とチャネルマッピングを見つけるのに対し、ErrorMessageExceptionTypeRouter は「例外原因」（たとえば payload.getCause()）の階層をナビゲートして見つけることです最も具体的な Throwable 型またはチャネルマッピング。mappingClass.isInstance(cause) を使用して、cause をクラスまたはスーパークラスに一致させます。

次の例は、ErrorMessageExceptionTypeRouter のサンプル構成を示しています。

router 要素は、ルーターを入力チャネルに接続する方法を提供し、オプションの default-output-channel 属性も受け入れます。ref 属性は、カスタムルーター実装（AbstractMessageRouter を継承する必要があります）の Bean 名を参照します。次の例は、3 つの汎用ルーターを示しています。

あるいは、ref は @Router アノテーションを含む POJO を指す場合があります（後述）か、ref を明示的なメソッド名と組み合わせることができます。メソッドを指定すると、このドキュメントで後述する @Router アノテーションセクションで説明されているのと同じ動作が適用されます。次の例では、ref 属性で POJO を指すルーターを定義しています。

カスタムルーターの実装が他の <router> 定義で参照されている場合は、通常 ref 属性を使用することをお勧めします。ただし、カスタムルーターの実装を <router> の単一の定義にスコープする必要がある場合は、次の例に示すように、内部 Bean 定義を提供できます。

次の例は、Java で構成された同等のルーターを示しています。

次の例は、Java DSL を使用して構成された同等のルーターを示しています。

または、次の例に示すように、メッセージペイロードからデータをルーティングできます。

@Router を使用してメソッドにアノテーションを付ける場合、メソッドは MessageChannel または String 型のいずれかを返す場合があります。後者の場合、エンドポイントはデフォルトの出力チャネルの場合と同様にチャネル名を解決します。さらに、メソッドは単一の値またはコレクションを返す場合があります。コレクションが返される場合、応答メッセージは複数のチャネルに送信されます。要約すると、次のメソッドシグネチャーはすべて有効です。

ペイロードベースのルーティングに加えて、メッセージヘッダー内でプロパティまたは属性として使用可能なメタデータに基づいてメッセージをルーティングできます。この場合、@Router アノテーションが付けられたメソッドには、@Header アノテーションが付けられたパラメーターが含まれる場合があります。これは、次の例に示すようにヘッダー値にマッピングされ、アノテーションサポートにドキュメント化されます。

ルーター構成の詳細については、Java DSL の章のメッセージルーターも参照してください。

ルーターマッピングを管理する 1 つの方法は、コントロールバス (英語) パターンを使用することです。これは、ルーターを含む Spring Integration コンポーネントを管理および監視するためのコントロールメッセージを送信できるコントロールチャネルを公開します。

通常、特定の管理対象コンポーネント（ルーターなど）で特定の操作を呼び出すように要求する制御メッセージを送信します。次の管理操作（メソッド）は、ルーター解決プロセスの変更に固有のものです。

これらのメソッドは、単純な変更（単一のルートの更新、ルートの追加または削除など）に使用できることに注意してください。ただし、あるルートを削除して別のルートを追加する場合、更新はアトミックではありません。これは、ルーティングテーブルが更新間で不確定な状態になる可能性があることを意味します。バージョン 4.0 以降、コントロールバスを使用して、ルーティングテーブル全体をアトミックに更新できるようになりました。次のメソッドを使用して、これを行うことができます。

各マッピングは改行文字（\n）で区切られていることに注意してください。マップをプログラムで変更する場合は、型の安全性が懸念されるため、setChannelMappings メソッドを使用することをお勧めします。replaceChannelMappings は、String オブジェクトではないキーまたは値を無視します。

Spring の JMX サポートを使用してルーターインスタンスを公開し、お気に入りの JMX クライアント（たとえば、JConsole）を使用して、ルーターの構成を変更するための操作（メソッド）を管理することもできます。

バージョン 4.1 から、Spring Integration はルーティングスリップ (英語) エンタープライズ統合パターンの実装を提供します。outputChannel がエンドポイントに指定されていない場合、routingSlip メッセージヘッダーとして実装され、AbstractMessageProducingHandler インスタンスの次のチャネルを決定するために使用されます。このパターンは、メッセージフローを決定するために複数のルーターを構成することが困難になる複雑で動的な場合に役立ちます。output-channel を持たないエンドポイントにメッセージが到着すると、routingSlip が調べられて、メッセージが送信される次のチャネルが決定されます。ルーティングスリップがなくなると、通常の replyChannel 処理が再開されます。

ルーティングスリップの構成は、HeaderEnricher オプションとして提示されます。これは、次の例に示すように、path エントリを含むセミコロンで区切られたルーティングスリップです。

上記の例には次のものがあります。

ルーティングスリップ path エントリには、MessageChannel Bean 名、RoutingSlipRouteStrategy Bean 名、および Spring 式（SpEL）を含めることができます。RoutingSlipHeaderValueMessageProcessor は、最初の processMessage 呼び出しで、各ルーティングスリップ path エントリを BeanFactory に対してチェックします。エントリ（アプリケーションコンテキストの Bean 名ではない）を ExpressionEvaluatingRoutingSlipRouteStrategy インスタンスに変換します。RoutingSlipRouteStrategy エントリは、null または空の String を返すまで複数回呼び出されます。

ルーティングスリップは getOutputChannel プロセスに関係しているため、リクエスト / 応答コンテキストがあります。RoutingSlipRouteStrategy は、requestMessage および reply オブジェクトを使用する次の outputChannel を決定するために導入されました。この戦略の実装は、アプリケーションコンテキストで Bean として登録する必要があり、その Bean 名はルーティングスリップ path で使用されます。ExpressionEvaluatingRoutingSlipRouteStrategy 実装が提供されます。SpEL 式を受け入れ、内部 ExpressionEvaluatingRoutingSlipRouteStrategy.RequestAndReply オブジェクトが評価コンテキストのルートオブジェクトとして使用されます。これは、各 ExpressionEvaluatingRoutingSlipRouteStrategy.getNextPath() 呼び出しの EvaluationContext 作成のオーバーヘッドを回避するためです。これは、Message<?> request と Object reply の 2 つのプロパティを持つ単純な Java Bean です。この式の実装では、SpEL（たとえば @routingSlipRoutingPojo.get(request, reply) および request.headers[myRoutingSlipChannel]）を使用してルーティングスリップ path エントリを指定し、RoutingSlipRouteStrategy に Bean を定義しないようにすることができます。

Java 構成の場合、次の例に示すように、RoutingSlipHeaderValueMessageProcessor インスタンスを HeaderEnricher Bean 定義に追加できます。

エンドポイントが応答を生成し、outputChannel が定義されていない場合、ルーティングスリップアルゴリズムは次のように機能します。

バージョン 4.1 から、AbstractMessageSplitter は value が分割する Iterator 型をサポートします。Iterator （または Iterable）の場合、基になるアイテムの数にアクセスできず、SEQUENCE_SIZE ヘッダーが 0 に設定されていることに注意してください。つまり、<aggregator> のデフォルト SequenceSizeReleaseStrategy は機能せず、splitter から CORRELATION_ID のグループは解放されません。incomplete のままになります。この場合、適切なカスタム ReleaseStrategy を使用するか、group-timeout または MessageGroupStoreReaper とともに send-partial-result-on-expiry に依存する必要があります。

バージョン 5.0 から、AbstractMessageSplitter は protected obtainSizeIfPossible() メソッドを提供し、可能であれば Iterable および Iterator オブジェクトのサイズを決定できます。たとえば、XPathMessageSplitter は、基になる NodeList オブジェクトのサイズを判別できます。また、バージョン 5.0.9 以降、このメソッドは com.fasterxml.jackson.core.TreeNode のサイズも適切に返します。

Iterator オブジェクトは、分割する前にメモリ内にコレクション全体を構築する必要を回避できます。例: 基礎となるアイテムが、反復またはストリームを使用して外部システム（例: DataBase または FTP MGET）から取り込まれた場合。

バージョン 5.0 以降、AbstractMessageSplitter は、value が分割する Java Stream および Reactive Streams Publisher 型をサポートします。この場合、ターゲット Iterator は反復機能に基づいて構築されます。

さらに、スプリッターの出力チャンネルが ReactiveStreamsSubscribableChannel のインスタンスである場合、AbstractMessageSplitter は Iterator の代わりに Flux の結果を生成し、出力チャンネルは、ダウンストリームフローデマンドでのバックプレッシャーベースの分割のためにこの Flux にサブスクライブされます。

バージョン 5.2 以降、スプリッターは、スプリット関数が空のコンテナー（コレクション、配列、ストリーム、Flux など）を返したリクエストメッセージを送信するための discardChannel オプションをサポートします。この場合、outputChannel に送信するために反復する項目はありません。null の分割結果は、フロー終了インジケータとして残ります。

AggregatingMessageHandler （AbstractCorrelatingMessageHandler のサブクラス）は MessageHandler 実装であり、アグリゲーター（および他の相関するユースケース）の共通機能をカプセル化します。

メッセージをグループ化する方法を決定する責任は、CorrelationStrategy インスタンスに委譲されます。メッセージグループを解放できるかどうかを決定する責任は、ReleaseStrategy インスタンスに委譲されます。

次のリストは、ベース AbstractAggregatingMessageGroupProcessor の簡単なハイライトを示しています（aggregatePayloads メソッドを実装する責任は開発者に任されています）。

AbstractAggregatingMessageGroupProcessor のすぐに使用可能な実装として DefaultAggregatingMessageGroupProcessor、ExpressionEvaluatingMessageGroupProcessor、MethodInvokingMessageGroupProcessor を参照してください。

バージョン 5.2 以降、Function<MessageGroup, Map<String, Object>> 戦略は、AbstractAggregatingMessageGroupProcessor が出力メッセージのヘッダーをマージおよび計算（集約）するために使用可能です。DefaultAggregateHeadersFunction 実装は、グループ間で競合のないすべてのヘッダーを返すロジックで使用できます。グループ内の 1 つ以上のメッセージにヘッダーがない場合、競合とは見なされません。競合するヘッダーは省略されます。新しく導入された DelegatingMessageGroupProcessor とともに、この関数は任意の（AbstractAggregatingMessageGroupProcessor 以外の） MessageGroupProcessor 実装に使用されます。基本的に、フレームワークは提供された関数を AbstractAggregatingMessageGroupProcessor インスタンスに注入し、他のすべての実装を DelegatingMessageGroupProcessor にラップします。AbstractAggregatingMessageGroupProcessor と DelegatingMessageGroupProcessor のロジックの違い。後者は、デリゲート戦略を呼び出す前にヘッダーを事前に計算せず、デリゲートが Message または AbstractIntegrationMessageBuilder を返す場合、関数を呼び出しません。その場合、フレームワークは、ターゲット実装が返された結果に含まれる適切なヘッダーセットを生成することを考慮したと想定します。Function<MessageGroup, Map<String, Object>> ストラテジーは、XML 構成の headers-function 参照属性、Java DSL の AggregatorSpec.headersFunction() オプション、プレーン Java 構成の AggregatorFactoryBean.setHeadersFunction() として利用可能です。

CorrelationStrategy は AbstractCorrelatingMessageHandler が所有し、次の例に示すように、IntegrationMessageHeaderAccessor.CORRELATION_ID メッセージヘッダーに基づいたデフォルト値を持っています。

メッセージグループの実際の処理に関しては、デフォルトの実装は DefaultAggregatingMessageGroupProcessor です。ペイロードが特定のグループに対して受信されたペイロードの List である単一の Message を作成します。これは、スプリッター、パブリッシュ / サブスクライブチャネル、アップストリームの受信者リストルーターを使用した単純なスキャッターギャザーの実装に適しています。

アプリケーションに特定のアグリゲーター戦略を実装する場合、AbstractAggregatingMessageGroupProcessor を継承して aggregatePayloads メソッドを実装できます。ただし、XML またはアノテーションを使用して構成できる集約ロジックを実装するための、API とはあまり関係のない、より優れたソリューションがあります。

一般に、POJO は、単一の java.util.List を引数として受け入れるメソッドを提供する場合、集約アルゴリズムを実装できます（パラメーター化されたリストもサポートされます）。このメソッドは、次のようにメッセージを集約するために呼び出されます。

バージョン 5.3 以降、メッセージグループの処理後、AbstractCorrelatingMessageHandler は、いくつかのネストされたレベルを持つ適切なスプリッターアグリゲーターシナリオの MessageBuilder.popSequenceDetails() メッセージヘッダー変更を実行します。メッセージグループの解放結果がメッセージのコレクションでない場合にのみ行われます。その場合、ターゲット MessageGroupProcessor は、それらのメッセージの作成中に MessageBuilder.popSequenceDetails() 呼び出しを担当します。

MessageGroupProcessor が Message を返す場合、sequenceDetails がグループ内の最初のメッセージと一致する場合にのみ、出力メッセージに対して MessageBuilder.popSequenceDetails() が実行されます。(以前は、プレーンペイロードまたは AbstractIntegrationMessageBuilder が MessageGroupProcessor から返された場合にのみ、これが行われていました。)

この機能は、新しい popSequence boolean プロパティによって制御できるため、相関の詳細が標準スプリッターによって入力されていないシナリオでは、MessageBuilder.popSequenceDetails() を無効にすることができます。このプロパティは、基本的に、AbstractMessageSplitter 内の最も近いアップストリーム applySequence = true によって実行されたことを元に戻します。詳細については、スプリッターを参照してください。

MessageGroupProcessor の processMessageGroup メソッドがコレクションを返す場合、Message<?> オブジェクトのコレクションでなければなりません。この場合、メッセージは個別にリリースされます。バージョン 4.2 より前は、XML 構成を使用して MessageGroupProcessor を提供することはできませんでした。集約には POJO メソッドのみを使用できます。ここで、参照された（または内部の）Bean が MessageProcessor を実装していることをフレームワークが検出すると、アグリゲーターの出力プロセッサーとして使用されます。

カスタム MessageGroupProcessor からオブジェクトのコレクションをメッセージのペイロードとしてリリースする場合、クラスは AbstractAggregatingMessageGroupProcessor を継承し、aggregatePayloads() を実装する必要があります。

また、バージョン 4.2 以降、SimpleMessageGroupProcessor が提供されています。グループからメッセージのコレクションを返します。これにより、前述のように、リリースされたメッセージが個別に送信されます。

これにより、アグリゲーターはメッセージバリアとして機能し、リリース戦略が実行され、グループが個々のメッセージのシーケンスとしてリリースされるまで、到着したメッセージが保持されます。

ReleaseStrategy インターフェースは次のように定義されます。

一般に、POJO は、単一の java.util.List を引数として受け入れ（パラメーター化されたリストもサポートされている）、ブール値を返すメソッドを提供する場合、完了決定ロジックを実装できます。このメソッドは、新しいメッセージが到着するたびに呼び出され、次のようにグループが完了したかどうかを判断します。

次の例は、型 Message の List に @ReleaseStrategy アノテーションを使用する方法を示しています。

次の例は、型 String の List に @ReleaseStrategy アノテーションを使用する方法を示しています。

前述の 2 つの例の署名に基づいて、POJO ベースのリリース戦略には、まだリリースされていないメッセージの Collection （Message 全体へのアクセスが必要な場合）またはペイロードオブジェクトの Collection が渡されます（type パラメーターが何かの場合 Message 以外）。これにより、ほとんどのユースケースが満たされます。ただし、何らかの理由で MessageGroup 全体にアクセスする必要がある場合は、ReleaseStrategy インターフェースの実装を提供する必要があります。

グループが集約のためにリリースされると、まだリリースされていないすべてのメッセージが処理され、グループから削除されます。グループも完了している場合（つまり、シーケンスからのすべてのメッセージが到着した場合、またはシーケンスが定義されていない場合）、グループは完了としてマークされます。このグループの新しいメッセージは、破棄チャネル（定義されている場合）に送信されます。expire-groups-upon-completion を true （デフォルトは false）に設定すると、グループ全体が削除され、新しいメッセージ（削除されたグループと同じ相関 ID を持つ）は新しいグループを形成します。MessageGroupStoreReaper と true に設定されている send-partial-result-on-expiry を使用して、部分シーケンスを解放できます。

Spring Integration は、ReleaseStrategy の実装を提供します: SimpleSequenceSizeReleaseStrategy。この実装は、到着する各メッセージの SEQUENCE_NUMBER および SEQUENCE_SIZE ヘッダーを調べて、メッセージグループが完了し、集約の準備ができたときを判断します。前に示したように、これはデフォルトの戦略でもあります。

大きなグループを集約する場合、部分的なグループを解放する必要はなく、重複したシーケンスを検出 / 拒否する必要はありません。代わりに SimpleSequenceSizeReleaseStrategy を使用することを検討してください。これらのユースケースでははるかに効率的で、デフォルトです部分的なグループリリースが指定されていない場合、バージョン 5.0 以降。

4.3 リリースは、SimpleMessageGroup のメッセージのデフォルト Collection を HashSet に変更しました（以前は BlockingQueue でした）。これは、大きなグループから個々のメッセージを削除するときにコストがかかりました（O（n）線形スキャンが必要でした）。ハッシュセットは通常、削除がはるかに高速ですが、挿入と削除の両方でハッシュを計算する必要があるため、大きなメッセージの場合はコストが高くなる可能性があります。ハッシュが高負荷なメッセージがある場合は、他のコレクション型の使用を検討してください。MessageGroupFactory を使用するで説明したように、SimpleMessageGroupFactory が提供されているため、ニーズに最適な Collection を選択できます。独自のファクトリ実装を提供して、他の Collection<Message<?>> を作成することもできます。

次の例は、以前の実装と SimpleSequenceSizeReleaseStrategy でアグリゲーターを構成する方法を示しています。

CorrelationStrategy インターフェースは次のように定義されます。

このメソッドは、メッセージをメッセージグループに関連付けるために使用される相関キーを表す Object を返します。キーは、equals() および hashCode() の実装に関して Map のキーに使用される条件を満たさなければなりません。

一般に、どの POJO も相関ロジックを実装でき、メッセージをメソッドの引数にマッピングするルールは ServiceActivator と同じです（@Header アノテーションのサポートを含む）。メソッドは値を返す必要があり、値は null であってはなりません。

Spring Integration は、CorrelationStrategy の実装を提供します: HeaderAttributeCorrelationStrategy。この実装は、メッセージヘッダーの 1 つ（コンストラクター引数で名前が指定されている）の値を相関キーとして返します。デフォルトでは、相関戦略は CORRELATION_ID ヘッダー属性の値を返す HeaderAttributeCorrelationStrategy です。相関に使用するカスタムヘッダー名がある場合は、HeaderAttributeCorrelationStrategy のインスタンスで構成して、アグリゲーターの相関戦略の参照として提供できます。

グループへの変更はスレッドセーフです。同じ相関 ID のメッセージを同時に送信すると、そのうちの 1 つのみがアグリゲーターで処理され、メッセージグループごとにシングルスレッドとして効果的に処理されます。LockRegistry は、解決された相関 ID のロックを取得するために使用されます。DefaultLockRegistry はデフォルトで使用されます（メモリ内）。共有 MessageGroupStore が使用されているサーバー間で更新を同期するには、共有ロックレジストリを構成する必要があります。

上記で説明したように、メッセージグループが変更されると（メッセージが追加または解放される）、ロックが保持されます。

次のフローを検討してください。

複数のスレッドがあり、アグリゲーターが共通のロックレジストリを共有している場合、デッドロックが発生する可能性があります。これにより、スレッドがハングし、jstack <pid> は次のような結果を表示する場合があります。

この問題を回避するには、いくつかの方法があります。

Spring Integration は、<aggregator/> 要素を介した XML を使用したアグリゲーターの構成をサポートします。次の例は、アグリゲーターの例を示しています。

通常、カスタムアグリゲーターハンドラー実装が他の <aggregator> 定義で参照される可能性がある場合は、ref 属性を使用することをお勧めします。ただし、カスタムアグリゲーターの実装が <aggregator> の単一の定義でのみ使用されている場合、次の例に示すように、<aggregator> エレメント内の集約 POJO を構成するために、内部 Bean 定義（バージョン 1.0.3 以降）を使用できます。

次の例は、アグリゲーター Bean の実装を示しています。

前述の例の完了戦略 Bean の実装は、次のとおりです。

上記の例の相関戦略 Bean の実装は、次のようになります。

前の例のアグリゲーターは、ある基準（この場合は 10 で割った後の残り）によって番号をグループ化し、ペイロードによって提供される番号の合計が特定の値を超えるまでグループを保持します。

次の例は、アノテーションを使用して構成されたアグリゲーターを示しています。

XML 要素によって提供されるすべての構成オプションは、@Aggregator アノテーションでも使用できます。

アグリゲーターは、XML から明示的に参照するか、クラスで @MessageEndpoint が定義されている場合、クラスパススキャンによって自動的に検出されます。

Aggregator コンポーネントのアノテーション構成（@Aggregator など）は、ほとんどのデフォルトオプションで十分な単純なユースケースのみを対象としています。アノテーション構成を使用するときにこれらのオプションをさらに制御する必要がある場合は、次の例に示すように、AggregatingMessageHandler の @Bean 定義の使用を検討し、@Bean メソッドを @ServiceActivator でマークします。

詳細については、プログラミングモデルおよび @Bean メソッドのアノテーションを参照してください。

オークション Scatter-Gather バリアントは、リクエストメッセージに「パブリッシュ / サブスクライブ」ロジックを使用します。ここで、「スキャッター」チャネルは apply-sequence="true" の PublishSubscribeChannel です。ただし、このチャネルは任意の MessageChannel 実装にすることができます（ContentEnricher の request-channel の場合のように - コンテンツエンリッチャーを参照）。ただし、この場合、aggregation 関数用に独自のカスタム correlationStrategy を作成する必要があります。

配布 Scatter-Gather バリアントは、RecipientListRouter （RecipientListRouter を参照）に基づいており、RecipientListRouter で使用可能なすべてのオプションがあります。これは、2 番目の ScatterGatherHandler コンストラクター引数です。recipient-list-router および aggregator のデフォルトの correlationStrategy のみに依存する場合は、apply-sequence="true" を指定する必要があります。それ以外の場合は、aggregator 用のカスタム correlationStrategy を提供する必要があります。PublishSubscribeChannel バリアント（オークションバリアント）とは異なり、recipient-list-router selector オプションを使用すると、メッセージに基づいてターゲットサプライヤーをフィルタリングできます。apply-sequence="true" では、デフォルトの sequenceSize が提供され、aggregator はグループを正しく解放できます。配布オプションは、オークションオプションと相互に排他的です。

オークションとディストリビューションの両方のバリエーションで、リクエスト（スキャター）メッセージは gatherResultChannel ヘッダーで強化され、aggregator からの応答メッセージを待機します。

デフォルトでは、すべてのサプライヤーは結果を replyChannel ヘッダーに送信する必要があります（通常、最終エンドポイントから output-channel を省略します）。ただし、gatherChannel オプションも提供されているため、サプライヤーは集約のためにそのチャネルに応答を送信できます。