第17章 実行エラー管理

ビジネスプロセスの実行エラーが発生すると、プロセスが停止し、直近の安定した状態 (直近の安全なポイント) に戻り、実行を継続します。プロセスでエラーが何も処理されていない場合には、トランザクション全体がロールバックされ、プロセスインスタンスを 1 つ前の待機状態のままにします。この過程はログにのみ表示され、通常プロセスエンジンに要求を送信する呼び出し元に表示されます。

プロセスの管理者 (process-admin)、または管理者 (admin) ロールが割り当てられているユーザーが、Business Central のエラーメッセージにアクセスできます。実行エラーメッセージ機能では、主に以下の利点があります。

  • より優れたトレーサビリティー
  • 重大なプロセスの表示
  • エラー状態に基づいたレポートおよび解析
  • 外部システムエラー処理および補正

設定可能なエラー処理は、プロセスエンジンの実行 (タスクサービスを含む) 時に発生した技術エラーに対応します。以下の技術例外が適用されます。

  • java.lang.Throwable を拡張するすべてのもの
  • プロセスレベルのエラー処理およびその他の例外が事前に処理されていない

エラー処理メカニズムを構成し、その機能を拡張するプラグ可能なアプローチが可能なコンポーネントが複数あります。

エラー処理を行うプロセスエンジンのエントリーポイントは ExecutionErrorManager です。これは、RuntimeManager と統合され、基盤となる KieSession および TaskService に渡します。

API の観点からすると、ExecutionErrorManager で次のコンポーネントにアクセスできます。

  • ExecutionErrorHandler: エラー処理の主なメカニズム
  • ExecutionErrorStorage: 実行エラー情報のための、プラグ可能なストレージ

17.1. 実行エラーの管理

定義上、検出および保存されたプロセスエラーは何も確認されておらず、何らかの形 (エラーからの自動回復の場合) で処理する必要がありますに。確認済みかどうかで、エラーをフィルタリングできます。エラーを確認すると、今後追跡可能にするため、ユーザー情報とタイムスタンプが保存されます。Error Management ビューにはいつでもアクセスできます。

手順

  1. Business Central で、MenuManageExecution Errors の順に移動します。
  2. 一覧からエラーを選択し、Details タブを開いて、エラーの情報を表示します。
  3. Acknowledge ボタンをクリックして、エラーを確認して削除します。Manage Execution Errors ページの Acknowledged フィルターで Yes を選択すれば、後からそのエラーを表示できます。

    エラーがタスクに関連する場合は、Go to Task ボタンが表示されます。

  4. 該当する場合には、Go to Task ボタンをクリックして、Manage Tasks ページに、関連するジョブ情報を表示します。

    Manage Tasks ページでは、対応するタスクの再起動、再スケジュール、または再試行を行うことができます。

17.2. ExecutionErrorHandler

ExecutionErrorHandler は、すべてのプロセスエラー処理の主要メカニズムです。これは RuntimeEngine に結びついているので、新規 RuntimeEngine が作成されるとこれも作成され、RuntimeEngine が破棄されるとこれも破棄されます。ある実行コンテキストもしくはトランザクションでは、単一インスタンスの ExecutionErrorHandler が使用されます。KieSessionTaskService の両方がそのインスタンスを使用して、処理されたノード/タスクについてのエラー処理を通知します。ExecutionErrorHandler には以下の情報について通知されます。

  • ノードインスタンスの処理の開始
  • ノードインスタンスの処理の完了
  • タスクインスタンスの処理の開始
  • タスクインスタンスの処理の完了

この情報は主に、未知のタイプのエラーに使用されます。つまり、プロセスコンテキストについての情報を提供しないエラーです。たとえば、コミット時にデータベース例外にはプロセス情報がありません。

17.3. 実行エラーの保存

ExecutionErrorStorage はプラグ可能な戦略で、実行エラーについての情報の永続化を各種の方法で可能にします。ストレージは、ストアのインスタンス作成時 (RuntimeEngine の作成時) にこれを取得するハンドラーが直接使用します。デフォルトのストレージ実装はデータベーステーブルをベースにしており、これはすべてのエラーを保存し、利用可能な全情報を含めるものです。エラーによっては詳細を含まないものもあります。これは、エラーのタイプや特定情報を抽出可能かどうかによって異なるためです。

17.4. エラータイプとフィルター

エラー処理ではどのような種類のエラーも捕まえて処理使用とするので、エラーをカテゴリ分けする方法が必要になります。こうすることで、エラーから適切に情報を抽出し、プラグ可能とすることができます。これは、ユーザーによっては、デフォルトとは違う方法で特定タイプのエラーのスローと処理方法を必要とするためです。

エラーのカテゴリー分けとフィルタリングは、ExecutionErrorFilters をベースにしています。このインターフェイスは ExecutionError のインスタンス構築を担っており、これは後で ExecutionErrorStorage 戦略で保存されます。これには以下のメソッドがあります。

  • accept: エラーがフィルターで処理可能かどうかを示します。
  • filter: 実際のフィルタリング、処理などが発生する場所です。
  • getPriority: フィルター呼び出し時に使用される優先度を示します。

フィルターは、一度に処理するエラーは 1 つで、優先順位の仕組みを使用して、複数のフィルターで、別の「ビュー」で同じエラーが返されないようにします。優先順位を使用すると、より特化したフィルターで、エラーが受け入れられるかどうか、または別のフィルターで処理可能かを判断します。

