66.5. プロセスエンジンの実行エラー
タスクサービスを含むプロセスエンジン実行のどの部分でも、例外を発生することができます。例外は、java.lang.Throwable を拡張する任意のクラスとすることができます。
一部の例外は、プロセスレベルで処理されます。注目すべき点は、ワークアイテムハンドラーは、エラー処理のためのサブプロセスを指定するカスタム例外を発生することができることです。ワークアイテムハンドラーの開発については、カスタムタスクおよびワークアイテムハンドラー を参照してください。
例外が処理されずにプロセスエンジンに到達した場合、実行エラー となります。実行エラーが発生した場合、プロセスエンジンは現在のトランザクションをロールバックし、プロセスを以前の安定した状態にします。その後、プロセスエンジンは、その時点からプロセスの実行を継続します。
実行エラーは、プロセスエンジンにリクエストを送った呼び出し元が見ることができます。プロセスエンジンは、実行エラーを処理し、その情報を保存するための拡張可能なメカニズムも備えています。このメカニズムは、以下のコンポーネントで設定されています。
ExecutionErrorManager: エラー処理のエントリーポイント。このクラスはRuntimeManagerと統合され、基盤となるKieSessionおよびTaskServiceに提供されます。ExecutionErrorManagerは、実行エラー処理メカニズムの他のクラスへのアクセスを提供します。プロセスエンジンが
RuntimeManagerインスタンスを作成すると、それに対応するExecutionErrorManagerインスタンスも作成されます。ExecutionErrorHandler: エラー処理のためのメインのクラス。このクラスはプロセスエンジンに実装されており、通常、直接カスタマイズや拡張を行う必要はありません。ExecutionErrorHandlerは、エラーフィルターを呼び出して特定のエラーを処理し、ExecutionErrorStorageを呼び出してエラー情報を格納します。ExecutionErrorHandlerは、RuntimeEngineのライフサイクルにバインドされ、新しいランタイムエンジンの生成時に生成され、RuntimeEngineが破棄されたときに破棄されます。ある実行コンテキストもしくはトランザクションでは、単一インスタンスのExecutionErrorHandlerが使用されます。KieSessionおよびTaskServiceの両方がそのインスタンスを使用して、処理されたノードまたはタスクに関するエラー処理を通知します。ExecutionErrorHandlerには、以下のイベントが通知されます。- ノードインスタンスの処理の開始
- ノードインスタンスの処理の完了
- タスクインスタンスの処理の開始
タスクインスタンスの処理の完了
特にエラー自体がプロセスコンテキスト情報を提供しない場合、
ExecutionErrorHandlerはこの情報を使用してエラーのコンテキストを記録します。たとえば、データベース例外にはプロセス情報がありません。
ExecutionErrorStorage: 実行エラー情報のための、プラグ可能なストレージクラスプロセスエンジンが
RuntimeManagerインスタンスを作成すると、それに対応するExecutionErrorStorageインスタンスも作成されます。続いて、ExecutionErrorHandlerクラスはこのExecutionErrorStorageインスタンスを呼び出して、すべての実行エラーの情報を保存します。デフォルトのストレージ実装では、データベーステーブルを使用して、すべてのエラーについて利用可能なすべての情報を格納します。一部のエラーでは、詳細な情報を抽出できない場合があるため、エラーの種類によって、利用できる詳細レベルが異なる場合があります。
- 特定の種類の実行エラーを処理する多数の フィルター。カスタムフィルターを追加することができます。
デフォルトでは、すべての実行エラーは 未承認 として記録されます。Business Central を使用すると、記録されたすべての実行エラーを表示し、それを承認することができます。すべてまたは一部の実行エラーを自動的に承認するジョブを作成することもできます。
Business Central を使用して実行エラーを表示する、エラーを自動的に承認するジョブを作成する方法については、Business Central でのビジネスプロセスの管理および監視 を参照してください。
66.5.1. 実行エラーのタイプとフィルター
実行エラーの処理では、どのような種類のエラーも補足して処理を試みます。しかし、エラーごとに異なる方法で処理しなければならない可能性があります。また、エラーの種類によって、利用できる詳細情報が異なります。
エラー処理メカニズムは、プラグイン可能なフィルター をサポートしています。どのフィルターも、特定の種類のエラーを処理します。特定のエラーを異なる方法で処理するフィルターを追加し、デフォルトの処理を上書きすることができます。
フィルターは、ExecutionErrorFilter インターフェイスの実装です。このインターフェイスは ExecutionError のインスタンスをビルドし、これは後で ExecutionErrorStorage クラスを使用して保存されます。
ExecutionErrorFilter インターフェイスは、以下のメソッドを持ちます。
-
accept: エラーがフィルターで処理可能かどうかを示します -
filter: エラーを処理し、ExecutionErrorインスタンスを返します -
getPriority: このフィルターの優先度を示します
実行エラーハンドラーは、各エラーを個別に処理します。エラーが発生するたびに、登録されているすべてのフィルターの accept メソッドを、優先度値の低いものから順に呼び出し始めます。あるフィルターの accept メソッドが true を返した場合、ハンドラーはそのフィルターの filter メソッドを呼び出し、他のフィルターを呼び出しません。
優先順位があるため、どのようなエラーでも 1 つのフィルターだけが処理します。より特殊なフィルターほど、優先度の値は低くなります。どの特殊なフィルターも受け付けないエラーは、より高い優先度の値を持つ汎用フィルターに到達します。
ServiceLoader メカニズムは、ExecutionErrorFilter インスタンスを提供します。カスタムフィルターを登録するには、その完全修飾クラス名をサービスプロジェクトの META-INF/services/org.kie.internal.runtime.error.ExecutionErrorFilter ファイルに追加します。
Red Hat Process Automation Manager には、以下の実行エラーフィルターが付属しています。
表66.1 ExecutionErrorFilters
| クラス名 | タイプ | 優先順位 |
|---|---|---|
| org.jbpm.runtime.manager.impl.error.filters.ProcessExecutionErrorFilter | Process | 100 |
| org.jbpm.runtime.manager.impl.error.filters.TaskExecutionErrorFilter | タスク | 80 |
| org.jbpm.runtime.manager.impl.error.filters.DBExecutionErrorFilter | DB | 200 |
| org.jbpm.executor.impl.error.JobExecutionErrorFilter | Job | 100 |
フィルターには、優先度の値の低いものが実行順序の高いものとして与えられます。したがって、実行エラーハンドラーは、以下の順序でこれらのフィルターを呼び出します。
- タスク
- Process
- Job
- DB
