Spring Batch 5.2 の新機能

このセクションでは、Spring Batch 5.2 の主な変更点について説明します。変更点の完全なリストについては、リリースノート [GitHub] (英語) を参照してください。

Spring Batch 5.2 には次の機能が含まれています。

依存関係のアップグレード
MongoDB ジョブリポジトリのサポート
新しいリソースレスジョブリポジトリ
複合アイテムリーダーの実装
java.util.function API の新しいアダプター
ブロッキングキューアイテムリーダーとライターによる同時ステップ
JPA アイテムリーダーでのクエリヒントのサポート
JDBC アイテムリーダーでのデータクラスのサポート
RecursiveCollectionLineAggregator で設定可能な行区切り
求人登録の改善

依存関係のアップグレード

このリリースでは、Spring の依存関係が次のバージョンにアップグレードされます。

Spring Framework 6.2.0
Spring Integration 6.4.0
Spring Data 3.4.0
Spring Retry 2.0.10
Spring LDAP 3.2.8
Spring AMQP 3.2.0
Spring Kafka 3.3.0
Micrometer 1.14.1

MongoDB ジョブリポジトリのサポート

このリリースでは、MongoDB を基盤とする最初の NoSQL ジョブリポジトリ実装が導入されています。リレーショナルジョブリポジトリ実装と同様に、Spring Batch には、バッチメタデータを保存および取得するために MongoDB で必要なコレクションを作成するスクリプトが付属しています。

この実装には MongoDB バージョン 4 以降が必要で、Spring Data MongoDB に基づいています。このジョブリポジトリを使用するには、新しく追加された MongoJobRepositoryFactoryBean に必要な MongoTemplate と MongoTransactionManager を定義するだけです。

@Bean
public JobRepository jobRepository(MongoTemplate mongoTemplate, MongoTransactionManager transactionManager) throws Exception {
	MongoJobRepositoryFactoryBean jobRepositoryFactoryBean = new MongoJobRepositoryFactoryBean();
	jobRepositoryFactoryBean.setMongoOperations(mongoTemplate);
	jobRepositoryFactoryBean.setTransactionManager(transactionManager);
	jobRepositoryFactoryBean.afterPropertiesSet();
	return jobRepositoryFactoryBean.getObject();
}

MongoDB ジョブリポジトリを定義したら、それを通常のジョブリポジトリとして任意のジョブまたはステップに挿入できます。完全な例は MongoDB ジョブリポジトリ統合テスト [GitHub] (英語) にあります。

新しいリソースレスジョブリポジトリ

v5 では、メモリ内マップベースのジョブリポジトリ実装がいくつかの理由で削除されました。Spring Batch に残された唯一のジョブリポジトリ実装は、データソースを必要とする JDBC 実装でした。これは H2 や HSQLDB などのメモリ内データベースではうまく機能しますが、追加の依存関係なしでマップベースのリポジトリを使用していたコミュニティの多くのユーザーにとって、データソースが必要であることは大きな制約でした。

このリリースでは、バッチメタデータをいかなる形式でも使用または保存しない (メモリ内も含め) JobRepository 実装を導入します。これは、バッチメタデータを破棄し、いかなるリソースともやり取りしない "NoOp" 実装です (そのため、「リソースレスジョブリポジトリ」という名前が付けられており、「リソースレストランザクションマネージャー」にちなんで名付けられています)。

この実装は、再起動が不要で、実行コンテキストがまったく関与しないユースケース (実行コンテキストを介してステップ間でデータを共有する場合や、パーティションメタデータが実行コンテキストを介してマネージャーとワーカー間で共有されるパーティション化されたステップなど) を対象としています。

この実装は、独自の JVM で実行される 1 回限りのジョブに適しています。トランザクションステップ (たとえば、DataSourceTransactionManager で構成) と非トランザクションステップ ( ResourcelessTransactionManager で構成) の両方で動作します。この実装はスレッドセーフではないため、同時実行環境では使用しないでください。

複合アイテムリーダーの実装

CompositeItemProcessor および CompositeItemWriter と同様に、同じ形式の複数のソースからデータを順番に読み取るように設計された新しい CompositeItemReader 実装を導入します。これは、データが異なるリソースに分散していて、カスタムリーダーを作成することができない場合に役立ちます。

CompositeItemReader は、読み取り操作を通常のアイテムリーダーに順番に委譲することで、他の複合アーティファクトと同様に機能します。以下は、フラットファイルから人物データを読み取る複合リーダー、次にデータベーステーブルから人物データを読み取る複合リーダーの簡単な例です。

