-
Notifications
You must be signed in to change notification settings - Fork 0
JSR 352 1.0 Final Release.pdfのテキトーな翻訳
JSR-000352 Batch Applications for the Java Platform - Final Release からダウンロードできるJSR-000352 Batch Applications for the JavaTM Platform 1.0 Final Release for Evaluation（JSR-352-1.0-Final-Release.pdf）いわゆるjBtchのテキトーな翻訳。
このwikiの文章は、JSR 352読んで訳したものですが、個人的なjBatch勉強の副産物にすぎません。そのため、俺のテキトーな翻訳が元で、何らかの不利益を被ったとしても、これといって責任は負えないのでよろしくして、どうぞ。
名詞の翻訳について。jBatch固有の名詞として、job,step,batchlet,chunkなどなどがあります。基本的に、それらはそのまま英字のままで、カタカナでジョブ・ステップ・バッチレット・チャンクなどとは書いていません。ただ、step level listenerとかはカタカナで「ステップレベルリスナー」と書いたほうが座りが良いかなぁ？ と思い、そういうケースはカタカナで書いています。レベルとかリスナーとかはカタカナでも十分馴染みのある単語なんで、そうした単語で組み合わせられる場合は、そちらに合わせた、といったとこです。
……としっても、標記揺れやら誤字やらは完全に消せてはいないだろうけど、お察し下さい。
Batch Applications for the Java Platform
Version 1.0
Final Release
Chris Vignola
18 April 2013
Java Batch specification("仕様(Specification)")のIBM Corporation("Spec Lead")は、本仕様書により、手数料や使用料なしにいかなる媒体においても、仕様の複製と表示の許可を与えます。ただし、複製の全てもしくはその一部を含めて下さい。
- 仕様へのリンクもしくはURL
http://jcp.org/aboutJava/communityprocess/final/jsr352/index.html - ここで示される著作権表示
Spec Leadは、ライセンス可能著作権の下で取り消し不能なライセンスに、恒久的で、非独占の、ワールドワイドな、全額払い込み(fully paid-up)の、著作権使用料無料の許可を与えます。また、下記を条件として、仕様実装過程における違反回避が技術的に実現可能な方法が無い特許クレームに応じます。
- 要求されるインタフェースと機能を含む、仕様の完全な実装。
- 仕様の名前空間を、修正、サブセット、スーパーセットまたは拡張をしていない。
- この仕様のTCKをパスしている。
- 仕様の要求部分を実装するための任意の特許と互恵的なライセンス(reciprocal license)を結ぶ。また、Java Specification Participation Agreementの6.A節の規定と整合性が取れている必要がある。
（以下、まだ訳せてない部分）
THE SPECIFICATION IS PROVIDED "AS IS," AND THE SPEC LEAD AND ANY OTHER AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. THE SPEC LEAD AND ANY OTHER AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SPECIFICATION OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.
The name and trademarks of the Spec Lead or any other Authors may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the Specification will at all times remain with the Authors. No other rights are granted by implication, estoppel or otherwise.
多くの個人がこの仕様を作成するために貢献をして頂いたことに深い感謝をしております。
- Kevin Conner
- Tim Fanelli
- Cheng Fang
- Mahesh Kannan
- Scott Kurz
- Wayne Lund
- Simon Martinelli
- Michael Minella
- Kaushik Mukherjee
- Joe Pullen
この仕様は、ジョブ定義言語(job specification language)、Javaプログラミングモデル(Java programming model)、Javaプラットフォームのためのバッチアプリケーションのランタイム環境(*1)について説明します。また、この仕様はJava SEとJava EEの両方で動作するように設計されています。加えて、DIコンテナ上で動作するようにも設計されていますが、特定のDI実装には依存していません。
*1 runtime environment for batch applications for the Java platform. この訳文では「ランタイム」か「バッチランタイム」としている
（省略）
バッチ処理は、個々のアプリケーション組織と実行モデルによって表現され、ワークロードのパターンは良く知られています(*1)。バッチ処理はほぼすべての産業で見られ、ステートメント生成(*2)のようなタスクに適用されたり、銀行の自動引き落とし(*3)をしたり、リスク評価や、クレジットスコア計算、在庫管理や、ポートフォリオ最適化、などの例が挙げられます。いずれのビジネス分野においてバルク処理のタスクはたいていバッチ処理の候補となります。
バッチ処理は、バルク処理で、非対話式で、バックグラウンド実行の特徴を持ちます。大抵は長時間実行で、データや計算主体のタスクで、シーケンシャルにもパラレルにも実行され、様々な呼び出しモデルで開始され、アドホック・定期的・必要に応じて実行されます。
バッチアプリケーションは共通の要求を持ち、それは、ログ出力、チェックポイント、パラレル実行です。バッチワークロードも共通の要求を持ち、特にバッチの動作制御で、バッチインスタンスとの対話形式で、開始・停止・リスタートが出来るものです。
*1 イマイチビミョーな役だが、序文なんで勘弁してもらいたい。application organizationってぐぐるとIBMのページが出てくるが、彼ら由来の用語なのだろうか？
*2 statement generationでぐぐると金融工学とかそっちの専門用語らしい
*3 bank postings http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q12116654227 はこれを見る限り＆バッチ処理の文脈的に月一回の自動引き落としのことと思われる
この仕様はJava SEとJava EE環境に適用され、Java 6以上を要求します。
経験豊富なバッチアーキテクトにとって、JSP 352を使用したバッチ処理の包括的なコンセプトは彼らにとって身近で快適なものでなければなりません。JSR 352には、ジョブ"Jobs"とステップ"Steps"と開発者に提供されるものとしてはItemReadersとItemWritersがあります。しかし、JSR 352のオペレーション・コールバック・イディオムにより、以下のような可能性が生まれます。
- 関心事の分離を明確な取り扱い
- インターフェースとして提供されるサービスとアーキテクチャレイヤーの明確な線引き
- 大幅に強化される拡張性
下記の図は、何年もの間使われてきた、バッチ参照アーキテクチャの単純なバージョンを示しています。下図はまた、バッチ処理のドメイン言語を構築するためのコンポーネントの概要でもあります。このアーキテクチャフレームワークの青写真は最近数世代のプラットフォーム（COBOL/Mainframe, C++/Unix, Javaほか色々）の実装で長年に渡り実績を積んできました。JCLとCOBOLの開発者にとってもC++, C#, Javaの開発者にとってもこのコンセプトは慣れ親しんだものでしょう。JSR 352が規定するのは、レイヤ、堅牢なシステムで共通に見られるサービスとコンポーネント、複雑なバッチアプリケーションを簡単に組み立てるために使用する保守システム、から成ります。
■図（さすがにPDFからコピってくるのはどうかと思ったので空にしている）
上の図はバッチのドメイン言語を構築するキーコンセプトを強調しています。一つのjobが一対多のstepを持ち、各stepはただ単に一つずつItemReader, ItemProcessor, ItemWriterを持っています。jobはJobOperatorが起動する必要があり、現在実行中のプロセスのメタデータはJobRepositoryに保存されている必要があります。
jobとは、バッチ処理全体をカプセル化するエンティティで、ジョブ定義言語により定義されます。また、jobは階層全体のトップに位置します。
■■■■■■■■■■■■■■■■■■■■■図
JSR 352では、jobは単にstepを含むコンテナです。flow内で論理的に関連のある複数のstepを結びつけたり、リスタート設定のようなすべてのstepにグローバルなプロパティ設定をしたりします。jobの設定は以下の通りです。
- job名の指定
- step実行順序の定義
- jobがリスタート可能かどうか
JobInstanceとは、論理的なjob実行のコンセプトのことを指しています。ここで、上図での'EndOfDay'ジョブのような一日の終わりに一度実行されるバッチジョブを考えてみます。ここには一つの'EndOfDay'ジョブが存在し、個々のジョブ実行は別々に記録される必要があります。このジョブの場合では、一日に一つの論理的なJobInstanceが作られるでしょう。たとえば、1月1日に実行し、1月2日に実行します。もし1月1日の初回実行は失敗して翌日に再実行する場合、1月1日が実行されます。たいていは日付と処理対象のデータは一致し、つまり、1月1日の実行が処理するデータは1月1日です。それゆえに、それぞれのJobInstanceは複数の実行(JobExecutionの詳細は後に解説されます)を持つことが出来ます。特定のjobに対応する一つ以上のJobInstancesは所定の時間に実行可能です。
JobInstanceの定義はロードされるデータとは全く関係がありません。ItemReaderの実装がどのようにデータがロードされるかを決定するので、それ次第です。たとえば、EndOfDayシナリオでは、'effective date'とか'schedule date'などのデータに関するカラムにデータが入れられています。そして、1月1日の実行はその日のデータのみをロードし、1月2日の実行は2日のデータのみを実行します。これはおおむねビジネス上の要求から決定されるものなので、ItemReaderに一任されます。同一のJobInstanceを使用するという決定は、以前の実行の'状態'が新しい実行に適用可能かどうか、によります。新しいJobInstanceを使用することは'最初から開始'を意味し、すでに存在するインスタンスを使用することはおおむね'中断の再開'を意味します。
jobパラメータは、jobが開始やリスタートされるときに毎回指定することができます。jobパラメータはkeyword/value形式の文字列の組み合わせです。JobOperatorの開始とリスタート操作はjobパラメータ仕様をサポートします。JobOperatorの詳細については10.4節を参照してください。
JobExecutionは、ある一つのjob実行の技術的なコンセプトのことを指しています。jobが開始されたりリスタートされるときは毎回、新しいJobExecutionが生成され、同一のJobInstanceに属します。
Stepとは、バッチジョブの連続したフェーズを独立してカプセル化するドメインオブジェクトです。それゆえ、どのjobもたいてい一つ以上のstepで構成されます。stepはバッチ処理を制御したり定義したりするのに必要な情報のすべてを持ちます。漠然とした記述ですが、なぜなら任意のstepは開発者の自由裁量に任せられているからです。あるstepは単純にも開発者が望む通りに複雑にもできます。あるいは、単純なstepはデータベースからデータをロードするのに、実装に依存しますが、コードをほんの少しもしくは全く必要としないかもしれません。より複雑なstepは、処理の一部分に複雑なビジネスロールを持つかもしれません。jobと同様に、stepはユニークなJobExecutionに対応する個々のStepExecutionを持ちます。
■図
StepExecutionとは、stepを実行する一つの試行単位です。新規のStepExecutionは、JobExecutionと似たように、stepが実行される度に生成されます。しかしながら、もし、あるstepがそれより前のstepが原因で実行に失敗する場合、続けての実行は行われません。StepExecutionはそのstepが開始されれるときにのみ生成されます。
JobOperatorは、開始・リスタート・停止のような操作コマンドに、jobの検索・実行のようなジョブリポジトリ関連のコマンドを含む、ジョブ処理のすべてのアスペクトを管理するインタフェースを提供します。JobOperatorの詳細については10.4節を参照してください。
ジョブリポジトリは現在実行中のjobと過去に実行されたjobについての情報を保持しています。JobOperatorインターフェースはリポジトリへのアクセス手段を提供します。リポジトリには、jobインスタンス・job実行・step実行が含まれます。より詳細な情報については、10.9.8, 10.9.9, 10.9.10節をそれぞれ参照してください。
ジョブリポジトリの実装はこの仕様の範囲外なことに注意してください。
ItemReaderは、stepで一度に一アイテムを入力・検索することを抽象化した表現です。ItemReaderは、提供されるアイテムが一杯になったときの指標を用意します(*1)。ItemReaderの詳細な情報については、9.1.1.1節を参照してください。
*1 ビミョウな日本語だが、既定件数読み込んだら書き込み処理に移る、って意味かと
ItemWriterは、一つのバッチもしくは一回のchunkのアイテムや、stepの出力を表現することを抽象化したものです。通常、ItemWriterは受け取る入力のことは関知せず、現在の実行で渡されたアイテムのみを処理します。ItemWriterのより詳細な情報については、9.1.1.3節をそれぞれ参照してください。
ItemProcessorは、アイテムに対するビジネスロジックを抽象化した表現です。ItemReaderが一つ一つアイテムを読み込み、ItemWriterがそれらを書き込み、ItemProcessorはその他のビジネスロジックを適用したり変形したりする手段を提供します。ItemWriterのより詳細な情報については、9.1.1.2節をそれぞれ参照してください。
JSR 352は、主なパターンとして'チャンク指向(Chunk Oriented)'の処理形態を定義しています。チャンク指向の処理は、トランザクション境界の内側で、一回に一アイテムを読み込んで、書き込み用に'chunk'を作成します。一つのアイテムがItemReaderで読み込まれたら、ItemProcessorに渡され、そして集約されます。読み込まれたアイテム数がコミット間隔に等しくなったら、ItemWriterでchunkが書き込まれ、トランザクションがコミットされます。
■図
大規模データ処理をするバッチアプリケーション - とりわけ長時間実行するもの - の共通な要求はチェックポイント/再開です。チェックポイントは、stepの実行を整合性のある最終地点からリスタートを可能にするために現在の進行状況を、定期的にブックマークします。
チェックポイントは必然的にチャンク指向処理で動作します。チェックポイント取得が自然にされる地点は、chunkごとの処理の終わりになります。
JSR 352はチェックポイント/リスタートのランタイムサポートをどんなチャンク指向のバッチstepにおいても使用可能な一般的な方法を定義します。
step実行の間、進行状況はイコール入出力データの現在位置を返す関数そのものなので、この関数が示唆することは、現在の位置を保存/復元することはreader/writerの責務である、と言えます。
step実行を管理することはランタイムの責任なので、バッチランタイムは必然的に初回起動・終了ステータス実行・リスタートを含むstep実行のライフサイクルを理解していなければなりません。
チェックポイントはしばしば、ロック保持時間に直接的な影響を及ぼすので、チェックポイント間隔のチューニングはシステム全体のスループットと深い関係があります。
ジョブ定義言語（Job Specification Language (JSL)）は、jobとそれに含まれるstepとその実行指示を定義します。JSR 352のJSLはXMLで実装されこれ以降は"Job XML"と呼称します。
'job'要素はジョブを示します。
文法:
<job id="{name}" restartable="{true|false}">入力(*1):
| id | 様々な目的に使用されるjobの論理名を定義します。妥当なXML文字列でなければなりません。必須項目。 |
| restartable | jobが再開可能かどうかを定義します。trueかfalseのどちらかです。オプション項目で、デフォルトはtrueです。 |
*1 原文だとWhereだけど一般的には何と訳すのだろうか？ 変数？
job実行をインターセプトするためにジョブレベルリスナーを設定できます。このリスナー要素はjob要素の子要素として定義できます。ジョブリスナーはジョブレベルリスナーとして定義される唯一のリスナータイプです。
複数のリスナーをjobに設定できます。しかし、実行順序については何も保障されません。
文法:
<listeners>
<listener ref="{name}">
...
</listeners>入力:
| ref | バッチアーティファクト名を指定します。 |
ジョブレベルリスナーによってスローされる未処理例外はバッチステータスFAILEDでの終了を引き起こします。
'properties'要素はjob要素の子要素として定義できます。jobに属するバッチアーティファクトやバッチランタイムでプロパティを参照できます。任意の数のプロパティを定義できます。ジョブレベルプロパティはJobContextランタイムオブジェクトを通して利用します。JobContextの詳細については9.4節を参照してください。
文法:
<properties
<property name="{property-name}" value="{name-value}"/>
</properties>入力:
|name|そのスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。必須項目。| |value|プロパティ名に対応する値を指定します。妥当なXML文字列でなければなりません。必須項目。|
'step'要素はjobのstepを定義します。jobは複数のstepを子要素して持てます。各stepはchunkかbatchletのどちらかです。chunkタイプのstepの詳細については8.2.1節を、batchletタイプのstepの詳細については8.2.2節を参照してください。
文法:
<step id="{name}" start-limit="{integer}"
allow-start-if-complete ="{true|false}" next="{ flow-id|step-id|split-id|decision-id}">入力:
| id | 様々な目的に使用されるstepの論理名を定義します。妥当なXML文字列でなければなりません。必須項目。 |
| start-limit | このstepが起動またはリスタートできる回数を指定します。妥当なXML文字列でなければなりません。オプション項目で、デフォルトは0で、これは無制限を意味します。もしこのリミットを超えた場合、jobはFAILEDステータスに設定されます。 |
| allow-start-if-complete | もし前回実行のstepが完了していたとしても、jobがリスタートするときstepが開始可能かどうかを指定します。trueかfalseのどちらかです。trueはstepがリスタート可能という意味です。オプション項目で、デフォルトはfalseです。 |
| next | このstepが完了したあとに実行される、step, flow, split, decisionを指定します。妥当なXML文字列でなければなりません。オプション項目で、デフォルトはこのstepがjobかflowの最終stepとなります。注意：step間でループを引き起こすような定義は出来ません。 |
'chunk'要素はchunkタイプのstepを指定します。step要素の子要素です。chunkタイプのstepは設定されたチェックポイントポリシーに従ってバッチランタイムによって定期的にチェックポイント処理がされます。チェックポイント間で処理されたアイテムは"chunk"と呼ばれます。chunkごとに一度だけItemWriterが呼び出されます。それぞれのchunkは別々のトランザクションで処理されます。トランザクションについての詳細は9.7節を参照してください。未完了chunkは最後のチェックポイントからリスタート可能です。allow-start-if-complete=trueに設定されたstepに属していて完了したchunkはリスタートされたとき最初から実行されます。
文法:
<chunk checkpoint-policy="{item|custom}"
item-count="{value}"
time-limit="{value}"
skip-limit="{value}"
retry-limit="{value}"
/>入力:
| checkpoint-policy | コミットの振る舞いを制御するチェックポイントポリシーを指定します。指定可能な値は"item"か"custom"です。"item"ポリシーは指定数のアイテム処理後にchunkがチェックポイント処理されます。"custom"ポリシーはチェックポイントアルゴリズム実装に従ってchunkがチェックポイント処理されます。"custom"を指定するにはcheckpoint-algorithm要素が必要です。checkpoint-algorithmの詳細については8.2.1.5節を参照してください。オプション項目で、デフォルトは"item"です。 |
| item-count | checkpoint-policyにitemを指定したとき一回のchunkで処理するアイテム数を指定します。オプション項目で、デフォルトは10です。checkpoint-policyが"custom"の場合はitem-count属性は無視されます。 |
| time-limit | checkpoint-policyがitem時のチェックポイントまでの制限秒数を指定します。妥当なXML整数でなければなりません。オプション項目で、デフォルトは0で、無制限を意味します。0より大きい値が指定された場合、time-limitに達したかitem-countまで処理されるかどちらかの条件が満たされた時点でチェックポイント処理が行われます。checkpoint-policyが"custom"の場合はtime-limit属性は無視されます。 |
| skip-limit | 設定されたスキップ可能例外がchunk処理中にスローされた場合、chunkがスキップする例外の数を指定します。妥当なXML整数でなければなりません。オプション項目で、デフォルトは無制限です。 |
| retry-limit | 設定されたリトライ可能例外がchunk処理中にスローされた場合、chunkがスキップする例外の数を指定します。妥当なXML整数でなければなりません。オプション項目で、デフォルトは無制限です。 |
'reader'要素はchunkのstepにおけるアイテムのreaderを指定し、'chunk'要素の子要素です。chunkのstepは一つだけreaderを持つ必要があります。
文法:
<reader ref="{name}"/>入力:
| ref | バッチアーティファクト名を指定します。 |
'properties'はreaderの子要素として指定します。readerへプロパティ値を渡すために使用し、任意の数を指定できます。
文法:
<properties>
<property name="{property-name}" value="{name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
'processor'要素はchunkのstepにおけるアイテムのprocessorを指定し、'chunk'要素の子要素です。chunkのstepではprocessor要素はオプション項目で、一つだけ持つことができます。
文法:
<processor ref="{name}"/>入力:
| ref | バッチアーティファクト名を指定します。 |
'properties'はprocessorの子要素として指定します。processorへプロパティ値を渡すために使用し、任意の数を指定できます。
文法:
<properties>
<property name="{property-name}" value="{name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
'writer'要素はchunkのstepにおけるアイテムのwriterを指定し、'chunk'要素の子要素です。chunkのstepは一つだけwriterを持つ必要があります。
文法:
<writer ref="{name}"/>入力:
| ref | バッチアーティファクト名を指定します。 |
'properties'はwriterの子要素として指定します。writerへプロパティ値を渡すために使用し、任意の数を指定できます。
文法:
<properties>
<property name="{property-name}" value="{name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
デフォルトでは、chunkを構成するいずれかのバッチアーティファクトがバッチランタイムへ例外をスローするとき、job実行はバッチステータスFAILEDで終了します。このデフォルトの振る舞いはreader, processor, writerアーティファクトで例外スキップもしくはリトライ設定によりオーバーライドできます。また、デフォルトの振る舞いはstep全体をstepの完了ステータスに一致するtransition要素を設定することでオーバーライドできます。
skippable-exception-classes要素はchunk処理をスキップする例外の組み合わせを、chunk要素の子要素で指定します。chunkタイプstepのreader, processor, writerバッチアーティファクトがスローする例外に適用されます。また、チェックポイントのコミット処理がスローする例外にも適用されます。コミットの失敗は書き込みの失敗と同様に扱われます。スキップする回数はchunk要素のskip-limit属性で指定します。chunk要素の詳細については8.2.1節を参照してください。
スキップする例外のリストはskippable-exception-classes要素のinclude子要素で指定します。一つ以上のinclude子要素でスキップされる例外クラスか親クラスを指定できます。exclude子要素でスキップ例外を除外できます。
オプションのスキップリスナー(Skip Listener)バッチアーティファクトをstepに設定できます。スキップ可能例外がreader, processor, writerからスローされた後にスキップリスナーへ制御が移ります。スキップリスナーバッチアーティファクトの詳細は9.2.7を参照してください。
文法:
<skippable-exception-classes>
<include class="{class name}"/>
<exclude class="{class name}"/>
</skippable-exception-classes>入力:
| include class | スキップする例外か例外の親クラスのクラス名を、完全修飾クラス名(FQCN)で指定します。include要素に複数インスタンスを指定できます。オプション項目ですが、この要素を指定したときclass属性は必須項目です。 |
| exclude class | スキップしない例外か例外の親クラスのクラス名を、完全修飾クラス名(FQCN)で指定します。'Exclude class'は'include class'で指定したスキップ例外を除外します。exclude要素に複数インスタンスを指定できます。オプション項目ですが、この要素を指定したときclass属性は必須項目です。 |
例:
<skippable-exception-classes>
<include class="java.lang.Exception"/>
<exclude class="java.io.FileNotFoundException"/>
</skippable-exception-classes>上の例はjava.io.FileNotFoundExceptionを除くすべての例外をスキップします。
retryable-exception-classes要素はchunk処理をリトライする例外の組み合わせを指定する、chunk要素の子要素です。chunkタイプstepのreader, processor, writerバッチアーティファクトがスローする例外に適用されます。また、チェックポイントのコミット処理がスローする例外にも適用されます。リトライの試行回数はchunk要素のretry-limit属性で設定します。chunk要素の詳細については8.2.1を参照してください。
リトライする例外のリストはretryable-exception-classes要素のinclude子要素で指定します。一つ以上のinclude子要素でリトライする例外クラスか親クラスを指定できます。exclude子要素でリトライ例外を除外できます。
オプションのリトライリスナー(Retry Listener)バッチアーティファクトをstepに設定できます。リトライ可能例外がreader, processor, writerからスローされた後にリトライリスナーへ制御が移ります。リトライリスナーバッチアーティファクトの詳細は9.2.8を参照してください。
文法:
<retryable-exception-classes>
<include class="{class name}"/>
<exclude class="{class name}"/>
</retryable-exception-classes>入力:
| include class | リトライする例外か例外の親クラスのクラス名を、完全修飾クラス名(FQCN)で指定します。include要素に複数インスタンスを指定できます。オプション項目ですが、この要素を指定したときclass属性は必須項目です。 |
| exclude class | リトライしない例外か例外の親クラスのクラス名を、完全修飾クラス名(FQCN)で指定します。'Exclude class'は'include class'で指定したリトライ例外を除外します。exclude要素に複数インスタンスを指定できます。オプション項目ですが、この要素を指定したときclass属性は必須項目です。 |
例:
<retryable-exception-classes>
<include class="java.io.IOException"/>
<exclude class="java.io.FileNotFoundException"/>
</retryable-exception-classes>上の例はjava.io.FileNotFoundExceptionを除くすべての例外をリトライします。
ある例外がリトライ可能とスキップ可能の両方に指定された場合、通常のchunk処理においてはリトライ可能がスキップ可能より優先されます。chunkがリトライしている場合、その例外ですでにリトライしたのでスキップ可能がリトライ可能より優先されます。
リトライ可能例外が発生したとき、デフォルトの振る舞いは、バッチランタイムに現在のchunkをロールバックさせ、チェックポイントポリシーはそのまま、item-countを1で再度処理します。オプションのChunkListenerがstepに設定されていた場合、onErrorメソッドがロールバック前に呼び出されます。デフォルトのリトライの振る舞いはno-rollback-exception-classes要素によって設定をオーバーライドできます。no-rollback例外の指定に関する詳細は8.2.1.4.5を参照してください。
no-rollback-exception-classes要素はリトライ例外におけるロールバックのデフォルトの振る舞いをオーバーライドする例外のリストを指定します。この要素はchunk要素の子要素です。もしリトライ可能例外がスローされた場合、デフォルトの振る舞いはリトライ前にロールバックを実施します。リトライ可能かつno-rollback例外と指定されていた場合、ロールバックは行われず現在のオペレーションがリトライされます。もしRetry Listenersが定義されていた場合はそのリスナーが呼び出されます。リトライリスナーバッチアーティファクトについては9.2.8節を参照してください。
文法:
<no-rollback-exception-classes>
<include class="{class name}"/>
<exclude class="{class name}"/>
</no-rollback-exception-classes>入力:
| include class | ロールバックがリトライ処理中に実施されないようにする例外か例外の親クラスのクラス名を、完全修飾クラス名(FQCN)で指定します。include要素に複数インスタンスを指定できます。オプション項目ですが、この要素を指定したときclass属性は必須項目です。 |
| exclude class | ロールバックがリトライ処理中に実施されるようにする例外か例外の親クラスのクラス名を、完全修飾クラス名(FQCN)で指定します。include要素に複数インスタンスを指定できます。オプション項目ですが、この要素を指定したときclass属性は必須項目です。 |
checkpoint-algorithm要素はオプションのカスタムチェックポイントアルゴリズムを指定します。chunk要素の子要素に指定します。この要素はchunk要素のcheckpoint-policy属性に'custom'を指定されたときのみ有効です。カスタムチェックポイントアルゴリズムはアイテム数や総数だけではない要因でチェックポイントを決定するために使用されます。カスタムチェックポイントアルゴリズムの詳細については9.1.1.4を参照してください。
文法:
<checkpoint-algorithm ref="{name}"/>入力:
| ref | バッチアーティファクト名を指定します。 |
'properties'要素はチェックポイントアルゴリズムにプロパティ値を渡すために使用する子要素です。任意の数を指定可能です。
文法:
<properties>
<property name="{property-name}" value="{name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
batchlet要素はタスク指向バッチステップ(task-oriented batch step)を定義するもので、step要素の子要素として指定します。chunk要素とは相互排他です。batchletについての詳細は9.1.2節を参照してください。このタイプのstepはアイテム指向でない、ファイル転送やコマンド実行のような、様々なタスク実行に役立ちます。
文法:
<batchlet ref="{name}"/>入力:
| ref | バッチアーティファクト名を指定します。 |
デフォルトでは、batchletタイプのstepを構成するバッチアーティファクトがバッチランタイムへ例外をスローするとき、ジョブ実行はFAILEDステータスで終了します。stepの完了ステータスとマッチするtransition要素の設定により、step全体のデフォルトの振る舞いをオーバーライドできます。
'properties'はbatchletの子要素として指定します。batchletへプロパティ値を渡すために使用し、任意の数を指定できます。
文法:
<properties>
<property name="{property-name}" value="{name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
'properties'要素はstep要素の子要素として定義できます。任意のステップレベルバッチアーティファクトとバッチランタイムにプロパティを定義するために使用されます。任意の数のプロパティを定義できます。ステップレベルプロパティはStepContextランタイムオブジェクトを通して利用できます。StepContextの詳細については9.4節を参照してください。
文法:
<properties
<property name="{property-name}" value="{name-value}"/>
</properties>入力:
|name|そのスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。必須項目。| |value|namedプロパティ名に対応する値を指定します。妥当なXML文字列でなければなりません。必須項目。|
ステップレベルリスナーはstep実行をインターセプトするためにjobのstepに指定することができます。listener要素はその目的のためにstep要素の子要素として定義できます。stepの種類に応じて以下のリスナーの種類が使用できます。
- chunk step - step listener, item read listener, item process listener, item write listener, chunk listener, skip listener, and retry listener
- batchlet step - step listener
複数のリスナーをstepに指定できます。しかし、実行順序を保証するものはありません。
文法:
<listeners>
<listener ref="{name}">
</listeners>入力:
| ref | バッチアーティファクト名を指定します。 |
'properties'要素をstep-levelリスナー要素の子要素として定義でき、リスナーへプロパティ値を渡すために使用できます。任意の数のプロパティを設定できます。
文法:
<properties
<property name="{property-name}" value="{name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
例:
<listener ref="{name}">
<properties>
<property name="Property1" value="Property1-Value"/>
</properties>
</listener>Job XMLで一番最初に定義するstep, flow, splitが最初に実行されます。"最初の(First)"の意味するところは、Job XMLでの定義順に沿って最初から最後に向かってパースされる、ということです。step, flow, splitの'next'属性は次に実行する要素を定義します。next属性にはstep, flow, split, decisionを定義可能で、step, flow, split要素で使用可能です。複数のstep, flow, decisionでは次に実行する要素を指定するのに"next"要素を代わりに使用できます。next属性とnext要素はjob実行要素がループするようには使用できません。
文法:
<next on="{exit status}" to="{id}" />入力:
| on | 次の要素への遷移条件となる完了ステータスを指定します。妥当なXML文字列でなければなりません。"*"と"?"をワイルドカードとして使用できます。"*"はゼロ以上の文字列で、"?"は一文字とマッチします。この設定値と完了ステータスの値が一致する必要があります。必須項目。 |
| to | 次に実行されるstep, split, flow, decisionのidを指定します。妥当なXML文字列でなければなりません。同一job内で別のstep, split, flow, decisionのidを指定する必要があります。flow内のstepでは、同一flow内でidは別のstepと一致している必要があります。必須項目。 |
stepには複数のnext要素を指定できます。複数のnext要素が指定された場合、その順序は最も一致するものからそうでないものとなります(*1)。完了ステータスがnext要素とマッチするものが見つかるまでそれぞれ比較されます。next要素が指定されるとき、すべての取りうる完了ステータスが設定されていなければなりません。もし完了ステータスがnext要素のいずれにもマッチしない場合、jobはFAILED状態で終了します。
*1 原文はfrom most specific to least specific
バッチのstepはパーティションステップ(*1)として実行できます。パーティーションステップは、一パーティーション・一スレッドや、同一ステップ定義を複数スレッド上の複数インスタンスとして、実行します。パーティーション数とスレッド数はJob XMLの静的な定義かpartition mapperのどちらかを通して制御されます。各パーティーションはそれらのデータを指示するためのユニークなパラメータを受け取る必要があります。各パーティーションのプロパティはオプションのpartition mapperかJob XMLで静的に指定できます。各スレッドはstepのコピーとして動作し、chunkとチェックポイント処理はchunk stepのそれぞれのstepで個別に発生します。
もし一つ以上のパーティーションが失敗した場合、取り消しできるようにpartition reducerの作業単位を調整する方法があります。PartitionReducerパッチアーティファクトはその方法を提供します。PartitionReducerは論理的な作業単位の境界をプログラミングでコントロールする方法を提供します(*2)。
パーティショーションステップのパーティーションはstepの結果全体を決定するコントロールポイントを使用して結果を共有する必要があります。PartitionCollectorとPartitionAnalyzerバッチアーティファクトの組み合わせはその要求に応えるものです。
'partition'要素はそのstepがパーティーションステップであると指定します。partition要素は'step'要素の子要素で、オプション要素です。
文法:
<partition>例:
以下のJob XMLスニペットはパーティーションステップを定義する方法の例を示しています。
<step id="Step1">
<chunk .../> or <batchlet ... />
<partition .../>
...</step>*1 原文ではpartitioned stepで、そのままでもよかったけど「パーティーションステップ」にすることにした。統一したつもりだけど「パーティーション化ステップ」「「パーティーションstep」と揺れてるかもしれない。 *2 that scopes all partitions of a partitioned stepを上手く日本語にできなんだで訳していない。
partition planはパーティーションステップの実行に影響を及ぼすいくつかの設定属性を定義します。partition planは、パーティーション数・同時実行パーティーション数・各パーティーション用のプロパティを定義します。partition planはJob XMLで静的に定義するかpartition mapperでランタイムに動的に定義することができます。
'plan'要素は'partition'要素の子要素です。'plan'要素はpartition mapper要素と相互排他です。partition mapperの詳細については9.5.1節を参照してください。
文法:
<plan partitions="{number}" threads="{number}"/>入力:
| partitions | このパーティーションステップのパーティーション数を指定します。オプション項目で、デフォルトは1です。 |
| threads | このstepのパーティーションを実行するスレッドの最大値を指定します。注意点として、バッチランタイムは要求されたスレッド数が利用可能であるとは保証しません。要求された最大値に達するように使われます(*1)。オプション属性で、デフォルトはパーティーション数です。 |
例:
以下のJob XMLスニペットはパーティション数3・スレッド数2でstepを定義する方法の例を示しています。
<step id="Step1">
<chunk .../>
<partition>
<plan partitions="3" threads="2"/>
</partition>
</chunk>
</step>*1 原文はit will use as many as it can up to the requested maximumで、設定された最大値までスレッドを作る努力はするけどランタイムは何の保証はしませんよ、って意味だろうけど上手く訳せない。
静的にパーティーションステップを定義するとき、Job XMLのproperty要素で各パーティーションごとにユニークなプロパティ値を渡すことができます。partition mapperに関する詳細な情報は9.5.1を参照してください。
文法:
<properties partition="partition-number">
<property name="{property-name}" value="{name-value}"/>
</properties>入力:
| partition | プロパティを適用する論理的なパーティーションナンバーを指定します。正の整数である必要があり、0オリジンです。 |
| name | ユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
例:
<partition>
<plan partitions="2">
<properties partition="0">
<property name="filename" value="/tmp/file1.txt"/>
</properties>
<properties partition="1">
<property name="filename" value="/tmp/file2.txt"/>
</properties>
</plan>
</partition>*1 上のXML例は、原文だとplanの閉じタグが間違っていると思われるので修正している。
partition mapperはパーティーションステップのスレッド数とパーティーション数をプログラミングで算出する方法を提供します。partition mappeはまた、各パーティーションごとのプロパティを定義します。mapper要素はPartitionMapperバッチアーティファクトを指定し、詳細は9.5.1を参照してください。注意点として、mapper要素はplan要素と相互排他です。
文法:
<mapper ref="{name}">入力:
| ref | バッチアーティファクト名を指定します。 |
例:
<partition>
<mapper ref="MyStepPartitioner"/>
</partition>'properties'要素をmapper要素の子要素として定義でき、PartitionMapperバッチアーティファクトへプロパティ値を渡すために使用できます。任意の数のプロパティを設定できます。
文法:
<properties
<property name="{property-name}" value="{name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
パーティーションステップはオプションのpartition reducerを実行できます。partition reducerはパーティーション処理におけるある種の処理単位の範囲を提供します(*1)。partition reducerを通してパーティーションステップのライフサイクルにプログラミング的なインターセプトが可能です。reducer要素はPartitionReducerバッチアーティファクトの参照を指定し、詳細は9.5.2節を参照してください。
'reducer'要素は'partition'要素の子要素です。
文法:
<reducer ref="{name}">入力:
| ref | バッチアーティファクト名を指定します。 |
例:
<partition>
<reducer ref="MyStepPartitionReducer"/>
</partition>*1 unit of work demarcation around the processing of the partitionsってどう訳すと自然なんですかね……
'properties'要素はPartitionReducer要素の子要素として指定します。PartitionReducerバッチアーティファクトにプロパティ値を渡すために使用され、任意の数のプロパティを指定できます。
文法:
<properties>
<property name="{property-name}" value="{ name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
Partition Collectorは、分析用途で各パーティーションからstepのPartition Analyzerへ中間結果を送出するのに役立ちます。それぞれのPartition Collectorインスタンスはstepパーティーションのスレッド上で実行されます。collectorは、chunk stepの各チェックポイントの終了時と、パーティションの終了時に呼び出されます。また、batchlet stepではパーティーション終了時に一度だけ呼び出されます。collectorはJava Serializableオブジェクトを戻り値として、それをstepのPartition Analyzerへと渡します。Partition Analyzerの詳細については9.5.4節を参照してください。collector要素はPartitionCollectorバッチアーティファクトの参照を指定し、その詳細は9.5.3節を参照してください。
'collector'要素は'partition'要素の子要素です。
文法:
<collector ref="{name}">入力:
| ref | バッチアーティファクト名を指定します。 |
例:
<partition>
<collector ref="MyStepCollector"/>
</partition>'properties'要素はcollector要素の子要素として指定します。PartitionCollectorバッチアーティファクトにプロパティ値を渡すために使用され、任意の数のプロパティを指定できます。
文法:
<properties>
<property name="{property-name}" value="{ name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
Partition AnalyzerはstepのPartition Collector経由で送出された各パーティーションからの中間結果を受け取ります。Partition analyzerはstepのメインスレッドで動作し、データの収集ポイントとして機能します。PartitionAnalyzerはまた、各パーティーションが終了したときその完了ステータスで制御を受け取ります、analyzerはstep用に、個々のパーティーションの結果に基づく、完了ステータスのカスタムハンドリング実装をすることができます。analyzer要素はPartitionAnalyzerバッチアーティファクトの参照を指定し、詳細は9.5.4節を参照してください。
文法:
<analyzer ref="{name}">入力:
| ref | バッチアーティファクト名を指定します。 |
例:
<partition>
<analyzer ref="MyStepAnalyzer"/>
</partition>'properties'要素はanalyzer要素の子要素として指定します。PartitionAnalyzerバッチアーティファクトにプロパティ値を渡すために使用され、任意の数のプロパティを指定できます。
文法:
<properties>
<property name="{property-name}" value="{ name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
step処理中にステップレベルアーティファクトによってスローされた未処理例外は、jobとstepをFAILEDバッチステータスで終了させます。
flowは一単位として実行する一連の処理要素を定義します。flowが終了するとき、flow全体が次の実行要素に遷移します。flowはstep, split, decision, 別のflowに遷移できます。flowはstep, flow, decision, split実行要素を含めることができます。decisionについての詳細は8.5節、splitの詳細については8.4節を参照してください。flow内の実行要素はその内部の要素間でのみ遷移が可能で、flow外の要素へは遷移できません。また、flowはtransition要素のnext, stop, fail, endを含むめることができます。transition要素の詳細については8.6節を参照してください。
文法:
<flow id="{name}"next="{flow-id|step-id|split-id|decision-id}">
<step> ... </step> ...
</flow>入力:
| id | 識別用途としてflowの論理名を指定します。妥当なXML文字列でなければなりません。必須項目。 |
| next | このstepが完了したあとに起動するstep, flow, split, decisionを指定します。妥当なXML文字列でなければなりません。オプション項目で、デフォルトはそのflowがjobの最終実行要素になります。注意点として、next属性はstep内でループするような指定をすることできません。 |
splitは同時実行するflowの組み合わせを定義します。splitは子要素にflow要素のみ含められます。flowの詳細については8.3節を参照してください。それぞれのflowはそれぞれのスレッドで動作します。すべてのflowが完了するとsplitは終了されます。splitが終了したとき、split全体が次の実行要素へと遷移します。splitはstep, flow, decision, 別のsplitへ遷移できます。
文法:
<split id="{name}"next="{flow-id|step-id|split-id|decision-id}">
<flow> ... </flow>
...
</split>入力:
| id | 識別用途としてsplitの論理名を指定します。妥当なXML文字列でなければなりません。必須項目。 |
| next | このstepが完了したあとに起動するstep, flow, split, decisionを指定します。妥当なXML文字列でなければなりません。オプション項目で、デフォルトはそのsplitがjobの最終実行要素になります。注意点として、next属性はstep内でループするような指定をすることできません。 |
splitの終了処理:
- すべてのflowの最後のstepがCOMPLETEDバッチステータスで終了した場合、splitは"to"属性で指定される実行要素に遷移します。
- 上記条件を満たさず、一つ以上のflowの最終stepがFAILEDバッチステータスで終了した場合、jobはFAILEDバッチステータスで終了します。job完了ステータスはこのような方法で終了した最初のflowの最終stepの完了ステータスが設定されます。
- 上記条件を満たさず、一つ以上のflowの最終stepがSTOPPEDバッチステータスで終了した場合、jobはSTOPPEDバッチステータスで終了します。job完了ステータスはこのような方法で終了した最初のflowの最終stepの完了ステータスが設定されます。 (*1)
*1 訳がビミョーだがjava eeチュートリアルによると、全フローがCOMPLETEDならCOMPLETED、フローのいずれかがFAILEDならFAILED、フローのいずれかがSTOPPEDでありFAILEDが一つも無いならSTOPPED、ということらしい。
条件分岐(decision)は、step, flow, split間の実行順序を決定する方法をカスタマイズするために使用します。decision要素はstep, flow, splitの後に指定します。jobは任意の数のdecision要素を使用できます。decision要素は、別のdecision, jobレベルのstep, splitの"next"属性に指定できます。decisionはdeciderバッチアーティファクト（9.6節参照）を必要とします。deciderの目的は次の遷移先を決定することです。decisionは遷移先を選択するためにtransition要素stop, fail, end, nextのいずれかを使用できます。transition要素の詳細については8.6節を参照してください。deciderは遷移先選択を調整するために新規の完了ステータスを設定できます。
文法:
<decision id="{name}" ref="{ref-name}">入力:
| id | 識別用途としてdecisionの論理名を指定します。妥当なXML文字列でなければなりません。必須項目。 |
| ref | バッチアーティファクト名を指定します。 |
例:
<decision id="AfterFlow1" ref="MyDecider">
...
</decision>'properties'要素はdecision要素の子要素として指定しますdeciderにプロパティ値を渡すために使用され、任意の数のプロパティを指定できます。
文法:
<properties>
<property name="{property-name}" value="{ name-value}"/>
</properties>入力:
| name | このスコープ内でユニークなプロパティ名を指定します。妥当なXML文字列でなければなりません。関連付けられたバッチアーティファクトのnamedなプロパティとマッチする場合、その値はこのプロパティに関連付けられます。もしそうでない場合、無視されます。必須項目。 |
| value | namedなプロパティと対応する値。妥当なXML文字列でなければなりません。必須項目。 |
decisionハンドリング中に実行されたバッチアーティファクトによってスローされたすべての例外はバッチステータスFAILEDでjobを終了させます。この例外はjobレベルリスナーから参照可能です。
transition要素は、step, flow, split, decisionのスコープ内で、job実行の終了またはjob実行順序の指示をすることができます。4つのtransition要素があり、
- next - 実行順序の次の要素を実行する。
- fail - FAILEDバッチステータスでjobを終了させる。
- end - COMPLETEDバッチステータスでjobを終了させる。
- stop - STOPPEDバッチステータスでjobを終了させる。
fail, end, stopはjob実行を終了させるので"終端要素(terminating elements)"と見なすことができます。
next要素は現在のdecisionから次の実行要素へ遷移するために使用します。現在のスコープ内で複数のnext要素を指定できます。
文法:
<next on="{exit status}" to="{step id | flow id | split id}"/>入力:
| on | このnext要素(*1)が有効となる完了ステータス値を指定します。妥当なXML文字列でなければなりません。ワイルカード"*"と"?"が使用できます。"*"はゼロ文字以上の文字列とマッチし、"?"は1つの文字とマッチします。この設定値と完了ステータスの値が一致する必要があります。必須項目。 |
| to | このdecisionの次の遷移先となるjobレベルのstep, flow, splitを指定します。妥当なXML文字列でなければなりません。必須項目。注意点として、バッチジョブでループを引き起こすような要素を遷移先としてtoに設定することはできません。 |
例:
<step id="Step1">
<next on="*" to="Step2"/>
</decision>*1 原文では end elementになっているがnext elementの間違いと思われる。
fail要素は現在のstepかflowを最後にjobを終了させるために使用します。バッチステータスはFAILEDです。現在のスコープ内で複数のfail要素を指定できます。fail要素はstep, flow, decision要素の子要素として指定できます。
<fail on="{exit status}" exit-status="{exit status}"/>入力:
| on | このfail要素が有効となる完了ステータス値を指定します。妥当なXML文字列でなければなりません。ワイルカード"*"と"?"が使用できます。"*"はゼロ文字以上の文字列とマッチし、"?"は1つの文字とマッチします。この設定値と完了ステータスの値が一致する必要があります。必須項目。 |
| exit-status | stepの完了ステータス変更したいときに指定します。妥当なXML文字列でなければなりません。オプション項目で、もし指定されない場合は、完了ステータスはそのままです。 |
例:
<step id="Step1">
<fail on="FAILED" exit-status="EARLY COMPLETION">
</step>end要素は現在のstepでjobを終了させるために使用します。バッチステータスはCOMPLETEDです。現在のスコープ内で複数のend要素を指定できます。end要素はstep, flow, decision要素の子要素として指定できます。
文法:
<end on="{exit status}" exit-status="{exit status}"/>入力:
| on | このend要素が有効となる完了ステータス値を指定します。妥当なXML文字列でなければなりません。ワイルカード"*"と"?"が使用できます。"*"はゼロ文字以上の文字列とマッチし、"?"は1つの文字とマッチします。この設定値と完了ステータスの値が一致する必要があります。必須項目。 |
| exit-status | stepの完了ステータスを変更したいときに指定します。妥当なXML文字列でなければなりません。オプション項目で、もし指定されない場合は、完了ステータスはそのままです。 |
例:
<step id="Step1">
<end on="COMPLETED" exit-status="EARLY COMPLETION">
</step>stop要素は現在のstepでjobを終了させるために使用します。もしstop要素が完了ステータスとマッチした場合、バッチステータスはSTOPPEDに設定されます。現在のスコープ内で複数のstop要素を指定できます。stop要素はstep, flow, decision要素の子要素として指定できます。
文法:
<stop on="{exit status}" exit-status="{exit status}" restart="{step id | flow id | split id}"/>入力:
| on | このstop要素(*1)が有効となる完了ステータス値を指定します。妥当なXML文字列でなければなりません。ワイルカード"*"と"?"が使用できます。"*"はゼロ文字以上の文字列とマッチし、"?"は1つの文字とマッチします。この設定値と完了ステータスの値が一致する必要があります。必須項目。 |
| exit-status | stepの完了ステータスを変更したいときに指定します。妥当なXML文字列でなければなりません。オプション項目で、もし指定されない場合は、完了ステータスはそのままです。 |
| restart | jobがリスタートしたときに、リスタートするjobレベルstep, flow, splitを指定します。妥当なXML文字列でなければなりません。必須項目です。 |
例:
<step id="Step1">
<stop on="COMPLETED" restart="step2"/>
</step>*1 原文ではend elementになっているがstopの間違いと思われる。つか、同じような文面続くからコピペミスしたんだろうなぁ……
バッチ実行は、jobが終了時にある終了状態へと達する、状態遷移のシーケンスを示します。それらの状態遷移は、job内の個々のstepと同様に、総体としてのjob全体に適用されます。状態遷移はプログラミングモデルのステータス値として参照可能です。ランタイムのステータス値は"バッチステータス(batch status)"、同様にユーザー定義値は"完了ステータス(exit status)"、とそれぞれ呼ばれます。
jobとjob内の各stepはバッチステータスと完了ステータスで終了します。バッチステータスはバッチランタイムによって設定され、完了ステータスはバッチアプリケーションがJob XMLを通して設定されます。デフォルトでは、完了ステータスはバッチステータスと同一です。もしバッチアーティファクトが明示的にデフォルトをオーバーライドして完了ステータスを設定する場合には注意してください。バッチステータスと完了ステータスはJobContextとStepContextで利用可能です。jobの完了ステータスとバッチ全体のステータスはJobOperatorインタフェースを通して利用可能です。バッチステータスと完了ステータスは文字列です。以下のバッチステータスが定義されています。
| 値 | 説明 |
|---|---|
| STARTING | バッチジョブが、JobOperatorインタフェースのstartかリスタート操作を通してバッチランタイムへ、渡された。step実行開始の前に、stepはSTARTINGステータスになる。 |
| STARTED | バッチジョブがバッチランタイムによって実行開始された。stepが実行開始されていたら、stepはSTARTEDステータスとなる。 |
| STOPPING | バッチジョブがJobOperatorインタフェースのstopかJob XMLのstop要素によって停止(stop)要求が出された。JobOperator.stopが呼ばれると、直ちにstepはSTOPPINGステータスとなる。 |
| STOPPED | バッチジョブがJobOperatorインタフェースのstopかJob XMLのstop要素によって停止された。バッチランタイムによって実際にstepが停止されると、stepはSTOPPEDステータスとなる。 |
| FAILED | バッチジョブが未解決の例外かJob XMLのfail要素によって終了した。stepは同じ条件によってFAILEDステータスとなる。 |
| COMPLETED | バッチジョブが正常終了かJob XMLのend要素で終了した。stepは同じ条件によってCOMPLETEDステータスとなる。 |
| ABANDONED | JobOperatorインタフェースのabandonメソッドによって放棄(abandoned)とマークされた。放棄されてもまだそのjobはJobOperatorインタフェースから参照できるが、実行しておらず、リスタートもできません。単に履歴として存在します。 |
jobの実行は下記の条件に従って終了します。
- "next"属性か"next"要素を指定しないjobレベルの実行要素(step, flow, split)が実行を終了。このケースでは、バッチステータスはCOMPLETEDに設定されます。
- stepがskipかretryの条件にマッチしない例外をバッチランタイムへスローした。このケースでは、バッチステータスはFAILEDに設定されます。パーティーションステップもしくは同時実行(split)stepの場合、jobがFAILEDバッチステータスで終わる前に、他のすべての実行中のパラレルインスタンスを終了させることができます。これがデフォルトの例外ハンドリングです。
- step, flow, decisionがstop, end, fail要素で実行を終了する。このケースでは、バッチステータスはそれぞれSTOPPED, COMPLETED, FAILEDになります。デフォルトの例外ハンドリングをオーバーライドした場合は、上述の通りです。
jobのバッチステータスと完了ステータスは以下のように設定されます。
- まずバッチステータスはバッチランタイムによってSTARTINGに設定されます。最初のstepを開始する直前に、バッチランタイムはバッチステータスをSTARTEDに設定します。完了ステータスはバッチステータスの文字列が設定されます。
- 完了ステータスは、任意のバッチアーティファクトがJobContextオブジェクトの完了ステータスsetterメソッドを実行するによって、上書きが可能です。
- 完了ステータスはdecision要素によってオーバーライドが可能です。
- 完了ステータスはstep, flow, splitのtransition要素によってオーバーライドが可能です。詳細は8.6節を参照してください。
- 最終的なバッチステータスがjobの結果に基づきバッチランタイムによって設定されます。上記の表を参照してください。もし、この節の冒頭にある通り、デフォルト動作をオーバーライドしていない場合、完了ステータスは最終バッチステータスが設定されます。注意点として、job実行中に完了ステータスを最後にオーバーライドしたものがその他すべてに優先されます。
stepのバッチステータスは、バッチランタイムによってまず設定され、最後にまた設定されます。stepの完了ステータスはバッチステータスとしての値と同一なものが設定されます。stepの完了ステータスは、StepContextオブジェクトの完了ステータスsetterメソッドを実行する、任意のバッチアーティファクトによって設定されます。StepContextオブジェクトの詳細については9.4節を参照してください。step実行後にstepの完了ステータスを設定することは出来ませんが、transition(8.6節参照)とdeciders(9.6節参照)経由で後続のstep実行に影響を及ぼすことは可能です。もしバッチアーティファクトが何も完了ステータスを設定しない場合、バッチランタイムはデフォルト値としてバッチステータスの文字列形式を設定します。
step終了時の動作はtransition要素のfail, end, stopを使用したJob XMLで任意に設定可能です。また、これらの要素は完了ステータスを設定できます。注意点として、StepContextオブジェクト経由で完了ステータスの設定をプログラミングすると、要素での完了ステータス設定を上書きします。
パーティーションstepの完了ステータスはstepと同様のルールに従いますが、個々のパーティーションを処理するバッチアーティファクトによって完了ステータスが設定される場合は除きます。この意味するところは、非パーティーションstepと同様に、stepの完了ステータスは下記によって設定される、ということです。
- transition要素stop, end, fail
- StepContext
もし完了ステータスが設定されない場合、非パーティーションstepと同様に、バッチステータスがデフォルトで設定されます。
パーティションbatchletでは、パーティーションを処理するスレッドそれぞれが別々の完了ステータスを返せます。パーティーションcollectorが別々の完了ステータスをstepの最終完了ステータスへと集約するために使用される場合を除いて、それらの完了ステータスは無視されます。
バッチランタイムはパーティーションごとにStepContextのクローンを保持し続けます。パーティーションを処理するスレッド上で動作するどのバッチアーティファクトでも、StepContextクローンを通して別々の完了ステータスを設定できます。パーティーションcollectorが別々の完了ステータスをstepの最終完了ステータスへと集約するために使用される場合を除いて、それらの完了ステータスは無視されます。
Job XMLは任意の属性値の一部を置換する仕組みをサポートしています。以下のEL式はすべての属性でサポトートされています。
<attribute-value> ::= ' " ' <principle-value-expression> [<default-expression>] ' " '
49
<principle-value-expression> ::= <value-expression>
<value-expression> ::= "#{"<operator-expression>"}" | <string-literal> [ <value-expression> ]
<default-expression> ::= "?:" <value-expression> ";"
<operator-expression> ::= <operator1> | <operator2> | <operator3> | <operator4> | <operator5>
<operator1> ::= "jobParameters" "[" <target-name> "]"
<operator2> ::= "jobProperties" "[" <target-name> "]"
<operator3> ::= "systemProperties" "[" <target-name> "]"
<operator4> ::= "partitionPlan" "[" <target-name> "]"
<target-name> ::= " ' " <string-literal> " ' "妥当なXML文字列のことです。
置換表現(Substitution expressions)はjobの開始時とリスタート時の両方で処理されます。すべての置換表現はjobが開始かリスタートされる前に解決されていなければなりません。ただし、遅延解決(deferred resolution)されるpartitionPlan操作は除きます。詳細は8.8.1.4を参照してください。置換表現の解決後、得られたXMLドキュメントは、13章で概要が記されているジョブ定義言語のXSDに従って、妥当性のチェックが行われます。
置換表現は、パラメーター名の指定や置換表現演算子経由のプロパティを使用して、ジョブパラメーターやジョブプロパティを参照可能です。この名前は、一般的には"ターゲット名(target name)"という置換表現の文法で呼ばれています。置換表現演算子は4つあります。
- jobParameters - ジョブパラメーターからnamedパラメーターを使用するために指定する。
- jobProperties - ジョブプロパティの中からnamedプロパティを使用するために指定する。
- systemProperties - システムプロパティの中からnamedプロパティを使用するために指定する。
- partitionPlan - パーティーションstepのpartition planからnamedプロパティを使用するために指定する。
jobParametersの置換演算子は指定されたターゲット名のジョブパラメータ値を解決します。
jobPropertiesの置換演算子は指定されたターゲット名のジョブプロパティ値を、指定されたターゲット名がスコープの最も内側から外側へと見つかるまで、定義されたプロパティを再帰的に探索することによって、解決します。
例:
バッチランタイムは以下のようにしてjobProperties置換演算子の解決を試みます。まずchunk定義のchunkプロパティを検索し、その次に（もし存在すれば）stepプロパティを探索し、その次に（もし存在すれば）jobプロパティを検索します。検索は指定されたターゲット名が最初に発見されたところで停止します。
<job id="job1">
<properties>
<property name="filestem" value="postings"/>
</properties>
<step id="step1">
<chunk>
<properties>
<property name="infile.name" value="#{jobProperties['filestem']}.txt"/>
</properties>
</chunk>
</step>
</job>"infile.name"プロパティの値は解決されて"postings.txt"になります。
systemPropertiesの置換演算子は指定されたターゲット名のシステムプロパティを解決します。
partitionPlanの置換演算子は、PartitionMapperが返すPartitionPlanで指定されるターゲット名で、partition planのプロパティ値を解決します。Partition planプロパティのスコープは、partition planが定義されるstepのみです。partitionPlan演算子は、パーティーション実行開始前に、各パーティションそれぞれで解決されます。
例として下記のようにjob1でjobが与えられる場合:
<job id="job1">
<step id="step1">
<chunk>
<itemReader ref="MyReader>
<properties>
<property name="infile.name"
value="file#{partitionPlan['partitionNumber']}.txt"/>
</properties>
</itemReader>
<itemWriter ref="MyWriter"/>
<partition>
<mapper ref="MyMapper"/>
</partition>
</chunk>
</step>
</job>MyMapperの実装は下記の通り:
public class MyMapper implements PartitionMapper {
public PartitionPlan mapPartitions() {
PartitionPlanImpl pp= new PartitionPlanImpl();
pp.setPartitions(2);
Properties p0= new Properties();
p0.setProperty("partitionNumber", "0");
Properties p1= new Properties();
p1.setProperty("partitionNumber", "1");
Properties[] partitionProperties= new Properties[2];
partitionProperties[0]= p0;
partitionProperties[1]= p1;
pp.setPartitionProperties(partitionProperties);
return pp;
}
}step1のchunkは2つのパーティーションで実行され、itemReaderのプロパティ"infile.name"は、パーティーション0と1で"file0.txt"と"file1.txt"に解決されます。
置換表現には"?:"演算子を使用してデフォルト値を設定できます。このデフォルトは、もし置換の値表現が空文字""に解決される場合、適用されます。
置換演算子に指定するプロパティは、置換表現で使用する前に定義しておく必要があります。
例:
- 解決可能なプロパティ参照(Resolvable Property Reference)
バッチランタイムは置換参照を定義済みのプロパティへ解決します。以下の例では、"infile.name"プロパティが、"tmpfile.name"プロパティの整形に使用される前に、定義されています。例:
<property name="infile.name" value="in.txt" />
<property name="tmpfile.name" value="#{jobProperties['infile.name']}.tmp" />バッチランタイムは、指定プロパティの参照を解決した値で、解決可能な参照を解決します。
- 解決不能なプロパティ参照(Unresolvable Property Reference)
バッチランタイムはプロパティが参照後に定義される置換参照を解決しません。以下の例では、"infile.name"プロパティが、"tmpfile.name"プロパティの整形に使用された後に、定義されています。
<property name="tmpfile.name" value="in.txt#{jobProperties[''infile.name]}" />
<property name="infile.name" value="in.txt" />バッチランタイムはXMLの解決不能な参照は空文字""として解決します。
未定義のターゲット名を指定する置換表現演算子は、XML上で空文字が割り当てられます。
jobパラメータはjobのリスタート時に指定可能です。置換表現の解決はリスタートごとに発生します。つまり、jobリスタートごとに、jobXMLの属性へ新しい値を適用可能です。置換表現の解決は、初回実行時もリスタート時も同様な方法で処理されます。ただし、パーティーションstepのパーティーション数には特別ルールが存在します。
partition planにおけるパーティーション数
バッチランタイムは、初めてstepが試行されるときに、パーティーションstepのパーティーション数を決定します。直前のjob実行がリスタートされると、バッチランタイムはその決定を記憶しており、次回のjob実行時のstepに適用します。この決定は置換表現では変更不能です。しかし、PartitionPlanオブジェクトの"override"オプションを指定したPartitionMapperを通してならば変更が可能です。PartitionPlanクラスの詳細については10.9.4節を参照してください。
-
<property name="infile.name" value="in.txt" />
解決されるプロパティ：infile.name="in.txt" -
<property name="infile.name" value="#{jobParameters['infile.name']}" />
解決されるプロパティ：infile.name=jobのinfile.nameパラメータの値 -
<property name="infile.name" value="#{systemProperties['infile.name']}" />
解決されるプロパティ：infile.name=システムプロパティinfile.nameの値 -
<property name="infile.name" value="#{jobProperties['infile.name']}" />
解決されるプロパティ：infile.name=jobのinfile.nameプロパティの値 -
<property name="infile.name" value="#{partitionPlan['infile.name']}" />
解決されるプロパティ：infile.name=現在のパーティーションのpartition planのinfile.nameの値 -
<property name="infile.name" value="#{jobParameters['infile.name']}?:in.txt;" />
解決されるプロパティ：infile.name =jobのinfile.nameパラメータの値もしくはjobのinfile.nameパラメータが未定義ならば"in.txt"
バッチプログラミングモデルは、インタフェース、抽象クラス、フィールドアノテーションによって定義されています。インタフェースはバッチアプリケーションとバッチランタイムの本質的な契約関係を定義しています。多くのインタフェースは開発者の手間を省くためにいくつかのメソッドのデフォルト実装をした抽象クラスもまた持っています。
stepはchunkかbatchletのどちらかです。
chunkタイプのstepはreader-processor-writerバッチパターンとチェックポイントを使用したアイテム指向処理を実行します。
ItemReaderはchunk stepでアイテムを読み込むために使用されます。ItemReaderはchunkタイプstepを構成する三つのバッチアーティファクトの一つです。他の二つはItemProcessorとItemWriterです。
ItemReaderインタフェースはItemReaderバッチアーティファクトを実装するために使用します。
package javax.batch.api.chunk;
import java.io.Serializable;
/**
* ItemReaderはchunk処理においてアイテム読み込むを行うバッチアーティファクトを定義します。
*/
public interface ItemReader {
/**
* openメソッドはアイテムを読み込むためのreaderを準備します。
*
* 入力パラメーターは与えられたjobインスタンスでこのreaderの最後のチェックポイントを表現しています。
*
* チェックポイントデータはこのreaderによって定義され、また、checkpointInfoメソッドによって提供されます。
* チェックポイントデータはリスタート時にアイテム読み込みを再開する必要がある情報とは何かをreaderに提供します。
* 初回起動時にはチェックポイントの値はnullが渡されます。
*
* @param checkpoint 最後のチェックポイントを定義
* @throws Exception 任意のエラーでスローされる例外
*/
public void open(Serializable checkpoint) throws Exception;
/**
* closeメソッドはItemReaderの使用終了を意味します。readerは必要なクリーンアップ処理を自由に行えます。
*
* @throws Exception 任意のエラーでスローされる例外
*/
public void close() throws Exception;
/**
* readItemメソッドはchunk処理における次のアイテムを返します。
* nullはそれ以上アイテムが無いことを示し、また、現在のchunkがコミットされてstepが終了することを意味します。
*
* @return 次のアイテムかnull
* @throws Exception 任意のエラーでスローされる例外
*/
public Object readItem() throws Exception;
/**
* checkpointInfoメソッドはこのreaderにおける現在のチェックポイントデータを返します。
* chunkのチェックポイントがコミットされる前に呼び出されます。
*
* @return チェックポイントデータ
* @throws Exception 任意のエラーでスローされる例外
*/
public Serializable checkpointInfo() throws Exception;
}package javax.batch.api.chunk;
import java.io.Serializable;
/**
* AbstractItemReaderはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public abstract class AbstractItemReader implements ItemReader {
/**
* もしItemReaderがopen時に処理を必要とするならこのメソッドをオーバーライドします。
* デフォルト実装は何もしません。
* @param checkpoint このitemReaderの最後のチェックポイント（たいていはnull）
* @throws Exception もしエラーが発生した場合
*/
@Override
public void open(Serializable checkpoint) throws Exception {
}
/**
* もしItemReaderがclose時に処理を必要とするならこのメソッドをオーバーライドします。
* デフォルト実装は何もしません。
* @throws Exception もしエラーが発生した場合
*/
@Override
public void close() throws Exception {
}
/**
* このメソッドでItemReaderの読み込みロジックを実装します。
* @return 次のアイテムかnull
* @throws Exception もしエラーが発生した場合
*/
@Override
public abstract Object readItem() throws Exception;
/**
* もしItemReaderがチェックポイントをサポートするならこのメソッドをオーバーライドします。
* デフォルト実装はnullを返します。
* @return チェックポイントデータ
* @throws Exception もしエラーが発生した場合
*/
@Override
public Serializable checkpointInfo() throws Exception {
return null;
}
}ItemProcessorはchunk stepにおけるアイテム処理に使用されます。ItemProcessorはchunkタイプstepを構成する三つのバッチアーティファクトの一つです。ItemProcessorはchunkタイプstepではオプションのアーティファクトです。他の二つはItemReaderとItemWriterです。
ItemProcessorインタフェースはItemProcessorバッチアーティファクトを実装するために使用されます。
package javax.batch.api.chunk;
/**
* ItemProcessorはchunk処理において入力アイテムを処理して出力アイテムを生成するために使用されます。
*/
public interface ItemProcessor {
/**
* processItemメソッドはchunk stepの一部分です。
* readerから入力アイテム受け取り、writerに渡されるアイテムが戻り値になります。
* 戻り値nullは、そのアイテムの処理を継続しないことを意味します。
* これはprocessItemで不要な入力アイテムをフィルタできること意味します。
*
* @param item 処理する入力アイテムを指定します
* @return 書き込むアイテムを出力します
* @throws Exception もしエラーが発生した場合
*/
public Object processItem(Object item) throws Exception;
}ItemWriterはchunk stepにおける出力アイテムのリストを書き込むために使用されます。ItemWriterはchunkタイプstepを構成する三つのバッチアーティファクトの一つです。他の二つはItemProcessorとItemReaderです。
ItemWriterインタフェースはItemWriterバッチアーティファクトを実装するために使用されます。
package javax.batch.api.chunk;
import java.io.Serializable;
import java.util.List;
/**
* ItemWriterはchunk処理におけるアイテムのリストを書き込むバッチアーティファクトを定義します。
*/
public interface ItemWriter {
/**
* openメソッドはアイテムを書き込むためのwriterを準備します。
*
* 入力パラメーターは与えられたjobインスタンスでこのwriterの最後のチェックポイントを表現しています。
* チェックポイントデータはこのwriterによって定義され、また、checkpointInfoメソッドによって提供されます。
* チェックポイントデータはリスタート時にアイテム書き込むを再開する必要がある情報とは何かをwriterに提供します。
* 初回起動時にはチェックポイントの値はnullが渡されます。
*
* @param checkpoint 最後のチェックポイントを定義
* @throws Exception 任意のエラーでスローされる例外
*/
public void open(Serializable checkpoint) throws Exception;
/**
* closeメソッドはItemWriterの使用終了を意味します。writerは必要なクリーンアップ処理を自由に行えます。
*
* @throws Exception 任意のエラーでスローされる例外
*/
public void close() throws Exception;
/**
* writeItemsメソッドは現在のchunkにおけるアイテムのリストを書き込みます。
*
* @param items 書き込むためのアイテムのリストを指定する
* @throws Exception 任意のエラーでスローされる例外
*/
public void writeItems(List<Object> items) throws Exception;
/**
* checkpointInfoメソッドはこのwriterにおける現在のチェックポイントデータを返します。
* chunkのチェックポイントがコミットされる前に呼び出されます。
*
* @return チェックポイントデータ
* @throws Exception 任意のエラーでスローされる例外
*/
public Serializable checkpointInfo() throws Exception;
}package javax.batch.api.chunk;
import java.io.Serializable;
import java.util.List;
/**
* AbstractItemWriterはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public abstract class AbstractItemWriter implements ItemWriter {
/**
* もしItemWriterがopen時に処理を必要とするならこのメソッドをオーバーライドします。
* デフォルト実装は何もしません。
*
* @param checkpoint このItemWriterの最後のチェックポイント（たいていはnull）
* @throws Exception もしエラーが発生した場合
*/
@Override
public void open(Serializable checkpoint) throws Exception {
}
/**
* もしItemWriterがclose時に処理を必要とするならこのメソッドをオーバーライドします。
* デフォルト実装は何もしません。
*
* @throws Exception もしエラーが発生した場合
*/
@Override
public void close() throws Exception {
}
/**
* このメソッドでItemWriterの書き込むロジックを実装します。
*
* @param items 書き込むアイテムのリストを指定
* @throws Exception もしエラーが発生した場合
*/
@Override
public abstract void writeItems(List<Object> items) throws Exception;
/**
* もしItemWriterがチェックポイントをサポートするならこのメソッドをオーバーライドします。
* デフォルト実装はnullを返します。
*
* @return チェックポイントデータ
* @throws Exception もしエラーが発生した場合
*/
@Override
public Serializable checkpointInfo() throws Exception {
return null;
}
}CheckpointAlgorithmはchunk stepのためのチェックポイントポリシーのカスタム実装を行います。CheckpointAlgorithmインタフェースはCheckpointAlgorithmバッチアーティファクトと実装するために使用されます。
package javax.batch.api.chunk;
/**
* CheckpointAlgorithmはchunk stepのためのチェックポイントポリシーのカスタム実装を提供します。
*/
public interface CheckpointAlgorithm {
/**
* チェックポイントタイムアウトの確立目的で新しいチェックポイントインターバルの開始時に呼び出されます。
* このメソッドは次のチェックポイントトランザクションが開始する前に呼び出されます。
* このメソッドは次のチェックポイントトランザクションに使用されるタイムアウト値となる整数値を返します。
* このメソッドはジョブ定義の外側の情報に基づいてチェックポイントタイムアウトの設定を自動化するのに役立ちます。
*
* (*1)
* @return 次のチェックポイントインターバルで使用するためのタイムアウトインターバル値
* @throws Exception もしエラーが発生した場合
*/
public int checkpointTimeout() throws Exception;
/**
* beginCheckpointメソッドは次のチェックポイントインターバルが開始される前に呼び出されます。
*
* @throws Exception もしエラーが発生した場合
*/
public void beginCheckpoint() throws Exception;
/**
* isReadyToCheckpointメソッドは、現時点が現在のchunkでチェックポイント処理を行うタイミングかどうかを決定するために、
* 各アイテムの処理後に、バッチランタイムによって呼び出されます。
*
* @return 現時点でチェックポイント処理をするかどうかを示す。
* @throws Exception もしエラーが発生した場合
*/
public boolean isReadyToCheckpoint() throws Exception;
/**
* endCheckpointメソッドは現在のチェックポイントが終了した後に呼び出されます。
*
* @throws Exception もしエラーが発生した場合
*/
public void endCheckpoint() throws Exception;
}package javax.batch.api.chunk;
/**
* AbstractCheckpointAlgorithmはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public class AbstractCheckpointAlgorithm implements CheckpointAlgorithm {
/**
* もしCheckpointAlgorithmがチェックポイントタイムアウトを確立するならこのメソッドをオーバーライドします。
* デフォルト実装はランタイム環境が許容する最大のタイムアウトを意味する0を返します。
*
* @return 次のチェックポイントインターバルで使用するためのタイムアウトインターバル
* @throws もしエラーが発生した場合
*/
@Override
public int checkpointTimeout() throws Exception {
return 0;
}
/**
* チェックポイント開始前にCheckpointAlgorithmで実行する何がしかのためにこのメソッドをオーバーライドします。
* デフォルト実装は何もしません。
*
* @throws もしエラーが発生した場合
*/
@Override
public void beginCheckpoint() throws Exception {
}
/**
* チェックポイントがその時点でされるかどうかを決定するためのロジックをこのメソッドで実装します。
*
* @return 現時点でチェックポイント処理をするかどうかを示す。
* @throws もしエラーが発生した場合
*/
@Override
public boolean isReadyToCheckpoint() throws Exception {
return false;
}
/**
* チェックポイント終了後にCheckpointAlgorithmで実行する何がしかのためにこのメソッドをオーバーライドします。
* デフォルト実装は何もしません。
*
* @throws もしエラーが発生した場合
*/
@Override
public void endCheckpoint() throws Exception {
}
}*1 原文のcheckpointTimeout()には引数が無いのに@paramがあり謎。
batchletタイプのstepは環境独自のバッチパターンの実装を行います。このバッチパターンは一度呼び出されると、完了するまで実行され、完了ステータスを返します。
BatchletインタフェースはBatchletバッチアーティファクトを実装するために使用されます。
package javax.batch.api;
/**
* batchletは、chunk指向アプローチとは全く異なるバックグラウンド処理のために使用される、stepのタイプの一つです。
* <p>
* 仕様に沿ったbatchletは停止リクエストをstopメソッド実装によって応えます。
*/
public interface Batchlet {
/**
* processメソッドはbatchletの動作です。もしこのメソッドが例外をスローする場合、batchlet
* stepはバッチステータスFAILEDで終了します。
*
* @return 完了ステータスのstring
* @throws Exception もしエラーが発生した場合。
*/
public String process() throws Exception;
/**
* stopメソッドはJobOperator.stop()メソッド処理の一部としてバッチランタイムから呼び出されます。
* このメソッドはbatchletのprocessメソッドが実行中のスレッド以外のスレッドで呼び出されます。
*
* @throws Exception もしエラーが発生した場合。
*/
public void stop() throws Exception;
}package javax.batch.api;
/**
* AbstractBatchletはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public class AbstractBatchlet implements Batchlet {
/**
* このメソッドでbatchletのロジックを実装します。
*
* @return 完了ステータスのstring
* @throws Exception もしエラーが発生した場合。
*/
@Override
public String process() throws Exception {
return null;
}
/**
* もしbatchletがJobOperator.stop()への応答として終了する場合にこのメソッドをオーバーライドします。
* デフォルト実装は何もしません。
*
* @throws Exception もしエラーが発生した場合。
*/
@Override
public void stop() throws Exception {
}
}プログラミングガイドライン
JobOperator.stopが呼び出されるとき、良い設計のbatchletは潔く(gracefully)停止します。stop処理の詳細な情報については11.13節を参照してください。
バッチ実行に割り込むためにはリスナーを使用します。
ジョブリスナーはジョブ実行の前後や、例外がジョブ処理中にスローされた場合に制御が渡されます。JobListenerインタフェースはJobListenerバッチアーティファクトを実装するために使用されます。
package javax.batch.api.listener;
/**
* JobListenerはジョブの実行をインターセプトします。
*/
public interface JobListener {
/**
* beforeJobメソッドはジョブ実行の開始前に制御が渡されます。
* @throws Exception エラー発生時にスローされる例外
*/
public void beforeJob() throws Exception;
/**
* afterJobメソッドはジョブ実行の終了前に制御が渡されます。
* @throws Exception エラー発生時にスローされる例外
*/
public void afterJob() throws Exception;
}package javax.batch.api.listener;
/**
* AbstractJobListenerはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public class AbstractJobListener implements JobListener {
/**
* もしJobListenerがジョブ開始前にすることがあればこのメソッドをオーバーライドします。デフォルト実装は何もしません。
*/
@Override
public void beforeJob() throws Exception {
}
/**
* もしJobListenerがジョブ終了後にすることがあればこのメソッドをオーバーライドします。デフォルト実装は何もしません。
*/
@Override
public void afterJob() throws Exception {
}
}ステップリスナーはステップ実行の前後や、例外がステップ処理中にスローされた場合に、制御が渡されます。StepListenerインタフェースはStepListenerバッチアーティファクトを実装するために使用されます。
package javax.batch.api.listener;
/**
* StepListenerはジョブの実行をインターセプトします。
*/
public interface StepListener {
/**
* beforeStepメソッドはステップ実行の開始前に制御が渡されます。
* @throws Exception エラー発生時にスローされる例外
*/
public void beforeStep() throws Exception;
/**
* afterStepメソッドはステップ実行の終了前に制御が渡されます。
* @throws Exception エラー発生時にスローされる例外
*/
public void afterStep() throws Exception;
}package javax.batch.api.listener;
/**
* AbstractStepListenerはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public class AbstractStepListener implements StepListener {
/**
* もしStepListenerがステップ開始前にすることがあればこのメソッドをオーバーライドします。デフォルト実装は何もしません。
*/
@Override
public void beforeStep() throws Exception {
}
/**
* もしJobListenerがステップ終了後にすることがあればこのメソッドをオーバーライドします。デフォルト実装は何もしません。
*/
@Override
public void afterStep() throws Exception {
}
}チャンクリスナーは、チャンク処理の開始と終了時、チェックポイント処理の前後、に制御が渡されます。ChunkListenerインタフェースはChunkListenerバッチアーティファクトを実装するために使用されます。
package javax.batch.api.chunk.listener;
/**
* ChunkListenerはチャンク処理をインターセプトします。
*/
public interface ChunkListener {
/**
* beforeChunkメソッドは次のチャンク処理が開始する前に制御が渡されます。このメソッドはチャンク処理と同じトランザクションで呼び出されます。
*
* @throws Exception エラー発生時にスローされる例外
*/
public void beforeChunk() throws Exception;
/**
* onErrorメソッドはチャンクトランザクションがロールバックされる前に制御が渡されます。注意点として、
* afterChunkはこのケースでは呼び出されません。
*
* @param ex ロールバックの原因となった例外
* @throws Exception エラー発生時にスローされる例外
*/
public void onError(Exception ex) throws Exception;
/**
* afterChunkメソッドは現在のチャンク処理の終了後に制御が渡されます。このメソッドはチャンク処理と同じトランザクションで呼び出されます。
*
* @throws Exception エラー発生時にスローされる例外
*/
public void afterChunk() throws Exception;
}package javax.batch.api.chunk.listener;
/**
* AbstractChunkListenerはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public class AbstractChunkListener implements ChunkListener {
/**
* ChunkListenerがチャンク開始前にすることがあればこのメソッドをオーバーライドしてください。デフォルト実装は何もしません。
*
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void beforeChunk() throws Exception {
}
/**
* ChunkListenerがチャンクトランザクションがロールバックされる前にすることがあればこのメソッドをオーバーライドしてください。
* デフォルト実装は何もしません。
*
* @param ex ロールバックの原因となった例外
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void onError(Exception ex) throws Exception {
}
/**
* ChunkListenerがチャンク終了後にすることがあればこのメソッドをオーバーライドしてください。 デフォルト実装は何もしません。
*
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void afterChunk() throws Exception {
}
}item readリスナーは、item readerによってアイテムが読み込まれる前後や、readerが例外をスローした場合に、制御が渡されます。ItemReadListenerインタフェースはItemReadListenerバッチアーティファクトを実装するために使用されます。
package javax.batch.api.chunk.listener;
/**
* ItemReadListenerはitem reader処理をインターセプトします。
*/
public interface ItemReadListener {
/**
* beforeReadメソッドは次のアイテムを読み込むためにitem readerが呼び出される前に制御が渡されます。
*
* @throws Exception エラー発生時にスローされる例外
*/
public void beforeRead() throws Exception;
/**
* afterReadメソッドはitem readerがアイテムを読み込んだ後に制御が渡されます。
* このメソッドは入力値として読み込まれたアイテムが渡されます。
*
* @param item item readerによって読み込まれたアイテム
* @throws Exception エラー発生時にスローされる例外
*/
public void afterRead(Object item) throws Exception;
/**
* onReadErrorはitem readerがreadItemメソッドで例外をスローした後に制御が渡されます。
* このメソッドは入力値として例外が渡されます。
*
* @param ex item readerで発生した例外
* @throws Exception エラー発生時にスローされる例外
*/
public void onReadError(Exception ex) throws Exception;
}package javax.batch.api.chunk.listener;
/**
* AbstractItemReadListenerはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public class AbstractItemReadListener implements ItemReadListener {
/**
* ItemReadListenerでアイテムが読み込まれる前にすることがあればこのメソッドをオーバーライドしてください。デフォルトは何もしません。
*
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void beforeRead() throws Exception {
}
/**
* ItemReadListenerでアイテムが読み込まれた後にすることがあればこのメソッドをオーバーライドしてください。デフォルトは何もしません。
*
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void afterRead(Object item) throws Exception {
}
/**
* ItemReaderのreadItemメソッドが例外をスローしたときにすることがあればこのメソッドをオーバーライドしてください。
* デフォルトは何もしません。
*
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void onReadError(Exception ex) throws Exception {
}
}item processorリスナーはアイテムがitem processorによって処理される前後や、processorが例外をスローする場合に、制御が渡されます。ItemProcessListenerインタフェースはItemProcessListenerバッチアーティファクトを実装するために使用されます。
package javax.batch.api.chunk.listener;
/**
* ItemProcessListenerはアイテム処理をインターセプトします。
*/
public interface ItemProcessListener {
/**
* beforeProcessメソッドは次のアイテムを処理するためにitem processorが呼び出される前に制御が渡されます。
* このメソッドは入力値として処理されるアイテムが渡されます。
*
* @param item 処理対象のアイテム
* @throws Exception エラー発生時にスローされる例外
*/
public void beforeProcess(Object item) throws Exception;
/**
* afterProcessメソッドはitem processorがアイテムを処理したあとに制御が渡されます。
* このメソッドは入力値として処理されるアイテムと結果のアイテムを受け取ります。
*
* @param item 処理対象のアイテム
* @param result item writerへ渡されるアイテム
* @throws Exception エラー発生時にスローされる例外
*/
public void afterProcess(Object item, Object result) throws Exception;
/**
* (*1)
* @param item 処理対象のアイテム
* @param ex item processorがスローした例外
* @throws Exception エラー発生時にスローされる例外
*/
public void onProcessError(Object item, Exception ex) throws Exception;
}package javax.batch.api.chunk.listener;
/**
* AbstractItemProcessListenerはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public class AbstractItemProcessListener implements ItemProcessListener {
/**
* アイテム処理前にItemProcessListenerですることがあればこのメソッドをオーバーライドします。
* デフォルトは何もしません。
*
* @param item 処理対象のアイテム
* @throw Exception エラー発生時にスローされる例外
*/
@Override
public void beforeProcess(Object item) throws Exception {
}
/**
* アイテム処理後にItemProcessListenerですることがあればこのメソッドをオーバーライドします。
* デフォルトは何もしません。
*
* @param item 処理対象のアイテム
* @param result item writerに渡されるアイテム
* @throw Exception エラー発生時にスローされる例外
*/
@Override
public void afterProcess(Object item, Object result) throws Exception {
}
/**
* ItemProcessorのprocessItemメソッドが例外をスローしたときItemProcessListenerですることがあればこのメソッドをオーバーライドします。
* デフォルトは何もしません。
*
* @param item 処理対象のアイテム
* @param ex item processorによってローされた例外
* @throw Exception エラー発生時にスローされる例外
*/
@Override
public void onProcessError(Object item, Exception ex) throws Exception {
}
}*1 onProcessErrorにafterProcessの内容がコピペされてるっぽいので訳無し
item writeリスナーはアイテムがitem writerによって書き込まれる前後や、writerが例外をスローする場合に、制御が渡されます。ItemWriteListenerインタフェースはItemWriteListenerバッチアーティファクトを実装するために使用されます。
package javax.batch.api.chunk.listener;
import java.util.List;
/**
* ItemWriteListenerはアイテム書き込み処理をインターセプトします。
*/
public interface ItemWriteListener {
/**
* beforeWriteメソッドは処理済アイテムを書き込むためにitem writerが呼び出される前に制御が渡されます。
* このメソッドは入力値としてitem readerに渡されたアイテムのリストが渡されます。
* (*1)
*
* @param items 書き込み対象のアイテムのリスト
* @throws Exception エラー発生時にスローされる例外
*/
public void beforeWrite(List<Object> items) throws Exception;
/**
* afterWriteメソッドはitem writerがアイテムを書き込んだ後に制御が渡されます。
* このメソッドは入力値としてitem readerに渡されたアイテムのリストが渡されます。
*
* @param items 書き込み対象のアイテムのリスト
* @throws Exception エラー発生時にスローされる例外
*/
public void afterWrite(List<Object> items) throws Exception;
/**
* onWriteErrorメソッドはitem writerのwriteItemメソッドが例外をスローした後に制御が渡されます。
* このメソッドは入力値としてitem readerに渡されたアイテムのリストが渡されます。
*
* @param items 書き込み対象のアイテムのリスト
* @param ex item writerによってスローされた例外
* @throws Exception エラー発生時にスローされる例外
*/
public void onWriteError(List<Object> items, Exception ex) throws Exception;
}*1 processor通過後のアイテムなのか、readerに渡されたアイテムなのか、どっちなんだろうか……
skip listenerはスキップ可能例外がitem reader, processor, writerからスローされたときに制御を渡されます。三つのインターフェースがそれぞれについてのリスナーを実装するために用意されています。
package javax.batch.api.chunk.listener;
/**
* SkipReadListenerはスキップ可能なitemReaderの例外ハンドリングをインターセプトします。
*/
public interface SkipReadListener {
/**
* onSkipReadItemメソッドはItemReaderのreadItemメソッドからスキップ可能例外がスローされたときに制御が渡されます。
* このメソッドは入力値として例外を受け取ります。
*
* @param ex ItemReaderによってスローされた例外
* @throws Exception エラー発生時にスローされる例外
*/
public void onSkipReadItem(Exception ex) throws Exception;
}package javax.batch.api.chunk.listener;
/**
* SkipProcessListenerはスキップ可能なitemProcessの例外ハンドリングをインターセプトします。
*/
public interface SkipProcessListener {
/**
* onSkipProcessItemメソッドはItemProcessのprocessItemメソッドからスキップ可能例外がスローされたときに制御が渡されます。
* このメソッドは入力値として例外と処理対象のアイテムを受け取ります。
*
* @param item ItemProcessorに渡されたアイテム
* @param ex ItemProcessorでスローされた例外
* @throws Exception エラー発生時にスローされる例外
*/
public void onSkipProcessItem(Object item, Exception ex) throws Exception;
}package javax.batch.api.chunk.listener;
import java.util.List;
/**
* SkipWriteListenerはスキップ可能なitemWriterの例外ハンドリングをインターセプトします。
*/
public interface SkipWriteListener {
/**
* onSkipWriteItemsメソッドはItemWriterのwriteItemsメソッドからスキップ可能例外がスローされたときに制御が渡されます。
* このメソッドは入力値として例外とスキップされたアイテムを受け取ります。
* @param item item writerに渡されたアイテムのリスト
* @param ex ItemWriterでスローされた例外
* @throws Exception エラー発生時にスローされる例外
*/
public void onSkipWriteItem(List<Object> items, Exception ex) throws Exception;
}retry listenerはリトライ可能例外がitem reader, processor, writerからスローされたときに制御を渡されます。三つのインターフェースがそれぞれについてのリスナーを実装するために用意されています。
package javax.batch.api.chunk.listener;
/**
* RetryReadListenerはItemReaderのリトライ処理をインターセプトします。
*/
public interface RetryReadListener {
/**
* onRetryReadExceptionメソッドは、リトライ可能例外がItemReaderのreadItemメソッドからスローされたときに制御を渡されます。
* このメソッドは入力値とし例外を受け取り、ItemReaderと同様のチェックポイントスコープとなります。
* もしこのメソッドが例外をスローする場合、ジョブはFAILEDステータスで終了します。
*
* @param ex item readerでスローされた例外
* @throws エラー発生時にスローされる例外
*/
public void onRetryReadException(Exception ex) throws Exception;
}package javax.batch.api.chunk.listener;
/**
* RetryProcessListenerはItemProcessorのリトライ処理をインターセプトします。
*/
public interface RetryProcessListener {
/**
* onRetryProcessExceptionメソッドは、リトライ可能例外がItemProcessorのprocessItemメソッドからスローされたときに制御を渡されます。
* このメソッドは入力値として例外とそのとき処理中のアイテムを受け取ります。
* また、このメソッドはItemProcessorと同様のチェックポイントスコープとなります。
* もしこのメソッドが例外をスローする場合、ジョブはFAILEDステータスで終了します。
*
* @param item ItemProcessorに渡されたアイテム
* @param ex ItemProcessorでスローされた例外
* @throws エラー発生時にスローされる例外
*/
public void onRetryProcessException(Object item, Exception ex) throws Exception;
}package javax.batch.api.chunk.listener;
import java.util.List;
/**
* RetryWriteListenerはItemWriterのリトライ処理をインターセプトします。
*/
public interface RetryWriteListener {
/**
* onRetryWriteExceptionメソッドは、リトライ可能例外がItemWriterのwriteItemsメソッドからスローされたときに制御を渡されます。
* このメソッドは入力値として例外と書き込み中のアイテムのリストを受け取ります。
* また、このメソッドはItemWriterと同様のチェックポイントスコープとなります。
* もしこのメソッドが例外をスローする場合、ジョブはFAILEDステータスで終了します。
*
* @param items item writerに渡されたアイテムのリスト
* @param ex item writerでスローされた例外
* @throws エラー発生時にスローされる例外
*/
public void onRetryWriteException(List<Object> items, Exception ex) throws Exception;
}バッチアプリケーションはジョブが実行のために初期化されるときにパラメータを受け取る方法が必要です。プロパティをバッチプログラミングモデルのアーティファクトで定義することができ、ジョブが初期化されるときに渡された値を持ちます。バッチのプロパティは文字列です。
バッチのプロパティはそれが定義されたスコープのみが可視範囲です。しかし、バッチプロパティの値はXML置換表現ルールに沿って他のプロパティを使用できます。置換表現の詳細については8.8節を参照してください。
@BatchPropertyアノテーションはバッチプロパティとしてフィールドインジェクションを指定します。バッチプロパティは名前とデフォルト値を持ちます。@BatchPropertyはバッチプログラミングモデルのアーティファクト（たとえばItemReader, ItemProcessor, JobListenerなど）として作成された任意のクラスのフィールドで使用できます。
@BatchPropertyは標準の@Injectアノテーション(javax.inject.Inject)と共に使用する必要があります。@BatchPropertyはJob XMLのバッチアーティファクトのプロパティにバッチアーティファクトを割り当てるために使用します。
@BatchPropertyアノテーションの付与されたフィールドは非staticかつ非finalでなければなりません。
バッチランタイムは、実行環境がJSR229もしくはJSR330の実装を含んでいてもそうでなくても、@Injectが@BatchPropertyと共に動作することを保証します。バッチプロパティは常にインジェクトされることを意味します。他のインジェクション機構がサポートされているかどうかバッチランタイム実装に依存します。
文法:
package: javax.batch.api
@Inject @BatchProperty(name="<property-name>") String <field-name>;入力:
| オプション項目のバッチプロパティ名。デフォルト値はJavaのフィールド名 | |
| バッチプロパティのフィールド名 |
package javax.batch.api;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import javax.enterprise.util.Nonbinding;
import javax.inject.Qualifier;
@Qualifier
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER })
@Retention(RetentionPolicy.RUNTIME)
public @interface BatchProperty {
@Nonbinding
public String name() default "";
}当該バッチアーティファクトのスコープのJSLで一致する名前のプロパティ要素が定義されている場合、バッチランタイムによってアノテーション付与されたフィールドの値が割り当てられます。もしJSLのプロパティ値が空文字に解決される場合、割り当ては発生せずにJavaのデフォルト値が適用されます。注意点として、この仕様の範囲外のDIの使用は異なる結果を生む可能性があります。その結果生じる振る舞いは開発者が使用したDIに依存し、それはこの仕様の範囲外です。
例:
import javax.inject.Inject;
import javax.batch.api.BatchProperty;
public class MyItemReaderImpl {
@Inject @BatchProperty String fname;
}
振る舞い:
バッチランタイムがバッチアーティファクト（上の例ではitem reader）を初期化するとき、Job XMLでのnamedプロパティの値を対応する@BatchPropertyのフィールドに割り当てます。もし値が無ければJavaのデフォルト値となります。
バッチランタイムから提供されるコンテキストオブジェクトはバッチアプリケーションに重要な機能を提供します。コンテキストは、実行中のバッチジョブに関する情報、中間結果を格納するバッチジョブのための領域、バッチアプリケーションがバッチランタイムへ重要な情報を書き戻す方法、を提供します。コンテキストはメンバ変数としてアプリケーションにインジェクトできます。jobとstep両方についてのコンテキストが存在します。ジョブコンテキストはjob全体を表現しています。ステップコンテキストはjob内で現在実行中のstepを表現しています。
バッチアーティファクトは標準@Injectアノテーション(javax.inject.Inject)を使用したインジェクションによってバッチコンテキストにアクセスします。バッチコンテキストがインジェクトされるフィールドは非staticかつ非finalでなければなりません。
例:
@Inject JobContext _jctxt;
@Inject StepContext _sctxt;バッチランタイムは現在実行中のjobかstepに従って正しいコンテキストオブジェクトがインジェクトされることを保証する責務があります。
バッチランタイムは、実行環境がJSR229もしくはJSR330の実装を含んでいてもそうでなくても、@InjectがJobContextとStepContextと共に動作することを保証します。バッチコンテキストは常にインジェクトされることを意味します。他のインジェクション機構がサポートされているかどうかバッチランタイム実装に依存します。
JobContextの定義については10.9.1を、StepContextの定義については10.9.2を参照してください。
バッチコンテキストはスレッドアフィニティを持ち、特定のスレッドで実行中のバッチアーティファクトでのみアクセス可能です。バッチコンテキストがインジェクトされたフィールドはスコープ外ではnullになります。各コンテキストタイプはタイプごとにスコープと下記のようなライフサイクルを持ちます。
- JobContext
job実行ごとに一つのJobContextが存在し、jobの生存期間と同じくする。（パーティーションstepなどの）パラレル実行のサブスレッドごとに別々のJobContextが存在する。 - StepContext
step実行ごとに一つStepContextが存在し、stepの生存期間と同じくする。パーティーションstepでは、親step／スレッドに一つのStepContextが存在する。サブスレッドごとに別々のStepContextが存在する。
バッチジョブは複数のstepをパラレル実行に設定可能です。二つのパラレル実行モデルがサポートされています。
1.Partitioned:
partitionedモデルでは、stepは複数スレッドにまたがる複数インスタンスとして動作するように設定されます。各スレッドは同一のstepかflowを実行します。このモデルは同一stepを複数インスタンスで実行するのと論理的に同等です。各パーティーションが入力アイテムの異なる範囲を処理することを意味します。
partitionedモデルはパラレル処理に対する細かな制御を可能にするバッチアーティファクトのオプションが含まれています。
- PartitionMapperはパーティーションごとのプロパティとパーティーション数をプログラミングによって算出する方法を提供します。
- PartitionReducerはパーティーション処理の間で単位処理を行う方法を提供します。
- PartitionCollectorは個々のパーティーションから中間結果をマージする方法を提供します。
- PartitionAnalyzerは中間結果を収集して個々のパーティーションからの最終結果を返す方法を提供します(*1)。
*1 for single point of control processing and decision making.が上手く訳せない…意味的にはmap-recduce的な並行データ処理モデルで分析結果を意思決定に役立てます、ってことなんだろうけども。
2.Concurrent:
concurrentモデルでは、splitによって定義されるflowは1スレッド1flowの複数スレッドでコンカレントに動作するよう設定できます。
partition mapperはパーティーション実行の開始時に制御を渡されます。partition mapperはパーティーションごとにユニークなバッチプロパティを渡す役割を持ちます。PartitionMapperインターフェースはPartitionMapperバッチアーティファクトを実装するために使用されます。
package javax.batch.api.partition;
import javax.batch.api.partition.PartitionPlan;
/**
* PartitionMapperはパーティーション実行の開始時に制御を渡されます。
* PartitionMapperはパーティーションごとにユニークなバッチプロパティを渡す役割を持ちます。
*/
public interface PartitionMapper {
/**
* mapPartitionsメソッドはパーティーション化step処理の開始時に制御を渡されます。
* PartitionPlanを返すメソッドは、各パーティーションごとのバッチプロパティを指定します。
* @return パーティーションstep用のpartition plan
* @throws Exception エラー発生時にスローされる例外
*/
public PartitionPlan mapPartitions( ) throws Exception;
}注意点として、PartitionMapperはjobのリスタートでは呼び出されません。バッチランタイムは初回のJobExecutionでpartition planを記憶しており、同一のJobInstanceではすべての後続のJobExecutionでそれを使用します。
戻り値となるPartitionPlan型の詳細については10.9.3節を参照してください。
partition reducerはパーティーション処理の間で単位処理を行う方法(unit of work demarcation across partitions)(*1)を提供します。非JTA transactionで、どのリソースもJTA下に入りません。partition reducerが提供するのは、補償ロジックまたは終了処理のマージを調整するトランザクショナル・フロー・セマンティクス(transactional flow semantic)です。PartitionReducerインターフェースはPartitionReducerバッチアーティファクトを実装するために使用されます。
*1 並行処理あんま詳しくないんで、おかしな日本語なんだよなぁ……たぶん、そっちの分野でなら良く出てくる用語な気がするので、分かる人には分かるんだろうと思われ
package javax.batch.api.partition;
/**
* PartitionReducerはpartitionsにまたがる単位処理を行う方法を提供します。
* 非JTA transactionで、どのリソースもJTA下に入りません。
* PartitionReducerが提供するのは補償ロジックまたは終了処理のマージを調整するトランザクショナル・フロー・セマンティクスです。
*/
public interface PartitionReducer {
public enum PartitionStatus {COMMIT, ROLLBACK}
/**
* beginPartitionedStepメソッドはパーティーション処理の開始時に制御が渡されます。
* PartitionMapperが呼び出される前と任意のパーティーションが開始する前に制御が渡されます。
* @throws Exception エラー発生時にスローされる例外
*/
public void beginPartitionedStep() throws Exception;
/**
* beforePartitionedStepCompletionメソッドはパーティション化step処理の終了時に制御が渡されます。
* すべてのパーティーションが完了した後に制御が渡されます。
* もしPartitionReducerがロールバックする場合には制御は渡されません。
* @throws Exception エラー発生時にスローされる例外
*/
public void beforePartitionedStepCompletion() throws Exception;
/**
* rollbackPartitionedStepメソッドは、もしランタイムがパーティーション化stepをロールバックする場合に、制御が渡されます。
* 実行中の任意のパーティーションスレッドはこのメソッドが呼び出される前に完了可能です。
* このメソッドは以下の条件のいずれかがtrueの場合に制御が渡されます。
* <p>
* <ol>
* <li>1つまたは複数のパーティーションのバッチステータスがSTOPPEDかFAILEDで終了。</li>
* <li>以下のパーティーション化stepのコールバックのいずれかかが例外をスロー。</li>
* <ol>
* <li>PartitionMapper</li>
* <li>PartitionReducer</li>
* <li>PartitionCollector</li>
* <li>PartitionAnalyzer</li>
* </ol>
* <li>パーティーション化stepのjobがリスタート。</li>
* </ol>
* @throws Exception エラー発生時にスローされる例外
*/
public void rollbackPartitionedStep() throws Exception;
/**
* afterPartitionedStepCompletionメソッドはパーティーション処理の終了時に制御が渡されます。
* パーティーション処理の結果を意味するステータス値が渡されます。
* ステータスの文字列は"COMMIT"か"ROLLBACK"のどちらかです。
* @param status パーティーション化stepの結果。"COMMIT"か"ROLLBACK"のどちらか。
* @throws Exception エラー発生時にスローされる例外
*/
public void afterPartitionedStepCompletion(PartitionStatus status) throws Exception;
}package javax.batch.api.partition;
/**
* AbstractBatchletはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public abstract class AbstractPartitionReducer implements PartitionReducer {
/**
* パーティーションstep処理が開始する前に実行する処理のためにこのメソッドをオーバーライドします。
*
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void beginPartitionedStep() throws Exception {}
/**
* 通常のパーティーションstep処理の終了前に実行する処理のためにこのメソッドをオーバーライドします。
*
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void beforePartitionedStepCompletion() throws Exception {}
/**
* パーティションstepがロールバックされるときに実行する処理のためにこのメソッドをオーバーライドします。
*
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void rollbackPartitionedStep() throws Exception {}
/**
* パーティションstep処理の終了後に実行する処理のためにこのメソッドをオーバーライドします。
*
* @param status パーティーションstepの結果。"COMMIT"か"ROLLBACK"のどちらか。
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void afterPartitionedStepCompletion(PartitionStatus status)
throws Exception {}
}partition collectorは個々のパーティーションから親スレッドで動作する単一制御点(a single point of control)へデータを送る方法を提供します。PartitionAnalyzerはデータの受け取りと処理に使用されます。PartitionAnalyzerの詳細については9.5.4節を参照してください。PartitionCollectorインタフェースはPartitionCollectorバッチアーティファクトを実装するためにしようされます。
package javax.batch.api.partition;
import java.io.Serializable;
/**
* PartitionCollectorは個々のパーティーションからstepの親スレッドで動作する単一制御点へデータを渡す方法を提供します。
* PartitionAnalyzerはデータを受け取って処理するために使用されます。
*/
public interface PartitionCollector {
/**
* collectPartitionDataメソッドはパーティーション処理中に定期的に制御が渡されます。
* このメソッドは以下のような各スレッドがパーティーションを処理する時点で制御が渡されます。
* <p>
* <ol>
* <li>chunkタイプのstepでは、各chunkのチェックポイント後とパーティーション終了時の最終チェックポイント後に制御が渡されます。</li>
* <li>batchletタイプのstepでは、batchletの終了時に制御が渡されます。</li>
* </ol>
* <p>
* 注意点として、collectorは、もしパーティーションがunhandledな例外起因で終了する場合、呼び出されません。
* <p>
* @return PartitionAnalyzerに渡すためのSerializableなオブジェクト
* @throws Exception エラー発生時にスローされる例外
*/
public Serializable collectPartitionData() throws Exception;
}partition analyzerはパーティーションの最終結果とデータを処理する目的のために制御が渡されます。もしpartition collectorがstepに設定されている場合、partition analyzerはpartition collectorから結果とデータを処理するために制御が渡されます。別々のpartition collectorのインスタンスがパーティーションを処理する各スレッドで呼び出される限り、partition analyzerはシングルスレッドで動作し、一貫性のあるスレッド(consistent thread)で毎回呼び出されます。PartitionAnalyzerインタフェースはPartitionAnalyzerバッチアーティファクトを実装するために使用されます。
package javax.batch.api.partition;
import java.io.Serializable;
import javax.batch.runtime.BatchStatus;
/**
* PartitionAnalyzerは各パーティーションからの最終結果とデータを処理するために制御が渡されます。
* PartitionCollectorがstepに設定されている場合、PartitionAnalyzerはpartition collectorから
* 結果とデータ処理のために制御が渡されます。
* 別々のPartitionCollectorインスタンスがstepパーティーションを処理する個々のスレッドで
* 呼び出される限り、単一のPartitionAnalyzerインスタンスが単一のスレッドで動作し、一貫性のある
* スレッドで毎回呼び出されます。
*
*/
public interface PartitionAnalyzer {
/**
* analyzeCollectorDataメソッドはPartition collectorが処理結果(*1)を送り出す度に制御が渡されます。
* 入力値としてSerializableなオブジェクトがcollectorから渡されます。
*
* @param data PartitionCollectorから送られる処理結果
* @throws Exception エラー発生時にスローされる例外
*/
public void analyzeCollectorData(Serializable data) throws Exception;
/**
* analyzeStatusメソッドはパーティーションが終了する度に制御が渡されます。
* 入力値としてパーティーションのバッチステータスと完了ステータスが渡されます
*
* @param batchStatus パーティーションのバッチステータス
* @param exitStatus パーティーションの完了ステータス
* @throws Exception エラー発生時にスローされる例外
*/
public void analyzeStatus(BatchStatus batchStatus, String exitStatus) throws Exception;
}*1 原文ではpayload. Partition collectorの戻り値で「データ本体」みたいなニュアンスなんだろうし、まぁ「処理結果」という安直な訳でいいか、と妥協した。
package javax.batch.api.partition;
import java.io.Serializable;
import javax.batch.runtime.BatchStatus;
/**
* AbstractPartitionAnalyzerはメソッドをただ実装しただけのデフォルト実装を提供します。
*/
public abstract class AbstractPartitionAnalyzer implements PartitionAnalyzer {
/**
* PartitionCollectorの処理結果を分析するにはこのメソッドをオーバーライドします。
*
* @param data PartitionCollectorから送られる処理結果
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void analyzeCollectorData(Serializable data) throws Exception {}
/**
* パーティーションの終了ステータスを分析するにはこのメソッドをオーバーライドします。
*
* @param batchStatus パーティーションのバッチステータス
* @param exitStatus パーティーションの完了ステータス
* @throws Exception エラー発生時にスローされる例外
*/
@Override
public void analyzeStatus(BatchStatus batchStatus, String exitStatus)
throws Exception {}
}deciderはJob XMLのstep, split, flow間のバッチ完了ステータスと遷移を決定するために使用されます。deciderは次の遷移先選択を決定するための完了ステータス値となる文字列を返します。DeciderインタフェースはDeciderバッチアーティファクトを実装するために使用されます。
package javax.batch.api;
import javax.batch.runtime.StepExecution;
/**
* Deciderはjobにおけるdecision要素の一部として制御を渡されます。
* job処理の間でflowを管理するために使用されます。
* 現在のjob実行完了ステータスをアップデートする完了ステータスを返します。
* この完了ステータス値はまた、deciderと同様のdecision要素で構成されるnext, end, stop, fail子要素に基づいて、実行の遷移を管理します。
*
*/
public interface Decider {
/**
* decideメソッドはjobに新しい完了ステータスを設定します。
* 入力値としてStepExecutionオブジェクトの配列を受け取ります。
* このStepExecutionオブジェクトは以下のようなdeciderへ遷移する実行要素を表現しています。
* <p>
* <ul>
* <li>Step</li>
* <p>
* 遷移がstepからのとき、decideメソッドは入力値としてそのstepに対応するStepExecutionを受け取ります。
* <li>Split</li>
* <p>
* 遷移がsplitからのとき、decideメソッドは入力値としてsplitに定義された各flowからのStepExecutionを受け取ります。
* <li>Flow</li>
* <p>
* 遷移がflowからのとき、decideメソッドはflowで完了した最後の実行要素に対応するStepExecutionを受け取ります。
* もし最後の要素がstepだった場合は一つのStepExecutionとなり、
* もし最後の要素がsplitだった場合は複数のStepExecutionとなります。
* </ul>
* @param executions この要素の前に実行された要素のStepExecution(s)
* @return 更新されるjob完了ステータス
* @throws Exception エラー発生時にスローされる例外
*/
public String decide(StepExecution[] executions) throws Exception;
}chunkタイプのチェックポイントはトランザクショナルです。バッチランタイムはJava EEプラットフォームではグローバル・トランザクション・モード(global transaction mode)を使用し、Java SEプラットフォームではローカル・トランザクション・モード(local transaction mode)を使用します。グローバル・トランザクション・タイムアウトはstepレベルのプロパティで設定可能です。
- javax.transaction.global.timeout={seconds} - デフォルトは180秒。
例:
<step id="MyGlobalStep">
<properties>
<property name="javax.transaction.global.timeout" value="600"/>
</properties>
</step>バッチランタイムはjob、 step、 パーティーション、アーティファクトレベルのプロパティをサポートしています。プロパティ名のプレフィクスjavax.batchは、バッチランタイムとこの仕様および将来のバージョンに向けて、予約されています。アプリケーションと仕様実装はこのプレフィクスで始まる独自のプロパティ定義は禁止されています。アプリケーションは未定義の振る舞いによる危険を冒すことになります。
バッチランタイムは以下のchunkタイプstepのメトリクスをサポートします。
- readCount - 読み込みの成功回数。
- writeCount - 書き込みの成功回数。
- filterCount - ItemProcessorによってフィルターされた回数。
- commitCount - トランザクションがコミットされた回数。
- rollbackCount - トランザクションがロールバックされた回数。
- readSkipCount - ItemReaderからスローされたスキップ可能例外の回数。
- processSkipCount - ItemProcessorからスローされたスキップ可能例外の回数。
- writeSkipCount - ItemWriterからスローされたスキップ可能例外の回数。
このメトリクスはStepExecutionランタイムオブジェクトを通して利用できます。StepExecutionの詳細な情報については10.9.10節を参照してください。
ジョブランタイムアーティファクトは以下の操作識別子でランタイムに一意定義されています。
| instanceId | ジョブインスタンスを表現するlong値。JobOperatorの"start"メソッドでjobが開始される度に新規のジョブインスタンスが作成されます。 |
| executionId | 次に実行を試行する特定のジョブインスタンスを表現するlong値。新規の実行は、最初にjobが開始されるときと、既存のjob実行がJobOperatorの"restart"メソッドでリスタートされる時に毎回、作成されます。注意点として、あるジョブインスタンスでは一度に一つのexecutionIdしかSTARTEDステータスは存在できません。 |
| stepExecutionId | job実行内のある特定のstepを実行する試行をを表現するlong値。 |
注意点として、instanceId, executionId, stepExecutionIdはジョブリポジトリ内ですべてグローバル・ユニークです。ジョブリポジトリの説明については7.4節を参照しだくさい。
JobOperatorインタフェースは、jobの開始・停止・リスタート・検査するための操作セットを提供します。このインタフェースの詳細な説明については10.9.6節を参照してください。JobOperatorインタフェースはファクトリーパターン経由で参照可能です。
JobOperator jobOper = BatchRuntime.getJobOperator();BatchRuntimeクラスの詳細については10.9.5節を参照してください。
バッチアプリケーションを構成するすべてのバッチアーティファクトは以下の順序に従うローダーによってロードされます。
- Implementation-specific loader
バッチランタイムの実装は、Job XMLのバッチアーティファクト参照（例えば'ref='attribute）の実装クラス解決とインスタンス化の手段を、実装固有(implementation-specific)の方法で提供_する可能性があります_。バッチランタイムがバッチアーティファクト参照をインスタンス化しようとする時、実装固有のメカニズム（が一つでも存在すれば）が最初に試行されます。ローダーはインスタンスもしくはnullを返さなければなりません。
実装固有ローダーの例はCDIやSpring DIになります。 - Archive loader
もし実装固有のメカニズムが存在しないかバッチアーティファクト参照の解決に失敗する（nullを返す）場合、バッチランタイムの実装はアーカイブローダーで参照を解決しなければなりません。ランタイムの実装は、参照名を実装クラス名にマッピングするbatch.xmlファイルを基にして、参照をルックアップで解決するアーカイブローダーを提供しなければなりません。ローダーはインスタンスもしくはnullを返さなければなりません。
batch.xmlファイルは開発者がMETA-INFディレクトリ下のアプリケーション（WEB-INF/classes/META-INFの.warファイル）としてパッケージ化します。batch.xmlの詳細については10.7.1節を参照してください。 - Thread Context Class Loader
もしアーカイブローダーがバッチアーティファクト参照の解決に失敗する（nullを返す）場合、バッチランタイム実装はクラス名で参照を解決してスレッドコンテキストクラスローダー(thread context class loader)を通してロードしなければなりません。ローダーはインスタンスかnullを返さなければなりません。
Job XMLはjobを開始するためのJobOperator.startコマンドの名前によって定義されます。
すべてのJob XML参照は以下の順序に従うローダーによってロードされます。
- implementation-specific loader
バッチランタイムの実装はJob XML参照をJob XMLドキュメントに解決する実装固有の手段を提供_しなければなりません_。
実装固有ローダーの目的は、リポジトリ・ファイルシステム・リモートキャッシュなどの、アプリケーションアーカイブの外側からXMLロードを出来るようにするためです。 - archive loader
もし実装固有メカニズムがJob XML参照の解決に失敗する場合、バッチランタイム実装はアーカイブローダーで参照を解決しなければなりません。実装はMETA-INF/batch-jobsディレクトリからルックアップして参照を解決するアーカイブローダーを提供しなければなりません。
Job XMLドキュメントは開発者がMETA-INF/batch-jobsディレクトリ下にアプリケーション(WEB-INF/classes/META-INF/batch-jobsの.warファイル)と共にパッケージ化します。
META-INF/batch-jobsの詳細については10.7.2節を参照してください。
バッチアプリケーションを構成するバッチアーティファクトのパッケージングは一つではありません。標準的なjarファイルにパッケージ化したり、ターゲットの実行環境でサポートされている任意のJavaアーカイブタイプに含めることが可能です。たとえば、バッチアーティファクトはwarやEJB jarなどに含めることができ、バッチジョブを初期化するプログラム（例：JobOperatorのstartメソッドを用いるもの）のクラスローダースコープと同等な生存期間となります。
バッチアプリケーションはバッチアーティファクトをロードするためにアーカイブローダー（10.5節を参照）を使用することがあります。アプリケーションはオプションのbatch.xmlによりダイレクトアーティファクトローディング(direct artifact loading)が可能です。batch.xmlはMETA-INFディレクトリ下に配置する必要があります。.jarファイルでは標準的なMETA-INFディレクトリで、.warファイルではWEB-INF/classes/META-INFディレクトリです。
batch.xmlのフォーマットとコンテンツは以下の通りです。
<batch-artifacts xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<ref id="<reference-name>" class="<impl-class-name>" />
</batch-artifacts>入力：
<reference-name> |
バッチアーティファクトの参照名を指定する。Jo XMLのref= attributeで指定される値。 |
<impl-class-name> |
バッチアーティファクト実装の完全修飾クラス名を指定する。 |
注意点：
- もし実装固有ローダーが使用される場合（10.5節参照）、実装固有ローダーがロードしたアーティファクトはbatch.xmlで指定されるアーティファクトより優先されます。
- batch.xmlを使用するバッチアーティファクトのロードはJavaのデフォルトコンストラクタに依存します。
バッチアプリケーションはJob XMLドキュメントをロードするためにアーカイブローダー(10.6節を参照)を使用することがあります。META-INF/batch-jobsディレクトリ下にJob XMLドキュメントを配置することでアプリケーションはこのロード方法を実行します。.jarファイルではbatch-jobsディレクトリは標準META-INFディレクトリ下になり、.warファイルではWEB-INF/classes/META-INFディレクトリ下になります。注意点として、Job XMLドキュメントはbatch-jobsディレクトリでのみ有効で、サブディレクトリは無視されます。
META-INF/batch-jobsに配置されたたJob XMLドキュメントは規約に沿って.xmlにします。
入力：
<name> |
Job XML名を指定する。JobOperator.startコマンドで指定する値。 |
| .xml | META-INF/batch-jobs下のJob XMLファイルに要求されるファイルタイプ。 |
注意点として、もし実装固有ローダー（10.6節参照）がJob XMLドキュメントをロードする場合、そのJon XMLドキュメントはMETA-INF/batch-jobs下に配置されたドキュメントより優先されます。
JobOperator restartメソッドはJobExecutionをリスタートするために使用されます。JobExecutionがリスタート可能な場合とは、
- そのバッチのバッチステータスがSTOPPEDかFAILEDである。
- 最新のJobExecutionである。
リスタート時には、jobは以下のように処理されます。
- 置換(Substitutions)(*1)処理
- リスタートポジションが決定される。リスタートポジションは以下のどちらかです。
- もし要素で直前の実行が終了している場合、要素で指定された実行要素となる。
- 8.2.5節Step Sequenceで説明されたように、最初のジョブ開始時と同様に最初の実行要素が決定される。
- リスタートポジションからスタート時には、各実行要素は再実行すべきかどうかを決定するために再検査(re-examined)されます。
- もし実行要素がallow-restart-if-complete=falseを指定するCOMPLETEDなstepな場合、直前の実行からこのstepへの完了ステータスに基づいた次の実行要素へと遷移します。
- もし実行要素がallow-restart-if-complete=trueを指定するCOMPLETEDなstepな場合、そのstepを再実行(re-run)して次の実行要素へと遷移します。
- もし実行要素がSTOPPEDかFAILEDなstepな場合、stepをリスタートして次の実行要素に遷移します。
注意点として、もしパーティーションstepな場合、以前に完了しなかったパーティーションのみがリスタートされます。この振る舞いはPartitionPlanを通して上書きでき、PartitionPlanの詳細については10.9.4節に記述されています。 - もし実行要素がdecisionな場合、decisionを実行して次の実行要素に遷移します。
- もし実行要素がflowな場合、flowの最初の実行要素を調査(examine)して上記3.aに書いてある実行要素の調査を続けます。flowの全ての実行要素が調査され終わった時、flowで調査された最終実行要素の完了ステータスに基づいてフロ―の遷移(flow's transition)が行われます。
- もし実行要素がsplitの場合、splitの各flowをリスタートして上記3.aに書いてある実行要素の調査を続けます。splitの全flowが調査され終わった時、次の実行要素へとstplitの遷移(split's transition)が行われます。
*1 8.8.1節あたりに書いてあるSubstitution Processingのことだと思われる。
ジョブパラメーター値はある実行から次の実行へと引き継がれません。ジョブリスタート時のすべてのジョブパラメータの置換は、リスタート時に指定されるジョブパラメータのみに基づいて実行されます。
jobのリスタートルールは8.8.1.8節を参照してください。
package javax.batch.runtime.context;
import java.util.Properties;
import javax.batch.runtime.BatchStatus;
/**
* JobContextは現在のjob実行に関する情報を提供します。
*/
public interface JobContext {
/**
* job名の取得。
* @return 'id'属性の値
*/
public String getJobName();
/**
* getTransientUserDataメソッドは現在のJob XML実行要素に属する一時的(transient)なデータオブジェクトを返します。
* @return ユーザ指定(user-specified)の型
*/
public Object getTransientUserData();
/**
* setTransientUserDataメソッドは現在のバッチコンテキストに一時的なデータオブジェクトを設定します。
* @param data ユーザ指定の型
*/
public void setTransientUserData(Object data);
/**
* getInstanceIdメソッドは現在のジョブインスタンスIDを返します。
* @return ジョブインスタンスID
*/
public long getInstanceId();
/**
*getExecutionIdメソッドは現在のjob実行IDを返します。
* @return job実行ID
*/
public long getExecutionId();
/**
* getPropertiesメソッドはジョブ定義で指定されたジョブレベルプロパティを返します。
* @return ジョブレベルプロパティ
*/
public Properties getProperties();
/**
* getBatchStatusメソッドはバッチステータスからジョブコンテキストに設定されたバッチステータス値を返します。
* @return バッチステータスの文字列
*/
public BatchStatus getBatchStatus();
/**
* getExitStatusメソッドはsetExitStatusメソッドでジョブコンテキストに設定された完了ステータス値かnullを返します。
* @return 完了ステータスの文字列
*/
public String getExitStatus();
/**
* setExitStatusメソッドは現在のjobにユーザ指定の完了ステータスを設定します。
* jobが終了するとき、jobの完了ステータスはsetExitStatusで設定された値になります。
* もしsetExitStatusが呼ばれていないかnullが設定された場合、完了ステータスはデフォルトであるjobのバッチステータスになります。
* @Param status ステータスの文字列
*/
public void setExitStatus(String status);
}package javax.batch.runtime.context;
import java.io.Serializable;
import java.util.Properties;
import javax.batch.runtime.BatchStatus;
import javax.batch.runtime.Metric;
/**
* StepContextはjob実行における現在のstepに関する情報を提供します。
*/
public interface StepContext {
/**
* step名の取得。
* @return <step>の'id'属性値
*/
public String getStepName();
/**
* getTransientUserDataメソッドは現在のJob XML実行要素に属する一時的なデータオブジェクトを返します。
* @return ユーザ指定(user-specified)の型
*/
public Object getTransientUserData();
/**
* setTransientUserDataメソッドは現在のバッチコンテキストに一時的なデータオブジェクトを設定します。
* @param data ユーザ指定の型
*/
public void setTransientUserData(Object data);
/**
* getStepExecutionIdメソッドは現在のstep実行IDを返します。
* @return step実行ID
*/
public long getStepExecutionId();
/**
* getPropertiesメソッドはジョブ定義で指定されたステップレベルプロパティを返します。
* @return ステップ(*1)レベルプロパティ
*/
public Properties getProperties();
/**
* getPersistentUserDataメソッドは現在のstepに属する永続的な(persistent)データオブジェクトを返します。
* ユーザデータ型はjava.util.Serializableの実装が必須です。
* このデータはstepのチェックポイントの一部として保存されます。
* チェックポイントが無いstepでは、step終了後に保存されます。
* このデータはリスタート時に利用可能です。
* @return ユーザ指定の型
*/
public Serializable getPersistentUserData();
/**
* setPersistentUserDataメソッドは現在のstepに永続的なデータオブジェクトを設定します。
* ユーザデータ型はjava.util.Serializableの実装が必須です。
* このデータはstepのチェックポイントの一部として保存されます。
* チェックポイントが無いstepでは、step終了後に保存されます。
* このデータはリスタート時に利用可能です。
* @param data ユーザ指定の型
*/
public void setPersistentUserData(Serializable data);
/**
* getBatchStatusメソッドは現在のstepのバッチステータスを返します。
* この値はバッチランタイムによって設定され、バッチステータスの何らかの変更により変化します。
* @return バッチステータスの文字列
*/
public BatchStatus getBatchStatus();
/**
* getExitStatusメソッドはsetExitStatusメソッドでステップコンテキストに設定された完了ステータス値かnullを返します。
* @return 完了ステータスの文字列
*/
public String getExitStatus();
/**
* setExitStatusメソッドは現在のstepにユーザ指定の完了ステータスを設定します。
* stepが終了するとき、stepの完了ステータスはsetExitStatusで設定された値になります。
* もしsetExitStatusが呼ばれていないかnullが設定された場合、完了ステータスはデフォルトであるstepのバッチステータスになります。
* @Param status ステータスの文字列
*/
public void setExitStatus(String status);
/**
* getExceptionメソッドはステップレベルバッチアーティファクトがバッチランタイムにスローした最後の例外を返します。
* @return 最後の例外
*/
public Exception getException();
/*
* getMetricsメソッドはステップレベルメトリクスの配列を返します。
* これらのデータはコミットやスキップなどの計測値です。
* @see javax.batch.runtime.metric.Metric 標準のメトリクス定義
* @return metrics array
*/
public Metric[] getMetrics();
}*1 原文はjobになってるけどタブンstepだと思う。
package javax.batch.runtime;
/**
* Metricインタフェースはバッチランタイムによって記録されるジョブメトリクスを定義します。
*/
public interface Metric {
public enum MetricType {READ_COUNT, WRITE_COUNT, COMMIT_COUNT,
ROLLBACK_COUNT, READ_SKIP_COUNT, PROCESS_SKIP_COUNT, FILTER_COUNT,
WRITE_SKIPCOUNT}
/**
* getNameメソッドはメトリクスのタイプを返します。
* @return メトリクスのタイプ
*/
public MetricType getType();
/**
* getValueメソッドはメトリクスの値を返します。
* @return メトリクスの値
*/
public long getValue();
}package javax.batch.api.partition;
import java.util.Properties;
/**
* PartitionPlanは @PartitionMapper メソッドによって設定されるパーティーション処理情報を運搬するためのヘルパークラスです。
*
* PartitionPlanには下記が含まれます。
* <ol>
* <li>パーティーションインスタンスの数</li>
* <li>パーティーションを実行するスレッド数</li>
* <li>各パーティーションごとの置換プロパティ</li>
* </ol>
*/
public interface PartitionPlan {
/**
* パーティーション数の設定。
* @param count パーティーション数の指定
*/
public void setPartitions(int count);
/**
* 前回job実行時のパーティーション数をオーバーライドするかどうかを指定します。
* stepのリスタート時にのみ適用され、デフォルトはfalseです。
* <p>
* falseが指定された場合、パーティーション数は前回実行時の値が使われ、
* 新しいパーティーション数が現在の実行で設定されてもすべて無視されます。
* 加えて、前回job実行のパーティーション結果は記憶されており、未完了パーティーションのみが再処理されます。
* <p>
* trueが指定された場合、パーティーション数は現在の実行の値が使われ、今までの
* パーティーションの全結果は廃棄されます。
* 任意のリソースについて、前回実行時における中途の状態を取り消すか
* クリーンアップすることは、アプリケーションの責任です。
* PartitionReducerアーティファクトのrollbackPartitionedStepメソッドは、
* 任意のパーティーションがクリーンアップ・フックを提供するための処理を開始する前に、リスタート中に呼ばれます。
*/
public void setPartitionsOverride(boolean override);
/**
* パーティーションの現在値が設定をオーバーライドしているかを返します。
* @return 設定をオーバーライドしているかどう。あ
*/
public boolean getPartitionsOverride();
/**
* スレッド数。
* デフォルトはゼロで、スレッド数とパーティーション数が等しいことを意味します。
* @param count スレッド数の指定
*/
public void setThreads(int count);
/**
* パーティーションのセット用に置換プロパティオブジェクトの配列を設定する。
* @param props プロパティオブジェクト配列を指定
*/
public void setPartitionProperties(Properties[] props);
/**
* パーティーション数の取得。
* @return パーティーション数
*/
public int getPartitions();
/**
* スレッド数の取得。
* @return スレッド数
*/
public int getThreads();
/**
* Partition Propertiesオブジェクトの配列を取得する。
* @return Partition Propertiesオブジェクトの配列
*/
public Properties[] getPartitionProperties();
}package javax.batch.api.partition;
import java.util.Properties;
/**
* PartitionPlanImplクラスはPartitionPlanのベーシックな実装を提供します。
*/
public class PartitionPlanImpl implements PartitionPlan {
private int partitions= 0;
private boolean override= false;
private int threads= 0;
Properties[] partitionProperties= null;
@Override
public void setPartitions(int count) {
partitions= count;
// デフォルトのスレッド数はパーティーション数となる。
if (threads == 0) threads= count;
}
@Override
public void setThreads(int count) {
threads= count;
}
@Override
public void setPartitionsOverride(boolean override) {
this.override= override;
}
@Override
public boolean getPartitionsOverride() {
return override;
}
@Override
public void setPartitionProperties(Properties[] props) {
partitionProperties= props;
}
@Override
public int getPartitions() {
return partitions;
}
@Override
public int getThreads() {
return threads;
}
@Override
public Properties[] getPartitionProperties() {
return partitionProperties;
}
}package javax.batch.runtime;
/**
* BatchRuntimeはバッチランタイム環境を表現しています。
*/
import javax.batch.operations.JobOperator;
/**
* BatchRuntimeはJSR 352のバッチランタイムを表現しています。
* JobOperatorインタフェースへのファクトリーアクセスを提供します。
*/
public class BatchRuntime {
/**
* getJobOperatorファクトリーメソッドはJobOperatorインタフェースのインスタンスを返します。
* @return JobOperatorインスタンス
*/
public static JobOperator getJobOperator() {return null;}
}package javax.batch.runtime;
/**
* BatchStatus enumはjobの取り得るバッチステータスを定義します。
*/
public enum BatchStatus {STARTING, STARTED, STOPPING,
STOPPED, FAILED, COMPLETED, ABANDONED }package javax.batch.operations;
import java.util.List;
import java.util.Set;
import java.util.Properties;
import javax.batch.runtime.JobExecution;
import javax.batch.runtime.JobInstance;
import javax.batch.runtime.StepExecution;
/**
* JobOperatorはバッチジョブ操作のインターフェースを提供します。
* JobOperatorを通して、プログラムはjobの開始・終了・リスタートが可能です。
* 加えて、job履歴の検査、以前に実行したjobと現在実行中jobの探索が可能です。
*
* JobOperatorインタフェースにはセキュリティ制約がありません。
* ただし、このインタフェースの実装者が独自のセキュリティスキーマでJobOperatorのメソッドを制限することは自由です。
* このインタフェースの実装者はJobSecurityExceptionを使用してセキュリティスキーマに基づいて制限される任意のメソッドを終了させるべきです。
*/
public interface JobOperator {
/**
* バッチランタイムが把握するすべてのjob名のsetを返します。
*
* @return job名のset
* @throws JobSecurityException
*/
public Set<String> getJobNames() throws JobSecurityException;
/**
* 指定された名前でジョブインスタンスの個数を返します。
*
* @param jobName job名
* @return 指定されたジョブ名のインスタンスの個数
* @throws NoSuchJobException
* @throws JobSecurityException
*/
public int getJobInstanceCount(String jobName) throws
NoSuchJobException,
JobSecurityException;
/**
* 指定された名前でjobに属するすべてのジョブインスタンスを新しい順で返します。
*
* @param jobName job名
* @param start ジョブインスタンス全件リストから取得するための相対開始位置（ゼロ開始）を指定
* @param count ジョブインスタンス全件リストの開始位置から取得するジョブインスタンス数を指定
* @return JobInstanceのリスト
* @throws NoSuchJobException
* @throws JobSecurityException
*/
public List<JobInstance> getJobInstances(String jobName, int start,
int count)throws NoSuchJobException, JobSecurityException;
/**
* 指定された名前で実行中のジョブインスタンスの実行idを返します。
* @param jobName job名の指定
* @return 実行idのリスト
* @throws NoSuchJobException
* @throws JobSecurityException
*/
public List<Long> getRunningExecutions(String jobName) throws
NoSuchJobException, JobSecurityException;
/**
* 指定されたジョブインスタンスのジョブパラメータを返します。
* インスタンスが最初にstartメソッドで作成されたときに指定されたkey/valueペアです。
*
* @param executionId パラメータを取得対象の実行ID
* @return key/valueジョブパラメータのPropertiesオブジェクト
* @throws NoSuchJobExecutionException
* @throws JobSecurityException
*/
public Properties getParameters(long executionId)
throws NoSuchJobExecutionException, JobSecurityException;
/**
* 新規ジョブインスタンスの生成と最初の実行を開始をします。
*
* 注意点として、jobを定義するJob XMLは、バッチランタイム実装が規定する方法に
* 従い、by nameで最初に検索されます。これは実装依存になるでしょう。
* もしJob XMLがこの方法で見つからなかった場合、バッチランタイムは、現在の
* クラスローダーでMETA-INF/batch-jobsディレクトリから、リソースとして指定された
* Job XMLを検索します。
* META-INF/batch-jobsディレクトリ下のJob XMLファイルはnaming conventionで
* "name".xmlに従い、"name"はjobXMLNameパラメータの値(下記参照)になります。
*
* @param jobXMLName jobが定義されているJob XMLの名前
* @param jobParameters Job XMLの属性置換(attribute substitution)のためのkeywork/valueペア
* @return job実行ID
* @throws JobStartException
* @throws JobSecurityException
*/
public long start(String jobXMLName, Properties jobParameters) throws
JobStartException, JobSecurityException;
/**
* failedかstoppedしたジョブインスタンスをリスタートします。
*
* @param executionId リスタートする実行を指定する。最新の実行でなければなりません。
* @param restartParameters Job XMLの属性置換のためのkeywork/valueペア
* @return 新しい実行ID
* @throws JobExecutionAlreadyCompleteException
* @throws NoSuchJobExecutionException
* @throws JobExecutionNotMostRecentException,
* @throws JobRestartException
* @throws JobSecurityException
*/
public long restart(long executionId, Properties restartParameters)
throws JobExecutionAlreadyCompleteException,
}
/**
* 実行中のjobを停止するリクエストをします。
* このメソッドはjob実行停止の通知したあとreturnします。job実行の正常停止は
* 非同期に行われます。
* 注意点として、JobOperatorはjob停止を保証しません。行儀の悪いバッチアプリケーション
* が制御を離さない可能性があるためです。
* <p>
* パーティーションbatchlet stepでは、アクティブでパーティーション処理中の
* 各スレッドでBatchletのstopメソッドが呼びだれます。
*
* @param executionId 停止するjobを指定。実行中のjob実行でなければならない。
* @throws NoSuchJobExecutionException
* @throws JobExecutionNotRunningException
* @throws JobSecurityException
*/
public void stop(long executionId) throws NoSuchJobExecutionException,
JobExecutionNotRunningException, JobSecurityException;
/**
* バッチステータスをABANDONEDに設定します。インスタンスは一つも実行していない
* 必要があります。
* <p>
* 注意点として、ABANDONEDな実行はリスタート不可能です。
*
* @param executionId abandonするjob実行
* @throws NoSuchJobExecutionException
* @throws JobExecutionIsRunningException
* @throws JobSecurityException
*/
public void abandon(long executionId) throws
NoSuchJobExecutionException,
JobExecutionIsRunningException, JobSecurityException;
/**
* 指定された実行IDのジョブインスタンスを返します。
*
* @param executionId job実行の指定
* @return ジョブインスタンス
* @throws NoSuchJobExecutionException
* @throws JobSecurityException
*/
public JobInstance getJobInstance(long executionId) throws
NoSuchJobExecutionException, JobSecurityException;
/**
* 指定されたジョブイスタンスに属するすべてのjob実行を返します。
*
* @param jobInstance ジョブインスタンスの指定
* @return job実行のリスト
* @throws NoSuchJobInstanceException
* @throws JobSecurityException
*/
public List<JobExecution> getJobExecutions(JobInstance instance) throws
NoSuchJobInstanceException, JobSecurityException;
/**
* 指定された実行IDのjob実行を返します。
*
* @param executionId job実行の指定
* @return job実行
* @throws NoSuchJobExecutionException
* @throws JobSecurityException
*/
public JobExecution getJobExecution(long executionId) throws
NoSuchJobExecutionException, JobSecurityException;
/**
* 指定された実行IDのStepExecutionsを返します。
*
* @param executionId job実行の指定
* @return step実行のリスト（順序保障無し）
* @throws NoSuchJobExecutionException
* @throws JobSecurityException
*/
public List<StepExecution> getStepExecutions(long jobExecutionId)
throws NoSuchJobExecutionException, JobSecurityException;
}package javax.batch.runtime;
public interface JobInstance {
/**
* このJobInstanceのユニークなIDを取得します。
* @return インスタンスID
*/
public long getInstanceId();
/**
* job名の取得。
* @return <job>の'id'属性値
*/
public String getJobName();
}package javax.batch.runtime;
import java.util.Date;
import java.util.Properties;
public interface JobExecution {
/**
* このJobExecutionのユニークなIDを取得します。
* @return 実行ID
*/
public long getExecutionId();
/**
* job名の取得。
* @return <job>の'id'属性値
*/
public String getJobName();
/**
* この実行のバッチステータスを取得します。
* @return バッチステータス値
*/
public BatchStatus getBatchStatus();
/**
* STARTEDステータスになった時間の取得。
* @return date (time)
*/
public Date getStartTime();
/**
* COMPLETED, STOPPED, FAILED終了ステータスになった時間の取得。
* @return date (time)
*/
public Date getEndTime();
/**
* 完了ステータスの取得。
* @return 完了ステータス.
*/
public String getExitStatus();
/**
* 実行が作成された時間の取得。
* @return date (time)
*/
public Date getCreateTime();
/**
* 実行が最後に更新された時間の取得。
* @return date (time)
*/
public Date getLastUpdatedTime();
/**
* この実行のジョブパラメータの取得。
* @return ジョブパラメータ
*/
public Properties getJobParameters();
}package javax.batch.runtime;
import java.util.Date;
import java.io.Serializable;
public interface StepExecution {
/**
* StepExecutionのユニークIDの取得。
* @return StepExecution id
*/
public long getStepExecutionId();
/**
* step名の取得。
* @return <step>の'id'属性
*/
public String getStepName();
/**
* step実行のバッチステータスの取得。
* @return batch status.
*/
public BatchStatus getBatchStatus();
/**
* このstepが開始された時間の取得。
* @return date (time)
*/
public Date getStartTime();
/**
* このstepが終了した時間の取得。
* @return date (time)
*/
public Date getEndTime();
/**
* stepの完了ステータスの取得。
* @return exit status
*/
public String getExitStatus();
/**
* ユーザ永続データの取得。
* @return persistent data
*/
public Serializable getUserPersistentData();
/**
* stepのメトリクスの取得。
* @return array of metrics
*/
public Metric[] getMetrics();
}この仕様はjavax.batch.operationsパッケージでバッチ例外クラスを定義します。注意点として、すべてのバッチ例外はBatchRuntimeExceptionクラスをベースとしたサブクラスで、このベースクラスはjava.lang.RuntimeExceptionのサブクラスになります。以下のバッチ例外クラスが定義されます。
- JobExecutionAlreadyCompleteException
- JobExecutionIsRunningException
- JobExecutionNotMostRecentException
- JobExecutionNotRunningException
- JobRestartException
- JobSecurityException
- JobStartException
- NoSuchJobException
- NoSuchJobExecutionException
- NoSuchJobInstanceException
以降の節ではアーティファクトメソッドの呼び出し順序について説明します。以下のような単純なシンボルを使用して呼び出し順序について示します。
| シンボル | 意味 |
|---|---|
<action> |
バッチランタイムによって実行されるアクション |
<->method |
バッチランタイムによるバッチアーティファクトメソッドの呼び出し |
[method] |
オプションのメソッド |
// comment |
振る舞いに対するコメント |
LABEL: |
flow制御コメントに使用されるラベル |
すべてのバッチアーティファクトは、Job XMLで定義されるスコープで使用される前に、インスタンス化されます。そして、アーティファクトが含まれているスコープ内が生存期間となります。アーティファクトのライフサイクルに関するスコープは三つあり、job, step, step-partitionとなります。
Job XMLの参照ごとに一つのアーテイファクトがインスタンス化されます。パーティーションstepの場合、パーティーションごとのJob XML参照ごとに一つのアーティファクト(*1)がインスタンス化されます。この意味するところは、ジョブレベルアーティファクトはjobが生存期間、ということです。ステップレベルアーティファクトはstepが生存期間になります。パーティーションのステップレベルアーティファクトはパーティーションが生存期間になります。
アーティファクトインスタンスはコンカレントなスコープを横断して共有されることはありません。同一インスタンスは特定のJob XML参照が示す適切なスコープで使用されなければなりません。
*1 one artifact per Job XML reference per partition is instantiated.
すべてのジョブリポジトリアーティファクトはjob処理中にバッチランタイムによって生成され、実装が提供する手段によって削除されるまでは存在します。
※訳注：こっから先しばらくは擬似コードによる各アーティファクトの説明なので、基本的には仕様から該当部分をそのまんまコピペしています。
1. <Create JobContext>
2. <Store job level properties in JobContext>
3. <->[JobListener.beforeJob...] // thread A
4. <processs execution elements>
5. <->[JobListener.afterJob...] // thread A
6. <Destroy JobContext>
1. <Create StepContext>
2. <Store step level properties in StepContext>
3. <->[StepListener.beforeStep...] // thread A
4. <->Batchlet.process // thread A
5. // if stop issued:
6. <->[Batchlet.stop] // thread B, StepContext is available
7. <->[StepListener.afterStep...] // thread A
8. <Store StepContext persistent area>
9. <Destroy StepContext>
1. <Create StepContext>
2. <Store step level properties in StepContext>
3. <->[StepListener.beforeStep...] // thread A
4. <->[PartitionReducer.beginPartitionedStep] // thread A
5. <->[PartitionMapper.mapPartitions] // thread A
6. // per partition:
a. <->Batchlet.process // thread Px
b. // if stop issued:
c. <->[Batchlet.stop] // thread Py, StepContext is available
d. <->[PartitionCollector.collectPartitionData] // thread Px
7. // when collector payload arrives:
8. <->[PartitionAnalyzer.analyzeCollectorData] // thread A
9. // when partition ends:
10. <->[PartitionAnalyzer.analyzeStatus] // thread A
11. // if rollback condition occurs:
12. <->[PartitionReducer.rollbackPartitionedStep] // thread A
13. <->[PartitionReducer.beforePartitionedStepCompletion] // thread A
14. <->[PartitionReducer.afterPartitionedStepCompletion] // thread A
15. <->[StepListener.afterStep...] // thread A
16. <Store StepContext persistent area>
17. <Destroy StepContext>
1. <Create StepContext>
2. <Store step level properties in StepContext>
3. <->[StepListener.beforeStep...] // thread A
4. [<begin transaction> ]
5. <->ItemReader.open // thread A
6. <->ItemWriter.open // thread A
7. [<commit transaction> ]
8. // chunk processing:
9. <repeat until no more items> {
a. <begin checkpoint [<begin transaction> ]>
b. <repeat until commit criteria reached> {
i. <->ItemReader.readItem // thread A
ii. <->ItemProcessor.processItem // thread A
iii. <add item to buffer>
c. }
d. <->ItemWriter.writeItems // thread A
e. <->[ItemReader.checkpointInfo] // thread A
f. <->[ItemWriter.checkpointInfo] // thread A
g. <Store StepContext persistent area>
h.
i. <commit checkpoint (commit transaction)>
10. }
11. [<begin transaction> ]
12. <->ItemWriter.close // thread A
13. <->ItemReader.close // thread A
14. [<commit transaction> ]
15. <->[StepListener.afterStep...] // thread A
16. <Store StepContext persistent area>
17. <Destroy StepContext>
##11.7 Partitioned Chunk Processing
1. <Create StepContext>
2. <Store step level properties in StepContext>
3. <->[StepListener.beforeStep...] // thread A
4. <->[PartitionReducer.beginPartitionedStep] // thread A
5. <->[PartitionMapper.mapPartitions] // thread A // per partition - on thread Px:
a. [<begin transaction> ]
b. <->ItemReader.open // thread Px
c. <->ItemWriter.open // thread Px
d. [<commit transaction> ]
a. <repeat until no more items> {
i. <begin checkpoint [<begin transaction> ]>
ii. <repeat until commit criteria reached> {
1. <->ItemReader.readItem // thread Px
2. <->ItemProcessor.processItem // thread Px
3. <add item to buffer>
iii. }
iv. <->ItemWriter.writeItems // thread Px
v. <->[ItemReader.checkpointInfo] // thread Px
vi. <->[ItemWriter.checkpointInfo] // thread Px
vii. <Store (partition-local) StepContext persistent area>
viii. <commit checkpoint (commit transaction)>
ix. <->[PartitionCollector.collectPartitionData] // thread Px
e. }
f. [<begin transaction> ]
g. <->ItemWriter.close // thread Px
h. <->ItemReader.close // thread Px
i. [<commit transaction> ]
j. <->[PartitionCollector.collectPartitionData] // thread Px
6. [<begin transaction> ] // thread A
7. // Actions 9-12 run continuously until all partitions end.
8. // when collector payload arrives:
9. <->[PartitionAnalyzer.analyzeCollectorData] // thread A
10. // when partition ends:
11. <->[PartitionAnalyzer.analyzeStatus] // thread A
12. // Remaining actions run after all partitions end:
13. // if rollback condition occurs:
14. <->[PartitionReducer.rollbackPartitionedStep] // thread A
15. [<rollback transaction >]
16. // else not rollback
17. <->[PartitionReducer.beforePartitionedStepCompletion] // thread A
18. [<commit transaction> ] // thread A
19. <->[PartitionReducer.afterPartitionedStepCompletion] // thread A
20. <->[StepListener.afterStep...] // thread A
21. <Store StepContext persistent area>
22. <Destroy StepContext>
1. <Create StepContext>
2. <Store step level properties in StepContext>
3. <->[StepListener.beforeStep...] // thread A
4. [<begin transaction> ]
5. <->ItemReader.open // thread A
6. <->ItemWriter.open // thread A
7. [<commit transaction> ]
8. // chunk processing:
9. <repeat until no more items> {
a. <begin checkpoint [<begin transaction> ]>
b. <->[ChunkListener.beforeChunk] // thread A
c. <repeat until commit criteria reached> {
i. <->[ItemReadListener.beforeRead] // thread A
ii. <->ItemReader.readItem // thread A
i. <->[ItemReadListener.afterRead] // thread A
ii. // or:
iii. {
iv. <->[ItemReadListener.onReadError] // thread A
v. <->[SkipListener.onSkipReadItem] // thread A
vi. }
vii. <->[ItemProcessListener.beforeProcess] // thread A
viii. <->ItemProcessor.processItem // thread A
ix. <->[ItemProcessListener.afterProcess] // thread A
x. // or:
xi. {
xii. <->[ItemProcessListener.onProcessError] // thread A
xiii. <->[SkipListener.onSkipProcessItem] // thread A
xiv. }
xv. <add item to buffer>
d. }
e. <->[ItemWriteListener.beforeWrite] // thread A
f. <->ItemWriter.writeItems // thread A
g. <->[ItemWriteListener.afterWrite] // thread A
h. // or:
i. {
j. <->[ItemWriteListener.onWriteError] // thread A
k. <->[SkipListener.onSkipWriteItems] // thread A
l. }
m. <->[ChunkListener.afterChunk] // thread A
n. <->[ItemReader.checkpointInfo] // thread A
o. <->[ItemWriter.checkpointInfo] // thread A
p. <Store StepContext persistent area>
q. <commit checkpoint (commit transaction)>
10. }
11. [<begin transaction> ]
12. <->ItemWriter.close // thread A
13. <->ItemReader.close // thread A
14. [<commit transaction> ]
15. <->[StepListener.afterStep...] // thread A
16. <Store StepContext persistent area>
17. <Destroy StepContext>
注意：ロールバック処理の詳細についてもこの節で記述されます。
1. <Create StepContext>
2. <Store step level properties in StepContext>
3. <->[StepListener.beforeStep...] // thread A
4. [<begin transaction> ]
5. <->ItemReader.open // thread A
6. <->ItemWriter.open // thread A
7. [<commit transaction> ]
8. // chunk processing:
9. <repeat until no more items> {
a. S1:
b. <begin checkpoint [<begin transaction> ]>
c. <repeat until commit-interval reached> {
i. S2:
ii. <->ItemReader.readItem // thread A
iii. // if exception
iv. <->[ItemReadListener.onReadErrror] // thread A
v. <->[RetryReadListener.onRetryReadException] // thread A
vi. // if retryable exception
vii. // if no-rollback exception
viii. resume S2:
ix. // else
x. <end repeat>
xi. // else
xii. <end repeat>
xiii. S3:
xiv. <->ItemProcessor.processItem // thread A
xv. // if exception
xvi. <->[ItemProcessListener.onProcessErrror] // thread A
xvii. <->[RetryProcessListener.onRetryProcessException] // thread A
xviii. // if retryable exception
xix. // if no-rollback exception
xx. resume S3:
xxi. // else
xxii. <end repeat>
xxiii. // else
xxiv. <end repeat>
xxv. <add item to buffer>
d. }
e. // if rollback exception, execute rollback procedure (below) and resume at S1 with item-count=1
f. S4:
g. <->ItemWriter.writeItems (buffer) // thread A
h. // if exception
i. <->[ItemWriteListener.onWriteErrror] // thread A
j. <->[RetryWriteListener.onRetryWriteException] // thread A
k. // if retryable exception
l. // if no-rollback exception
m. resume S4:
n. // else
o. execute rollback procedure (below) and resume S1:
p. // else execute rollback procedure (below) and resume S1:
q. <->[ItemReader.checkpointInfo] // thread A
r. <->[ItemWriter.checkpointInfo] // thread A
s. <Store StepContext persistent area> // thread A
t. S5:
u. <commit checkpoint (commit transaction)> // thread A
v. // if exception
w. // if retryable exception
x. // if no-rollback exception:
y. resume S5:
z. // else
aa. execute rollback procedure (below) and resume S1:
bb. // else execute rollback procedure (below) and resume S1:
10. }
11. [<begin transaction> ]
12. <->ItemWriter.close // thread A
13. <->ItemReader.close // thread A
14. [<commit transaction> ]
15. <->[StepListener.afterStep...] // thread A
16. <Store StepContext persistent area>
17. <Destroy StepContext>
Rollback Procedure
1. <->ItemWriter.close // thread A
2. <->ItemReader.close // thread A
3. [ChunkListener.onError] // thread A
4. [rollback transaction]
5. [<begin transaction> ]
6. <->ItemWriter.open // thread A, pass last committed checkpoint info
7. <->ItemReader.open // thread A, pass last committed checkpoint info
8. [<commit transaction> ]
1. <Create StepContext>
2. <Store step level properties in StepContext>
3. <->[StepListener.beforeStep...] // thread A
4. [<begin transaction> ]
5. <->ItemReader.open // thread A
6. <->ItemWriter.open // thread A
7. [<commit transaction> ]
8. // chunk processing:
9. <repeat until no more items> {
a. [
b. <->[CheckpointAlgorithm.checkpointTimeout]
c. <begin checkpoint [<begin transaction> ]>
b. ]
c. <repeat until commit criteria reached> {
i. <->ItemReader.readItem // thread A
ii. <->ItemProcessor.processItem // thread A
iii. <add item to buffer>
iv. <->CheckpointAlgorithm.isReadyToCheckpoint // thread A
d. }
e. <->ItemWriter.writeItems // thread A
f. <->[ItemReader.checkpointInfo] // thread A
g. <->[ItemWriter.checkpointInfo] // thread A
h. <Store StepContext persistent area>
d. <->[CheckpointAlgorithm.beginCheckpoint] // thread A
e. <commit checkpoint (commit transaction)>
i. <->[CheckpointAlgorithm.endCheckpoint] // thread A
10. }
11. [<begin transaction> ]
12. <->ItemWriter.close // thread A
13. <->ItemReader.close // thread A
14. [<commit transaction> ]
15. <->[StepListener.afterStep...] // thread A
16. <Store StepContext persistent area>
17. <Destroy StepContext>
1. // For each flow:
2. <run flow> // thread Fx
1. // For each split or step:
2. <run split or step> // thread Xy
JobOperator.stopは実行中のjobを停止します。もしstopが呼び出されたときにstepが実行中の場合、バッチランタイムは以下のアクションを起こします。
Chunk Step
jobとstepのバッチステータスはSTOPPINGになります。注意点として、バッチランタイムはstepが終了することを保証しません。バッチランタイムはread/process/write chunk処理ループをインタラプトしようと試み、stepに現在のアイテム処理を停止することを許可します。この意味するところは、読み込まれてprocessor設定があればそこで処理された現在のアイテム、現在までにバッファーされたアイテム、がもしあれば、現在のアイテムを含めて書き込みが行われます。もしchunkタイプのstepに設定されたバッチアーティファクトがバッチランタイムにreturnする場合は、期待通りに、jobとstepのバッチステータスはSTOPPEDになります。
Batchlet Step
jobとstepのバッチステータスはSTOPPINGになります。バッチランタイムはbatchletのstopメソッドを呼び出します。注意点として、バッチランタイムはbatchletが実際に終了することを保証しません。ただし、行儀のよいbatchletはその限りではありません。もしbatchletがバッチランタイムにreturnする場合、jobとstepのバッチステータスはSTOPPEDになります。
パーティーションbatchlet stepにおいては、batchletのstopメソッドがアクティブでパーティーション処理をしている個々のスレッド上で呼び出されます。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
targetNamespace="http://xmlns.jcp.org/xml/ns/javaee"
mlns:jbatch="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
<xs:element name="batch-artifacts" type="jbatch:BatchArtifacts" />
<xs:complexType name="BatchArtifacts">
<xs:sequence>
<xs:element name="ref" type="jbatch:BatchArtifactRef" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="BatchArtifactRef">
<xs:attribute name="id" use="required" type="xs:string" />
<xs:attribute name="class" use="required" type="xs:string" />
</xs:complexType>
</xs:schema>
XMLスキーマで定義されたジョブ定義言語（Job Specification Language:JSL）のディレクティブにより記述されたjobは、おおむねJob XMLとも呼称されます。
バッチランタイムは、startメソッドが呼び出し元に処理を返す前に、JobOperatorのstart処理中にスキーマ・バリデーションを実行しなければなりません。スキーマ・バリデーションのエラーはJobStartExceptionになります。ランタイム実装はJSLの意味解析処理において二つの選択肢があります。
- 呼び出し元に処理を返す前に、JobOperatorのstart処理中に意味解析を実行する。もし意味解析エラーが発生する場合、実装はJobStartExceptionをスローしなければならない。
- job開始後に意味解析を実行する。もし意味解析エラーが発生する場合、実装はjobをFAILEDステータスで終了しなければならない。実装は問題解決のために十分なエラー情報をログ出力することが推奨される。
バッチランタイムが検出および処理すべき一般的な意味解析は以下に挙げますが、実査にはこの限りではありません。
- 実行可能な要素が無い。
- 遷移不能（例.next="value"の"value"が存在しない）。
- 遷移先が循環している（例.step1:next=step2; step2:next=step1）。
<?xml version='1.0' encoding='utf-8'?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementformdefault="qualified" targetnamespace="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:jsl="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
<xs:annotation>
<xs:documentation>
Job Specification Language (JSL) specifies a job, its steps, and directs their
execution. JSL also can be referred to as "Job XML".
</xs:documentation>
</xs:annotation>
<xs:simpletype name="artifactRef">
<xs:annotation>
<xs:documentation>
This is a helper type. Though it is not otherwise called out by this name
in the specification, it captures the fact that the xs:string value refers
to a batch artifact, across numerous other JSL type definitions.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpletype>
<xs:complextype name="Job">
<xs:annotation>
<xs:documentation>
The type of a job definition, whether concrete or abstract.
This is the type of the root element of any JSL document.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
<xs:annotation>
<xs:documentation>
The job-level properties, which are accessible via the
JobContext.getProperties() API in a batch artifact.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="listeners" type="jsl:Listeners" minoccurs="0" maxoccurs="1">
<xs:annotation>
<xs:documentation>
Note that "listeners" sequence order in XML does not imply order of
execution by the batch runtime, per the specification.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:choice minoccurs="0" maxoccurs="unbounded">
<xs:element name="decision" type="jsl:Decision">
</xs:element>
<xs:element name="flow" type="jsl:Flow">
</xs:element>
<xs:element name="split" type="jsl:Split">
</xs:element>
<xs:element name="step" type="jsl:Step">
</xs:element>
</xs:choice>
</xs:sequence>
<xs:attribute name="version" use="required" type="xs:string" fixed="1.0">
</xs:attribute>
<xs:attribute name="id" use="required" type="xs:ID">
</xs:attribute>
<xs:attribute name="restartable" use="optional" type="xs:string">
</xs:attribute>
</xs:complextype>
<xs:element name="job" type="jsl:Job">
<xs:annotation>
<xs:documentation>
The definition of an job, whether concrete or abstract.
This is the type of the root element of any JSL document.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complextype name="Listener">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
<xs:complextype name="Split">
<xs:sequence>
<xs:element name="flow" type="jsl:Flow" minoccurs="0" maxoccurs="unbounded">
</xs:element>
</xs:sequence>
<xs:attribute name="id" use="required" type="xs:ID">
</xs:attribute>
<xs:attribute name="next" use="optional" type="xs:string">
</xs:attribute>
</xs:complextype>
<xs:complextype name="Flow">
<xs:sequence>
<xs:choice minoccurs="0" maxoccurs="unbounded">
<xs:element name="decision" type="jsl:Decision">
</xs:element>
<xs:element name="flow" type="jsl:Flow">
</xs:element>
<xs:element name="split" type="jsl:Split">
</xs:element>
<xs:element name="step" type="jsl:Step">
</xs:element>
</xs:choice>
<xs:group ref="jsl:TransitionElements" minoccurs="0" maxoccurs="unbounded">
</xs:group>
</xs:sequence>
<xs:attribute name="id" use="required" type="xs:ID">
</xs:attribute>
<xs:attribute name="next" use="optional" type="xs:string">
</xs:attribute>
</xs:complextype>
<xs:group name="TransitionElements">
<xs:annotation>
<xs:documentation>
This grouping provides allows for the reuse of the
'end', 'fail', 'next', 'stop' element sequences which may appear at the end of a
'step', 'flow', 'split' or 'decision'. The term 'TransitionElements' does not
formally appear in the spec, it is a schema convenience.
</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="end" type="jsl:End">
</xs:element>
<xs:element name="fail" type="jsl:Fail">
</xs:element>
<xs:element name="next" type="jsl:Next">
</xs:element>
<xs:element name="stop" type="jsl:Stop">
</xs:element>
</xs:choice>
</xs:group>
<xs:complextype name="Decision">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
<xs:group ref="jsl:TransitionElements" minoccurs="0" maxoccurs="unbounded">
</xs:group>
</xs:element>
</xs:sequence>
<xs:attribute name="id" use="required" type="xs:ID">
</xs:attribute>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
<xs:attributegroup name="TerminatingAttributes">
<xs:attribute name="on" use="required" type="xs:string">
</xs:attribute>
<xs:attribute name="exit-status" use="optional" type="xs:string">
</xs:attribute>
</xs:attributegroup>
<xs:complextype name="Fail">
<xs:attributegroup ref="jsl:TerminatingAttributes">
</xs:attributegroup>
</xs:complextype>
<xs:complextype name="End">
<xs:attributegroup ref="jsl:TerminatingAttributes">
</xs:attributegroup>
</xs:complextype>
<xs:complextype name="Stop">
<xs:attributegroup ref="jsl:TerminatingAttributes">
<xs:attribute name="restart" use="optional" type="xs:string">
</xs:attribute>
</xs:attributegroup>
</xs:complextype>
<xs:complextype name="Next">
<xs:attribute name="on" use="required" type="xs:string">
</xs:attribute>
<xs:attribute name="to" use="required" type="xs:string">
</xs:attribute>
</xs:complextype>
<xs:complextype name="CheckpointAlgorithm">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
<xs:complextype name="ExceptionClassFilter">
<xs:sequence>
<xs:element name="include" minoccurs="0" maxoccurs="unbounded">
</xs:element>
</xs:sequence>
</xs:complextype>
<xs:complextype>
<xs:sequence>
<xs:attribute name="class" use="required" type="xs:string">
</xs:attribute>
</xs:sequence>
</xs:complextype>
<xs:element name="exclude" minoccurs="0" maxoccurs="unbounded">
<xs:complextype>
<xs:sequence>
<xs:attribute name="class" use="required" type="xs:string">
</xs:attribute>
</xs:sequence>
</xs:complextype>
</xs:element>
<xs:complextype name="Step">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
<xs:element name="listeners" type="jsl:Listeners" minoccurs="0" maxoccurs="1">
<xs:annotation>
<xs:documentation>
Note that "listeners" sequence order in XML does not imply order of
execution by the batch runtime, per the specification.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:choice minoccurs="0" maxoccurs="1">
<xs:element name="batchlet" type="jsl:Batchlet">
</xs:element>
<xs:element name="chunk" type="jsl:Chunk">
</xs:element>
</xs:choice>
<xs:element name="partition" type="jsl:Partition" minoccurs="0" maxoccurs="1">
<xs:group ref="jsl:TransitionElements" minoccurs="0" maxoccurs="unbounded">
</xs:group>
</xs:element>
</xs:sequence>
<xs:attribute name="id" use="required" type="xs:ID">
</xs:attribute>
<xs:attribute name="start-limit" use="optional" type="xs:string">
</xs:attribute>
<xs:attribute name="allow-start-if-complete" use="optional" type="xs:string">
</xs:attribute>
<xs:attribute name="next" use="optional" type="xs:string">
</xs:attribute>
</xs:complextype>
<xs:complextype name="Batchlet">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
<xs:complextype name="Chunk">
<xs:sequence>
<xs:element name="reader" type="jsl:ItemReader">
</xs:element>
<xs:element name="processor" type="jsl:ItemProcessor" minoccurs="0" maxoccurs="1">
</xs:element>
<xs:element name="writer" type="jsl:ItemWriter">
</xs:element>
<xs:element name="checkpoint-algorithm" type="jsl:CheckpointAlgorithm" minoccurs="0" maxoccurs="1">
</xs:element>
<xs:element name="skippable-exception-classes" type="jsl:ExceptionClassFilter" minoccurs="0" maxoccurs="1">
</xs:element>
<xs:element name="retryable-exception-classes" type="jsl:ExceptionClassFilter" minoccurs="0" maxoccurs="1">
</xs:element>
<xs:element name="no-rollback-exception-classes" type="jsl:ExceptionClassFilter" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="checkpoint-policy" use="optional" type="xs:string">
<xs:annotation>
<xs:documentation>
Specifies the checkpoint policy that governs commit behavior for this chunk.
Valid values are: "item" or "custom". The "item" policy means the chunk is
checkpointed after a specified number of items are processed.
The "custom" policy means the chunk is checkpointed according to a checkpoint
algorithm implementation. Specifying "custom" requires that the
checkpoint-algorithm element is also specified. It is an optional attribute.
The default policy is "item".
However, we chose not to define a schema-specified default for this attribute.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="item-count" use="optional" type="xs:string">
<xs:annotation>
<xs:documentation>
Specifies the number of items to process per chunk when using the item
checkpoint policy. It must be valid XML integer.
It is an optional attribute. The default is 10. The item-count attribute is
ignored for "custom" checkpoint policy. However, to make it easier for
implementations to support JSL inheritance we abstain from defining a
schema-specified default for this attribute.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="time-limit" use="optional" type="xs:string">
<xs:annotation>
<xs:documentation>
Specifies the amount of time in seconds before taking a checkpoint for
the item checkpoint policy. It must be valid XML integer.
It is an optional attribute. The default is 0, which means no limit.
However, to make it easier for implementations to support JSL inheritance
we abstain from defining a schema-specified default for this attribute.
When a value greater than zero is specified, a checkpoint is taken
when time-limit is reached or item-count items have been processed,
whichever comes first. The time-limit attribute is ignored for
"custom" checkpoint policy.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="skip-limit" use="optional" type="xs:string">
<xs:annotation>
<xs:documentation>
Specifies the number of exceptions a step will skip if any configured
skippable exceptions are thrown by chunk processing. It must be a valid
XML integer value. It is an optional attribute. The default is no limit.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="retry-limit" use="optional" type="xs:string">
<xs:annotation>
<xs:documentation>
Specifies the number of times a step will retry if any configured
retryable exceptions are thrown by chunk processing.
It must be a valid XML integer value. It is an optional attribute.
The default is no limit.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complextype>
<xs:complextype name="ItemReader">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
<xs:complextype name="ItemProcessor">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
<xs:complextype name="ItemWriter">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
<xs:complextype name="Property">
<xs:attribute name="name" type="xs:string" use="required">
</xs:attribute>
<xs:attribute name="value" type="xs:string" use="required">
</xs:attribute>
</xs:complextype>
<xs:complextype name="Properties">
<xs:sequence>
<xs:element name="property" type="jsl:Property" maxoccurs="unbounded" minoccurs="0">
</xs:element>
</xs:sequence>
<xs:attribute name="partition" use="optional" type="xs:string">
</xs:attribute>
</xs:complextype>
<xs:complextype name="Listeners">
<xs:sequence>
<xs:element name="listener" type="jsl:Listener" maxoccurs="unbounded" minoccurs="0">
</xs:element>
</xs:sequence>
</xs:complextype>
<xs:complextype name="Partition">
<xs:sequence>
<xs:choice minoccurs="0" maxoccurs="1">
<xs:element name="mapper" type="jsl:PartitionMapper">
</xs:element>
<xs:element name="plan" type="jsl:PartitionPlan">
</xs:element>
</xs:choice>
<xs:element name="collector" type="jsl:Collector" minoccurs="0" maxoccurs="1">
</xs:element>
<xs:element name="analyzer" type="jsl:Analyzer" minoccurs="0" maxoccurs="1">
</xs:element>
<xs:element name="reducer" type="jsl:PartitionReducer" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
</xs:complextype>
<xs:complextype name="PartitionPlan">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="unbounded">
</xs:element>
</xs:sequence>
<xs:attribute name="partitions" use="optional" type="xs:string">
</xs:attribute>
<xs:attribute name="threads" use="optional" type="xs:string">
</xs:attribute>
</xs:complextype>
<xs:complextype name="PartitionMapper">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
<xs:complextype name="Collector">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
<xs:complextype name="Analyzer">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
<xs:complextype name="PartitionReducer">
<xs:sequence>
<xs:element name="properties" type="jsl:Properties" minoccurs="0" maxoccurs="1">
</xs:element>
</xs:sequence>
<xs:attribute name="ref" use="required" type="jsl:artifactRef">
</xs:attribute>
</xs:complextype>
</xs:schema>
7章のDomain Language of BatchはSpring Batch Reference Documentationが出典です。
http://static.springsource.org/spring-batch/trunk/reference/html-single/index.html