N Oracle FormsおよびOracle E-Business Suiteのサポート
この付録では、Oracle E-Business Suite(EBS)およびOracle Formsベースのアプリケーションの正確な監視のために提供されるサポートについて詳しく説明します。 詳細は、オラクル社の担当者に問い合せてください。
モニタリングの有効範囲の確認
多くの場合、EBSソフトウェアは標準以外のポート(8000など)を使用するように構成されます。 EBSインストールが実行しているポートを確認するには、ログインURLを調べてください。 これは次の形式になっています。
https(s)://hostname
:portnumber
/OA_HTML/AppsLogin
定義されたポートのいずれかとしてportnumber
が構成されていることを確認します(これらについては後述します)。 また、HTTPSポートが指定される場合は、WebサーバーのSSL秘密キーのコピーをコレクタ・システムにインポートするようにしてください。 ポート番号を検証するには、「ネットワーク・ベースのモニタリングの有効範囲の管理」で説明されている手順に従います。
EBSスイート定義の作成
EBSベースのアプリケーションのスイート定義を作成できます。作成方法は、サポートされている他のOracle Enterpriseアーキテクチャの場合と同じです。 スイートの作成手順については、「スイートの使用」で説明します。
Formsを使用するEBSスイートの場合は、「拡張」セクションを選択し、その他タブをクリックすることに注意します。 スイートの概要が、図N-1に示されるように変わります。
図N-1 拡張スイート構成セクション

