Cosminexus V9 BPM/ESB基盤 サービスプラットフォーム システム構築・運用ガイド
この項では,TP1/RPC受付実行時に発生する障害に対して取得できる情報の種類,および障害の対処方法などについて説明します。
エラーの伝わり方は,エラーの種類によって異なります。
ここでは,次の場合についてエラーの伝わり方を説明します。
図7-83 サービス部品からユーザ定義例外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理なし)
サービス部品で発生した例外は,CSCMsgServerExceptionとしてTP1/RPC受付に伝わります。その例外をキャッチしたTP1/RPC受付は,実行時例外をTP1インバウンドアダプタに再スローします。その後,TP1インバウンドアダプタ経由で,サービスリクエスタには,サービス要求のリターン値としてDCRPCER_SYSERR_AT_SERVER(-316)が返ります。図7-84 サービス部品からユーザ定義例外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理あり)
サービス部品で発生した例外は,そのまま例外としてビジネスプロセスのフォルト処理に伝わります。その後,ビジネスプロセスのフォルト処理でその障害情報を応答電文にデータ変換し,障害情報を含んだ応答電文として,以降の処理に返します。この場合,メッセージ配送制御を経由して,TP1/RPC受付に応答電文が返ります。TP1/RPC受付は,通常の応答電文と同様,その応答電文をTP1インバウンドアダプタに返します。サービスリクエスタには,通常の処理と同様,サービス要求の引数に,応答電文が設定されて返ります。図7-85 サービス部品からユーザ定義例外以外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理なし)
サービス部品で想定外の例外が発生した場合,RuntimeException(システム例外)としてTP1/RPC受付に伝わります。その例外をキャッチしたTP1/RPC受付は,キャッチしたRuntimeException(システム例外)を,そのままTP1インバウンドアダプタに再スローします。その後,TP1インバウンドアダプタ経由で,サービスリクエスタには,サービス要求のリターン値としてDCRPCER_SYSERR_AT_SERVER(-316)が返ります。図7-86 サービス部品からユーザ定義例外以外のエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方(フォルト処理あり)
サービス部品で発生した例外は,そのまま例外としてビジネスプロセスのフォルト処理に伝わります。その後,ビジネスプロセスのフォルト処理でその障害情報を応答電文にデータ変換し,障害情報を含んだ応答電文として,以降の処理に返します。この場合,メッセージ配送制御を経由して,TP1/RPC受付に応答電文が返ります。TP1/RPC受付は,通常の応答電文と同様,その応答電文をTP1インバウンドアダプタに返します。サービスリクエスタには,通常の処理と同様,サービス要求の引数に,応答電文が設定されて返ります。HCSCサーバからエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方を次の図に示します。
図7-87 HCSCサーバからエラーがリターンした場合(ビジネスプロセスを使用するとき)のTP1/RPC受付でのエラーの伝わり方
図中の各エラーには,次に示すケースが該当します。
HCSCサーバで図中のエラー1〜エラー5のどれかを検知した場合,発生したエラーの情報をCSCMsgServerExceptionで,TP1/RPC受付にスローします。その例外をキャッチしたTP1/RPC受付は,実行時例外をTP1インバウンドアダプタに再スローします。その後,TP1インバウンドアダプタ経由で,サービスリクエスタには,サービス要求のリターン値としてDCRPCER_SYSERR_AT_SERVER(-316)が返ります。
TP1インバウンドアダプタでエラーを検知した場合のTP1/RPC受付でのエラーの伝わり方を次の図に示します。
図7-88 TP1インバウンドアダプタでエラーを検知した場合のTP1/RPC受付でのエラーの伝わり方
TP1インバウンドアダプタでエラーが発生した場合,サービスリクエスタには,サービス要求のリターン値として0以外の値が返ります。
詳細は,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「4.17 TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。
運用時に障害が発生した場合,障害対策に必要な情報は,ログファイルにログとして出力され,トレースファイルにトレースとして出力されます。
ここでは,メッセージログおよび各種トレースの取得方法について説明します。
メッセージログは,次に示すログに出力されます。
メッセージログの取得方法および出力先については,「7.4.1 メッセージログ」を参照してください。また,メッセージログの詳細は,マニュアル「サービスプラットフォーム メッセージ」の「2. メッセージ一覧」を参照してください。
リクエストトレースは,リクエストの障害要因の解析に使用します。
リクエストトレースの詳細は,マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録A.8 障害情報の取得(カスタム受付)」のリクエストトレース(カスタム受付)に関する説明を参照してください。
性能解析トレース(PRFトレース)は,サービスプラットフォームシステムの性能解析をするためのトレース情報で,それをCSV形式で編集出力したテキストファイルが性能解析トレースファイルです。性能解析トレースは,J2EEアプリケーションを含めた,システム全体の性能ボトルネックを解析するための情報が出力されます。システムの性能ネックや性能トラブルシュートに使用します。性能解析トレース機能については,マニュアル「アプリケーションサーバ 機能解説 保守/移行編」の「7. 性能解析トレースを使用した性能解析」を参照してください。
図7-89 性能解析トレースの取得ポイント
イベントID,トレース取得ポイント,および性能解析トレース取得レベルを次の表に示します。なお,次の表の「図中の番号」は,図中の番号と対応しています。表7-70 性能解析トレースの取得ポイント
イベント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 |
表7-71 性能解析トレースファイルに出力される内容
項目 | 内容 |
---|---|
イベントID | 各取得ポイントのイベントIDが出力されます。 |
リターンコード | 取得ポイント種別が出力されます。
|
インターフェース名 | クラス名が出力されます。 |
オペレーション名 | メソッド名が出力されます。 |
オプション情報 | 次のオプション情報が出力されます。
|
ユーザ電文トレースは,電文の状態を確認するために使用します。
次の内容をユーザ電文トレースとして取得できます。
ユーザ電文トレースの詳細は,マニュアル「サービスプラットフォーム 開発ガイド 受付・アダプタ定義編」の「付録A.8 障害情報の取得(カスタム受付)」を参照してください。
ここでは,サービスリクエスタからTP1/RPC受付を使用してサービス部品を呼び出した場合の問題発生個所の切り分け方について説明します。
問題発生個所の切り分け方を次の図に示します。
図7-90 問題発生個所の切り分け方
図中の(a)〜(d)について,調査する内容を次に示します。
サービス部品に障害の要因がある場合,実行環境のメッセージログを参照し,サービス部品が返した例外の内容を確認します。
要因は,次の観点で調査してください。
サービス部品呼び出し要求を再送するかどうかは,HCSCサーバを介したサービスリクエスタとサービス部品間(エンドツーエンド)の取り決めとなります。
ビジネスプロセスで実行したアクティビティの処理に障害の要因があるおそれがあります(サービス呼出アクティビティの場合,呼び出したサービス部品に障害の要因があるおそれがあります)。この場合,実行環境のメッセージログを参照し,ビジネスプロセスが返したフォルトの内容を確認します。
要因は,次の観点で調査してください。
サービス部品呼び出し要求を再送するかどうかは,HCSCサーバを介したサービスリクエスタとサービス部品間(エンドツーエンド)の取り決めとなります。
また,ビジネスプロセスの設計内容によっても,再送(ビジネスプロセスの再実行)するかどうかを決めておく必要があります。
実行環境のメッセージログを参照し,エラーの内容を確認します。確認したエラーコードおよびエラーメッセージの対策に従って対処します。
要因は,次の観点で調査してください。
サービス部品呼び出し要求を再送するかどうかは,エラーの内容によって異なります。一時的な障害の場合は,再送を試みることで成功することがありますが,次に示すエラーの場合は,再送を試みてもエラーとなります。
TP1インバウンドアダプタの障害対策に従って,エラーの内容を調査します。詳細は,マニュアル「アプリケーションサーバ 機能解説 基本・開発編(コンテナ共通機能)」の「4.17 TP1インバウンドアダプタで発生するRPCエラー応答」を参照してください。
サービスリクエスタから指定した情報や,HCSCサーバからの情報を基に,サービス部品呼び出しの処理がどこまで進んでいるかを実行履歴から追跡できます。
ここでは,実行履歴を追跡するために必要な次の情報について説明します。
ルートアプリケーション情報は,一連の処理の先頭になるプロセス(サービスリクエスタ)で取得した情報で,性能解析トレースに出力されます。
ルートアプリケーション情報が引き継がれる範囲を次の図に示します。
図7-91 ルートアプリケーション情報が引き継がれる範囲
クライアント相関IDは,TP1/RPC受付がサービス部品呼び出し要求ごとに付与するIDです。サービスリクエスタからの要求電文と,HCSCサーバで管理しているログおよびトレースと対応づけるために使用します。
クライアント相関IDが引き継がれる範囲を次の図に示します。
図7-92 クライアント相関IDが引き継がれる範囲
メッセージ共通IDは,HCSCサーバがサービス部品呼び出し要求ごとに付与するIDです。HCSCサーバ内のログおよびトレースを識別するために使用します。
メッセージ共通IDが引き継がれる範囲を次の図に示します。
図7-93 メッセージ共通IDが引き継がれる範囲
All Rights Reserved. Copyright (C) 2012, 2019, Hitachi, Ltd.