| Oracle® Real User Experience Insightユーザーズ・ガイド 13.3.1.0 for Linux x86-64 E98302-02 |
|
 前 |
 次 |
前述のように、RUEIにおけるページ識別は、アプリケーションに基づいて行われます。 ただし、アプリケーションが特定のOracle Enterpriseアーキテクチャ(Oracle E-Business Suite、Siebel、WebLogic Portalなど)に基づいている場合、スイートという第4のレベルが導入されます。 スイートとは一般にアプリケーションの集合であり、スイートに関連付けられているWebページは、スイート » アプリケーション » グループ » ページという構造を持ちます。
重要
現在サポートされているOracle Enterprise Architectureのいずれかを監視対象の環境で使用している場合は、この機能を使用することをお薦めします。 この機能を使用すると、アプリケーション定義にかかる時間が短縮され、スイート内のアプリケーションの互換性が高くなるのみでなく、これらのアーキテクチャが正しく監視されるようにもなります。
スイートのインスタンスを定義する手順は、次のとおりです。
図10-1 スイート
図10-2 新規スイート
これらのフィルタ基準の使用方法は、「アプリケーションの定義」で説明されているものと同じです。 この情報を入力すると、「フィルタ」 「プレビュー」列で定義が反映されます。 空白フィルタは使用できません。 「ポートの検索」フィールドにワイルドカード文字(*)を指定することはできず、標準以外のポート(つまりポート80/443)に着信するネットワーク・トラフィックはスイート・インスタンスに関連付けられません。 明示的に指定できるポート番号は1つのみです。 さらに必要な場合は、追加フィルタとして構成する必要があります。 ワイルドカード文字を指定して、ドメイン名とURL引数の組合せによるその他の情報を指定しないことはできません。
注意:
スイート、SSOプロファイル、アプリケーションおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。非固有のフィルタ定義を使用すると、予期しない結果になる場合があります。 詳細は、「RUEI内でのルール順序設定の制御」を参照してください。
注意:
アプリケーション、スイート、サービス、およびユーザーとクライアントのID識別のために構成されるURL引数は、エンコーディングなしで(%、&、=記号を除く)指定する必要があります。
一致対象とするURL GET引数を指定することもできます。 この機能を使用する場合は、引数名と引数値の両方を完成させて、検出されたページURLsと一致させる必要があります。 つまり、部分一致はサポートされていません。 準備ができたら、次へをクリックします。 図10-3に示すダイアログが表示されます。
図10-3 スイート・タイプ
図10-4 スイートの概要
デフォルトでは、スイートはネットワーク・ベースのデータ収集を使用するように定義されています。 WebCenter Sitesの場合のみ、タグ・ベースのデータ収集を使用できます。 これは、図10-4に示すスイート定義画面で有効にできます。
タグ・ベースのデータ収集を有効にする場合、「ブラウザJSライブラリ設定の定義」の説明に従ってブラウザJSライブラリを定義する必要があります。 タグおよびネットワーク・ベースのモニタリングの設定の詳細は、「RUEIインストレーション・ガイド」の「RUEIソフトウェアのインストール」を参照してください。
特定のOracleアーキテクチャの本番環境に基づいたトラフィックのモニタリング時に使用するために提供された適切なスクリプトを実行することをお薦めします。 たとえば、create_EBS_info.plスクリプトなどです。 この目的は、実際の環境でこれらのアーキテクチャが実装された方法を特定することです。 特に重要なのは、ページ・ネーミング・スキームです。 次を実行します。
図10-5 スイート構成のアップロード
注意:
この構成ファイルを、目的の各スイート・インスタンス用にアップロードする必要があります。 構成ファイルには、既知の(および空でない).txtファイルのみを含めることができます。 これらのファイルはすべてルート・ディレクトリに存在する必要があります。 つまり、サブディレクトリは許可されていません。 実際の本番環境に基づいた適切な構成ファイルを目的のスイート・インスタンス用にアップロードする必要があります。 監視対象のアプリケーションを変更する場合、スクリプトを再実行して、生成された.zipファイルを再インポートする必要があります。エラーの多い構成ファイルのインポート結果は、正しくないレポートになります。
前述のように、スイートとは一般にアプリケーションの集合です。 スイートを定義した後は、「アプリケーションの定義」のアプリケーションで説明されているのと同じ方法で、関連付けられたプロパティを変更できます。
次の点に特に注意してください。
スイートでクリック・アウト機能を使用するためには、スイート・インスタンス「企業名」を正しく指定する必要があります(「外部ツールへのクリック・アウトの構成」を参照)。 これは、EMGCでのスイートの構成から取得できます。 たとえば、ec2ebs2-Oracle E-Business Suite、siebel_emgc-amp11.oracle.comのように指定します。
スイート固有のデフォルトの関数エラーが多数定義されています。 これを確認して、実際の環境の要件に合うようにしてください。 手順は、「アプリケーション・コンテンツ・メッセージのトラップ」で説明しているものと同じです。
デフォルトでは、未分類のページはレポートされません。 これを変更するには、未分類のページのレポートチェック・ボックスを選択します。 手順は、「未分類のページのレポート作成」で説明しているものと同じです。
サービス・テスト・トラフィックのレポートチェック・ボックスを使用して、選択したスイートのためにOracle Enterprise Managerで構成されているサービス・テスト・トラフィックをRUEIでレポートするかどうかを指定できます。 デフォルトでは、レポートは行われません。 この機能の使用方法の詳細は、「サービス・テスト・トラフィックのレポート」を参照してください。 監視対象サービス・テストはRUEIユーザー・フローにも変換できます。 これについては、「サービス・テスト・セッションのユーザー・フローへの変換」で詳しく説明します。
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはIPパケットからフェッチされます。 ただし、RUEIシステムをNATデバイスの前に配置する場合には、特定のヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。 これについては、「NATed Trafficのモニタリング」で詳しく説明しています。
スイートごとに、デフォルトのユーザー識別スキームが定義されています。 これを確認して、実際の環境の要件に合うようにしてください。 手順は、「ユーザー識別の定義」で説明しているものと同じです。
スイート診断グループ(「問題分析のスイートURL診断」を参照)を使用すると、スイートのヒットについてレポートされた機能URLsを表示できます。 この機能の使用方法は、アプリケーションの場合と同じです(「問題分析グループ内のレポートの制御」を参照)。
スイート全体のページを識別できるのみでなく、ページを手動で定義することもできます。 手順は、「ページの手動識別」で説明しているものと同じです。 ただし、新規ページを最初から定義することはできません。 既存のページを新規ページのベースとして使用する必要があります。
Oracle Enterprise Architectベース・アプリケーションについてRUEIで収集およびレポートされるデータの品質を保証するために、レポートされる詳細を検証することをお薦めします。 定義済スイートについて検出される関連ページの数に特に注意する必要があります。
データの参照→すべてのページグループ→アプリケーションサブグループの順に選択します。 ページ・ビューやヒットなど個々のディメンションにおいて、ページ・ビューがいくつかのアプリケーションについてレポートされているのを確認できます。 ディメンションのスイート名は、カッコ内に表示されます。 WLPストリーミング・ポータルの例を図10-6に示します。
「スイートの使用」より前に説明したように、RUEIは特定のOracle Enterpriseアーキテクチャ(SiebelやOracle E-Business Suiteなど)のモニタリング専用サポートを提供します。 これは、各アーキテクチャが基礎となる標準のフレームワークに基づいて異なるためです。 しかし、カスタマイズしたバージョンのアーキテクチャ・フレームワークを使用してアプリケーションを開発した場合、そのネットワーク・トラフィックを正確に監視してレポートするために、RUEIでは変更点に関する情報が必要になります。 これは、アーキテクチャ・フレームワークがレガシー・アプリケーションのラッパーとして使用された場合でも同様です。 アプリケーション開発者は、フレームワーク例外の機能を使用して、RUEIの標準アーキテクチャでのレポート・スキームに対して必要な例外を指定することができます。 この機能は、スイート以外のアプリケーションでも使用できます。
アプリケーションの基礎となるフレームワークを変更してカスタム・ページを追加した場合には、そのページが正しく識別されるように、(「ページの手動識別」で説明されている)手動でページを定義するのではなく、フレームワーク例外の機能を使用することをお薦めします。
アプリケーションの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/*は、「プリファレンス」を含む任意のパス(次のような深いパスを含む)と一致します。
www.myshop.com/preferences
www.myshop.com/user/preferences
www.myshop.com/another/location/preferences/subdir/subdir/
ただし、ワイルドカードのないパスは完全一致のみに一致し、たとえば、/shop/checkoutは/shop/checkout/payments/とは一致しません。
また、パス内のURL引数は考慮されないため、同じパス(URL引数を持つものと持たないもの)は同じとみなされます。
「ページ/オブジェクト条件」タブで、「新規条件の追加」アイテムをクリックします。 図10-10に示すダイアログが表示されます。
ヒット・タイプメニューを使用して、検出されたヒットの処理方法を指定します。 表10-1に、使用可能なオプションを示します。
表10-1 ヒット・タイプオプション
| ヒット・タイプ | ページ名(1) | ロード時間(2) | Content error(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のメイン・ディレクトリ、ファイル名(ファイル拡張子は除く)および構成済の引数から導出する必要があります。 |
ルーリング機能を作成すると、それを使用して、新規作成する定義を調整する追加の一致ルールを指定できます。 これについては、「規則指定機能の使用方法」で説明しています。
デフォルトでは、個々の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 フレームワーク例外のダウンロードウィンドウ
例10-1 フレームワーク例外定義のアップロード
フレームワーク例外定義をアップロードすると、この定義に含まれているURLパターンは、評価優先度チェーンの末尾に追加されます。 したがって、定義をアップロードした後は、URLパターンの評価優先度を見直すことを強くお薦めします。 フレームワーク例外定義がすでに存在する場合、URLパターンは、アップロードにあるURLパターンと置換されます。
注意:
フレームワーク例外が最初にダウンロードされた後に追加または変更されたURLパターンは、このフレームワーク例外定義をアップロードすると削除されます。
置換済のすべてのパターンの場合、パターン一致優先度と、最後に使用されたときを示すカウンタの両方はリセットされます。 したがって、パターンの置換は、レポート済の最終使用時の情報をリセットする場合の手法として使用できます。
アップロードを行った後は、URLパターン一致優先度の見直しおよび調整を行うことを忘れないでください。
Webサービスの出現は、IT産業における最も重要な進歩の1つです。 各組織は、情報(たとえば注文書、在庫水準、出荷通知およびインターバンク取引など)を交換するためにエンタープライズ・アプリケーションの統合を進めています。
Webサービスの理解
ここでいうWebサービスとは新しい種類のサービスであり、それまでWebサービスと呼ばれてきたものとは区別する必要があります。 通常、Webサービスは、Web上で使用可能な任意のサービスのことを指していました(たとえば検索エンジン、言語翻訳、天気ガイド、地図など)。 ただし、このようなタイプのWebサービスには、人間によるなんらかの介入が必要でした。
Webサービスは、W3C 「脚注5」をネットワーク上で相互運用可能なマシンとマシンの相互作用をサポートするように設計されたソフトウェア・システムとして定義されます。 Webサービスが実装するビジネス機能は明確に規定されており、他のサービスの状態に依存せずに稼働します。 Webサービスには、その消費者との間で明確に規定された契約があります。 サービス同士の接続は柔軟で、あるサービスが他のサービスと連動するためにその技術的な詳細を把握する必要はなく、すべての相互作用はインタフェースを介して行われます。 サービス・プロバイダは、このテクノロジを使用して、Web上でサービスとともにインタフェースとサービスのネーミング仕様を単に公開して、接続を待機します。
サービスはサービスの説明で使用可能にします。 それには、サービスのコール方法、およびサービスをリクエストしてレスポンスを得るために必要な情報を記述します。 データ交換は、リクエスト/レスポンスのパターンを踏襲します。 RUEIでは主としてXML-SOAPおよび同様のメッセージの監視がサポートされます。
Webサービス定義の作成
Webサービスを定義する手順は、次のとおりです。
この情報を入力すると、「フィルタ」 「プレビュー」列で定義が反映されます。
最高レベルのフィルタはドメインです。 ドメインを変更または微調整するには、URLの部分を指定します。 サービス名を指定して他のすべてのフィールドを空白にすることはできません。 ワイルドカード文字(*)は「ポートの検索」フィールドには指定できず、標準以外のポート(つまりポート80/443)に着信するネットワーク・トラフィックは、ポート番号が明示的に指定されないかぎり、サービスに関連付けられません。 ポートの検索フィールドには1つのポート番号しか指定できません。 追加のポートを指定する必要がある場合は、新しいサービスが作成された後で追加のフィルタとして指定してください。
ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。 ワイルドカード文字を指定して、それ以外にドメインとURL引数の組合せ情報を指定しないことはできません。
注意:
サービス、SSOプロファイル、アプリケーションおよびスイート間でフィルタ定義を相互排他的にしておくことをお薦めします。 たとえば、ドメインoracle.comと、別のサービス、スイート、またはoracle.com/application_servletでフィルタ処理されるアプリケーションを定義しないでください。相互に排他的ではないフィルタ定義を使用すると、予期しない結果が生じる可能性があります。 フィルタの適用順序を変更できる方法は、「RUEI内でのルール順序設定の制御」を参照してください。
URLの部分の中に、一致対象とする引数を指定することもできます。 この機能を使用する場合は、引数と引数名の両方が完全に一致しないと、ページURLsが検索されません。 つまり、部分一致はサポートされていません。 次へをクリックします。 図10-17に示すダイアログが表示されます。
次に、終了をクリックします。 指定したサービス定義の概要が表示されます。 例を図10-18に示します。
図10-18 サービスの概要
例10-2 サービス定義の微調整
サービスを定義した後で、関連する機能スキームを変更できます。 識別セクションで、新規フィルタの追加をクリックして、サービスに関連付ける必要がある機能に追加のフィルタを指定できます。 定義済フィルタのいずれかと一致する機能が、サービスに割り当てられます。 また、既存のフィルタ定義を変更するには、それをクリックします。 いずれの場合にも、図10-16に示したフィルタの中から選択できます。 ユーザーによる追加または変更を反映するようにサービス概要が更新されます。
例10-3 Client Identification
クライアントID識別スキームを定義する手順は、アプリケーションやスイートについての手順と同じです。「ユーザー識別の定義」で説明します。
例10-4 IPアドレス・ソースの指定
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはTCPパケットからフェッチされます。 ただし、RUEIシステムをNATデバイスの前に配置する場合には、特定のヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。 拡張セクション(図10-16)のクライアントIPソース・チェック・ボックスを使用して、目的のスキームを指定できます。 これについては、「NATed Trafficのモニタリング」で説明しています。
関数コールのうち、そのURL定義によりサービスに属していることが確認されているものの、関連する分類済の名前が見つからないものは、廃棄されレポートされません(デフォルト)。 ただし、そのような未分類のコールをレポートする場合は、関数セクションの未分類のコールのレポートチェック・ボックスを使用します。
サービスに属していることが確認されていないヒットは未分類のコールとして識別されるため、定義が不正確または不十分な関数コールは未分類として識別されます。 未分類のコールは、関連するデータ・ブラウザ・グループ内のカテゴリその他の下にレポートされます。
関数のレスポンス時間を評価するために、RUEIでは関数コールごとに満足度レベルが割り当てられます。 これは、「ページ・ロードの満足度の指定」で説明しているページ・ロードしきい値と同じです。
脚注の凡例
脚注 5:World Wide Web Consortium (W3C)は、World Wide Webの主要な国際標準規格です。
