-
Notifications
You must be signed in to change notification settings - Fork 0
8 Job Specification Language
ジョブ定義言語（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"