Hitachi

Cosminexus V11 BPM/ESB基盤 サービスプラットフォーム システム構築・運用ガイド


7.7.5 TP1/RPC受付実行時の障害対策

この項では,TP1/RPC受付実行時に発生する障害に対して取得できる情報の種類,および障害の対処方法などについて説明します。

〈この項の構成〉

(1) TP1/RPC受付実行時に発生したエラーの伝わり方

エラーの伝わり方は,エラーの種類によって異なります。

ここでは,次の場合についてエラーの伝わり方を説明します。

(a) サービス部品からユーザ定義例外のエラーがリターンした場合(ビジネスプロセスを使用するとき)

  • フォルト処理で障害情報をサービス電文にデータ変換しない場合

    サービス部品からユーザ定義例外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理なし)を次の図に示します。

    図7‒89 サービス部品からユーザ定義例外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理なし)

    [図データ]

    サービス部品で発生した例外は,CSCMsgServerExceptionとしてTP1/RPC受付に伝わります。その例外をキャッチしたTP1/RPC受付は,実行時例外をTP1インバウンドアダプタに再スローします。その後,TP1インバウンドアダプタ経由で,サービスリクエスタには,サービス要求のリターン値としてDCRPCER_SYSERR_AT_SERVER(-316)が返ります。

  • フォルト処理で障害情報をサービス電文にデータ変換する場合

    サービス部品からユーザ定義例外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理あり)を次の図に示します。

    図7‒90 サービス部品からユーザ定義例外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理あり)

    [図データ]

    サービス部品で発生した例外は,そのまま例外としてビジネスプロセスのフォルト処理に伝わります。その後,ビジネスプロセスのフォルト処理でその障害情報を応答電文にデータ変換し,障害情報を含んだ応答電文として,以降の処理に返します。この場合,メッセージ配送制御を経由して,TP1/RPC受付に応答電文が返ります。TP1/RPC受付は,通常の応答電文と同様,その応答電文をTP1インバウンドアダプタに返します。サービスリクエスタには,通常の処理と同様,サービス要求の引数に,応答電文が設定されて返ります。

(b) サービス部品からユーザ定義例外以外のエラーがリターンした場合(ビジネスプロセスを使用するとき)

  • フォルト処理で障害情報をサービス電文にデータ変換しない場合

    サービス部品からユーザ定義例外以外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理なし)を次の図に示します。

    図7‒91 サービス部品からユーザ定義例外以外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理なし)

    [図データ]

    サービス部品で想定外の例外が発生した場合,RuntimeException(システム例外)としてTP1/RPC受付に伝わります。その例外をキャッチしたTP1/RPC受付は,キャッチしたRuntimeException(システム例外)を,そのままTP1インバウンドアダプタに再スローします。その後,TP1インバウンドアダプタ経由で,サービスリクエスタには,サービス要求のリターン値としてDCRPCER_SYSERR_AT_SERVER(-316)が返ります。

  • フォルト処理で障害情報をサービス電文にデータ変換する場合

    サービス部品からユーザ定義例外以外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理あり)を次の図に示します。

    図7‒92 サービス部品からユーザ定義例外以外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理あり)

    [図データ]

    サービス部品で発生した例外は,そのまま例外としてビジネスプロセスのフォルト処理に伝わります。その後,ビジネスプロセスのフォルト処理でその障害情報を応答電文にデータ変換し,障害情報を含んだ応答電文として,以降の処理に返します。この場合,メッセージ配送制御を経由して,TP1/RPC受付に応答電文が返ります。TP1/RPC受付は,通常の応答電文と同様,その応答電文をTP1インバウンドアダプタに返します。サービスリクエスタには,通常の処理と同様,サービス要求の引数に,応答電文が設定されて返ります。

(c) HCSCサーバからエラーがリターンした場合(ビジネスプロセスを使用するとき)

HCSCサーバからエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方を次の図に示します。

図7‒93 HCSCサーバからエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方

[図データ]

図中の各エラーには,次に示すケースが該当します。

  • エラー1:要求パラメタ不正など

  • エラー2:宛先(ロケーション)が見つからない,サービスアダプタが停止しているなど

  • エラー3:データ変換に失敗したなど

  • エラー4:宛先不正,サービス部品が停止,通信障害など

  • エラー5:ビジネスプロセス処理上での例外エラーなど

HCSCサーバで図中のエラー1〜エラー5のどれかを検知した場合,発生したエラーの情報をCSCMsgServerExceptionで,TP1/RPC受付にスローします。その例外をキャッチしたTP1/RPC受付は,実行時例外をTP1インバウンドアダプタに再スローします。その後,TP1インバウンドアダプタ経由で,サービスリクエスタには,サービス要求のリターン値としてDCRPCER_SYSERR_AT_SERVER(-316)が返ります。

(d) TP1インバウンドアダプタでエラーを検知した場合

