| Oracle Real User Experience Insightユーザーズ・ガイド リリース6.5.1 for Linux x86-64 B61012-01 |
|
 戻る |
 次へ |
この章では、監視するWebページを識別する方法について説明します。具体的には、どのWebページについて追加情報を記録するかを定義する方法、監視対象ページのユーザー・フローにおける論理的順序の定義方法、および特定のテキスト文字列が出現するかどうかの監視対象とするページの定義方法について説明します。また、シングル・サインオン（SSO）プロファイルおよびスイートの定義についても説明します。これを実行できるのは、「Analytical」レベルのアクセス権限を持つユーザーのみです。
URL引数
アプリケーション、スイート、サービス、およびユーザーとクライアントのID識別のために構成されるURL引数は、エンコーディングなしで（%、&、=記号を除く）指定する必要があることに注意してください。
RUEIにおけるページ識別は、アプリケーションに基づいて行われます。一般的に、アプリケーションはWebページの集合です。通常、Webサイトのページは特定のアプリケーションにバインドされているためです。アプリケーション内の各ページには名前が割り当てられていて、それぞれのページはグループに属します。たとえば、「MyShop » Contact » About us」は、MyShopアプリケーション内のContactグループの「About us」ページを指します。
各アプリケーションには、アプリケーションの有効範囲を定義するページ・ネーミング・スキームが関連付けられています。スキームの指定には、ドメイン名の一部またはURL構文の一部、あるいはその両方の組合せを使用できます。また、ページ・ネーミング・スキーム（ページ・タグ付けやHTMLページのタイトル部分など）は、アプリケーション定義を微調整する際にも指定できます。
RUEIで検出される各ページに対し、スキームは、存在するアプリケーション定義を使用して名前を割り当てます。これらの定義を使用して識別できないページに関する情報は廃棄されるため、レポートおよびデータ・ブラウザでは使用できません。
アプリケーション・ページは、自動検出できるのみでなく、手動で定義することもできます。手動定義が特に役立つのは、URL構文に一貫性のない場合や、識別されたページにサブページが含まれる場合、またはアプリケーションによって自動的に割り当てられた名前とは違う名前を割り当てる必要がある場合です。手動で定義されたこれらのページは、アプリケーション定義で自動的に識別されたページより優先されることに注意してください。
現時点で定義されているアプリケーションとそのグループおよびページの構造を表示するには、「Configuration」→「Applications」→「Applications」の順に選択します。例を図6-1に示します。
アプリケーションを定義する手順は、次のとおりです。
「Configuration」→「Applications」→「Applications」の順に選択し、「New application」をクリックします。図6-2に示すダイアログが表示されます。
アプリケーションの名前を指定します。これは、スイート、サービス、SSOプロファイルとSSOアプリケーションを通じて一意である必要があります。アプリケーション名はレポートされるページに付加されるため、定義されたアプリケーション名をできるだけ維持することをお薦めします。アプリケーションの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、アプリケーションの有効範囲を指定します。有効範囲はページURLを使用して定義されます。この情報を入力すると同時に、入力した定義が「Filter preview」列に表示されます。
最高レベルのフィルタはドメインです。アプリケーション名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字（*）は「Find Port」フィールドには指定できないことに注意してください。指定できるのはポート番号1つのみです。さらにポートを指定する必要がある場合は、新しいアプリケーションが作成された後で追加のフィルタとして指定してください。
特定のフィールドではワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、ドメインとURL引数の組合せによるその他の情報を指定しないことはできません。
|
注意: スイート、SSOプロファイル、アプリケーションおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。たとえば、ドメインus.oracle.comでフィルタリングされるアプリケーションと、us.oracle.com/application_servletでフィルタリングされる別のアプリケーションがある場合、予測できない結果が発生することがあります。一致規則の適用順序を制御する方法は、7.6項「RUEI内でのルール順序設定の制御」を参照してください。 |
一致対象とするURL GET引数を指定することもできます。この機能を使用する場合は、引数名と引数値の両方を揃えて指定することで初めて、検出されたページURLと一致することに注意してください。つまり、部分一致はサポートされていません。次に、「Next」をクリックします。図6-3に示すダイアログが表示されます。
このダイアログでは、アプリケーション内のページに使用する自動ページ・ネーミング・スキームを指定できます。各アプリケーションに対して指定できるスキームは1つのみです。次のオプション・グループがあります。
Page tagging: 標準スキーム（「Coremetrics」など）とカスタム・スキームのいずれを使用するかを指定します。カスタム・スキームの場合は、カスタム・タグの名前を指定する必要があります。「HTML title」オプションは、ページの<title>タグにあるテキストを使用してページを識別する必要があることを指定します。このオプションの使用方法の詳細は、6.2.1項「詳細設定の使用によるページとオブジェクトの処理の制御」を参照してください。RUEIでサポートされているページ・タグ付けの汎用スキームの構造および処理は、付録A「タグ付け規則」に記載されています。
Client request: ページをそのURL構文に基づいて識別することを指定します。次のオプションにより、URLのどの部分を使用するかを指定します。
URL: ページ・ネーミングが、ビジターのブラウザのロケーション・バーに表示される完全なドメインとURLに基づきます。このスキームは規則指定を使用するときに特に役立ちます。
URL directory: URLのディレクトリ部分のみを使用します。URLの各部分は、図6-4に示されています。
URL base: URLのメイン・ディレクトリとファイル名（ファイル拡張子は除く）の部分を使用します。
URL full: URLのメイン・ディレクトリ、ファイル名（ファイル拡張子は除く）および構成済の引数を使用します。このオプションを選択すると、ページ名に含める引数を指定するように求められます。このダイアログ・ボックスでは、複数の引数はアンパサンド（&）文字で区切る必要があります。たとえば、frmActionパラメータを定義した図6-4のURLは、myshop » shop » NL index frmAction=buyというページ名になります。
これらいずれかのオプションを選択した場合、使用方法の詳細は、6.2.1項「詳細設定の使用によるページとオブジェクトの処理の制御」を参照してください。
Server response: サーバーのレスポンスに適用されたXPath式に基づいてページを識別することを指定します。XPath式の使用方法の詳細は、付録F「XPath問合せの使用」を参照してください。
Manual: アプリケーション・ページを自動検出せずに手動で定義することを指定します。このオプションを選択すると、監視するアプリケーションに関連付けられているすべてのページを手動で定義する必要が生じてくるため、注意してください。ページの手動定義の詳細は、6.2.15項「ページの手動識別」を参照してください。このオプションがデフォルトです。
次に、「Finish」をクリックします。指定したアプリケーション定義が表示されます。例を図6-5に示します。
この概要には、定義したアプリケーションのサマリーが示されます。これには、アプリケーションの名前、これまでに一致した一意のページ数、最後に識別されたページの日付が含まれます。直前の3日間にアプリケーションについて識別されたページがない場合は、アプリケーションが現在機能していないことを示す警告のアイコンが表示されます。
画面の下部のタブでは、アプリケーションの具体的な項目の情報が表示されます。たとえば、「Identification」セクションではアプリケーションに対して現在定義されているフィルタ基準のサマリーが表示されます。また、「Pages」セクションでは、使用されるページ・ネーミング・スキーム、未分類のページのレポート設定、ページ・ロード満足度のしきい値、アプリケーションに所属するこれまでに識別されたページが示されます。それぞれのセクションの詳細は次の各項で説明します。
「HTML title」スキームまたはクライアント・リクエストのページ・ネーミング・スキームのいずれか（「URL base」など）を選択した場合、「application overview」の「Advanced」タブを使用してこれらのスキームの運用を微調整できます。「HTML title」スキームの場合は、図6-6に示すダイアログが表示されます。
図6-6 「Edit Application Page-Naming Scheme」ダイアログ
Time Recognition
「Time recognition」メニューを使用して、ページを識別するために非強制オブジェクトを使用するかどうかを制御できます。図6-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」タブをクリックすると、図6-8に示すダイアログが表示されます。
「Page handling」メニューを使用して、URL内のリダイレクトをどのように処理するかを指定します。次のオプションがあります。
Final page: ページ名を決定するために最終ページのURLのみを使用することを指定します。このオプションがデフォルトです。
Redirect naming: 最終ページの前でリダイレクトから得られる情報を使用してページを識別することを指定します。情報がない場合は、最終ページの情報が使用されます。
Redirect becomes page: リダイレクトが実際に識別されるページになるように指定します。最初のリダイレクトがページ作成に使用され、その後のすべてのリダイレクトは作成されたページのオブジェクトになることに注意してください。アプリケーションのレポートに及ぼす結果をよく理解した場合のみ、このオプションを選択することを強くお薦めします。
各アプリケーション定義では、使用するページ・ネーミング・スキームを指定する必要があります。このスキームは、規則指定機能を使用して拡張できます。追加の一致規則を指定できるようになり、それによって選択したスキームの微調整を行います。一致規則は、指定したページ・ネーミング・スキームに基づきます。規則指定機能は自動（手動ではない）ページ・ネーミング・スキームとの組合せのみで使用できることに注意してください。
|
注意: 規則指定は複雑であるため、指定したページ・ネーミング・スキームを十分理解しているユーザーのみがこの機能を使用することをお薦めします。また、選択したアプリケーションの基礎となる構文も明確に理解しておく必要があります。 |
選択したアプリケーションで規則指定の使用を指定する手順は、次のとおりです。
アプリケーションの初期定義を行った後（前述の説明を参照）、図6-5に示されるページ・ネーミング・スキーム設定をクリックします。「Manual」以外のスキームを選択した場合は、図6-9に示すダイアログが表示されます。
図6-9 「Edit Application Page-Naming Scheme」ダイアログ
「Ruling」タブをクリックして、使用する規則と、規則を評価する順序を指定します。図6-10に示すダイアログが表示されます。
このダイアログを使用し、新しい規則を定義するか、既存の規則を削除します。各規則のコンテキスト・メニューを使用して、適用順序を変更することもできます。「Add new matching rule」項目をクリックし、新しい一致規則を定義します。図6-11に示すダイアログが表示されます。
規則の次の要素を指定します。
Input value: 予期されるスキームの構造を指定します（URLまたはページ・タグ付けなど）。通常、受信したスキームを解釈するためのテンプレートを指定します。
Search expression: 一致する必要があるスキームの定義を指定します。これは通常、必須のパラメータからなるシーケンスで表されます。
Page group: 受信したスキームからページ・グループを識別する方法を指定します。これが未指定の場合、ページ・グループにはページ名が割り当てられます。
Page name: 受信したスキームからページ名を識別する方法を指定します。
規則の要素を指定したら、「Check rule」ボタンをクリックして、定義した規則が指定されている検証値と一貫性があることを検証できます。結果のウィンドウを展開すると、一致するプレースホルダーのサマリーを表示できることに注意してください。例を図6-12に示します。
次に、「Save」をクリックします。図6-10に示したダイアログに戻ります。
必要なすべての規則を定義したら、「« Check rules «」項目をクリックして、定義したすべての規則を検証値に対して検証できます。各検証値は、対応する規則に関連している必要があります。検証の後で、各規則の横にステータスを示すアイコンが表示されます。検証が失敗した規則については、マウスを重ねるとボックスに追加の情報が表示されます。図6-13に示す例について考えます。
最初の規則は定義済の検証値と一貫性があり、正常に検証されています。ただし、2番目の規則は非常に汎用性が高いため、複数の評価規則がこの規則と一致すると警告されます。実際に、汎用性が高いために関連する検証値がすでに正常に適用されてしまい、後続の規則を適用できません。つまり、3番目の規則が使用されません。このため、2番目の規則ではなく3番目の規則についてエラーがレポートされます。ただし、2番目の規則を移動して最後の規則にすると、3つの規則が正常に検証されます。
エラーがレポートされた規則指定の定義を保存することは可能ですが、問題があれば規則指定の定義を保存する前に解決することを強くお薦めします。次に、「Save」をクリックします。規則指定の定義の変更は5分以内に有効になります。
URL一致に関する規則指定
URL一致では大/小文字が区別され、URL（一致の後）は小文字に変換されることに注意してください。規則指定の後で、一致したスラッシュはページ名においてスペースに置き換えられます。
ユーザー識別に関する規則指定
規則指定機能は、ページ・ネーミング・スキームだけでなくユーザー識別スキームでも使用できます。この詳細は、6.2.10項「ユーザー識別の定義」に記載されています。
ユーザー識別のための規則指定の使用は、ページ・ネーミングについて説明した方法と同じです。ユーザー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|menswear/catalog"という構文に変換されます。その後、正しくレポートされるために次のように変換される必要があります。
ソース: %\%7C%/%グループ: %1 名前: %2
ソースの指定では、グループとページ名の間のセパレータ（|）は\%7Cと指定され、パイプ文字としてエンコーディングされます。URL構文内のスラッシュ記号は規則指定で使用できることに注意してください。規則指定の後で、一致したスラッシュは、レポートされるグループと名前においてはスペースに置き換えられます。
検索の構文
URL一致規則には、パラメータの他に、表6-1に示す要素も使用できます。
表6-1 拡張検索の構文
| 使用方法 | 説明 |
|---|---|
|
|
ゼロ個以上の文字に一致し、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定義によりアプリケーションに属していることが確認されているものの、関連する分類済の名前が見つからないものは、廃棄されレポートされません（デフォルト）。ただし、そのような未分類のページをデータ・ブラウザ・グループでレポートする場合は、図6-14に示す「application overview」内の「Pages」セクションにある「Report unclassified pages」チェック・ボックスを使用します。
ページの識別は、時間ベースのアクティビティであるため、オブジェクトとして予約されていないオブジェクトへの参照は、未分類のページであるとして、誤って識別される場合があります。このため、未分類のページのレポート作成は、テスト目的でのみ有効にすることをお薦めします。その後、これを再度無効にし、識別された問題のあるページを手動で定義できます。未分類のページは、対応するデータ・ブラウザ・グループ内のカテゴリ「other」にレポートされることに注意してください。
監視対象のサービス・テストはRUEIユーザー・フローにも変換できることに注意してください。この機能は、6.6.6項「サービス・テスト・セッションのユーザー・フローへの変換」に記載されています。
「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 »」をクリックして、アプリケーションと関連付ける必要のあるページの追加フィルタを指定します。また、既存のフィルタ定義を変更するには、それをクリックします。いずれの場合にも、図6-2に示したフィルタの中から選択できます。ユーザーによる追加または変更を反映するようにアプリケーション概要が更新されます。
セッションでアプリケーション・ページを表示している際のユーザー・エクスペリエンスを評価するために、RUEIではページごとに満足度レベルが割り当てられます。これは次のとおりです。
Satisfactory: ページは指定のしきい値内でユーザー・ブラウザにロードされます。このしきい値は、ページ・ロードの満足度のしきい値です。たとえば、ページが5秒以内にロードされる、などです。
Tolerable: ページのロードにかかる時間は指定のしきい値の4倍未満です。
Frustrating: ページのロードに、指定のしきい値の4倍よりも時間がかかります。
ページ・ロード満足度のレポートの例を図6-15に示します。
前述のように、この評価は、ページのロードの完了までに通常想定されるしきい値に基づきます。このしきい値を変更し、データ・ブラウザでレポートされるページ・ロード満足度を微調整できます。次を実行します。
目的のアプリケーションを選択し、「Pages」セクションをクリックし、現在定義されている「Page-loading satisfaction」設定をクリックします。図6-16に示すダイアログが表示されます。
ページのロードの完了までに通常想定される期間（秒単位）を指定します。デフォルトは4秒です。次に、「Save」をクリックします。指定した変更は、即座に有効になります。
ページに表示される文字列を検出して、アプリケーション・エラーとしてレポートする必要がある場合があります。たとえば、「選択された品目は在庫切れです」のようなメッセージです。このような関数エラーはシステム・エラー（Webサーバーまたはネットワークのエラーなど）とは異なります。リターン・コードではなくページ・コンテンツが原因であり、構成されたアプリケーション特有のエラーです。
選択したアプリケーションに含まれるすべてのページ内に、指定したエラー文字列がないかどうかが検索されます。ページ・コンテンツ・チェックの場合と異なり、特定のページに検索を限定することはできません。指定したエラー・テキスト文字列と一致するものとして表示されるページ・テキストが、ページ・コンテンツの結果である「error string: error search string」とともにレポートされます。関数エラーのレポートの例を図6-17に示します。
関数エラー文字列を定義する手順は、次のとおりです。
「Configuration」→「Applications」の順に選択して、目的のアプリケーションを選択します。（図6-5に示したような）「Application overview」が表示されます。「Errors」セクションをクリックし、次に「Errors」タブをクリックします。現時点で定義されている関数エラーが表示されます。「« Add new functional error »」をクリックして新しいエラーを定義するか、既存のエラーをクリックして変更します。図6-18に示すダイアログが表示されます。
「Search type」メニューを使用して検索範囲を指定します。これには、リクエストまたはレスポンスのヘッダーかコンテンツを指定できます。検索は、リテラル検索文字列またはXPath式に基づいて行うことができます。XPath式の場合、検索できるのはリクエスト・ヘッダーまたはレスポンス・ヘッダーのみです。
「String」フィールドを使用して、リテラル検索文字列を指定します。ワイルドカードの使用はサポートされておらず、指定するすべての文字がリテラルとして扱われることに注意してください。または、「XPath search」フィールドを使用して、使用するXPath式を指定します。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。
次に、「Save」をクリックします。変更は5分以内に有効になります。
監視対象とする各関数エラーを個別に定義するかわりに、事前定義済アプリケーション・エラーのリストを含むファイルをインポートできます。次を実行します。
「Configuration」→「Applications」の順に選択して、目的のアプリケーションを選択します。（図6-5に示したような）「Application overview」が表示されます。「Errors」タブをクリックし、次に「Errors」タブをクリックします。「« Upload list »」をクリックします。図6-19に示すダイアログが表示されます。
「Browse」ボタンを使用し、目的のファイルを検索して選択します。必要に応じて、「File encoding」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートの詳細は、付録G「各国語サポートの使用」を参照してください。サポートされていないエンコーディングが検出された場合、またはトランスコーディングに失敗した場合は、エラーがレポートされます。
アップロードされるファイルでは、1行に1つのエラー・メッセージを含める必要があり、空白の行を含めることはできません。これらのメッセージが、レスポンス内容で検索されるリテラル文字列になります。次に、「Merge」をクリックします。
必要に応じて、一意のエラー文字列それぞれに対して一連の説明を定義することもできます。たとえば、Oracle Databaseエラーの説明を表6-2のように定義できます。
表6-2 エラー文字列の説明の例
| エラー文字列 | 説明 |
|---|---|
|
|
DDLロックの取得が試行されましたが、すでにロックされています。 |
|
|
一時表の数が一時表ロックの数以上です。 |
|
|
マウントされているデータベースのDB_BLOCK_SIZE初期化パラメータが違います。 |
|
|
DB_FILES初期化パラメータの値が超過されました。 |
|
|
ユーザー・フローがリソースの待機中に互いにデッドロックしました。 |
|
|
起動中の共有インスタンスがDMLロックを使用しており、実行中のインスタンスがDMLロックを使用していません（あるいは、その逆の状態）。 |
|
|
インスタンスがDML_LOCKS = 0で起動されたが、実行中の文では全表ロック（S、XまたはSSX）が必要です。 |
|
|
指定されたログ・ファイルの数が、このリリースでサポートされているログ・ファイルの最大数を超えました。 |
エラーの説明を定義する手順は、次のとおりです。
「Configuration」→「Applications」の順に選択して、目的のアプリケーションを選択します。（図6-5に示したような）「Application overview」が表示されます。「Errors」セクションをクリックし、次に「Error translations」タブをクリックします。現時点で定義されているエラーの説明が表示されます。「« Add new translation »」をクリックして新しい説明を定義するか、既存の説明をクリックして変更します。図6-20に示すダイアログが表示されます。
必要なソース値とその説明を指定します。次に、「Save」をクリックします。
非常に多くの説明がある場合は、「Search」フィールドを使用すると目的の説明をすぐに見つけることができます。検索機能では部分一致が使用されます。ワイルドカードの使用はサポートされておらず、すべての文字がリテラルとして扱われます。次に、「Go」をクリックします。
それぞれの説明を別々に定義するかわりに、「« Upload list »」項目をクリックして、説明のリストを含むファイルをインポートできます。図6-21に示すダイアログが表示されます。
説明ファイルの名前を指定します。必要に応じて、「File encoding」メニューを使用し、ファイルのキャラクタ・エンコーディングを指定します。各国語のキャラクタ・セットのサポートの詳細は、付録G「各国語サポートの使用」を参照してください。サポートされていないエンコーディングが検出された場合、またはトランスコーディングに失敗した場合は、エラーがレポートされます。
ファイルには、ソース値とその説明をタブで区切って、1行に1つの説明のみを含めることができます。次に、「Merge」をクリックします。
標準のリターン・コード（404または500など）と一緒にコンテンツ・エラーがレポートされると非常に便利です。トラブルシューティングを促進するためにエラーのコンテキストに関する追加情報を提供することも可能になります。ただし、これはレポートのデフォルトの動作ではありません。
3.2.3項「ページ配信ディメンション」に記載されているように、1ページで数種類のエラー（たとえばサーバー・エラーとコンテンツ・エラー）が発生しても、ページ・エラーは複数回レポートされません。かわりに、エラーは特定の順序（Webサイト、サーバー、ネットワーク、コンテンツの順）でレポートされます。
標準のリターンが追加情報と一緒にレポートされるように指定する手順は、次のとおりです。
「Configuration」→「Applications」の順に選択して、目的のアプリケーションを選択します。（図6-5に示したような）「Application overview」が表示されます。「Errors」セクションをクリックし、次に「Advanced」タブをクリックします。
「Add additional explanations」チェック・ボックスを選択して、定義済の説明（ある場合）をレポートされるリターン・コードに付加することを指定します。デフォルトでは、このような説明は付加されません。
「Error translations」タブをクリックし、必要な説明を定義します。この手順は、6.2.9.3項「関数エラーの説明の定義」に記載されています。次に例を示します。
Source value: 1001 Translation: データベース接続が確立できませんでした
指定されるソース値は、失敗したデータベース接続の内部アプリケーション・コードを表します。
拡張ページ配信の詳細の例を図6-22に示します。
RUEIでは、新たに作成されるアプリケーションは、ユーザー識別が「HTTP Authorization」フィールドとSSLクライアント証明書の共通名（CN）部分（使用可能な場合）に基づくように自動的に構成されます。図6-23にこれを示します。
ただし、URL、Cookie、リクエスト・ヘッダー、レスポンス・ヘッダー、XPath式、カスタム・タグまたはレスポンス、OAMユーザー・トラッキング（6.3項「OAMベース・トラフィックの監視」を参照）に関して、アプリケーションのユーザー識別スキームを構成することもできます。「HTTP Authorization」フィールドは構成される他の値よりも優先されること、SSL証明書は代替スキームであることに注意してください。構成されたユーザーIDが監視対象トラフィックで検出されたものと一致しない場合、そのユーザーIDはAnonymousとしてレポートされます。
アプリケーションのユーザー識別スキームの構成
アプリケーションのユーザー識別スキームを構成する手順は、次のとおりです。
目的のアプリケーションを選択し、「Users」セクションをクリックします。
「« Add new source »」項目をクリックします。図6-24に示すダイアログが表示されます。
「Search type」メニューを使用し、ユーザーの識別メカニズムを指定します。これは、リテラル検索文字列またはXPath式を使用して指定できます。次の点に注意してください。
リテラル検索文字列の場合、リクエスト・ヘッダーまたはレスポンス・ヘッダーを検索するかどうかを指定できます。
XPath式の場合、リクエストまたはレスポンスを検索するかどうかを指定できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。
Cookieの場合は、Cookieの名前を指定する必要があります。選択したCookieに対して、またはデフォルトのCookieマスキング・アクションとしてハッシングが指定されている場合、Cookieの一意性は保たれますが、元の値は保存されません。この詳細は、8.4項「ユーザー情報のマスキング」に記載されています。
URL引数の場合は、引数の名前を指定する必要があります。
OAMベース・トラフィックの場合は、詳細について6.3項「OAMベース・トラフィックの監視」を参照してください。
カスタム・パターンの場合は、開始文字列と終了文字列（オプション）を指定して、検索対象のコンテンツの範囲を決める必要があります。ワイルドカード文字の使用はサポートされておらず、指定するすべての文字がリテラルとして扱われることに注意してください。また、終了文字列を指定すると、検索は次の行以降では行われません。
カスタム・タグの場合は、ユーザーIDが取得されるname=valueペアに名前を指定する必要があります。
前述のように、HTTPベースの認証が指定されている場合は、他に識別スキームが定義されても優先されます。また、SSLクライアント証明書が指定されている場合、これは代替スキームになります。
次に、「Save」をクリックします。
National Language Support
各国語のキャラクタ・セットを使用する際に識別が持つ意味の詳細は、付録G「各国語サポートの使用」を参照してください。
アプリケーションで検出されたページの構造は、ウィンドウの左側にあるアプリケーション概要に表示されます。例を図6-25に示します。
アプリケーションには、非常に多くのページが関連付けられている可能性があります。実際、図6-25に示す構造では、簡単には確認できないほど多くのページが関連付けられています。このため、この構造のビューは、Point of Interest（POI）を持つページに制限されています。したがって、レポートに含まれているページ、キー・ページとして定義されているページ、手動で名前が設定されたページ、監視対象KPIの一部であるページなどが表示されます。図6-26に示す表示メニューでは、構造概要に表示するページのタイプを制御できます。
次のオプションがあります。
All: すべてのアプリケーション・ページをリストします。
Report pages: レポート・フィルタとして指定されているページのみをリストします（2.5項「レポート・フィルタの使用方法」を参照）。
Checked pages: コンテンツ・チェックが定義されているページのみをリストします（6.2.14項「ページ・コンテンツ・チェックの指定」を参照）。
Manually named pages: 手動で定義されているページのみをリストします（6.2.15項「ページの手動識別」を参照）。
Key pages: キー・ページとして定義されているページのみをリストします（6.2.13項「ページの使用状況の追跡」を参照）。
アプリケーション・ページ・カテゴリをドリルダウンすると、特定のページに移動できます。ただし、多数のページを含むアプリケーションの使用時は、ページ検索機能を使用した方が便利な場合があります。次を実行します。
検索するアプリケーションを選択します。「Pages」セクションを選択し、「Identified pages」タブをクリックします。
目的のページの検索に使用する検索プロファイルを指定します。検索は現在のアプリケーションに制限され、ページ名は、アプリケーション » グループ » 名前という構造になることに注意してください。検索機能では、完全一致または部分文字列として指定した検索パターンとの一致が行われます。このため、検索パターンhomeは、アプリケーション、グループまたはページの名前におけるこの文字列または部分文字列の出現に一致します。次に、「Go」をクリックします。結果リストを図6-27に示します。
検索結果がダイアログの下半分に表示されます。一致したページをクリックして開きます。右および左矢印ボタンを使用し、結果の複数のページ間を移動します。また、表示メニュー（6.2.11項「アプリケーション・ページ構造の表示」を参照）を使用すると、特定の基準（レポートで使用されるページなど）に合うように表示リストを制限できます。
|
注意: 検索範囲には、検出済のページと、レポートおよびユーザー・フローに存在する未検出ページの両方が含まれます。 |
アプリケーションで検出された各ページに関する情報は、ページ分析ウィンドウで確認できます。例を図6-28に示します。
このウィンドウには次のタブがあります。
Identification: ページ識別スキーム（手動または自動）と、識別に使用する条件を指定します。
Content check: コンテンツ検索文字列がページに定義されているかどうかを指定します。この詳細は、6.2.14項「ページ・コンテンツ・チェックの指定」に記載されています。
Reporting: このページを含むレポートをリストします。レポートの詳細は、第2章「レポートの操作」に記載されています。
Monitoring: このページを含むKPIをリストします。KPIを定義する手順の詳細は、5.2項「KPIおよびSLAの定義」を参照してください。
キー・ページの定義
図6-28の「Key page」チェック・ボックスを使用して、ページをキー・ページとして定義します。
キー・ページは、監視対象のうち、特に注目するWebページです。通常、これは特に重要なページです。たとえば、組織のホームページや、注文入力などのユーザー・フロー内の一連のページなどがあります。これらのページに関しては、追加情報が記録されます。追加情報には、クライアント情報（ISP、アクセス元の国など）やクライアントのブラウザ情報（オペレーティング・システム、ブラウザ・バージョンなど）があります。
特定のページに特定のテキスト文字列が出現するかどうかの監視が必要となる場合があります。たとえば、Webアプリケーションに注文ページがあり、販売に成功した後、"ご購入ありがとうございました"というテキスト文字列がこのページに表示されるとします。目的のページにこの文字列があるかどうかを検索するページ・コンテンツ・チェックを定義できます。指定したテキスト文字列がそのページで見つからない場合、ページ・コンテンツ・チェックでは「configured string not found」を戻します。
ページ・コンテンツ・チェックを定義する手順は、次のとおりです。
「Configuration」→「Applications」→「Applications」の順に選択して、目的のアプリケーション・ページを選択します。ページ分析ウィンドウ（図6-28を参照）が表示されます。
「Content check」タブをクリックし、「«Add new check»」をクリックします。図6-29に示すダイアログが表示されます。
検索時に、リテラル検索文字列またはXPath式のいずれを使用するか、およびサーバーのレスポンスまたはクライアントのリクエストのどちらを検索するかを指定します。XPath式の場合は、クライアントまたはサーバーのレスポンス・コンテンツで検索する詳細な値も指定できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。次に、「Save」をクリックします。
アプリケーション全体のページを識別できるのみでなく、ページを手動で定義することもできます。手動で識別されたページは、アプリケーションによって自動的に識別されたページより優先されることに注意してください。この機能は、自動的には識別できないサブページに、別の名前を割り当てる場合に便利です。手動で識別されるページは、新規ページのベースとなる既存のページを選択して作成します。
ページが手動で識別されるようにするには、新規のページを最初から定義するか、既存のページ（自動で検出または手動で定義されたページ）を新規ページのベースとして使用します。
ページを定義する手順は、次のとおりです。
ページを最初から定義するには、目的のアプリケーションを選択し、「New page」ボタンをクリックします。既存のページを新規ページのベースとして使用するには、目的のアプリケーション・ページを選択し、「New page (based on current)」ボタンをクリックします。いずれの場合も、図6-30に示すダイアログが表示されます。
このダイアログを使用して、割り当てた名前がページに設定されるための条件を指定します。この条件は、ページURLの一部または詳細、コンテンツ、ドメインまたは引数を使用して定義できます。XPath式も指定できます。「Add condition」をクリックして必要な各条件を追加します。
詳細なURL（たとえばhttp://www.oracle.com/contact.htmlなど）を指定する場合、ドメインとそれ以外のURL構文はページ条件に自動的に割り当てられます。たとえば、「Find in domain」オプション（oracle.com）や「Find exact URL」（/contact.html）のようになります。
追加条件を指定すると、その条件がダイアログに表示されます。一致のためには、指定したすべての条件が満たされる必要があります。青字で表示される条件はクリックすると削除できますが、黒字で表示される条件は削除できないことに注意してください。ページを識別するには、1つ以上の条件を指定する必要があります。次に、「Next」をクリックします。図6-31に示すダイアログが表示されます。
このダイアログを使用して、ページのグループおよび名前を指定します。次に、「Finish」をクリックします。
新規ページの詳細が、図6-25に示したようなウィンドウに表示されます。このウィンドウを使用すると、ページ検出を追跡し、その定義を変更できます。
「URL diagnostics」グループ（3.2.4項「「URL Diagnostics」グループ」を参照）を使用すると、アプリケーションのヒットについてレポートされた機能URLを表示できます。これらは、特定の要件に合せてアプリケーション・レベルでカスタマイズできます。
URL診断を使用すると、アプリケーションの問題の把握に役立ちます。たとえば、特定のアプリケーションでロード時間が異常に長くかかる場合に、問題がある特定のオブジェクトまたは原因となっているサーバーをすぐに識別できます。さらに、この機能をセッション診断機能（3.10項「セッション診断機能の使用」を参照）と組み合せると、アプリケーションの問題について非常に高性能の根本原因分析を行うことができます。
選択したアプリケーションで使用するURL診断レポート・スキームを指定する手順は、次のとおりです。
「Configuration」→「Applications」の順に選択して、目的のアプリケーションを選択します。（図6-5に示したような）「Application overview」が表示されます。「Advanced」セクションをクリックし、「URL diagnostics」タブをクリックします。監視対象のURL範囲を指定するために使用される、現時点で定義済のURLパターンが表示されます。「« Add new URL pattern »」をクリックして新しいパターン一致スキームを定義するか、既存のパターン一致スキームをクリックして変更します。図6-32に示すようなダイアログが表示されます。
「URL match type」メニューを使用して、これから定義するスキームをすべてのアプリケーションのURLに適用するか、特定のURLのみに適用するかを指定します。後者の場合は、URL構文を指定する必要があります。この構文が「URL diagnostics」グループ内でアプリケーションについてレポートされます。定義するURLパターンが検出されたURLと一致したときにレポートされます。ワイルドカード文字（*）の使用はサポートされますが、指定する他の文字はすべてリテラルとして解釈されます。URL構文を定義しないと、アプリケーションの関連するヒットが「URL diagnostics」グループでレポートされないことに注意してください。
検出されるURL構文の一部（要素）をレポートするように指定することもできます。または、レポートされるURLを特定の引数に限定することもできます。いずれの場合も、「« Add URL argument/component »」項目をクリックします。図6-33に示すようなダイアログが表示されます。
「Scheme type」メニューを使用して、一致するURLをレポートするときに、特定のパラメータまたは要素に限定するかどうかを指定します。パラメータの場合は、レポートされるパラメータ名を指定する必要があります。要素の場合は、一致したURLから分離する要素を指定し、「Part」メニューを使用してレポートする必要がある部分を指定します。使用可能なオプションの数は、「URL component」フィールドに指定されるワイルドカード（*）の数と同じです。
たとえば、図6-34に示す要素の定義について考えます。
この場合は、*/MyShop/catalog/よりも後の部分のみがレポートされます。部分のパラメータは、「Value」定義に指定されたワイルドカードと照合されることに注意してください。たとえば、指定された値*/session=*/*には3つのワイルドカードが含まれるため、一致するURLは3つの論理部分を含むとみなされます。URL診断の定義には最大で9個のワイルドカードを指定できます。
次に、「Save」をクリックします。図6-32に示したダイアログに戻ります。
アプリケーションのパラメータと要素の定義を確認します。次に、「Save」をクリックします。5分後から一致するURLパターンが「URL diagnostics」グループでレポートされます。
除外するURLの情報
強制オブジェクト（D.4.2項「強制オブジェクト」を参照）は、レポートされるURLから自動的に外されます。この他に、セッション・パラメータおよび静的オブジェクト（イメージなど）のレポートを除外するように、アプリケーション定義を構成することをお薦めします。こうすることで、診断情報が長くなりすぎて切り捨てられることを防ぎます。
セッション診断の再生機能で表示されるアプリケーション・ページは、インラインJavaScriptコードを含む可能性があります。通常、このコードはチェックを実行するために使用されます。たとえば、指定されたサーバーに接続して、セッションが期限切れになったかどうかを判別します。このようなチェックおよびJavaScriptの他の機能は、関連するページを再生機能で表示するときに問題になることがあります。
この理由のために、アプリケーション構成機能を使用して、インラインJavaScriptコードの実行をReplay Viewerでどのように扱うかを指定できます（3.10項「診断機能の使用」を参照）。JavaScriptの実行を完全に無効にするか、特定の関数またはファイルをページの再生時に置き換えるように指定できます。
実行規則の定義
アプリケーション・ページの再生時に使用されるJavaScriptの実行規則を定義する手順は、次のとおりです。
「Configuration」→「Applications」→「Applications」の順に選択して、目的のアプリケーションを選択します。（図6-5に示したような）「Application overview」が表示されます。「Advanced」セクションをクリックし、次に「JavaScript replay」タブをクリックします。現時点で定義されている実行規則が表示されます。図6-35に示すようなダイアログが表示されます。
「Disable all JavaScript execution」チェック・ボックスを使用して、選択したアプリケーションのページが再生機能で再生されるときに、ページ内のすべてのJavaScriptコードを無効にするように指定します。このチェック・ボックスを選択すると、既存の実行規則は無視されます。新しい規則を定義することもできません。デフォルトでは、このチェック・ボックスが選択されています。
「« Add new rule »」をクリックして新しい規則を定義するか、既存の規則をクリックして変更します。この機能が使用できるのは、「Disable All JavaScript execution」チェック・ボックスを選択していない場合のみであることに注意してください。図6-36に示すようなダイアログが表示されます。
「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つのファイルを変更すると、対応するアプリケーションのみに適用され、他のアプリケーションには適用されません。
Oracle Access Manager(OAM）トラフィック内のユーザーIDを識別するように、RUEIを構成できます。OAMバージョン10.1.4.x（以上）がサポートされます。OAMベース・トラフィックを監視する手順は、次のとおりです。
目的のアプリケーションを選択し、「Users」セクションをクリックします。
「« Add new source »」項目をクリックします。図6-24に示すダイアログが表示されます。
「Search type」メニューで「Oracle Access Manager」オプションを選択します。
「Source value」フィールドに、監視対象のOAMベース・トラフィック内でユーザー識別を追跡するために使用するCookieの名前を指定します。デフォルトでは、これはObSSOcookieです。次に、「Save」をクリックします。カスタマイズされたCookie実装がOAMサーバーで使用される場合は、OAM管理者に問い合せてください。OAM Cookieのカスタマイズの情報は、Oracle Access Manager管理者ガイドに記載されています。
「Configuration」→「Applications」→「Session tracking」の順に選択します。現時点で定義されているCookieの設定が表示されます。例を図7-1に示します。
「« Add new cookie »」をクリックします。図7-2に示すダイアログが表示されます。
「Cookie type」メニューで「OAM」オプションを選択します。
「Cookie name」フィールドに、監視対象のOAMベース・トラフィック内でユーザー識別を追跡するために使用するCookieを指定します。デフォルトでは、これはObSSOcookieです。次に、「Save」をクリックします。
RUEIで使用するためのOAMサーバーの構成手順は、Oracle Real User Experienceインストレーション・ガイドに記載されています。
OAMベース・トラフィックのレポート
データ・ブラウザでのユーザーIDのレポートは、識別名（DN）に基づいています。例を図6-37に示します。
シングル・サインオン（SSO）とは、1回ログインすれば、ログインすることを再度求められることなく、複数のソフトウェア・システムのリソースにアクセスできるようになるアクセス制御方法です。アプリケーションとリソースが異なれば、サポートされる認証メカニズムも異なるため、SSOでは様々な資格証明を内部的に変換および保存して、初期認証で使用された資格証明と照合する必要があります。SSOには次の利点があります。
ユーザー名とパスワードの様々な組合せを管理する煩雑さを軽減します。
同じIDに対するパスワードの再入力に要する時間を省きます。
ITヘルプ・デスクに対するパスワード関連の問合せの数を減らすことで、ITコストを削減します。
SSOでは、中央の認証サーバーを使用し、他のすべてのアプリケーションおよびシステムがこれらのサーバーを認証目的で利用します。この技術が、ユーザーが自分の資格証明を複数回入力することを頻繁に求められないようにする技術と組み合せられます。
SSO対応アプリケーションが正しく監視されるようにするには、実際の環境で使用する認証サーバーを構成する必要があります。このためには、SSOプロファイルを作成します。
SSOサーバーでは、ユーザー・プロファイルを管理し、認証されたユーザーにログイン・ページを表示します。次に、アプリケーションがSSOサーバーと通信し、一時トークンを検証します。図6-38に、アプリケーション認証がSSOサーバーで有効化されている場合に機能する仕組みを示します。
図6-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」をクリックします。図6-39に示すダイアログが表示されます。
SSOプロファイルの名前を指定します。これは、スイート、サービス、アプリケーションおよびSSOプロファイルを通じて一意である必要があります。SSOプロファイルの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、SSOプロファイルの有効範囲を指定します。有効範囲はページURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「Filter preview」列に表示されます。
|
注意: SSOプロファイル、アプリケーション、スイートおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。こうしておかないと、予期しない結果がもたらされる可能性があります。一致規則の適用順序を制御する方法は、7.6項「RUEI内でのルール順序設定の制御」を参照してください。 |
最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。プロファイル名を指定して他のすべてのフィールドを空白にすることはできません。つまり、空白フィルタは使用できません。ワイルドカード文字（*）は「Find Port」フィールドには指定できません。標準以外のポート（つまりポート80/443以外）に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、SSOプロファイルは関連付けられないことに注意してください。指定できるポート番号は1つのみです。追加のポートを指定する必要がある場合は、新しいSSOプロファイルが作成された後で追加のフィルタとして指定してください。
ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURLの組合せ情報を指定しないことはできません。フィルタの適用順序を制御する方法は、7.6項「RUEI内でのルール順序設定の制御」を参照してください。
次に、「Next」をクリックします。図6-40に示すダイアログが表示されます。
このダイアログを使用し、使用しているSSO認証サーバーに関する情報を指定します。セッションCookie名、認証トークンを含んでいるURL引数、および監視対象トラフィックでのユーザーの識別方法を指定する必要があります。これは通常、URL引数と値を使用して定義します。ただし、Cookie、リクエスト・ヘッダーまたはレスポンス・ヘッダーあるいはXPath式で指定することもできます。
次に、「Finish」をクリックします。指定したSSOプロファイル定義の概要が表示されます。例を図6-41に示します。
この概要では、定義したSSOプロファイルのサマリーが示され、必要に応じて、その定義を変更できます。この詳細は次の項に記載されています。
ユーザー識別を定義した結果は、「XLS User Information」レポートの「Clients」カテゴリで確認できます。レポートの詳細は、第2章「レポートの操作」を参照してください。
SSOプロファイルを定義後に変更するには、その概要を使用します。次のタブがあります。
Identification: SSOサーバーの有効範囲を、ページURLの1つ以上の部分一致を使用して指定します。ページは、定義済のフィルタがページのURLに一致すると、SSOサーバーに割り当てられます。新規フィルタを追加するには、「«Add new filter»」をクリックします。既存のフィルタを変更するには、そのフィルタをクリックします。図6-42に示すようなダイアログが表示されます。
ダイアログの下部にある「Notice」は、現在のルール順序設定スキームを示しています。この詳細は、7.6項「RUEI内でのルール順序設定の制御」に記載されています。
Configuration: 使用される認証トークンとCookieを指定します。
User: ユーザーIDをアプリケーション内で識別する方法を指定します。これが未定義で、SSLクライアント証明書が存在する場合、この証明書が使用されます。
SSO対応アプリケーションの動作およびレポートが正しいかどうかを検証する場合、重要ポイントは、ユーザーIDが正しいかどうかを検査することです。データ・ブラウザ内のレポートを定期的に確認することをお薦めします（「All sessions」→「User Id」→「Sessions and pageviews」）。たとえば、未識別（匿名）ユーザーの数が予想より多い場合などです。
また、SSO対応アプリケーション内のURLがアプリケーション関連データとしてレポートされていないかどうかも検証する必要があります。レポートされている場合は、問題があることを示している可能性があります。
前述のように、RUEIにおけるページ識別は、アプリケーションに基づいて行われます。ただし、アプリケーションが特定のOracle Enterpriseアーキテクチャ（Oracle E-Business Suite、Siebel、WebLogic Portalなど）に基づいている場合、スイートという第4のレベルが導入されます。スイートとは一般にアプリケーションの集合であり、スイートに関連付けられているWebページは、スイート » アプリケーション » グループ » ページという構造を持ちます。
スイートを使用する理由
現在サポートされているOracle Enterpriseアーキテクチャのいずれかを監視対象の環境で使用している場合は、この機能を使用することを強くお薦めします。この機能を使用すると、アプリケーション定義にかかる時間が短縮され、スイート内のアプリケーションの互換性が高くなるのみでなく、これらのアーキテクチャが正しく監視されるようにもなります。
スイートの作成
スイートのインスタンスを定義する手順は、次のとおりです。
「Configuration」→「Applications」の順に選択して、図6-43に示すメニュー構造から「Suites」を選択します。
「New suite」をクリックします。図6-44に示すダイアログが表示されます。
スイートの名前を指定します。この名前は、スイート、サービス、SSOプロファイルおよびアプリケーションを通じて一意である必要があり、最大で6文字に制限されます。スイート・インスタンスの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、スイートの有効範囲を指定します。有効範囲はページURLの部分として定義されます。これらのフィルタ基準の使用方法は、6.2項「アプリケーションの定義」に記載されているものと同じです。この情報を入力すると同時に、入力した定義が「Filter preview」 列に表示されます。空白フィルタは使用できません。ワイルドカード文字（*）は「Find port」フィールドには指定できません。標準以外のポート（つまりポート80/443）に着信するネットワーク・トラフィックには、スイート・インスタンスは関連付けられないことに注意してください。明示的に指定できるポート番号は1つのみです。さらに必要な場合は、追加フィルタとして構成する必要があります。ワイルドカード文字を指定して、ドメイン名とURL引数の組合せによるその他の情報を指定しないことはできません。次に、「Next」をクリックします。図6-45に示すダイアログが表示されます。
|
注意: スイート、SSOプロファイル、アプリケーションおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。相互排他的ではないフィルタ定義を使用すると、予測できない結果が発生することがあります。フィルタの適用順序を制御する方法は、7.6項「RUEI内でのルール順序設定の制御」を参照してください。 |
このダイアログでは、スイートのベースとなるOracle Enterpriseアーキテクチャを指定できます。次に、「Finish」をクリックします。指定したスイート定義が表示されます。例を図6-46に示します。
この概要には、定義したスイートのサマリーが示されます。これには、定義したページ識別フィルタ、スイートに今までに一致したページの数、検出および記録が必要な関数エラー（存在する場合）、およびビジター・セッションの追跡にスイート内で使用されるユーザー識別メカニズムが含まれます。これらはすべて、必要に応じて個別に変更できます。手順は、6.2項「アプリケーションの定義」に記載されているものと同じです。
パッケージに付属の該当スクリプトをOracleアーキテクチャの本番環境で実行することをお薦めします。たとえば、create_EBS_info.plスクリプトなどです。このスクリプトの目的は、実際の環境でこれらのアーキテクチャが実装された方法を特定することです。特に重要なのは、ページ・ネーミング・スキームです。次を実行します。
選択したスイートに付属の適切なスクリプトをダウンロードします。この機能の使用方法の詳細は、対応する付録を参照してください。
スクリプトをデプロイメント環境で実行します。このスクリプトにより、環境内でページIDにIDが割り当てられます。多数の.txtファイルが作成されます。
生成された.txtファイルから.zipファイルを作成します。
「Configuration」→「Applications」→「Suites」の順に選択して、該当するスイートを選択します。スイートの概要が表示されます。「Upload configuration」コマンド・ボタンをクリックします。図6-47に示すダイアログが表示されます。
スクリプトで生成されたファイルの名前を指定します。目的のファイルを検索するための「Browse」ボタンが使用可能です。ファイルは.zipファイルである必要があります。次に、「Upload」をクリックします。
|
注意: この構成ファイルは、目的の各スイート・インスタンス用にアップロードする必要があります。構成ファイルには、既知の（および空でない）.txtファイルのみを含めることができます。これらのファイルはすべてルート・ディレクトリに存在する必要があります。つまり、サブディレクトリは許可されていません。実際の本番環境に基づいた適切な構成ファイルを目的のスイート・インスタンス用にアップロードする必要があります。誤った構成ファイルをインポートすると、不適切なレポートが作成されます。 |
スイート定義の変更
前述のように、スイートとは一般にアプリケーションの集合です。スイートの定義後にそのプロパティを変更するには、6.2項「アプリケーションの定義」でアプリケーションに関して記載されているのと同じ方法を使用します。
次の点に特に注意してください。
スイートでクリックアウト機能を使用するためには、スイート・インスタンスのエンタープライズ名を正しく指定する必要があります（7.7項「外部ツールへのクリックアウトの構成」を参照）。これは、EMGCでのスイートの構成から取得できます。たとえば、ec2ebs2-Oracle E-Business Suiteまたはsiebel_emgc-amp11.us.oracle.comです。
スイート固有のデフォルトの関数エラーが多数定義されています。これを確認して、実際の環境の要件に合うようにしてください。手順は、6.2.9項「アプリケーションの関数エラーのトラップ」に記載されているものと同じです。
デフォルトでは、未分類のページはレポートされません。これを変更するには、「Report unclassified pages」チェック・ボックスを選択します。手順は、6.2.3項「未分類のページのレポート作成」に記載されているものと同じです。
「Report service test traffic」チェック・ボックスを使用して、選択したスイートのためにOracle Enterprise Manager Grid Controlで構成されているサービス・テスト・トラフィックをRUEIでレポートするかどうかを指定できます。デフォルトでは、レポートは行われません。この機能の使用方法の詳細は、3.2.6項「Oracle Enterprise Managerのサービス・テスト監視」に記載されています。監視対象のサービス・テストはRUEIユーザー・フローにも変換できることに注意してください。この機能は、6.6.6項「サービス・テスト・セッションのユーザー・フローへの変換」に記載されています。
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはIPパケットからフェッチされます。ただし、RUEIシステムをNATサービスの前に配置する場合には、特定のヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。この詳細は、付録O「NATトラフィックの監視」に記載されています。
スイートごとに、デフォルトのユーザー識別スキームが定義されています。これを確認して、実際の環境の要件に合うようにしてください。手順は、6.2.10項「ユーザー識別の定義」に記載されているものと同じです。
「suite diagnostics」グループ（3.2.4項「「URL Diagnostics」グループ」を参照）を使用すると、スイートのヒットについてレポートされた機能URLを表示できます。この機能の使用方法は、アプリケーションの場合と同じです（6.2.16項「「URL Diagnostics」グループ内でのレポートの制御」を参照）。
スイート全体のページを識別できるのみでなく、ページを手動で定義することもできます。手順は、6.2.15項「ページの手動識別」に記載されているものと同じです。ただし、新規ページを最初から定義することはできません。既存のページを新規ページのベースとして使用する必要があります。
この項では、ネットワーク・トラフィックを監視するときのユーザー・フローの役割について考えます。また、ユーザー・フローを構成する要素（ステップ、条件、イベントなど）やRUEIでのそれらのレポートについて説明します。
ユーザー・フローとは、1つの論理タスクを定義したWebページの集合です。タスクを完了するために実行する必要がある複数のステップで構成されます。たとえば、予約ユーザー・フローには次のステップが定義されます。
航路と日付の詳細。
乗客と船舶の詳細。
支払いの詳細。
確認書。
個々のステップは複数のWebページで構成される場合があります。たとえば、上記の支払いの詳細ステップでは、使用できる支払い方法（クレジット・カードや銀行振込みなど）ごとに独立したページを定義できます。ユーザー・フローは、ビジターが最後のステップに到達したときに完了したとみなされます。また、ステップは主にページに関して定義されますが、他のディメンション（SiebelのメソッドまたはEBSの職責やアクションなど）に関しても定義できます。
管理を容易にするために、ユーザー・フローはカテゴリにグループ分けされます。たとえば、予約、パンフレット請求、CRMアクティビティなどのために個別のカテゴリを定義できます。
条件とイベント
ユーザー・フローのステップは条件に関して定義されます。条件は、ステップに到達したとみなされるために満たす必要がある要件です。各条件はイベントに基づいて定義されます。イベントはディメンション値を使用して指定されます。
たとえば、上記の支払いの詳細ステップについて考えてみます。通常、このステップにはいくつかの異なる条件が定義され、それぞれが別の支払方法に対応しています。ステップに到達したとみなされるためには、ユーザー・セッション中にこれらの条件の1つだけが満たされる必要があります。各条件はイベント（つまり、特定のディメンション値）を使用して定義されます。条件が満たされたとみなされるためには、イベントが実現する必要があります。ある条件が満たされたとみなされるには、その条件について定義されたすべてのイベントが実現する必要があることに注意してください。
オプション・ステップと必須ステップ
ユーザー・フロー内のステップは、オプションまたは必須として構成できます。たとえば、ユーザー・フローのステップA、B、CおよびDを定義し、パスA > B > C > D、A > B > D、A > BおよびA > C > Dが可能とします。この場合、ステップBおよびCがオプションで、ステップAおよびDが必須です。パスA > B > Dを進んだビジターの場合、ユーザー・フローはA > B > C（スキップ） > Dとレポートされます。ユーザー・フローの最初と最後のステップはオプションとして定義できません。
外部ページとアボート・ページ
ビジターがユーザー・フローを完了する途中でステップとして定義されていないページにナビゲートすることがあります。このようなページは外部ページと呼ばれます。この場合、ビジターがユーザー・フローを実際にアボートしようとしているのか、ユーザー・フローに戻ることが許可されるのかを判別する必要があります（たとえば、ヘルプ・ページで操作方法を調べた後など）。ただし、ビジターが特定の外部ページにナビゲートしたときは、ユーザー・フローがアボートされたとみなす必要があります。このようなページはアボート・ページと呼ばれます。
最初のステップには特に注意する必要があります。ビジターが最初のステップに戻った場合、現在のユーザー・フローをアボートして新しいユーザー・フローを開始しようとしているのか、現在のユーザー・フローを完了する意図がまだあるのかを判別する必要があります。たとえば、上記の予約ユーザー・フローでは、ビジターが支払いの詳細ステップにいたときに、航路と日付の選択ステップに戻ることを選択した場合は、現在のユーザー・フローを中止して新しいユーザー・フローを開始しようとしていると考えられます。
アイドル時間とタイムアウト
ビジターは特定の時間内（たとえば5分間）でユーザー・フロー・ステップを完了することが予期されます。時間内に完了しないと、ユーザー・フローはアイドルとみなされます。ただし、ステップによっては時間が長くかかることがあるため（たとえば、ビジターが情報を読むための時間が必要な場合など）、ユーザー・フローの各ステップについて許容されるビジターのアイドル時間を構成できます。
セッション・アイドル時間（7.4.3項「セッション・レポートの制御」を参照）では、ビジターが非アクティブになってからセッションが終了したとみなされるまでの時間が指定されることに注意してください。デフォルトでは60分です。ただし、ステップのアイドル時間は、特定のユーザー・フロー・ステップ内でビジターが非アクティブになる時間のみを指します。セッションのアイドル時間がユーザー・フローで経過すると、ユーザー・フローのタイムアウトとしてレポートされます。
新しいユーザー・フローを定義するには、ビジネス・レベルの「Full」権限が必要です。次を実行します。
「Configuration」→「Applications」→「User flows」の順に選択します。現在定義されているユーザー・フローのカテゴリがウィンドウの左側にリストされます。ツールバーの「New user flow」コマンド・ボタンをクリックします。ダイアログが表示されます。
「Add User Flow」ダイアログ|
注意: 既存のユーザー・フローではステップの追加または削除を行うことはできません。ユーザー・フローが基づいているデータ・アクセス権限も変更できません。したがって、ユーザー・フローを構成する前に、要件を反映するように注意深く設計することをお薦めします。 |
ユーザー・フローの名前を指定します。名前はすべてのユーザー・フローを通じて一意にする必要があり、長さは255文字までに制限されます。定義できるユーザー・フローの最大数は100であることに注意してください。
「Category」メニューを使用して、ユーザー・フローを収めるカテゴリを選択します。新しいカテゴリに収める場合は、「New category」ボタンをクリックして新しいカテゴリの名前を指定します。
「Data access」メニューを使用して、ユーザー・フローを特定のアプリケーションまたはスイートにバインドするか、汎用にするかを指定します。データ・アクセス・フィルタの使用方法は、1.7.3項「データ・アクセス・フィルタの使用」を参照してください。
必須ユーザー・フロー・ステップごとに、「« Add new step »」項目をクリックします。図6-48に示すダイアログが表示されます。1つのユーザー・フローに含めることができるステップの最大数は15であることに注意してください。
ステップの名前を指定します。これはこの新規ユーザー・フロー内で一意にする必要があります。ユーザー・フロー・レポートで読みやすくするためにステップ名は短くすることをお薦めします（6.6.5項「ユーザー・フローのレポート方法の概要」を参照）。
ビジターが非アクティブになってからステップがタイムアウトしたとみなされるまでの時間（分）を指定します。デフォルトでは10分です。ステップのアイドル時間は、ステップで必要な読取りの時間やビジターが実行する必要がある他の操作（計算や選択など）に対応できるようによく検討することをお薦めします。デフォルトのユーザー・フロー・ステップのアイドル時間は、6.6.3項「デフォルトのステップ・アイドル時間の指定」に記載される手順を使用して指定できます。
このステップがユーザー・フローの最初または最後のステップでない場合は、「Optional」チェック・ボックスを使用して、ユーザー・フローの一部としてビジターがこのステップを完了する必要があるかどうかを指定できます。デフォルトでは、ステップは必須です（チェック・ボックスは選択されていません）。
ステップに到達したとみなされるために満たす必要がある最初のステップ条件を指定します。条件のイベントごとに、「Dimension level」および「Value」メニューを使用して、チェックされるディメンションと保持する必要がある値を選択します。目的の値が「Value」メニューにない場合は、横にある「Search」アイコンをクリックして探すことができます。
オプションとして、「Exclude」チェック・ボックスを使用すると、定義したディメンション・レベル=値のペアを除外するように適用できます。つまり、定義したイベントが満たされない場合に、イベントが達成されたとみなされます。たとえば、特定のページが表示されない場合です。次に、「Save」をクリックします。元のダイアログに戻ります。
オプションとして、新規ステップの下の「« Add new condition »」項目をクリックして、ステップで必要な追加の条件を定義します。図6-49に示すダイアログが表示されます。
必要な条件イベントごとにディメンション・レベル=値のペアを指定します。次に、「Add」をクリックします。ステップに到達したとみなされるためには定義された1つの条件のみを達成する必要がありますが、条件が満たされたとみなされるためには条件内のすべてのイベントが達成される必要があります。次に、「Save」をクリックします。元のダイアログに戻ります。
「Abort conditions」タブをクリックして、ユーザー・フローがアボートされたとみなされる状況を指定します。図6-50に示すダイアログが表示されます。
次のチェック・ボックスがあります。
First user flow step: ビジターが最初のステップに戻った場合にユーザー・フローがアボートされたとみなすかどうかを指定します。デフォルトでは選択されていません。
All outside pages: 選択されたユーザー・フロー内のステップとして定義されていないページにビジターがナビゲートした場合に、ユーザー・フローがアボートされたとみなすかどうかを指定します。デフォルトでは選択されていません。
All other first user flow steps: 別のユーザー・フローの最初のステップとして定義されているページにビジターがナビゲートした場合に、ユーザー・フローがアボートされたとみなすかどうかを指定します。デフォルトでは選択されていません。
オプションとして、「« Add new condition »」項目をクリックして、ビジターがナビゲートした場合にユーザー・フローがアボートされたとみなす特定のページ（またはディメンション）を指定します。
オプションとして、「Monetary value」タブをクリックし、図6-51に表示される「Monetary source」メニューと「Source value」フィールドを使用して、ユーザー・フローでレポートされる通貨価値が基づくソースを指定します。この機能の使用方法の詳細は、6.6.4項「ユーザー・フローへの通貨価値の割当て」に記載されています。
通貨価値は、URL引数、XPath式、ヘッダー、Cookie、カスタム・タグまたはカスタム関数から導出できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。
次に、「Save」をクリックします。新規ユーザー・フローの監視は5分以内に開始されます。新しいユーザー・フローの概要が表示されます。
イベント・ステップの処理方法の概要
レポートされるユーザー・フロー情報を分析するときは、RUEIがユーザー・フロー・アクティビティを処理する順序を理解することが重要です。この順序をまとめると次のようになります。
RUEIは、ビジターがユーザー・フローで進んだかどうかを判別しようとします。つまり、ビジターが次のステップに移動したかどうかを判別しようとします。移動した場合、それに応じてレポートされる進捗が更新されます。
次のステップに直接進んでいない場合は、後続の各ステップ（オプション・ステップの場合）に進んだかどうかがチェックされます。進捗が判別されると、レポートされます。
進捗が判別されなかった場合は、現在のステップがチェックされます。これが失敗すると、先行するすべてのステップ（オプション・ステップの場合）がチェックされます。進捗が判別されると、レポートされます。
ここまですべてのチェックでユーザー・トランザクションの進捗が確認できない場合は、アボート条件がチェックされます。条件が一致すると、ユーザー・フローがアボートされたとレポートされます。一致しない場合、ユーザー・フローの現在のステータスが、外部アクティビティとしてレポートされます。
ベスト・プラクティス
ユーザー・フローを定義するときは特に次の点に注意することをお薦めします。
ビジターが最後のステップに到達したときにユーザー・フローが完了したとみなされるため、最後のステップとして確認ページまたは完了のページを必ず定義する必要があります。
オプション・ステップを定義するときは、承認されたナビゲーションが行われるようにWebサイトを構成してください。
ユーザー・フローを定義するときはステップ・アイドル時間に特に注意することをお薦めします。ステップのアイドル時間をセッションのアイドル時間よりも長く定義すると、セッションのアイドル時間が優先され、セッションのアイドル時間を超過したユーザー・フローがタイムアウトとしてレポートされることに注意してください。
既存のユーザー・フローではステップの追加または削除を行うことはできません。ユーザー・フローが基づいているデータ・アクセス権限も変更できません。したがって、ユーザー・フローを構成する前に、要件を反映するように注意深く設計することをお薦めします。
ステップの条件およびステップの他の情報（名前、場所、アボート条件、通貨価値など）は変更できることに注意してください。ユーザー・フローを変更する手順は、次のとおりです。
「Configuration」→「Application」→「User flows」の順に選択します。ウィンドウの左側で適切なカテゴリとユーザー・フローをクリックします。選択したユーザー・フローの概要が表示されます。例を図6-52に示します。
「Edit」コマンド・ボタンをクリックします。ダイアログが表示されます。
オプションとして、ステップのコンテキスト・メニューで「Edit」を選択し、名前、アイドル時間またはオプションと必須の設定を変更します。前述のように、ユーザー・フローは少なくとも2つのステップを含む必要があります。最初のステップと最後のステップは必須です。次に、「Save」をクリックします。
オプションとして、個々のステップ条件をクリックして変更することもできます。または、横にある「Remove」アイコンをクリックすると削除できます。ステップ内の「Add new condition」項目をクリックして、ステップに追加の条件を定義することもできます。
次に、「Save」をクリックします。ユーザー・フロー定義の変更は5分以内に有効になります。
既存のユーザー・フローに行える変更は限られているため、ウィンドウの左側でユーザー・フローのコンテキスト・メニューの下にある「Copy」オプションを使用すると便利です。特に、このオプションを使用すると、問題のあるユーザー・フローのwhat-if分析を実行できます。
たとえば、ユーザー・フロー内の特定のステップでのアボート率が高い場合があります。ビジターのブラウザの言語設定に問題が関係しているのではないかと考えます。コピー機能を使用して、ユーザー・フローの複製を作成し、必要なステップ定義を変更します。その後、元のユーザー・フローと変更したユーザー・フローの結果を比較して、ユーザー・フローの変更によって改善したかどうかを確認します。
新しいユーザー・トランザクションが作成されるたびに、そのトランザクションのステップにアイドル時間が割り当てられます。これは、ビジターが非アクティブになってからステップがタイムアウトしたとみなされるまでの時間です。デフォルトは10分です。ただし、「Configuration」→「General」→「Advanced settings」→「Session processing」→「Default user flow step time」の順に選択して、デフォルトを変更できます。この設定の変更は新規ユーザー・トランザクション定義のみに適用されることに注意してください。既存のユーザー・フローには影響しません。
パフォーマンス問題の実際のコストを把握するために、終了したユーザー・フローに通貨価値を割り当てることができます。終了したユーザー・フローとは、完了したユーザー・フロー、タイムアウトしたユーザー・フローまたはアボートされたユーザー・フローです。たとえば、この機能を使用すると、ユーザー・フローの損失に関してサーバー・アップグレードのコストを判別できます。通貨価値のソースは、カスタム・ディメンションと同様の方法で指定されます（3.9項「カスタム・ディメンションの使用」を参照）。様々なユーザー・フローの通貨価値の比較例を図6-53に示します。
重要:
ユーザー・フローに通貨価値を割り当てるときは、次の点に注意してください。
選択した要素の通貨価値を判別するとき、先行するスペースはすべて削除されます。数字が出現してから次に数字以外の文字が出現するまでの部分が、値として取得されます。たとえば、?Basket=99.99 US dollarsという要素は99と計算されます。
値が、負の数、232よりも大きい、または文字列であると判別されると、0が返されます。
基礎となる要素（リクエスト・ヘッダーなど）は、ユーザー・フローの間に変化することがあります。図6-54に示す状況について考えます。ユーザー・フローAが開始したとき、通貨価値は0でした。ユーザー・フローが進行するにつれ、通貨価値は80、120、90と変化します。完了時には通貨価値90がレポートされます。
このじょうご型の図では、選択したユーザー・フローに関する一般的な情報が得られます。選択した期間のユーザー・フローでのビジターの推移が示されます。例を図6-55に示します。
選択したユーザー・フローの最新ステータスのさらに詳しい情報は、「Flow status」表示で確認できます。特に、現在各ステップを使用しているビジター数、ビジターがステップで行ったWebアクション（ページ・ロードやエラーなど）の状況、タイムアウトしたステップとアボートされたステップの数が表示されます。例を図6-56に示します。
ユーザー・フロー内のオプション・ステップは点線で示されます。ステップで発生した特定のエラーに関する詳しいセッション情報を含む診断情報は、ステップ内の「Error on step」インジケータをクリックすると表示されます。この機能の使用方法の詳細は、3.10項「診断機能の使用」に記載されています。
ユーザー・フローの最も詳細な情報は、「Flow transitions」表示で得られます。例を図6-57に示します。
ステップにおける外部アクティビティのレベル、アボート、タイムアウト、オプション・ステップのスキップなど、ステップ間の遷移について豊富な情報が提供されます。「Idle」項目は、ステップを使用しているが、定義されたステップ・アイドル時間よりも非アクティブな状態が続いているビジター数を示すことに注意してください。これらのビジターが1時間以内にアクティビティを再開すると、「Idle returns」項目に表示されます。再開しない場合は、タイムアウトとみなされてステップが停止します。
「Service test diagnostics」グループ（3.2.6項「Oracle Enterprise Managerのサービス・テスト監視」を参照）では、選択したサービス・テスト・セッションをRUEIユーザー・フローに変換することができます。こうすると、監視対象のユーザー・フローが「Transactions」グループ内でレポートされるという利点が得られます。監視対象の他のユーザー・トランザクションと直接比較できるだけでなく、レポート機能が強化されます。
サービス・テスト・セッションをRUEIユーザー・トランザクションに変換するには、ビジネス・レベルの「Full」権限が必要です。次を実行します。
「Browse data」→「Service test」グループを順に選択し、「Service test diagnostics」機能をクリックします。図3-23に示すような診断パネルが表示されます。診断機能の概要は、3.10項「診断機能の使用」を参照してください。
カレンダ・コントロール（2.4項「カレンダの使用方法」を参照）を使用して、目的の期間を選択します。表示範囲としては1日（または未満）を選択する必要があります。この制限外で検索しようとするとエラーが発生します。次に、「Search」をクリックします。検索結果がウィンドウの主要部に表示されます。例を図6-58に示します。
検索機能を使用するには、検索パターンを指定して「Go」をクリックします。他の診断グループとは異なり、指定する検索パターンが、ビーコン名またはサービス・テスト名を指す必要があることに注意してください。
サービス・テスト・セッションを選択したら、「Service test diagnostics」ツールバーの「Create user flow」コマンド・ボタンをクリックして、選択したサービス・テスト・セッションをRUEIユーザー・トランザクションに変換します。図6-59に示すダイアログが表示されます。
図6-59 「Add User Flow From Service Test Session」ダイアログ
新しいユーザー・フローの名前を指定します。これは選択したユーザー・フロー・カテゴリ内で一意にする必要があります。デフォルトは、監視対象のサービス・テスト名です。
新しいユーザー・フローを収めるするカテゴリを指定します。既存のカテゴリでも新規カテゴリでもかまいません。デフォルトは「Service test」です。
オプションとして、各ステップ名のコンテキスト・メニューを使用して、ステップの詳細の編集、ステップの削除、新しいユーザー・フロー内での位置変更を行います。
次に、「Save」をクリックします。
重要:
サービス・テスト・セッションをユーザー・フローに変換するときは、次の点に注意してください。
新規ユーザー・フローのステップは最大15に制限されます。この制限を超えるステップを含むサービス・テスト・セッションは、自動的に切り捨てられます。
各ステップには、作成されたユーザー・フロー内で一意の名前を付ける必要があります。
変換されたユーザー・フローには少なくとも2つのステップが含まれる必要があります。
複数のトランザクションまたは重複ステップを含むサービス・テスト・セッションからはユーザー・フローを作成できません。
