| Oracle Real User Experience Insightユーザーズ・ガイド リリース6.5.1 for Linux x86-64 B61012-01 |
|
 戻る |
 次へ |
この章では、監視される環境で使用する基本的なWebサイト構成の管理方法について説明します。これには、Cookieテクノロジ、ユーザー識別スキームおよびWebサービスの指定が含まれます。さらに、いくつかの高度な機能についても説明します。ネットワーク・トラフィックの監視に使用されるルール順序設定の変更や、データのレポートを微調整する機能が含まれます。
RUEIがユーザーのWeb環境を正確に監視するためには、RUEIは、ユーザーのWebサイトが使用しているCookieテクノロジを把握して認識する必要があります。Cookieテクノロジは標準的なテクノロジ（ASPやColdFusionなど）かカスタム実装のいずれかになります。カスタム実装の場合には、関連する情報をシステムに提供する必要があります。監視時に使用するCookieテクノロジは最大5つ定義できます。
Cookieテクノロジを指定する手順は、次のとおりです。
「Configuration」→「Applications」→「Session tracking」の順に選択します。このオプションを使用できるのは管理者のみです。現時点で定義されているCookieの設定が表示されます。例を図7-1に示します。
「« Add new cookie »」または既存のCookie定義をクリックします。図7-2に示すようなダイアログが表示されます。
Web環境で使用しているCookieテクノロジを「Cookie type」メニューから選択します。非標準テクノロジを使用している場合は、「(custom)」を選択します。
「(custom)」を選択した場合は、組織で使用しているCookieの名前を指定する必要があります。Cookie名の一部としてワイルドカード文字（*）を指定できることに注意してください。
|
注意: Cookie名は大/小文字が区別されます。 |
「(URL argument)」を選択した場合は、組織で使用しているURL引数の名前を指定する必要があります。セッションの追跡でのURL引数の使用方法は、付録B「Cookieの構造」に記載されています。次に、「Save」をクリックします。
この設定への変更は、少しの間隔（通常5分〜10分）を置いて適用され、さらにその少し後にレポータ・システムに表示されます。
前述のように、セッションの追跡はCookieに基づいて行います。ただし、Cookieが適していない状況または使用できない状況があります。たとえば、次の状況について考えてみます。
Cookieがヒットごとに変化する場合（たとえば、ObSSOCookieのケース）。
Cookieに設定されているパスがアプリケーションの一部にしか対応しない場合。
Webサーバーで構成されているプライバシ・ポリシーのためにCookieの使用が無効な場合。
セッションの追跡のために適切なCookieがない場合は、JavaScriptを使用してクライアント側のCookieメカニズムを実装することをお薦めします。
クライアント側のCookieメカニズムの構成
次を実行します。
該当するログイン・ページに次のコードを追加します。
<SCRIPT
LANGUAGE="JavaScript">if(document.cookie.indexOf('track=')==-1){document.cookie
='track='+parseInt(Math.random()*2147418112)+new
Date().getTime()+';path=/;domain='+document.location.host.substring(
document.location.host.lastIndexOf('.',
document.location.host.lastIndexOf('.') - 1)) ;}</SCRIPT>
「Configuration」→「Applications」→「Session tracking」の順に選択します。「Add new cookie」をクリックします。図7-3に示すダイアログが表示されます。
Cookieテクノロジ「(custom)」を「Cookie type」メニューから選択し、適切なCookie名を指定します。前のJavaScriptコードではCookie名はtrackです。これはログイン・ページのJavaScriptコードに指定した名前と一致する必要があります。使用できるのは英数字のみです。また、ヘッダー・サイズを最小限にするためにCookie名は10文字以下にすることをお薦めします。次に、「Save」をクリックします。
Cookie構成の確認
Cookie構成が正しく追跡されることを確認する手順は、次のとおりです。
ブラウザですべてのCookieを消去します。
監視対象のアプリケーションに（再）ログインします。
いくつかのページ表示を実行します。
監視対象のアプリケーションからログアウトします。
少なくとも10分間待機します。
RUEIレポータ環境を開き、「Browse data」を選択し、「All sessions」グループを開いて「Session diagnostics」を選択します。記録されたセッション（ユーザーID別または時間別）を探します。アプリケーションについてフィルタリングできます。
セッションを開き、ログイン・ページ以外にページ・ビューがあることを確認します。これで、セッションIDがログイン後に保存されていることが確認されます。
Cookieテクノロジを指定しない場合は、クライアント・ネットワークとクライアント・ブラウザの組合せを使用してセッションを追跡します（デフォルト）。ただし、この方法が環境に適していない場合は、代替追跡メカニズムとしてクライアントIPアドレスを使用できます。
代替セッション追跡メカニズムを指定する手順は、次のとおりです。
「Configuration」→「Applications」→「Session tracking」の順に選択します。現時点で定義されているCookieの設定が表示されます。現時点で定義されているセッション追跡の代替メカニズムをクリックします。図7-4に示すダイアログが表示されます。
「Tracking mechanism」メニューを使用して、クライアント・ネットワークとブラウザの組合せを使用する（デフォルト）かクライアントIPアドレスを使用するかを指定します。
次に、「Save」をクリックします。行った変更は、即座に有効になります。
代替セッション追跡メカニズムの選択
どちらの代替メカニズムを使用するかを検討するとき、外部用アプリケーションではデフォルトのネットワークとブラウザの組合せを使用し、内部用アプリケーションではクライアントIPアドレスを使用するのが原則です。同じプロキシ・サーバーで複数のユーザーが存在する場合は、デフォルトの代替メカニズムの使用をお薦めします。ただし、この場合は、すべてのユーザーが1つのセッションに記録されることに注意してください。通常、次の状況ではクライアントIPアドレス・メカニズムの使用をお薦めします。
すべてのユーザーに一意のIPアドレスがある場合。アプリケーションごとに、クライアントIPアドレスをTCPパケットから取得するか、特定のHTTPリクエスト・ヘッダーから取得するかを指定できることに注意してください。この詳細は、付録O「NATトラフィックの監視」に記載されています。
組織で定められたブラウザが使用されている場合。つまり、標準のバージョンおよびプラグインの標準ブラウザ（Internet ExplorerまたはMozilla Firefoxなど）。
管理対象のアプリケーションの一部（またはすべて）が部分的にJavaで実装されている場合。Oracle E-Business Suite（EBS）は、このようなアプリケーション・アーキテクチャの例です。このようなアプリケーションでは、クライアントIPアドレス・メカニズムの使用により、Javaとクライアント・リクエストの両方が同じレポート・セッションに表示されないようになります。
|
重要: ネットワーク・トラフィックの正確なレポートのため、Webサイトで使用するCookieテクノロジを正確に指定することを強くお薦めします。また、ビジター・セッションの追跡に指定するCookieがブラインディングされないようにしてください。ブラインディングが行われると、Cookieに基づくセッション作成が失敗します。 |
オプションの名前付きサーバー機能を使用すると、監視対象Webサイトのビジターを詳細に分析できます。この機能を使用すると、一連のサーバーIPアドレス（ネットマスクを使用して指定）を1つのWebサーバー・グループおよび個別のWebサーバーに割り当てることができます。たとえば、サーバー・グループとして部門またはデータ・センターを使用し、そのグループに属する特定のWebサーバー名をサーバー名として指定できます。これにより、問題（ページの失敗など）が発生したときに、該当するWebサーバーの場所を簡単に特定できます。
この機能を使用する手順は、次のとおりです。
「Configuration」→「General」→「Named servers」の順に選択します。このオプションを使用できるのは、ITユーザーで「Analytical」レベルのアクセス権限を持つユーザーのみです。現時点で定義されている名前付きサーバーが表示されます。「«Add new server»」をクリックします。図7-5に示すダイアログが表示されます。
このダイアログ内のフィールドを使用して、ネットマスクで限定した一連のIPアドレスまたは単一のIPアドレス、および関連するWebサーバーとそのグループを指定します。次に、「Save」をクリックします。
名前付きサーバーのリストのアップロード
オプションの「«Upload list»」をクリックすると、名前付きサーバーのリストを現時点で定義されているリストとマージできます。リストのファイルでは1行が1エントリである必要があり、各サーバーに関する情報（図7-5のように表示される情報）はタブで区切っておく必要があります。新しくマージするファイルの中に、すでに定義されている名前付きサーバーが含まれている場合は、既存の定義が上書きされるため、注意してください。
名前付きサーバー・グループへの変更は、少しの間隔（通常5分〜10分）を置いて適用され、さらにその少し後にレポータ・システムに表示されます。
ビジターのIPアドレスに関連する情報の拡張が必要な場合もあります。イントラネットのトラフィックを監視しているときに、ユーザー独自のクライアント分類を使用する必要がある場合に、これは特に便利です。
この機能を使用する手順は、次のとおりです。
「Configuration」→「General」→「Named clients」の順に選択します。現時点で定義されている名前付きサーバーがリストされます。「«Add new client»」をクリックします。このオプションを使用できるのは、ITユーザーで「Analytical」レベルのアクセス権限を持つユーザーのみです。図7-6に示すダイアログが表示されます。
このダイアログ内のフィールドを使用して、ネットマスクで限定した一連のIPアドレスまたは単一のIPアドレス、クライアントおよび関連するグループ（たとえば会社の部門）を指定します。次に、「Save」をクリックします。
名前付きクライアントのリストのアップロード
オプションの「«Upload list»」をクリックすると、名前付きクライアントのリストを現時点で定義されているリストとマージできます。リストのファイルでは1行が1エントリである必要があり、各クライアントに関する情報（図7-6のように表示される情報）はタブで区切っておく必要があります。新しくマージするファイルの中に、すでに定義されている名前付きクライアントが含まれている場合は、既存の定義が上書きされるため、注意してください。
定義を変更した名前付きクライアント・グループは、少しの間隔（通常5分〜10分）を置いて適用され、さらにその少し後にレポータ・システムに表示されます。
最も信頼できるデータを入手するためには、監視対象トラフィック用に指定する設定の微調整が必要になる場合があります。微調整を行うには、これらの設定に関連したレポートを定期的に確認することをお薦めします。また、「Configuration」メニューから「Show statistics」を選択することにより、構成の詳細を表示できます。例を図7-7に示します。
次の情報がレポートされます。
「Hits」セクションには、定義済アプリケーションに関連するオブジェクト（「Defined page」）、定義済アプリケーションの構成要素ではないオブジェクト（「Undefined page」）、およびページの構成要素ではないオブジェクト（「Spurious」）が示されます。
「Pages」セクションには、検出された、定義済アプリケーションに関連するページ（「Defined」）および定義済アプリケーションに関連しないページ（「Undefined」）が示されます。未定義ページは記録されず、情報が表示されないため、注意してください。
「Page views」セクションには、Cookieによって追跡されたセッション内で表示されたページ（「With session」）と使用可能なCookie情報がないページ（「Without session」）が示されます。
さらに、レポート・データの精度を上げるために使用できる詳細設定がいくつかあります。詳細設定は次の各項で説明します。
ヒットの失敗は、失敗したURLグループの中に記録されます。ヒットの失敗は広範な理由で発生し得るため、どのようなヒットの失敗を記録するのかを設定しておく必要があります。たとえば、リモート・ロボット検索に関連したインシデントの記録が必要になることはほぼありません。次を実行します。
「Configuration」→「General」→「Advanced settings」→「Ignore failed URLs」の順に選択します。このオプションを使用できるのは管理者のみです。図7-8に示すダイアログが表示されます。
失敗したURLビューの中で無視する必要のあるファイル名を指定します。これらのファイルはエラーとみなさないことを意味します。たとえば、robots.txtまたはfavicon.icoを指定します。指定したオブジェクトはオブジェクトURLにはリストされないことに注意してください。次に、「Next」をクリックします。
新しい設定は10分後に適用されます。その少し後に、指定した変更がレポータ・インタフェースに表示されます。
最低レベルのページURLディメンションに、URL引数をすべて記録するか、一部を記録するか、または記録しないかを設定できます。次を実行します。
「Configuration」→「General」→「Advanced settings」→「Page URL argument filtering」の順に選択します。このオプションを使用できるのは管理者のみです。図7-9に示すダイアログが表示されます。
メニューを使用して適切なフィルタを選択します。デフォルトは「allow-all」です。つまり、引数がすべて記録されます。次に、「Next」をクリックします。
「allow-some」フィルタを選択した場合は、続くダイアログで、どの引数を記録するかを指定する必要があります。複数ある引数はアンパサンド（&）記号で区切ります。次に、「Next」をクリックします。
新しい設定は10分後に適用されます。その少し後に、指定した変更がレポータ・インタフェースに表示されます。
|
注意: ユーザーのページURLにセッション引数またはその他任意の引数が含まれる場合は、この機能を使用することをお薦めします。この機能を使用しない場合は、ページベース・ビュー（全ページまたは失敗したURLなど）の内容が非常に大きくなることがあります。 |
RUEIでは、セッション情報は「All sessions」グループ内でレポートされます。この機能では、ビジターのセッションに関する情報はセッション開始後約5分で表示されます。デフォルトでは、ビジターが活動しない時間が、定義されたセッション・アイドル時間（デフォルトは60分）を超えた場合に、ビジター・セッションが終了したとみなされます。
セッションのレポートを最適化するために、「Session idle time」の詳細設定を使用して、ビジターのセッションが終了したとみなされる非アクティブな期間（分）を指定します。デフォルトは60分です。
|
重要: この設定は、システムのパフォーマンスおよびレポートされるデータの精度に影響することがあるため、Oracleサポート・サービスのアドバイスを受けた場合のみ変更することを強くお薦めします。 |
セッション設定の指定
セッションをレポートするときに使用するアイドル時間を指定する手順は、次のとおりです。
「Configuration」→「General」→「Advanced settings」→「Session processing」→「Session idle time」の順に選択します。図7-10に示すダイアログが表示されます。
ビジターが非アクティブになってからセッションが終了したとみなされるまでの時間（分）を指定します。デフォルトは60分です。次に、「Save」をクリックします。
この設定は、変更すると、5分以内に有効になります。
Webサービスの出現は、IT産業における最も重要な進歩の1つです。各組織は、情報（たとえば注文書、在庫水準、出荷通知およびインターバンク取引など）を交換するためにエンタープライズ・アプリケーションの統合を進めています。
Webサービスの概要
ここでいう「Webサービス」とは新しい種類のサービスであり、それまで「Webサービス」と呼ばれてきたものとは区別する必要があります。一般に、WebサービスとはWeb上で使用可能な任意のサービスのことを指していました（たとえば検索エンジン、言語翻訳プログラム、天気ガイド、地図など）。ただし、このようなタイプのWebサービスには、人間によるなんらかの介入が必要でした。
WebサービスはW3C脚注1により、「ネットワーク上で相互作用できるマシンとマシンの対話をサポートするために設計されたソフトウェア・システム」と定義されています。Webサービスが実装するビジネス機能は明確に規定されており、他のサービスの状態に依存せずに稼働します。Webサービスには、その消費者との間で明確に規定された契約があります。サービス同士の接続は柔軟で、あるサービスが他のサービスと連動するためにその技術的な詳細を把握する必要はなく、すべての相互作用はインタフェースを介して行われます。サービス・プロバイダは、このテクノロジを使用して、Web上でサービスとともにインタフェースとサービスのネーミング仕様を単に公開して、接続を待機します。
サービスの公開は、サービスの説明を通じて行います。サービスの説明には、サービスのコール方法、およびサービスをリクエストしてレスポンスを得るために必要な情報を記述します。データ交換は、リクエスト/レスポンスのパターンを踏襲します。RUEIでは主としてXML-SOAPおよび同様のメッセージの監視がサポートされます。
Webサービスの定義
Webサービスを定義する手順は、次のとおりです。
「Configuration」→「Services」の順に選択します。現時点で定義されているWebサービスがリストされます。「New services」をクリックします。図7-11に示すダイアログが表示されます。
サービスの名前を指定します。定義されたサービスに対して、この名前がレポートおよびデータ・ブラウザ内で使用されます。この名前は、サービス、SSOプロファイル、スイートおよびアプリケーションを通じて一意である必要があります。サービスの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、サービスの有効範囲を指定します。有効範囲はサービスURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「Filter preview」 列に表示されます。
最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。サービス名を指定して他のすべてのフィールドを空白にすることはできません。ワイルドカード文字（*）は「Find Port」フィールドには指定できません。標準以外のポート（つまりポート80/443以外）に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、サービスは関連付けられないことに注意してください。「Find Port」フィールドには1つのポート番号しか指定できません。追加のポートを指定する必要がある場合は、新しいサービスが作成された後で追加のフィルタとして指定してください。
ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURL引数の組合せ情報を指定しないことはできません。
|
注意: サービス、SSOプロファイル、アプリケーションおよびスイート間でフィルタ定義を相互排他的にしておくことをお薦めします。たとえば、ドメインus.oracle.comでフィルタリングされるサービスを定義した状態で、us.oracle.com/application_servletでフィルタリングされる別のサービス、スイートまたはアプリケーションを定義しないでください。相互排他的ではないフィルタ定義を使用すると、予測できない結果が発生することがあります。フィルタの適用順序を制御する方法は、7.6項「RUEI内でのルール順序設定の制御」を参照してください。 |
URLの部分の中に、一致対象とする引数を指定することもできます。この機能を使用する場合は、引数と引数名の両方を揃えて指定することで初めてページURLと一致することができることに注意してください。つまり、部分一致はサポートされていません。次に、「Next」をクリックします。図7-12に示すダイアログが表示されます。
このダイアログを使用し、サービスを識別してレポートする方法を指定します。アプリケーション（6.2項「アプリケーションの定義」を参照）がアプリケーション » グループ » ページという構造で構成されているのに対して、サービスはサービス名 » 機能グループ » 機能名という構造で構成されていることを理解しておく必要があります。定義したグループに属していない機能は、デフォルト・グループgenericに属するとみなされることに注意してください。グループ・ネーミング・スキームを指定する場合、グループ・ネーミング・スキームがレポートされるためには、グループ・ネーミング・スキームが関数コール内にあることが必要です。
次に、「Finish」をクリックします。指定したサービス定義の概要が表示されます。例を図7-13に示します。
サービス定義の微調整
サービスを定義した後で、関連する機能スキームを変更できます。「Identification」セクションで、「«Add new filter»」をクリックして、サービスと関連付ける必要のある機能の追加フィルタを指定します。定義済フィルタのいずれかと一致する機能が、サービスに割り当てられます。また、既存のフィルタ定義を変更するには、それをクリックします。いずれの場合にも、図7-11に示したフィルタの中から選択できます。ユーザーによる追加または変更を反映するようにサービス概要が更新されます。
クライアントID識別スキームを定義する手順は、アプリケーションやスイートについての手順と同じです。6.2.10項「ユーザー識別の定義」に記載されています。
IPアドレス・ソースの指定
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはTCPパケットからフェッチされます。ただし、RUEIシステムをNATサービスの前に配置する場合には、特定のヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。「Advanced」セクション（図7-13）の「Client IP source」チェック・ボックスを使用して、目的のスキームを指定できます。この詳細は、付録O「NATトラフィックの監視」に記載されています。
関数コールのうち、そのURL定義によりサービスに属していることが確認されているものの、関連する分類済の名前が見つからないものは、廃棄されレポートされません（デフォルト）。ただし、そのような未分類のコールをレポートする場合は、「Functions」セクションの「Report unclassified calls」チェック・ボックスを使用します。
サービスに属していることが確認されていないヒットは未分類のコールとして識別されるため、定義が不正確または不十分な関数コールは未分類として識別されます。未分類のコールは、関連するデータ・ブラウザ・グループ内のカテゴリ「Other」にレポートされることに注意してください。
関数のレスポンス時間を評価するために、RUEIでは関数ごとに満足度レベルが割り当てられます。このレベルは、サービス内で選択した関数コールのエンドツーエンド時間（つまり、すべてのサーバー時間とネットワーク時間の合計）を指定するものです。この時間は、その関数を呼び出すために必要なエンドツーエンド時間（秒単位）を表します。つまり、サーバー時間とネットワーク時間の合計です。デフォルトは4秒で、小数点以下3桁までを指定できます（たとえば、2.567）。これは、6.2.8項「ページ・ロードの満足度の指定」で説明するページ・ロードしきい値と等価です。
関数に関連付けられた文字列を検出する手順は、アプリケーションの場合の手順と同じです。6.2.9項「アプリケーションの関数エラーのトラップ」に記載されています。
関数を使用してクライアントを追跡するには、サービス内で使用するクライアントの識別メカニズムを定義しておく必要があります。これは、URL、XPath式またはCookieによって検索するか、また、サーバー・レスポンスとクライアント・リクエストのいずれかを検索するかを指定できます。この手順はアプリケーションの場合と同じです。6.2.10項「ユーザー識別の定義」に記載されています。
デフォルトでは、RUEI内でアプリケーション、SSO、プロファイル、スイートおよびサービスの各フィルタで一致が行われる順序は、定義に指定されている詳細のレベルによって決まります。つまり、最も多くの情報が指定されている定義が最初に適用されます。ただし、フィルタの適用順序の変更が必要になる場合があります。
たとえば、ドメインshop.oracle.comのネットワーク・トラフィックを監視するとします。また、2つのアプリケーション（ドメインshop*用に1つおよびドメイン*oracle*用に1つ）を定義しておきます。文字列*oracle*は、文字列shop*より長いため、最初に適用されます。ただし、ドメインshop*のページIDを優先する必要があるとします。ルール順序設定機能を使用すると、デフォルトのルール一致順序を、必要なドメインのページを適用する順序で上書きできます。
|
注意: デフォルトのルール順序設定を使用すること、およびアプリケーション、SSOプロファイル、スイートおよびサービスが相互排他的になるように十分な情報を使用してそれぞれを定義することをお薦めします。 |
ルール順序設定機能を使用する手順は、次のとおりです。
「Configuration」タブをクリックし、「Configuration」メニュー・オプションを選択してから「Edit ruling orders」オプションを選択します。このオプションを使用できるのは、ITユーザーで「Full」アクセス権限を持つユーザーのみであることに注意してください。図7-14に示すようなダイアログが表示されます。
「Automatic rule ordering」チェック・ボックスを使用して、現在定義されているアプリケーション、SSO、プロファイル、スイートおよびサービスからルール順序設定を自動的に導出するかどうかを指定します。前述のように、デフォルトでは、最も多くの情報が指定されている定義が最初に適用されます。「Up」および「Down」コントロールを使用してルールの適用順序を指定すると、このチェック・ボックスの選択が自動的に解除されます。このチェック・ボックスを再び選択すると、フィルタ順序設定が自動的にデフォルトにリセットされます。
行った変更は即座に有効になります。次に、「Close」をクリックします。
|
重要: デフォルトのルール順序設定を変更してから、新規のアプリケーション、SSOプロファイル、スイートまたはサービスを定義すると、関連付けられているフィルタが現在のルール順序設定の最下部に即座に配置されます。このため、新規フィルタの作成後には必ずルール順序設定を確認してください。 |
「URL diagnostics」グループ（3.2.4項「「URL Diagnostics」グループ」を参照）、「suite diagnostics」グループ（3.2.5項「「Suite」グループ」を参照）、およびセッション診断機能（3.10項「診断機能の使用」を参照）は、選択した機能URLや特定のディメンションから外部診断ユーティリティへのクリックアウトをサポートしています。現時点でサポートされている外部ユーティリティを表7-1に示します。
表7-1 サポートされるクリックアウト・ツール
| ユーティリティ | 説明 |
|---|---|
|
AD4J 10g |
Oracle Application Diagnostics for Java（AD4J）は、Oracleミドルウェア用のOracle診断パックに含まれます。オーバーヘッドの少ない監視および診断の機能を提供し、Javaアプリケーションの可用性とパフォーマンスを向上します。 この機能を使用するには、組織においてAD4J 10g R4がインストールされていることが必要です。 |
|
CAMM 10g |
Oracle Composite Application Monitor and Modeler（CAMM）は、組織で実行している高度に分散されたJava EEおよびSOAアプリケーションを監視できるユーティリティです。 この機能を使用するには、組織においてCAMM 10g R4がインストールされていることが必要です。 |
|
EBS |
EBSデプロイメントについてのサーバーまたはユーザー・レポート機能をユーザーが使用できます。 |
|
EMGC 11 |
インストールされているOracle Enterprise Managerミドルウェアおよびアプリケーション管理パックによって異なりますが、次の機能が使用できます。
|
|
My Oracle Support |
レポートされる特定のエラーについて、関連情報をOracleカスタマ・サービスのWebサイト（My Oracle Support）で検索します。たとえば、ORA-12154またはSBL-UIF-00271などについて検索します。 この機能を使用するには、My Oracle Supportの登録が有効であることが必要です。詳細は、 |
|
Siebel |
Siebelデプロイメントについてのサーバー概要またはユーザー検索機能をユーザーが使用できます。 |
クリックアウト機能の可用性
指定した構成の設定によって異なりますが、次の状況でユーザーがクリックアウト機能を使用できます。
「URL diagnostics」グループでの機能URL。
「suite diagnostics」グループでの機能URL。
コンテンツ・エラーのディメンション。クリックアウトを使用できるのは標準エラー（ORA-06512など）のみであることに注意してください。ユーザー定義のコンテンツ・エラー（「在庫切れ」など）では使用できません。
Siebelグループでのアプリケーション名、ページURL、Siebelスイート名およびユーザーID。ユーザーIDはユーザー検索機能に送られ、他のすべての項目はサーバー概要機能に送られます。
EBSグループでのアプリケーション名、ページURL、EBSスイート名およびユーザーID。ユーザーIDはユーザー・レポート機能に送られ、他のすべての項目はサーバー・レポート機能に送られます。
これらの機能はセッション診断機能でも使用できます（3.10項「診断機能の使用」）。
クリックアウト機能の構成
RUEIからこれらのユーティリティへのアクセスを構成する手順は、次のとおりです。
「Configuration」タブ→「General」→「Advanced settings」→「Clickout settings」の順に選択します。このオプションを使用できるのは管理者のみです。「Add new item」または既存の外部ユーティリティ定義をクリックします。図7-15に示すようなダイアログが表示されます。
「Clickout tool」メニューを使用して、インタフェースを構成する外部ユーティリティを選択します。サポートされている外部ユーティリティは表7-1に示しています。このダイアログに表示される他のフィールドは、選択したユーティリティによって異なることに注意してください。
「Host」フィールドを使用して、選択した外部ユーティリティにアクセスする方法を指定します。プロトコル・スキーム（http://など）は含めないでください。たとえば、ruei-camm.oracle.comと指定します。
「Port」フィールドを使用して、目的のポート番号を指定します。指定できるポート番号は1つのみです。ワイルドカード文字（*）は指定できません。
「Extensions」入力フィールドを使用して、クリックアウトを行えるオブジェクト・ファイルの拡張子を指定します。「Add」ボタンを使用して、追加の拡張子を指定します。「Also allow no extension」チェック・ボックスを使用すると、ファイル拡張子が関連しないヒットについてクリックアウトを可能にするかどうかも指定できます。
「Advanced」タブをクリックし、「Protocol」フィールドを使用して、選択したユーティリティとの接続にHTTPとHTTPSのどちらを使用するかを指定します。デフォルトでは、HTTPが使用されます。
「Regular expression」フィールドと「Replace」フィールドを使用して、置き換えられる外部アプリケーションに渡すURLの一部を指定します。正規表現の詳細は、My Oracle Support Webサイト（https://support.oracle.com/CSP/ui/flash.html）にあるナレッジベースの記事を参照してください。
次に、「Save」をクリックします。これらの設定への変更は即座に適用されます。
アプリケーションおよびスイートの構成
目的のアプリケーションごとに、クリックアウトをサポートする機能URLを指定します。この詳細は、6.2.16項「「URL Diagnostics」グループ内でのレポートの制御」に記載されています。
Oracle E-Business Suite（EBS）スイートおよびSiebelスイートの場合、ディメンションでクリックアウト機能を使用するためには、エンタープライズ名をスイートの構成に含めて指定する必要があります。この機能は、6.5項「スイートの使用」に記載されています。
クリックアウト機能のアクセス
データ・ブラウザ項目のクリックアウト機能は、項目のコンテキスト・メニューから選択できます。使用できる正確なオプションは、データ・ブラウザ・グループ、選択したディメンション、および定義されたクリックアウト設定によって異なります。例を図7-16に示します。
脚注
脚注1: World Wide Web Consortium（W3C）は、World Wide Webの中心的な国際標準組織です。