TP1インバウンドアダプタでエラーを検知した場合のTP1/RPC受付でのエラーの伝わり方を次の図に示します。

図7‒94 TP1インバウンドアダプタでエラーを検知した場合のTP1/RPC受付でのエラーの伝わり方

[図データ]

TP1インバウンドアダプタでエラーが発生した場合,サービスリクエスタには,サービス要求のリターン値として0以外の値が返ります。

詳細は,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「4.17 TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

(2) 障害情報の取得(TP1/RPC受付)

運用時に障害が発生した場合,障害対策に必要な情報は,ログファイルにログとして出力され,トレースファイルにトレースとして出力されます。

ここでは,メッセージログおよび各種トレースの取得方法について説明します。

(a) メッセージログ(TP1/RPC受付)

メッセージログは,次に示すログに出力されます。

  • HCSC-Managerのログ

  • 統合メッセージログ

  • J2EEサーバの稼働ログ

メッセージログの取得方法および出力先については,「7.4.1 メッセージログ」を参照してください。また,メッセージログの詳細は,マニュアル「サービスプラットフォーム メッセージ」の「2. メッセージ一覧」を参照してください。

(b) リクエストトレース(TP1/RPC受付)

リクエストトレースは,リクエストの障害要因の解析に使用します。

リクエストトレースの詳細は,マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録A.8 障害情報の取得(カスタム受付)」のリクエストトレース(カスタム受付)に関する説明を参照してください。

(c) 性能解析トレース(TP1/RPC受付)

性能解析トレース(PRFトレース)は,サービスプラットフォームシステムの性能解析をするためのトレース情報で,それをCSV形式で編集出力したテキストファイルが性能解析トレースファイルです。性能解析トレースは,J2EEアプリケーションを含めた,システム全体の性能ボトルネックを解析するための情報が出力されます。システムの性能ネックや性能トラブルシュートに使用します。性能解析トレース機能については,マニュアル「アプリケーションサーバ 機能解説 保守/移行編」の「7. 性能解析トレースを使用した性能解析」を参照してください。

  • 性能解析トレースの取得ポイント

    性能解析トレースの取得ポイントを次の図に示します。

    図7‒95 性能解析トレースの取得ポイント(TP1/RPC受付)

    [図データ]

    イベントID,トレース取得ポイント,および性能解析トレース取得レベルを次の表に示します。なお,次の表の「図中の番号」は,図中の番号と対応しています。

    表7‒79 性能解析トレースの取得ポイント(TP1/RPC受付)

    イベントID

    図中の番号

    トレース取得ポイント

    レベル

    0x9860

    1

    カスタム受付フレームワークの入口

    A

    0x9861

    2

    カスタム受付フレームワークの出口

    A

    0x9862

    3

    データ変換(要求電文)の呼び出し口

    B

    0x9863

    4

    データ変換(要求電文)の応答受信口

    B

    0x9864

    5

    メッセージ配送制御の呼び出し口

    A

    0x9865

    6

    メッセージ配送制御の応答受信口

    A

    0x9866

    7

    データ変換(応答電文)の呼び出し口

    B

    0x9867

    8

    データ変換(応答電文)の応答受信口

    B

    0x9868

    9

    カスタム受付の入口

    A

    0x9869

    10

    カスタム受付の出口

    A

    0x986A

    11

    カスタム受付フレームワークの呼び出し口

    B

    0x986B

    12

    カスタム受付フレームワークの応答受信口

    B

    (凡例)

    A:標準であることを示します。

    B:詳細であることを示します。

  • 性能解析トレースファイルの出力形式と出力内容

    • 出力形式

      性能解析トレースファイルに出力される形式は,J2EEサーバの性能解析トレースと同様です。性能解析トレースファイルの詳細は,マニュアル「アプリケーションサーバ 機能解説 保守/移行編」の「7. 性能解析トレースを使用した性能解析」を参照してください。

    • 出力内容

      性能解析トレースファイルの出力内容を次の表に示します。

      表7‒80 性能解析トレースファイルに出力される内容

      項目

      内容

      イベントID

      各取得ポイントのイベントIDが出力されます。

      リターンコード

      取得ポイント種別が出力されます。

      • 0:正常終了

      • 1:異常終了

      インターフェース名

      クラス名が出力されます。

      オペレーション名

      メソッド名が出力されます。

      オプション情報

      次のオプション情報が出力されます。

      • 受付名

      • 受付ID

      • クライアント相関ID

      • サービス名

      • サービスオペレーション名

      • 例外名

      注※

      障害が発生したときだけ出力されます。

  • 性能解析トレースの取得方法と出力先

    性能解析トレースファイルの取得方法および出力先は,アプリケーションサーバおよびサービスプラットフォーム全体で共通です。取得方法および出力先については,マニュアル「アプリケーションサーバ 機能解説 保守/移行編」の「7. 性能解析トレースを使用した性能解析」を参照してください。

