バックグラウンド・プロセスに指定するパラメータ

この項では、バックグラウンド・プロセスに提供される様々なタイプのパラメータについて説明します。

一般的なパラメータ

次の情報は、すべてのバックグラウンド・プロセスに渡されます。

  • バッチ・コード。バッチ・コードは、バックグラウンド・プロセスの一意の識別子です。

  • バッチ・スレッド番号。スレッド番号は、複数のパラレル・スレッドで実行できるバックグラウンド・プロセスでのみ使用されます。ここには、プロセスの相対的なスレッド番号が含まれます。たとえば、請求プロセスが20のパラレル・スレッドで実行するように設定されている場合は、20の各インスタンスが相対的なスレッド番号(1から20)を受け取ります。詳細は、「パラレルのバックグラウンド・プロセスに最適なスレッド数」を参照してください。

  • バッチ・スレッド数。スレッド数は、複数のパラレル・スレッドで実行できるバックグラウンド・プロセスでのみ使用されます。ここには、スケジュールされているパラレル・スレッドの合計数が含まれます。たとえば、請求プロセスが20のパラレル・スレッドで実行されるように設定されている場合は、20の各インスタンスがスレッド数20を受け取ります。詳細は、「パラレルのバックグラウンド・プロセスに最適なスレッド数」を参照してください。

  • バッチ再実行番号。再実行番号は、特定の実行番号に属する情報をダウンロードするバックグラウンド・プロセスでのみ使用されます。これを指定する必要があるのは、過去の実行(最新の実行ではなく)をダウンロードする必要がある場合のみです。

  • バッチ営業日。営業日は、それぞれの処理で現在の日付を使用するバックグラウンド・プロセスでのみ使用されます。たとえば、請求プロセスでは、ダウンロードする必要のある請求サイクルを決定するために営業日を使用できます。このパラメータを空白のままにすると、システム日付が使用されます。日付を指定する場合は、YYYY-MM-DD書式を使用する必要があります。注意: このパラメータは、一定期間におけるプロセスの動作をテストするQA時にのみ使用されます。

  • コミット間の最大レコード数の上書き。このパラメータはオプションで、各バックグラウンド・プロセスの標準コミットを上書きします。たとえば、日中にジョブを発行しているときに、コミットの頻度を上げることで保留リソースを解放する必要がある場合は、この値を小さくします。バックグラウンド・プロセスを夜(または週末)に実行し、サーバーに大量のメモリーがある場合は、この値を大きくできます。

  • カーソル再開までの最大分数の上書き。このパラメータはオプションで、各バックグラウンド・プロセスの標準カーソル再開の分数を上書きします。たとえば、日中にジョブを発行しているときに、コミットの頻度(またはカーソル開始の頻度)を上げることで保留リソースを解放する必要がある場合は、これらの値を小さくします。バックグラウンド・プロセスを夜(週末)に実行し、サーバーに大量のメモリーがある場合は、これらの値を大きくできます。

  • ユーザーID。ユーザーIDについては、次の点に注意してください。

    • ジョブを発行するユーザーとバッチ発行に記録されたユーザーIDの両方に、実行を確保するバッチ管理用のアプリケーション・サービスに対するアクセス権が必要です。

    • 作成または更新するレコードにユーザーIDをスタンプするすべてのバッチ・プロセスは、該当する処理でこのユーザーIDを使用します。

    • このユーザーIDの表示プロファイルによって、メッセージでの日付と通貨の値の書式が制御されます。

  • パスワード。パスワードは現在使用されていません。

  • 言語コード。言語コードは、言語固有の管理表値にアクセスするために使用します。たとえば、エラー・メッセージはこの言語コードで表示されます。

  • 「プログラム開始トレース」「プログラム終了トレース」「SQLトレース」および「出力トレース」。これらのスイッチは、QAおよびベンチマーク時にのみ使用します。「プログラム開始トレース」を選択すると、プログラムが開始されるたびにメッセージが表示されます。「プログラム終了トレース」を選択すると、プログラムが終了するたびにメッセージが表示されます。「SQLトレース」を選択すると、SQL文が実行されるたびにメッセージが表示されます。「出力トレース」を選択すると、バックグラウンド・プロセスで書式設定された特別なメッセージが書き込まれます。

注意: 出力トレース・スイッチがオンのときに表示される情報は、各バックグラウンド・プロセスに依存します。このスイッチに関する特別な情報は、バックグラウンド・プロセスで表示されない可能性があります。

