この章の内容は次のとおりです。
バッチ・ジョブは、ユーザー対話なしで実行できるタスクであり、非対話型でバルク指向の長時間実行タスクに最も適しています(これらのタスクは、リソース消費型で、順次実行またはパラレル実行が可能であり、アドホックに開始するか、スケジュールを使用して開始できます)。
Java EE 7のチュートリアルで説明するように、バッチ・フレームワークは次の内容で構成されます。
XMLに基づくジョブ仕様言語。
ビジネス・ロジックを実装するアプリケーション・クラスのバッチ・アノテーションおよびインタフェースのセット。
バッチ・ジョブの実行を管理するバッチ・コンテナ。
バッチ・コンテナと連携するためのクラスとインタフェースのサポート。
バッチ・ジョブ、バッチ処理およびバッチ処理フレームワークの詳細は、Java EE 7チュートリアルのバッチ処理に関する項を参照してください。「Java Specification Request 352: Batch Applications for the Java Platform」(http://jcp.org/en/jsr/detail?id=352
)も参照してください。仕様により、バッチ・アプリケーションのプログラミング・モデルと、バッチ・ジョブのスケジュールおよび実行のランタイムが定義されます。
サンプルを備えたWebLogic Server一式をインストールする場合、サンプル・ソース・コードは、EXAMPLES_HOME
\examples\src\examples
ディレクトリに配置されます。デフォルト・パスはORACLE_HOME
\wlserver\samples\server
です。このディレクトリから、サンプル・ドメインを設定せずに、Batch 1.0サンプルのソース・コードと手順ファイルにアクセスできます。
ORACLE_HOME
\user_projects\domains\wl_server
ディレクトリには、WebLogic Serverのサンプル・ドメインが含まれています。このドメインには、アプリケーション、アプリケーションおよびOracle WebLogic Serverの動作を定義するXML構成ファイル、および起動スクリプトと環境スクリプトが含まれます。WebLogic Serverサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。
Batch Job Operatorの使用 – javax.batch.operations.JobOperator
インタフェースを使用してバッチ・ジョブを発行する方法を示します。JobOperator
インタフェースには、ジョブの起動、停止、再起動および調査を行うための一連の操作が用意されています。このサンプルでは、リスナーを使用して、バッチ処理実行時に発生する特定イベントを通知する方法も示されます。
EXAMPLES_HOME/examples/src/examples/javaee7/batch/joboperator-api
バッチ並行処理モデルを使用した、パーティション化ジョブ・ステップの実行 – PartitionMapper
インタフェースを使用して、並行処理を適切に制御できる方法を示します。
EXAMPLES_HOME/examples/src/examples/javaee7/batch/partition
Avitek Medical Records (MedRec) – WebLogic ServerおよびJava EEの機能とベスト・プラクティスを例示する総合的な学習用サンプル・アプリケーションです。Java EE 7の場合、Medrecでは、管理者のバックグラウンドに薬品統計を集計することで、バッチ処理機能を示します。統計は、レコード、医師および薬品の観点で、開始日と終了日を含めたコストを1回のバッチでまとめて要約しますが、3つの出力が行われます。
Avitek Medical Recordsは、オプションで、WebLogic Serverと一緒にインストールできます。MedRecは、ORACLE_HOME
/user_projects/domains/medrec
から起動できます。ORACLE_HOME
は、Oracle WebLogic Serverのインストール時にOracleホームとして指定したディレクトリです。
バッチを使用する独自のアプリケーションをプログラミングする前に、これらのサンプルを実行することをお薦めします。
バッチ・アプリケーションは、WebLogic Serverにデプロイしてすぐに開始できます。実行時の構成は必要ありません。これは、大量のデータの処理や格納を行わない比較的小規模の開発環境に役立ちます。
バッチ・ランタイム構成が存在しない場合、WebLogic Serverで使用される内容は次のとおりです。
バッチ・ジョブの詳細を保持するためにJobRepositoryの更新に必要なデータ・ソースを作成するデモDerbyデータベース。
java:comp/DefaultManagedExecutorService
のデフォルトJNDI名にバインドされるエグゼキュータ・サービス(Java EE 7仕様で必要)。
デフォルトのバッチ・ランタイム構成にアクセスするには、startWeblogic.sh
スクリプトを使用してWebLogic Serverを起動する必要があります。
バッチ・ランタイムの問合せの詳細は、「バッチ・ランタイムの問合せ」を参照してください。
WebLogic Serverのバッチ・ランタイムでは、XA対応データ・ソースを使用してバッチ・ジョブと管理対象エグゼキュータ・サービスのJobRepository表にアクセスすることで、非同期バッチ・ジョブを実行します。管理対象エグゼキュータ・サービスでジョブを処理して、JobRepositoryデータ・ソースで現在と過去のジョブのステータスを格納します。
WebLogicドメインのデフォルトのバッチ・ランタイムは構成なしで使用できるため、Derbyデモ・データベースのみを必要とする開発モード環境で役立ちます。データベース・スキーマを使用するデータ駆動本番環境では、ドメインの専用JobRepositoryデータ・ソースと管理対象エグゼキュータ・サービスを構成できます。
大量のデータを処理して格納するエンタープライズ・レベルの本番環境の場合、特定のデータベースにバッチ・ジョブの詳細を格納するように専用バッチ・ランタイムを構成できます。
データベース管理者は、バッチ・ジョブの詳細を保持するために必要なJobRepository表を作成する必要があります。これらの表の作成に使用されるスキーマ名は、ドメインのバッチ・ランタイムの構成時に、BatchConfigMBean
のgetSchemaName()
メソッドで示されます。「専用バッチ・データ・ソースおよび管理対象エグゼキュータ・サービスを使用するためのバッチ・ランタイムの構成」を参照してください。
JobRepository表は、WebLogic Server 12cで使用するためにサポートされるデータベースの場合、リポジトリ作成ユーティリティ(RCU)またはSQLスクリプトを使用して作成できます。これらの表を作成するためのスキーマは、次の場所にあります。
ORACLE_HOME
/oracle_common/common/sql/wlservices/batch/
dbname
ORACLE_HOME
は、Oracle WebLogic Serverの最上位インストール・ディレクトリ、dbname
はデータベースの名前を表します。
WebLogic Server 12cのサポート対象データベースの詳細は、Oracle Technology Networkの「Oracle Fusion Middleware Supported System Configurations」ページを参照してください。
RCUを使用してJobRepository表とスキーマ所有者を作成する場合、次の事項に注意することが重要です。
JBatch_WLS
など)にデフォルトで設定されることに注意してください。この名前はバッチ・データ・ソースとバッチ・ランタイムの作成時に使用するため書き留めておいてください。これで、「JobRepositoryのJDBCデータ・ソースの作成」の説明に従い、バッチ・データ・ソースを作成できます。「コンポーネントの選択」ページで選択したスキーマ所有者をデータ・ソースのユーザー名として使用する必要があることに注意してください。
注意:
バッチ・ランタイムはスキーマ名をキャッシュします。JobRepository表を更新するために接続を取得すると、その接続に対してスキーマ名を設定します。この制限が原因で、アプリケーションとJobRepositoryの両方に同じデータ・ソースを使用できません(個別のスキーマを使用する場合)。
リポジトリ・クリーン・ユーティリティ(RCU)の詳細は、『Oracle Fusion Middlewareリポジトリ作成ユーティリティによるスキーマの作成』を参照してください。
RCUユーティリティを使用してバッチのJobRepository表を作成しない場合、SQLコマンド行ユーティリティと付属のbatch.sql
スクリプトを使用して作成できます。たとえば、Oracle DatabaseおよびOracle EBR (Edition-Based Redefinition)のJobRepository表を作成する場合、SQLで表を作成する必要があります。
batch.sql
SQLスクリプトは、JobRepository表を作成するためにすべてのサポート対象データベース(mysql、db2など)に用意されており、次の場所にあります。
ORACLE_HOME
/oracle_common/common/sql/wlservices/batch/
dbname
batch.sql
SQLスクリプトを使用して表を作成するには、次の手順を実行します。
これで、「JobRepositoryのJDBCデータ・ソースの作成」の説明に従い、バッチ・データ・ソースを作成できます。作成したjbatch
スキーマ所有者をデータ・ソースのユーザー名として使用する必要があることに注意してください。
ドメイン内の専用バッチ・ランタイムの場合、WebLogic管理者は、JobRepository表が含まれるデータベースに対してXA対応データ・ソースを構成する必要があります。Java EEコンポーネントがバッチ・ジョブを発行すると、バッチ・ランタイムは、データ・ソースのJNDI名の参照により取得されるこのXAデータ・ソースを使用してJobRepository表を更新します。
管理コンソールまたはWLSTを使用してバッチ・データ・ソースを作成する場合、「JobRepository表の作成」の説明に従い、RCUで作成したスキーマ所有者(jbatch_wls
など)またはSQLスクリプトで作成したスキーマ所有者jbatch
を使用する必要があります。
JDBCデータ・ソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの作成に関する項を参照してください。
最適なパフォーマンスを実現するために、バッチ・ランタイムsetBatchJobsManagedExecutorServiceName()
と同じ名前を使用する管理対象エグゼキュータ・サービス・テンプレート(MESテンプレート)を構成することで、アプリケーション・スコープ指定の管理対象エグゼキュータ・サービスを使用するようにバッチ・ランタイムを構成できます。バッチ・ランタイムの構成時にMESテンプレートを指定しない場合、(java:comp/DefaultManagedExecutorService
)にバインドされるデフォルトのJava EE管理対象エグゼキュータ・サービスをかわりに使用します。
管理対象エグゼキュータ・サービスの新しいインスタンスがMESテンプレートごとに作成される場合、ドメインにデプロイされるアプリケーションに対して発行されるバッチ・ジョブを実行します。たとえば、ドメインにMES1
およびMES2
という2つのMESテンプレートがある場合、BatchApp1
とBatchApp2
をデプロイすると、各アプリケーションは、MES1
とMES2
のインスタンスを取得します。
ただし、setBatchJobsExecutorServiceName("MES2")
を設定した場合、BatchApp1
またはBatchApp1
(あるいは、ドメインにデプロイされるいずれかのアプリケーション)から発行されたすべてのバッチ・ジョブではMES2
を使用します。
管理対象エグゼキュータ・サービス・テンプレートの構成の手順については、「同時管理対象オブジェクトの構成」を参照してください。
「前提条件ステップによるJobRepository表、バッチ・データ・ソースおよび管理対象エグゼキュータ・サービスの構成」で作成したJobRepositoryデータ・ソースと管理対象エグゼキュータ・サービスは、次のいずれかのWebLogic管理ツールを使用して、専用バッチ・ランタイムを構成するために使用できるようになりました。
ヒント:
「JobRepository表の作成」で使用されるスキーマ名は、次の項で構成手順を実行する際に指定する必要があります。たとえば、MBeanを使用する場合、スキーマ名は、ドメインのBatchConfigMBean
のgetSchemaName()
で示す必要があります。
専用バッチ・ランタイムは、管理コンソールを使用してドメイン・スコープに構成できます。「domain-nameの設定」ページで、「バッチ」ページを開き、次の構成フィールドに入力します。
データソースJNDI名 – バッチ・ランタイムのJobRepositoryデータ・ソースのJNDI名を選択します。これは、ドメインにデプロイされたアプリケーションから発行されるバッチ・ジョブのデータを格納するために使用されます。
スキーマ名 – 「JobRepository表の作成」で説明するように、JobRepository表がRCUまたはJBatch SQLスクリプトで作成されたときに使用されたスキーマ名を入力します。
データ・ソースがアプリケーションで共有される場合、このスキーマ名は、アプリケーションが予期するものと同じ名前である必要があります。
エグゼキュータ・サービス・テンプレート – 管理対象エグゼキュータ・サービス(MES)テンプレートを選択します。これは、ドメインにデプロイされたアプリケーションから発行されるバッチ・ジョブを実行するために使用されます。同じ名前のMESテンプレートが存在し、バッチ・ジョブの発行時にドメイン・スコープにターゲット指定される必要があります。
MESテンプレートを選択しない場合、バッチ・ランタイムは、デフォルトのJNDI名java:comp/DefaultManagedExecutorService
にバインドされるデフォルトのJava EE管理対象エグゼキュータ・サービスを使用します。
WebLogic Server管理コンソールを使用して、管理対象エグゼキュータ・サービス・テンプレートをドメイン構成で構成するには、「環境」→「同時テンプレート」ページを使用します。詳細は、「同時管理対象オブジェクトの構成」を参照してください。
WLSTでBatchRuntimeConfigMBean
とDomainMBean
を使用して、JobRepositoryに特定のデータベースを使用するようにバッチ・ランタイムを構成できます。
def update_domain_batch_config(domainName, jndiName, schemaName): connect('admin','passwd') edit() startEdit() cmo.setDataSourceJndiName(jndiName) cd('/BatchConfig/' + domainName) cmo.setSchemaName(schemaName) save() activate()
この例では、管理者がJNDI名jdbc/batchDS
でデータ・ソースを作成した場合、update_domain_batch_config('mydomain','jdbc/batchDS','BATCH')
をコールすると、jndiName
: 'jdbc/batchDS'
にバインドされたデータ・ソースで指し示されるデータベースのスキーマ'BATCH'
にすべてのJobRepository表を格納するようにバッチ・ランタイムが構成されます。
WLSTを使用して、バッチ・ジョブの実行に特定の管理対象エグゼキュータ・サービスを使用するようにバッチ・ランタイムを構成できます。ただし、最初に管理対象エグゼキュータ・サービスを作成し、その管理対象エグゼキュータ・サービスの名前をDomainMBean
に指定する必要があります。
connect('admin
','passwd
') edit() startEdit() cmo.setBatchJobsExecutorServiceName('mesName
') save() activate()
ここで、mesName
は、このドメインに対してすでに作成されている(ターゲット指定されている)管理対象エグゼキュータ・サービスの名前になります。
バッチ・ランタイムは、DomainMBean
のgetBatchJobsManagedExecutorServiceName()
メソッドを使用して、別の管理対象エグゼキュータ・サービスを使用するように構成できます。ただし、同じ名前の管理対象エグゼキュータ・サービス・テンプレートが存在し、バッチ・ジョブの発行時にドメイン・スコープにターゲット指定される必要があります。
詳細は、Oracle WebLogic Server MBeanリファレンスのBatchConfigMBeanに関する項およびDomainMBeanに関する項を参照してください。
WLSTコマンドの使用の詳細は、『WebLogic Server WLSTコマンド・リファレンス』のオンラインおよびオフラインのWebLogic Server WLSTコマンド・リファレンスに関する項を参照してください。
次の管理ツールを使用して、ドメイン・スコープについてバッチ・ランタイムのJobRepositorに問い合せることができます。
注意:
バッチJobRepositoryを格納しているデータベースが実行されていることを確認してください。たとえば、デフォルトのDerbyデータベースは、java weblogic.Server
コマンドを使用してWebLogic Serverをブートしたときに自動的に起動されることはありません。データベースが実行されていない場合は、バッチ・ジョブを発行したときか、WLSTまたは管理コンソールを使用してBatchJobRepositoryRuntimeMBeanにアクセスしたときに、バッチRIによって例外がスローされます。詳細は、「トラブルシューティングのヒント」を参照してください。
管理コンソールを使用してJobRepositoryに問い合せることで、ドメインのバッチ・ジョブの詳細を取得できます。
「domain-nameの設定」ページで、「モニタリング」→「バッチ・ジョブ」ページを開き、ドメインにデプロイされたアプリケーションから発行されるすべてのジョブの詳細を表示します。
表8-1 すべてのバッチ・ジョブ
要素名 | 説明 |
---|---|
ジョブ名 |
バッチ・ジョブの名前。 |
アプリケーション名 |
バッチ・ジョブを発行したアプリケーションの名前。 |
インスタンスID |
インスタンスID。 |
実行ID |
実行ID。 |
バッチ・ステータス |
このジョブのバッチ・ステータス。 |
開始時刻 |
ジョブの開始時刻。 |
終了時刻 |
ジョブの完了時刻。 |
終了ステータス |
ジョブの終了ステータス。 |
ジョブのステップ実行の詳細は、それを選択して「表示」をクリックすることで表示できます。
表8-2 ジョブ実行の詳細
要素名 | 説明 |
---|---|
ジョブ名 |
バッチ・ジョブの名前。 |
インスタンスID |
インスタンスID。 |
実行ID |
実行ID。 |
バッチ・ステータス |
このジョブのバッチ・ステータス。 |
開始時刻 |
ジョブの開始時刻。 |
終了時刻 |
ジョブの完了時刻。 |
終了ステータス |
ジョブの終了ステータス。 |
WLSTでBatchJobRepositoryRuntimeMBean
を使用してJobRepositoryに問い合せることで、ドメインのバッチ・ジョブの詳細を取得できます。
詳細は、『Oracle WebLogic Server MBeanリファレンス』のBatchJobRepositoryRuntimeMBeanに関する項を参照してください。
getJobDetails
を使用したすべてのバッチ・ジョブの詳細の取得getJobDetails()
属性により、ドメインにデプロイされたアプリケーションによって発行されるすべてのジョブに関する詳細が返されます。コレクションの各エントリには、次の要素の配列が含まれます。
表8-4 getJobDetails()属性の要素
要素名 | 説明 |
---|---|
JOB_NAME |
バッチ・ジョブの名前。 |
APP_NAME |
バッチ・ジョブを発行したアプリケーションの名前(文字列)。 |
INSTANCE_ID |
インスタンスID (長)。 |
EXECUTION_ID |
実行ID (長)。 |
BATCH_STATUS |
このジョブのバッチ・ステータス(文字列)。 |
START_TIME |
ジョブの開始時刻( |
END_TIME |
ジョブの完了時刻( |
EXIT_STATUS |
ジョブの終了ステータス(文字列)。 |
次に、ドメインにデプロイされたすべてのバッチ・ジョブのリストを出力するgetJobDetails()
を使用するWLSTスクリプトの例を示します。
connect('admin', 'admin123')
domainRuntime()
cd('BatchJobRepositoryRuntime')
cd('myserver')
executions=cmo.getJobDetails(6)
print "JobName AppName InstanceID ExecutionID BatchStatus StartTime EndTime ExitStatus"
print e[0], " ", e[1], " ", e[2], " ", e[3], " ", e[4], " ", e[5], " ", e[6], ",e[7]
次に、getJobDetails()
の実行後のサンプル出力を示します。
JobName InstanceID ExecutionID BatchStatus StartTime EndTime ExitStatus PayrollJob 6 6 COMPLETED Fri Apr 24 10:11:00 PDT 2015 Fri Apr 24 10:11:01 PDT 2015 COMPLETED PayrollJob 5 5 COMPLETED Fri Apr 24 10:10:57 PDT 2015 Fri Apr 24 10:10:58 PDT 2015 COMPLETED PayrollJob 4 4 COMPLETED Fri Apr 24 10:10:56 PDT 2015 Fri Apr 24 10:10:56 PDT 2015 COMPLETED PayrollJob 3 3 COMPLETED Mon Apr 20 11:32:12 PDT 2015 Mon Apr 20 11:32:12 PDT 2015 COMPLETED PayrollJob 2 2 COMPLETED Mon Apr 20 11:32:10 PDT 2015 Mon Apr 20 11:32:11 PDT 2015 COMPLETED PayrollJob 1 1 COMPLETED Mon Apr 20 11:25:26 PDT 2015 Mon Apr 20 11:25:26 PDT 2015 COMPLETED
getJobExecutions
を使用したジョブ実行の詳細の取得getJobExections
属性により、特定のジョブ実行に関する詳細が返されます。コレクションの各エントリには、次の要素の配列が含まれます。
表8-5 getJobExecutions()属性の要素
要素名 | 説明 |
---|---|
JOB_NAME |
バッチ・ジョブの名前(文字列)。 |
INSTANCE_ID |
インスタンスID (長)。 |
EXECUTION_ID |
実行ID (長)。 |
BATCH_STATUS |
このジョブのバッチ・ステータス(文字列)。 |
START_TIME |
ジョブの開始時刻( |
END_TIME |
ジョブの完了時刻( |
EXIT_STATUS |
ジョブの終了ステータス(文字列)。 |
次に、特定のExecutionIDの詳細を取得するためにWLSTスクリプトでgetJobExectuions()
を使用する例(getJobExecutions(6)
)を示します。すべてのExecutionIDのリストを取得するには、getJobDetails()
メソッドを使用します。
connect('admin', 'admin123')
domainRuntime()
cd('BatchJobRepositoryRuntime')
cd('myserver')
executions=cmo.getJobExecutions(6)
print "JobName InstanceID ExecutionID BatchStatus StartTime EndTime ExitStatus"
for e in executions
print e[0], " ", e[1], " ", e[2], " ", e[3], " ", e[4], " ", e[5], " ", e[6]
次に、getJobExecutions()
の実行後のサンプル出力を示します。
JobName InstanceID ExecutionID BatchStatus StartTime EndTime ExitStatus PayrollJob 6 6 COMPLETED Fri Apr 24 10:11:00 PDT 2015 Fri Apr 24 10:11:01 PDT 2015 COMPLETED
getStepExecutions
を使用したジョブ・ステップ実行の詳細の取得getStepExecutions
属性により、ジョブ実行の各ステップに関するメトリックが返されます。コレクションの各エントリには、次の要素の配列が含まれます。
表8-6 getStepExecutions()属性の要素
要素名 | 説明 |
---|---|
STEP_NAME |
バッチ・ジョブ・ステップの名前(文字列)。 |
STEP_ID |
ステップID (長)。 |
EXECUTION_ID |
実行ID (長)。 |
BATCH_STATUS |
このジョブのバッチ・ステータス(文字列)。 |
START_TIME |
ジョブの開始時刻( |
END_TIME |
ジョブの完了時刻( |
EXIT_STATUS |
ジョブの終了ステータス(文字列)。 |
次に、特定のStepExecutionID (getStepExecutions(6)
)の詳細を取得するためにWLSTスクリプトでgetStepExecutions()
を使用する例を示します。すべてのExecutionIDのリストを取得するには、getJobDetails()
メソッドを使用します。
connect('admin', 'admin123')
domainRuntime()
cd('BatchJobRepositoryRuntime')
cd('myserver')
executions=cmo.getStepExecutions(6)
print "StepName StepExecutionID BatchStatus StartTime EndTime ExitStatus"
print e[0], " ", e[1], " ", e[2], " ", e[3], " ", e[4], " ", e[5], "]
次に、getStepExecutions()
の実行後のサンプル出力を示します。
StepName StepExecutionID BatchStatus StartTime EndTime ExitStatus PayrollJob 6 6 COMPLETED Fri Apr 24 10:11:00 PDT 2015 Fri Apr 24 10:11:01 PDT 2015 COMPLETED
この項では、WebLogic Serverでのバッチ・ランタイムの構成と使用に関するヒントについて説明します。
Batch RI (参照実装)のユーザーがよく犯す間違いとして、JobRepository表を含むデータベースの起動を怠ることがあります。たとえば、java weblogic.Server
コマンドを使用してWebLogicを起動する場合、Derbyデータベースは自動で起動しません。DBが実行していない場合、バッチ・ジョブを発行するかJobRepositoryRuntimeMBean
にアクセスすると(WLSTまたは管理コンソールのいずれかを使用)、そのジョブは失敗し、Batch RIから次のような不可解な例外がスローされます。
[1] Exception thrown by Refernce Implementation (from IBM): Caused by: weblogic.common.resourcepool.ResourceSystemException: Cannot load driver class org.apache.derby.jdbc.ClientDataSource for datasource '<<<Data Source name>>>>'
次に、JobRepositoryのデータベースが実行していない場合にBatch RIからスローされる可能性のある別のエラー・メッセージを示します。
Caused By: com.ibm.jbatch.container.exception.PersistenceException: weblogic.jdbc.extensions.ConnectionDeadSQLException: weblogic.common.resourcepool.ResourceDeadException: 0:weblogic.common.ResourceException: Could not create pool connection for datasource '_com_oracle_weblogic_batch_connector@_com_oracle_weblogic_batch_connector_impl_@_com_oracle_weblogic_batch_connector_impl_WLSDatabaseConfigurationBean@_com_oracle_batch_internal__derby_batch_DataSource'. The DBMS driver exception was: java.net.ConnectException : Error connecting to server localhost on port 1,527 with message Connection refused. at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.getConnectionToDefaultSchema(JDBCPersistenceManagerImpl.java:354) at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.isDerby(JDBCPersistenceManagerImpl.java:182) at com.ibm.jbatch.container.services.impl.JDBCPersistenceManagerImpl.init(JDBCPersistenceManagerImpl.java:143) at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader.getService(ServicesManagerImpl.java:404) at com.ibm.jbatch.container.servicesmanager.ServicesManagerImpl$ServiceLoader.access$300(ServicesManagerImpl.java:388)
これらのエラーが表示された場合、Batch JobRepositoryが含まれるデータベースが実行していることを確認します。