Spring Batchにより開発を行ったジョブをWebOTX Batch Server上で動作させる場合、下記の点に注意する必要があります。
Spring Batchによりジョブを実行させる場合、下記のモジュールやリソースを定義する必要がありますが、これらのモジュールやリソースの定義はバッチコンテナが一括して管理・提供するため、利用者は定義する必要がありません。
| モジュール名 | 用途 | コンテナが提供する Bean の ID |
|---|---|---|
| JobRepository | ジョブの実行状態の保存 | jobRepository |
| JobLauncher | ジョブの実行、スレッドの管理 | jobLauncher |
| TransactionManager | トランザクション管理 | transactionManager |
| DataSource | JDBC データソース | ユーザ定義に依存 |
| JobOperator 等 | UI 向けのモジュール | - |
バッチコンテナは上記の名前の Bean を ApplicationContext にバインドしています。そのため、ジョブの定義中に同名の Bean を定義した場合にはジョブのロードに失敗します。
上記モジュールがジョブの定義中に含まれる場合は、コンテナに対する設定に合わせて、ジョブ定義から上記モジュールの指定を削除・修正する必要があります。
Spring Batchでは、利用者の指示でジョブ、および、ステップの実行を停止させる方法が提供されています。
しかし、Spring Batchではチャンク処理の終了時（トランザクションをコミット/ロールバックするタイミング）でのみ停止するか否かの確認を行っています。そのため、チャンクのサイズ(コミットの間隔)を大きく設定している場合、実行中のトランザクションが終了するまで、ジョブの停止が待たされることになります。
WebOTX Batch Serverでは、チャンクの処理の内部でも停止要求の有無を確認し、可能な限り迅速にジョブを停止するためのモジュールを提供しています。
下記のような定義によって、既存のSpring Batch向けのジョブの定義にこのモジュールをアドオンするかたちでWebOTX Batch Serverによるジョブの強制停止機能を利用することができます。
設定方法については、強制停止機能の利用 を参照してください。
Spring Batch V2.0以降で提供している並列ステップ・リモートチャンク・パーティションステップはWebOTX Batch Serverでは未サポートです。
下記のような定義によって、分割したステップフローを並列に処理する方法はWebOTX Batch Serverではサポートしていません。
<split id="split1" task-executor="taskExecutor" next="step4">
<flow>
<step id="step1" parent="s1" next="step2"/>
<step id="step2" parent="s2"/>
</flow>
<flow>
<step id="step3" parent="s3"/>
</flow>
</split>
<step id="step4" parent="s4"/>
Spring Batchでは、チャンクを処理する read-process-write の流れの中で、read と process-write を異なるプロセスで実行するための枠組みを提供しています。
WebOTX Batch Serverでは、このリモートチャンクを実現するための機能は提供していません。
Spring Batchでは一つのステップで処理すべき大量のレコードを分割し、複数のステップで同時に並列実行することができます。
下記のような定義によって、パーティションステップとして定義したステップの動作はWebOTX Batch Serverではサポートしていません。
<bean name="step1:master"
class="org.springframework.batch.core.partition.support.PartitionStep">
<property name="partitionHandler" ref="partitionHandler"/>
<property name="stepExecutionSplitter" ref="stepExecutionSplitter"/>
<property name="jobRepository" ref="jobRepository" />
</bean>
Spring Batchが提供する ExitCodeMapper インタフェースを実装して、ジョブ実行コマンドの終了コードを決定していた場合、WebOTX Batch Serverが提供する ExitCode マッピング機能への移行が必要になります。
WebOTX Batch Serverが提供する ExitCode マッピング機能では、次のようなことが行えます。
例えば、下記のように ExitCodeMapper への COMPLETED でジョブが終了した場合にだけ 0 を返すような ExitCodeMapper を作成している場合、ExitCode マッピングファイルに返却する値を指定するだけで同様の結果を得ることができます。
import org.springframework.batch.core.launch.support.ExitCodeMapper;
public class UserMapper implements ExitCodeMapper {
public int intValue(String exitCode) {
if(exitCode.equals("COMPLETED")) {
return 0;
}
return 1;
}
}
webotx.batch.exit.default=1 webotx.batch.exit.status.COMPLETED=0
WebOTX Batch Server のシステム構成は下図の通りです。 バッチドメインには唯一のバッチドメインエージェントが存在し、バッチアプリケーションを処理するためのバッチコンテナを制御します。
ドメインエージェントは配備されたジョブの制御要求を受け付け、コンテナ上のジョブの開始、停止、強制停止を行います。
以下に、システムの各構成要素についての説明を記述します。
WebOTX Batch Server における運用管理の単位です。
ドメインには単一のドメインエージェントが存在します。
ジョブ実行プロセスの管理単位です。
1以上のコンテナプロセスを含みます。
WebOTX Batch Server におけるアプリケーションの管理単位です。コンテナへの配備対象を指定する単位でもあります。
バッチアプリケーショングループ名の既定値は、 default です。
1以上のバッチアプリケーションを含みます。
WebOTX Batch Server におけるアプリケーションの管理単位です。
バッチアプリケーション名の既定値は、 default です。
単一の バッチアプリケーション名.xml というファイル名のジョブ定義ファイルと、複数のJavaクラスファイル、および、その他リソースファイルを含みます。
ジョブ定義ファイルには、1以上のジョブ、および、ステップの定義を含めることができます。
ジョブは、WebOTX Batch Server におけるアプリケーションの管理単位であり、 １つ以上のステップによって構成されます。ジョブはJobLauncherによって起動され、定義に従って１つ以上のステップを実行します。 ジョブは、ジョブの名前、ステップの定義とその実行順序などを定義します。
ステップの基本的な動作は、ItemReaderにより読み込んだレコードをItemProcessorによって加工し、 ItemWriterによって書き込みを行うというものです。これらの処理中にはジョブの実行状態の保存を行うJobRepositoryへの読み書きを行います。 必要に応じてJavaのコードを記述し、ステップの処理中に使用することが可能です。
ジョブ制御コマンド、および、コンテナ制御コマンド実行時に、指定するユーザです。
WebOTX Batch Server では、OSのユーザ管理、認証機構を利用して、各種操作要求受け付け時の認証を行います。
WebOTX Batch Server では、各アカウントに対して、操作の権限管理を行う単位であるロール(権限)を設定することができます。
WebOTX Batch Server の実行環境は下図に示すとおりで、主に、バッチドメインエージェントプロセスとバッチコンテナプロセスとコマンドプロセスによって構成されます。 それぞれについて以下で説明します。
ドメインを構成する中心の常駐プロセスです。ドメインエージェントは、各種操作コマンドの要求を受け付けるエントリポイントであるとともに、ドメインを一元的に管理します。
ドメインエージェントはジョブ制御要求を受け付け、コンテナ上のジョブの開始、停止、強制停止を行います。 ジョブの実行に際して、ドメインエージェントはコマンドやAPIからのジョブリクエストを受け付け、 同プロセス上のジョブリクエストキューに格納します。格納されたジョブリクエストは、 ドメインエージェントにより実行可能なコンテナプロセス（ジョブリクエストのジョブが配備されている、かつ、 稼動状態のコンテナプロセス）に振り分けます。 ジョブリクエストが振り分けられたコンテナプロセス上では、ジョブリクエストおよびジョブ定義を基に、 Contextが生成されジョブが開始されます
バッチコンテナはジョブを実行するために必要なモジュールを管理・構成し、バッチアプリケーションをロードしてジョブを実行可能な状態にします。 バッチコンテナは一つのバッチドメイン上に複数定義することができ、その複数のバッチコンテナそれぞれ毎に定義を保持します。 また、バッチコンテナはプロセス多重度の設定により、単一バッチコンテナで複数バッチコンテナプロセスを同時に動作させることができます。
ドメインエージェントによってジョブリクエストキューに登録されたジョブ開始リクエストに応じて、順次コンテナプロセス上のジョブ実行制御を呼び出すことでジョブを実行します。 コンテナプロセス上では、ジョブ実行制御に対して指示されたジョブは、アプリケーションアクセス制御で指定されたアクセス権の範囲内で処理を実行します。
コマンドプロセスはJavaによる制御コマンドと、ネイティブ実装によるジョブ実行コマンドを使用することができます。 コマンドからジョブリクエストの投入要求を受けジョブリクエストキューにリクエストを格納する際、そのジョブリクエストに指定されているジョブ名・ユーザ名のジョブを処理可能なバッチコンテナが存在するかどうかを確認し、 受入可能なジョブリクエストである場合にのみジョブリクエストキューにリクエストを格納します。 受入不可であった場合は、即時にコマンドへエラーを返却します。
ジョブを実行するためには、実行対象のジョブをコンテナに配備しておく必要があります。
配備はジョブをバッチアプリケーションアーカイブ形式でアーカイブした後、運用管理コマンドを利用して対象のドメイン・コンテナへ転送・有効化することで行います。
バッチアプリケーショングループ sampleGroup が下記のフォルダ構成で作成されているとして、以降のアーカイブ操作を説明します。
sampleGroup/ | ||||||
lib/ | : アプリケーショングループライブラリフォルダ | |||||
sample.jar | ||||||
sampleApp1/ | : アプリケーションフォルダ | |||||
sampleApp1.xml | : ジョブ定義ファイル | |||||
lib/ | : アプリケーションライブラリフォルダ | |||||
ap.jar | ||||||
classes/ | : アプリケーションクラスフォルダ | |||||
sample.properties | ||||||
sampleApp2/ | : アプリケーションフォルダ | |||||
sampleApp2.xml | : ジョブ定義ファイル | |||||
lib/ | : アプリケーションライブラリフォルダ | |||||
ap2.jar | ||||||
sampleGroupフォルダが存在するフォルダ内で、下記のようにjarコマンドを実行することで、sampleGroup.jarという名前のバッチアプリケーショングループアーカイブファイルが作成されます。
> ls sampleGroup > jar cMf sampleGroup.jar -C sampleGroup . > ls sampleGroup sampleGroup.jar > jar tf sampleGroup.jar lib/ lib/sample.jar sampleApp1/ sampleApp1/classes/ sampleApp1/classes/sample.properties sampleApp1/lib/ sampleApp1/lib/ap1.jar sampleApp2/ sampleApp2/lib/ sampleApp2/lib/ap2.jar
配備には、otxadmin install-bs-batchapgroupコマンド、および、otxadmin enable-bs-batchapgroupを使用します。
ジョブ配備の詳細手順については、WebOTX Batch Server 運用・利用ガイド バッチアプリケーションの配備 を参照してください。
実行対象のジョブがコンテナに配備された状態で、jobctlコマンドのstartもしくは、start-jobコマンドにより、 ジョブを実行することができます。
ジョブ実行の詳細手順については、WebOTX Batch Server 運用・利用ガイド ジョブの実行 を参照してください。
ジョブの実行状態・結果確認は、 jobctlコマンドのstatus , result、および、result-jobコマンド、status-jobコマンドコマンドを用いて行います。 jobctlコマンドのresult、および、result-jobコマンドはジョブの結果を取得します。 startコマンドで指定したオプションと同一のjobname, jobParametersを指定して、 そのジョブの実行結果(コマンドの戻り値とジョブ実行ログ)を取得します。
また、jobctlコマンドのstatus、および、status-jobコマンドは 開始済みジョブの状態に応じたコマンドの戻り値を返します。
ジョブの実行、停止、異常等のイベントをログに記録します。 ジョブ実行ログは、INSTANCE_ID毎に出力し、ローテートは行いません。 ${DOMAIN_HOME}/logs/batch/<ユーザー名>/<バッチアプリケーショングループ名>/<バッチアプリケーション名>/<ジョブ名>配下に、 INSTANCE_ID毎の別々のログファイルが次のフォーマットのファイル名で作成されます。
<ジョブ名>_<INSTANCE_IDを16桁の16進数表記>.log
ジョブ実行中にこのログファイルに書き込まれたログが、jobctl startコマンドやstart-jobコマンドの標準出力に表示されます。
また、${DOMAIN_HOME}/logs/batch/<コンテナ名>/allExecution_<コンテナシーケンス番号>.logに そのコンテナシーケンス番号のコンテナプロセスで実行した全てのジョブのログをまとめて出力するログファイルが作成されます。
ジョブ実行ログに利用者任意のログを出力する場合、 ${DOMAIN_HOME}/config/batch/logging/log4j.xmlに利用者独自のLoggerを追加し、 Appenderに"executionLog"を設定してください。 設定を追加する場合、下記のように「利用者によるLoggerの追加 ここから - ここまで」コメントの間に 設定を追加するようにしてください。
<!-- 利用者によるLoggerの追加 - ここから -->
<logger name="sample.user.UserExecutionLog" additivity="false">
<level value="INFO" />
<appender-ref ref="executionLog" />
</logger>
<!-- 利用者によるLoggerの追加 - ここまで -->
また、ジョブ実行ログ以外にもLog4Jを利用した利用者独自のログを出力したい場合には、 上記のlog4j_container_settings.xmlを修正してください。
Spring Batchは、あるバッチアプリケーションを実行するときにCommandLineJobRunnerを使用している場合、その実行毎にJVMを起動して実行を行います。 したがって、複数のバッチアプリケーションを実行するときにはその数だけJVMを起動する必要があります。
これに対して WebOTX Batch Server は、バッチドメインエージェントプロセスとバッチコンテナプロセスとコマンドプロセスによって構成され、
常駐するバッチコンテナプロセス上の複数スレッドを用いてバッチアプリケーションを実行します。
これにより、複数のバッチアプリケーションを同時に実行するときに、その数だけJVMを起動する必要がなく、メモリの使用量を抑えることが可能となります。
ただし、ジョブの実行を行うためには、ドメインエージェントとバッチコンテナを起動しておく必要があることに注意してください。
また、 WebOTX Batch Server では実行多重度設定に基づいて、単一プロセス内において複数スレッドを用いたジョブの多重実行が行われ得るため、
WebOTX Batch Server 上で実行するバッチアプリケーションの実装にはスレッドセーフ性の考慮が要求されることに注意してください。
一例としては、CommandLineJobRunner を使用して実行毎にJVMを起動されている場合には問題とならない、static フィールドに起因する競合の問題が顕在化する可能性などがあります。
Spring Batch の CommandLineJobRunner を使用している場合、 ジョブの中からジョブを実行したコマンドの標準出力・標準エラー出力に直接メッセージが出力されます。
これに対して WebOTX Batch Server では、 実際にジョブを実行するバッチコンテナのプロセスと、ジョブを実行するコマンドプロセスとが異なるため、 ジョブの中からメッセージを直接ジョブ実行時のコンソールに出力することができません。
そこで Batch Serverでは、ログファイルに出力したジョブ実行ログをジョブ実行コマンドの標準出力に
表示する機能を提供しています。
さらに、ジョブの中でcom.nec.webotx.batch.util.BSJobExecutionLogUtil クラスを利用することで、
ジョブ実行ログに利用者のログを記録することができるようにしています。これによりジョブの中からコマンドのジョブ実行時のコンソールの標準出力に
メッセージを出力することができます。
詳細は 2.3.2. ジョブ実行ログへのログ出力 を参照してください。
コマンドプロセスの終了コードは、ジョブ終了時のExitStatusとBatchStatusの組合せをもとに決定されます。
このとき、利用者が指定した終了コードでコマンドを終了するために、
ジョブ終了時のExitStatusとBatchStatusの組合せとコマンドの終了コードのマッピングを行うことができます。
このマッピング機能はジョブ実行コマンド（startとresult）の場合にのみ有効になり、その他のジョブ制御コマンドには影響を与えません。 また、BS固有エラーが発生した場合のコマンドプロセスの終了コードにも影響を与えません。
ExitCodeマッピングの設定は${DOMAIN_HOME}/config/batch/exitcode/mapping.propertiesファイルに記述します。 Spring BatchのComandLineJobLuncherを用いてジョブを実行する場合、ジョブ終了時の戻り値はジョブのExitStatusをもとに決定されます。 これに対して、WebOTX Batch Server では前述のとおり、ジョブ終了時のExitStatusとBatchStatusの組合せをもとに決定されます。 したがって、アプリケーションを開発する際の、戻り値のハンドリングに関しては、BatchStatusも考慮して行う必要があることに注意してください。
Batch Serverはジョブのアプリケーションコンテキストを
org.springframework.context.support.FileSystemXmlApplicationContext
によって読込みます。
そのため、ジョブ定義ファイル内でリソースへのパスを指定する際に、
file:、classpath:を省略するとfile: が指定されている場合と同様のパスを解決しようとします。
リソースパスの指定を行う際は、クラスパス上のパスなのかファイルシステム上のパスなのかを 明示的に指定するようにしてください。
Spring Batch の CommandLineJobRunner を使用している場合、ジョブを実行するコマンドに設定される環境変数や Javaのシステムプロパティをジョブの内部で読込むことが可能です。
これに対して WebOTX Batch Server では、 実際にジョブを実行するバッチコンテナのプロセスと、ジョブを実行するコマンドプロセスとが異なるため、 コマンド実行側で設定されている環境変数やJavaのシステムプロパティを読込むことはできません。
コマンド実行時に指定したい動的なパラメータは、ジョブパラメータとしてコマンドの引数で指定する必要があります。
また、静的なパラメータとして環境変数やJavaシステムプロパティをジョブで利用する場合は、
ドメイン共通の設定ファイルかコンテナ単位の設定ファイルに
環境変数やJavaシステムプロパティの設定を追加してください。
Spring Batch用に実装されたアプリケーションを、WebOTX Batch Server に移行する場合、以下の点に注意する必要があります。