拡張パスポート（EPP）を使用すると、分散システムランドスケープ内のコールシーケンスを分析できます。
目的
今日のシステムランドスケープは、いくつかの統合されたSAPシステムと非SAPシステムで構成されている可能性があります。これにより、システム間の通信の監視と分析が困難になります。
拡張パスポート（EPP）を使用すると、コールシーケンスを評価し、ログトレースとエラーメッセージを相互に関連付け、分散システムランドスケープでエンドツーエンドのトレースを実行できます。
EPPは、新しいユーザーセッションが開かれたときに作成されます。これは、通信プロトコル（RFC、HTTPなど）によって転送されるデータ構造を表します。EPPは、常にクライアントからサーバーに転送されます。
EPPの利点
-
呼び出しシーケンスの一部である単一のシステムと個々の要求を識別できます。
-
統合システム内のクライアントとサーバー間の要求とプロセスのシーケンスを分析することにより、分散ランドスケープのパフォーマンスのボトルネックを検出できます。
-
統計レコード、ログ、およびABAPトレース、SQLトレース、RFCトレース、開発者トレースなどのトレースで、クライアント/サーバー通信を監視および分析することができます。
EPP構造
EPPは、監視ツールまたは特定のAPIを介して表示できるユーザーセッションに関する次の情報を提供します。
統合
クライアントが最初の要求をサーバーに送信すると、ルートコンテキストIDが生成され、呼び出しシーケンス全体を通じてEPPとともに渡されます。リクエスト自体は接続IDで識別されます。クライアントとサーバーの両方が、ログ、トレース、および統計レコードでこの情報を使用します。
ただし、ステートフル通信とステートレス通信でEPPがどのように転送されるかについていくつかの違いを考慮する必要があります。
ステートフルコミュニケーションにおけるEPPトランスポート
図に示されている例では、ABAPクライアントは、ステートフルクライアント/サーバー通信で通常使用される同期RFCを介してABAPサーバーに要求を送信します。ルートコンテキストIDは初期コンテキストで作成され、EPPとともにサーバーに転送されます。最初のRFC要求を送信している間、ABAPクライアントは接続ID（A1）でRFC接続を確立します。クライアントが2番目の要求を送信するとき、RFC接続がすでに存在するため、接続IDは同じままです。接続カウンタの値はから増加します1に2。
RFCを介した次のシステムコールでは、ルートコンテキストIDのみが一定のままです。確立されたRFC接続は、新しい接続ID（B1）によって識別され、接続カウンターは次のように設定されます。1。
ステートレス通信におけるEPPトランスポート
ステートレスクライアント/サーバー通信では、通常、HTTP通信プロトコルが使用されます。この図は、クライアントがHTTP要求をサーバーに送信する例を示しています。ステートフル通信の場合と同様に、ルートコンテキストIDは初期コンテキストで作成され、呼び出しシーケンス全体を通じて安定しています。確立されたHTTP接続は接続ID（A1）を取得します。
次のシステムコールでは、ルートコンテキストIDのみが転送されます。クライアントは新しいHTTPリクエストをサーバーに送信します。クライアントとサーバー間で新しく確立された接続は、接続ID（B1）を取得します。接続カウンタはに設定されています1。クライアントがサーバーからの応答を受信した後、接続は閉じられます。次のHTTPリクエストが送信されると、新しい接続ID（B2）を持つ新しい接続が確立されます。接続カウンタの値は増加しません。
EPPによるトレース
EPPを送信することによって提供される情報は、次のようないくつかの監視および統計ツールでのフィルタリングに使用されます。
-
システムログ（SM21）
-
ダンプ分析（ST22）
-
ABAP統計レコード（STAD、STATS、STADWD）
-
ワークロードモニター（ST03）
EPP処理
ABAPシステム間の通信では、EPPがデフォルトで実装されています。他のすべてのシステムでは、EPP機能を有効にする必要があります。
EPPの使用方法の詳細については、拡張パスポートの使用を参照してください。
