| Oracle® Real User Experience Insightユーザーズ・ガイド リリース11.1 for Linux x86-64 B63041-01 |
|
 前へ |
 次へ |
この章では、スイートを使用して特定のOracle Enterpriseアーキテクチャ(Oracle E-Business Suite、Siebel、WebLogic Portalなど)を拡張監視する方法について説明します。また、Webサービスの監視についても説明します。
前述のように、RUEIにおけるページ識別は、アプリケーションに基づいて行われます。ただし、アプリケーションが特定のOracle Enterpriseアーキテクチャ(Oracle E-Business Suite、Siebel、WebLogic Portalなど)に基づいている場合、スイートという第4のレベルが導入されます。スイートとは一般にアプリケーションの集合であり、スイートに関連付けられているWebページは、スイート » アプリケーション » グループ » ページという構造を持ちます。
重要:
現在サポートされているOracle Enterpriseアーキテクチャのいずれかを監視対象の環境で使用している場合は、この機能を使用することを強くお薦めします。この機能を使用すると、アプリケーション定義にかかる時間が短縮され、スイート内のアプリケーションの互換性が高くなるのみでなく、これらのアーキテクチャが正しく監視されるようにもなります。
スイートのインスタンスを定義する手順は、次のとおりです。
「Configuration」→「Applications」の順に選択して、図10-1に示すメニュー構造から「Suites」を選択します。
「New suite」をクリックします。図10-2に示すダイアログが表示されます。
スイートの名前を指定します。この名前は、スイート、サービス、SSOプロファイルおよびアプリケーションを通じて一意である必要があり、最大で6文字に制限されます。スイート・インスタンスの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、スイートの有効範囲を指定します。有効範囲はページURLの部分として定義されます。これらのフィルタ基準の使用方法は、8.2項「アプリケーションの定義」に記載されているものと同じです。この情報を入力すると同時に、入力した定義が「Filter preview」列に表示されます。空白フィルタは使用できません。ワイルドカード文字(*)は「Find port」フィールドには指定できません。標準以外のポート(つまりポート80/443)に着信するネットワーク・トラフィックには、スイート・インスタンスは関連付けられないことに注意してください。明示的に指定できるポート番号は1つのみです。さらに必要な場合は、追加フィルタとして構成する必要があります。ワイルドカード文字を指定して、ドメイン名とURL引数の組合せによるその他の情報を指定しないことはできません。次に、「Next」をクリックします。図10-3に示すダイアログが表示されます。
|
注意: スイート、SSOプロファイル、アプリケーションおよびサービス間でフィルタ定義を相互排他的にしておくことをお薦めします。相互排他的ではないフィルタ定義を使用すると、予測できない結果が発生することがあります。フィルタの適用順序を制御する方法は、12.8項「RUEI内でのルール順序設定の制御」を参照してください。 |
このダイアログでは、スイートのベースとなるOracle Enterpriseアーキテクチャを指定できます。次に、「Finish」をクリックします。指定したスイート定義が表示されます。例を図10-4に示します。
この概要には、定義したスイートのサマリーが示されます。これには、定義したページ識別フィルタ、スイートに今までに一致したページの数、検出および記録が必要な関数エラー(存在する場合)、およびビジター・セッションの追跡にスイート内で使用されるユーザー識別メカニズムが含まれます。これらはすべて、必要に応じて個別に変更できます。手順は、8.2項「アプリケーションの定義」に記載されているものと同じです。
特定のOracleアーキテクチャの本番環境に基づいたトラフィックの監視時に使用するために提供された適切なスクリプトを実行することを強くお薦めします。たとえば、create_EBS_info.plスクリプトなどです。この目的は、実際の環境でこれらのアーキテクチャが実装された方法を特定することです。特に重要なのは、ページ・ネーミング・スキームです。次の手順を実行します。
選択したスイートに付属の適切なスクリプトをダウンロードします。この機能の使用方法の詳細は、対応する付録を参照してください。
スクリプトをデプロイメント環境で実行します。このスクリプトにより、環境内でページIDにIDが割り当てられます。スクリプトを実行するディレクトリ内に、多数の.txtファイルが作成されます。
生成された.txtファイルから.zipファイルを作成し、RUEIレポータ・システムへのファイルのアップロードに使用可能な場所に、この.zipファイルをコピーします。
「Configuration」→「Applications」→「Suites」の順に選択して、該当するスイートを選択します。スイートの概要が表示されます。「Upload configuration」コマンド・ボタンをクリックします。図10-5に示すダイアログが表示されます。
スクリプトで生成されたファイルの名前を指定します。目的のファイルを検索するための「Browse」ボタンが使用可能です。ファイルは.zipファイルである必要があります。次に、「Upload」をクリックします。
|
重要: この構成ファイルは、目的の各スイート・インスタンス用にアップロードする必要があります。構成ファイルには、既知の(および空でない).txtファイルのみを含めることができます。これらのファイルはすべてルート・ディレクトリに存在する必要があります。つまり、サブディレクトリは許可されていません。実際の本番環境に基づいた適切な構成ファイルを目的のスイート・インスタンス用にアップロードする必要があります。監視対象のアプリケーションになんらかの変更を加える場合は、スクリプトを再実行して、生成された.zipファイルを再インポートする必要があります。誤った構成ファイルをインポートすると、不適切なレポートが作成されます。 |
前述のように、スイートとは一般にアプリケーションの集合です。スイートの定義後にそのプロパティを変更するには、8.2項「アプリケーションの定義」でアプリケーションに関して記載されているのと同じ方法を使用します。
次の点に特に注意してください。
スイートでクリックアウト機能を使用するためには、スイート・インスタンスのエンタープライズ名を正しく指定する必要があります(4.5項「外部ツールへのクリックアウトの構成」を参照)。これは、EMGCでのスイートの構成から取得できます。たとえば、ec2ebs2-Oracle E-Business Suiteまたはsiebel_emgc-amp11.us.oracle.comです。
スイート固有のデフォルトの関数エラーが多数定義されています。これを確認して、実際の環境の要件に合うようにしてください。手順は、8.2.9項「アプリケーション・コンテンツ・メッセージのトラップ」に記載されているものと同じです。
デフォルトでは、未分類のページはレポートされません。これを変更するには、「Report unclassified pages」チェック・ボックスを選択します。手順は、8.2.3項「未分類のページのレポート作成」に記載されているものと同じです。
「Report service test traffic」チェック・ボックスを使用して、選択したスイートのためにOracle Enterprise Manager Grid Controlで構成されているサービス・テスト・トラフィックをRUEIでレポートするかどうかを指定できます。デフォルトでは、レポートは行われません。この機能の使用方法の詳細は、3.2.6項「Oracle Enterprise Managerのサービス・テスト監視」に記載されています。監視対象のサービス・テストはRUEIユーザー・フローにも変換できることに注意してください。この機能は、9.8項「サービス・テスト・セッションのユーザー・フローへの変換」に記載されています。
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはIPパケットからフェッチされます。ただし、RUEIシステムをNATサービスの前に配置する場合には、特定のヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。この詳細は、付録O「NATトラフィックの監視」に記載されています。
スイートごとに、デフォルトのユーザー識別スキームが定義されています。これを確認して、実際の環境の要件に合うようにしてください。手順は、8.2.10項「ユーザー識別の定義」に記載されているものと同じです。
「suite diagnostics」グループ(3.2.4項「「URL Diagnostics」グループ」を参照)を使用すると、スイートのヒットについてレポートされた機能URLを表示できます。この機能の使用方法は、アプリケーションの場合と同じです(8.2.16項「「URL Diagnostics」グループ内でのレポートの制御」を参照)。
スイート全体のページを識別できるのみでなく、ページを手動で定義することもできます。手順は、8.2.15項「ページの手動識別」に記載されているものと同じです。ただし、新規ページを最初から定義することはできません。既存のページを新規ページのベースとして使用する必要があります。
Oracle Enterpriseアーキテクチャ・ベースのアプリケーションについてRUEIで収集およびレポートされるデータの品質を保証するために、レポートされる詳細を検証することを強くお薦めします。定義済スイートについて検出される関連ページの数に特に注意する必要があります。
「Browse data」→「All pages」グループ→「Applications」サブグループの順に選択します。ページ・ビューやヒットなど個々のディメンションにおいて、ページ・ビューがいくつかのアプリケーションについてレポートされているのを確認できます。ディメンションのスイート名は、カッコ内に表示されます。WLPストリーミング・ポータルの例を図10-6に示します。
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」をクリックします。図10-7に示すダイアログが表示されます。
サービスの名前を指定します。定義されたサービスに対して、この名前がレポートおよびデータ・ブラウザ内で使用されます。この名前は、サービス、SSOプロファイル、スイートおよびアプリケーションを通じて一意である必要があります。サービスの名前は後から変更できないため、注意してください。
残りのフィールドを使用して、サービスの有効範囲を指定します。有効範囲はサービスURLの部分として定義されます。この情報を入力すると同時に、入力した定義が「Filter preview」 列に表示されます。
最高レベルのフィルタはドメインです。ドメインを変更または微調整するには、URLの部分を指定します。サービス名を指定して他のすべてのフィールドを空白にすることはできません。ワイルドカード文字(*)は「Find Port」フィールドには指定できません。標準以外のポート(つまりポート80/443以外)に着信するネットワーク・トラフィックには、ポート番号が明示的に指定されない限り、サービスは関連付けられないことに注意してください。「Find Port」フィールドには1つのポート番号しか指定できません。追加のポートを指定する必要がある場合は、新しいサービスが作成された後で追加のフィルタとして指定してください。
ワイルドカード文字の使用がサポートされますが、指定する他の文字はすべてリテラルとして解釈されることに注意してください。ワイルドカード文字を指定して、それ以外にドメインとURL引数の組合せ情報を指定しないことはできません。
|
注意: サービス、SSOプロファイル、アプリケーションおよびスイート間でフィルタ定義を相互排他的にしておくことをお薦めします。たとえば、ドメインus.oracle.comでフィルタリングされるサービスを定義した状態で、us.oracle.com/application_servletでフィルタリングされる別のサービス、スイートまたはアプリケーションを定義しないでください。相互排他的ではないフィルタ定義を使用すると、予測できない結果が発生することがあります。フィルタの適用順序を制御する方法は、12.8項「RUEI内でのルール順序設定の制御」を参照してください。 |
URLの部分の中に、一致対象とする引数を指定することもできます。この機能を使用する場合は、引数と引数名の両方を揃えて指定することで初めてページURLと一致することができることに注意してください。つまり、部分一致はサポートされていません。次に、「Next」をクリックします。図10-8に示すダイアログが表示されます。
このダイアログを使用し、サービスを識別してレポートする方法を指定します。アプリケーション(8.2項「アプリケーションの定義」を参照)がアプリケーション » グループ » ページという構造で構成されているのに対して、サービスはサービス名 » 機能グループ » 機能名という構造で構成されていることを理解しておく必要があります。定義したグループに属していない機能は、デフォルト・グループgenericに属するとみなされることに注意してください。グループ・ネーミング・スキームを指定する場合、グループ・ネーミング・スキームがレポートされるためには、グループ・ネーミング・スキームが関数コール内にあることが必要です。
次に、「Finish」をクリックします。指定したサービス定義の概要が表示されます。例を図10-9に示します。
サービス定義の微調整
サービスを定義した後で、関連する機能スキームを変更できます。「Identification」セクションで、「Add new filter」をクリックして、サービスに関連付ける必要がある機能に追加のフィルタを指定できます。定義済フィルタのいずれかと一致する機能が、サービスに割り当てられます。また、既存のフィルタ定義を変更するには、それをクリックします。いずれの場合にも、図10-7に示したフィルタの中から選択できます。ユーザーによる追加または変更を反映するようにサービス概要が更新されます。
クライアントID識別スキームを定義する手順は、アプリケーションやスイートについての手順と同じです。8.2.10項「ユーザー識別の定義」に記載されています。
IPアドレス・ソースの指定
ユーザーのアクセスをレポートする際に、デフォルトによりクライアントのIPアドレスはTCPパケットからフェッチされます。ただし、RUEIシステムをNATデバイスの前に配置する場合には、特定のヘッダーからクライアントのIPアドレスを取得する方が便利な場合があります。「Advanced」セクション(図10-7)の「Client IP source」チェック・ボックスを使用して、目的のスキームを指定できます。この詳細は、付録O「NATトラフィックの監視」に記載されています。
関数コールのうち、そのURL定義によりサービスに属していることが確認されているものの、関連する分類済の名前が見つからないものは、廃棄されレポートされません(デフォルト)。ただし、そのような未分類のコールをレポートする場合は、「Functions」セクションの「Report unclassified calls」チェック・ボックスを使用します。
サービスに属していることが確認されていないヒットは未分類のコールとして識別されるため、定義が不正確または不十分な関数コールは未分類として識別されます。未分類のコールは、関連するデータ・ブラウザ・グループ内のカテゴリ「Other」にレポートされることに注意してください。
関数のレスポンス時間を評価するために、RUEIでは関数ごとに満足度レベルが割り当てられます。このレベルは、サービス内で選択した関数コールのエンドツーエンド時間(つまり、すべてのサーバー時間とネットワーク時間の合計)を指定するものです。この時間は、その関数を呼び出すために必要なエンドツーエンド時間(秒単位)を表します。つまり、サーバー時間とネットワーク時間の合計です。デフォルトは4秒で、小数点以下3桁までを指定できます(たとえば、2.567)。これは、8.2.8項「ページ・ロードの満足度の指定」で説明するページ・ロードしきい値と等価です。
関数に関連付けられた文字列を検出する手順は、アプリケーションの場合の手順と同じです。8.2.9項「アプリケーション・コンテンツ・メッセージのトラップ」に記載されています。
脚注
脚注1: World Wide Web Consortium(W3C)は、World Wide Webの中心的な国際標準組織です。
