| Oracle® Fusion Middleware Oracle WebCenter Contentのマネージメント 12c (12.2.1) E70072-01 |
|
 前 |
 次 |
この章の構成は、次のとおりです。
Content Trackerは、Oracle WebCenter Content Serverとともに自動的にインストールされるオプション・コンポーネントです。Content Trackerコンポーネントが有効になっているときには、最もアクセス頻度の高いコンテンツ・アイテムや、ユーザーまたは特定グループにとって最も価値の高いコンテンツなど、システム使用に関する情報が提供されます。組織のコンテンツの消費パターンを理解することによって、ユーザーを中心に据えた適切な情報をより効率的に提供できます。
Content Trackerのカスタマイズの詳細は、Oracle Fusion Middleware Oracle WebCenter Contentによる開発を参照してください。
Content Trackerでは、コンテンツ・サーバーのインスタンスのアクティビティが監視され、それらのアクティビティについて選択した詳細が記録されます。さらに、システムがどのように使用されているかを示すレポートが生成されます。この項では、Content TrackerおよびContent Trackerレポートの機能について概要を説明します。
Content Trackerには、構成変数によって制御されるいくつかの最適化機能が組み込まれています。変数のデフォルト値によって、大規模な本番環境で可能なかぎり効率的に機能するようにContent Trackerを設定できます。Content Trackerの構成変数の詳細は、Oracle Fusion Middleware Oracle WebCenter Content構成リファレンスを参照してください。
この項の内容は次のとおりです。
Content Trackerでは、システムが監視され、様々なアクティビティに関するソースから収集された情報が記録されます。情報はマージされ、コンテンツ・サーバー・データベース内の一連の表に書き込まれます。Content Trackerでは、次に基づいてアクティビティが監視されます。
コンテンツ・アイテム使用状況: Webフィルタ・ログ・ファイル、コンテンツ・サーバー・データベースおよびその他の外部アプリケーション(ポータルやWebサイトなど)からデータを取得します。コンテンツ・アイテム・アクセスのデータには、日付、時刻、コンテンツIDおよび現在のメタデータが含まれます。
サービス: コンテンツを返すサービスおよび検索リクエストを処理するサービスを追跡します。Content Trackerでは、デフォルトで、コンテンツ・アクセスのイベント・タイプを持つサービスのみがログに記録されますが、構成変更により、カスタム・サービスも含めてすべてのサービスを監視できます。
ユーザー・アクセス: ユーザー・プロファイルのサマリーの収集や統合など、コンテンツ・アクセス・イベント以外の他の情報を収集します。このデータには、ユーザー名およびユーザー・プロファイル情報が含まれます。
Content Trackerでは、次のソースからデータが記録されます。
Webサーバー・フィルタ・プラグイン: コンテンツが静的URLを介してリクエストされると、Webサーバー・フィルタ・プラグインによってリクエストの詳細が記録され、イベント・ログ・ファイルに情報が保存されます。イベント・ログ・ファイルは、Content Trackerデータ削減プロセスで入力として使用されます。
サービス・ハンドラ・フィルタ: Content Trackerでは、コンテンツを返すサービスが監視されます。これらのサービスの1つが呼び出されると、そのサービスの詳細がコピーされ、SctAccessLog表に保存されます。
ロギング・サービス: Content Trackerでは、イベントをログに記録するための単一サービス・コールがサポートされています。これは、URLを介して直接呼び出すか、サービス・スクリプト内のアクションとして呼び出すか、またはIdoc Scriptから呼び出すことができます。
データベース表: ユーザー・プロファイル情報を収集して処理するように構成すると、データ削減プロセスで、選択されたデータベース表を問い合せ、レポート作成期間中にアクティブであったユーザーの情報が取得されます。
アプリケーションAPI: 他のコンポーネントやアプリケーションを追跡対象として登録できるインタフェースが用意されています。このインタフェースを使用すると、Site Studioなどの連携するアプリケーションで、イベント情報をリアルタイムでログに記録できます。アプリケーションAPIは、サービスを使用しないコード間のコールとして設計されています。APIは、汎用的には使用できません。このインタフェースを使用してアプリケーションを構築する場合は、コンサルティング・サービスにお問い合せください。
データ削減プロセスでは、データ記録ソースから取得されたデータが収集されてマージされます。この削減プロセスが完了するまで、Content Tracker表のデータは完成しません。毎日の収集データに対して削減を1回実行します。削減は手動で実行するか、または自動的に実行するようにスケジュールでき、通常はシステム負荷が少ないピーク外の時間帯にスケジュールします。
Content Trackerで使用される用語は、次のとおりです。
データ収集: コンテンツ・アクセス情報を収集し、情報をイベント・ログ・ファイルに書き込むこと。
データ削減: データ収集からの情報を処理してデータベース表にマージすること。
データ・エンジン・コントロール・センター: データ・エンジンのユーザー制御機能へのアクセスを提供するインタフェース。このリージョンには次のタブがあります。
コレクション: データ収集を有効化するために使用します。
削減: データ削減(データをデータベース表内にマージすること)を停止および開始するために使用します。
スケジュール: 自動データ削減を有効化するために使用します。
スナップショット: アクティビティ・メトリックを有効化するために使用します。また、スナップショットという用語は、特定の時点の状態を表す情報セットも示します。
サービス: ログに記録するサービス・コールを追加、構成および編集するために使用します。また、これは、指定されたサービスについてログに記録する具体的なイベント詳細を定義する場合にも使用します。
サービス定義: サービス・コール構成ファイル(SctServiceFilter.hda)内のResultSet構造で、ログに記録する各サービス・コールを定義するエントリが含まれます。サービス定義ResultSetは、ServiceExtraInfoという名前です。
サービス・エントリ: ログに記録されるサービス・コールを定義する、サービス定義ResultSet (ServiceExtraInfo)内のエントリ。ServiceExtraInfo ResultSetには、ログに記録されるサービスごとに1つのサービス・エントリが含まれます。
フィールド・マップ: サービス・コール・データおよび特定のデータ記録場所を定義する、サービス・コール構成ファイル(SctServiceFilter.hda)内の2次的なResultSet。
上位アクセス・コンテンツ・アイテム: システム内の最も頻繁にアクセスされているコンテンツ・アイテム。
コンテンツ・ダッシュボード: 特定のコンテンツ・アイテムのアクセスに関する概要情報が表示されるページ。
Content Trackerは、ほとんどのハードウェアおよびネットワーク構成でサポートされていますが、ハードウェアとソフトウェアの組合せによっては特別な考慮が必要になります。
グリニッジ標準時(GMT)を使用するには、SctUseGMT構成変数をtrueに設定します。デフォルトでは、ローカル時間を使用するように、falseに設定されています。構成変数の詳細は、Oracle Fusion Middleware Oracle WebCenter Content構成リファレンスを参照してください。
以前のバージョンのContent Trackerをアップグレードする場合、アクセス時間が1回前に戻ります(地域によっては先に進みます)。年2回のサマー・タイム実施に対応するために、記録されるユーザー・アクセス時間に中断が生じます(ローカル時間の使用および地域によって異なります)。
Content Trackerでは、構成に応じて、動的および静的なコンテンツ・アクセスやサービス・コールなどのイベント情報のデータ収集を実行できます。どちらのタイプのデータも、結合された出力表(SctAccessLog)に記録されます。サービス・コールはリアルタイムでログに挿入されますが、静的URL情報は最初に(手動またはスケジュール実行で)データ削減プロセスを実行する必要があります。
アクティビティ・データが収集されると、Content Trackerではイベント情報が結合、分析および統合され、要約されたアクティビティがデータベース表にロードされます。
データ収集は、追跡機能の最初のステップです。Content Trackerのデータ収集には、静的URL参照およびサービス・コール・イベントからの情報の収集が含まれます。データの収集には、複数の方法が使用されます。
Content Trackerは、サービス・ハンドラ・フィルタを使用して、Webサーバー経由の動的コンテンツ・リクエストに関する情報や、その他のタイプのアクティビティ(アプリケーションからのコールなど)に関する情報を取得します。サービス・リクエスト詳細は、サービス・コールに付随するDataBinderから取得され、情報は結合された出力表(SctAccessLog)にリアルタイムで格納されます。
SctServiceFilter.hda構成ファイルは、ログに記録するサービス・コールを指定するために使用されます。ここでは、ログに記録されるサービスごとにサービス定義エントリが1つずつ含まれるResultSet構造が使用されます。拡張されたサービス・ロギング機能を使用している場合、このファイルには、サービス定義エントリに対応するフィールド・マップも含まれます。
SctServiceFilter.hdaファイルには、ServiceExtraInfo ResultSetが含まれています。このResultSetには、ログに記録されるサービスを定義する1つ以上のサービス・エントリが含まれます。拡張されたサービス・ロギング機能をサポートするために、追加のフィールド・マップResultSetが使用されます。追加のデータ値を追跡するサービスごとに、SctServiceFilter.hdaファイル内には、関連するサービスのデータ・フィールド、場所およびデータベース宛先列を定義するフィールド・マップResultSetが存在する必要があります。
静的URLを介して取得された管理対象コンテンツでは、通常、サービスを起動しません。Content TrackerのWebサーバー・フィルタプラグインによって、アクセス・イベント詳細(静的URL参照)が収集され、RAW Content Trackerイベント・ログ(sctlogファイル)に記録されます。これらのファイル内の情報は、結合された出力表にサービス・コール・データとともに挿入される前に、明示的な削減を(対話式またはスケジュール実行で)実行する必要があります。
ロギング・サービスは、URLを介して直接、またはサービス・スクリプト内のアクションとして呼び出すことができる単一サービス・コールです。また、executeService関数を使用して、Idocスクリプトから呼び出すこともできます。呼出し元アプリケーションによって、記録する必要のあるサービスDataBinder内のフィールドが設定され、これには、Content Trackerサービス・フィルタ構成ファイル(SctServiceFilter.hda)にリストされている記述フィールドが含まれます。
サービス・ハンドラ・フィルタを介してログに記録されるサービスと、Content Trackerロギング・サービスを介してログに記録されるサービスとの間に、重複や競合はないはずです。サービスの名前がContent Trackerサービス・ハンドラ・フィルタ・ファイルに指定されている場合、それらのサービスは自動的にログに記録されるため、Content Trackerロギング・サービスによる記録は不要です。ただし、Content Trackerでは、このような重複を回避する処理は行われません。
データ削減中に、Webサーバー・フィルタ・プラグインによって取得された静的URL情報がサービス・コール・データとともにマージされ、出力表に書き込まれます。また、削減時には、Content Trackerの構成に応じて、Content Trackerユーザー・メタデータ・データベース表が、静的URLアクセスおよびサービス・コール・イベント・レコードから収集された情報で更新されます。
データ削減プロセス中に、静的URL情報がRAWデータ・ファイルから抽出され、SctAccessLog表に格納されているサービス情報と結合されます。Content Trackerでは、デフォルトで、SctAccessLog表のデータのみが収集および記録されます。ユーザー・データ出力表が存在しても、Content Trackerではその出力表に移入されません。
Content Trackerの構成に応じて、この削減プロセスでは次の処理が実行されます。
静的URLコンテンツ・アクセスのアクセス情報がサービス詳細と結合されます。
レポート作成期間中にアクティブであったユーザー・アカウントに関する情報が要約されます。この情報は、Content Trackerのユーザー・メタデータ・データベース表に書き込まれます。
Content Trackerには、検索関連データを選択的に生成してカスタム・メタデータ・フィールドに格納するためのオプションが用意されています。スナップショット機能を使用すると、アクティブにするアクティビティ・メトリックを選択できます。ログに記録されたデータには、コンテンツ・アイテムの人気度を示すコンテンツ・アイテム使用状況情報が含まれます。
Content Trackerでは、デフォルトで、SctAccessLog表のデータのみが収集および記録されます。スナップショット機能がアクティブでないかぎり、ユーザー・データ出力表が存在しても、Content Trackerではその出力表に移入されません。ただし、スナップショット機能を使用すると、Content Trackerのパフォーマンスに影響します。
スナップショット機能およびアクティビティ・メトリックをアクティブにした場合は、削減処理フェーズに続いて、カスタム・メタデータ・フィールドの値が更新されます。ユーザーがコンテンツ・アイテムにアクセスすると、適用可能な検索関連メタデータ・フィールドの値が変わります。Content Trackerでは、削減後の手順の中で、SQL問合せを使用して、レポート作成期間中にアクセスされたコンテンツ・アイテムが特定されます。Content Trackerでは、データベース表メタデータ・フィールドが新しい値で更新され、再索引付けサイクルが開始されます。ただし、再索引付けされるのは、アクセス・カウント・メタデータ値が変更されたコンテンツ・アイテムのみです。
削減後の手順は、影響を受けるコンテンツ・アイテムごとにアクティビティ・メトリックを処理して表を作成し、割り当てられたカスタム・メタデータ・フィールドにデータをロードするために必要です。また、アクティビティ・メトリック値が変更されたコンテンツ・アイテムに対して再索引付けサイクルを開始することによって、確実にデータが検索索引に含まれるため、検索結果を選択したり並べ替えるためにアクセスできるようになります。
図9-1 アクティビティ・メトリックを使用するデータ削減プロセス
削減された表データは、関連付けられたRAWデータが「最新」ステータスから「アーカイブ」ステータスに移行すると、プライマリ表から対応するアーカイブ表に移動します。プライマリ表には「新規」サイクルおよび「最新」サイクルにおける削減データの出力が含まれ、アーカイブ表には「アーカイブ」サイクルにおける削減データの出力が含まれます。
データが削減されて1日経過すると、RAWデータは「新規」から「最新」に移行します。このように、「新規」サイクルは、データが現在の日付のものであり、以前の日付から削減されていないことを示しています。「最新」サイクルは、データが前日以前のものであり、すでに削減されていることを示します。
「最新」セットの数が構成済のしきい値に到達した場合、手動またはスケジューラによって削減プロセスが実行されると、RAWデータは「アーカイブ」に移行します(また、SctAccessLog表の対応する行がSctAccessLogArchive表に移動します)。「最新」セット数のしきい値の構成の詳細は、Oracle Fusion Middleware Oracle WebCenter Content構成リファレンスにあるSctMaxRecentCount構成変数の情報を参照してください。削減プロセスが実行されていない場合、RAWデータはいつまでも「最新」サイクルのままです。
コンテンツ・アイテムにアクセスするために使用されたアクセス・モードによって、それらのアクセスがSctAccessLog表に記録される方法が決まります。サービスを介してコンテンツ・アイテムがアクセスされる(実際のネイティブ・ファイルを表示する)と、イベントがリアルタイムでSctAccessLog表に記録されます。この場合、アクティビティは即時に記録され、削減プロセスには依存しません。
静的URLを介してコンテンツ・アイテムがアクセスされる(Webロケーション・ファイルを表示する)と、Webサーバー・フィルタ・プラグインによって静的ログ・ファイルにイベントが記録されます。データ削減プロセス中に、指定された日付の静的ログ・ファイルが収集され、データがSctAccessLog表に移動します。この場合、特定の日付についてデータ削減が実行されないと、静的URLはSctAccessLogに記録されず、これらのアクセスが行われた証拠は残りません。
間隔カウントについては、静的アクセスとサービス・アクセスの処理方法の違いを考慮する必要があります。たとえば、ユーザーが土曜日にコンテンツ・アイテムに2回アクセスした場合、1回はWebロケーション・ファイルを介して(静的アクセス)、もう1回はネイティブ・ファイルを介して(サービス・アクセス)アクセスしたとします。サービス・アクセスはSctAccessLog表に記録されますが、Webロケーション・アクセスはSctAccessLog表に記録されません。日曜日のデータが削減された場合、(静的アクセスでなく)サービス・アクセスのみが短期および長期のアクセス・カウント間隔のサマリーに含められます。ただし、土曜日のデータも削減された場合は、サービス・アクセスと静的アクセスの両方がSctAccessLog表に記録され、両方の間隔に含められます。
レポートに最新の情報が含まれるように、データ・セットは、通常、発生時間(カレンダ)順に削減されます。RAWデータ・ログ・ファイルが削減される順序によって、記録およびカウントされるユーザー・アクセス・データの種類が決まります。削減中に、SctAccessLog表およびユーザー・メタデータ・データベース表が、RAWデータ・ファイルからのデータで変更されます。
スナップショット機能を使用して検索関連情報を収集する場合は、アクティブ化されたアクティビティ・メトリックに関連付けられているメタデータ・フィールドもデータ削減中に更新されます。アクティビティ・メトリックでは、DocMetaデータベース表に含まれているカスタム・メタデータ・フィールドが使用されます。
Content Trackerでは、削減データ・セット内の適用可能データに従ってアクティビティ・メトリック値が変更されます。データ値を完全かつ最新に保つために、毎日データ削減を実行します。データ・セットを順序どおりに削減しない場合は、現行または最新のデータ・セットを再削減すると、カウントが訂正されます。ただし、データは常に日付順に削減することをお薦めします。
次のシナリオに、削減順序によって格納されるデータがどのような影響を受けるかを示します。
シナリオ1:
特定の日(たとえば、土曜日と日曜日)のアクティビティが削減されていない場合、コンテンツ・アイテムへのアクセス方法によっては、これらの日に発生したアクセスが記録またはカウントされないことがあります。詳細は、「アクセス・モードおよびデータ削減」を参照してください。同様に、火曜日にコンテンツ・アイテムがアクセスされ、月曜日と水曜日に削減が実行された場合、そのコンテンツ・アイテムへの最後のアクセスに対して火曜日のアクセスがカウントされないことがあります。
シナリオ2:
過去数日間でアクセス数が大幅に増加し、2週間前からのデータを削減した場合、コンテンツ・アイテムの長期および短期のアクセス・メトリックは最新のアクティビティを反映しません。この場合、2週間前からの間隔値で本日の値がオーバーライドされます。現在または最新のデータ・セットを削減すると、カウントが訂正されます。
削減順序によって最終アクセス日付が誤って変更されることはありません。削減データ・セット内の最新のアクセスがコンテンツ・サーバーのDocMetaデータベース表の最終アクセス値よりも新しい場合にのみ、削減プロセスによって最終アクセス日付が変更されます。
最新のデータ・セットを削減し、特定のコンテンツ・アイテムがアクセスされた場合は、最終アクセス・フィールドが削減データ・セット内の最新のアクセス日付に更新されます。その後、それ以前のデータ・セットを再削減した場合、現行値は、このコンテンツ・アイテムに対する以前のアクセス日付で上書きされません。
シナリオ3:
任意の順序でデータ・セットを削減した場合は、「最新」データ・ファイルから「アーカイブ」データ・ファイルへの移行が妨げられます。関連付けられた表レコードは存続時間に基づいて移動し、アーカイブ表は最も古いデータを格納することを目的にしています。データ・セットがランダムな順序で削減された場合、どのデータが最も古いかは不明になります。
「最新」データ・ファイルおよび「アーカイブ」データ・ファイルの詳細は、「ユーザー・メタデータ表」および「データ削減サイクル」を参照してください。
スケジュールに基づいた削減の実行を構成し、定期的にRAWデータを削減できます。RAWデータは、「最新」リポジトリおよび「アーカイブ」リポジトリに安定して移動し、同様に、削減済データはプライマリ表からアーカイブ表に安定して移動します。
Content Trackerデータ・エンジンが、スケジュールされた削減実行の前日に無効化された場合、データは収集されないことに注意してください。スケジュールされた削減実行の日に有効化された場合、使用可能なデータが存在しないため、スケジューラは実行されません。
特定の日にスケジュールされたデータ削減は、その前日中に収集されたデータに対して実行されます。前日の定義は、午前0時(システム時間)に開始および終了する24時間です。CPUリソースを節約するには、システム負荷が一般に最も低い早朝時間帯に削減実行をスケジュールします。
削減が午前0時から数分後以内に実行されるようにスケジュールされている場合、エラーが発生することがあります。エラーが発生した場合は、削減がそれよりも後に実行されるように再スケジュールしてください。
Content Trackerでは、様々なイベント・ログ・タイプ、および複数のWebサーバーを含む構成に対応するために、複数の入力ファイルがサポートされています。各Webサーバー・フィルタ・プラグイン・インスタンスでは、イベント・ログ用のファイル名接尾辞として固有のタグが使用されます。固有の接尾辞には、Webサーバー・ホスト名とサーバー・ポート番号が含まれています。
削減プロセスでは、sctLog-yyyymmdd-<myhostmyport.txtという名前の複数のRAWイベント・ログが検索されてマージされます。RAWイベント・ログは、個別に処理されます。
ユーザーがContent Serverにログインしていても、コンテンツ・サーバーでコンテンツ・アクセス・イベントのユーザー名が取得されていない場合があります。この場合、アイテムは静的URLリクエストを介してアクセスされており、通常、Webサーバーによってユーザーの資格証明の送信を要求されないかぎり、ブラウザにユーザー名は表示されません。アイテムがパブリック・コンテンツの場合、Webサーバーはユーザーの資格証明の送信をブラウザに要求しないため、URLにアクセスするユーザーは不明となります。
すべてのドキュメント・アクセスのユーザー名を記録するには、ゲスト・ロールがコンテンツにアクセスできないようにする必要があります。コンテンツがパブリックでない場合、アイテムにアクセスするにはユーザーの資格証明が必要になり、ユーザー名がRAWイベント・ログ・エントリに記録されます。
Content Trackerの構成に応じて、「新規」サイクルのRAWデータ・ログ・ファイルが削減されると、データ・エンジンは、データ・ファイルを次のサブディレクトリに移動します。
recent/ディレクトリに格納可能なデータ・セットのデフォルト数は、入力データ・ログ・ファイルのうち60セット(日付)です。このデータ・セット数を超えると、最も古いデータ・セットは/archiveディレクトリに移動します。
cs_root/data/contenttracker/data/recent/yyyymmdd/
デフォルトでは、Content Trackerでデータはアーカイブされません。かわりに、期限切れの行が破棄されて最適なパフォーマンスが確保されます。適切に構成されている場合、Content Trackerは、archive/ディレクトリを使用して、「最新」サイクルから移動したすべての入力データ・ログ・ファイルを保持します。
cs_root/data/contenttracker/data/archive/yyyymmdd/
RAWデータ・ファイルが削減されると、別のファイル(reduction_ts-yyyymmdd.txt)がタイムスタンプ・ファイルとして生成されます。
SctAccessLog表には、静的および動的なすべてのコンテンツ・アクセス・イベント・レコードのエントリが含まれます。SctAccessLog表は、レポート作成期間中のイベントごとに1行ずつ使用して編成されます。表の列には、タイプに従ってタグが付けられます。
Sは、サービス・コールについて記録されたレコードを表します。
Wは、静的URLリクエストについて記録されたレコードを表します。
デフォルトでは、Content TrackerによってGIF、JPG、JS、CSS、CABおよびCLASSファイル・タイプへのアクセスはログに記録されません。したがって、これらのファイル・タイプのエントリは、データ削減後、結合された出力表に挿入されません。
Content TrackerのWebサーバー・フィルタ・プラグインでは、ユーザー・コンテンツのURLと、ユーザー・インタフェースによって使用されるURLを区別できません。client.cabなどのUIオブジェクトへの参照が静的アクセス・ログ内に含まれることがあります。このような誤検出を防ぐために、SctIgnoreDirectories構成変数を使用して、Content Trackerフィルタで無視されるディレクトリ・ルートのリストを定義します。これらのファイル・タイプをログに記録するには、SctIgnoreFileTypes構成変数のデフォルト設定をそのタイプ(gif、jpg、js、css)に変更します。構成変数の使用方法の詳細は、Oracle Fusion Middleware Oracle WebCenter Content構成リファレンスを参照してください。
次の表では、SctAccessLog表の各レコードについて収集される情報について説明します。Content Trackerでは、デフォルトで、大規模なアイテムやほとんど使用しないアイテムのデータは収集されず、それらの列は移入されません。
| 列名 | タイプ/サイズ | 列の定義 |
|---|---|---|
SctDateStamp |
datetime |
データが収集されたローカル日付(YYYYMMDD)で、顧客のロケーションおよびイベントが発生した時間によって変わります。eventDateに記録された日付と異なる場合があります。時刻は00:00:00に設定されます データ・ソース: 内部 |
SctSequence |
int /8 |
エントリ・タイプに固有のシーケンス データ・ソース: 内部 |
SctEntryType |
char /1 |
エントリ・タイプ。値はWまたはS データ・ソース: 内部 |
eventDate |
datetime |
リクエストが完了したGMT日時。日付は、顧客のロケーションおよびイベントが発生した時間によって変わります。SctDateStampに記録された日付と異なる場合があります。 |
SctParentSequence |
integer |
ツリー内の最外部のサービス・イベントのシーケンス(ある場合) |
c_ip |
varchar /15 |
クライアントのIP |
cs_username |
varchar /255 |
|
cs_method |
varchar /10 |
GET |
cs_uriStem |
varchar /255 |
URIのステム |
cs_uriQuery |
varchar /[maxUrlLen] |
問合せの一部。 |
cs_host |
varchar /255 |
コンテンツ・サーバーのサービス名 |
cs_userAgent |
varchar /255 |
クライアント・ユーザー・エージェントのID デフォルトでは、この列には |
cs_cookie |
varchar /[maxUrlLen] |
現在のCookie |
cs_referer |
varchar /[maxUrlLen] |
このリクエストに至るURL |
sc_scs_dID |
int /8 |
dID データ・ソース: 問合せから、またはURLから導出(逆引き参照) |
sc_scs_dUser |
varchar /50 |
dUser データ・ソース: サービスDataBinder |
sc_scs_idcService |
varchar /255 |
IdcServiceの名前。 データソース: 問合せまたはサービスDataBinder |
sc_scs_dDocName |
varchar /30 |
dDocName データ・ソース: 問合せまたはサービスDataBinder |
sc_scs_callingProduct |
varchar /255 |
任意の識別子 データソース: SctServiceFilter構成ファイルまたはサービスDataBinder |
sc_scs_eventType |
varchar /255 |
任意の識別子 データソース: SctServiceFilter構成ファイルまたはサービスDataBinder |
sc_scs_status |
varchar /10 |
サービス実行ステータス データ・ソース: サービスDataBinder |
sc_scs_reference |
varchar /255 |
値はアクセスされるファイルのレンディションを表します( データソース: アルゴリズムを使用した問合せパラメータまたはServiceFilter構成ファイル |
comp_username |
varchar /50 |
計算されたユーザー名。サービスの場合、UserDataサービス・オブジェクトから取得するか、あるいはHTTP_INTERNETUSER、REMOTE_USERまたはdUserです。静的URLの場合は、認可ユーザーまたはインターネット・ユーザーから取得されます。 |
comp_validRef |
char /1 |
参照されるオブジェクトが存在するかどうか、およびリクエスト・ユーザーに対して使用可能かどうかを示します。 アクセスがWeb参照(W)であった場合、ispromptloginとisaccessdeniedの両方がNULLで、削減時に静的URLが存在していれば 削減時に静的URLが存在していなかった場合、ユーザー・ログオンが失敗した場合、またはログオンは成功したがユーザーにオブジェクトの表示権限がなかった場合は |
sc_scs_isPrompt |
char /1 |
trueの場合は データソース: プラグインimmediateResponseEventフィールド |
sc_scs_isAccessDenied |
char /1 |
trueの場合は データソース: プラグインimmediateResponseEventフィールド |
sc_scs_inetUser |
varchar /50 |
インターネット・ユーザー名(セキュリティ問題の場合) データソース: プラグインimmediateResponseEventフィールド |
sc_scs_authUser |
varchar /50 |
認可ユーザー名(セキュリティ問題の場合) データソース: プラグインimmediateResponseEventフィールド |
sc_scs_inetPassword |
varchar /8 |
インターネット・パスワード(セキュリティ問題の場合) データソース: プラグインimmediateResponseEventフィールド |
sc_scs_serviceMsg |
varchar /255 |
コンテンツ・サーバー・サービス完了ステータス データ・ソース: サービスDataBinder |
extField_1からextField_10 |
varchar /255 |
拡張されたサービス・トラッキング機能で使用する汎用目的の列。フィールド・マップResultSet内では、DataBinderフィールドがこれらの列にマップされます。 |
Content Trackerが適切に構成されている場合は、静的および動的なコンテンツ・アクセス・リクエスト情報およびすべてのメタデータ・フィールドがアクセス可能になります。ログに記録されるメタデータには、コンテンツ・アイテムおよびユーザー・メタデータが含まれます。
Content Trackerユーザー・メタデータ・データベース表は、レポート作成期間中にアクティブであったユーザーに関して収集された情報で更新されます。これらの表には、データ削減実行時のユーザー・プロファイルに関するデータが保持されます。ユーザー・メタデータ表の名前は、ルート(含まれている情報のクラスを示す)、およびその表とネイティブのコンテンツ・サーバー表を区別するための接頭辞Sctで構成されます。
デフォルトでは、Content Trackerでデータはアーカイブされないため、期限切れの行はプライマリ表からアーカイブ表に移動されません。かわりに、期限切れの行が破棄されて最適なパフォーマンスが確保されます。ユーザー・メタデータ・データベース表の2つの完全セットが作成されます。
プライマリ: SctUserInfoなどには、「新規」および「最新」サイクルにおける削減データの出力が含まれます。
アーカイブ: SctUserInfoArchiveなどには、「アーカイブ」サイクルにおける削減データの出力が含まれます。
Content Trackerがアーカイブを実行するように構成されている場合は、削減データ・ファイルが「最新」から「アーカイブ」ステータスに移行し、関連付けられた表レコードがプライマリ表からアーカイブ表に移動します。これにより、プライマリ表に余分な行が構築されることがなく、最新データに対して実行された問合せは短時間で完了します。アーカイブ表の行は削除されません。これらは、SQL問合せツールを使用して移動または削除できます。アーカイブ表のすべての行を削除するには、表自体を削除します。これらは、コンテンツ・サーバーが次に再起動されるときに再作成されます。レポートは、アーカイブ・データに対しては実行されません。
作成される表は、次のとおりです。
SctAccounts表には、すべてのアカウントのリストが含まれます。アカウントごとに1行ずつ使用して編成されます。
SctGroups表には、削減時のすべての現行ユーザー・グループのリストが含まれます。コンテンツ・アイテム・グループごとに1行ずつ使用して編成されます。
SctUserAccounts表には、SctUserInfo表にリストされていて、かつ現行インスタンス内で定義されているアカウントを割り当てられた全ユーザーのエントリが含まれます。ユーザーとアカウントの組合せごとに、個別のエントリが存在します。
Content Trackerでは、複数のプロキシ・インスタンスのユーザーのグループおよびアカウント情報を判別できないことがあります。現行インスタンスがプロキシの場合、別のプロキシで定義されているアクティブ・ユーザーのグループ情報が、そのユーザーのSctUserGroups内のプレースホルダ行で置換されます。この行には、ユーザー名と、グループのハイフン(-)プレースホルダが含まれます。現行インスタンス内で少なくとも1つのアカウントが定義されている場合は、別のプロキシで定義されているユーザーのSctUserAccounts内に同様のエントリが作成されます。
SctUserGroups表は、レポート作成期間中にアクティブな各ユーザーのユーザー・グループごとに1行ずつ使用して編成されます。データ収集期間中にログオンしたユーザーを参照します。Content Trackerがプロキシのコンテンツ・サーバー構成で実行されている場合は、現行インスタンス内で定義されているグループのみがリストされます。たとえば、「joe」という名前のユーザーがマスター・インスタンスで定義され、そのユーザーにはマスター・インスタンス内のグループ「Public」および「Plastics」へのアクセス権があるとします。joeがプロキシ・インスタンスにログオンし、そのプロキシ内にグループPlasticsが定義されていない場合、SctUserGroupsには、joeとPublicの関連のみが示されます。
SctUserInfo表は、ユーザーごとに1行ずつ使用して編成されます。現行インスタンスに既知のすべてのユーザー、およびデータ収集期間中に現行インスタンスにログオンした別のインスタンスからの追加ユーザーが含まれます。プロキシ構成においては、あるインスタンスに対してローカルなユーザーは、通常、他のインスタンスに対してUserAdminアプリケーションから可視になります。同じユーザーが2つのインスタンスに同名でローカルに定義されている場合、各インスタンスではローカル・ユーザーのみが可視になります。
たとえば、マスターで定義されている「sysadmin」は、プロキシのUserAdminアプリケーションで表示される「sysadmin」とは異なります。この異なる2ユーザーの両方が、同じデータ収集期間中にログインすることも考えられます。たとえば、マスターからのユーザーがsysadminとしてログオンし、プロキシからのユーザーがcs_2/sysadminとしてログオンするような場合です。この期間について生成されるSctUserInfoファイルには、sysadminとcs_2/sysadminに対する別々のエントリが記載されます。
場合によっては、Content Trackerにはデータの追跡に関する制限事項があります。この項では、それらの制限事項の概要を示します。
現在、Content Trackerでは、単一サーバーにインストールされたマルチノード・クラスタはサポートされていません。このことは、複数のネットワーク・カードが搭載され、各クラスタ・ノードに固有のIPアドレスがある場合にも当てはまります。この場合、各クラスタ・ノードのContent Serverインスタンスは、IntradocServerPortを特定のIPアドレスに正常にバインドできます。
ただし、受信プロバイダのServerPortを指定のIPアドレスにバインドできるクラスタ・ノードは1つのみです。したがって、すべてのクラスタ・ノードが同じ受信プロバイダのServerPortを共有し、交代で使用します。このため、Content TrackerのSctLockプロバイダは、一度に1つのクラスタのドキュメント・アクセスのみを追跡できます。
Content Trackerによって判別されたアクセス・カウントは通常は正確ですが、状況によっては、コンテンツが実際にリクエスト・ユーザーに配信されたかどうか、または配信された場合にコンテンツのどのリビジョンが配信されたのかをソフトウェアで判別できないことがあります。
WebDAV経由で繰返されるリクエスト: ユーザーがWebDAVクライアント経由でドキュメントにアクセスした後、同じドキュメントに再アクセスする場合、記録されるのは最初のWebDAVリクエストのみです。このようなコンテンツについて報告されるアクセス・カウントは、通常、実際よりも少なくなります。
静的URL: ユーザーがコンテンツ・ファイルのURLを保存しますが、その後コンテンツは改訂され、保存されているURLが無効になります。ユーザーが保存されているURLを介してコンテンツにアクセスしようとすると、エラーが発生します。Content Trackerでは、コンテンツが配信されていなくても、これを正常なアクセスとして記録します。このようなコンテンツについて報告されるアクセス・カウントは、通常、実際よりも多くなります。
静的URLおよび間違ったdID: ユーザーがURLを使用してコンテンツにアクセスし、Content Trackerデータ削減操作が実行される前にコンテンツが改定されていたり、セキュリティ・グループが変更されている場合、ユーザーには最新リビジョンが表示されていると報告されます。このようなコンテンツについて報告されるアクセス・カウントは、通常、実際よりも新しいリビジョンに関して行われます。このような結果を最小限に抑えるには、データ削減を定期的にスケジュールまたは実行します。
この項の内容は次のとおりです。
シナリオ: ユーザーがWebロケーション(URL)を介してコンテンツにアクセスします。その後、Content Trackerでデータ削減操作が実行される前に、コンテンツが改訂されました。ユーザーに表示されたのは実際に表示されたリビジョンではなく、最新リビジョンであると報告されます。このようなコンテンツについて報告されるアクセス・カウントは、実際よりも新しいリビジョンに関して行われる傾向があります。Content Trackerデータ削減を定期的にスケジュールまたは実行して、このような結果を最小限に抑えます。
詳細: これは、前述の「保存済(失効)静的URLによるアクセスの誤検出」に関連しています。つまり、WebサーバーではWebロケーション全体(例:DomainHome/ucm/cs/groups/public/documents/adacct/xyzzy.doc)を使用してコンテンツの検索および配信が行われるのに対し、Content TrackerではContentID部分のみを使用してdIDおよびdDocNameの値が判別されます。さらに、Content Trackerでは、実際のアクセス発生時ではなく、データ削減中にこの判別が行われます。
リビジョンのグループやセキュリティが元のものから変更された場合など、この問題がすぐには明らかにならない場合もあります。たとえば、ユーザーが静的URLを介してドキュメントの「Public」リビジョン1にアクセスした場合、その後ドキュメントがリビジョン2に改訂され、Content Trackerデータ削減の実行前に「Secure」に変更されると、Trackerでは、Secureバージョンがユーザーに表示されたと報告されます。これは、コンテンツ・ファイル・タイプが変更された場合にも起こる可能性があります。ユーザーが元の.xmlバージョンにアクセスした後、データ削減の実行前にその.xmlバージョンが完全に別の.docに置き換えられた場合、Trackerでは、実際の.xmlバージョンではなく.docリビジョンがユーザーに表示されたと報告されます。
シナリオ: ユーザーがコンテンツ・ファイルのWebロケーション(URL)を保存します。その後、コンテンツが改訂されて、保存されているURLが無効になりました。次に、ユーザーが(失効した)URLを介してコンテンツにアクセスしようとして、「該当するページが見つかりません。」エラー(HTTP 404)が発生します。Content Trackerでは、コンテンツが実際にユーザーに配信されていないのに、これを正常なアクセスとして記録する場合があります。このようなコンテンツについて報告されるアクセス・カウントは、実際よりも多くなる傾向があります。
詳細: コンテンツ・ファイルのWebロケーションは、ユーザーが静的URLを介してコンテンツにアクセスするための手段です。URL内の特定のファイル・パスは、わずかに異なる2つのコンテキストで使用されます。1つは、Webサーバーがコンテンツ・サーバー・リポジトリ内でコンテンツ・ファイルを検索する場合で、もう1つは、Content Trackerがデータ削減プロセス中にコンテンツ・ファイルのdIDおよびdDocNameを判別する場合です。問題が発生するのは、コンテンツが改訂されて、URLの保存時とアクセス試行時の間に特定のコンテンツIDのWebロケーションが変更された場合です。
たとえば、Wordドキュメントがチェックインされ、その後XMLドキュメントに改定された場合、コンテンツの最新リビジョンのWebロケーションは、次に示す1行目のコードから2行目のコードに変更されます(ここで、xyzzyは割り当てられたコンテンツIDです)。
DomainHome/ucm/cs/groups/public/documents/adacct/xyzzy.doc
DomainHome/ucm/cs/groups/public/documents/adacct/xyzzy.xmlに変更されます。
元のリビジョンは、
DomainHome/ucm/cs/groups/public/documents/adacct/xyzzy~1.doc
これは、元のWebロケーションは静的URLとして機能しなくなることを意味します。ただし、元のURLから取得されたコンテンツIDは最新リビジョンと一致します。
シナリオ: ユーザーがWebDAVクライアント経由でドキュメントにアクセスした後、同じ方法で同じドキュメントにアクセスします。記録されるのは、ドキュメントに対する最初のWebDAVリクエストのみです。このようなコンテンツについて報告されるアクセス・カウントは、実際よりも少なくなる傾向があります。
詳細: WebDAVクライアントは通常、ネットワーク・トラフィックの量を減らすためになんらかの形態のオブジェクト・キャッシングを使用します。ユーザーが特定のオブジェクトをリクエストすると、クライアントは最初に、ローカル・ストア内にオブジェクトのコピーが存在しているかどうかを判別します。存在していない場合、クライアントはサーバーに接続し、転送をネゴシエートします。この転送は、COLLECTION_GET_FILEサービス・リクエストとして記録されます。
クライアントにすでにオブジェクトのコピーが存在する場合、クライアントはサーバーに接続して、クライアント・ローカル・コピーが取得された後にオブジェクトが変更されたかどうかを判別します。変更されている場合は、新しいコピーが転送され、COLLECTION_GET_FILEサービス詳細が記録されます。
クライアントのオブジェクト・コピーが現行のままである場合、転送は行われず、クライアントは保存済のオブジェクト・コピーをユーザーに表示します。この場合、ユーザーが元のコンテンツの新しいコピーを取得したように見えても、コンテンツ・アクセスはカウントされません。
Content TrackerのWebサーバー・フィルタ・プラグインは、アクセス・リクエストが処理されているユーザーの認可コンテキスト内で実行されます。リクエスト処理スレッドの所有者は、システム・アカウントである場合があります。そうでない場合、これはリクエスト・ユーザーか、またはアプリケーションで使用されるシステム以外の別のタイプのアカウントです。
フィルタによって、情報がRAWイベント・ログに記録されます。ログ・ファイルが存在しない場合、イベント・スレッドを所有するユーザーの保護および認可のデフォルト資格証明を使用して新しいファイルが作成されます。ユーザー・アカウントにデータ・ディレクトリに対する書込み権限がある場合は、コンテンツ・アクセス・データが記録されます。そうでない場合、ログへのリクエストの記録は失敗し、アクセス・イベント詳細は記録されません。
Content Trackerでユーザー・アクセス・リクエストを適切に記録するには、すべてのユーザーについてアカウント認可の資格照明を受け入れるようにデータ・ディレクトリを構成する必要があります。1つの方法は、すべてのユーザーに書込み権限(または同等の権限)を付与することです。セキュリティの考慮事項によって無制限のアクセス・レベルが禁止されていなければ、無制限の書込みアクセス権を許可することをお薦めします。
ExtranetLookコンポーネントを使用すると(有効な場合)、Cookieベースのログイン形式とページを匿名タイプのユーザー向けにカスタマイズできます。このコンポーネントでは組込みのWebサーバー・プラグインを使用して、リクエストを監視し、リクエストがCookie設定に基づいて認証されているかどうかを判別します。ユーザーがコンテンツ・アイテムへのアクセスをリクエストした場合、Content Trackerはそのユーザーのアカウントの認可コンテキスト内で機能する必要があります。
アクセス情報が収集された後に、Content Trackerではイベント・データをログ・ファイルに記録しようとします。ユーザーのアカウントにContent Trackerのデータ・ディレクトリにアクセスする権限がある場合、リクエスト・アクティビティはログに記録されます。ただし、アカウントに書込み認可がない場合、ログへのリクエストの記録は失敗し、リクエスト・アクティビティは記録されません。
この項では、Content Trackerで使用できる様々なデータ追跡機能について説明します。
アクティビティ・スナップショット機能によって、記録された各コンテンツ・アイテム・アクセスに関連するユーザー・メタデータが取得されます。
アクティブにすると、アクティビティ・メトリックおよび対応するメタデータ・フィールドに、コンテンツ・アイテムのユーザー・アクセスに関する検索関連情報が移入されます。オプションの自動ロード機能を使用すると、チェックインされたコンテンツ・アイテムのタイムスタンプが正確になるように、最終アクセス・アクティビティ・メトリックを更新できます。
Content Trackerでは、必要に応じて、特定のコンテンツ・アイテムの人気度を示すコンテンツ・アイテム使用状況情報が検索関連カスタム・メタデータ・フィールドに挿入されます。この情報には、2つの異なる時間間隔における最新アクセスの日付およびアクセス数が含まれます。
これらのアクティビティ・メトリック機能から生成された情報は、様々な方法で使用されます。たとえば、最近表示されたコンテンツ・アイテムや、先週最も多く表示されたコンテンツ・アイテムに従って、検索結果を並べ替えることができます。
スナップショット機能がアクティブになっている場合は、削減後の手順で検索関連メタデータ・フィールドの値が更新されます。この処理手順の間、Content TrackerではSQL問合せを使用して、アクティビティ・メトリックの値を変更したコンテンツ・アイテムが判別されます。Content Trackerでは、適用可能なデータベース表が新しい値で更新され、再索引付けサイクルが開始されます。ただし、再索引付けされるのは、メタデータ値を変更したコンテンツ・アイテムのみです。
これらのオプション機能を使用するには、最初に、アクティビティ・メトリック選択項目をアクティブにするスナップショット後処理機能を有効化する必要があります。次に、アクティビティ・メトリックを選択して有効化し、事前に選択したカスタム・メタデータ・フィールドを割り当てます。
スナップショット機能を有効化し、アクティビティ・メトリックをアクティブ化する手順は、次のとおりです。
スナップショット機能を実装する前に、有効化した各アクティビティ・メトリックに関連付けるカスタム・メタデータ・フィールドを決定します。また、このカスタム・メタデータ・フィールドが存在し、正しい型である必要があります。有効化するアクティビティ・メトリックに応じて、適用可能な手順に従って1つ以上のカスタム・メタデータ・フィールドを作成します。
アクティビティ・メトリックに関する次の特定情報を追加します。
最終アクセス・メトリック
フィールド・タイプ: 日付
デフォルト値: オプション。指定されていない場合、コンテンツ・アイテムがチェックインされてデータ削減が実行されるまで、フィールドは移入されません。一部のアプリケーションではデフォルト値が必要であり、その場合は、最終アクセス・フィールドにコンテンツのチェックインの日時が移入されるように「デフォルト値」フィールドに値を入力します。詳細は、「最終アクセス・フィールドのチェックイン時刻値の設定」を参照してください。
検索インタフェースの有効化: オプション。検索に使用できるフィールドの作成をチェックします。
短期および長期アクセス・メトリック
フィールド・タイプ: 整数
検索インタフェースの有効化: オプション。検索に使用できるフィールドの作成をチェックします。
カスタム・メタデータ・フィールドの索引付けはオプションですが、索引付けによってこのフィールドでの検索がより効率的になります。索引付けによって、蓄積された検索関連統計を問い合せて有用なデータを生成できます。たとえば、人気順に並べたコンテンツ・アイテムのリストを作成できます。
通常、最終アクセス日付フィールドは、管理対象オブジェクトがユーザーおよびデータ削減実行によってリクエストされると、Content Trackerによって更新されます。フィールドは、次のデータ削減が実行されるまで空(NULL)になる場合があります。アプリケーションによっては、最終アクセス・フィールドにコンテンツ・チェックインの日時が即時に記録される必要があります。
最終アクセス・フィールドに移入するには、次のいずれかの方法を使用します。
構成マネージャの使用: メタデータ・フィールドを追加する場合、コンテンツ・チェックインの日時をフィールドに移入する式を入力します(たとえば、<$dateCurrent()$>のデフォルト値では、現在のチェックインの日時がフィールドに移入されます)。値を設定した後、「自動ロード」オプションを使用して既存コンテンツのフィールドに入力します。
「自動ロード」オプションの使用: このオプションを使用すると、最終アクセス・フィールドのNULL値を遡って現在の日時に置き換えることができます。最終アクセス・メタデータ・フィールドが空(NULL)のレコードのみが影響を受けます。
「メイン」メニューから「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センター: 「スナップショット」タブをクリックします。
1つ以上のアクティビティ・メトリックのチェック・ボックスを選択して有効にします。アクティビティ・メトリックにリンクされるカスタム・メタデータ・フィールドの名前を入力します(xLastAccess、xShortAccess、xLongAccessなど)。
「自動ロード」チェック・ボックスを選択します。
「OK」をクリックします。
確認ダイアログ・ボックスが表示され、DocMetaデータベース表の適用可能な最終アクセス・フィールド(値がNULL)に現在の日時が挿入されます。
次の点に注意してください。
「自動ロード」は、主に、チェックイン操作をアクセス・アクティビティとしてみなすアプリケーションでの使用を意図しています。
「自動ロード」では、最終アクセス・フィールドに日付の値が含まれていない既存のすべてのコンテンツに現在の日時が入力されます。最終アクセス・フィールドの定義後にチェックインされたすべてのコンテンツのフィールドには、デフォルト値としてチェックインの日時が自動的に移入されます。
「自動ロード」の実行は、DocMetaデータベース表内のすべてのレコードに影響を与えることがあります。このオプションは可能なかぎり使用しないようにしてください。
最終アクセス・メタデータ・フィールドが空(NULL)のDocMetaレコードのみが影響を受けます。
「自動ロード」は永続的です。「自動ロード」チェック・ボックスの状態は、スナップショットの他の設定とともに保存されます。このオプションを誤って使用しないようにするには、自動ロード機能を実行した直後に「自動ロード」チェック・ボックスの選択を解除して、アクティビティ・メトリック・フィールドの設定を再度保存してください。
「自動ロード」による更新の完了後にコンテンツ・サーバーのインデクサは自動実行されません。コレクションの再構築をいつ実行するかを決定する必要があります。
デフォルトでは、「自動ロード」問合せによって、最終アクセス・メタデータ・フィールドが現在の日時に設定されます。必要に応じて問合せをカスタマイズできます。
アーカイブおよびバッチロードされたコンテンツを適切に保存するには、インポートまたは挿入用に最終アクセス・フィールドに日付を設定します。そうしないと、これらのコンテンツ・アイテムのアクセス日付はNULLになり、このフィールドに基づいた保存は失敗します。また、日付が保存管理にどのように影響するかについても考慮してください。たとえば、1998年データのインポートは、コンテンツの保存品質を正確に反映するために、インポートを実行した日付よりもその日付を使用した方が適切にタグ付けできる場合があります。
最終アクセス・フィールドの名前は、フィールドの作成時に指定した名前に基づいています。たとえば、最終アクセスという名前を使用する場合は、xLastAccessがインポートまたは挿入で使用されます。
バッチ・ローダー・ユーティリティの使用方法の詳細は、Oracle Fusion Middleware Oracle WebCenter Contentの管理を参照してください。
バッチ・ローダーを使用して最終アクセス・フィールドに移入する手順の概要は、次のとおりです。
アクティビティ・メトリック・オプションは、アクティブ化した後、個別に選択して有効化する必要があります。アクティビティ・メトリックを有効化すると、対応するカスタム・メタデータ・フィールドもアクティブ化されます。
アクティビティ・メトリックを有効化し、対応するカスタム・メタデータ・フィールドをアクティブ化する手順は、次のとおりです。
フィールドでは、大文字と小文字が区別されることに注意してください。すべてのフィールド値が正しいスペルの大文字であることを確認してください。
Content Trackerでは次のエラー・チェックを使用して、有効化されたそれぞれのアクティビティ・メトリック・フィールドの値を検証します。
DocMetaデータベース表をチェックして、カスタム・メタデータ・フィールドが実際に存在することを確認します。
カスタム・メタデータ・フィールドの型が正しいことを確認します(たとえば、最終アクセス・メタデータ・フィールドは日付型などになります)。
dIDメタデータ・フィールドを明示的に除外することを確認します。
Content Trackerでは、サービス・コールを、関連付けられたサービスに関連するデータ値とともにログに記録できます。ログに記録する各サービスには、サービス・コール構成ファイル(SctServiceFilter.hda)内にサービス・エントリが存在している必要があります。ログに記録するサービスに加えて、対応するフィールド・マップResultSetをSctServiceFilter.hdaに含めることができます。
サービス・コールの管理の詳細は、Oracle Fusion Middleware Oracle WebCenter Contentによる開発を参照してください。
重要:
Webビーコン機能の実装要件は、関連するシステム構成に依存しています。このドキュメントでは、すべての要素には対応できません。Content Trackerで収集および処理されるアクセス・レコードに関する情報は、正確なカウントではなく、一般的なユーザー・アクティビティを示すものです。
Webビーコンは、Webページまたは他の管理対象コンテンツへの間接ユーザー・アクセスを容易に追跡するための特別サポートを提供する管理対象オブジェクトです。Content Trackerの以前のリリースでは、キャッシュされたページのデータや、キャッシュされたサービスから生成されたページのデータは収集できませんでした。キャッシュされたWebページやコンテンツ・アイテムにユーザーがアクセスした場合、コンテンツ・サーバーやContent Trackerではこれらのリクエストが発生したことを認識できません。Webビーコン参照を使用しないと、Content Trackerではこのようなリクエストを記録してカウントできません。
Webビーコンを使用すると、クライアント側では、コンテンツ・サーバー内の管理対象ビーコン・オブジェクトへの目にみえない参照として埋込み参照を使用できます。Content Trackerでは、コンテンツ・サーバーからコンテンツを直接取得せずに、再配布のために外部エンティティによってコピーされた管理対象コンテンツ・アイテムに対するユーザー・アクセス・リクエストを記録してカウントできます。
Webビーコン機能はリバース・プロキシ・アクティビティに役立ちます。
特に、リバース・プロキシ・アクティビティおよびSite Studioの使用時には、Webビーコン機能の使用が適しています。
リバース・プロキシ・シナリオでは、リバース・プロキシ・サーバーは、ユーザーとコンテンツ・サーバーの間に位置します。リバース・プロキシ・サーバーはリクエストされたオブジェクトのコピーを作成することにより、管理対象コンテンツ・アイテムをキャッシュします。別のユーザーが次回にドキュメントを要求すると、プライベート・キャッシュ内のコピーが表示されます。リバース・プロキシ・サーバーのキャッシュ内にオブジェクトが存在しない場合は、コピーをリクエストします。
リバース・プロキシ・サーバーはキャッシュされたコンテンツを配信するため、コンテンツ・サーバーと直接相互作用することはありません。したがって、Content Trackerではこれらのリクエストを検出できないため、このユーザー・アクセス・アクティビティを追跡できません。
リバース・プロキシ・サーバーは、キャッシュしたり、ファイアウォールの内側にあるアプリケーションやサイトへのWebアクセスを管理することによって、Webパフォーマンスを向上させるために使用します。このような構成は、頻繁にアクセスされるコンテンツのコピーを、スケジュールに基づいて更新されるWebサーバーに移動することによってロード・バランシングを行います。
Webビーコン機能を有効にするために、各ユーザー・アクセスには、コンテンツ・サーバーの管理対象ビーコン・オブジェクトへの追加リクエストが含まれています。追加リクエストによってオーバーヘッドが増加しますが、Webビーコン・オブジェクトは非常に小さいため、リバース・プロキシ・サーバーのパフォーマンスに大きな影響を与えることはありません。必要なのは、特に追跡するオブジェクトにWebビーコン参照を埋め込む操作のみです。
Webサイトが外部対象者向けの場合は、サイトのコピーを作成して、別のサーバーに転送できます。このソリューションでは、サイトをパブリックに表示すること以外に、開発サイトと本番サイトを別々にすることも可能です。ただし、この配置の場合は、Webビーコン機能を実装して、Content Trackerでユーザー・アクティビティを収集および処理できるようにしてください。
Webビーコン・オブジェクトの管理方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』を参照してください。