@Bean
public FlatFileItemReader<Person> itemReader1() {
    return new FlatFileItemReaderBuilder<Person>()
            .name("personFileItemReader")
            .resource(new FileSystemResource("persons.csv"))
            .delimited()
            .names("id", "name")
            .targetType(Person.class)
            .build();
}

@Bean
public JdbcCursorItemReader<Person> itemReader2() {
    String sql = "select * from persons";
    return new JdbcCursorItemReaderBuilder<Person>()
            .name("personTableItemReader")
            .dataSource(dataSource())
            .sql(sql)
            .beanRowMapper(Person.class)
            .build();
}

@Bean
public CompositeItemReader<Person> itemReader() {
    return new CompositeItemReader<>(Arrays.asList(itemReader1(), itemReader2()));
}

java.util.function API の新しいアダプター

java.util.function.Function をアイテムプロセッサーに適合させる FucntionItemProcessor と同様に、このリリースでは、Supplier、Consumer、Predicate などの他の java.util.function インターフェース用の新しいアダプターがいくつか導入されています。

新しく追加されたアダプターは SupplierItemReader、ConsumerItemWriter、PredicateFilteringItemProcessor です。これらの新しいアダプターの詳細については、org.springframework.batch.item.function [GitHub] (英語) パッケージを参照してください。

ブロッキングキューアイテムリーダーとライターによる同時ステップ

ステージングイベントドリブンアーキテクチャ [Wikipedia] (英語) (SEDA) は、キューで接続されたステージでデータを処理する強力なアーキテクチャスタイルです。このスタイルはデータパイプラインに直接適用でき、ジョブを一連のステップとして設計できるため、Spring Batch に簡単に実装できます。

ここで唯一欠落しているのは、中間キューからデータを読み書きする方法です。このリリースでは、BlockingQueue からデータを読み書きするためのアイテムリーダーとアイテムライターが導入されています。これら 2 つの新しいクラスを使用すると、キューにデータを準備する最初のステップと、同じキューからデータを使用する 2 番目のステップを設計できます。このようにして、両方のステップを同時に実行して、ノンブロッキングのイベント駆動型でデータを効率的に処理できます。

JPA アイテムリーダーでのクエリヒントのサポート

バージョン 5.1 までは、JPA カーソルおよびページングアイテムリーダーはクエリヒント (フェッチサイズ、タイムアウトなど) をサポートしていませんでした。カスタムヒントを指定するには、ユーザーはカスタムクエリプロバイダーを提供する必要がありました。

このリリースでは、使用する JPA クエリを定義するときにクエリヒントを受け入れるように JPA リーダーとそれぞれのビルダーが更新されました。

JDBC アイテムリーダーでのデータクラスのサポート

このリリースでは、JDBC カーソルおよびページング項目リーダーのビルダーに新しいメソッドが導入され、項目の型がデータクラス (Java レコードまたは Kotlin データクラス) の場合にユーザーが DataClassRowMapper を指定できるようになりました。

dataRowMapper(TargetType.class) という新しいメソッドは beanRowMapper(TargetType.class) に似ており、通常のクラス (Java Bean) とデータクラス (Java レコード) 間で行マッパーの構成を一致させるように設計されています。

RecursiveCollectionLineAggregator で設定可能な行区切り

これまで、RecursiveCollectionLineAggregator の行区切りプロパティは、システムの行区切り値に設定されていました。システムプロパティを通じて値を変更することは可能ですが、この構成スタイルはバッチ成果物の他のプロパティと一致しません。

このリリースでは、RecursiveCollectionLineAggregator に新しい setter が導入され、ユーザーはシステムプロパティを使用せずに行区切りのカスタム値を構成できるようになりました。

求人登録の改善

バージョン 5.1 では、バッチインフラストラクチャ Bean のデフォルト構成が更新され、アプリケーションコンテキストで JobRegistryBeanPostProcessor Bean を定義することでジョブレジストリが自動的に入力されるようになりました。Spring Framework の最近の変更により BeanPostProcessorChecker のログレベルが変更されたため、一般的な Spring Batch アプリケーションで JobRegistryBeanPostProcessor に関連するいくつかの警告が記録されました。これらの警告は、JobRegistryBeanPostProcessor が JobRegistry Bean に依存していることが原因で発生します。これは推奨されておらず、Bean ライフサイクルの課題を引き起こす可能性があります。

これらの課題は、このリリースで、JobRegistry を設定するメカニズムを BeanPostProcessor から SmartInitializingSingleton を使用するように変更することで解決されました。JobRegistryBeanPostProcessor は廃止され、代わりに新しく追加された JobRegistrySmartInitializingSingleton が採用されました。