ExecutionErrorFilterServiceLoader メカニズムを使用することで 提供され、これによりエラー処理の機能が容易に拡張できます。

Red Hat Process Automation Manager には以下の ExecutionErrorFilters が同梱されています。

表17.1 ExecutionErrorFilters

クラス名タイプ優先順位

org.jbpm.runtime.manager.impl.error.filters.ProcessExecutionErrorFilter

Process

100

org.jbpm.runtime.manager.impl.error.filters.TaskExecutionErrorFilter

Task

80

org.jbpm.runtime.manager.impl.error.filters.DBExecutionErrorFilter

DB

200

org.jbpm.executor.impl.error.JobExecutionErrorFilter

Job

100

フィルターには、優先度の値の低いものが実行順序の高いものとして与えられます。上記のテーブルでは、以下の順序でフィルターが実行されます。

  1. Task
  2. Process
  3. Job
  4. DB

17.5. 実行エラーの自動承認

実行エラーが発生すると、デフォルトでは承認されず、承認されるには手動での作業が必要になります。これがなされないと、実行エラーは注意が必要な情報としてみなされます。ボリュームが大きい場合は、手動作業には時間がかかるので、状況によっては適当ではありません。

自動承認によりこの問題が解消されます。これは jbpm-executor を使ったスケジュールジョブをベースとするもので、以下の 3 つのタイプのジョブが利用できます。

org.jbpm.executor.commands.error.JobAutoAckErrorCommand
1 回失敗したものの、別の実行でキャンセル、完了、もしくは再スケジュールされたジョブを探します。このジョブは Job タイプの実行エラーのみを承認します。
org.jbpm.executor.commands.error.TaskAutoAckErrorCommand
1 回失敗したものの、いずれかの終了状態 (completed、failed、exited、obsolete) にあるタスクのユーザータスク実行エラーを自動承認します。このジョブは Task タイプの実行エラーのみを承認します。
org.jbpm.executor.commands.error.ProcessAutoAckErrorCommand
エラーがアタッチされたプロセスインスタンスを自動承認します。プロセスインスタンスが既に終了してる (completed または aborted) エラー、もしくはエラーの発生元であるタスクがすでに終了しているエラーを承認します。これは init_activity_id 値をベースにしています。このジョブは、これらの条件に合致する実行エラーのタイプすべてを承認します。

ジョブは KIE Server で登録できます。Business Central では、以下のようにしてエラーに対する自動承認ジョブを設定できます。

前提条件

  • プロセス実行中に 1 つ以上のタイプの実行エラーが発生したが、さらなる注意を必要としていない。

手順

  1. Business Central で、MenuManageProcess Instances の順にクリックします。
  2. 画面右上の New Job をクリックします。
  3. Business Key フィールドにプロセス相関キーを入力します。
  4. Type フィールドに上記のリストから自動承認ジョブタイプを追加します。
  5. Due On でジョブの完了時間を選択します。

    1. ジョブをすぐに実行する場合は、Run now オプションを選択します。
    2. 特定の時間にジョブを実行する場合は、Run later を選択します。Run later オプションの横に日時フィールドが表示されるので、フィールドをクリックしてカレンダーを開き、ジョブ実行日時をスケジュールします。

      auto acknowledge error job1
  6. Create をクリックしてジョブを作成し、Manage Jobs ページに戻ります。

以下のステップはオプションになり、自動承認ジョブを 1 回のみ (SingleRun) または特定の間隔 (NextRun) で実行するか、承認するジョブの検索にエンティティマネジャーファクトリーのカスタム名を使用 (EmfName) して実行するように設定できます。

  1. 詳細 タブをクリックします。
  2. パラメーターの追加 ボタンをクリックします。
  3. ジョブに適用する設定パラメーターを入力します。

    1. SingleRun: true または false
    2. NextRun: 2h、5d、1m などの時間表示。
    3. EmfName: カスタムのエンティティマネージャーファクトリー名

      auto acknowledge error job2

17.6. エラー一覧のクリーンアップ

ExecutionErrorInfo エラーリストテーブルは、クリーンアップして冗長情報を削除できます。プロセスのライフサイクルによっては、エラーがリストにしばらく残る場合があり、そのリストをクリーンアップするための直接的な API はありません。代わりに、ExecutionErrorCleanupCommand コマンドをスケジュールして、エラーを定期的にクリーンアップできます。

クリーンアップコマンドには、次のパラメーターを設定できます。このコマンドは、すでに完了または中断済みのプロセスインスタンスの実行エラーしか削除できません。

  • DateFormat

    • 日付関連パラメーター用の日付形式 - 指定されない場合は、yyyy-MM-dd が使用されます (SimpleDateFormat クラスのパターン)。
  • EmfName

    • クエリーに使用するエンティティマネジャーファクトリーの名前 (有効な永続的ユニット名)。
  • SingleRun

    • 実行が 1 回のみかどうかを指定します (true|false)。
  • NextRun

    • 次回の実行時間を指定します (有効な時間表記。例: 1d、5h など)
  • OlderThan

    • 削除するエラーを指定します - 指定した日付より古いものが削除されます。
  • OlderThanPeriod

    • 指定した時間表記よりも古いエラーを削除することを指定します (有効な時間表記。例: 1d、5h など)
  • ForProcess

    • 指定したプロセス定義のみのエラーを削除します。
  • ForProcessInstance

    • 指定したプロセスインスタンスのみのエラーを削除します。
  • ForDeployment

    • 指定したデプロイメント ID からのエラーを削除します。