| Oracle® Real User Experience Insightユーザーズ・ガイド 12c リリース6 (12.1.0.7) for Linux x86-64 E61771-02 |
|
 前 |
 次 |
| Oracle® Real User Experience Insightユーザーズ・ガイド 12c リリース6 (12.1.0.7) for Linux x86-64 E61771-02 |
|
前 |
次 |
この章では、スイートを使用して特定のOracle Enterpriseアーキテクチャ(Oracle E-Business Suite、Siebel、WebLogic Portalなど)を拡張監視する方法について説明します。また、Webサービスの監視についても説明します。
前述のように、RUEIにおけるページ識別は、アプリケーションに基づいて行われます。ただし、アプリケーションが特定のOracle Enterpriseアーキテクチャ(Oracle E-Business Suite、Siebel、WebLogic Portalなど)に基づいている場合、スイートという第4のレベルが導入されます。スイートとは一般にアプリケーションの集合であり、スイートに関連付けられているWebページは、スイート » アプリケーション » グループ » ページという構造を持ちます。
重要:
現在サポートされているOracle Enterpriseアーキテクチャのいずれかを監視対象の環境で使用している場合は、この機能を使用することを強くお薦めします。この機能を使用すると、アプリケーション定義にかかる時間が短縮され、スイート内のアプリケーションの互換性が高くなるのみでなく、これらのアーキテクチャが正しく監視されるようにもなります。
スイートのインスタンスを定義する手順は、次のとおりです。
「構成」→「アプリケーション」の順に選択して、図10-1に示すメニュー構造から「スイート」を選択します。
「新規スイート」をクリックします。図10-2に示すダイアログが表示されます。
スイートの名前を指定します。この名前は、スイート、サービス、SSOプロファイルおよびアプリケーションを通じて一意である必要があります。スイート・インスタンスの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、スイートの有効範囲を指定します。有効範囲はページURLの部分として定義されます。これらのフィルタ基準の使用方法は、8.3項「アプリケーションの定義」に記載されているものと同じです。この情報を入力すると同時に、入力した定義が「フィルタのプレビュー」列に表示されます。空白フィルタは使用できません。ワイルドカード文字(*)は「ポートの検索」フィールドには指定できません。標準以外のポート(つまりポート80/443)に着信するネットワーク・トラフィックには、スイート・インスタンスは関連付けられないことに注意してください。明示的に指定できるポート番号は1つのみです。さらに必要な場合は、追加フィルタとして構成する必要があります。ワイルドカード文字を指定して、ドメイン名とURL引数の組合せによるその他の情報を指定しないことはできません。次に、「次へ」をクリックします。図10-3に示すダイアログが表示されます。
|
注意: スイート、SSOプロファイル、アプリケーションおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。相互に排他的でないフィルタ定義を使用すると、予期しない結果が生じることがあります。フィルタの適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。 |
このダイアログでは、スイートのベースとなるOracle Enterpriseアーキテクチャを指定できます。次に、「終了」をクリックします。指定したスイート定義が表示されます。例を図10-4に示します。
この概要には、定義したスイートのサマリーが示されます。これには、定義したページ識別フィルタ、これまでに表示されたページ数の合計(0:00現在日以降)、検出および記録が必要な関数エラー(存在する場合)、およびビジター・セッションの追跡にスイート内で使用されるユーザー識別メカニズムが含まれます。これらはすべて、必要に応じて個別に変更できます。手順は、8.3項「アプリケーションの定義」に記載されているものと同じです。
デフォルトでは、スイートはネットワーク・ベースのデータ収集を使用するように定義されています。WebCenter Sitesの場合のみ、タグ・ベースのデータ収集を使用できます。これは、図10-4に示すスイート定義画面で有効にできます。
タグ・ベースのデータ収集を有効にした場合、8.3.1項「ブラウザJSライブラリ設定の定義」の説明に従ってブラウザJSライブラリを定義する必要があります。タグ・ベースおよびネットワーク・ベースの監視の設定の詳細は、RUEIインストレーション・ガイドの「RUEIソフトウェアのインストール」を参照してください。
特定のOracleアーキテクチャの本番環境に基づいたトラフィックの監視時に使用するために提供された適切なスクリプトを実行することを強くお薦めします。たとえば、create_EBS_info.plスクリプトなどです。この目的は、実際の環境でこれらのアーキテクチャが実装された方法を特定することです。特に重要なのは、ページ・ネーミング・スキームです。次を実行します。
選択したスイートに付属の適切なスクリプトをダウンロードします。この機能の使用方法の詳細は、対応する付録を参照してください。
スクリプトをデプロイメント環境で実行します。このスクリプトにより、環境内でページIDにIDが割り当てられます。スクリプトを実行するディレクトリ内に、多数の.txtファイルが作成されます。
生成された.txtファイルから.zipファイルを作成し、RUEIレポータ・システムへのファイルのアップロードに使用可能な場所に、この.zipファイルをコピーします。
「構成」→「アプリケーション」→「スイート」の順に選択して、該当するスイートを選択します。スイートの概要が表示されます。「構成のアップロード」コマンド・ボタンをクリックします。図10-5に示すダイアログが表示されます。
スクリプトで生成されたファイルの名前を指定します。目的のファイルを検索するための「参照」ボタンが使用可能です。ファイルは.zipファイルである必要があります。次に、「アップロード」をクリックします。
|
重要: この構成ファイルを、目的の各スイート・インスタンス用にアップロードする必要があります。構成ファイルには、既知の(および空でない).txtファイルのみを含めることができます。これらのファイルはすべてルート・ディレクトリに存在する必要があります。つまり、サブディレクトリは許可されていません。実際の本番環境に基づいた適切な構成ファイルを目的のスイート・インスタンス用にアップロードする必要があります。監視対象のアプリケーションを変更する場合、スクリプトを再実行して、生成された.zipファイルを再インポートする必要があります。エラーの多い構成ファイルのインポート結果は、正しくないレポートになります。 |
前述のように、スイートとは一般にアプリケーションの集合です。スイートの定義後にそのプロパティを変更するには、8.3項「アプリケーションの定義」でアプリケーションに関して記載されているのと同じ方法を使用します。
次の点に特に注意してください。
スイートでクリックアウト機能を使用するためには、スイート・インスタンスのエンタープライズ名を正しく指定する必要があります(4.6項「外部ツールへのクリックアウトの構成」を参照)。これは、EMGCでのスイートの構成から取得できます。たとえば、ec2ebs2-Oracle E-Business Suite、siebel_emgc-amp11.oracle.comのように指定します。
スイート固有のデフォルトの関数エラーが多数定義されています。これを確認して、実際の環境の要件に合うようにしてください。手順は、8.3.13項「アプリケーション・コンテンツ・メッセージのトラップ」に記載されているものと同じです。
デフォルトでは、未分類のページはレポートされません。これを変更するには、「未分類のページのレポート」チェック・ボックスを選択します。手順は、8.3.6項「未分類のページのレポート作成」に記載されているものと同じです。
「サービス・テスト・トラフィックのレポート」チェック・ボックスを使用して、選択したスイートのためにOracle Enterprise Managerで構成されているサービス・テスト・トラフィックをRUEIでレポートするかどうかを指定できます。デフォルトでは、レポートは行われません。この機能の使用方法の詳細は、8.6項「サービス・テスト・トラフィックのレポート」に記載されています。監視対象のサービス・テストはRUEIユーザー・フローにも変換できることに注意してください。この機能は、9.8項「サービス・テスト・セッションのユーザー・フローへの変換」に記載されています。
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはIPパケットからフェッチされます。ただし、RUEIシステムをNATデバイスの前に配置する場合には、特定のヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。この詳細は、付録Q「NATトラフィックの監視」に記載されています。
スイートごとに、デフォルトのユーザー識別スキームが定義されています。これを確認して、実際の環境の要件に合うようにしてください。手順は、8.3.14項「ユーザー識別の定義」に記載されているものと同じです。
スイート診断グループ(3.2.5項「問題分析のためのスイートURL診断」を参照)を使用すると、スイートのヒットについてレポートされた機能URLを表示できます。この機能の使用方法は、アプリケーションの場合と同じです(8.3.21項「問題分析グループ内のレポートの制御」を参照)。
スイート全体のページを識別できるのみでなく、ページを手動で定義することもできます。手順は、8.3.20項「ページの手動識別」に記載されているものと同じです。ただし、新規ページを最初から定義することはできません。既存のページを新規ページのベースとして使用する必要があります。
Oracle Enterpriseアーキテクチャ・ベースのアプリケーションについてRUEIで収集およびレポートされるデータの品質を保証するために、レポートされる詳細を検証することを強くお薦めします。定義済スイートについて検出される関連ページの数に特に注意する必要があります。
「データの参照」→「すべてのページ」グループ→「アプリケーション」サブグループの順に選択します。ページ・ビューやヒットなど個々のディメンションにおいて、ページ・ビューがいくつかのアプリケーションについてレポートされているのを確認できます。ディメンションのスイート名は、カッコ内に表示されます。WLPストリーミング・ポータルの例を図10-6に示します。
10.1項「スイートの使用」ですでに説明しているように、RUEIは、特定のOracle Enterpriseアーキテクチャ(SiebelやOracle E-Business Suiteなど)の監視の専用サポートを提供します。これは、各アーキテクチャが基礎となる標準のフレームワークに基づいて異なるためです。しかし、カスタマイズしたバージョンのアーキテクチャ・フレームワークを使用してアプリケーションを開発した場合、そのネットワーク・トラフィックを正確に監視してレポートするために、RUEIでは変更点に関する情報が必要になります。これは、アーキテクチャ・フレームワークがレガシー・アプリケーションのラッパーとして使用された場合でも同様です。アプリケーション開発者は、フレームワーク例外の機能を使用して、RUEIの標準アーキテクチャでのレポート・スキームに対して必要な例外を指定することができます。この機能は、スイート以外のアプリケーションでも使用できます。
アプリケーションの基礎となるフレームワークを変更してカスタム・ページを追加した場合には、そのページが正しく識別されるように、手動でページを定義するのではなく(8.3.20項「ページの手動識別」を参照)、フレームワーク例外の機能を使用することを強くお薦めします。
アプリケーションのURLパターン
通常、アプリケーションは、ドメインによって識別されます。たとえば、myshop.comなどです。可能なホーム・ページを図10-7に示します。
各機能部は、URLパターンで識別されます。次に例を示します。
myshop.com/catalog: 使用できる項目のオンライン・カタログから項目を参照および注文する顧客の機能を含みます。これは、標準フレームワーク実装に基づきます。
myshop.com/user/preferences: 顧客がWebサイトの表示を変更してパーソナル・プリファレンスを反映できる機能を含みます。たとえば、言語、測定単位、通貨などです。これは、カスタマイズされたフレームワーク実装に基づきます。
myshop.com/shop/checkout: 顧客の注文を確認して支払いを手配できる機能を含みます。これは、カスタマイズされた請求実装に基づきます。
この場合、正しいレポートを確認するため、アプリケーションのuser/preferencesおよびshop/checkout部に行われたカスタマイズの情報が提供される必要があります。catalog部は標準フレームワークに基づいているため、詳細情報を指定する必要がありません。
フレームワーク例外の指定
アプリケーションに対して使用されるフレームワーク例外を定義するには、次の手順を実行します。
「構成」→「アプリケーション」→「フレームワーク例外」の順に選択します。「新規フレームワーク例外」項目をクリックします。図10-8に示すダイアログが表示されます。
フレームワーク例外の一意の名前を指定します。フレームワーク例外をすべてのアプリケーション定義に適用する場合には「汎用」、特定のOracle Enterpriseアーキテクチャに適用する場合には「スイート」を選択してください。後者の場合は、アーキテクチャを指定する必要があります。少なくとも1つのスイート・インスタンスが定義されている場合、スイートが「スイート・タイプ」メニューにのみ表示されます。オプションで、短い説明を指定します。定義する例外の目的と範囲に関する説明を含めることをお薦めします。次に、「保存」をクリックします。
新規作成したフレームワーク例外をクリックします。図10-9に示すような概要が表示されます。
「識別」タブをクリックし、「新しいURLパターンの追加」アイテムをクリックします。これにより、フレームワーク例外の範囲が指定されます。1つ以上のパターンを入力し、アプリケーションの構造を反映させます。パターンはスラッシュ("/")またはワイルドカード("*")で始める必要があります。そうしないと、URLと一致しません。ワイルドカードを必要に応じて使用して、ディレクトリにつながるパスに関係なく、特定のURLパターンのすべてのサブディレクトリを含めるか、特定のサブディレクトリのみを指定します。たとえば、*/preferences/*は、次のような深いパスを含め、"preferences"を含む任意のパスと一致します。
www.myshop.com/preferences
www.myshop.com/user/preferences
www.myshop.com/another/location/preferences/subdir/subdir/
ただし、ワイルドカードのないパスは、正確なURLとのみ一致します。たとえば、/shop/checkoutは、/shop/checkout/payments/とは一致しません。
また、パス内のURL引数は考慮されないため、同じパス(URL引数を持つものと持たないもの)は同じとみなされます。
ページ/オブジェクト条件タブをクリックします。「新規条件の追加」項目をクリックします。図10-10に示すダイアログが表示されます。
「ヒット・タイプ」メニューを使用して、検出されたヒットの処理方法を指定します。表10-1に、使用可能なオプションを示します。
表10-1 「ヒット・タイプ」オプション
| ヒット・タイプ | ページ名脚注1 | ロード時間脚注2 | コンテンツ・エラー脚注3 | プレビュー脚注4 |
|---|---|---|---|---|
|
ページ |
X |
X |
X |
X |
|
オブジェクト |
- |
X |
- |
- |
|
リダイレクト |
- |
X |
- |
- |
|
ハートビート |
- |
- |
- |
- |
脚注1 レポートされるページ名は、ヒットから取得されます。
脚注2 ページ・ロード時間を決定する際にヒットが考慮されます。
脚注3 コンテンツ・エラーについてヒットがスキャンされます。
脚注4 「セッション診断」機能でプレビューに使用されます。
例外が適用されるために満たされる必要があるイベントを指定します。イベントごとに、「ディメンション・レベル」および「値」メニューを使用して、チェックされるディメンションと保持する必要がある値を選択します。目的の値が「値」メニューにない場合は、横にある「検索」アイコンをクリックして探すことができます。
必要に応じて、「除外」チェック・ボックスを使用すると、定義したディメンション・レベル=値ペアを除外するように適用します。つまり、定義したイベントが満たされない場合に、イベントが達成されたとみなされます。次に、「追加」をクリックします。例外が適用されるためには定義された1つの条件のみを達成する必要がありますが、条件が満たされたとみなされるためには条件内のすべてのイベントが達成される必要があります。次に、「保存」をクリックします。図10-9に示したダイアログに戻ります。
「ディメンション定義」タブをクリックします。選択したアプリケーション・タイプに固有のディメンションが表示されます。例を図10-11に示します。
デフォルト・ソースを変更したいディメンションをクリックします。「ソース・タイプ」と「ソース値」のフィールドを使用して、選択したディメンションのレポート値を導出する方法を指定します。図10-12を参照してください。
オプションで「置換値」フィールドを使用すると、取得した値に適用する変換を指定できます。表10-2に、使用可能なオプションを示します。次に、「保存」をクリックします。
表10-2 識別オプション
| オプション | 説明 |
|---|---|
|
URL引数 |
ディメンション値は、指定したURL引数から導出する必要があります。 |
|
リクエストのXPath |
ディメンション値は、リクエストに適用されるXPath式から導出する必要があります。 |
|
JSONリクエストのXPath |
ディメンション値は、JSONリクエストに適用されるXPath式から導出する必要があります。 |
|
リクエストのヘッダー |
ディメンション値は、指定したリクエスト・ヘッダーから導出する必要があります。 |
|
レスポンスのXPath |
ディメンション値は、レスポンスに適用されるXPath式から導出する必要があります。 |
|
JSONレスポンスのXPath |
ディメンション値は、JSONレスポンスに適用されるXPath式から導出する必要があります。 |
|
レスポンスのヘッダー |
ディメンション値は、指定したレスポンス・ヘッダーから導出する必要があります。 |
|
Cookie |
ディメンション値は、指定したCookie要素から導出する必要があります。 |
|
カスタム・タグ |
ディメンション値は、指定したカスタム・タグから導出する必要があります。 |
|
カスタム関数 |
ディメンション値は、指定したカスタム関数から導出する必要があります。最初のパラメータのみが使用され、単一引用符または二重引用符で囲む必要があります。次に例を示します。
wiViewState("wi_menu_main_menu");
|
|
リテラル値 |
ディメンション値を指定したリテラル値に設定する必要があります。 |
|
HTMLタイトル |
ディメンション値は、ページの<title>タグ内で見つかったテキストから導出する必要があります。 |
|
URL |
ディメンション値は、ビジターのブラウザのロケーション・バーに表示される完全なドメインとURLから導出する必要があります。 |
|
URLベース |
ディメンション値は、URLのメイン・ディレクトリとファイル名(ファイル拡張子は除く)の部分から導出する必要があります。 |
|
URLディレクトリ |
ディメンション値は、URLのディレクトリ部から導出する必要があります。 |
|
URL全体 |
ディメンション値は、URLのメイン・ディレクトリ、ファイル名(ファイル拡張子は除く)および構成済の引数から導出する必要があります。 |
ルーリング機能を作成すると、それを使用して、新規作成する定義を調整する追加の一致ルールを指定できます。この詳細は、8.3.5項「規則指定機能の使用方法」に記載されています。
デフォルトでは、個々のURLパターンが評価される順序は、URLパターンがシステムで定義されている順序になります。つまり、新しく定義する各URLパターンは、パターン評価チェーンの末尾に配置されます。処理中に、RUEIはURLを、この順序で使用可能なパターンと照合しようとします。
1つ以上のURLパターンの評価優先度の変更が必要になる場合があります。たとえば、パターンが高レベルの詳細を含んでいるため、特定のURL (/shop/checkout/payment-failed.jspなど)に絞り込む場合、/shop/*などのより汎用的な式より前に評価する必要があります。
RUEIは、URLパターンの評価優先度の管理機能を提供します。フレームワーク例外の概要画面で、ツールバーの「フレームワーク例外の優先度の編集」ボタンをクリックします。
次のダイアログが表示されます。
このダイアログでは、フレームワーク例外のすべてのURLパターンの概要が、評価される順序で表示されます(チェーンの上にあるパターンは、下にあるパターンより先に評価されます)。
1列目にはURLパターンが含まれています。2列目には、このパターンが定義されているフレームワーク例外が表示されます。3列目には、フレームワーク例外のタイプ(これはフレームワーク例外の作成時に指定したタイプ)が表示されます。4列目は、フレームワーク例外が現在有効であるかどうかを示します。(一致優先度チェーン内の位置に関係なく、無効なフレームワーク例外のURLパターンは、URL一致時にスキップされます。)
最終列には、チェーン内でパターンを上下に動かせるコントロールが含まれています。上向き矢印をクリックすると、現在のURLパターンは1行上昇し、一致優先度が高くなります。下向き矢印をクリックすると、現在のURLパターンは1行下降し、一致優先度が下がります。変更はすぐに有効になります。
終了したら、「閉じる」ボタンをクリックします。
フレームワーク例外は、アプリケーション自体と同時に作成することをお薦めします。そのためには、開発中のアプリケーションをRUEIで開始し、そこで定義されている例外を取得した結果に基づいて微調整するのが最も確実です。
デプロイの準備ができると、アプリケーションは本番環境に移動されます。その新しい環境が別のRUEIインストールによって監視される場合でも、アプリケーションの例外ルールを手動で再作成する必要はありません。そのかわりに、ダウンロード機能を使用してその最新定義を取得し、生成されたファイルをアップロードして新しいRUEIインストールで使用することができます。
この機能は、複数の環境間でアプリケーションをデプロイするときに特に便利です。たとえば、エクストラネット・ベースのアプリケーションをビジネス・パートナーが使用するように提供する場合などです。
|
重要: 生成されるフレームワークは独自のフォーマットなので、どんな場合でも変更しないでください。 |
フレームワーク例外定義のダウンロード
定義済のフレームワーク例外をダウンロードするには、次の手順を実行します。
「構成」→「アプリケーション」→「フレームワーク例外」の順に選択します。「フレームワーク例外のダウンロード」コマンド・ボタンをクリックします。現在定義されているフレームワーク例外を示すウィンドウが開きます。例を図10-15に示します。
必要なフレームワーク例外を選択します。準備ができたら、「ダウンロード」をクリックします。
ブラウザの構成方法によって異なりますが、zipファイルの保存場所の指定を求められるか、定義済のデフォルトの場所にファイルがすぐに保存されます。
フレームワーク例外定義のアップロード
フレームワーク例外定義をアップロードすると、この定義に含まれているURLパターンは、評価優先度チェーンの末尾に追加されます。したがって、定義をアップロードした後は、URLパターンの評価優先度を見直すことを強くお薦めします。フレームワーク例外定義がすでに存在する場合、URLパターンは、アップロードにあるURLパターンと置換されます。
|
注意: フレームワーク例外が最初にダウンロードされた後に追加または変更されたURLパターンは、このフレームワーク例外定義をアップロードすると削除されます。 |
置換済のすべてのパターンの場合、パターン一致優先度と、最後に使用されたときを示すカウンタの両方はリセットされます。したがって、パターンの置換は、レポート済の最終使用時の情報をリセットする場合の手法として使用できます。
アップロードを行った後は、URLパターン一致優先度の見直しおよび調整を行うことを忘れないでください。
Webサービスの出現は、IT産業における最も重要な進歩の1つです。各組織は、情報(たとえば注文書、在庫水準、出荷通知およびインターバンク取引など)を交換するためにエンタープライズ・アプリケーションの統合を進めています。
Webサービスの概要
ここでいう「Webサービス」とは新しい種類のサービスであり、それまで「Webサービス」と呼ばれてきたものとは区別する必要があります。通常、Webサービスは、Web上で使用可能な任意のサービスのことを指していました(たとえば検索エンジン、言語翻訳、天気ガイド、地図など)。ただし、このようなタイプのWebサービスには、人間によるなんらかの介入が必要でした。
WebサービスはW3C脚注1により、「ネットワーク上で相互作用できるマシンとマシンの対話をサポートするために設計されたソフトウェア・システム」と定義されています。Webサービスが実装するビジネス機能は明確に規定されており、他のサービスの状態に依存せずに稼働します。Webサービスには、その消費者との間で明確に規定された契約があります。サービス同士の接続は柔軟で、あるサービスが他のサービスと連動するためにその技術的な詳細を把握する必要はなく、すべての相互作用はインタフェースを介して行われます。サービス・プロバイダは、このテクノロジを使用して、Web上でサービスとともにインタフェースとサービスのネーミング仕様を単に公開して、接続を待機します。
サービスはサービスの説明で使用可能にします。それには、サービスのコール方法、およびサービスをリクエストしてレスポンスを得るために必要な情報を記述します。データ交換は、リクエスト/レスポンスのパターンを踏襲します。RUEIでは主としてXML-SOAPおよび同様のメッセージの監視がサポートされます。
Webサービス定義の作成
Webサービスを定義する手順は、次のとおりです。
「構成」→「サービス」の順に選択します。現時点で定義されているWebサービスがリストされます。「新規サービス」をクリックします。図10-16に示すダイアログが表示されます。
サービスの名前を指定します。定義されたサービスに対して、この名前がレポートおよびデータ・ブラウザ内で使用されます。この名前は、サービス、SSOプロファイル、スイートおよびアプリケーションを通じて一意である必要があります。サービスの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、サービスの有効範囲を指定します。有効範囲はサービスURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「フィルタのプレビュー」列に表示されます。
最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。サービス名を指定して他のすべてのフィールドを空白にすることはできません。ワイルドカード文字(*)は「ポートの検索」フィールドには指定できません。標準以外のポート(つまりポート80/443以外)に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、サービスは関連付けられないことに注意してください。「ポートの検索」フィールドには1つのポート番号しか指定できません。追加のポートを指定する必要がある場合は、新しいサービスが作成された後で追加のフィルタとして指定してください。
ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURL引数の組合せ情報を指定しないことはできません。
|
注意: サービス、SSOプロファイル、アプリケーションおよびスイート間でフィルタ定義を相互排他的にしておくことをお薦めします。たとえば、ドメインoracle.comでフィルタリングされるサービスを定義した状態で、oracle.com/application_servletでフィルタリングされる別のサービス、スイートまたはアプリケーションを定義しないでください。相互に排他的でないフィルタ定義を使用すると、予期しない結果が生じることがあります。フィルタの適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。 |
URLの部分の中に、一致対象とする引数を指定することもできます。この機能を使用する場合は、引数と引数名の両方を揃えて指定することで初めてページURLと一致することができることに注意してください。つまり、部分一致はサポートされていません。次に、「次へ」をクリックします。図10-17に示すダイアログが表示されます。
このダイアログを使用し、サービスを識別してレポートする方法を指定します。アプリケーション(8.3項「アプリケーションの定義」を参照)がアプリケーション » グループ » ページという構造で構成されているのに対して、サービスはサービス名 » 機能グループ » 機能名という構造で構成されていることを理解しておく必要があります。グループ・ネーミング・スキームを指定する場合、グループ・ネーミング・スキームがレポートされるためには、グループ・ネーミング・スキームが関数コール内にあることが必要です。
次に、「終了」をクリックします。指定したサービス定義の概要が表示されます。例を図10-18に示します。
サービス定義の微調整
サービスを定義した後で、関連する機能スキームを変更できます。「識別」セクションで、「新規フィルタの追加」をクリックして、サービスに関連付ける必要がある機能に追加のフィルタを指定できます。定義済フィルタのいずれかと一致する機能が、サービスに割り当てられます。また、既存のフィルタ定義を変更するには、それをクリックします。いずれの場合にも、図10-16に示したフィルタの中から選択できます。ユーザーによる追加または変更を反映するようにサービス概要が更新されます。
クライアントID識別スキームを定義する手順は、アプリケーションやスイートについての手順と同じです。8.3.14項「ユーザー識別の定義」に記載されています。
IPアドレス・ソースの指定
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはTCPパケットからフェッチされます。ただし、RUEIシステムをNATデバイスの前に配置する場合には、特定のヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。「拡張」セクション(図10-16)のクライアントIPソース・チェック・ボックスを使用して、目的のスキームを指定できます。この詳細は、付録Q「NATトラフィックの監視」に記載されています。
関数コールのうち、そのURL定義によりサービスに属していることが確認されているものの、関連する分類済の名前が見つからないものは、廃棄されレポートされません(デフォルト)。ただし、そのような未分類のコールをレポートする場合は、「関数」セクションの「未分類のコールのレポート」チェック・ボックスを使用します。
サービスに属していることが確認されていないヒットは未分類のコールとして識別されるため、定義が不正確または不十分な関数コールは未分類として識別されます。未分類のコールは、関連するデータ・ブラウザ・グループ内のカテゴリ「その他」にレポートされることに注意してください。
関数のレスポンス時間を評価するために、RUEIでは関数コールごとに満足度レベルが割り当てられます。これは、8.3.11項「ページ・ロードの満足度の指定」で説明するページ・ロードしきい値と等価です。
関数に関連付けられた文字列を検出する手順は、アプリケーションの場合の手順と同じです。8.3.13項「アプリケーション・コンテンツ・メッセージのトラップ」に記載されています。
脚注
脚注1: World Wide Web Consortium(W3C)は、World Wide Webの中心的な国際標準組織です。
