| Oracle$reg; Real User Experience Insightユーザーズ・ガイド リリース11.1 for Linux x86-64 B63041-01 |
|
 前へ |
 次へ |
この章では、監視対象のWebページの識別方法について説明します。特に、追加情報を利用する必要があるWebページおよび特定のテキスト文字列の出現を監視する必要があるページを定義する方法について説明します。また、規則指定機能と他の高度な機能の使用方法についても説明します。最後に、SSOベースの環境におけるトラフィックの監視について説明します。
URL引数
アプリケーション、スイート、サービス、およびユーザーとクライアントのID識別のために構成されるURL引数は、エンコーディングなしで(%、&、=記号を除く)指定する必要があることに注意してください。
RUEIにおけるページの識別は、アプリケーションに基づいて行われます。一般的に、アプリケーションはWebページの集合です。通常、Webサイトのページは特定のアプリケーションにバインドされているためです。アプリケーション内の各ページには名前が割り当てられていて、それぞれのページはグループに属します。たとえば、「MyShop ≫ Contact ≫ About us」は、MyShopアプリケーション内のContactグループの「About us」ページを指します。
各アプリケーションには、アプリケーションの有効範囲を定義するページ・ネーミング・スキームが関連付けられています。スキームの指定には、ドメイン名の一部またはURL構文の一部、あるいはその両方の組合せを使用できます。また、ページ・ネーミング・スキーム(ページ・タグ付けやHTMLページのタイトル部分など)は、アプリケーション定義を微調整する際にも指定できます。
RUEIで検出される各ページに対し、スキームは、存在するアプリケーション定義を使用して名前を割り当てます。これらの定義を使用して識別できないページに関する情報は廃棄されるため、レポートおよびデータ・ブラウザでは使用できません。
アプリケーション・ページは、自動検出できるのみでなく、手動で定義することもできます。手動定義が特に役立つのは、URL構文に一貫性のない場合や、識別されたページにサブページが含まれる場合、またはアプリケーションによって自動的に割り当てられた名前とは違う名前を割り当てる必要がある場合です。手動で定義されたこれらのページは、アプリケーション定義で自動的に識別されたページより優先されることに注意してください。
現時点で定義されているアプリケーションとそのグループおよびページの構造を表示するには、「Configuration」→「Applications」→「Applications」の順に選択します。例を図8-1に示します。
アプリケーションを定義する手順は、次のとおりです。
「Configuration」→「Applications」→「Applications」の順に選択し、「New application」をクリックします。図8-2に示すダイアログが表示されます。
アプリケーションの名前を指定します。これは、スイート、サービス、SSOプロファイルとSSOアプリケーションを通じて一意である必要があります。アプリケーション名はレポートされるページに付加されるため、定義されたアプリケーション名をできるだけ維持することをお薦めします。アプリケーションの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、アプリケーションの有効範囲を指定します。有効範囲はページURLを使用して定義されます。この情報を入力すると同時に、入力した定義が「Filter preview」列に表示されます。
最高レベルのフィルタはドメインです。アプリケーション名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字(*)は「Find Port」フィールドには指定できないことに注意してください。指定できるのはポート番号1つのみです。さらにポートを指定する必要がある場合は、新しいアプリケーションが作成された後で追加のフィルタとして指定してください。
特定のフィールドではワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、ドメインとURL引数の組合せによるその他の情報を指定しないことはできません。
|
注意: スイート、SSOプロファイル、アプリケーションおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。たとえば、ドメインus.oracle.comでフィルタリングされるアプリケーションと、us.oracle.com/application_servletでフィルタリングされる別のアプリケーションがある場合、予測できない結果が発生することがあります。一致規則の適用順序を制御する方法は、12.8項「RUEI内でのルール順序設定の制御」を参照してください。 |
|
注意: アプリケーション、スイート、サービス、およびユーザーとクライアントのID識別のために構成されるURL引数は、エンコーディングなしで(%、&、=記号を除く)指定する必要があります。 |
一致対象とするURL GET引数を指定することもできます。この機能を使用する場合は、引数名と引数値の両方を揃えて指定することで初めて、検出されたページURLと一致することに注意してください。つまり、部分一致はサポートされていません。次に、「Next」をクリックします。図8-3に示すダイアログが表示されます。
このダイアログでは、アプリケーション内のページに使用する自動ページ・ネーミング・スキームを指定できます。各アプリケーションに対して指定できるスキームは1つのみです。次のオプション・グループがあります。
Page tagging: 標準スキーム(「Coremetrics」など)とカスタム・スキームのいずれを使用するかを指定します。カスタム・スキームの場合は、カスタム・タグの名前を指定する必要があります。「HTML title」オプションは、ページの<title>タグにあるテキストを使用してページを識別する必要があることを指定します。このオプションの使用方法の詳細は、8.2.1項「詳細設定の使用によるページとオブジェクトの処理の制御」を参照してください。RUEIでサポートされているページ・タグ付けの汎用スキームの構造および処理は、付録A「タグ付け規則」に記載されています。
Client request: ページをそのURL構文に基づいて識別することを指定します。次のオプションにより、URLのどの部分を使用するかを指定します。
URL: ページ・ネーミングが、ビジターのブラウザのロケーション・バーに表示される完全なドメインとURLに基づきます。このスキームは規則指定を使用するときに特に役立ちます。
URL directory: URLのディレクトリ部分のみを使用します。URLの各部分は、図8-4に示されています。
URL base: URLのメイン・ディレクトリとファイル名(ファイル拡張子は除く)の部分を使用します。
URL full: URLのメイン・ディレクトリ、ファイル名(ファイル拡張子は除く)および構成済の引数を使用します。このオプションを選択すると、ページ名に含める引数を指定するように求められます。このダイアログ・ボックスでは、複数の引数はアンパサンド(&)文字で区切る必要があります。たとえば、frmActionパラメータを定義した図8-4のURLは、myshop ≫ shop ≫ NL index frmAction=buyというページ名になります。
これらいずれかのオプションを選択した場合、使用方法の詳細は、8.2.1項「詳細設定の使用によるページとオブジェクトの処理の制御」を参照してください。
Server response: サーバーのレスポンスに適用されたXPath式に基づいてページを識別することを指定します。XPath式の使用方法の詳細は、付録F「XPath問合せの使用」を参照してください。
Manual: アプリケーション・ページを自動検出せずに手動で定義することを指定します。このオプションを選択すると、監視するアプリケーションに関連付けられているすべてのページを手動で定義する必要が生じてくるため、注意してください。ページの手動定義の詳細は、8.2.15項「ページの手動識別」を参照してください。このオプションがデフォルトです。
次に、「Finish」をクリックします。指定したアプリケーション定義が表示されます。例を図8-5に示します。
この概要には、定義したアプリケーションのサマリーが示されます。これには、アプリケーションの名前、これまでに一致した一意のページ数、最後に識別されたページの日付が含まれます。直前の3日間にアプリケーションについて識別されたページがない場合は、アプリケーションが現在機能していないことを示す警告のアイコンが表示されます。
画面の下部のタブでは、アプリケーションの具体的な項目の情報が表示されます。たとえば、「Identification」セクションではアプリケーションに対して現在定義されているフィルタ基準のサマリーが表示されます。また、「Pages」セクションでは、使用されるページ・ネーミング・スキーム、未分類のページのレポート設定、ページ・ロード満足度のしきい値、アプリケーションに所属するこれまでに識別されたページが示されます。それぞれのセクションの詳細は次の各項で説明します。
「HTML title」スキームまたはクライアント・リクエストのページ・ネーミング・スキームのいずれか(「URL base」など)を選択した場合、「application overview」の「Advanced」タブを使用してこれらのスキームの運用を微調整できます。「HTML title」スキームの場合は、図8-6に示すダイアログが表示されます。
図8-6 「Edit Application Page-Naming Scheme」ダイアログ
Time Recognition
「Time recognition」メニューを使用して、ページを識別するために非強制オブジェクトを使用するかどうかを制御できます。図8-7に示す例について考えます。
この場合、ページ識別に使用することができる3つの非強制オブジェクト(home.jsp、sub.jspおよびdown.jsp)があります。「Disabled」オプションが「Time recognition」メニューで指定されている場合(デフォルト)、最後のヒットの1秒以内に検出されると、最初のオブジェクト(home.jsp)のみがページとして識別されます。ただし、「enabled」の場合には、3つの非強制オブジェクトそれぞれ(jspなど)が検出時刻は考慮されずに別のページとして識別されます。強制オブジェクトの詳細は、D.4.2項「強制オブジェクト」を参照してください。
サブヘッダーによる代用
「HTML title」ページ・ネーミング・スキームを選択した場合は、ページの<title>タグにあるテキストがページの識別に使用されます。このテキストが見つからない場合は、サブヘッダー<H1>、<H2>および<H3>を使用できます。このためには、「sub-header fallback」メニューを使用してこの機能を制御します。デフォルトでは、サブヘッダーは使用されません(「Disabled」)。
リダイレクトの処理
クライアント・リクエストベースのいずれかのスキーム(「URL base」など)を選択して、「Advanced」タブをクリックすると、図8-8に示すダイアログが表示されます。
「Page handling」メニューを使用して、URL内のリダイレクトをどのように処理するかを指定します。表8-1に示すオプションがあります。
表8-1
| 設定 | 説明 |
|---|---|
|
Final page |
ページ名を決定するために最終ページのURLのみを使用することを指定します。これがデフォルトです。 |
|
Redirect naming |
最終ページの前でリダイレクトから得られる情報を使用してページを識別することを指定します。ない場合は、最終ページの情報が使用されます。 |
|
Redirect becomes page |
リダイレクトが実際に識別されるページになるように指定します。最初のリダイレクトがページ作成に使用され、その後のすべてのリダイレクトは作成されたページのオブジェクトになることに注意してください。アプリケーションのレポートに及ぼす結果をよく理解した場合のみ、このオプションを選択することを強くお薦めします。 |
各アプリケーション定義では、使用するページ・ネーミング・スキームおよびユーザー識別スキームを指定する必要があります。また、必要に応じて、特定のアプリケーション・ページで表示されたときにレポートする必要のあるコンテンツ・メッセージを指定することも可能です。これらの各定義は、規則指定機能を使用して拡張できます。追加の一致規則を指定できるようになり、それによって選択したページ・ネーミング・スキーム、ユーザー識別スキームまたはメッセージの仕様を微調整します。規則指定機能は、自動(手動ではない)ページ・ネーミング・スキームおよびXPathベース(リテラルではない)のコンテンツ・メッセージのみで使用できることに注意してください。
推奨される使用方法
規則指定は複雑であるため、選択したアプリケーションの適切なスキームまたはメッセージ構文を十分理解しているユーザーのみがこの機能を使用することをお薦めします。たとえば、URLベースのページ・ネーミング・スキームの場合、選択したアプリケーションの基礎となるURL構文も明確に理解しておく必要があります。
ルールの定義
アプリケーションまたはスイートで規則指定の使用を指定する手順は、次のとおりです。
「Configuration」を選択し、「Applications」または「Suites」のいずれかを選択します。目的のアプリケーションまたはスイートをクリックして、その概要を表示します。例を図8-1および図10-4に示します。
必要な規則指定の使用方法に応じて、ページ・ネーミング・スキーム(「Pages」タブ内)、適切なユーザー識別スキーム(「Users」タブ内)、または適切なコンテンツ・メッセージの仕様(「Content messages」タブ内)をクリックします。図8-9に示すようなダイアログが表示されます。
図8-9 「Edit Application Page-Naming Scheme」ダイアログ
「Ruling」タブをクリックして、使用する規則と、規則を評価する順序を指定します。図8-10に示すダイアログが表示されます。
このダイアログを使用し、新しい規則を定義するか、既存の規則を削除します。各規則のコンテキスト・メニューを使用して、適用順序を変更することもできます。「Add new matching rule」項目をクリックし、新しい一致規則を定義します。図8-11に示すようなダイアログが表示されます。
規則の次の要素を指定します。
Input value: 予期されるスキーム(URLまたはページ・タグ付けなど)またはメッセージ仕様の構文を指定します。通常、受信したスキームまたは仕様を解釈するためのテンプレートを指定します。
Search expression: 一致する必要があるスキームの定義または仕様を指定します。これは通常、必須のパラメータまたは要素からなるシーケンスで表されます。
Page group: 受信したページ・ネーミング・スキームからページ・グループを識別する方法を指定します。これが未指定の場合、ページ・グループにはページ名が割り当てられます。このフィールドを使用できるのはページ・ネーミング規則のみです。
User ID/Page Name/Content message: 受信したスキームまたは仕様からページ名、ユーザーIDまたはコンテンツ・メッセージを識別する方法を指定します。
規則の要素を指定したら、「Check rule」ボタンをクリックして、定義した規則が指定されている検証値と一貫性があることを検証できます。結果のウィンドウを展開すると、一致するプレースホルダのサマリーを表示できることに注意してください。例を図8-12に示します。
次に、「Save」をクリックします。図8-10に示すダイアログに戻ります。
必要なすべての規則を定義したら、「Check rules」をクリックして、定義したすべての規則を検証値に対して検証できます。各検証値は、対応する規則に関連している必要があります。検証の後で、各規則の横にステータスを示すアイコンが表示されます。検証が失敗した規則については、マウスを重ねるとボックスに追加の情報が表示されます。図8-13に示す例について考えます。
最初の規則は定義済の検証値と一貫性があり、正常に検証されています。ただし、2番目の規則は非常に汎用性が高いため、複数の評価規則がこの規則と一致すると警告されます。実際に、汎用性が高いために関連する検証値がすでに正常に適用されてしまい、後続の規則を適用できません。つまり、3番目の規則が使用されません。このため、2番目の規則ではなく3番目の規則についてエラーがレポートされます。ただし、2番目の規則を移動して最後の規則にすると、3つの規則が正常に検証されます。
エラーがレポートされた規則指定の定義を保存することは可能ですが、問題があれば規則指定の定義を保存する前に解決することを強くお薦めします。次に、「Save」をクリックします。規則指定の定義の変更は5分以内に有効になります。
URL一致に関する規則指定
URL一致では大/小文字が区別され、URL(一致の後)は小文字に変換されることに注意してください。規則指定の後で、一致したスラッシュはページ名において空白に置き換えられます。
ユーザー識別に関する規則指定
ユーザー識別で規則指定を使用する方法は、ページ・ネーミングの場合と同じですが、ユーザーIDが選択したスキームから識別される方法を指定すること、ページ・グループ識別がサポートされないことが異なります。次の例について考えてください。指定したユーザー識別スキームがCookieに基づき、各Cookieは次の構造をしています。
ORA_UCM_INFO=5~DVJ88287~John~Doe~john.doe@myshop.com~USA~en~33~44~5~~1;
このCookieの電子メール・アドレス部分のみに基づいてユーザーを識別するようにします。この場合、次のように指定できます。
Search expression: %~%~%~%~%~%User ID: %5
検証値は、上記の例のCookieまたは同じ構造の他のCookieの例を使用して指定できます。
規則内のページ・グループの識別
ページ・ネーミング・スキームで規則指定機能を使用するとき、ページ・ネーミング・スキームのソースにページ・グループが含まれる場合は、グループ値が正しく識別されるようにする必要があります。ソースがmyhost.com/myshop/menswear/catalog/basket.jspというURLページ・ネーミング・スキームの場合、内部ではmyshop\%7Cmenswear/catalogという構文に変換されます。その後、正しくレポートされるために次のように変換される必要があります。
Input value: myshopmyshop: %7Cmenswear/catelogSearch expression: %\%7C%/%Page group: %1Page name: %2
検索式では、グループとページ名の間のセパレータ(|)は\%7Cとエンコーディングされ、エンコーディングされたパイプ文字になります。URL構文内のスラッシュ記号は規則指定で使用できることに注意してください。規則指定の後で、一致したスラッシュは、レポートされるグループと名前においては空白に置き換えられます。
検索の構文
URL一致規則には、パラメータの他に、表8-2に示す要素も使用できます。
表8-2 拡張検索の構文
| 使用方法 | 説明 |
|---|---|
|
|
ゼロ個以上の文字に一致し、1つのプレースホルダに入力します。使用できるプレースホルダは%1から%9です。 |
|
|
URL引数内に指定した名前のいずれかに一致する1つの値を検索し、元のプレースホルダの1つと一致後のプレースホルダの1つに入力します。 |
|
|
URL引数内に指定した名前に一致するすべての値を検索し、元のプレースホルダの1つのパラメータ・プレースホルダと、指定した数のプレースホルダの1つのパラメータ・プレースホルダに入力します。 |
|
|
URL引数内に指定した名前に一致するゼロ個以上の値を検索し、元のプレースホルダの1つと指定した数のプレースホルダの1つに入力します。 |
|
|
指定した数の文字を検索します。 |
|
|
URLのディレクトリ・パスを検索し、1つのプレースホルダに入力します。 |
|
|
URLのファイル名パス(ファイル拡張子は除く)を検索し、1つのプレースホルダに入力します。 |
|
|
URLのドメイン部分を検索し、3つのプレースホルダに入力します(たとえば |
|
|
後続の文字の1つが一致するまで一致を試行し、1つのプレースホルダに入力します。 |
|
|
指定したリストの文字に一致しない文字が見つかるまで一致を試行します。 |
特殊文字(%、\、|、!、~)が文字どおりに解釈されるようにするには、前にバックスラッシュを付ける必要があります。たとえば、\%は、パラメータではなく、%文字そのものを示します。また、%文字の後の特殊文字(^、&、[、])もエスケープする必要があります。指定できるプレースホルダは最大9つまでであることに注意してください。
例
Search value: %[h]/%/%/%/%?%
Page group: %6 (electronics)
Page name: %7 (tv821)
URL (for checking): www.mydomain.co.uk/shop/catalog/electronics/tv821?params=all
Search value: %[h]/%[&shop_cat]
Page group: %2 (pcShop)
page name: %5 (Cables)
URL (for checking): www.pcShop.com/home/applications/catalog?cust_id=123&shop_cat=Cables
Search value: %[h]/cart:%[c9]/articleid:%[c9]/%
Page group: %4 (00000ABCD)
Page name: %5 (000018201)
URL (for checking): www.myshop.com/cart:00000ABCD/articleid:000018201/shop.jsp?params=all
ページのうち、そのURL定義によりアプリケーションに属していることが確認されているものの、関連する分類済の名前が見つからないものは、廃棄されレポートされません(デフォルト)。ただし、そのような未分類のページをデータ・ブラウザ・グループでレポートする場合は、図8-14に示す「application overview」内の「Pages」セクションにある「Report unclassified pages」チェック・ボックスを使用します。
ページの識別は、時間ベースのアクティビティであるため、オブジェクトとして予約されていないオブジェクトへの参照は、未分類のページであるとして、誤って識別される場合があります。このため、未分類のページのレポート作成は、テスト目的でのみ有効にすることをお薦めします。その後、これを再度無効にし、識別された問題のあるページを手動で定義できます。未分類のページは、対応するデータ・ブラウザ・グループ内のカテゴリ「other」にレポートされることに注意してください。
監視対象のサービス・テストはRUEIユーザー・フローにも変換できることに注意してください。この詳細は、9.8項「サービス・テスト・セッションのユーザー・フローへの変換」に記載されています。
「Advanced」セクションの「Report service test traffic」チェック・ボックスを使用して、選択したアプリケーションのためにOracle Enterprise Manager Grid Controlで構成されているサービス・テスト・トラフィックをRUEIでレポートするかどうかを指定できます。デフォルトでは、レポートは行われません。この機能の使用方法の詳細は、3.2.6項「Oracle Enterprise Managerのサービス・テスト監視」に記載されています。
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはIPパケットからフェッチされます。ただし、RUEIシステムをNATサービスの前に配置する場合には、特定のHTTPリクエスト・ヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。この詳細は、付録O「NATトラフィックの監視」に記載されています。
前述のように、RUEI内の各ページは、アプリケーション ≫ グループ ≫ 名前という形式になります。自動的に検出されたページには、URL内のディレクトリ構造に基づき、グループ名とページ名が割り当てられます。URL内の第1ディレクトリがグループ名に割り当てられ、残りのサブディレクトリがページ名に割り当てられます。ドメイン部分は、割り当てられる名前で使用されないことに注意してください。これは、URLのベース、ディレクトリまたは完全なページ・ネーミング・スキームで定義されたアプリケーションにのみ適用されます。
たとえば、ClothingというアプリケーションのページURL http://MyShop.nl/catalog/menswear/sale.htmlでは、Clothing ≫ catalog ≫ menswear saleというRUEIページ名が生成されます。ディレクトリ構造内のスラッシュは空白に変換されることに注意してください。
URL内にサブディレクトリがない場合、デフォルト・グループであるhomeがページに割り当てられます。たとえば、Clothingアプリケーション内のURL http://MyShop.nl/sale.htmlには、clothing ≫ home ≫ saleというページ名が割り当てられます。
アプリケーションの定義後に、アプリケーションに関連するページ・ネーミング・スキームを変更するには、この項で前述したように、アプリケーションをクリックして新規スキームを選択します。
「Identification」セクションで、「Add new filter」をクリックして、アプリケーションと関連付ける必要のあるページの追加フィルタを指定します。また、既存のフィルタ定義を変更するには、それをクリックします。いずれの場合にも、図8-2に示したフィルタの中から選択できます。ユーザーによる追加または変更を反映するようにアプリケーション概要が更新されます。
セッションでアプリケーション・ページを表示している際のユーザー・エクスペリエンスを評価するために、RUEIではページごとに満足度レベルが割り当てられます。これを表8-3に示します。
表8-3 ページ・ロード満足度のレベル
| レベル | 説明 |
|---|---|
|
Satisfactory |
ページは指定のしきい値内でユーザー・ブラウザにロードされます。このしきい値は、ページ・ロードの満足度のしきい値です。たとえば、ページが5秒以内にロードされる、などです。 |
|
Tolerable |
ページのロードにかかる時間は指定のしきい値の4倍未満です。 |
|
Frustrating |
ページのロードに、指定のしきい値の4倍よりも時間がかかります。 |
ページ・ロード満足度のレポートの例を図8-15に示します。
前述のように、この評価は、ページのロードの完了までに通常想定されるしきい値に基づきます。このしきい値を変更し、データ・ブラウザでレポートされるページ・ロード満足度を微調整できます。次を実行します。
目的のアプリケーションを選択し、「Pages」セクションをクリックし、現在定義されている「Page-loading satisfaction」設定をクリックします。図8-16に示すダイアログが表示されます。
ページのロードの完了までに通常想定される期間(秒単位)を指定します。デフォルトは4秒です。次に、「Save」をクリックします。指定した変更は、即座に有効になります。
ページ内に表示される文字列を検出し、アプリケーション通知("注文が正常に処理されました"など)またはアプリケーション・エラー("サーバーへのネットワーク接続に失敗しました"など)のいずれかとしてレポートする必要が生じる場合があります。
コンテンツ・メッセージのチェックと、システム・エラーおよびページ・コンテンツのチェック
コンテンツ・メッセージは、リターン・コードではなくページ・コンテンツに基づき、選択したアプリケーションに固有であるため、システム・エラー(Webサーバー・エラーまたはネットワーク・エラー)とは異なります。
指定したメッセージ文字列は、選択したアプリケーション内のすべてのページを対象として検索されることに注意してください。ページ・コンテンツ・チェックが行われるため、特定のページのみを検索することはできません(8.2.14項「ページ・コンテンツ・チェックの指定」を参照)。
アプリケーション・コンテンツ・メッセージおよびページ・コンテンツ・メッセージはベージベースです。サービスの場合、それらはコール(つまりヒット)固有です。したがって、ページベースのグループのみでレポートされ、(URLベースの)診断グループではレポートされません。
コンテンツ・メッセージのレポート
個々のコンテンツ・メッセージは、通知またはエラーとして指定できます。いずれの場合も、ページ配信ディメンションでレポートされます。
指定した通知文字列と一致するものとして表示されるページ・テキストは、ページ・コンテンツの結果である「notification string: notification search string」とともにレポートされ、エラーの場合は「error string: error search string」としてレポートされます。コンテンツ・エラーのレポートの例を図8-17に示します。
コンテンツ・メッセージの定義
コンテンツ・メッセージの文字列を定義する手順は、次のとおりです。
「Configuration」を選択し、「Applications」、「Suites」または「Services」を選択して、目的のアプリケーションを選択します。(図8-5に示すような)「Application overview」が表示されます。
「Content messages」タブ→「Content messages」の順にクリックします。現在定義されているコンテンツ・メッセージが表示されます。「Add new content message」をクリックして新しいメッセージを定義するか、または既存のものをクリックして変更します。図8-18に示すダイアログが表示されます。
「Search type」メニューを使用して検索範囲を指定します。これには、リクエストまたはレスポンスのヘッダーかコンテンツを指定できます。検索は、リテラル検索文字列またはXPath式に基づいて行うことができます。XPath式の場合、検索できるのはリクエスト・ヘッダーまたはレスポンス・ヘッダーのみです。リクエスト・ヘッダーまたはレスポンス・ヘッダーを指定すると、検索対象のHTTPヘッダーを指定するように要求されます。
「String」フィールドを使用して、リテラル検索文字列を指定します。ワイルドカードの使用はサポートされておらず、指定するすべての文字がリテラルとして扱われることに注意してください。または、「XPath search」フィールドを使用して、使用するXPath式を指定します。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。
次に、「Save」をクリックします。変更は5分以内に有効になります。XPathベースのコンテンツ・メッセージを作成すると、規則指定機能を使用してメッセージの仕様を微調整できることに注意してください。この詳細は、8.2.2項「規則指定機能の使用方法」に記載されています。
コンテンツ・メッセージのリストのインポート
監視対象とする各メッセージを個別に定義するかわりに、事前定義済アプリケーション・メッセージのリストを含むファイルをインポートできます。次の手順を実行します。
目的のアプリケーションまたはスイートを選択したら、「Message specifications」タブをクリックします。「Upload list」をクリックします。図8-19に示すダイアログが表示されます。
「Browse」ボタンを使用し、目的のファイルを検索して選択します。必要に応じて、「File encoding」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートの詳細は、付録G「各国語サポートの使用」を参照してください。サポートされていないエンコーディングが検出された場合、またはトランスコーディングに失敗した場合は、エラーがレポートされます。
アップロードされるファイルでは、1行に1つのメッセージを含める必要があり、空白の行を含めることはできません。これらのメッセージが、レスポンス内容で検索されるリテラル文字列になります。次に、「Merge」をクリックします。
必要に応じて、一意のメッセージ文字列それぞれに対して一連の説明を定義することもできます。たとえば、Oracle Databaseメッセージの説明を表8-4のように定義できます。
表8-4 メッセージ文字列の説明の例
| 文字列 | 説明 |
|---|---|
|
|
DDLロックの取得が試行されましたが、すでにロックされています。 |
|
|
一時表の数が一時表ロックの数以上です。 |
|
|
マウントされているデータベースのDB_BLOCK_SIZE初期化パラメータが違います。 |
|
|
DB_FILES初期化パラメータの値が超過されました。 |
|
|
ユーザー・フローがリソースの待機中に互いにデッドロックしました。 |
|
|
起動中の共有インスタンスがDMLロックを使用しており、実行中のインスタンスがDMLロックを使用していません(あるいは、その逆の状態)。 |
|
|
インスタンスがDML_LOCKS = 0で起動されたが、実行中の文では全表ロック(S、XまたはSSX)が必要です。 |
|
|
指定されたログ・ファイルの数が、このリリースでサポートされているログ・ファイルの最大数を超えました。 |
メッセージの説明を定義する手順は、次のとおりです。
適切なアプリケーションまたはスイートを選択したら、「Content messages」タブ→「Message specifications」タブの順にクリックします。現在定義されているメッセージの説明が表示されます。「Add new specification」をクリックして新しい説明を定義するか、または既存のものをクリックして変更します。図8-20に示すダイアログが表示されます。
必要なソース値と、必要に応じて説明を指定します。次に、「Save」をクリックします。
「Message type」メニューを使用して、メッセージをエラー(デフォルト)または通知のいずれとしてレポートするかを指定します。次に、「Save」をクリックします。
前述の例では、これは次のようにレポートされます。
error code ORA-00056: An attempt was made to acquire a DDL lock that is already locked.
非常に多くの説明がある場合は、「Search」フィールドを使用すると目的の説明をすぐに見つけることができることに注意してください。検索機能では部分一致が使用されます。ワイルドカードの使用はサポートされておらず、すべての文字がリテラルとして扱われます。次に、「Go」をクリックします。
説明のリストのインポート
各説明を個別に定義するかわりに、説明のリストを含むファイルをインポートできます。次の手順を実行します。
「Upload list」をクリックします。図8-21に示すダイアログが表示されます。
「Browse」ボタンを使用し、説明ファイルを探して名前を指定します。メッセージの定義が重複している場合は、最新の定義が使用されることに注意してください。必要に応じて、「File encoding」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートに関する詳細は、付録G「各国語サポートの使用」を参照してください。サポートされていないエンコーディングが検出された場合、またはトランスコーディングに失敗した場合は、エラーがレポートされます。ファイルには、ソース値とその説明をタブで区切って、1行に1つの説明のみを含めることができます。
「Message type」メニューを使用して、ファイルに定義されたメッセージをエラー(デフォルト)または通知のいずれとしてレポートするかを指定します。次に、「Merge」をクリックします。
コンテンツに関連のないエラー(つまり、Webサイト、ネットワークまたはサーバーのエラー)と一緒にコンテンツ・メッセージがレポートされると非常に便利です。トラブルシューティングを促進するためにエラーのコンテキストに関する追加情報の提供が可能になります。ただし、これはレポートのデフォルトの動作ではありません。
3.2.3項「ページ配信ディメンション」に記載されているように、1ページで数種類のエラー(たとえばサーバー・エラーとネットワーク・エラー)が発生しても、ページ・エラーは複数回レポートされません。かわりに、エラーは特定の順序(Webサイト、サーバー、ネットワーク、コンテンツの順)でレポートされます。
コンテンツに関連のないエラーが追加情報と一緒にレポートされるように指定する手順は、次のとおりです。
「Configuration」→「Applications」の順に選択して、目的のアプリケーションを選択します。(図8-5に示すような)「Application overview」が表示されます。「Content messages」タブ→「Advanced」タブの順にクリックします。図8-22に示す画面が表示されます。
ページ上に定義済コンテンツ・メッセージが見つかった場合はレポート時にエラーに追加するよう指定するには、「Append content messages」チェック・ボックスを選択します。デフォルトでは、コンテンツ・メッセージは追加されません。同じページ内に複数のコンテンツ・メッセージが見つかった場合は、ページ上で最初に見つかったメッセージがレポートで使用されることに注意してください。
拡張ページ配信の詳細の例を図8-23に示します。
RUEIでは、新たに作成されるアプリケーションは、ユーザー識別が「HTTP Authorization」フィールドとSSLクライアント証明書の共通名(CN)部分(使用可能な場合)に基づくように自動的に構成されます。図8-24にこれを示します。
ただし、URL、Cookie、リクエスト・ヘッダー、レスポンス・ヘッダー、XPath式、カスタム・タグまたはレスポンス、OAMユーザー・トラッキング(11.1項「OAMベース・トラフィックの監視」を参照)に関して、アプリケーションのユーザー識別スキームを構成することもできます。「HTTP Authorization」フィールドは構成される他の値よりも優先されること、SSL証明書は代替スキームであることに注意してください。構成されたユーザーIDが監視対象トラフィックで検出されたものと一致しない場合、そのユーザーIDはAnonymousとしてレポートされます。
アプリケーションのユーザー識別スキームの構成
アプリケーションのユーザー識別スキームを構成する手順は、次のとおりです。
目的のアプリケーションを選択し、「Users」セクションをクリックします。
「Add new source」をクリックします。図8-25に示すダイアログが表示されます。
「Search type」メニューを使用し、ユーザーの識別メカニズムを指定します。これは、リテラル検索文字列またはXPath式を使用して指定できます。次の点に注意してください。
リテラル検索文字列の場合、リクエスト・ヘッダーまたはレスポンス・ヘッダーを検索するかどうかを指定できます。
XPath式の場合、リクエストまたはレスポンスを検索するかどうかを指定できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。
Cookieの場合は、Cookieの名前を指定する必要があります。選択したCookieに対して、またはデフォルトのCookieマスキング・アクションとしてハッシングが指定されている場合、Cookieの一意性は保たれますが、元の値は保存されません。この詳細は、13.5項「ユーザー情報のマスキング」に記載されています。
URL引数の場合は、引数の名前を指定する必要があります。
OAMベース・トラフィックの場合は、詳細について11.1項「OAMベース・トラフィックの監視」を参照してください。
カスタム・パターンの場合は、開始文字列と終了文字列(オプション)を指定して、検索対象のコンテンツの範囲を決める必要があります。ワイルドカード文字の使用はサポートされておらず、指定するすべての文字がリテラルとして扱われることに注意してください。また、終了文字列を指定すると、検索は次の行以降では行われません。
カスタム・タグの場合は、ユーザーIDが取得されるname=valueペアに名前を指定する必要があります。
前述のように、HTTPベースの認証が指定されている場合は、他に識別スキームが定義されても優先されます。また、SSLクライアント証明書が指定されている場合、これは代替スキームになります。
次に、「Save」をクリックします。
各国語サポート
各国語のキャラクタ・セットを使用する際に識別が持つ意味の詳細は、付録G「各国語サポートの使用」を参照してください。
アプリケーションで検出されたページの構造は、ウィンドウの左側にあるアプリケーション概要に表示されます。例を図8-26に示します。
アプリケーションには、非常に多くのページが関連付けられている可能性があります。実際、図8-26に示す構造では、簡単には確認できないほど多くのページが関連付けられています。このため、この構造のビューは、Point of Interest(POI)を持つページに制限されています。したがって、レポートに含まれているページ、キー・ページとして定義されているページ、手動で名前が設定されたページ、監視対象KPIの一部であるページなどが表示されます。図8-27に示す表示メニューでは、構造概要に表示するページのタイプを制御できます。
表8-5に示すオプションがあります。
図8-5 表示メニュー・オプション
| オプション | 説明 |
|---|---|
|
All |
すべてのアプリケーション・ページをリストします。 |
|
Report pages |
レポート・フィルタとして指定されているページのみをリストします(2.6項「レポート・フィルタの使用方法」を参照)。 |
|
Checked pages |
コンテンツ・チェックが定義されているページのみをリストします(8.2.14項「ページ・コンテンツ・チェックの指定」を参照)。 |
|
Manually named pages |
手動で定義されているページのみをリストします(8.2.15項「ページの手動識別」を参照)。 |
|
Key pages |
キー・ページとして定義されているページのみをリストします(8.2.13項「ページの使用状況の追跡」を参照)。 |
アプリケーション・ページ・カテゴリをドリルダウンすると、特定のページに移動できます。ただし、多数のページを含むアプリケーションの使用時は、ページ検索機能を使用した方が便利な場合があります。次を実行します。
検索するアプリケーションを選択します。「Pages」セクションを選択し、「Identified pages」タブをクリックします。
目的のページの検索に使用する検索プロファイルを指定します。検索は現在のアプリケーションに制限され、ページ名は、アプリケーション ≫ グループ ≫ 名前という構造になることに注意してください。検索機能では、完全一致または部分文字列として指定した検索パターンとの一致が行われます。このため、検索パターンhomeは、アプリケーション、グループまたはページの名前におけるこの文字列または部分文字列の出現に一致します。次に、「Go」をクリックします。結果リストを図8-28に示します。
検索結果がダイアログの下半分に表示されます。一致したページをクリックして開きます。右および左矢印ボタンを使用し、結果の複数のページ間を移動します。また、表示メニュー(8.2.11項「アプリケーション・ページ構造の表示」を参照)を使用すると、特定の基準(レポートで使用されるページなど)に合うように表示リストを制限できます。
|
注意: 検索範囲には、検出済のページと、レポートおよびユーザー・フローに存在する未検出ページの両方が含まれます。 |
アプリケーションで検出された各ページに関する情報は、ページ分析ウィンドウで確認できます。例を図8-29に示します。
このウィンドウには次のタブがあります。
Identification: ページ識別スキーム(手動または自動)と、識別に使用する条件を指定します。
Content check: コンテンツ検索文字列がページに定義されているかどうかを指定します。この詳細は、8.2.14項「ページ・コンテンツ・チェックの指定」に記載されています。
Reporting: このページを含むレポートをリストします。レポートの詳細は、第2章「レポートの操作」に記載されています。
Monitoring: このページを含むKPIをリストします。KPIを定義する手順の詳細は、7.2項「KPIおよびSLAの定義」を参照してください。
図8-29の「Key page」チェック・ボックスを使用して、ページをキー・ページとして定義します。
キー・ページは、監視対象のうち、特に注目するWebページです。通常、これは特に重要なページです。たとえば、組織のホームページや、注文入力などのユーザー・フロー内の一連のページなどがあります。これらのページに関しては、追加情報が記録されます。追加情報には、クライアント情報(ISP、アクセス元の国など)やクライアントのブラウザ情報(オペレーティング・システム、ブラウザ・バージョンなど)があります。
特定のページに特定のテキスト文字列が出現するかどうかの監視が必要となる場合があります。たとえば、Webアプリケーションに注文ページがあり、販売に成功した後、"ご購入ありがとうございました"というテキスト文字列がこのページに表示されるとします。目的のページにこの文字列があるかどうかを検索するページ・コンテンツ・チェックを定義できます。指定したテキスト文字列がそのページで見つからない場合、ページ・ビューは失敗したページとしてレポートされることに注意してください。
ページ・コンテンツ・チェックのレポート
成功したページとしてレポートされるためには、ページに対して指定したすべての文字列がページ・ビュー内で見つかる必要があることに注意してください。それ以外は失敗したページ・ビューとしてレポートされます。また、コンテンツ・メッセージ(8.2.9項「アプリケーション・コンテンツ・メッセージのトラップ」を参照)の一致はページ・コンテンツ・チェックの前に行われます。したがって、ページ・コンテンツ・チェックでは失敗したページとしてレポートするように示しても、ページ・ビューは通知(つまり、成功)としてレポートされることがあります。
ページ・コンテンツ・チェックの定義
ページ・コンテンツ・チェックを定義する手順は、次のとおりです。
「Configuration」→「Applications」→「Applications」の順に選択して、目的のアプリケーション・ページを選択します。ページ分析ウィンドウ(図8-29を参照)が表示されます。
「Content check」タブ→「Add check」の順にクリックします。図8-30に示すダイアログが表示されます。
検索時に、リテラル検索文字列またはXPath式のいずれを使用するか、およびサーバーのレスポンスまたはクライアントのリクエストのどちらを検索するかを指定します。XPath式の場合は、クライアントまたはサーバーのレスポンス・コンテンツで検索する詳細な値も指定できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。次に、「Save」をクリックします。
アプリケーション全体のページを識別できるのみでなく、ページを手動で定義することもできます。手動で識別されたページは、アプリケーションによって自動的に識別されたページより優先されることに注意してください。この機能は、自動的には識別できないサブページに、別の名前を割り当てる場合に便利です。手動で識別されるページは、新規ページのベースとなる既存のページを選択して作成します。
ページが手動で識別されるようにするには、新規のページを最初から定義するか、既存のページ(自動で検出または手動で定義されたページ)を新規ページのベースとして使用します。
ページを定義する手順は、次のとおりです。
ページを最初から定義するには、目的のアプリケーションを選択し、「New page」ボタンをクリックします。既存のページを新規ページのベースとして使用するには、目的のアプリケーション・ページを選択し、「New page (based on current)」ボタンをクリックします。いずれの場合も、図8-31に示すダイアログが表示されます。
このダイアログを使用して、割り当てた名前がページに設定されるための条件を指定します。この条件は、ページURLの一部または詳細、コンテンツ、ドメインまたは引数を使用して定義できます。XPath式も指定できます。「Add condition」をクリックして必要な各条件を追加します。
詳細なURL(たとえばhttp://www.oracle.com/contact.htmlなど)を指定する場合、ドメインとそれ以外のURL構文はページ条件に自動的に割り当てられます。たとえば、「Find in domain」オプション(oracle.com)や「Find exact URL」(/contact.html)のようになります。
追加条件を指定すると、それらがダイアログに表示されます。一致を行うときは、指定したすべての条件が満たされる必要があります。青字で表示される条件はクリックすると削除できますが、黒字で表示される条件は削除できないことに注意してください。ページを識別するには、1つ以上の条件を指定する必要があります。次に、「Next」をクリックします。図8-32に示すダイアログが表示されます。
このダイアログを使用して、ページのグループおよび名前を指定します。次に、「Finish」をクリックします。
新規ページの詳細が、図8-26に示すようなウィンドウに表示されます。このウィンドウを使用すると、ページ検出を追跡し、その定義を変更できます。
「URL diagnostics」グループ(3.2.4項「「URL Diagnostics」グループ」を参照)を使用すると、アプリケーションのヒットについてレポートされた機能URLを表示できます。これらは、特定の要件に合せてアプリケーション・レベルでカスタマイズできます。
URL診断を使用すると、アプリケーションの問題の把握に役立ちます。たとえば、特定のアプリケーションでロード時間が異常に長くかかる場合に、問題がある特定のオブジェクトまたは原因となっているサーバーをすぐに識別できます。さらに、この機能をセッション診断機能(4.1項「概要」を参照)と組み合せると、アプリケーションの問題について非常に高性能の根本原因分析を行うことができます。
選択したアプリケーションで使用するURL診断レポート・スキームを指定する手順は、次のとおりです。
「Configuration」→「Applications」の順に選択して、目的のアプリケーションを選択します。(図8-5に示すような)「Application overview」が表示されます。「Advanced」セクションをクリックし、「URL diagnostics」タブをクリックします。監視対象のURL範囲を指定するために使用される、現時点で定義済のURLパターンが表示されます。「Add new URL pattern」をクリックして新しいパターン一致スキームを定義するか、既存のパターン一致スキームをクリックして変更します。図8-33に示すようなダイアログが表示されます。
「URL match type」メニューを使用して、これから定義するスキームをすべてのアプリケーションのURLに適用するか、特定のURLのみに適用するかを指定します。後者の場合は、URL構文を指定する必要があります。この構文が「URL diagnostics」グループ内でアプリケーションについてレポートされます。定義するURLパターンが検出されたURLと一致したときにレポートされます。ワイルドカード文字(*)の使用はサポートされますが、指定する他の文字はすべてリテラルとして解釈されます。URL構文を定義しないと、アプリケーションの関連するヒットが「URL diagnostics」グループでレポートされないことに注意してください。
検出されるURL構文の一部(要素)をレポートするように指定することもできます。または、レポートされるURLを特定の引数に限定することもできます。いずれの場合も、「Add URL argument/component」をクリックします。図8-34に示すようなダイアログが表示されます。
「Scheme type」メニューを使用して、一致するURLをレポートするときに、特定のパラメータまたは要素に限定するかどうかを指定します。パラメータの場合は、レポートされるパラメータ名を指定する必要があります。要素の場合は、一致したURLから分離する要素を指定し、「Part」メニューを使用してレポートする必要がある部分を指定します。使用可能なオプションの数は、「URL component」フィールドに指定されるワイルドカード(*)の数と同じです。
たとえば、図8-35に示す要素の定義について考えます。
この場合は、*/MyShop/catalog/よりも後の部分のみがレポートされます。部分のパラメータは、「Value」定義に指定されたワイルドカードと照合されることに注意してください。たとえば、指定された値*/session=*/*には3つのワイルドカードが含まれるため、一致するURLは3つの論理部分を含むとみなされます。URL診断の定義には最大で9個のワイルドカードを指定できます。
次に、「Save」をクリックします。図8-33に示したダイアログに戻ります。
アプリケーションのパラメータと要素の定義を確認します。次に、「Save」をクリックします。5分後から一致するURLパターンが「URL diagnostics」グループでレポートされます。
除外するURLの情報
強制オブジェクト(D.4.2項「強制オブジェクト」を参照)は、レポートされるURLから自動的に外されます。この他に、セッション・パラメータおよび静的オブジェクト(イメージなど)のレポートを除外するように、アプリケーション定義を構成することをお薦めします。こうすることで、診断情報が長くなりすぎて切り捨てられることを防ぎます。
セッション診断の再生機能で表示されるアプリケーション・ページは、インラインJavaScriptコードを含む可能性があります。通常、このコードはチェックを実行するために使用されます。たとえば、指定されたサーバーに接続して、セッションが期限切れになったかどうかを判別します。このようなチェックおよびJavaScriptの他の機能は、関連するページを再生機能で表示するときに問題になることがあります。
この理由のために、アプリケーション構成機能を使用して、インラインJavaScriptコードの実行をReplay Viewerでどのように扱うかを指定できます(4.1項「概要」を参照)。JavaScriptの実行を完全に無効にするか、特定の関数またはファイルをページの再生時に置き換えるように指定できます。
実行規則の定義
アプリケーション・ページの再生時に使用されるJavaScriptの実行規則を定義する手順は、次のとおりです。
「Configuration」→「Applications」→「Applications」の順に選択して、目的のアプリケーションを選択します。(図8-5に示すような)「Application overview」が表示されます。「Advanced」セクションをクリックし、次に「JavaScript replay」タブをクリックします。現時点で定義されている実行規則が表示されます。図8-36に示すようなダイアログが表示されます。
「Disable all JavaScript execution」チェック・ボックスを使用して、選択したアプリケーションのページが再生機能で再生されるときに、ページ内のすべてのJavaScriptコードを無効にするように指定します。このチェック・ボックスを選択すると、既存の実行規則は無視されます。新しい規則を定義することもできません。デフォルトでは、このチェック・ボックスが選択されています。
「Add new rule」をクリックして新しい規則を定義するか、既存の規則をクリックして変更します。この機能が使用できるのは、「Disable All JavaScript execution」チェック・ボックスを選択していない場合のみであることに注意してください。図8-37に示すようなダイアログが表示されます。
「Rule type」メニューを使用して、定義する実行規則のタイプを指定します。次のオプションから選択してください。
Replace function: 実行時に、指定したJavaScriptの関数を削除し、オプションとしてリターン・コードで置き換えるように指定します。たとえば、Cookieがまだ有効かどうかを調べる関数を、再生時にOKという戻り値で置き換えることができます。
指定される関数の定義は、ページのインライン・コードに含まれる必要があります。外部関数を置き換えることはできません。JavaScriptコードが置き換えられるのは、レンダリングされるブラウザ・ページのみです。再生されるページのコンテンツでは置き換えられません(「HTTP content」機能でレポートされます)。
関数の定義でfunction構文と関数名の間にコメントが含まれる場合は、置換が失敗することに注意してください。たとえば、次の構文では失敗します。
function
/* some comment */
myfunction ( url ) {
.....}
アプリケーション・ページに外部関数への参照が含まれる場合は、変更した関数定義を含むファイルをアップロードして置き換えることができます。これは次に説明します。
Replace file: JavaScriptコードを含む指定のファイルを別のファイルで置き換えるように指定します。たとえば、検証ルーチンを含むファイルを、再生用に簡単な内容に置き換えることができます。このオプションを選択した場合は、置き換えるファイルの名前と拡張子を「Source name」フィールドに指定する必要があります。これらは、対応するscript要素に指定するものと同じであることが必要です。たとえば、次のファイル参照があるとします。
<script type="text/javascript" src="public/scripts/checks.js"></script>
ここでは、ファイル名checks.jsを指定する必要があります。
「Replacement file」フィールドを使用して、代替ファイルを指定します。このファイルの拡張子は.jsで、MIMEタイプはtextであることが必要です。このファイルはレポータ・システムの/opt/ruei/gui/upload/ディレクトリにアップロードされます。
次に、「Save」をクリックします。定義済のアプリケーション再生規則に行った変更は、すぐに適用されます。
置換ファイルのアップロード
置換のための.jsファイルは、レポータ・システムの/opt/ruei/gui/uploadディレクトリにアップロードされます。必要であれば、適切な規則を選択して、元のファイルを変更したものをアップロードするかまったく新しいファイルを指定することで、置換ファイルの内容を変更できることに注意してください。どちらの場合も、元のファイルの内容は新たにアップロードされるファイルで上書きされます。規則が削除されると、その規則についてアップロードされたファイルも自動的に削除されます。
アプリケーションに複数の規則が含まれ、それらが同じファイルを参照する場合、1つのバージョンのファイルのみがレポータ・ファイル・システムに保持され、そのファイルが常に最新バージョンとしてアップロードされることに注意してください。そのファイルがファイル・システムから削除されるのは、そのファイルを使用するすべての規則も削除された場合のみです。
同じJavaScriptファイルが複数のアプリケーションで使用されることは頻繁にあります。アプリケーションに指定される各置換ファイルは一意のファイルを表すことに注意してください。これは、複数のアプリケーションに対して同じファイル名が指定されるときにも該当します。たとえば、3つのアプリケーションA、BおよびCのすべてに、置換ファイルmychecks.jsが指定されているとします。この場合、3つのバージョンのmychecks.jsファイルがRUEIによって管理されます。いずれか1つのファイルを変更すると、対応するアプリケーションのみに適用され、他のアプリケーションには適用されません。
シングル・サインオン(SSO)とは、1回ログインすれば、ログインすることを再度求められることなく、複数のソフトウェア・システムのリソースにアクセスできるようになるアクセス制御方法です。アプリケーションとリソースが異なれば、サポートされる認証メカニズムも異なるため、SSOでは様々な資格証明を内部的に変換および保存して、初期認証で使用された資格証明と照合する必要があります。SSOには次の利点があります。
ユーザー名とパスワードの様々な組合せを管理する煩雑さを軽減します。
同じIDに対するパスワードの再入力に要する時間を省きます。
ITヘルプ・デスクに対するパスワード関連の問合せの数を減らすことで、ITコストを削減します。
SSOでは、中央の認証サーバーを使用し、他のすべてのアプリケーションおよびシステムがこれらのサーバーを認証目的で利用します。この技術が、ユーザーが自分の資格証明を複数回入力することを頻繁に求められないようにする技術と組み合せられます。
SSO対応アプリケーションが正しく監視されるようにするには、実際の環境で使用する認証サーバーを構成する必要があります。このためには、SSOプロファイルを作成します。
SSOサーバーでは、ユーザー・プロファイルを管理し、認証されたユーザーにログイン・ページを表示します。次に、アプリケーションがSSOサーバーと通信し、一時トークンを検証します。図8-38に、アプリケーション認証がSSOサーバーで有効化されている場合に機能する仕組みを示します。
図8-38に示す認証フローは、次の順序を取ります。
ユーザーが、保護されたURLへのアクセスを試行します。アプリケーション・サーバーが、リクエストされたアプリケーションの認証Cookieが存在するかどうかをチェックします。Cookieが見つかった場合は、ユーザーがすでにログオンしていることを意味し、追加認証は不要です。
ユーザーは、アプリケーション・サーバーによってSSOサーバーにリダイレクトされます。また、アプリケーション・サーバーは、アプリケーションURLをSSOサーバーに提供し、SSOサーバーがユーザー・ログオン後の移動先を把握できるようにします。SSOサーバーは、既存の認証Cookieを検証することで、ユーザーが(別のアプリケーションによって)認証済かどうかもチェックすることに注意してください。
ユーザーが既存の認証Cookieに基づいて認識されない場合、SSOサーバーは、ログイン・ページでユーザーの資格証明を要求します。資格証明は、ユーザーによってユーザー名とパスワードの組合せで指定されます。
ユーザーの資格証明が、SSOサーバー・データベース内の対応するエントリと照合されます。検証されると、SSO Cookieによって認証が維持されます。このCookieの名前は、SSOプロファイルの作成時に指定する必要があります。
SSOサーバーが、ユーザーの属性をフェッチします。実際にフェッチされる属性は実装固有であり、RUEIには無関係です。
SSOサーバーが、手順2で提供されたURLを使用して、フェッチされた属性をパートナ・アプリケーション・サーバーに渡します。トークン引数がこのURLに追加されることに注意してください。このトークン引数の名前は、SSOプロファイルの作成時に指定する必要があります。アプリケーション・サーバーは、通常、ユーザーへの独自のCookieの発行も行います。これは、アプリケーションまたはスイートの定義中に構成されます。
最後に、手順1、2および5で使用されるネットワーク回線は、RUEIの監視対象トラフィックの有効範囲内である必要があることに注意してください。
SSOプロファイルとSSOアプリケーション
SSOプロファイルとSSOアプリケーションは、密接に関連していますが、RUEI内では独立したエンティティとしてレポートされることを理解しておく必要があります。このため、SSOプロファイルとSSOアプリケーションの定義は、相互排他的にする必要があります。つまり、それぞれが独自のドメインおよびCookieに基づく必要があります。こうしておかないと、監視対象トラフィックはアプリケーション関連トラフィックとしてレポートされ、拡張レポート作成による利点は得られません。
SSOプロファイルを定義する手順は、次のとおりです。
「Configuration」→「Applications」→「Single Sign-On」の順に選択し、「New SSO profile」をクリックします。図8-39に示すダイアログが表示されます。
SSOプロファイルの名前を指定します。これは、スイート、サービス、アプリケーションおよびSSOプロファイルを通じて一意である必要があります。SSOプロファイルの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、SSOプロファイルの有効範囲を指定します。有効範囲はページURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「Filter preview」列に表示されます。
|
注意: SSOプロファイル、アプリケーション、スイートおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。こうしておかないと、予期しない結果がもたらされる可能性があります。一致規則の適用順序を制御する方法は、12.8項「RUEI内でのルール順序設定の制御」を参照してください。 |
最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。プロファイル名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字(*)は「Find Port」フィールドには指定できません。標準以外のポート(つまりポート80/443以外)に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、SSOプロファイルは関連付けられないことに注意してください。指定できるポート番号は1つのみです。追加のポートを指定する必要がある場合は、新しいSSOプロファイルが作成された後で追加のフィルタとして指定してください。
ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURLの組合せ情報を指定しないことはできません。フィルタの適用順序を制御する方法は、12.8項「RUEI内でのルール順序設定の制御」を参照してください。
次に、「Next」をクリックします。図8-40に示すダイアログが表示されます。
このダイアログを使用し、使用しているSSO認証サーバーに関する情報を指定します。セッションCookie名、認証トークンを含んでいるURL引数、および監視対象トラフィックでのユーザーの識別方法を指定する必要があります。これは通常、URL引数と値を使用して定義します。ただし、Cookie、リクエスト・ヘッダーまたはレスポンス・ヘッダーあるいはXPath式で指定することもできます。
次に、「Finish」をクリックします。指定したSSOプロファイル定義の概要が表示されます。例を図8-41に示します。
この概要では、定義したSSOプロファイルのサマリーが示され、必要に応じて、その定義を変更できます。この詳細は次の項に記載されています。
ユーザー識別を定義した結果は、「XLS User Information」レポートの「Clients」カテゴリで確認できます。レポートの詳細は、第2章「レポートの操作」を参照してください。
SSOプロファイルを定義後に変更するには、その概要を使用します。次のタブがあります。
Identification: SSOサーバーの有効範囲を、ページURLの1つ以上の部分一致を使用して指定します。ページは、定義済のフィルタがページのURLに一致すると、SSOサーバーに割り当てられます。新規フィルタを追加するには、「Add new filter」をクリックします。既存のフィルタを変更するには、そのフィルタをクリックします。図8-42に示すようなダイアログが表示されます。
ダイアログの最下部にあるメモは、現在のルール順序設定スキームを示します。この詳細は、12.8項「RUEI内でのルール順序設定の制御」に記載されています。
Configuration: 使用される認証トークンとCookieを指定します。
User: ユーザーIDをアプリケーション内で識別する方法を指定します。これが未定義で、SSLクライアント証明書が存在する場合、この証明書が使用されます。
SSO対応アプリケーションの動作およびレポートが正しいかどうかを検証する場合、重要ポイントは、ユーザーIDが正しいかどうかを検査することです。データ・ブラウザ内のレポートを定期的に確認することをお薦めします(「All sessions」→「User Id」→「Sessions and pageviews」)。たとえば、未識別(匿名)ユーザーの数が予想より多い場合などです。
また、SSO対応アプリケーション内のURLがアプリケーション関連データとしてレポートされていないかどうかも検証する必要があります。レポートされている場合は、問題があることを示している可能性があります。