共通の追加パラメータ

各バッチ管理では、追加のパラメータの定義をサポートしています。すべてのバッチ・プロセスに共通する、または特定のタイプのバッチ・プロセスに共通する追加のパラメータがいくつかあります。バッチ管理には、適切な追加のパラメータを提供する必要があります。ただし、新しい追加のパラメータが導入された場合に、既存のバッチ管理が新しい追加のパラメータで更新されないことがあります。

次の表に、バッチ管理にリンクできる共通のパラメータを示します。バッチ・パラメータでは、表示されるパラメータの順序を制御するシーケンス番号がありますが、バッチ・プロセスでは、シーケンスを使用して特定のパラメータを識別するのではなくパラメータ名が使用されます。場合によっては、複数のパラメータ名がサポートされています(先頭文字が大文字のバージョンとすべて大文字のバージョン)。

パラメータ名 摘要 補足コメント
MAX-ERRORS / maxErrors 各バッチ・プロセスには、事前設定された定数が実行パラメータの一部としてあり、この定数によって、バッチ・プロセスの実行の中止が必要となる前に許容されるエラーの件数が決定されます。ユーザーは、このパラメータを使用して定数を上書きできます。 入力値には、ゼロ以上の整数を指定する必要があります。このパラメータの最大有効値は、999,999,999,999,999です。
DIST-THD-POOL 各バッチ・プロセスがスレッド・プールで実行されます。このパラメータは、バッチ・プロセスがデフォルトのスレッド・プールとは異なるスレッド・プールで実行される場合にのみ必要です。 デフォルトのスレッド・プール名はDEFAULTです。
emailMode 関連するEメール・アドレスとともにバッチ・ジョブが発行された場合、デフォルトのロジックでは、成功または失敗に関係なくジョブが完了したときにEメールが送信されます。このパラメータを使用して、ジョブが終了したときのステータスに基づいてEメールを制限します。 有効値
  • ERROR — ジョブがエラー・ステータスで終了した場合にのみEメールを送信します。

  • SUCCESS — ジョブが正常に終了した場合にのみEメールを送信します。

  • ALL — ジョブが終了した場合にのみ常にEメールを送信します。(これがデフォルトです。)

次の各パラメータは、「パラレルのバックグラウンド・プロセス」で説明しているように、作業をスレッドに配分するスレッド・レベルのSQL Selectの方法を使用するジョブにのみ適用されます。
overrideLowIdValue スレッドの範囲の計算に使用する新しい下限IDを指定します。デフォルトでは、IDは0の連続(例: 000000000)から9の連続(例: 9999999999)の間とみなされますが、このパラメータは下限値を上書きします。 パラメータ値は実際の数値にするか、autoに設定できます。autoが構成されている場合は、バックグラウンド・プロセスに関連付けられているデータベース表の現在の最小値に設定されます。
overrideHighIdValue スレッドの範囲の計算に使用する新しい上限IDを指定します。デフォルトでは、IDは0の連続(例: 000000000)から9の連続(例: 9999999999)の間とみなされますが、このパラメータは上限値を上書きします。 パラメータ値は実際の数値にするか、autoに設定できます。autoが構成されている場合は、バックグラウンド・プロセスに関連付けられているデータベース表の現在の最大値に設定されます。
idRangeOverrideClass このパラメータを使用して、スレッドの範囲を計算するカスタム・クラスを指定します。バッチの実行時に、この上書きクラスがインスタンス化され、必要に応じてsetterメソッドがコールされてIDが初期化されます。下限および上限のgetterメソッドがコールされ、実行に使用する上限IDおよび下限IDが取得されます。 指定されたクラス名は、インタフェースcom.splwg.base.api.batch.BatchIdRangeOverrideを実装する必要があります。
次のパラメータは、バッチ・ジョブの抽出など、単一のコミットを実行するジョブにのみ適用されます。
numRecordsToFlush このパラメータは、Hibernateキャッシュをフラッシュする頻度を定義し、高いヒープ消費およびメモリー不足によるエラーを防止します。

固有のバッチ・パラメータ

一部のバックグラウンド・プロセスには、その機能に固有の追加のパラメータを定義します。プロセスが追加パラメータを受け取ると、そのパラメータはアプリケーションのバッチ管理エントリ内で定義および記述されます。