「図N-1 拡張スイート構成セクション」の説明
これらの設定の使用方法は次の項に記載されています。
APM統合の有効化
Oracle Cloud InfrastructureにAPMサービスが構成されている場合、次の手順を使用して、フォーム詳細を送信するようにRUEIを構成します。 APMでのOracle EBSのトレースの詳細は、「Oracle E-Business Suiteのトレースの構成」を参照してください。
次の前提条件があります:
- RUEIで構成されたEBSスイート名
- プライベート・データ・キーを含む完全なAPMデータ・アップロードURL
RUEI_USERユーザーとして次のコマンドを実行します:
$ execsql config_set_match_http_api "<EBS suite name>" apm "<APM data upload URL>" $ execsql config_set_match_http_api_filter "<EBS suite name>" apm EBS_FRAMEWORK == form-based
トラッキング・テクノロジの指定
RUEIではセッション情報はCookieに基づいています。 Cookieは、ヒットを特定のアクセスに結び付けるために使用されます。 一般的にCookieはユーザー・ログイン・ページにも結び付けられるため、RUEIは同じCookieを持つ後続のすべてのヒットにユーザー名を含めることができます。
セッション・トラッキング、相関変数およびセッションURL引数
相関変数とセッションURL引数に関して指定する必要がある追跡メカニズムは、いくつかのフロー・チャートを使用して決定することをお薦めします。
Formsセッション・パラメータ
フォームURLは、フォーム・セッションごとに一意の値を提供する引数について調べる必要があります。 通常、この引数はURLでセミコロンまたは疑問符の後にあります。 たとえば、jsessionid
またはJServSessionIdforms
です。 指定したパラメータがURLで見つからない場合、Cookieが検索されます。
相関変数
相関変数を使用すると、セッションを1つのエンドユーザー・セッションにマージできます。
アクション、ページおよびオブジェクト
各EBSフレームワークを分析して、すべてのヒットがオブジェクト・ヒットまたは、アクション・ヒットおよびページ・ヒットとして分類されるように正しい構成を得る必要があります。 フレームワーク固有の考慮事項を次に示します。
OA
OAフレームワークは、M-V-C(Model-View-Controller)モデルを使用して構築されます。 コントローラはHTTPレベルで確認できる部分であるため、RUEIに関連するのはコントローラのみです。 コントローラは、特定のページを表示するか、またはそのページを構築する別の場所にビジターをリダイレクトするかを内部的に決定します。 リダイレクトはRUEIの標準機能であり、自動的に認識されます。
URLパラメータに基づいてページ名が定義されます(リダイレクトの場合は、前のページのパラメータを含む元のURLではなく、リダイレクト先URLのURLを使用する必要があります)。 コントローラの他に、このフレームワークには固定URL(OALogout.jsp
のようなコントローラをバイパスする)も含まれます。 このようなファイルはJTTベース・ファイルと一緒に認識されます。
JTT
JTTフレームワークは、M-V-C(Model-View-Controller)モデルを使用して構築されます。 すべてのアプリケーションに1つのコントローラがあるのではなく、アプリケーションごとに1つ(または複数)のコントローラがある点で、OAフレームワーク定義とは異なります。 つまり、関連する.jsp
ファイルの数が多く、関連するすべての.jsp
ファイルの調査が必要になります。 .jsp
ファイルをサーバー側で分析すると、アプリケーション定義の判別が可能です(.jsp
ファイルの場所に基づいて)。
機能エラー
デフォルトのRUEIインストールでは様々なタイプのエラーが認識されます。「コンテンツ・メッセージの翻訳の定義」を参照してください。 これらはネットワーク・エラーおよびHTTPエラーです。 また、事前定義済のコンテンツ・メッセージがすべての標準FRMおよびメッセージ・ディクショナリ・アイテム(つまり、接頭辞「APP_」を使用したメッセージ)に自動的に提供されます。 デフォルトでは、タイプ「エラー」のメッセージのみがエラーとしてレポートされ、他のすべてのメッセージ・タイプ(「ノート」や「ヒント」など)が通知としてレポートされます。 Oracle Formsトラフィックの場合、個々のforms要素交換ですべての読取可能テキスト文字列から指定のコンテンツ・メッセージが検索されます。
運用上の理由で、メッセージID(APP-FND-01702など)が正規化されます(つまり、先頭のゼロが無視されます)。 文字列の比較を実行する場合、このことを考慮する必要があります。
Oracle Formsエラーの原因
Formsセッション中に発生するエラーは、様々なレイヤーが原因となっている可能性があります。
-
ネットワーク・エラーは、すべてのアプリケーションと同じ方法でRUEIでレポートされます。
-
HTTPサーバー・エラー(500、404など)は、すべてのアプリケーションと同じ方法でRUEIでレポートされます。
-
Formsサーブレット・エラー(サーブレット接続エラー)は、対応する
ifError
コードと一緒にレポートされます。 これは、Formsフレームワークで発生する内部通信エラーです。
フォーム名レポート
デフォルトでは、レポートされるForms名は、構成スクリプトでアップロードされたマッピングに基づいて、Formsウィンドウ・タイルから導出されます。 ただし、環境変数FORMS_RUEI_SEND_FORM_NAME
が設定されている場合、Formsサーバーは、ウィンドウ作成メッセージとともにFormsモジュール名を送信します。 デフォルトでは、環境情報がdefault.env
ファイルに設定されます。 別のファイル名を使用できますが、これをformsweb.cfg
ファイルに指定する必要があります。 これにより、同じウィンドウ・タイトルを持つトラフィック内の複数のForms名を区別できます。
OAフレームワーク・ページ名控除
OAベースのトラフィックは次のようにRUEIにマッピングされます。
-
コントローラは、ユーザーが開始するアクションのキー・インジケータとして使用されます。 コントローラに密接に関連するヒットは、そのページの構成要素と仮定されます。 OAフレームワークには、
OA.jsp
とRF.jsp
という2つのコントローラがあります。 -
ページの名前は、コントローラに送られるパラメータに基づいて付けられます。 function_id、_rc、akRegionCode、OAFunc、pageおよびregionというパラメータが考慮されます。 (新しい)フォームまたは職責への参照を含まないページは、前のページのフォーム名または職責を保ちます。
ページ内容
すべてのアクションがページに関連するとは限りません。 このため、この項ではアクション(HTTPリクエストなど)がどのようにページ・ビューとしてレポートされるかを説明します。
ページについてのリクエストが受信されるたびに、OAフレームワークはOAPageContextを作成します。これは新しいページの処理が完了するまで存続します。 特に、OAPageBean(ページ処理の中心機能)によってOAPageContextが作成されます。
RUEIでのレポートは、HTTPレベルで表示されるリクエストに基づきます。 ページが1つのリクエスト内で変化する場合、計測された時間は元のページに対してレポートされます。
データ項目
「表N-1」に示すEBS固有のデータ・アイテムは、RUEIによってレポートされます。
表N-1 EBS固有のデータ・アイテム
項目 | 説明 |
---|---|
1ページ当たりのデータベース時間(ミリ秒) |
1ページ当たりのデータベース時間。 これは、Chronosまたは「エンド・ユーザーの監視」が有効になっている場合のみ使用できます。 |
合計Database時間(ミリ秒) |
合計データベース処理時間 |
EBSアクション |
ユーザーによって実行されたアクションの説明(これは、フレームワークに基づいて決定されます) |
EBSコンポーネント |
アクティブ・コンポーネントの説明(このフレームワークで決定できる場合) |
EBSフォーム階層 |
測定されたアクティビティ中にOracle Formsプロトコル内でアクティブだった要素のコンポーネント階層。 |
EBSフォーム・メッセージ |
Oracle Formsメッセージの開始/終了を示す特定のプログラムされたメッセージに関連する情報。 |
EBSフォーム名 |
アクティビティに関連するOracle Formsの名前。 |
EBSフォーム名の説明 |
アクティブだったOracle Forms名の説明。 |
EBSフレームワーク |
使用されるEBSフレームワーク。 たとえば、FORMS (Oracle Forms traffic)、OA (Oracle Applicationフレームワーク)、JTT (JTTフレームワーク)、servlet (サーブレット)、other-traffic (未分類ページ設定が選択されている場合にのみ表示されます。実際のURLを表示するにはpage-URLを使用します)です。 |
EBS JSPファイル名 |
使用されるJSPベース・ファイルの名前。 たとえば、ログインイベントまたはrunformsなどのアクションが含まれることがあります。 |
EBS Javaクラス |
ユーザー・アクティビティに対してアクティブだったコンポーネントのクラス名。 |
EBSモジュール |
エンド・ユーザーがナビゲートしていた場所のEBSモジュール。 |
EBSモジュール・コード |
エンド・ユーザーがナビゲートしていた場所のEBSモジュール。 |
EBS職責 |
アクティビティ中にアクティブだった職責。 |
EBS職責ID |
アクティビティ中にアクティブだった職責ID。 |
EBSユーザー入力 |
識別できる場合、アクティビティ中にユーザーが入力したリテラル・テキスト。 |
既知の制限事項
現在、RUEIはEBSのすべての機能には対応していません。 特に次の制約事項がすでに判明しています。
-
Formsフレームワークにはレポートを作成する機能が含まれます。 この機能ではユーザーが高度な構成を行うことができます。 結果として、レポートを自動的に追跡することができません。 また、レポートのために関連するビジネス指向名が含まれる便利な変換用の表もありません。 解決方法としては、判明しているレポートURLを変換ファイルに基づいて正しいレポート名に記述し直すことしかできません。
この問題に関する補足情報ですが、一部のユーザーがjobs機能を使用してレポートを作成していることに注意してください。 この方法は安全ではありません。前後の番号を簡単に推測できるため、権限を持たないユーザーがレポートを表示できる可能性があるためです。 名前(数字のみ)がランダムであるため、このようなタイプのレポートの使用時にレポートに関するレポートを生成しても役に立ちません。
ここで説明した問題のために、Formsのレポートは監視されません。
-
レポートは、最後にアクティブになった部分に基づいて行われます。 したがって、1人のエンドユーザーが複数のブラウザ・ウィンドウで同時に参照しているとき、レポートされるページ名には正しくない情報が含まれることがあります。
-
現在、OAおよびJTTフレームワークに基づくアプリケーションしかサポートされません。 このため、Oracle Applications Manager(OAM)やOracle Portalのようなパッケージは現時点ではサポートされていません。
-
リッチ・インターネット・アプリケーション(RIA)・フレームワーク(Ajaxなど)を使用するアプリケーションは、再生機能が低下する場合があります。 これは、Oracle Formsベース・アプリケーションの場合に特に見られます。
EBSアプリケーションのトラブルシューティング
この項では、EBSアプリケーションを監視するときに特によく発生する問題について説明します。 カスタマ・サポートに問い合せる前に、この項の内容を確認してください。
測定されないネットワーク・トラフィック
予期されるネットワーク・トラフィックがレポートされないように見える場合は、次の点を確認することをお薦めします。
-
RUEIが、OA、JTT、PLS、Oracle Formsおよびサーブレット・フレームワークに基づくEBSアプリケーションを監視できること。 一般的に、スイートはインストールごとに異なる特定のポートで実行するように構成されます。 これもRUEIに指定する必要があります。 「構成」→「セキュリティ」→「プロトコル」を選択します。 定義されたポート設定を確認し、EBSアプリケーションの要件を満たすようにします。
-
EBSには、追加設定せずにセッション・トラッキングのために使用可能なCookieはないことに注意してください。 したがって、Cookieはログイン・ページで作成される必要があります。 このCookieがアプリケーション全体に対応します。 デフォルトでは、
Jession
Cookieはアプリケーション・リンクのみに対応し、イメージ、CGIおよびライブラリには対応しません。oracle.uix
Cookieはすべてのヒットに対応しますが、ビジターごとに一意ではありません。
多数の不明なアクションがレポートされます
レポートされるトラフィックの大部分を識別されないアクションが占める場合、Formsの追跡が正常に機能していません。 次の項目に注意する必要があります。
-
"Status Bar"や"Textfield"などが表示されない場合は、監視対象トラフィックの特定の特性が取得されていないことを示します。 この場合は、カスタマ・サポートに問い合せてください。
-
「モニタリングの有効範囲の確認」の説明に従って、サーバー・ポートが正しく構成されていることを確認します。 特に、これは通常のHTTPポートとしてではなく、Formsサーブレット・モード・ポートとして構成されている必要があります。
フォームのみの環境でのユーザーId認識の構成
formsプロトコルは通常のhttpトラフィック(RUEIのネイティブ)と同じではないため、formsのみの環境にuser-idソースを構成する場合は多少の知識が必要になります。 この項では、このような環境でuser-idを構成する方法について説明します。
使用できるソースのタイプは2種類で、これらがクライアント・リクエストとして構成されている必要があります。
-
Oracle Formsクライアント要素
formsの階層構造によって送信されるforms要素内の値です。
-
Oracle Formsクライアント・プロパティ
user-idが含まれる、一意の名前を持つプロパティ。