Transformer
メッセージトランスフォーマーは、メッセージプロデューサーとメッセージコンシューマーの疎結合を可能にする上で非常に重要なロールを果たします。すべてのメッセージ生成コンポーネントに、次のコンシューマーがどの型を期待するかを知る必要はなく、それらのコンポーネント間にトランスフォーマーを追加できます。String を XML ドキュメントに変換するような汎用トランスフォーマーも非常に再利用可能です。
一部のシステムでは、標準的なデータモデル (英語) を提供するのが最善かもしれませんが、Spring Integration の一般的な哲学は、特定の形式を必要としないことです。むしろ、最大限の柔軟性を得るために、Spring Integration は、拡張のために可能な限り単純なモデルを提供することを目指しています。他のエンドポイント型と同様に、XML または Java アノテーションで宣言型構成を使用すると、単純な POJO をメッセージトランスフォーマーのロールに適合させることができます。この章の残りの部分では、これらの構成オプションについて説明します。
| 柔軟性を最大化するために、Spring は XML ベースのメッセージペイロードを必要としません。それでも、フレームワークは、XML ベースのペイロードを処理するための便利なトランスフォーマーを提供します。これが実際にアプリケーションにとって正しい選択である場合です。これらのトランスフォーマーの詳細については、XML サポート - XML ペイロードの処理を参照してください。 |
Java およびその他の DSL を使用した Transformer の構成
単純な Java およびアノテーション構成の場合、Spring Bean POJO メソッドは @Transformer アノテーションでマークされている必要があり、フレームワークはメッセージが入力チャネルから消費されるときにそれを呼び出します。
public class SomeService {
@Transformer(inputChannel = "transformChannel", outputChannel = "nextServiceChannel")
public OutputData exampleTransformer(InputData payload) {
...
}
}詳細については、アノテーションサポートを参照してください。
Java、Groovy または Kotlin DSL の場合、IntegrationFlow の .transform() 演算子はトランスフォーマーエンドポイントを表します。
Java DSL
Kotlin DSL
Groovy DSL
@Bean
public IntegrationFlow someFlow() {
return IntegrationFlow
.from("transformChannel")
.transform(someService, "exampleTransformer")
.channel("nextServiceChannel")
.get();
}
@Bean
fun someFlow() =
integrationFlow("transformChannel") {
transform(someService, "exampleTransformer")
channel("nextServiceChannel")
}
@Bean
someFlow() {
integrationFlow 'transformChannel',
{
transform someService, 'exampleTransformer'
channel 'nextServiceChannel'
}
}
DSL の詳細については、次の各章を参照してください。
XML を使用した Transformer の構成
<transformer> 要素は、メッセージ変換エンドポイントを作成するために使用されます。input-channel および output-channel 属性に加えて、ref 属性が必要です。ref は、単一のメソッドで @Transformer アノテーションを含むオブジェクトを指す場合もあれば(アノテーション付きの Transformer の構成を参照)、method 属性で指定された明示的なメソッド名の値と組み合わせる場合もあります。
<int:transformer id="testTransformer" ref="testTransformerBean" input-channel="inChannel"
method="transform" output-channel="outChannel"/>
<beans:bean id="testTransformerBean" class="org.foo.TestTransformer" /> 通常、カスタムトランスフォーマハンドラーの実装を他の <transformer> 定義で再利用できる場合は、ref 属性を使用することをお勧めします。ただし、カスタムトランスフォーマーハンドラーの実装を <transformer> の単一の定義にスコープする必要がある場合、次の例に示すように、内部 Bean 定義を定義できます。
<int:transformer id="testTransformer" input-channel="inChannel" method="transform"
output-channel="outChannel">
<beans:bean class="org.foo.TestTransformer"/>
</transformer> 同じ <transformer> 構成で ref 属性と内部ハンドラー定義の両方を使用することは許可されません。曖昧な状態を作成し、例外がスローされるためです。 |
ref 属性が AbstractMessageProducingHandler を継承する Bean(フレームワーク自体によって提供されるトランスフォーマーなど)を参照する場合、出力チャネルをハンドラーに直接注入することにより、構成が最適化されます。この場合、各 ref は、個別の Bean インスタンス(または prototype -scoped Bean)にするか、内部 <bean/> 構成型を使用する必要があります。誤って複数の Bean から同じメッセージハンドラーを参照すると、構成例外が発生します。 |
POJO を使用する場合、変換に使用されるメソッドは、受信メッセージの Message 型またはペイロード型のいずれかを予期する場合があります。また、@Header および @Headers パラメーターアノテーションをそれぞれ使用して、メッセージヘッダー値を個別に、または完全なマップとして受け入れることもできます。メソッドの戻り値は任意の型にできます。戻り値自体が Message である場合、トランスフォーマーの出力チャネルに渡されます。
Spring Integration 2.0 以降、メッセージトランスフォーマーの変換メソッドは null を返すことができなくなりました。メッセージトランスフォーマーは常に各ソースメッセージを有効なターゲットメッセージに変換することが期待されるため、null を返すと例外 (正確には MessageTransformationException ) が発生します。つまり、専用の <filter> オプションがあるため、メッセージトランスフォーマーをメッセージフィルターとして使用すべきではありません。ただし、この型の動作 (コンポーネントが null を返す可能性があり、これをエラーと見なすべきではない場合) が必要な場合は、サービスアクティベーターを使用できます。その requires-reply 値はデフォルトで false ですが、トランスフォーマーと同様に、null の戻り値に対して例外をスローするように、true に設定できます。
Transformers と Spring 式言語 (SpEL)
ルーター、アグリゲーター、その他のコンポーネントと同様に、Spring Integration 2.0 以降、トランスフォーマーも変換ロジックが比較的単純な場合はいつでも SpEL サポートの恩恵を受けることができます。次の例は、SpEL 式の使用方法を示しています。
<int:transformer input-channel="inChannel"
output-channel="outChannel"
expression="payload.toUpperCase() + '- [' + T(System).currentTimeMillis() + ']'"/> 前の例では、カスタムトランスフォーマーを作成せずにペイロードを変換します。ペイロード(String と想定)は大文字で、現在のタイムスタンプと連結され、いくつかのフォーマットが適用されています。
共通 Transformers
Spring Integration は、いくつかのトランスフォーマー実装を提供します。
オブジェクトから文字列への Transformer
Object の toString() 表現を使用するのが非常に一般的であるため、Spring Integration は ObjectToStringTransformer (Transformers ファクトリも参照) を提供します。出力は文字列 payload を持つ Message です。その String は、受信メッセージのペイロードに対して toString() オペレーションを呼び出した結果です。次の例は、オブジェクトから文字列へのトランスフォーマーのインスタンスを宣言する方法を示しています。
Java DSL
Kotlin DSL
Groovy DSL
XML
@Bean
public IntegrationFlow someFlow() {
return IntegrationFlow
.from("in")
.transform(Transformers.objectToString())
.channel("out")
.get();
}
@Bean
fun someFlow() =
integrationFlow("in") {
transform(Transformers.objectToString())
channel("out")
}
@Bean
someFlow() {
integrationFlow 'in',
{
transform Transformers.objectToString()
channel 'out'
}
}
<int:object-to-string-transformer input-channel="in" output-channel="out"/>
このトランスフォーマーの潜在的な用途は、file 名前空間の「送信チャネルアダプター」に任意のオブジェクトを送信することです。そのチャネルアダプターは、デフォルトで String、バイト配列、java.io.File ペイロードのみをサポートしますが、アダプターが必要な変換を処理する直前にこのトランスフォーマを追加します。toString() 呼び出しの結果がファイルに書き込みたいものである限り、うまく機能します。それ以外の場合は、前に示した汎用 'transformer' 要素を使用して、カスタム POJO ベースのトランスフォーマーを提供できます。
logging-channel-adapter はメッセージペイロードをログに記録できるため、デバッグ時には、このトランスフォーマーは通常必要ありません。詳細については、ワイヤータップを参照してください。 |
オブジェクトから文字列への変換は非常に簡単です。受信ペイロードで toString() を呼び出します。Spring Integration 3.0 以降、このルールには 2 つの例外があります。
ペイロードが
char[]である場合、new String(payload)を呼び出します。ペイロードが
byte[]の場合、new String(payload, charset)を呼び出します。charsetはデフォルトで UTF-8 です。charsetは、トランスフォーマーに charset 属性を指定することにより変更できます。
より高度な処理(実行時の文字セットの動的な選択など)を行うには、次の例に示すように、代わりに SpEL 式ベースのトランスフォーマーを使用できます。
Java DSL
XML
@Bean
public IntegrationFlow someFlow() {
return IntegrationFlow
.from("in")
.transform("new String(payload, headers['myCharset']")
.channel("out")
.get();
}
<int:transformer input-channel="in" output-channel="out"
expression="new String(payload, headers['myCharset']" />
Object をバイト配列にシリアライズしたり、バイト配列を Object にデシリアライズしたりする必要がある場合、Spring Integration は対称シリアライゼーション変換を提供します。これらの変換はデフォルトで標準の Java シリアライゼーションを使用しますが、それぞれ serializer 属性と deserializer 属性を使用することで、Spring の Serializer または Deserializer 戦略の実装を提供することができます。Transformers ファクトリクラスも参照してください。次の例は、Spring のシリアライザとデシリアライザの使用方法を示しています。
Java DSL
XML
@Bean
public IntegrationFlow someFlow() {
return IntegrationFlow
.from("objectsIn")
.transform(Transformers.serializer())
.channel("bytesOut")
.channel("bytesIn")
.transform(Transformers.deserializer("com.mycom.*", "com.yourcom.*"))
.channel("objectsOut")
.get();
}
<int:payload-serializing-transformer input-channel="objectsIn" output-channel="bytesOut"/>
<int:payload-deserializing-transformer input-channel="bytesIn" output-channel="objectsOut"
allow-list="com.mycom.*,com.yourcom.*"/>
信頼できないソースからデータをデシリアライズするときは、パッケージおよびクラスパターンの allow-list を追加することを検討する必要があります。デフォルトでは、すべてのクラスはデシリアライズされます。 |
Object -to- Map および Map -to- Object トランス
Spring Integration は、Object から Map へのトランスフォーマーと Map から Object へのトランスフォーマーも提供します。これらは、JSON を使用してオブジェクトグラフを直列化および逆直列化します。オブジェクト階層は、最もプリミティブな型(String、int など)にイントロスペクトされます。この型へのパスは、変換された Map で key になる SpEL で記述されます。プリミティブ型が値になります。
次の例を考えてみましょう。
public class Parent{
private Child child;
private String name;
// setters and getters are omitted
}
public class Child{
private String name;
private List<String> nickNames;
// setters and getters are omitted
} 前の例の 2 つのクラスは、次の Map に変換されます。
{person.name=George, person.child.name=Jenna, person.child.nickNames[0]=Jen ...}JSON ベースの Map では、実際の型を共有せずにオブジェクト構造を記述できます。これにより、構造を維持している限り、オブジェクトグラフを異なる型のオブジェクトグラフに復元および再構築できます。
例: Map -to- Object トランスフォーマーを使用して、前述の構造を次のオブジェクトグラフに復元できます。
public class Father {
private Kid child;
private String name;
// setters and getters are omitted
}
public class Kid {
private String name;
private List<String> nickNames;
// setters and getters are omitted
}「構造化された」マップを作成する必要がある場合は、flatten 属性を指定できます。デフォルトは "true" です。'false' に設定すると、構造は Map オブジェクトの Map になります。
次の例を考えてみましょう。
public class Parent {
private Child child;
private String name;
// setters and getters are omitted
}
public class Child {
private String name;
private List<String> nickNames;
// setters and getters are omitted
} 前の例の 2 つのクラスは、次の Map に変換されます。
{name=George, child={name=Jenna, nickNames=[Bimbo, ...]}}これらのトランスフォーマーを構成するために、Spring Integration はそれぞれの XML コンポーネントと Java DSL ファクトリを提供します。
Java DSL
XML
@Bean
public IntegrationFlow someFlow() {
return IntegrationFlow
.from("directInput")
.transform(Transformers.toMap())
.channel("output")
.get();
}
<int:object-to-map-transformer input-channel="directInput" output-channel="output"/>
次のように、flatten 属性を false に設定することもできます。
Java DSL
XML
@Bean
public IntegrationFlow someFlow() {
return IntegrationFlow
.from("directInput")
.transform(Transformers.toMap(false))
.channel("output")
.get();
}
<int:object-to-map-transformer input-channel="directInput" output-channel="output" flatten="false"/>
Spring Integration は Map-to-Object の XML 名前空間サポートを提供し、Java DSL ファクトリには次の例に示すように fromMap() メソッドがあります。
Java DSL
XML
@Bean
public IntegrationFlow someFlow() {
return IntegrationFlow
.from("input")
.transform(Transformers.fromMap(org.something.Person.class))
.channel("output")
.get();
}
<int:map-to-object-transformer input-channel="input"
output-channel="output"
type="org.something.Person"/>
または、次の例に示すように、ref 属性とプロトタイプスコープの Bean を使用することもできます。
Java DSL
XML
@Bean
IntegrationFlow someFlow() {
return IntegrationFlow
.from("inputA")
.transform(Transformers.fromMap("person"))
.channel("outputA")
.get();
}
@Bean
@Scope("prototype")
Person person() {
return new Person();
}
<int:map-to-object-transformer input-channel="inputA"
output-channel="outputA"
ref="person"/>
<bean id="person" class="org.something.Person" scope="prototype"/>
"ref" および "type" 属性は相互に排他的です。また、'ref' 属性を使用する場合、「プロトタイプ」スコープの Bean を指す必要があります。そうでない場合、BeanCreationException がスローされます。 |
バージョン 5.0 からは、ObjectToMapTransformer にカスタマイズされた JsonObjectMapper を提供できます。日付の特別なフォーマットまたは空のコレクション(およびその他の用途)の null が必要な場合。JsonObjectMapper 実装の詳細については、JSONTransformers を参照してください。
ストリームトランス
StreamTransformer は、InputStream ペイロードを byte[](または charset が提供されている場合は String)に変換します。
次の例は、XML で stream-transformer 要素を使用する方法を示しています。
Java DSL
XML
@Bean
public IntegrationFlow someFlow() {
return IntegrationFlow
.from("input")
.transform(Transformers.fromStream("UTF-8"))
.channel("output")
.get();
}
<int:stream-transformer input-channel="directInput" output-channel="output"/> <!-- byte[] -->
<int:stream-transformer id="withCharset" charset="UTF-8"
input-channel="charsetChannel" output-channel="output"/> <!-- String -->
次の例は、StreamTransformer クラスと @Transformer アノテーションを使用して、Java でストリームトランスフォーマーを構成する方法を示しています。
@Bean
@Transformer(inputChannel = "stream", outputChannel = "data")
public StreamTransformer streamToBytes() {
return new StreamTransformer(); // transforms to byte[]
}
@Bean
@Transformer(inputChannel = "stream", outputChannel = "data")
public StreamTransformer streamToString() {
return new StreamTransformer("UTF-8"); // transforms to String
}JSONTransformers
Spring Integration は、Object-to-JSON および JSON-to-Object トランスフォーマーを提供します。次の例のペアは、XML で宣言する方法を示しています。
<int:object-to-json-transformer input-channel="objectMapperInput"/>
<int:json-to-object-transformer input-channel="objectMapperInput"
type="foo.MyDomainObject"/> デフォルトでは、前述のリストのトランスフォーマーはバニラ JsonObjectMapper を使用します。クラスパスからの実装に基づいています。次の例に示すように、適切なオプションを使用して、または必要なライブラリ(GSON など)に基づいて、独自のカスタム JsonObjectMapper 実装を提供できます。
<int:json-to-object-transformer input-channel="objectMapperInput"
type="something.MyDomainObject" object-mapper="customObjectMapper"/> バージョン 3.0 以降、 |
FactoryBean またはファクトリメソッドを使用して、必要な特性を持つ JsonObjectMapper を作成することを検討できます。次の例は、そのようなファクトリの使用方法を示しています。
public class ObjectMapperFactory {
public static JacksonJsonObjectMapper getMapper() {
ObjectMapper mapper = JsonMapper.builder()
.configure(JsonReadFeature.ALLOW_JAVA_COMMENTS, true)
.build();
return new JacksonJsonObjectMapper(mapper);
}
}次の例は、同じことを XML で行う方法を示しています。
<bean id="customObjectMapper" class="something.ObjectMapperFactory"
factory-method="getMapper"/> バージョン 2.2 以降、
|
バージョン 3.0 から、ObjectToJsonTransformer は、ソース型を反映するヘッダーをメッセージに追加します。同様に、JsonToObjectTransformer は JSON をオブジェクトに変換するときにこれらの型ヘッダーを使用できます。これらのヘッダーは AMQP アダプターにマップされるため、Spring-AMQP JsonMessageConverter (Javadoc) と完全に互換性があります。
これにより、次のフローが特別な構成なしで機能します。
…→amqp-outbound-adapter---→---→amqp-inbound-adapter→json-to-object-transformer→…発信アダプターが
JsonMessageConverterで構成され、受信アダプターがデフォルトのSimpleMessageConverterを使用する場合。…→object-to-json-transformer→amqp-outbound-adapter---→---→amqp-inbound-adapter→…発信アダプターが
SimpleMessageConverterで構成され、受信アダプターがデフォルトのJsonMessageConverterを使用する場合。…→object-to-json-transformer→amqp-outbound-adapter---→---→amqp-inbound-adapter→json-to-object-transformer→両方のアダプターが
SimpleMessageConverterで構成されている場合。
ヘッダーを使用して型を判別する場合、class 属性はヘッダーより優先されるため、class 属性を指定しないでください。 |
JSONTransformers に加えて、Spring Integration は式で使用するための組み込み #jsonPath SpEL 関数を提供します。詳細については、Spring 式言語 (SpEL) を参照してください。
バージョン 3.0 以降、Spring Integration には、式で使用するための組み込み #xpath SpEL 関数も提供されています。詳細については、「 #xpath SpEL 関数」を参照してください。
バージョン 4.0 以降、ObjectToJsonTransformer は resultType プロパティをサポートし、ノード JSON 表現を指定します。結果のノードツリー表現は、提供された JsonObjectMapper の実装に依存します。デフォルトでは、ObjectToJsonTransformer は JacksonJsonObjectMapper を使用し、オブジェクトの変換をノードツリーに ObjectMapper#valueToTree メソッドに委譲します。ノード JSON 表現は、ダウンストリームメッセージフローが JSON データのプロパティにアクセスする SpEL 式を使用する場合、JacksonPropertyAccessor を使用する効率を提供します。詳細については、プロパティアクセサーを参照してください。
バージョン 5.1 から、resultType を BYTES として構成して、このデータ型で動作するダウンストリームハンドラーで作業する場合に便利な byte[] ペイロードを持つメッセージを生成できます。
バージョン 5.2 以降では、JsonToObjectTransformer を ResolvableType で構成して、ターゲット JSON プロセッサーでの逆直列化中にジェネリクスをサポートできます。また、このコンポーネントは、最初に JsonHeaders.RESOLVABLE_TYPE または JsonHeaders.TYPE_ID の存在についてリクエストメッセージヘッダーを参照し、それ以外の場合は構成された型にフォールバックするようになりました。ObjectToJsonTransformer は、考えられるダウンストリームシナリオのリクエストメッセージペイロードに基づいて JsonHeaders.RESOLVABLE_TYPE ヘッダーも設定するようになりました。
バージョン 5.2.6 以降では、JsonToObjectTransformer に valueTypeExpression を指定して、ペイロードの ResolvableType を解決し、リクエストメッセージに対して実行時に JSON から変換することができます。デフォルトでは、リクエストメッセージで JsonHeaders を調べます。この式が null または ResolvableType を返す場合、建物が ClassNotFoundException をスローすると、トランスフォーマーは提供された targetType にフォールバックします。JsonHeaders は実際のクラス値を持たない可能性があるため、このロジックは式として存在しますが、一部の外部レジストリに従ってターゲットクラスにマップする必要がある型 ID を持っている可能性があります。
Apache AvroTransformers
バージョン 5.2 には、Apache Avro との間で変換するためのシンプルなトランスフォーマーが追加されました。
スキーマレジストリがないという点で、洗練されていません。トランスフォーマーは、Avro スキーマから生成された SpecificRecord 実装に組み込まれたスキーマを使用するだけです。
SimpleToAvroTransformer に送信されるメッセージには、SpecificRecord を実装するペイロードが必要です。トランスフォーマーは複数の型を処理できます。SimpleFromAvroTransformer は、デシリアライズするデフォルトの型として使用される SpecificRecord クラスで構成する必要があります。setTypeExpression メソッドを使用して、逆直列化する型を決定する SpEL 式を指定することもできます。デフォルトの SpEL 式は headers[avro_type] (AvroHeaders.TYPE)であり、デフォルトでは、SimpleToAvroTransformer によってソースクラスの完全修飾クラス名が設定されます。式が null を返す場合、defaultType が使用されます。
SimpleToAvroTransformer には setTypeExpression メソッドも備わっています。これにより、送信側がヘッダーに型を表すトークンを設定し、コンシューマー側がそのトークンを型にマッピングすることで、プロデューサーとコンシューマーを分離することが可能になります。
プロトコルバッファ Transformers
バージョン 6.1 では、プロトコルバッファ (英語) データコンテンツとの間の変換のサポートが追加されています。
ToProtobufTransformer は、com.google.protobuf.Message メッセージペイロードをネイティブのバイト配列または JSON テキストペイロードに変換します。application/x-protobuf コンテンツ型 (デフォルトで使用) は、バイト配列出力ペイロードを生成します。コンテンツ型が application/json の場合、クラスパス上に com.google.protobuf:protobuf-java-util が見つかった場合はそれを追加すると、出力はテキスト JSON ペイロードになります。コンテンツ型 ヘッダーが設定されていない場合、ToProtobufTransformer はデフォルトで application/x-protobuf になります。
FromProtobufTransformer は、バイト配列またはテキストの protobuf ペイロード (コンテンツ型に応じて) を com.google.protobuf.Message インスタンスに変換します。FromProtobufTransformer は、予期されるクラス型を明示的に指定するか (setExpectedType メソッドを使用)、SpEL 式を使用して、setExpectedTypeExpression メソッドを使用して逆直列化する型を決定する必要があります。デフォルトの SpEL 式は headers[proto_type] (ProtoHeaders.TYPE) で、ソース com.google.protobuf.Message クラスの完全修飾クラス名が ToProtobufTransformer によって設定されます。
例: 次の IDL をコンパイルします。
syntax = "proto2";
package tutorial;
option java_multiple_files = true;
option java_package = "org.example";
option java_outer_classname = "MyProtos";
message MyMessageClass {
optional string foo = 1;
optional string bar = 2;
} 新しい org.example.MyMessageClass クラスを生成します。
次に、以下を使用します。
// Transforms a MyMessageClass instance into a byte array.
ToProtobufTransformer toTransformer = new ToProtobufTransformer();
MyMessageClass test = MyMessageClass.newBuilder()
.setFoo("foo")
.setBar("bar")
.build();
// message1 payload is byte array protocol buffer wire format.
Message message1 = toTransformer.transform(new GenericMessage<>(test));
// Transforms a byte array payload into a MyMessageClass instance.
FromProtobufTransformer fromTransformer = new FromProtobufTransformer();
// message2 payload == test
Message message2 = fromTransformer.transform(message1);アノテーション付きの Transformer の構成
@Transformer アノテーションは、Message 型またはメッセージペイロード型のいずれかを期待するメソッドに追加できます。戻り値は、<transformer> 要素を説明するセクションで前述したのとまったく同じ方法で処理されます。次の例は、@Transformer アノテーションを使用して String を Order に変換する方法を示しています。
@Transformer
Order generateOrder(String productId) {
return new Order(productId);
}Transformer メソッドは、Annotation Support でドキュメント化されているように、@Header および @Headers アノテーションも受け入れることができます。次の例は、@Header アノテーションの使用方法を示しています。
@Transformer
Order generateOrder(String productId, @Header("customerName") String customer) {
return new Order(productId, customer);
}アノテーションを使用したエンドポイントへのアドバイスも参照してください。
ヘッダーフィルター
変換のユースケースは、いくつかのヘッダーを削除するだけの簡単な場合もあります。このような使用例のために、Spring Integration は、出力メッセージから削除する特定のヘッダー名を指定できるヘッダーフィルターを提供します(たとえば、セキュリティ上の理由からヘッダーを削除したり、一時的にのみ必要な値を削除したりします)。基本的に、ヘッダーフィルターはヘッダーエンリッチャーの反対です。後者はヘッダーエンリッチャーで説明されています。次の例では、ヘッダーフィルターを定義しています。
Java DSL
XML
@Bean
public IntegrationFlow someFlow() {
return IntegrationFlow
.from("inputChannel")
.headerFilter("lastName", "state")
.channel("outputChannel")
.get();
}
<int:header-filter input-channel="inputChannel"
output-channel="outputChannel" header-names="lastName, state"/>
ご覧のとおり、ヘッダーフィルターの設定は非常にシンプルです。これは、入力チャネルと出力チャネル、header-names 属性を持つ典型的なエンドポイントです。この属性には、削除するヘッダー名(複数ある場合はカンマで区切る)を指定します。つまり、上記の例では、"lastName" と "state" というヘッダーは送信メッセージに含まれません。
コーデックベースの Transformers
コーデックを参照してください。