| 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 |
|
前 |
次 |
この章では、監視するWebページを識別する方法について説明します。特に、追加情報を利用する必要があるWebページおよび特定のテキスト文字列の出現を監視する必要があるページを定義する方法について説明します。また、規則指定機能と他の高度な機能の使用方法についても説明します。最後に、SSOベースの環境におけるトラフィックの監視について説明します。
URL引数
アプリケーション、スイート、サービス、およびユーザーとクライアントのID識別のために構成されるURL引数は、エンコーディングなしで(%、&、=記号を除く)指定する必要があることに注意してください。
RUEIにおけるページの識別は、アプリケーションに基づいて行われます。一般的に、アプリケーションはWebページの集合です。通常、Webサイトのページは特定のアプリケーションにバインドされているためです。アプリケーション内の各ページには名前が割り当てられていて、それぞれのページはグループに属します。たとえば、「MyShop » Contact » About us」は、MyShopアプリケーション内のContactグループの「About us」ページを指します。
各アプリケーションには、アプリケーションの有効範囲を定義するページ・ネーミング・スキームが関連付けられています。スキームの指定には、ドメイン名の一部またはURL構文の一部、あるいはその両方の組合せを使用できます。また、ページ・ネーミング・スキーム(ページ・タグ付けやHTMLページのタイトル部分など)は、アプリケーション定義を微調整する際にも指定できます。
RUEIで検出される各ページに対し、スキームは、存在するアプリケーション定義を使用して名前を割り当てます。これらの定義を使用して識別できないページに関する情報は廃棄されるため、レポートおよびデータ・ブラウザでは使用できません。
アプリケーション・ページは、自動検出できるのみでなく、手動で定義することもできます。手動定義が特に役立つのは、URL構文に一貫性のない場合や、識別されたページにサブページが含まれる場合、またはアプリケーションによって自動的に割り当てられた名前とは違う名前を割り当てる必要がある場合です。手動で定義されたこれらのページは、アプリケーション定義で自動的に識別されたページより優先されることに注意してください。
現時点で定義されているアプリケーションとそのグループおよびページの構造を表示するには、「構成」→「アプリケーション」→「アプリケーション」の順に選択します。例を図8-1に示します。
8.3項「アプリケーションの定義」で、タグ・ベースまたはネットワーク・ベースのデータ・コレクタを使用してアプリケーションを監視する方法について説明します。
タグ・ベースのアプリケーションではタグ・データ・コレクタが使用されますが、ネットワーク・データ・コレクタは使用されず、アプリケーション構成でヘッダー、XPathおよびコンテンツ・ソースからのデータの収集は適用されません。たとえば、ユーザーIDおよびコンテンツのメッセージはタグ・ベースのアプリケーションに適用されません。タグ・ベースのアプリケーションのユーザーを識別するには、oraInfo.userタグを使用します。ブラウザ例外を構成するには、コンテンツ・メッセージ内の特定の"ブラウザ例外"ソースを使用し、Javascriptライブラリにより送信されるCookieを使用するようにセッション・トラッキング構成を'Oracle'に設定します。
しかし、タグ・ベースのアプリケーションを使用する場合、複数のメトリック(ヒット、アプリケーション言語、アプリケーション・テリトリ、詳細なタイミングやサイズなど)およびリプレイ機能は使用できません。
これらの制限を回避するために、タグ・ベースのコレクタに加えてネットワーク・データ・コレクタをインストールできます。10.2項「フレームワーク例外によるアプリケーション定義の微調整」の説明に従ってフレームワーク例外を作成して、タグ・ベースのトラフィックとネットワーク・ベースのトラフィックの両方が結合されたハイブリッド構成を作成します。
タグ・ベースおよびネットワーク・ベースの監視の設定の詳細は、RUEIインストレーション・ガイドの「RUEIソフトウェアのインストール」を参照してください。
アプリケーションを定義する手順は、次のとおりです。
「構成」→「アプリケーション」→「アプリケーション」の順に選択し、「新規アプリケーション」をクリックします。図8-2に示すダイアログが表示されます。
アプリケーションの名前を指定します。これは、スイート、サービス、SSOプロファイルとSSOアプリケーションを通じて一意である必要があります。アプリケーション名はレポートされるページに付加されるため、定義されたアプリケーション名をできるだけ短くすることをお薦めします。アプリケーションの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、アプリケーションの有効範囲を指定します。有効範囲はページURLを使用して定義されます。この情報を入力すると同時に、入力した定義が「フィルタのプレビュー」列に表示されます。
最高レベルのフィルタはドメインです。アプリケーション名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字(*)は「ポートの検索」フィールドには指定できないことに注意してください。指定できるのはポート番号1つのみです。さらにポートを指定する必要がある場合は、新しいアプリケーションが作成された後で追加のフィルタとして指定してください。
特定のフィールドではワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、ドメインとURL引数の組合せによるその他の情報を指定しないことはできません。
|
注意: スイート、SSOプロファイル、アプリケーションおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。たとえば、ドメインoracle.comでフィルタリングされるアプリケーションと、oracle.com/application_servletでフィルタリングされる別のアプリケーションがある場合、予測できない結果が発生することがあります。一致規則の適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。 |
|
注意: アプリケーション、スイート、サービス、およびユーザーとクライアントのID識別のために構成されるURL引数は、エンコーディングなしで(%、&、=記号を除く)指定する必要があります。 |
一致対象とするURL GET引数を指定することもできます。この機能を使用する場合は、引数名と引数値の両方を揃えて指定することで初めて、検出されたページURLと一致することに注意してください。つまり、部分一致はサポートされていません。次に、「次へ」をクリックします。図8-3に示すダイアログが表示されます(「HTMLタイトル」がデフォルトで選択されています)。
|
注意: 「タグ・ベース・アプリケーション」チェック・ボックスを選択した場合、次のページ・ネーミング・スキーマが表示されます。
|
タグ・ベースのアプリケーションを作成する場合は、そのオプションを選択し、「終了」をクリックします。タグおよびネットワークのデータ・コレクタの詳細は、8.2項「タグ・ベースのアプリケーション」を参照してください。
ネットワーク・データ・コレクタ・ベースのアプリケーションを作成する場合、このダイアログでは、アプリケーション内のページに使用する自動ページ・ネーミング・スキームを指定できます。各アプリケーションに対して指定できるスキームは1つのみです。次のオプション・グループがあります。
ページのタグ付け: 標準スキーム(「Coremetrics」など)とカスタム・スキームのいずれを使用するかを指定します。カスタム・スキームの場合は、カスタム・タグの名前を指定する必要があります。「HTMLタイトル」オプションは、ページの<title>タグにあるテキストを使用してページを識別する必要があることを指定します。このオプションの使用方法の詳細は、8.3.4項「詳細設定の使用によるページとオブジェクトの処理の制御」を参照してください。RUEIでサポートされているページ・タグ付けの汎用スキームの構造および処理は、付録A「タグ付け規則」に記載されています。
クライアント・リクエスト: ページをそのURL構文に基づいて識別することを指定します。次のオプションにより、URLのどの部分を使用するかを指定します。
URL引数: ページ・ネーミングは、URL内の指定した引数に基づきます。ASCII文字のみが許可され、特殊文字("&"および"|"など)をURLでエンコードする必要があることに注意してください。
URL: ページ・ネーミングが、ビジターのブラウザのロケーション・バーに表示される完全なドメインとURLに基づきます。このスキームは規則指定を使用するときに特に役立ちます。
URLディレクトリ: URLのディレクトリ部分のみを使用します。URLの各部分は、図8-4に示されています。
URLベース: URLのメイン・ディレクトリとファイル名(ファイル拡張子は除く)の部分を使用します。
URL全体: URLのメイン・ディレクトリ、ファイル名(ファイル拡張子は除く)および構成済の引数を使用します。このオプションを選択すると、ページ名に含める引数を指定するように求められます。このダイアログ・ボックスでは、複数の引数はアンパサンド(&)文字で区切る必要があります。たとえば、frmActionパラメータを定義した図8-4のURLは、myshop » shop » NL index frmAction=buyというページ名になります。
リクエストのヘッダー: ページ・ネーミングでクライアント・リクエスト内の指定されたヘッダーを使用することを指定します。ヘッダー名で使用できるのはASCII文字のみです(「:」などの特殊文字は使用できません)。
リクエストのXPath: クライアント・リクエストに適用されたXPath式に基づいてページを識別することを指定します。XPath式の使用方法の詳細は、付録F「XPath問合せの使用」を参照してください。
JSONリクエストのXPath: JSONクライアント・リクエストに適用されたXPath式に基づいてページを識別することを指定します。JSONリクエスト用XPath式の使用の詳細は、F.6項「JSONコンテンツでのXPath」を参照してください。
HTTPメソッドおよびURL: ページ・ネーミングが、ビジターのブラウザのロケーション・バーに表示されるHTTPメソッドおよび完全なドメインとURLに基づきます。これにより、REpresentational State Transfer (REST)スタイルのアプリケーションのサポートが可能になります。このネーミング・スキーム・オプションは、HTTPメソッドおよびスペースで区切られた完全なURLをレポートします。アプリケーション定義を作成した後、アプリケーション概要でネーミング・スキームを選択して、URL規則指定を定義し、翻訳リストを作成します。
これらいずれかのオプションを選択した場合、使用方法の詳細は、8.3.4項「詳細設定の使用によるページとオブジェクトの処理の制御」を参照してください。
サーバー・レスポンス: サーバーのレスポンスに基づいてページを識別することを指定します。次のオプションがあります。
レスポンスのヘッダー: サーバー・レスポンス内で指定されたヘッダーに基づいてページを識別することを指定します。
レスポンスのXPath: サーバーのレスポンスに適用されたXPath式に基づいてページを識別することを指定します。XPath式の使用方法の詳細は、付録F「XPath問合せの使用」を参照してください。
JSONレスポンスのXPath: JSONサーバーのレスポンスに適用されたXPath式に基づいてページを識別することを指定します。XPath式の使用の詳細は、F.6項「JSONコンテンツでのXPath」を参照してください。
手動: アプリケーション・ページを自動検出せずに手動で定義することを指定します。このオプションを選択すると、監視するアプリケーションに関連付けられているすべてのページを手動で定義する必要が生じてくるため、注意してください。ページの手動定義の詳細は、8.3.20項「ページの手動識別」を参照してください。このオプションがデフォルトです。
次に、「終了」をクリックします。指定したアプリケーション定義が表示されます。例を図8-5に示します。
この概要には、定義したアプリケーションのサマリーが示されます。これには、アプリケーションの名前、これまでに一致した一意のページ数、最後に識別されたページの日付が含まれます。直前の3日間にアプリケーションについて識別されたページがない場合は、アプリケーションが現在機能していないことを示す警告のアイコンが表示されます。
タグ・ベースのアプリケーションを作成した場合、8.3.1項「ブラウザJSライブラリ設定の定義」の説明に従ってブラウザJSライブラリを定義する必要があります。
作成したアプリケーションはすぐに有効になります。これは、設定条件に一致するトラフィックがすべて記録されるという意味です。「データ収集が有効」ボックスの選択が解除されているときには、そのアプリケーションは存在しないものとしてトラフィック・ルールが適用されます。既存データはそのまま残り、アプリケーションはいつでも有効に戻すことができます。
画面の下部のタブでは、アプリケーションの具体的な項目の情報が表示されます。たとえば、「識別」セクションではアプリケーションに対して現在定義されているフィルタ基準のサマリーが表示されます。また、「ページ」セクションでは、使用されるページ・ネーミング・スキーム、未分類のページのレポート設定、ページ・ロード満足度のしきい値、アプリケーションに所属するこれまでに識別されたページが示されます。それぞれのセクションの詳細は次の各項で説明します。
|
注意: アプリケーションを削除すると、構成とそれまで測定されたデータがすべて破棄されます。この操作は元に戻すことができません。 |
|
注意: URLベースでないページ・ネーミング・スキームを使用してタグ・ベースのアプリケーションを作成し、後から(「タグ・ベース・アプリケーション」チェック・ボックスを選択解除することにより)そのアプリケーションを編集してタグ・ベースでないアプリケーションにした場合、そのページ・ネーミング・スキームは相当するページ・ネーミング・スキームに変換されます。たとえば、「HTMLタイトル(ブラウザJSライブラリ)」スキームは「HTMLタイトル」になります。以前はタグ・ベースでなく、URLベースでないページ・ネーミング・スキームを使用していたアプリケーションに対して「タグ・ベース・アプリケーション」チェック・ボックスを選択すると、そのネーミング・スキームは「Oracle (ブラウザJSライブラリ)」に変換され、すべてのルーリングが削除されます。 |
タグ・ベースのアプリケーションを作成した場合、ブラウザJSライブラリ(監視対象のタグとして機能するアプリケーションによって提供されるURL)を定義する必要があります。
アプリケーションまたはスイートで使用されるブラウザJSライブラリを指定する手順は、次のとおりです。
「構成」を選択し、「アプリケーション」または「スイート」を選択します。必要なアプリケーションまたはスイートを選択して、その概要を表示します。例を図8-1に示します。「ページ」タブ→「構成」タブの順にクリックします。
「ブラウザJSライブラリ」設定をクリックします。図8-6に示すダイアログが表示されます。
リクエストされるオブジェクトのURLを指定し、オプションで、ページ上のオブジェクト数を記録するオプションまたは画面解像度を記録するオプション(あるいは、その両方)を有効にします。画面解像度に関連するデータを参照するには、「データの参照」を選択し、「ユーザー・フロー完了」または「すべてのセッション」を選択します。「クライアント画面解像度」に関連するデータを参照できるようになります。
「ブラウザ例外」オプションを選択した場合、すべてのJavaScriptエラーがRUEIに送信されます。後でこれらのエラーを確認するには、「データの参照」→「ブラウザ例外」を選択します。
ブラウザ・ヒットを確認するには、「すべてのページ」→アプリケーション・ヒットとブラウザ・ヒットを選択します。「URL」フィールドに、ワイルドカードを含まない絶対パスを指定します。監視対象のアプリケーションが別のドメインでホストされている場合、スキームを含む完全URIを指定します(例: http://myhost.com/images/marker.gif)。
|
注意: タグ・ベースのアプリケーションを定義する場合、ブラウザJSライブラリURLは、強制オブジェクトとして定義されている拡張子を持つファイルを参照する必要があります(12.16項「ページとしてのオブジェクトのレポートの制御」を参照)。 |
ブラウザのナビゲーションに関するタイミングのレポートが必要な場合は、「ナビゲーション・タイミング」オプションを選択します。ナビゲーションのタイミングのレポート方法の詳細は、12.19項「ページ・ダウンロードおよびブラウザ時間レポートの最適化」を参照してください。
「JavaScriptの生成」をクリックしてJavaScriptコードをダウンロードし、アプリケーション・ページに次の変更を加え、目的のアプリケーション・ページにコードを含めます。
<head>タグと</head>タグの間に次の行を追加します。
<script type="text/javascript" src="ruei_library.js"></script>
前述の例は、JavaScriptライブラリがページ自体と同じwebserverパスにあることを前提とします。
次を<body onLoad>タグまたはページのレンダリングが終了している適切な場所に追加します。
<body onLoad="oraInfo.sendPageLoad();">
以前のリリースのRUEIでは、次のHTMLが推奨されていました。このコードは引き続きサポートされます。
<body onLoad="oraInfo.sendData();">
8.3項「アプリケーションの定義」の説明に従って、アプリケーションのページ・ネーミング・スキームとして「Oracle (ブラウザJSライブラリ)」を選択した場合は、次に説明するようにoraInfo.pageプロパティも設定する必要があります。
セキュリティ上の理由で、ワイルドカード文字の使用はサポートされていないことに注意してください。
ネットワーク・データ監視を使用するアプリケーションおよびスイートの場合、デフォルトでブラウザJSライブラリは構成されておらず、ブラウザJSライブラリを自分で定義しなければ、ページ・ブラウザ時間がゼロとしてレポートされます。また、レポートされたページ・ロード時間はページ・ブラウザ時間を含まないため、ページ・ロード/読取り時間分析が不正確になる可能性があります。ページがCDNサーバー(Akamaiなど)からリクエストされている場合、OnLoadイベントを使用すると、CDNで処理されるオブジェクトのレンダリング時間が含まれます。
タグ・ライブラリのプロパティ
タグ・ベースのアプリケーションを作成した場合、RUEIでは、予約されたタグ・ライブラリ・プロパティoraInfo.titleを使用してページ・タイトルが自動的にレポートされます。
さらに、JavaScriptコードを使用して次のプロパティも指定できます。
表8-1 タグのプロパティ
| 名前 | デフォルト | 説明 |
|---|---|---|
|
oraInfo.url |
document.location.href |
RUEIによってページURLとしてレポートされる値。 |
|
oraInfo.page |
RUEIによってページ名としてレポートされる値。 |
|
|
oraInfo.pagegroup |
RUEIによってページ・グループとしてレポートされる値。 |
|
|
oraInfo.action |
RUEIによってアクションとしてレポートされる値。 |
|
|
oraInfo.user |
RUEIによってユーザーとしてレポートされる値。 |
次に例を示します。
<script type="text/javascript" src="ruei_library.js"></script> <script type="text/javascript"> oraInfo.page = 'homepage'; oraInfo.action = 'view'; </script>
タグ・ライブラリを使用したページ・クリックの監視
タグ・ベースのアプリケーションを作成した場合、onclick oraInfo.sendActionプロパティを使用してページ・クリックを監視できます。たとえば、次のコードでは、ユーザーによる"Click here"リンクのクリックがレポートされます。
<a href="#" onclick="oraInfo.sendAction('clickAction');"> Click here</a>
ブラウザJSライブラリ・リンクの手動デプロイメント
8.3.1項「ブラウザJSライブラリ設定の定義」の手順4のかわりに、自分で指定したマーカー・オブジェクトへのリクエストを作成することもできます。リクエストが有効にされたときにRUEIはこれを検知し、ブラウザ時間になるようにリクエストの開始時間を記録します。指定するURL検索パターンはトリガーされるリクエスト内のURL検索パターンと一致している必要があります。
次に例を示します。
onLoad="m=new Image(); m.src='http://myhost.com/marker.gif?apikey=yourAPIkey&' + new Date().getTime();"
ここで、yourAPIkeyは、ブラウザJSライブラリ構成画面で指定したAPIキーです(図8-6を参照)。イベントは、HTMLページのBODY部分、またはその他の必要な場所(フラッシュ・プログラム内など)に含めることができます。
前述の例には、ブラウザ例外、ナビゲーション・タイミング、オブジェクト・カウントおよび画面解像度は含まれていません。これらを含める場合はJavaScriptライブラリが必要です。
ブラウザJSライブラリでのカスタム・ディメンションの使用
3.12項「カスタム・ディメンションの使用」の説明に従って「カスタム・タグ(ブラウザJSライブラリ)」ディメンションを作成する場合、これらのディメンションに関連するプロパティを設定できます。たとえば、製品、グループおよびベンダーの3つのレベルで構成されるディメンションを作成した場合は、次のコードを追加してページのプロパティを設定できます。
<script type="text/javascript" src="ruei_library.js"></script> <script type="text/javascript"> oraInfo.product = 'x9991'; oraInfo.group = 'Servers'; oraInfo.vendor = 'Oracle'; </script>
この3レベル・ディメンションを作成すると、RUEIによってデータが収集され、後からこのデータを参照してレポートで使用できます(3.12項「カスタム・ディメンションの使用」を参照)。
8.1項「ページのネーミング」に記載されている定義されたページ・ネーミング・スキーム以外に、ページ翻訳の使用によってアプリケーション・ページのレポートも変更できます。これらにより、ページのレポートされたpage-group » page-name仕様に行われる変換を指定できます。
ページ翻訳の定義
ページ翻訳を定義する手順は、次のとおりです。
「構成」→「アプリケーション」→「アプリケーション」の順に選択して、目的のアプリケーションを選択します。(図8-5に示したような)「アプリケーション概要」が表示されます。
「ページ」タブ→「ページ翻訳」タブの順にクリックします。現在定義されているページの説明が表示されます。「新規翻訳の追加」をクリックして新しい説明を定義するか、既存の説明をクリックして変更します。図8-7に示すダイアログが表示されます。
元のページIDおよびレポートされるグループと名前を指定します。元の値を形式group|nameで指定する必要があります。次に、「保存」をクリックします。
環境間のページ翻訳の移動
ページ翻訳は、アプリケーション自体と同時に作成することをお薦めします。そのためには、開発中のアプリケーションをRUEIで開始し、そこで定義されているページ翻訳を取得した結果に基づいて微調整するのが最も確実です。
デプロイの準備ができると、アプリケーションは本番環境に移動されます。その新しい環境が別のRUEIインストールによって監視される場合でも、アプリケーションのページ翻訳を手動で再作成する必要はありません。そのかわりに、ダウンロード機能を使用してその最新定義を取得し、生成されたファイルをアップロードして新しいRUEIインストールで使用することができます。
事前定義済のページ翻訳のリストを含むファイルをアップロードするには、次の手順を実行します。
必要なアプリケーションを選択した後、「ページ」タブをクリックします。「アップロード・リスト」をクリックします。図8-8に示すダイアログが表示されます。
「参照」ボタンを使用して、ページ翻訳ファイルの名前を検索および指定します。アップロードされるファイルの拡張子は.txtであることが必要です。必要に応じて、「ファイル・エンコーディング」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートの詳細は、付録G「各国語サポートの使用」を参照してください。ページ翻訳が重複した場合には、最後の翻訳が使用されます。ファイルには、1行に1つの翻訳のみを含めることができ、ページ・グループとページ名をタブで区切ります。次に、「マージ」をクリックします。
現在定義されているページ翻訳をダウンロードするには、「ダウンロード・リスト」をクリックします。ブラウザの構成方法によって異なりますが、ファイルの保存場所の指定を求められるか、定義済のデフォルトの場所にファイルがすぐに保存されます。
8.3.23項「アクション・ネーミング・スキームの定義」で説明するように、アクション・ネーミング・スキームを、HTTPメソッドおよびURLなどに使用する場合、このスキームを、アクション翻訳を備えた、指定されたHTTPメソッドおよびURLなどに関連付けることができます。
アクション翻訳の定義
アクション翻訳を定義するには、次の手順を実行します。
「HTMLタイトル」スキームまたはクライアント・リクエストのページ・ネーミング・スキームのいずれか(「URLベース」など)を選択した場合、そのページ・ネーミング・スキーム内の「拡張」タブを使用して、これらのスキームの運用を微調整できます。「HTML title」スキームの場合は、図8-10に示すダイアログが表示されます。
図8-10 「Edit Application Page-Naming Scheme」ダイアログ
時間認識
「時間認識」メニューを使用して、ページを識別するために非強制オブジェクトを使用するかどうかを制御できます。図8-11に示す例について考えます。
この場合、ページ識別に使用することができる3つの非強制オブジェクト(home.jsp、sub.jspおよびdown.jsp)があります。
有効なオプション(デフォルト)が「時間認識」メニューに指定されている場合、最初のオブジェクト(home.jsp)のみがページとして識別され、最後のオブジェクトがヒットしてから1秒以内にヒットが検出されなくなるまで、以降のすべてのヒットがオブジェクトとみなされます。ただし、「有効」の場合には、3つの非強制オブジェクトそれぞれ(jspなど)が検出時刻は考慮されずに別のページとして識別されます。強制オブジェクトの詳細は、12.16項「ページとしてのオブジェクトのレポートの制御」を参照してください。
大/小文字の制御
「拡張」タブにある「小文字変換」メニューを使用すると、ページ名を小文字に変換するかどうかを指定できます。表8-2に、使用可能なオプションを示します。
表8-2 大/小文字制御オプション
| オプション | 説明 |
|---|---|
|
いいえ |
ページ名を元の大/小文字のまま維持します。これがデフォルトです。 |
|
ルーリング前 |
選択したアプリケーション、スイート、サービスについてレポートされるページ名を、「ルーリング」タブで定義されているすべてのルールを適用する前に小文字に変換します。テスト入力および検索式は小文字で入力する必要があります。 |
|
ルーリング後 |
選択したアプリケーション、スイート、サービスについてレポートされるページ名を、「ルーリング」タブで定義されているすべてのルールを適用する後に小文字に変換します。 |
サブヘッダーによる代用
「HTMLタイトル」ページ・ネーミング・スキームを選択した場合は、ページの<title>タグにあるテキストがページの識別に使用されます。このテキストが見つからない場合は、サブヘッダー<H1>、<H2>および<H3>を使用できます。このためには、「サブヘッダー代替」メニューを使用してこの機能を制御します。デフォルトでは、サブヘッダーは使用されません(「無効」)。
リダイレクトの処理
クライアント・リクエストベースのいずれかのスキーム(「URLベース」など)を選択して、「拡張」タブをクリックすると、図8-12に示すダイアログが表示されます。
「ページの処理」メニューを使用して、URL内のリダイレクトをどのように処理するかを指定します。表8-3に示すオプションがあります。
表8-3 ページ処理オプション
| 設定 | 説明 |
|---|---|
|
最終ページ |
ページ名を決定するために最終ページのURLのみを使用することを指定します。これがデフォルトです。 |
|
リダイレクト・ネーミング |
最終ページの前でリダイレクトから得られる情報を使用してページを識別することを指定します。ない場合は、最終ページの情報が使用されます。 |
|
リダイレクトがなるページ |
リダイレクトが実際に識別されるページになるように指定します。最初のリダイレクトがページ作成に使用され、その後のすべてのリダイレクトは作成されたページのオブジェクトになることに注意してください。アプリケーションのレポートに及ぼす結果をよく理解した場合のみ、このオプションを選択することを強くお薦めします。 |
各アプリケーション定義では、使用するページ・ネーミング・スキームおよびユーザー識別スキームを指定する必要があります。また、必要に応じて、特定のアプリケーション・ページで表示されたときにレポートする必要のあるコンテンツ・メッセージを指定することも可能です。これらの各定義は、規則指定機能を使用して拡張できます。追加の一致規則を指定できるようになり、それによって選択したページ・ネーミング・スキーム、ユーザー識別スキームまたはメッセージの仕様を微調整します。
ページ・ネーミングの規則指定機能を使用しているときには、一致するURLについてのみレポートされます。URLが一致しない場合、完全に無視されます。規則指定機能は、自動(手動ではない)ページ・ネーミング・スキームおよびXPathベース(リテラルではない)のコンテンツ・メッセージのみで使用できることに注意してください。
推奨される使用方法
規則指定は複雑であるため、選択したアプリケーションの適切なスキームまたはメッセージ構文を十分理解しているユーザーのみがこの機能を使用することをお薦めします。たとえば、URLベースのページ・ネーミング・スキームの場合、選択したアプリケーションの基礎となるURL構文も明確に理解しておく必要があります。
|
注意: 「小文字変換」オプションで「ルーリング前」設定が適用されている場合、テスト入力および検索式は小文字で入力する必要があります。 |
ルールの定義
アプリケーションの規則指定の使用を指定するには、次の手順を実行します。
「構成」を選択し、「アプリケーション」を選択します。目的のアプリケーションをクリックして概要を表示します。例を図8-1および図10-4に示します。
必要な規則指定の使用方法に応じて、ページ・ネーミング・スキーム(「ページ」タブ内)、適切なユーザー識別スキーム(「ユーザー」タブ内)、または適切なコンテンツ・メッセージの仕様(「コンテンツ・メッセージ」タブ内)をクリックします。図8-13に示すようなダイアログが表示されます。
図8-13 「Edit Application Page-Naming Scheme」ダイアログ
「ルーリング」タブをクリックして、使用する規則と、規則を評価する順序を指定します。図8-14に示すダイアログが表示されます。
このダイアログを使用し、新しい規則を定義するか、既存の規則を削除します。各規則のコンテキスト・メニューを使用して、適用順序を変更することもできます。「新規の一致ルールの追加」項目をクリックし、新しい一致規則を定義します。図8-15に示すようなダイアログが表示されます。
規則の次の要素を指定します。
入力値: 予期されるスキーム(URLまたはページ・タグ付けなど)またはメッセージ仕様の構文を指定します。通常、受信したスキームまたは仕様を解釈するためのテンプレートを指定します。
検索式: 一致する必要があるスキームの定義または仕様を指定します。これは通常、必須のパラメータまたは要素からなるシーケンスで表されます。
ページ・グループ: 受信したページ・ネーミング・スキームからページ・グループを識別する方法を指定します。これが未指定の場合、ページ・グループは空のままになります。このフィールドを使用できるのはページ・ネーミング規則のみです。
ユーザーID/ページ名/コンテンツ・メッセージ: 受信したスキームまたは仕様からページ名、ユーザーIDまたはコンテンツ・メッセージを識別する方法を指定します。
クライアント・ブラウザ/クライアント・ブラウザ・バージョン: 受信したユーザー・エージェント文字列からどのようにクライアント・ブラウザ/クライアント・ブラウザ・バージョンを識別するかを指定します。
規則の要素を指定したら、「ルールのチェック」ボタンをクリックして、定義した規則が指定されている検証値と一貫性があることを検証できます。結果のウィンドウを展開すると、一致するプレースホルダのサマリーを表示できることに注意してください。例を図8-16に示します。
次に、「保存」をクリックします。図8-14に示したダイアログに戻ります。
必要なすべての規則を定義したら、「ルールのチェック」をクリックして、定義したすべての規則を検証値に対して検証できます。各検証値は、対応する規則に関連している必要があります。検証の後で、各規則の横にステータスを示すアイコンが表示されます。検証が失敗した規則については、マウスを重ねるとボックスに追加の情報が表示されます。図8-17に示す例について考えます。
最初の規則は定義済の検証値と一貫性があり、正常に検証されています。ただし、2番目の規則は非常に汎用性が高いため、複数の評価規則がこの規則と一致すると警告されます。実際に、汎用性が高いために関連する検証値がすでに正常に適用されてしまい、後続の規則を適用できません。つまり、3番目の規則が使用されません。このため、2番目の規則ではなく3番目の規則についてエラーがレポートされます。ただし、2番目の規則を移動して最後の規則にすると、3つの規則が正常に検証されます。
エラーがレポートされた規則指定の定義を保存することは可能ですが、問題があれば規則指定の定義を保存する前に解決することを強くお薦めします。次に、「保存」をクリックします。規則指定の定義の変更は5分以内に有効になります。
URL一致に関する規則指定
URL一致では大/小文字が区別され、URL(一致の後)は小文字に変換されることに注意してください。規則指定の後で、一致したスラッシュはページ名において空白に置き換えられます。
また、URL構造に基づいてルーリングを実行する場合、「URL」ページ・ネーミング・スキームのみを使用することをお薦めします。これは、他のURLベースのネーミング・スキームが初期フォーマットの一部のフォームを実行するためです。
ユーザー識別に関する規則指定
ユーザー識別で規則指定を使用する方法は、ページ・ネーミングの場合と同じですが、ユーザーIDが選択したスキームから識別される方法を指定すること、ページ・グループ識別がサポートされないことが異なります。次の例について考えてください。指定したユーザー識別スキームがCookieに基づき、各Cookieは次の構造をしています。
ORA_UCM_INFO=5~DVJ88287~John~Doe~john.doe@myshop.com~USA~en~33~44~5~~1;
このCookieの電子メール・アドレス部分のみに基づいてユーザーを識別するようにします。この場合、次のように指定できます。
検索式: %\~%\~%\~%\~%\~%
ユーザーID: %5
検証値は、上記の例のCookieまたは同じ構造の他のCookieの例を使用して指定できます。
クライアント・ブラウザの規則指定
クライアント・ブラウザの規則指定を使用すると、モバイル・アプリケーション・ベースのトラフィックとブラウザ・トラフィックを分離できます。たとえば、モバイル・アプリケーションがユーザー・エージェントMyApp/Shopping/v1.3を使用してWebページにアクセスできる場合、規則を使用すると、モバイル・アプリケーションがShopping、クライアント・バージョンがShopping 1.3とレポートされるようにできます。
入力値: MyApp/Shopping/v1.3
検索式: %/%/v%
クライアント・ブラウザ: %2
クライアント・ブラウザ・バージョン: %2~%3
規則内のページ・グループの識別
ページ・ネーミング・スキームで規則指定機能を使用するとき、ページ・ネーミング・スキームのソースにページ・グループが含まれる場合は、グループ値が正しく識別されるようにする必要があります。ソースがmyhost.com/myshop/menswear/catalog/basket.jspというURLページ・ネーミング・スキーム(「URL」を除く)の場合、内部ではmyshop\%7Cmenswear/catalogという構文に変換されます。その後、正しくレポートされるために次のように変換される必要があります。
入力値: myshop|menswear/catalog
検索式: %|%/%
ページ・グループ: %1
ページ名: %2
検索式で、グループとページ名の間の区切り文字のパイプ文字(|)をエンコードする必要はありません。URL構文内のスラッシュ記号は規則指定で使用できることに注意してください。規則指定の後で、一致したスラッシュは、レポートされるグループと名前においては空白に置き換えられます。
検索の構文
URL一致規則には、パラメータの他に、表8-4に示す要素も使用できます。
表8-4 拡張検索の構文
| 使用方法 | 説明 |
|---|---|
|
|
ゼロ個以上の文字に一致し、1つのプレースホルダに入力します。使用できるプレースホルダは%1から%9です。 |
|
|
URL引数内に指定した名前のいずれかに一致する1つの値を検索し、元のプレースホルダの1つと一致後のプレースホルダの1つに入力します。 |
|
|
URL引数内に指定した名前に一致するすべての値を検索し、元のプレースホルダの1つのパラメータ・プレースホルダと、指定した数のプレースホルダの1つのパラメータ・プレースホルダに入力します。 |
|
|
URL引数内に指定した名前に一致するゼロ個以上の値を検索し、元のプレースホルダの1つと指定した数のプレースホルダの1つに入力します。 |
|
|
指定した数の文字を検索します。 |
|
|
URLのディレクトリ・パスを検索し、1つのプレースホルダに入力します。 |
|
|
URLのファイル名パス(ファイル拡張子は除く)を検索し、1つのプレースホルダに入力します。 |
|
|
URLのドメイン部分を検索し、3つのプレースホルダに入力します(たとえば |
|
|
後続の文字の1つが一致するまで一致を試行し、1つのプレースホルダに入力します。 |
|
|
指定したリストの文字に一致しない文字が見つかるまで一致を試行します。 |
|
|
指定した |
特殊文字(%、\、|、!、~)が文字どおりに解釈されるようにするには、前にバックスラッシュを付ける必要があります。たとえば、\%は、パラメータではなく、%文字そのものを示します。また、%文字の後の特殊文字(^、&、[、])もエスケープする必要があります。指定できるプレースホルダは最大9つまでであることに注意してください。
複数のURLパラメータの一致
複数のURLパラメータを一致する場合、1つのセットの大カッコ内に定義することを強くお薦めします。たとえば、%[!parm1!parm2]などです。%[!parm1]%[!parm2]を指定できますが、定義される同じ順序で表示される場合に指定した引数のみ一致するので注意してください。文字列/example/path/file.htmlを考えてみます。使用可能な一致スキームを表8-5に示します。
表8-5 複数のURLパラメータの一致
| 定義 | 一致した結果 |
|---|---|
|
|
|
|
|
|
例
検索値: %[h]/%/%/%/%?%
ページ・グループ: %6 (electronics)
ページ名: %7 (tv821)
URL (チェック用): www.mydomain.co.uk/shop/catalog/electronics/tv821?params=all
検索値: %[h]/%[&shop_cat]
ページ・グループ: %2 (pcShop)
ページ名: %5 (Cables)
URL (チェック用): www.pcShop.com/home/applications/catalog?cust_id=123&shop_cat=Cables
検索値: %[h]/cart:%[c9]/articleid:%[c9]/%
ページ・グループ: %4 (00000ABCD)
ページ名: %5 (000018201)
URL (チェック用): www.myshop.com/cart:00000ABCD/articleid:000018201/shop.jsp?params=all
ページのうち、そのURL定義によりアプリケーションに属していることが確認されているものの、関連する分類済の名前が見つからないものは、廃棄されレポートされません(デフォルト)。ただし、そのような未分類のページをデータ・ブラウザ・グループでレポートする場合は、図8-18に示す「アプリケーション概要」内の「ページ」セクションにある「未分類のページのレポート」チェック・ボックスを使用します。
ページの識別は、時間ベースのアクティビティであるため、オブジェクトとして予約されていないオブジェクトへの参照は、未分類のページであるとして、誤って識別される場合があります。このため、未分類のページのレポート作成は、テスト目的でのみ有効にすることをお薦めします。その後、これを再度無効にし、識別された問題のあるページを手動で定義できます。未分類のページは、対応するデータ・ブラウザ・グループ内のカテゴリ「その他」にレポートされることに注意してください。
監視対象のサービス・テストはRUEIユーザー・フローにも変換できることに注意してください。この詳細は、9.8項「サービス・テスト・セッションのユーザー・フローへの変換」に記載されています。
「拡張」セクションの「サービス・テスト・トラフィックのレポート」チェック・ボックスを使用して、選択したアプリケーションのためにOracle Enterprise Managerで構成されているサービス・テスト・トラフィックをRUEIでレポートするかどうかを指定できます。デフォルトでは、レポートは行われません。この機能の使用方法の詳細は、8.6項「サービス・テスト・トラフィックのレポート」に記載されています。
有効にすると、サービス・テスト・グループは、監視されるサービス・テスト・ビーコン・トラフィックの情報を提供します。構造の詳細は、表V-1に記載されています。
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはIPパケットからフェッチされます。ただし、RUEIシステムをNATサービスの前に配置する場合には、特定のHTTPリクエスト・ヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。この詳細は、付録Q「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というページ名が割り当てられます。
アプリケーションの定義後に、アプリケーションに関連するページ・ネーミング・スキームを変更するには、この項で前述したように、アプリケーションをクリックして新規スキームを選択します。
「識別」セクションで、「新規フィルタの追加」をクリックして、アプリケーションと関連付ける必要のあるページの追加フィルタを指定します。また、既存のフィルタ定義を変更するには、それをクリックします。いずれの場合にも、図8-2に示したフィルタの中から選択できます。ユーザーによる追加または変更を反映するようにアプリケーション概要が更新されます。
セッションでアプリケーション・ページを表示している際のユーザー・エクスペリエンスを評価するために、RUEIではページごとに満足度レベルが割り当てられます。これを表8-6に示します。
表8-6 ページ・ロード満足度のレベル
| レベル | 説明 |
|---|---|
|
良好 |
ページは、満足のページ・ロードしきい値の期間内でユーザー・ブラウザにロードされます。デフォルトでは、これは4秒です。 |
|
OK |
ページは、OKのしきい値の期間内でユーザー・ブラウザにロードされます。デフォルトでは、これは16秒です。 |
|
劣悪 |
ページのロードは、劣悪のしきい値より長くかかります。 |
ページ・ロード満足度のレポートの例を図8-19に示します。
前述のように、この評価は、ページのロードの完了までに通常想定されるしきい値に基づきます。このしきい値を変更して、レポートされるページ・ロード満足度を調整することができます。次を実行します。
目的のアプリケーションを選択し、「ページ」セクションをクリックし、「デフォルト」設定をクリックします。図8-20に示すダイアログが表示されます。
「デフォルト」項目をクリックします。図8-21に示すダイアログが表示されます。
ページ・ロードの満足度を評価するときに使用するしきい値を指定します(秒単位)。これらのしきい値は表8-3で説明しています。デフォルトは4から16秒です。定義するしきい値は0.001から86400(つまり1日)の範囲です。次に、「保存」をクリックします。図8-20に示したダイアログに戻ります。
オプションで、「例外の追加」をクリックし、ユーザー・エクスペリエンスの評価に別の(デフォルトとは異なる)ページ・ロードのしきい値を使用する状況を指定します。この機能は、特定のユーザー・アクションを実行するとき他のアプリケーション・アクションよりかなり長く時間がかると想定される場合に特に便利です。たとえば、ダウンロードや複雑なデータベース問合せなどの場合です。図8-22に示すダイアログが表示されます。
定義された例外においてページおよびユーザー・アクションの評価に使用されるページ・ロードしきい値を指定します。
例外が到達されたとみなされるために満たされる必要があるイベントを指定します。例外が発生するには、定義するイベントがすべて満たされる必要があります。イベントごとに、「ディメンション・レベル」および「値」メニューを使用して、チェックされるディメンションと保持する必要がある値を選択します。目的の値が「値」メニューにない場合は、横にある「検索」アイコンをクリックして探すことができます。
必要に応じて、「除外」チェック・ボックスを使用すると、定義したディメンション・レベル=値ペアを除外するように適用できます。つまり、定義したイベントが満たされない場合に、イベントが達成されたとみなされます。次に、「追加」をクリックします。新しいイベントが例外の定義に追加されます。1つの例外に定義できるイベントは最大10件までです。次に、「保存」をクリックします。図8-20に示したダイアログに戻ります。
例外は、上から下の順で解決されることに注意してください。必要な場合は、例外のコンテキスト・メニューで「上に移動」と「下に移動」のオプションを使用して、例外の位置を移動できます。定義できる例外の最大数は100です。
次に、「保存」をクリックします。指定した変更は、即座に有効になります。
ページとオブジェクト・ロードの満足度のレポート方法の理解
ページ・ロード満足度はユーザーのブラウザでページのロードに要する時間に基づいていますが、オブジェクト・ロード満足度はオブジェクトのエンドツーエンド時間の合計に基づいています。オブジェクト・ロード満足度では、デフォルトのアプリケーション・ページ・ロードしきい値を使用し、定義されている例外は無視します。
3.2.2項「問題分析グループ」で説明するように、2秒未満のエンドツーエンド時間のオブジェクトは遅いURLとみなされません。2秒を超える場合、URLロード満足度はデフォルトのアプリケーション・ページ・ロードしきい値に基づき、定義されている例外は無視します。
RUEIでは、ユーザーがアプリケーションからログアウトしても、自動的にセッションの終了とはみなされません。かわりに、セッションのアイドル・タイムアウト(デフォルトでは60分)に達すると、ユーザー・セッションの終了と判断されます。これは、ユーザーがログアウトした際に、アプリケーションによりユーザーのセッションが終了されず、ユーザーがそのアプリケーションに再度ログインした場合、RUEIでは、アプリケーションのログアウトが検出されず、2つのアプリケーション・セッションが同じユーザー・セッションの一部としてレポートされることを意味します。
これがレポート要件として適切でない場合は、そのページに到達すると、自動的に現在のユーザー・セッションの終了とみなされるアプリケーション・イベントを定義できます。通常、これはログアウト・ページおよびイベントになります。後続のユーザー・アクションは、新しいユーザー・セッションの一部とみなされてレポートされます。
アプリケーション・ログアウト・イベントの定義
次を実行します。
「構成」、「アプリケーション」、「アプリケーション」または「スイート」の順に選択し、必要なアプリケーションを選択します。(図8-5に示したような)「アプリケーション概要」が表示されます。
「ページ」タブ→「ログアウト・イベント」タブの順にクリックします。現時点で定義されているログアウト・イベントがリストされます。「新規イベントの追加」をクリックします。または、既存の定義をクリックしてそれを編集します。図8-23に示すダイアログが表示されます。
必要なイベント条件ごとにディメンション・レベル=値ペアを指定します。必要に応じて、「除外」チェック・ボックスを使用すると、定義したペアを除外するように適用できます。つまり、定義した条件が満たされない場合に、イベントが達成されたとみなされます。次に、「追加」をクリックします。定義したイベントが1つでも取得されればセッションは終了したとみなされますが、達成したとみなされるには、イベント内のすべての条件が満たされる必要があります。次に、「保存」をクリックします。
ページ内に表示される文字列を検出し、アプリケーション通知("注文が正常に処理されました"など)またはアプリケーション・エラー("サーバーへのネットワーク接続に失敗しました"など)のいずれかとしてレポートする必要が生じる場合があります。
コンテンツ・メッセージのチェックと、システム・エラーおよびページ・コンテンツのチェック
コンテンツ・メッセージは、リターン・コードではなくページ・コンテンツに基づき、選択したアプリケーションに固有であるため、システム・エラー(Webサーバー・エラーまたはネットワーク・エラー)とは異なります。
指定したメッセージ文字列は、選択したアプリケーション内のすべてのページを対象として検索されることに注意してください。ページ・コンテンツ・チェックが行われるため、特定のページのみを検索することはできません(8.3.19項「ページ・コンテンツ・チェックの指定」を参照)。
アプリケーション・コンテンツ・メッセージおよびページ・コンテンツ・メッセージはページベースです。サービスの場合、それらはコール(つまりヒット)固有です。したがって、ページベースのグループのみでレポートされ、(URLベースの)診断グループではレポートされません。
コンテンツ・メッセージのレポート
個々のコンテンツ・メッセージは、通知またはエラーとして指定できます。いずれの場合も、ページ配信ディメンションでレポートされます。
指定した通知文字列と一致するものとして表示されるページ・テキストは、ページ・コンテンツの結果である「通知文字列: 通知検索文字列」とともにレポートされ、エラーの場合は「エラー文字列: エラー検索文字列」としてレポートされます。コンテンツ・エラーのレポートの例を図8-24に示します。
コンテンツ・メッセージの定義
コンテンツ・メッセージの文字列を定義する手順は、次のとおりです。
「構成」を選択し、「アプリケーション」、「スイート」または「サービス」を選択して、目的のアプリケーションを選択します。(図8-5に示すような)「アプリケーション概要」が表示されます。
「コンテンツ・メッセージ」タブ→「コンテンツ・メッセージ」の順にクリックします。現在定義されているコンテンツ・メッセージが表示されます。「新規コンテンツ・メッセージの追加」をクリックして新しいメッセージを定義するか、または既存のものをクリックして変更します。図8-25に示すダイアログが表示されます。
「検索タイプ」メニューを使用して、検索範囲を指定します。検索の場所として、リクエスト・ヘッダー、応答ヘッダー、リクエスト・コンテンツ、応答コンテンツまたはURLを指定できます。検索タイプは、XPathまたはリテラルです。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」を参照してください。
リクエスト・ヘッダーまたはレスポンス・ヘッダーを指定する場合、検索するヘッダーを指定できます。このフィールドを空白のままにすると、完全なヘッダー・コンテンツが自動的に入力されます。
URLを指定する場合、URL部分に追加的にレポートされるURL引数を指定できます。
ワイルドカードの使用はサポートされておらず、指定するすべての文字がリテラルとして扱われます。
次に、「保存」をクリックします。変更は5分以内に有効になります。XPathベースまたはヘッダーのコンテンツ・メッセージを作成すると、規則指定機能を使用してメッセージの仕様を微調整できます。この詳細は、8.3.5項「規則指定機能の使用方法」に記載されています。
コンテンツ・メッセージのリストのインポート
監視対象とする各メッセージを個別に定義するかわりに、事前定義済アプリケーション・メッセージのリストを含むファイルをインポートできます。次を実行します。
目的のアプリケーションまたはスイートを選択したら、「メッセージ指定」タブをクリックします。「アップロード・リスト」をクリックします。図8-26に示すダイアログが表示されます。
「参照」ボタンを使用し、目的のファイルを検索して選択します。必要に応じて、「ファイル・エンコーディング」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートの詳細は、付録G「各国語サポートの使用」を参照してください。サポートされていないエンコーディングが検出された場合、またはトランスコーディングに失敗した場合は、エラーがレポートされます。
アップロードされるファイルでは、1行に1つのメッセージを含める必要があり、空白の行を含めることはできません。これらのメッセージが、レスポンス内容で検索されるリテラル文字列になります。次に、「マージ」をクリックします。
必要に応じて、一意のメッセージ文字列それぞれに対して一連の説明を定義することもできます。たとえば、Oracle Databaseメッセージの説明を表8-7のように定義できます。
表8-7 メッセージ文字列の説明の例
| 文字列 | 説明 |
|---|---|
|
|
DDLロックの取得が試行されましたが、すでにロックされています。 |
|
|
一時表の数が一時表ロックの数以上です。 |
|
|
マウントされているデータベースのDB_BLOCK_SIZE初期化パラメータが違います。 |
|
|
DB_FILES初期化パラメータの値が超過されました。 |
|
|
ユーザー・フローがリソースの待機中に互いにデッドロックしました。 |
|
|
起動中の共有インスタンスがDMLロックを使用しており、実行中のインスタンスがDMLロックを使用していません(あるいは、その逆の状態)。 |
|
|
インスタンスがDML_LOCKS = 0で起動されたが、実行中の文では全表ロック(S、XまたはSSX)が必要です。 |
|
|
指定されたログ・ファイルの数が、このリリースでサポートされているログ・ファイルの最大数を超えました。 |
メッセージの説明を定義する手順は、次のとおりです。
適切なアプリケーションまたはスイートを選択したら、「コンテンツ・メッセージ」タブ→「メッセージ指定」タブの順にクリックします。現在定義されているメッセージの説明が表示されます。「新規指定の追加」をクリックして新しい説明を定義するか、または既存のものをクリックして変更します。図8-27に示すダイアログが表示されます。
必要なソース値と、必要に応じて説明を指定します。次に、「保存」をクリックします。
「メッセージ・タイプ」メニューを使用して、メッセージをエラー(デフォルト)または通知のいずれとしてレポートするかを指定します。次に、「保存」をクリックします。
前述の例では、これは次のようにレポートされます。
error code ORA-00056: An attempt was made to acquire a DDL lock that is already locked.
非常に多くの説明がある場合は、「検索」フィールドを使用すると目的の説明をすぐに見つけることができることに注意してください。検索機能では部分一致が使用されます。ワイルドカードの使用はサポートされておらず、すべての文字がリテラルとして扱われます。次に、「実行」をクリックします。
説明のリストのインポート
各説明を個別に定義するかわりに、説明のリストを含むファイルをインポートできます。次を実行します。
「アップロード・リスト」をクリックします。図8-28に示すダイアログが表示されます。
「参照」ボタンを使用して、翻訳ファイルの名前を検索および指定します。メッセージ定義が重複している場合は、最新の定義が使用されます。必要に応じて、「ファイル・エンコーディング」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートの詳細は、付録G「各国語サポートの使用」を参照してください。サポートされていないエンコーディングが検出された場合、またはトランスコーディングに失敗した場合は、エラーがレポートされます。ファイルには、ソース値とその説明をタブで区切って、1行に1つの説明のみを含めることができます。
「メッセージ・タイプ」メニューを使用して、ファイルに定義されたメッセージをエラー(デフォルト)または通知のいずれとしてレポートするかを指定します。次に、「マージ」をクリックします。
コンテンツに関連のないエラー(つまり、Webサイト、ネットワークまたはサーバーのエラー)と一緒にコンテンツ・メッセージがレポートされると非常に便利です。トラブルシューティングを促進するためにエラーのコンテキストに関する追加情報の提供が可能になります。ただし、これはレポートのデフォルトの動作ではありません。
3.2.3項「ページ配信ディメンション」に記載されているように、1ページで数種類のエラー(たとえばサーバー・エラーとネットワーク・エラー)が発生しても、ページ・エラーは複数回レポートされません。かわりに、エラーは特定の順序(Webサイト、サーバー、ネットワーク、コンテンツの順)でレポートされます。
コンテンツに関連のないエラーが追加情報と一緒にレポートされるように指定する手順は、次のとおりです。
「構成」→「アプリケーション」の順に選択して、目的のアプリケーションを選択します。(図8-5に示すような)「アプリケーション概要」が表示されます。「コンテンツ・メッセージ」タブ→「拡張」タブの順にクリックします。図8-29に示す画面が表示されます。
ページ上に定義済コンテンツ・メッセージが見つかった場合はレポート時にエラーに追加するよう指定するには、「コンテンツ・メッセージの追加」チェック・ボックスを選択します。デフォルトでは、コンテンツ・メッセージは追加されません。同じページ内に複数のコンテンツ・メッセージが見つかった場合は、ページ上で最初に見つかったメッセージがレポートで使用されることに注意してください。
拡張ページ配信の詳細の例を図8-30に示します。
RUEIでは、新たに作成されるアプリケーションは、ユーザー識別がHTTP認可フィールドとSSLクライアント証明書の共通名(CN)部分(使用可能な場合)に基づくように自動的に構成されます。図8-31にこれを示します。
ただし、URL、Cookie、リクエスト・ヘッダー、レスポンス・ヘッダー、XPath式、カスタム・タグまたはレスポンス、OAMユーザー・トラッキング(11.1項「OAMベース・トラフィックの監視」を参照)に関して、アプリケーションのユーザー識別スキームを構成することもできます。HTTP認可フィールドは構成される他の値よりも優先されること、SSL証明書は代替スキームであることに注意してください。構成されたユーザーIDが監視対象トラフィックで検出されたものと一致しない場合、そのユーザーIDは"(値なし)"としてレポートされます。RUEIにおける値なしアイテムのレポートの詳細は、付録Eを参照してください。
アプリケーションのユーザー識別スキームの構成
アプリケーションのユーザー識別スキームを構成する手順は、次のとおりです。
目的のアプリケーションを選択し、「ユーザー」セクションをクリックします。
「新規ソースの追加」をクリックします。図8-32に示すダイアログが表示されます。
「ソース・タイプ」および「ソース値」フィールドを使用して、ユーザー識別メカニズムを指定します。これは、リテラル検索文字列またはXPath式を使用して指定できます。次の点に注意してください。
リテラル検索文字列の場合、リクエスト・ヘッダーまたはレスポンス・ヘッダーを検索するかどうかを指定できます。
XPath式の場合、リクエストまたはレスポンスを検索するかどうかを指定できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。
Cookieの場合は、Cookieの名前を指定する必要があります。選択したCookieに対して、またはデフォルトのCookieマスキング・アクションとしてハッシングが指定されている場合、Cookieの一意性は保たれますが、元の値は保存されません。この詳細は、13.6項「ユーザー情報のマスキング」に記載されています。
URL引数の場合は、引数の名前を指定する必要があります。
OAMベース・トラフィックの場合は、詳細について11.1項「OAMベース・トラフィックの監視」を参照してください。
カスタム・パターンの場合は、開始文字列と終了文字列(オプション)を指定して、検索対象のコンテンツの範囲を決める必要があります。ワイルドカード文字の使用はサポートされておらず、指定するすべての文字がリテラルとして扱われることに注意してください。また、終了文字列を指定すると、検索は次の行以降では行われません。
カスタム・タグの場合は、ユーザーIDが取得されるname=valueペアに名前を指定する必要があります。
前述のように、HTTPベースの認証が指定されている場合は、他に識別スキームが定義されても優先されます。また、SSLクライアント証明書が指定されている場合、これは代替スキームになります。
「詳細」タブをクリックします。「小文字変換」メニューを使用して、ユーザー名を小文字に変換するかどうかを指定し、変換する場合にはユーザー識別定義の作成後に定義できる一致ルールの適用前か適用後かも指定します。
次に、「保存」をクリックします。ユーザー識別スキームを定義すると、ルーリング機能を使用して実装を絞り込むことができます。この詳細は、8.3.5項「規則指定機能の使用方法」に記載されています。
各国語サポート
各国語のキャラクタ・セットを使用する際に識別が持つ意味の詳細は、付録G「各国語サポートの使用」を参照してください。
デフォルトで新規作成されたアプリケーションおよびサービスでは、ローカライゼーション・ソースが構成されません。ただし、URL、Cookie、リクエストあるいはレスポンス・ヘッダー、XPath式、またはカスタム・タグあるいはレスポンスに関して、アプリケーションのローカライゼーション(テリトリおよび言語)ソースを構成できます。
アプリケーションのローカライゼーション・ソースの構成
アプリケーションのローカライゼーション・ソースを構成するには、次の手順を実行します。
必要なアプリケーションを選択し、「拡張」セクションをクリックします。
「ローカライゼーション」セクションをクリックします。
「アプリケーション・テリトリ」または「アプリケーション言語」セクションを選択します。
「新規ソースの追加」をクリックします。
「ソース・タイプ」および「ソース値」のフィールドを使用して、ローカライゼーション識別メカニズムを指定します。次の点に注意してください。
リテラル検索文字列の場合、リクエスト・ヘッダーまたはレスポンス・ヘッダーを検索するかどうかを指定できます。
XPath式の場合、リクエストまたはレスポンスを検索するかどうかを指定できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。
Cookieの場合は、Cookieの名前を指定する必要があります。選択したCookieに対して、またはデフォルトのCookieマスキング・アクションとしてハッシングが指定されている場合、Cookieの一意性は保たれますが、元の値は保存されません。この詳細は、13.6項「ユーザー情報のマスキング」に記載されています。
URL引数の場合は、引数の名前を指定する必要があります。
カスタム・パターンの場合は、開始文字列と終了文字列(オプション)を指定して、検索対象のコンテンツの範囲を決める必要があります。ワイルドカード文字の使用はサポートされておらず、指定するすべての文字がリテラルとして扱われることに注意してください。
行文字列の終わりを指定しないかぎり、検索は新規行を超えて拡張しません。
カスタム・タグの場合は、ユーザーIDが取得される名前=値ペアに名前を指定する必要があります。
「詳細」タブをクリックします。「小文字変換」メニューを使用して、値を小文字に変換するかどうかを指定し、変換する場合は、ローカライゼーション・ソースの作成後に定義できる一致ルールの適用前か適用後かも指定します。次に、「保存」をクリックします。ローカライゼーション・ソースを定義すると、ルーリング機能を使用して実装を絞り込むことができます。この詳細は、8.3.5項「規則指定機能の使用」に記載されています。
アプリケーションで検出されたページの構造は、ウィンドウの左側にあるアプリケーション概要に表示されます。例を図8-34に示します。
アプリケーションには、非常に多くのページが関連付けられている可能性があります。実際、図8-34に示す構造では、簡単には確認できないほど多くのページが関連付けられています。このため、この構造のビューは、Point of Interest(POI)を持つページに制限されています。したがって、レポートに含まれているページ、キー・ページとして定義されているページ、手動で名前が設定されたページ、監視対象KPIの一部であるページなどが表示されます。図8-35に示す表示メニューでは、構造概要に表示するページのタイプを制御できます。
表8-8に示すオプションがあります。
表8-8 「ビュー」メニューのオプション
| オプション | 説明 |
|---|---|
|
すべて |
すべてのアプリケーション・ページをリストします。 |
|
レポート・ページ |
レポート・フィルタとして指定されているページのみをリストします(2.7項「レポート・フィルタの使用方法」を参照)。 |
|
チェックしたページ |
コンテンツ・チェックが定義されているページのみをリストします(8.3.19項「ページ・コンテンツ・チェックの指定」を参照)。 |
|
手動で名付けられたページ |
手動で定義されているページのみをリストします(8.3.20項「ページの手動識別」を参照)。 |
|
キー・ページ |
キー・ページとして定義されているページのみをリストします(8.3.18項「ページの使用状況の追跡」を参照)。 |
アプリケーション・ページ・カテゴリをドリルダウンすると、特定のページに移動できます。ただし、多数のページを含むアプリケーションの使用時は、ページ検索機能を使用した方が便利な場合があります。次を実行します。
検索するアプリケーションを選択します。「ページ」セクションを選択し、「識別されたページ」タブをクリックします。
目的のページの検索に使用する検索プロファイルを指定します。検索は現在のアプリケーションに制限され、ページ名は、アプリケーション » グループ » 名前という構造になることに注意してください。検索機能では、完全一致または部分文字列として指定した検索パターンとの一致が行われます。このため、検索パターンhomeは、アプリケーション、グループまたはページの名前におけるこの文字列または部分文字列の出現に一致します。次に、「実行」をクリックします。結果リストを図8-36に示します。
検索結果がダイアログの下半分に表示されます。一致したページをクリックして開きます。右および左矢印ボタンを使用し、結果の複数のページ間を移動します。また、表示メニュー(8.3.16項「アプリケーション・ページ構造の表示」を参照)を使用すると、特定の基準(レポートで使用されるページなど)に合うように表示リストを制限できます。
|
注意: 検索範囲には、検出済のページと、レポートおよびユーザー・フローに存在する未検出ページの両方が含まれます。 |
識別されたページをすべて削除する場合は、ウィンドウの一番下にある「すべての識別されたページのパージ」を選択します。これにより、「識別されたページ」カウンタがリセットされ、結果リストがクリアされます。
アプリケーションで検出された各ページに関する情報は、ページ分析ウィンドウで確認できます。例を図8-37に示します。
このウィンドウには次のタブがあります。
識別: ページ識別スキーム(手動または自動)と、識別に使用する条件を指定します。
コンテンツ・チェック: コンテンツ検索文字列がページに定義されているかどうかを指定します。この詳細は、8.3.19項「ページ・コンテンツ・チェックの指定」に記載されています。
レポート: このページを含むレポートをリストします。レポートの詳細は、第2章「レポートの操作」に記載されています。
監視: このページを含むKPIをリストします。KPIの定義手順に関する詳細を参照してください。
図8-37の「キー・ページ」チェック・ボックスを使用して、ページをキー・ページとして定義します。
キー・ページは、監視対象のうち、特に注目するWebページです。通常、これは特に重要なページです。たとえば、組織のホームページや、注文入力などのユーザー・フロー内の一連のページなどがあります。これらのページに関しては、追加情報が記録されます。追加情報には、クライアント情報(ISP、アクセス元の国など)やクライアントのブラウザ情報(オペレーティング・システム、ブラウザ・バージョンなど)があります。
特定のページに特定のテキスト文字列が出現するかどうかの監視が必要となる場合があります。たとえば、Webアプリケーションに注文ページがあり、販売に成功した後、"ご購入ありがとうございました"というテキスト文字列がこのページに表示されるとします。目的のページにこの文字列があるかどうかを検索するページ・コンテンツ・チェックを定義できます。指定したテキスト文字列がそのページで見つからない場合、ページ・ビューは失敗したページとしてレポートされることに注意してください。
ページ・コンテンツ・チェックのレポート
成功したページとしてレポートされるためには、ページに対して指定したすべての文字列がページ・ビュー内で見つかる必要があることに注意してください。それ以外は失敗したページ・ビューとしてレポートされます。また、コンテンツ・メッセージ(8.3.13項「アプリケーション・コンテンツ・メッセージのトラップ」を参照)の一致はページ・コンテンツ・チェックの前に行われます。したがって、ページ・コンテンツ・チェックでは失敗したページとしてレポートするように示しても、ページ・ビューは通知(つまり、成功)としてレポートされることがあります。
ページ・コンテンツ・チェックの定義
ページ・コンテンツ・チェックを定義する手順は、次のとおりです。
「構成」→「アプリケーション」→「アプリケーション」の順に選択して、目的のアプリケーション・ページを選択します。ページ分析ウィンドウ(図8-37を参照)が表示されます。
「コンテンツ・チェック」タブ→「チェックの追加」の順にクリックします。図8-38に示すダイアログが表示されます。
検索時に、リテラル検索文字列またはXPath式のいずれを使用するか、およびサーバーのレスポンスまたはクライアントのリクエストのどちらを検索するかを指定します。XPath式の場合は、クライアントまたはサーバーのレスポンス・コンテンツで検索する詳細な値も指定できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。次に、「保存」をクリックします。
アプリケーション全体のページを識別できるのみでなく、ページを手動で定義することもできます。手動で識別されたページは、アプリケーションによって自動的に識別されたページより優先されることに注意してください。この機能は、自動的には識別できないサブページに、別の名前を割り当てる場合に便利です。手動で識別されるページは、新規ページのベースとなる既存のページを選択して作成します。
ページが手動で識別されるようにするには、新規のページを最初から定義するか、既存のページ(自動で検出または手動で定義されたページ)を新規ページのベースとして使用します。
ページを定義する手順は、次のとおりです。
ページを最初から定義するには、目的のアプリケーションを選択し、「新規ページ」ボタンをクリックします。既存のページを新規ページのベースとして使用するには、目的のアプリケーション・ページを選択し、「新規ページ(現在のページに基づく)」ボタンをクリックします。いずれの場合も、図8-39に示すダイアログが表示されます。
このダイアログを使用して、割り当てた名前がページに設定されるための条件を指定します。この条件は、ページURLの一部または詳細、コンテンツ、ドメインまたは引数を使用して定義できます。XPath式も指定できます。「条件の追加」をクリックして必要な各条件を追加します。
詳細なURL(たとえばhttp://www.oracle.com/contact.htmlなど)を指定する場合、ドメインとそれ以外のURL構文はページ条件に自動的に割り当てられます。たとえば、ドメイン内の検索オプション(oracle.com)や「正確なURLの検索」(/contact.html)のようになります。
追加条件を指定すると、それらがダイアログに表示されます。一致を行うときは、指定したすべての条件が満たされる必要があります。青字で表示される条件はクリックすると削除できますが、黒字で表示される条件は削除できないことに注意してください。ページを識別するには、1つ以上の条件を指定する必要があります。次に、「次へ」をクリックします。図8-40に示すダイアログが表示されます。
このダイアログを使用して、ページのグループおよび名前を指定します。次に、「終了」をクリックします。
新規ページの詳細が、図8-34に示すようなウィンドウに表示されます。このウィンドウを使用すると、ページ検出を追跡し、その定義を変更できます。
URL診断グループ(3.2.4項「問題分析のためのURL診断」を参照)を使用すると、アプリケーションのヒットについてレポートされた機能URLを表示できます。これらは、特定の要件に合せてアプリケーション・レベルでカスタマイズできます。
URL診断を使用すると、アプリケーションの問題の把握に役立ちます。たとえば、特定のアプリケーションでロード時間が異常に長くかかる場合に、問題がある特定のオブジェクトまたは原因となっているサーバーをすぐに識別できます。さらに、この機能をセッション診断機能(4.1項「概要」を参照)と組み合せると、アプリケーションの問題について非常に高性能の根本原因分析を行うことができます。
選択したアプリケーションで使用するURL診断レポート・スキームを指定する手順は、次のとおりです。
「構成」→「アプリケーション」の順に選択して、目的のアプリケーションを選択します。(図8-5に示すような)「アプリケーション概要」が表示されます。「拡張」セクションをクリックし、「URL診断」タブをクリックします。監視対象のURL範囲を指定するために使用される、現時点で定義済のURLパターンが表示されます。「新規URLパターンの追加」をクリックして新しいパターン一致スキームを定義するか、既存のパターン一致スキームをクリックして変更します。図8-41に示すようなダイアログが表示されます。
「URL一致タイプ」メニューを使用して、これから定義するスキームをすべてのアプリケーションのURLに適用するか、特定のURLのみに適用するかを指定します。後者の場合は、URL構文を指定する必要があります。この構文が「URL診断」グループ内でアプリケーションについてレポートされます。定義するURLパターンが検出されたURLと一致したときにレポートされます。ワイルドカード文字(*)の使用はサポートされますが、指定する他の文字はすべてリテラルとして解釈されます。URL構文を定義しないと、アプリケーションの関連するヒットが「URL診断」グループでレポートされないことに注意してください。
検出されるURL構文の一部(要素)をレポートするように指定することもできます。または、レポートされるURLを特定の引数に限定することもできます。いずれの場合も、「URL引数/コンポーネントの追加」をクリックします。図8-42に示すようなダイアログが表示されます。
「スキーム・タイプ」メニューを使用して、一致するURLをレポートするときに、特定のパラメータまたは要素に限定するかどうかを指定します。パラメータの場合は、レポートされるパラメータ名を指定する必要があります。要素の場合は、一致したURLから分離する要素を指定し、「パート」メニューを使用してレポートする必要がある部分を指定します。使用可能なオプションの数は、「URLコンポーネント」フィールドに指定されるワイルドカード(*)の数と同じです。
たとえば、図8-43に示す要素の定義について考えます。
この場合は、*/MyShop/catalog/よりも後の部分のみがレポートされます。部分のパラメータは、「値」定義に指定されたワイルドカードと照合されることに注意してください。たとえば、指定された値*/session=*/*には3つのワイルドカードが含まれるため、一致するURLは3つの論理部分を含むとみなされます。URL診断の定義には最大で9個のワイルドカードを指定できます。
次に、「保存」をクリックします。図8-41に示したダイアログに戻ります。
アプリケーションのパラメータと要素の定義を確認します。次に、「保存」をクリックします。5分後から一致するURLパターンが「URL診断」グループでレポートされます。
除外するURLの情報
強制オブジェクト(12.16項「ページとしてのオブジェクトのレポートの制御」を参照)は、レポートされたURLから自動的に除去されます。この他に、セッション・パラメータおよび静的オブジェクト(イメージなど)のレポートを除外するように、アプリケーション定義を構成することをお薦めします。こうすることで、診断情報が長くなりすぎて切り捨てられることを防ぎます。
セッション診断の再生機能で表示されるアプリケーション・ページは、インラインJavaScriptコードを含む可能性があります。通常、このコードはチェックを実行するために使用されます。たとえば、指定されたサーバーに接続して、セッションが期限切れになったかどうかを判別します。このようなチェックおよびJavaScriptの他の機能は、関連するページを再生機能で表示するときに問題になることがあります。
この理由のために、アプリケーション構成機能を使用して、インラインJavaScriptコードの実行をReplay Viewerでどのように扱うかを指定できます(4.1項「概要」を参照)。JavaScriptの実行を完全に無効にするか、特定の関数またはファイルをページの再生時に置き換えるように指定できます。
実行規則の定義
アプリケーション・ページの再生時に使用されるJavaScriptの実行規則を定義する手順は、次のとおりです。
「構成」→「アプリケーション」→「アプリケーション」の順に選択して、目的のアプリケーションを選択します。(図8-5に示すような)「アプリケーション概要」が表示されます。「拡張」セクションをクリックし、次に「JavaScriptリプレイ」タブをクリックします。現時点で定義されている実行規則が表示されます。図8-44に示すようなダイアログが表示されます。
「すべてのJavaScript実行の無効化」チェック・ボックスを使用して、選択したアプリケーションのページが再生機能で再生されるときに、ページ内のすべてのJavaScriptコードを無効にするように指定します。このチェック・ボックスを選択すると、既存の実行規則は無視されます。新しい規則を定義することもできません。デフォルトでは、このチェック・ボックスが選択されています。
「新規ルールの追加」をクリックして新しい規則を定義するか、既存の規則をクリックして変更します。この機能が使用できるのは、「すべてのJavaScript実行の無効化」チェック・ボックスを選択していない場合のみであることに注意してください。図8-45に示すようなダイアログが表示されます。
「ルール・タイプ」メニューを使用して、定義する実行規則のタイプを指定します。次のオプションから選択してください。
関数の置換: 実行時に、指定したJavaScriptの関数を削除し、オプションとしてリターン・コードで置き換えるように指定します。たとえば、Cookieがまだ有効かどうかを調べる関数を、再生時にOKという戻り値で置き換えることができます。
指定される関数の定義は、ページのインライン・コードに含まれる必要があります。外部関数を置き換えることはできません。JavaScriptコードが置き換えられるのは、レンダリングされるブラウザ・ページのみです。再生されるページのコンテンツでは置き換えられません(「HTTPコンテンツ」機能でレポートされます)。
関数の定義でfunction構文と関数名の間にコメントが含まれる場合は、置換が失敗することに注意してください。たとえば、次の構文では失敗します。
function
/* some comment */
myfunction ( url ) {
.....}
アプリケーション・ページに外部関数への参照が含まれる場合は、変更した関数定義を含むファイルをアップロードして置き換えることができます。これは次に説明します。
ファイルの置換: JavaScriptコードを含む指定のファイルを別のファイルで置き換えるように指定します。たとえば、検証ルーチンを含むファイルを、再生用に簡単な内容に置き換えることができます。このオプションを選択した場合は、置き換えるファイルの名前と拡張子を「ソース名」フィールドに指定する必要があります。これらは、対応するscript要素に指定するものと同じであることが必要です。たとえば、次のファイル参照があるとします。
<script type="text/javascript" src="public/scripts/checks.js"></script>
ここでは、ファイル名checks.jsを指定する必要があります。
置換ファイル・フィールドを使用して、代替ファイルを指定します。このファイルの拡張子は.jsで、MIMEタイプはtextであることが必要です。このファイルはレポータ・システムの/opt/ruei/gui/upload/ディレクトリにアップロードされます。
次に、「保存」をクリックします。定義済のアプリケーション再生規則に行った変更は、すぐに適用されます。
置換ファイルのアップロード
置換のための.jsファイルは、レポータ・システムの/opt/ruei/gui/uploadディレクトリにアップロードされます。必要であれば、適切な規則を選択して、元のファイルを変更したものをアップロードするかまったく新しいファイルを指定することで、置換ファイルの内容を変更できることに注意してください。どちらの場合も、元のファイルの内容は新たにアップロードされるファイルで上書きされます。規則が削除されると、その規則についてアップロードされたファイルも自動的に削除されます。
アプリケーションに複数の規則が含まれ、それらが同じファイルを参照する場合、1つのバージョンのファイルのみがレポータ・ファイル・システムに保持され、そのファイルが常に最新バージョンとしてアップロードされることに注意してください。そのファイルがファイル・システムから削除されるのは、そのファイルを使用するすべての規則も削除された場合のみです。
同じJavaScriptファイルが複数のアプリケーションで使用されることは頻繁にあります。アプリケーションに指定される各置換ファイルは一意のファイルを表すことに注意してください。これは、複数のアプリケーションに対して同じファイル名が指定されるときにも該当します。たとえば、3つのアプリケーションA、BおよびCのすべてに、置換ファイルmychecks.jsが指定されているとします。この場合、3つのバージョンのmychecks.jsファイルがRUEIによって管理されます。いずれか1つのファイルを変更すると、対応するアプリケーションのみに適用され、他のアプリケーションには適用されません。
リッチ・フレームワーク(Ajaxなど)を使用するアプリケーションの場合は、アクション・ネーミング・スキームを指定できます。これは、特定のページで実行される対話型のユーザー・アクションの内容を把握する場合に特に便利です。たとえば、ユーザーがオンライン・カタログ・ページを表示している状況で、「買い物かごに入れる」というアクションをクリックしたときを把握する場合などです。
アクションに関する情報は、すべてのページおよび問題分析(「失敗したページ」など)のグループの「アクション」ビューから参照できます。セッション診断機能内でも表示できます。例を図8-46に示します。
アクション・ネーミング・スキームを定義するには、次の手順を実行します。
「構成」→「アプリケーション」→「アプリケーション」の順に選択して、適切なアプリケーションをクリックします。(図8-5に示したような)「アプリケーション概要」が表示されます。
「ページ」タブ→「アクション・ネーミング・スキーム」設定の順にクリックします。
同じアクション・ネーミング・スキームがページ・ネーミング(手動を除く)に使用でき、8.1項「ページのネーミング」に記載されています。
オプションで、「拡張」タブをクリックし、アクション名を小文字に変換するかどうかを指定できます。デフォルトでは、元の大/小文字のまま維持します。次に、「保存」をクリックします。
必要なアクション・ネーミング・スキームを選択したら、ルーリング機能を使用して操作を絞り込むことができます。この詳細は、8.3.5項「規則指定機能の使用方法」に記載されています。
シングル・サインオン(SSO)とは、1回ログインすれば、ログインすることを再度求められることなく、複数のソフトウェア・システムのリソースにアクセスできるようになるアクセス制御方法です。アプリケーションとリソースが異なれば、サポートされる認証メカニズムも異なるため、SSOでは様々な資格証明を内部的に変換および保存して、初期認証で使用された資格証明と照合する必要があります。SSOには次の利点があります。
ユーザー名とパスワードの様々な組合せを管理する煩雑さを軽減します。
同じIDに対するパスワードの再入力に要する時間を省きます。
ITヘルプ・デスクに対するパスワード関連の問合せの数を減らすことで、ITコストを削減します。
SSOでは、中央の認証サーバーを使用し、他のすべてのアプリケーションおよびシステムがこれらのサーバーを認証目的で利用します。この技術が、ユーザーが自分の資格証明を複数回入力することを頻繁に求められないようにする技術と組み合せられます。
SSO対応アプリケーションが正しく監視されるようにするには、実際の環境で使用する認証サーバーを構成する必要があります。このためには、SSOプロファイルを作成します。
SSOサーバーでは、ユーザー・プロファイルを管理し、認証されたユーザーにログイン・ページを表示します。次に、アプリケーションがSSOサーバーと通信し、一時トークンを検証します。図8-47に、アプリケーション認証がSSOサーバーで有効化されている場合に機能する仕組みを示します。
図8-47に示す認証フローは、次の順序を取ります。
ユーザーが、保護された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プロファイルを定義する手順は、次のとおりです。
「構成」→「アプリケーション」→「シングル・サインオン」の順に選択し、「新規SSOプロファイル」をクリックします。図8-48に示すダイアログが表示されます。
SSOプロファイルの名前を指定します。これは、スイート、サービス、アプリケーションおよびSSOプロファイルを通じて一意である必要があります。SSOプロファイルの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、SSOプロファイルの有効範囲を指定します。有効範囲はページURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「フィルタのプレビュー」列に表示されます。
|
注意: SSOプロファイル、アプリケーション、スイートおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。こうしておかないと、予期しない結果がもたらされる可能性があります。一致規則の適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。 |
最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。プロファイル名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字(*)は「ポートの検索」フィールドには指定できません。標準以外のポート(つまりポート80/443以外)に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、SSOプロファイルは関連付けられないことに注意してください。指定できるポート番号は1つのみです。追加のポートを指定する必要がある場合は、新しいSSOプロファイルが作成された後で追加のフィルタとして指定してください。
ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURLの組合せ情報を指定しないことはできません。フィルタの適用順序を制御する方法は、12.9項「RUEI内でのルール順序設定の制御」を参照してください。
次に、「次へ」をクリックします。図8-49に示すダイアログが表示されます。
このダイアログを使用し、使用しているSSO認証サーバーに関する情報を指定します。セッションCookie名、認証トークンを含んでいるURL引数、および監視対象トラフィックでのユーザーの識別方法を指定する必要があります。これは通常、URL引数と値を使用して定義します。ただし、Cookie、リクエスト・ヘッダーまたはレスポンス・ヘッダーあるいはXPath式で指定することもできます。
次に、「終了」をクリックします。指定したSSOプロファイル定義の概要が表示されます。例を図8-50に示します。
この概要では、定義したSSOプロファイルのサマリーが示され、必要に応じて、その定義を変更できます。この詳細は次の項に記載されています。
ユーザー識別を定義した結果は、ユーザー情報(XLS形式)レポートの「クライアント」カテゴリで確認できます。レポートの詳細は、第2章「レポートの操作」を参照してください。
SSOプロファイルを定義後に変更するには、その概要を使用します。次のタブがあります。
識別: SSOサーバーの有効範囲を、ページURLの1つ以上の部分一致を使用して指定します。ページは、定義済のフィルタがページのURLに一致すると、SSOサーバーに割り当てられます。新規フィルタを追加するには、「新規フィルタの追加」をクリックします。既存のフィルタを変更するには、そのフィルタをクリックします。図8-51に示すようなダイアログが表示されます。
ダイアログの最下部にあるメモは、現在のルール順序設定スキームを示します。この詳細は、12.9項「RUEI内でのルール順序設定の制御」に記載されています。
構成: 使用される認証トークンとCookieを指定します。
ユーザー: ユーザーIDをアプリケーション内で識別する方法を指定します。これが未定義で、SSLクライアント証明書が存在する場合、この証明書が使用されます。
RUEIのデプロイメントで監視中のトラフィックが正しく識別されていることを確認するために、定期的に確認することを強くお薦めします。そのためには、「構成」メニューから「統計の表示」を選択します。図8-52に示すダイアログが表示されます。
未確認のヒットやページが予想以上に多い場合は、ページの識別定義を確認する必要があります。この詳細は、8.1項「ページのネーミング」に記載されています。セッション識別のないページ・ビューが予想以上に多い場合は、ユーザーの識別定義を確認する必要があります。この詳細は、8.3.14項「ユーザー識別の定義」に記載されています。
ビジネス・クリティカルなサービスに対して最上位レベルの可用性およびパフォーマンスを維持するため、Oracle Enterprise Managerを構成してサービス・テストを監視できます。Oracle Enterprise Managerのサービス・テストはビーコンから実行されます。Oracle Enterprise Managerは、エンドユーザーの観点からサービスを監視し、ベースのITインフラストラクチャとサービスの相関関係も監視します。通常、ビーコンは、通常のアプリケーション使用に相当するユーザー・フローを実行するように設定されます。Oracle Enterprise Managerは、ユーザー・フローのレスポンス時間を各構成部分に細分化して分析します。ビーコンおよびサービス・テストを定義する手順の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』に記載されています。
RUEI内のサービス・テスト機能は、比較可能なリアル・ユーザー・トラフィックに対するこの統合トラフィックの結果の検証を許可して、Oracle Enterprise Managerサービス・テストを補完します。たとえば、サービス・テストがアプリケーションの特定項目の問題をレポートする場合、この機能を使用して、同じ期間中にこの問題がリアル・ユーザー・トラフィックでも確認されるかどうかを判別できます。この方法で、エラーの多いインシデントをすぐに識別および無視でき、実際のユーザーのレポートされた問題の影響をすぐに評価できます。
