1. 製品管理の実装
  2. 失敗したプロセスのデバッグ
機械翻訳について

失敗したプロセスのデバッグ

エラー情報を収集して、スケジューリングおよびアクティブ化の失敗の原因をデバッグしたり、変更をスタックするのを支援できます。 役に立つ情報を次に示します:

デバッグ情報を表示

  • 重要なデバッグ情報には、Enterprise Scheduler Service (ESS)のログ表およびデータベース表(EGO_CHANGE_ERRORSおよびEGO_VERSIONS_BATCH_THREADS)でアクセスできます。
  • デバッグ情報は、単一のエラー表(EGO_CHANGE_ERRORS)に集中管理されます。 エラーの詳細列(ERROR_DETAIL)は、スタック・トレース全体を取得します。

    メッセージは、開始しなかったスレッドが原因で変更オーダーが自動的に取り消されるとトリガーされます。 EGO_CHANGES_ERRORS表の「CLOB」フィールドには、この理由で自動的に取り消された変更明細の詳細がログに記録されます。

  • サービス・サーバー名と実行IDは、スレッド表(EGO_VERSIONS_BATCH_THREADS)およびエラー表(EGO_CHANGE_ERRORS)の列として使用可能であり、変更がスケジュールされたステータスでスタックした場合にデバッグに役立ちます。

エンタープライズ・サービス・スケジューラ・ジョブ間の時間間隔の構成

  • エンタープライズ・スケジューラ・サービス・エラーの場合、アプリケーションはスタックおよび未処理の変更明細の再処理を試行します。

    Enterprise Service Schedulerジョブ間の時間間隔を構成できます。

    Enterprise Managerで、ESSAPP > 「構成」 > 「アプリケーション・プロパティ」をクリックします。

  • FirstRetryInterval: エンタープライズ・スケジューラ・ジョブがエラーで終了してから、最初の変更明細の再処理を試行する時間(分)。
  • FollowOnRetryBaseInterval: 変更明細の再処理を最初に試行してから、2回目の試行で変更明細の再処理を試行する分数。 この間隔に基づいて、明細が再処理されるまで5回の試行が開始されます。

    たとえば、変更に10行あり、3行目から10行目が完了しなかったとします。 FirstRetryIntervalを15、FollowOnRetryBaseIntervalを30に設定しました。 この場合、行を取り消すのではなく、行4から10が再処理されます。 最初の試行は、行が失敗した15分後に行われます。 2番目の試行は、最初の試行が失敗した30分後に行われます。

  • アクティブ化中のエラーを回避するために、次の表の同期有効日を前処理します:

    EGO_VERSIONS_B

    EGP_ITEM_REVISIONS_B

    EGP_SYSTEM_ITEMS_B

    EGO_ITEM_EFF_B

    EGO_ITEM_EFF_TL

    EGP_ITEM_RELATIONSHIPS_B

    EGP_COMPONENTS_B

    EGO_ITEM_REVISION_EFF_B

    EGO_ITEM_REVISION_EFF_TL

    EGO_ITEM_SUPPLIER_EFF_B

    EGO_ITEM_SUPPLIER_EFF_B

    EGO_ITEM_SUPPLIER_EFF_TL

    EGO_ITEM_ASSOCIATIONS

    スケジューリング・ログのパージ後でも、エラー詳細にアクセスできます
ノート: 実装ログで変更オーダー検証エラーを直接デバッグするには、管理者プロファイル値の管理タスクを使用して、変更デバッグの有効化(ORA_EGO_CHANGE_DEBUG_MODE)というプロファイル・オプションを有効にする必要があります。

スケジュール済プロセスの失敗時にプロセスIDを表示

ルールの検証に失敗すると、エラー表とログの両方に、詳細を示す適切なエラー・メッセージが表示されます。

スケジューリング・プロセスが失敗すると、エンタープライズ・スケジューラ・サービスのログにプロセスIDが表示され、影響を受けるオブジェクト・タブが変更されます。

プロセスIDを使用して、EGO_CHANGES_ERRORS表からエラーを問い合せ、失敗したプロセスをデバッグできます。

サンプルの問合せを次に示します:

fusion.ego_change_errorsから*を選択します。request_id=[ 「プロセスID」 ];

失敗したプロセスをデバッグする方法を次に示します:

  1. 変更オーダーの「影響を受けるオブジェクト」タブにナビゲートします。

  2. 「アクティブ化プロセスID」列および「サブプロセスID」列を見つけて、失敗したプロセスIDをコピーします。

    必要に応じて、列までスクロールします。

    プロファイル・オプション変更デバッグの有効化に応じて、デバッグ情報の問合せ方法を次に示します。

  3. プロファイル・オプション変更デバッグの有効化が有効:の場合

    プロセスIDを使用して、デバッグ情報をEGO_CHANGES_ERRORS表に問い合せます。

  4. プロファイル・オプション変更デバッグの有効化が無効:の場合

    失敗したスケジュール済プロセスの場合は、スケジューリング・プロセスIDを使用して、デバッグ情報をEGO_CHANGES_ERRORS表に問い合せます。

    失敗したアクティブ化プロセスの場合:
    • 「スケジュール済プロセスの表示」ページを使用して、アクティブ化プロセスIDで検索します。

    • 階層ビューで、エラーが発生したサブプロセスのIDを確認できます。 エラーの詳細を表示するには、「ログの表示」をクリックします。

    • サブプロセスIDを使用して、EGO_CHANGES_ERRORS表にデバッグ情報を問い合せます。

      ノート: 同様の問合せを使用してBIデータ・モデルを作成し、EGO_CHANGES_ERRORS表のデータを表示できます。
スケジュール済ステータス中に検証がスキップされました
変更の回復性とパフォーマンスを向上させるために、スケジュールされたステータス中に次の検証がスキップされます:
  • 承認が必要: 承認が必要検証(重大度レベルが品目ルール・セットの管理タスクで承認が必要に設定されている)は、スケジュール済ステータス中にスキップされます。 これにより、変更オーダーの進行中に、属性名、API名または拡張可能フレックスフィールド属性のプロンプトに対する更新によって生じる問題が回避されます。
  • 拡張可能フレックスフィールド値セット: 拡張可能フレックスフィールド属性値セットの検証で、変更オーダーの値が非アクティブ化されているか、または終了したかどうかが予定済ステータス中にスキップされるかどうかを確認します。
  • 拡張可能フレックスフィールド属性: スケジュール済ステータス中に強制拡張可能フレックスフィールド属性をチェックするための検証はスキップされます。 これによって、強制フレックスフィールド属性を変更オーダーに追加することによる問題が回避されます。