(d) ユーザ電文トレース(TP1/RPC受付)

ユーザ電文トレースは,電文の状態を確認するために使用します。

次の内容をユーザ電文トレースとして取得できます。

  • TP1インバウンドアダプタ経由で受け付けたサービス部品呼び出し要求または応答の電文

  • ビジネスプロセスを呼び出したときの要求または応答の電文

  • サービスアダプタからサービス部品を呼び出したときの要求または応答の電文

  • データ変換を実行したときの変換前または変換後の電文

ユーザ電文トレースの詳細は,マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録A.8 障害情報の取得(カスタム受付)」を参照してください。

(3) 問題発生個所の切り分け方

ここでは,サービスリクエスタからTP1/RPC受付を使用してサービス部品を呼び出した場合の問題発生個所の切り分け方について説明します。

問題発生個所の切り分け方を次の図に示します。

図7‒96 問題発生個所の切り分け方

[図データ]

図中の(a)〜(d)について,調査する内容を次に示します。

(a) サービス部品に障害の要因がある場合

サービス部品に障害の要因がある場合,実行環境のメッセージログを参照し,サービス部品が返した例外の内容を確認します。

要因は,次の観点で調査してください。

  • サービスリクエスタから要求したユーザ電文

  • サービス部品稼働マシン

  • サービス部品のプログラム

サービス部品呼び出し要求を再送するかどうかは,HCSCサーバを介したサービスリクエスタとサービス部品間(エンドツーエンド)の取り決めとなります。

(b) ビジネスプロセスに障害の要因がある場合

ビジネスプロセスで実行したアクティビティの処理に障害の要因があるおそれがあります(サービス呼出アクティビティの場合,呼び出したサービス部品に障害の要因があるおそれがあります)。この場合,実行環境のメッセージログを参照し,ビジネスプロセスが返したフォルトの内容を確認します。

要因は,次の観点で調査してください。

  • サービスリクエスタから要求したユーザ電文

  • サービス部品稼働マシン

  • サービス部品のプログラム

  • ビジネスプロセスの定義内容

サービス部品呼び出し要求を再送するかどうかは,HCSCサーバを介したサービスリクエスタとサービス部品間(エンドツーエンド)の取り決めとなります。

また,ビジネスプロセスの設計内容によっても,再送(ビジネスプロセスの再実行)するかどうかを決めておく必要があります。

(c) HCSCサーバでエラーを検知した場合

実行環境のメッセージログを参照し,エラーの内容を確認します。確認したエラーコードおよびエラーメッセージの対策に従って対処します。

要因は,次の観点で調査してください。

  • HCSCサーバの設定または状態

  • サービスアダプタの定義内容

  • ビジネスプロセスの定義内容

  • サービスリクエスタから要求したユーザ電文

  • サービス部品稼働マシン

  • サービス部品のプログラム

  • ネットワークの状態

サービス部品呼び出し要求を再送するかどうかは,エラーの内容によって異なります。一時的な障害の場合は,再送を試みることで成功することがありますが,次に示すエラーの場合は,再送を試みてもエラーとなります。

  • HCSCサーバの設定に誤りがある場合

  • サービスアダプタやビジネスプロセスの定義に誤りがある場合

  • サービスリクエスタから要求したユーザ電文に誤りがある場合

(d) TP1インバウンドアダプタでエラーを検知した場合

TP1インバウンドアダプタの障害対策に従って,エラーの内容を調査します。詳細は,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「4.17 TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。

(4) そのほかの障害要因の特定方法(実行履歴の追跡)

サービスリクエスタから指定した情報や,HCSCサーバからの情報を基に,サービス部品呼び出しの処理がどこまで進んでいるかを実行履歴から追跡できます。

ここでは,実行履歴を追跡するために必要な次の情報について説明します。

(a) ルートアプリケーション情報

ルートアプリケーション情報は,一連の処理の先頭になるプロセス(サービスリクエスタ)で取得した情報で,性能解析トレースに出力されます。

ルートアプリケーション情報が引き継がれる範囲を次の図に示します。

図7‒97 ルートアプリケーション情報が引き継がれる範囲

[図データ]

(b) クライアント相関ID

クライアント相関IDは,TP1/RPC受付がサービス部品呼び出し要求ごとに付与するIDです。サービスリクエスタからの要求電文と,HCSCサーバで管理しているログおよびトレースと対応づけるために使用します。

クライアント相関IDが引き継がれる範囲を次の図に示します。

図7‒98 クライアント相関IDが引き継がれる範囲

[図データ]

(c) メッセージ共通ID

メッセージ共通IDは,HCSCサーバがサービス部品呼び出し要求ごとに付与するIDです。HCSCサーバ内のログおよびトレースを識別するために使用します。

メッセージ共通IDが引き継がれる範囲を次の図に示します。

図7‒99 メッセージ共通IDが引き継がれる範囲

[図データ]