| Oracle® Fusion Middleware Oracle WebCenter Contentのマネージング 11g リリース1 (11.1.1) B72426-04 |
|
 前 |
 次 |
この章では、コンテンツ・サーバー・インスタンスのコンテンツ・アイテムのアクティビティに関する情報を取得する方法について説明します。このアクティビティは、Oracle WebCenter Content ServerのコンポーネントであるContent TrackerおよびContent Trackerレポートを使用して追跡できます。
この章の内容は、次のとおりです。
Content TrackerおよびContent Trackerレポートはオプションのコンポーネントで、Oracle WebCenter Content Serverとともに自動的にインストールされます。これらは個別のモジュールですが、有効化すると、最もアクセス頻度の高いコンテンツ・アイテムや、ユーザーまたは特定グループにとって最も価値の高いコンテンツなど、システムの使用状況に関する情報を提供します。組織のコンテンツの消費パターンを理解することによって、ユーザーを中心に据えた適切な情報をより効率的に提供できます。
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でデータが抽出され、データベース表に移入された後、Content Trackerレポート使用して次のことを実行できます。
レポートの生成: 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レポートには、アクティビティおよび使用状況に関するよくある質問の答えを示すレポートが用意されています。また、Content Trackerの構成に応じて、これらのレポートから、最も使用頻度が高い検索および最もアクティブなユーザーを特定することもできます。レポートは、インタフェースから直接使用したり、「コンテンツ情報」ページでアクションとして使用できます。事前定義済レポート・オプションの使用可能なカテゴリは、Content Trackerの構成によって異なります。レポート、基礎となる問合せおよび出力書式はカスタマイズできます。
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レポートに使用できるようになります。
データ収集は、追跡機能の最初のステップです。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では、このような重複を回避する処理は行われません。
データ収集を有効化または無効化する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センター: 「コレクション」タブで、「データ収集の有効化」チェック・ボックスを選択(収集を有効化する場合)するか、選択を解除(収集を無効化する場合)します。
「OK」をクリックします。
アプレットは終了しないでください。確認メッセージが表示されるまで待ちます。確認メッセージの前に終了すると、要求した変更が有効にならない場合があります。
確認メッセージが表示されたら、「OK」をクリックします。
Webサーバーおよびコンテンツ・サーバーをこの順序で再起動します。
データ削減中に、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では、データベース表メタデータ・フィールドが新しい値で更新され、再索引付けサイクルが開始されます。ただし、再索引付けされるのは、アクセス・カウント・メタデータ値が変更されたコンテンツ・アイテムのみです。
削減後の手順は、影響を受けるコンテンツ・アイテムごとにアクティビティ・メトリックを処理して表を作成し、割り当てられたカスタム・メタデータ・フィールドにデータをロードするために必要です。また、アクティビティ・メトリック値が変更されたコンテンツ・アイテムに対して再索引付けサイクルを開始することによって、確実にデータが検索索引に含まれるため、検索結果を選択したり並べ替えるためにアクセスできるようになります。
削減された表データは、関連付けられた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:
特定の日(たとえば、土曜日と日曜日)のアクティビティが削減されていない場合、コンテンツ・アイテムへのアクセス方法によっては、これらの日に発生したアクセスが記録またはカウントされないことがあります。詳細は、第9.3.2.4項を参照してください。同様に、火曜日にコンテンツ・アイテムがアクセスされ、月曜日と水曜日に削減が実行された場合、そのコンテンツ・アイテムへの最後のアクセスに対して火曜日のアクセスがカウントされないことがあります。
シナリオ2:
過去数日間でアクセス数が大幅に増加し、2週間前からのデータを削減した場合、コンテンツ・アイテムの長期および短期のアクセス・メトリックは最新のアクティビティを反映しません。この場合、2週間前からの間隔値で本日の値がオーバーライドされます。現在または最新のデータ・セットを削減すると、カウントが訂正されます。
削減順序によって最終アクセス日付が誤って変更されることはありません。削減データ・セット内の最新のアクセスがコンテンツ・サーバーのDocMetaデータベース表の最終アクセス値よりも新しい場合にのみ、削減プロセスによって最終アクセス日付が変更されます。
最新のデータ・セットを削減し、特定のコンテンツ・アイテムがアクセスされた場合は、最終アクセス・フィールドが削減データ・セット内の最新のアクセス日付に更新されます。その後、それ以前のデータ・セットを再削減した場合、現行値は、このコンテンツ・アイテムに対する以前のアクセス日付で上書きされません。
シナリオ3:
任意の順序でデータ・セットを削減した場合は、「最新」データ・ファイルから「アーカイブ」データ・ファイルへの移行が妨げられます。関連付けられた表レコードは存続時間に基づいて移動し、アーカイブ表は最も古いデータを格納することを目的にしています。データ・セットがランダムな順序で削減された場合、どのデータが最も古いかは不明になります。
「最新」データ・ファイルおよび「アーカイブ」データ・ファイルの詳細は、第9.3.5.2項および第9.3.2.3項を参照してください。
スケジュールに基づいた削減の実行を構成し、定期的にRAWデータを削減できます。RAWデータは、「最新」リポジトリおよび「アーカイブ」リポジトリに安定して移動し、同様に、削減済データはプライマリ表からアーカイブ表に安定して移動します。
Content Trackerデータ・エンジンが、スケジュールされた削減実行の前日に無効化された場合、データは収集されないことに注意してください。スケジュールされた削減実行の日に有効化された場合、使用可能なデータが存在しないため、スケジューラは実行されません。
特定の日にスケジュールされたデータ削減は、その前日中に収集されたデータに対して実行されます。前日の定義は、午前0時(システム時間)に開始および終了する24時間です。CPUリソースを節約するには、システム負荷が一般に最も低い早朝時間帯に削減実行をスケジュールします。
削減が午前0時から数分後以内に実行されるようにスケジュールされている場合、エラーが発生することがあります。エラーが発生した場合は、削減がそれよりも後に実行されるように再スケジュールしてください。
データを手動で削減する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センター: 「削減」タブで、削減する入力データのセットをクリックして選択します。このページには、次の情報が表示されます。
サイクル: 入力データのステータス。値には、「新規」(入力データが削減されていません)、「最新」(データが削減されていますがアーカイブされていません)および「アーカイブ」(削除されるまでデータは「アーカイブ」サイクルのままです)があります。
データ収集日: データが収集された日時。
ステータス: 削減のステータス。値には、「準備完了」(入力データを削除できます)、「実行中」(データを削減中です)および「アーカイブ」(データを「最新」サイクルから「アーカイブ」サイクルに移動中です)があります。
完了(%): 削減サイクルの進行状況。
完了日: 削減が完了した日時。
「データの削減」をクリックします。
データを削減するには、「はい」をクリックします。
|
注意: 現在の日付のデータが削減された場合、データが削減されても「サイクル」列のステータスは「新規」のままです。 |
データ削減の自動実行を設定する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センター: 「スケジュール」タブで、「スケジュール設定が有効化されています」チェック・ボックスを選択します。
データ削減を実行する曜日のチェック・ボックスを選択します。
データ削減を実行する時間および分を選択します。
「OK」をクリックします。
アプレットは終了しないでください。確認メッセージが表示されるまで待ちます。確認メッセージの前に終了すると、要求した変更が有効にならない場合があります。
確認メッセージが表示されたら、「OK」をクリックします。
データ・ファイルを削除する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センター: 「削減」タブで、削除する入力データのセットをクリックして選択します。
「削除」または「アーカイブの削除」をクリックします。
データを削除するには、「OK」をクリックします。
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 through extField_10 |
varchar /255 |
拡張されたサービス・トラッキング機能で使用する汎用目的の列。フィールド・マップResultSet内では、DataBinderフィールドがこれらの列にマップされます。 |
Content Trackerが適切に構成されている場合は、静的および動的なコンテンツ・アクセス・リクエスト情報およびすべてのメタデータ・フィールドが、Content Trackerレポート・コンポーネントによって生成されるレポートで使用できるようにアクセス可能になります。ログに記録されるメタデータには、コンテンツ・アイテムおよびユーザー・メタデータが含まれます。
Content Trackerでは、コンテンツ・アイテム・メタデータ用に、標準のコンテンツ・サーバー・メタデータ表が使用されます。このため、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データ・エンジンによって、reduction-yyyymmdd.logという名前のサマリー結果ログ・ファイルが生成されます。削減ログは、データ削減エラーを診断する際に役立ちます。
場合によっては、Content Trackerにはデータの追跡に関する制限事項があります。この項では、それらの制限事項の概要を示します。
現在、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データ削減操作が実行される前にコンテンツが改定されていたり、セキュリティ・グループが変更されている場合、ユーザーには最新リビジョンが表示されていると報告されます。ユーザーが元のバージョンにアクセスした後、それが別のバージョンに置き換えられた場合、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では、実際のアクセス発生時ではなく、データ削減中にこの判別が行われます。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は最新リビジョンと一致します。Webサーバーがリクエストされたファイルをユーザーに配信できなかった場合でも、Content TrackerではこれがコンテンツID「xyzzy」へのアクセスとして報告されます。
シナリオ: ユーザーが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では、適用可能なデータベース表が新しい値で更新され、再索引付けサイクルが開始されます。ただし、再索引付けされるのは、メタデータ値を変更したコンテンツ・アイテムのみです。
これらのオプション機能を使用するには、最初に、アクティビティ・メトリック選択項目をアクティブにするスナップショット後処理機能を有効化する必要があります。次に、アクティビティ・メトリックを選択して有効化し、事前に選択したカスタム・メタデータ・フィールドを割り当てます。
スナップショット機能を有効化し、アクティビティ・メトリックをアクティブ化する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センター: 「スナップショット」タブで、スナップショットの有効化を選択します。
「OK」をクリックします。
確認ウィンドウで、「OK」をクリックします。
スナップショット機能を実装する前に、有効化した各アクティビティ・メトリックに関連付けるカスタム・メタデータ・フィールドを決定します。また、このカスタム・メタデータ・フィールドが存在し、正しい型である必要があります。有効化するアクティビティ・メトリックに応じて、適用可能な手順に従って1つ以上のカスタム・メタデータ・フィールドを作成します。
アクティビティ・メトリックに関する次の特定情報を追加します。
最終アクセス・メトリック
フィールド・タイプ: 日付
デフォルト値: オプション。指定されていない場合、コンテンツ・アイテムがチェックインされてデータ削減が実行されるまで、フィールドは移入されません。一部のアプリケーションではデフォルト値が必要であり、その場合は、最終アクセス・フィールドにコンテンツのチェックインの日時が移入されるように「デフォルト値」フィールドに値を入力します。詳細は、第9.4.1.4項を参照してください。
検索インタフェースの有効化: オプション。検索に使用できるフィールドの作成をチェックします。
短期および長期アクセス・メトリック
フィールド・タイプ: 整数
検索インタフェースの有効化: オプション。検索に使用できるフィールドの作成をチェックします。
カスタム・メタデータ・フィールドの索引付けはオプションですが、索引付けによってこのフィールドでの検索がより効率的になります。索引付けによって、蓄積された検索関連統計を問い合せて有用なデータを生成できます。たとえば、人気順に並べたコンテンツ・アイテムのリストを作成できます。
通常、最終アクセス日付フィールドは、管理対象オブジェクトがユーザーおよびデータ削減実行によってリクエストされると、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の管理』を参照してください。
バッチ・ローダーを使用して最終アクセス・フィールドに移入する手順の概要は、次のとおりです。
バッチ・ローダーにアクセスします。
適切な最終アクセス日付を確立するレコードを作成します。次に例を示します。
# This is a comment Action=insert dDocName=Sample1 dDocType=ADACCT xLastAccess=5/1/1998 dDocTitle=Batch Load record insert example dDocAuthor=sysadmin dSecurityGroup=Public primaryFile=links.doc dInDate=8/15/2001 <<EOD>>
バッチ・ローダーを実行して、ファイル・レコードを処理します。
アクティビティ・メトリック・オプションは、アクティブ化した後、個別に選択して有効化する必要があります。アクティビティ・メトリックを有効化すると、対応するカスタム・メタデータ・フィールドもアクティブ化されます。
アクティビティ・メトリックを有効化し、対応するカスタム・メタデータ・フィールドをアクティブ化する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センター: 「スナップショット」タブをクリックします。
1つ以上のアクティビティ・メトリックのチェック・ボックスを選択して有効にします。アクティビティ・メトリックにリンクされるカスタム・メタデータ・フィールドの名前を入力します(xLastAccess、xShortAccess、xLongAccessなど)。
短期アクセス・カウントおよび長期アクセス・カウントに、適用可能な時間間隔を日数で入力します。たとえば、短期アクセス・カウントに7日間、長期アクセス・カウントに28日間と入力します。
これら2つのアクセス・カウント・メトリックは計算期間のみが(たとえば、最後の30日間と最後の90日間、最後の1週間と最後の1年間のように)異なります。アクティビティ・メトリックに指定される時間間隔は相互に独立しています。たとえば、1つ目の時間間隔(短期アクセス)の日数に、2つ目の時間間隔(長期アクセス)よりも長い日数を設定できます。
削減された日数についてのみ、アクセス・カウントが表に計上されます。1日分以上のデータを削減しない場合、その日付に対するアクセスはログに記録およびカウントされません。アクセス・カウント・メトリックは削減日の順序の影響を受けるため、ランダムな順序でデータを削減しないでください。
終了したら、「OK」をクリックします。
確認ウィンドウで、「OK」をクリックします。
フィールドでは、大文字と小文字が区別されることに注意してください。すべてのフィールド値が正しいスペルの大文字であることを確認してください。
Content Trackerでは次のエラー・チェックを使用して、有効化されたそれぞれのアクティビティ・メトリック・フィールドの値を検証します。
DocMetaデータベース表をチェックして、カスタム・メタデータ・フィールドが実際に存在することを確認します。
カスタム・メタデータ・フィールドの型が正しいことを確認します(たとえば、最終アクセス・メタデータ・フィールドは日付型などになります)。
dIDメタデータ・フィールドを明示的に除外することを確認します。
スナップショットのアクティビティ・メトリック設定を変更する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センター: 「スナップショット」タブをクリックします。
アクティビティ・メトリック・フィールドに必要な変更を加えます。
「OK」をクリックします。
確認ウィンドウで、「OK」をクリックします。
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ビーコン参照を埋め込む操作のみです。
別の使用シナリオに関係するのがSite Studioであり、これは、コンテンツ・サーバーで格納および管理されるWebサイトを作成するために使用されるアプリケーションです。Site StudioとContent Serverが同じサーバーに存在する場合、Content Trackerは適用可能なユーザー・アクセスを自動的に追跡するように構成されます。収集されたSite Studioアプリケーション・データは、第9.5.1.4項で説明されているように、事前定義済レポートで使用されます。
Webサイトが外部対象者向けの場合は、サイトのコピーを作成して、別のサーバーに転送できます。このソリューションでは、サイトをパブリックに表示すること以外に、開発サイトと本番サイトを別々にすることも可能です。ただし、この配置の場合は、Webビーコン機能を実装して、Content Trackerでユーザー・アクティビティを収集および処理できるようにしてください。
Webビーコン・オブジェクトの管理方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』を参照してください。
Content Trackerレポートでは、取得されて削減されたデータを使用して、特定のコンテンツ部分の使用状況履歴の概要を示すレポートが生成されます。事前定義済レポートを使用したり、追跡する情報に対するカスタム問合せを作成します。外部の市販レポート作成ツールを使用できます。詳細は、第9.5.2.5項を参照してください。
デフォルトでは、Content Trackerではコンテンツ・アクセス・イベントのデータのみが収集および記録され、検索などのコンテンツ・アクセス・イベント以外での情報収集やユーザー・プロファイルのサマリーの収集および統合は除外されます。この除外のため、「Content Trackerレポートの生成」メイン・ページには様々な事前定義済レポートのオプションは表示されません。事前定義済レポートのすべてのオプションを使用可能にするには、config.cfgファイルを変更して最適化機能の設定を変更するか、コンポーネント・マネージャの更新機能を使用します。
レポートは、特定のユーザー、ユーザー・グループ、メタデータ値の問合せやグループによって定義可能なコンテンツのセットなど、様々な基準から導出できます。Content Trackerレポートでは、システム内の変数(ユーザーの数、コンテンツの量、メタデータ・カウントなど)に基づいて、数百個もの主要なメトリックをレポートに含めることができます。特化したレポートによって、ユーザーに最も関連性の高いコンテンツを把握して公開できます。
この項の内容は次のとおりです。
レポート機能を使用する場合は、次の問題を考慮してください。
コンテンツ・サーバー・データベースとしてOracleデータベースまたはDB2を使用している場合は、メタデータ値の大/小文字が区別されます。大/小文字を正しく使用して問合せレポート基準に値を入力する必要があり、そうしない場合、Content Trackerレポートで一部の可能な一致ファイルが返されないことがあります。
たとえば、OracleまたはDB2コンテンツ・サーバー・データベースがAdAccであるのに、ユーザーが問合せフィールドにadacc、ADACCまたはAdaccと入力した場合、Content Trackerレポートでは結果が返されません。この場合、各事前定義問合せレポートのすべてのメタデータ・フィールドに対して、入力値とメタデータ値の大/小文字を一致させる必要があります。
Content Trackerレポートのコンポーネントをインストールすると、SctrEnableSecurityChecks構成変数が設定され、2つのセキュリティ・モード(セキュア・モードおよび非セキュア・モード)のいずれかを使用できます。変数を変更すると、個々のユーザー・ロールおよびアカウント情報を使用して、レポート結果におけるコンテンツ・アイテム情報の表示を制限するためのオプションが提供されます。
生成されるレポートでユーザーに表示されるコンテンツ・アイテムおよびメタデータを制御できます。ユーザーがコンテンツ・サーバー検索で見つけられなかった内容はContent Trackerレポートでも表示されないようにすることが理想的です。セキュア・モードを使用すると、生成されるレポートの情報は、ユーザーのロールおよびアカウント権限に基づいてフィルタ処理されます。
ただし、インスタンスに対してアクセス制御リスト(ACL)を有効化した場合、Content Trackerレポートのセキュア・モード・オプションは機能しません。インストール時は、セキュリティ・チェック・プリファレンス・チェック・ボックスを空白にしておいてください。ACLベースのシステムでは、セキュア・モードが無効になっている必要があります。この場合、システム管理者以外のユーザーに、本来はアクセスと表示の権限を付与していないコンテンツ・アイテムの情報が表示される可能性があります。
システムまたは権限で保護されたコンテンツ・アイテムへの失敗したアクセス試行を監視する監査機能を使用できます。セキュリティ違反のアクセス試行の分析に役立つ2つのレポートが用意されており、これらのレポートには、失敗したユーザー・ログイン、およびセキュアなコンテンツ・アイテムへの失敗したアクセス試行が表示されます。失敗したアクセス試行に関する情報は、システムやコンテンツのセキュリティを保護したり、監査証跡およびレコードを適切に保持するために不可欠です。
使用可能な監査レポートは次のとおりです。
ユーザーによる認可の失敗: このレポートには、ユーザー名とそのIPアドレスを含む、アクセス認可の否認情報が示されます。これらのユーザーにはシステム・アクセス権限がありますが、ユーザーのロールまたはアカウントのメンバーシップによって特定のコンテンツ・アイテムへのアクセス(給与コンテンツへのアクセスなど)が制限される場合があります。
ログイン失敗: このレポートには、ユーザー名とそのIPアドレスを含む、ログインおよび認証の失敗情報が示されます。ログインが成功しないとユーザー・タイプを区別できないため、ログに記録されたデータでは、外部ユーザー、内部ユーザーおよびグローバル・ユーザーは区別されていません。
Site Studioを使用している場合は、Site Studioアクティビティが追跡されるようにContent Trackerが自動的に構成されます。Content Trackerレポートでは、ログに記録されたデータを使用して、Webサイト・アクセス結果を要約する事前定義済レポートが生成されます。Site Studioをインストールしている場合は、「Content Trackerレポートの生成」メイン・ページに、Site Studio固有のWebアクセス・レポートが表示されます。
Site Studioの事前定義済レポートでは、Content Trackerレポートのデフォルト・フォーマットが使用され、ドリルダウン・レポート機能が提供されます。どちらの場合も最上位レベル・レポートは、「サイトID」および「アクセス」を汎用基準として使用したサマリー・レポートです。ドリルダウン・レポートには、関連する統計が示されます。
Webサイト・コンテンツへのアクセス: このレポートは、最上位レベルではIDベースで、それ以降のドリルダウン・レポートでは結果がコンテンツID別および相対URL別にリストされます。この情報によって、Webサイトへのアクセスに使用されているURLが示されます。ただし、実際には、多数の異なるURLで同じページが表示される場合もあります。このレポートの結果には、ユーザーがノードにアクセスした方法に関係なく、ノードの合計アクセス数も含まれます。
URLを使用したWebサイト・アクセス: このレポートには、Webサイト相対URLおよび関連するアクティビティ合計が要約されます。
Content Trackerレポートの生成には3つの方法があります。
Content Trackerレポートには、最も頻繁にリクエストされるトピックのレポートを生成するために使用される多くの事前定義済レポート・オプションが用意されています。
「Content Trackerレポートの生成」を使用して生成する各レポートには、同じ一般フォーマットとビジュアル・レイアウトが適用されます。レポートの情報は、SctAccessLogデータベース表およびその他のコンテンツ・サーバー・データベース表(必要な場合)の削減済データから抽出されます。
コンパイル済結果に含まれるのは、コンテンツ・アイテムをリクエストして開いたユーザーです。開かれるコンテンツ・アイテムは、Webロケーション・ファイル(コンテンツ・アイテムへの絶対パス)、HTMLバージョン(Dynamic Converterを使用)、または実際のネイティブ・ファイルです。「コンテンツ情報」ページのみを開いたユーザーは、追跡データに含まれません。
情報は最初にContent Trackerによって蓄積され、次にデータ削減サイクルを経過する必要があります。データを手動で削減すると即時にデータベース表が更新され、生成された問合せレポートにも更新済の情報が表示されます。そうでない場合は、ユーザーがコンテンツ・アイテムにアクセスしてから、その情報がアクセス履歴結果に含められるまでに、1日の遅れがあります。
生成された問合せレポートに特定のコンテンツ・アイテムへのアクティブなリンクが含まれている場合、そのリンクをクリックすると、対応するコンテンツ・ダッシュボードが表示されます。コンテンツ・ダッシュボードには、コンテンツ・アイテムのバージョンおよびアクセス回数が表示されます。「バージョン別」をクリックするとすべてのバージョンが表示され、「すべてのバージョン」をクリックするとバージョンの表示が結合されます。
事前定義済レポートごとに、様々なレベルのレポート結果を生成できます。「Content Trackerレポートの生成」メイン・ページで入力した検索条件に基づいて、結果が適宜フィルタ処理されます。最上位レベルのレポートはサマリー・レポートで、一般性の高い情報が示されます。最上位レベルのレポートにあるリンクを使用して、より具体的な情報にドリルダウンします。
Content Trackerレポートで提供されているサンプル・レポートに加えて、情報を追跡するためのカスタム問合せを作成できます。カスタム・レポートを作成する場合は、次の内容を考慮してください。
Oracle Databaseおよびエイリアスを使用して、生成されるレポートに列名を表示するには、/shared/config/resources/upper_clmns_map.htmファイルにエイリアスを追加します。たとえば、NameおよびAccess_Date_GMT列ヘッダーを使用する場合は、upper_clmns_map.htmファイル内に次の行を入力します。
<tr> <td>NAME</td> <td>Name</td> </tr> <tr> <td>ACCESS_DATE_GMT</td> <td>Access_Date_GMT</td> </tr>
拡張されたサービス・トラッキング機能を使用する場合は、サービス名が常にsc_scs_idcService列に記録されることに注意してください。拡張フィールドのコンテンツを参照する問合せを設計する場合は、問合せ内に修飾子としてサービスを含めます。
カスタム・レポート問合せをレポート問合せファイルに追加した後は、それを使用して結果を表示できるようになります。
事前定義済レポートまたはカスタム・レポートを生成する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Trackerレポート」を選択します。
レポート・タイプを選択します。
該当するフィールドに、検索基準およびフィルタ処理基準を入力します。
「送信」をクリックします。
コンテンツ・アイテムの「情報」ページからそのコンテンツ・アイテムのアクセス履歴レポートを生成できます。
コンテンツ・アイテムを検索し、関連付けられた「情報」アイコンをクリックします。
「コンテンツ情報」ページの「グローバル・アクション」リストから、「アクセス履歴レポートの表示」を選択します。
コンテンツ・アクセス・レポートで、「アクセス」をクリックします。
コンテンツ・アクセス・レポートで、「ユーザー」をクリックします。
市販のレポート生成ツールを使用して、Content Trackerで収集されたデータから基本的なテキスト・レポートや、より高度なグラフィック(棒グラフや円グラフなど)を生成できます。
このガイドでは、カスタム・レポートの作成で使用する外部レポート作成ツールについての操作知識がユーザーにあることを前提としています。このため、この項では、ほとんどの市販のレポート作成製品に適用できる基本的なガイドラインのみを示しています。
外部レポート作成ツールを使用してカスタム・レポートを生成する手順は、次のとおりです。
外部レポート作成ツール・アプリケーションを開きます。
データベースへのODBC接続(適用可能な場合)を設定します。
レポートに使用するデータベース表を選択します。
ファイル内で共通のキーIDまたはフィールドに基づいて、選択した複数の表をリンクします。選択した各表は、各表に共通している同じキーIDまたはフィールドを使用してリンクすることが理想的です。
各表からフィールドを選択して、レポート・フォームに統合します。ほとんどの場合、フィールドを選択してフォームにドラッグ・アンド・ドロップできます。
この手順では、カスタマイズ・レポートを設計します。外部レポート作成アプリケーションによって生成される最終的な基本テキスト・レポートでは、選択した特定のフィールドは列として表示されます。
外部レポート作成アプリケーションでこれらのオプションがサポートされている場合は、カスタム・パラメータ、基準またはその両方を作成できます。
たとえば、問合せされた情報を最終レポートでハードコードにしたり、プロンプトを使用してエンド・ユーザーから直接入力を取得するようなタイプのカスタム・パラメータを作成できます。さらに、特定のソート基準を作成すると、最終レポートに含める集計データを戦略的に制限および最適化できます。
選択したフィールドのソート順序を指定し、最終レポート出力をフォーマットします。
最終レポートをプレビューします(オプション)。
レポートを配信メカニズムにチェックインします。
一般に、最終レポートは、Web表示可能ページまたは印刷可能ファイルとしてフォーマットして配信できます。また、外部レポート作成アプリケーションでデータ結果を使用して、棒グラフや円グラフなどの有用なグラフを作成することもできます。
さらに、保存したファイルをMicrosoft ExcelやWordファイルなどの他の製品にインポートすることもできます。
Content Trackerレポートのインストール・プロセス中に、個々のユーザー・ロールおよびアカウント情報を使用して、レポート結果におけるコンテンツ・アイテム情報の表示を制限し、生成されるレポートでユーザーに表示されるコンテンツ・アイテムおよびメタデータを制御できます。ユーザーがコンテンツ・サーバー検索で見つけられなかった内容はContent Trackerレポートでも表示されないようにすることが理想的です。
|
注意: インスタンスに対してアクセス制御リスト(ACL)を有効化している場合、Content Trackerレポートのセキュア・モード・オプションは機能しません。詳細は、第9.5.1.2項を参照してください。 |
Content Trackerレポートのコンポーネントをインストールすると、SctrEnableSecurityChecks構成変数が設定されます。この変数では、セキュア・モードまたは非セキュア・モードのいずれかを使用できます。インストール中に、セキュリティ・チェック・ボックスを選択するかどうかによって、モードを選択します。インストール後は、コンポーネント・マネージャを使用して設定を変更します。
SctrEnableSecurityChecks=Trueの場合、Content Trackerレポートはセキュア・モードで動作します。検索結果を制限するために使用されたものと同じセキュリティ基準(ロールおよびアカウントの制限)が、Content Trackerレポートの問合せおよび生成されるレポートにも適用されます。2つの異なるユーザーが「上位アクセス・コンテンツ・アイテム」レポートを実行した場合、異なる結果が表示されることがあります。false(デフォルト)に設定されている場合、システム管理者以外のユーザーに、アクセスと表示の権限を付与していないコンテンツ・アイテムの情報が表示される可能性があります。
contenttrackerreports_query.htmファイルには、事前定義済レポートおよびカスタム・レポートを生成する「Content Trackerレポートの生成」のすべての問合せが含まれます。非セキュア・モードおよびセキュア・モードをサポートするために、このファイルには2つの問合せセットが含まれます。
|
注意: ローカライゼーションのサポートのために、事前定義済レポート名の「document」という語は「content item」に変更されています。ただし、これまでと同様に、対応するレポート問合せにはWordドキュメントの略語(doc)が含まれます。 たとえば、「上位アクセス・コンテンツ・アイテム」レポートは、「Content Trackerレポートの生成」メイン・ページにリストされる事前定義済レポートです。 qSctrTopDocs(非セキュア・バージョン) qSctrTopDocs_SEC(セキュア・バージョン) |
この項の内容は次のとおりです。
ユーザーが、管理者権限、コントリビュータ権限、ゲスト権限およびシステム・マネージャ権限を持っている(準管理者ユーザー)が、特定のコンテンツ・アイテム(給与レポートなど)を表示するための適切なロールまたはアカウントのメンバーシップを持っていないとします。割り当てられた権限を使用すると、このユーザーは「コンテンツ・サーバー管理者」ページにアクセスでき、「Content Trackerレポートの生成」メイン・ページにアクセスできます。ただし、このユーザーがコンテンツ・サーバーで標準検索を実行した場合、結果ページには給与レポートが存在することは示されません。
セキュリティ・チェック・プリファレンス変数が有効化されている場合、Content Trackerレポートでは、同じロールおよびアカウントのメンバーシップ・チェックが実施されます。次に、特定のレポートをリクエストしたユーザーに応じて、ロールおよびアカウントの照合アクティビティが実行され、対象になるコンテンツ・アイテム使用状況データが決まります。
次の各例に示すように、特定のユーザー(前述の準管理者ユーザー)に対して生成されるレポート結果は、プリファレンス変数が有効化されているかどうかによって異なります。
セキュア・モードの例:
セキュリティ・チェック・プリファレンスが有効化されている場合、Content Trackerレポートはセキュア・モードで実行され、ロールおよびアカウントの一致がチェックされます。この場合、準管理者ユーザーは機密データを取得および表示する資格がありません。このユーザーのロールおよびアカウント権限に関連付けられた制限によって、給与コンテンツ・アイテムは常にまったく表示されません。データはレポート結果に含まれず、ユーザーはデータの存在も認識できません。
非セキュア・モードの例:
セキュリティ・チェック・プリファレンスが無効化されている場合、Content Trackerレポートは非セキュア・モードで実行され、ロールおよびアカウントの一致はチェックされません。この場合、準管理者ユーザーは、給与レポートに対してアクセスまたは表示する資格がなくても、給与コンテンツ・アイテムに関連付けられた機密情報の一部を取得できます。
少なくとも、ユーザーは給与レポートの存在を知り、そのメタデータの一部を表示できます。この状況における危険性は、メタデータに含まれている情報の種類によって異なります。場合によっては、コンテンツ・アイテムが存在することを知るだけでも、重大なセキュリティ違反になることがあります。
|
注意: このようなセキュリティ違反は、準管理者ユーザーにかぎらず発生します。たとえば、権限のないユーザー(つまり、通常は検索結果ページの特定のコンテンツ・アイテムを表示する権限のないユーザー)が「Content Trackerレポートの生成」メイン・ページにアクセスできることがあります。これは、「管理者」ページにアクセスしたり、URLを推測することによって可能になります。この場合、制限されているコンテンツ・アイテムを記述したメタデータの一部を含むレポートがユーザーに表示されます。 |
ほとんどの事前定義済レポート問合せでは、contenttrackerreports_query.htmファイルにセキュア・フォームと非セキュア・フォームの両方が含まれます。問合せの検索結果がユーザー・ロールおよびアカウント権限の影響を受ける可能性がある場合は、非セキュアな問合せのセキュアなバリアントが含められます。セキュリティ・チェック変数が有効化されている場合は、問合せのセキュア・フォームが優先され、対応する非セキュアな問合せにかわって実行されます。
レポート問合せごとにセキュリティ・チェック・プリファレンス変数を選択的に有効化または無効化することはできません。ただし、contenttrackerreports_query.htmファイルをカスタマイズして、セキュアな問合せおよび非セキュアな問合せを管理できます。特定の問合せのセキュア・フォームを削除または名前変更することによって、その問合せのセキュリティ・チェック(アカウント照合)を無効化できます。
事前定義済レポートに加えて、特定のニーズに合わせてカスタマイズした検索問合せに基づくカスタム・レポートを作成できます。カスタム・レポートを作成するだけでなく、レポートにセキュリティ・チェックを選択的に実装することもできます。contenttrackerreports_query.htmファイルに問合せの非セキュア・フォームとセキュア・フォームの両方を含めることができます。
たとえば、両方の問合せフォームを備えたカスタム・レポートを追加できます。非セキュアな問合せの名前がqMyTopTwentyの場合、セキュアな問合せの名前はqMyTopTwenty_SECになります。セキュリティ・チェック・プリファレンス変数が有効化されている場合は、セキュアな問合せ(qMyTopTwenty_SEC)を使用してレポートが生成されます。セキュリティ・チェック・プリファレンス変数が有効化されていない場合は、非セキュアな問合せ(qMyTopTwenty)を使用してレポートが生成されます。
|
注意: カスタム問合せのセキュア・フォームは、 |
ScrtEnableSecurityChecks設定を手動で有効化または無効化する手順は、次のとおりです。
「メイン」メニューから「管理」→「管理サーバー」→「拡張コンポーネント・マネージャ」を選択します。
「拡張コンポーネント・マネージャ」ページの「コンポーネント構成の更新」フィールドで、リストから「Content Trackerレポート」を選択します。
「更新」をクリックします。
「コンポーネント構成の更新」ページのSctWebBeaconIDListプリファレンス・フィールドに、適用可能なWebビーコン・オブジェクトのdDocNameをカンマで区切って入力します。
「更新」をクリックします。
コンテンツ・サーバーを再起動して変更内容を適用します。
Content Trackerレポートでは、リクエストされたレポートを生成するために、適用可能な非セキュアな問合せまたはセキュアな問合せを選択して実行する必要があります。
Content Trackerレポートでは、次のプロセスに基づいてレポート問合せが選択されます。
ユーザーがレポート・リクエストを発行すると、レポート問合せの名前が専用のContent Trackerレポート・サービスに送信されます。
Content Trackerレポート・サービスによって、次のようにしてセキュリティ・チェック設定が実施されます。
セキュリティ・チェック・プリファレンスが無効化されている場合:
Content Trackerレポートは非セキュア・モードで実行され、ロールおよびアカウント照合(ユーザー・ロールおよびアカウント権限の検証)は実行されません。Content Trackerレポート・サービスでは、問合せの非セキュア・バージョンが検索され、リクエストされたレポートの生成に使用されます。レポート問合せのセキュア・バージョンが存在しているかどうかは関係ありません。
非セキュア・モードでは、非セキュアな問合せのみがレポートの生成に使用されます。その結果、ユーザーの各ロールおよびアカウントのメンバーシップに関係なく、すべてのユーザーに同じレポート結果が表示されます。
セキュリティ・チェック・プリファレンスが有効化されている場合:
Content Trackerレポートはセキュア・モードで実行され、ロールおよびアカウント照合(ユーザー・ロールおよびアカウント権限の検証)が実行されます。
処理の開始時:
Content Trackerレポート・サービスによって、発行された問合せ名に接尾辞「_SEC」が付加され、リクエストされた問合せのこのバリアントがcontenttrackerreports_query.htmファイル内で検索されます。
検索時:
問合せのセキュア・フォームが検出されると、リクエストされたレポートの生成にそのフォームが使用されます。
これは、ロールおよびアカウント照合を実施するセキュリティ・チェックが実行され、レポートをリクエストしたユーザーのロールおよびアカウント権限によって問合せ結果が制限されることを意味します。したがって、ユーザーごとに異なるデータ結果を表示できます。
問合せのセキュア・フォームが検出されない場合は、非セキュアな変数が使用されます。
この場合、実際には、セキュリティ・チェック・プリファレンスが無効化されているときと同じ結果になります。これは、ロールおよびアカウント権限は認証されず、コンテンツ・アイテム・データはフィルタ処理されないことを意味します。したがって、レポートに表示される結果はすべてのユーザーについて同じになります。適切な権限のないユーザーに機密情報が表示される可能性もあります。
ユーザーが「ユーザー・タイプ」レポートをリクエストすると、次の処理が実行されます。
レポート問合せ名(qSctrUsersByType)がContent Trackerレポート・サービスに渡されます。
Content Trackerレポート・サービスで、セキュリティ・チェック・プリファレンス変数に基づいてリクエストが評価されます。
セキュリティ・チェックが無効化されている(falseに設定されている)場合、サービスでは、contenttrackerreports_query.htmファイル内でqSctrUsersByType問合せが検索されます。
セキュリティ・チェックが有効化されている(trueに設定されている)場合、サービスでは、問合せ名にセキュリティ接尾辞が追加され(qSctrUsersByType_SEC)、contenttrackerreports_query.htmファイル内でこのバリアントが検索されます。
Content Trackerレポートでは、セキュリティ・チェック・ステータスに応じて、適用可能な問合せを使用して「ユーザー・タイプ別ユーザー」レポートが生成されます。
特定のレポート問合せに対してセキュリティ・チェック(アカウント照合)を無効化または有効化する手順は、次のとおりです。
テキスト・エディタで、必要なファイルを開きます。
IntradocDir/components/ContentTrackerReports/resources/contenttrackerreports_query.htm
無効化する問合せのセキュア・バージョンを検索します。
問合せの名前を変更します。たとえば、qSctrUsersByType_SEC問合せを無効化する場合は、接尾辞「_disabled」を問合せ名に追加します。
qSctrUsersByType_SEC_disabled
問合せの名前を変更すると、Content Trackerレポート・サービスでは、contenttrackerreports_query.htmファイル内にセキュアな問合せを検出できなくなります。かわりに、非セキュア・バージョン(qSctrUsersByType)が使用されます。
|
注意: セキュアな問合せの名前変更は、一時的に問合せを無効化する手段です。後でセキュア・バージョンの問合せを使用するには、元の名前に戻すことによって再有効化できます。セキュア・バージョンの問合せを削除する場合は、セキュア・バージョンの問合せ全体を再作成して再度使用する必要があります。 |
contenttrackerreports_query.htmファイルを保存して閉じます。
コンテンツ・サーバーを再起動して、変更を適用します。
セキュア・モードの場合、Content Trackerレポートでは常にセキュア・フォームの問合せが優先されます。セキュア・フォームの問合せがcontenttrackerreports_query.htmファイル内に見つかると、レポートの生成には、対応する非セキュアな問合せではなくセキュア・フォームの問合せが使用されます。
レポート問合せごとにセキュリティ・チェック・プリファレンス変数を選択的に有効化または無効化することはできません。ただし、contenttrackerreports_query.htmファイルをカスタマイズして、セキュアな問合せおよび非セキュアな問合せを管理することは可能です。
レポート問合せファイルのカスタマイズでは、次の操作を実行します。
特定のレポート問合せに対してセキュリティ・チェック(アカウント照合)を選択的に有効化または無効化します。
1つ以上の非セキュア・カスタム・レポート問合せを作成し、情報のセキュリティ要件に応じて、対応するセキュア・バージョンを選択的に追加します。
非セキュアなレポート問合せのセキュア・バージョンを作成する手順は、次のとおりです。
テキスト・エディタで、contenttrackerreports_query.htmファイルを開きます。
IntradocDir/components/ContentTrackerReports/resources/contenttrackerreports_query.htm
セキュア・バージョンを作成する問合せを検索します。一貫性を維持するために、セキュアな問合せは対応する非セキュア・バージョンの直後に追加してください。
セキュアなSQLレポート問合せを設計します(カスタム・レポート問合せの作成の手順2を参照)。
既存のセキュアな問合せのパターンに従って問合せを調整します。
FROM句にRevisions表を含めます。
WHERE句に%SCTR_SECURITY_CLAUSE%トークンを含めます。このトークンは、Content Trackerレポート・サービスによって挿入されるWHERE句のプレースホルダとして機能します。
既存のセキュアな問合せで確立されているパターンに従って、問合せを完成します。
contenttrackerreports_query.htmファイルを保存して閉じます。
コンテンツ・サーバーを再起動して、変更を適用します。
この項では、Content Trackerレポート機能およびタスクの手順について説明します。
事前定義済レポートまたはカスタム・レポートを生成する手順は、次のとおりです。
「メイン」メニューから「管理」→「Content Trackerレポート」を選択します。
レポート・タイプをクリックします。
該当するフィールドに、検索基準およびフィルタ処理基準を入力します。
「送信」をクリックします。
選択したレポート・タイプが表示されます。
1つ以上のドリルダウン・レポートにアクセスする手順は、次のとおりです。
事前定義済レポートまたはカスタム・レポートを生成します。詳細は、第9.5.4.1項を参照してください。
事前定義済レポートを生成すると、特定の行アイテム結果にアクティブなドリルダウン・レポート・リンクが設定されます。リンクをクリックします。
選択したドリルダウン・レポートが表示されます。
|
注意: レポートに複数レベルのドリルダウン・レポートが含まれる場合があります。たとえば、「上位アクセス・コンテンツ・アイテム」レポートには「DocName」ドリルダウン・レポート・リンクが含まれます。このリンクをクリックすると、選択したコンテンツ・アイテムの適用可能なコンテンツ・アクセスの詳細が表示される別のレポートが生成されます。このレポート内には、さらに2つの使用可能なドリルダウン・レポート(アクセス用とユーザー用)があります。 |
コンテンツ・アイテムの「情報」ページからそのコンテンツ・アイテムのアクセス履歴レポートを生成する手順は、次のとおりです。
コンテンツ・アイテムを検索し、関連付けられた「情報」アイコンをクリックします。
「コンテンツ情報」ページの「グローバル・アクション」リストから、「アクセス履歴レポートの表示」を選択します。
コンテンツ・アクセス・レポートで、「アクセス」をクリックします。
コンテンツ・アクセス・レポートで、「ユーザー」をクリックします。
コンテンツ・アイテムの最新のユーザー別アクセス・レポートが表示されます。
デフォルトでは、1つのコンテンツ・アイテムの複数バージョンのアクセス結果は、コンテンツ・ダッシュボードで個別に表示されます。コンテンツ・ダッシュボード・レポートの個別のアクセス結果ビューを表示する手順は、次のとおりです。
「Content Trackerレポートの生成」メイン・ページから、コンテンツ・アイテム・ベースの問合せレポートを生成します。詳細は、第9.5.4.1項を参照してください。たとえば、「Content Trackerレポートの生成」メイン・ページで「上位アクセス・コンテンツ」オプションを選択して、適用可能なレポートを生成します。
結果レポートからコンテンツ・アイテムを選択し、「DocName」列にリストされているコンテンツ識別番号をクリックします。
選択したコンテンツ・アイテムのコンテンツ・ダッシュボードが表示されます。デフォルトでは、このビューに、選択したコンテンツ・アイテムの中でアクセスされたコンテンツ・アイテムの各リビジョンについてアクセス結果が表示されます。
コンテンツ・ダッシュボード・レポートの結合されたアクセス結果ビューを表示する手順は、次のとおりです。
「Content Trackerレポートの生成」メイン・ページから、コンテンツ・アイテム・ベースの問合せレポートを生成します。詳細は、第9.5.4.1項を参照してください。たとえば、「Content Trackerレポートの生成」メイン・ページで「上位アクセス・コンテンツ」オプションを選択して、適用可能なレポートを生成します。
結果レポートからコンテンツ・アイテムを選択し、「DocName」列にリストされているコンテンツ識別番号をクリックします。
選択したコンテンツ・アイテムのコンテンツ・ダッシュボードで、「すべてのバージョン」をクリックします。
結果のコンテンツ・ダッシュボード・ビューに、両方のバージョンの結合されたアクセス結果が表示されます。
この項では、非セキュアなカスタム・レポート問合せの作成方法を説明する例を示します。この特定の問合せでは、ユーザーとその個人属性がリストされたレポートが生成されます。データは、コンテンツ・サーバーのUsersデータベース表から導出されます。
カスタム・ユーザー・レポートを作成する手順は、次のとおりです。
SQLレポート問合せを設計します。
カスタム・レポート問合せをContent Trackerレポートの問合せファイルに入力します。
IntradocDir/components/ContentTrackerReports/resourcesディレクトリにナビゲートします。テキスト・エディタでcontenttrackerreports_query.htmファイルを開きます。
レポートの表に行を追加します。各行には、3つの列があります。カスタム・レポート名、問合せ文字列および追加の入力パラメータを入力します。
たとえば、問合せファイルの次の部分は、カスタム問合せレポートによってUsersデータベース表のすべての列から情報が抽出され、日付範囲が承認されることを示しています。
<tr>
<td>qSctrCustomUsers</td>
<td>SELECT *
FROM Users
WHERE (SctDateStamp >= ?) AND (SctDateStamp <= ?)
</td><td>
SctFmtFromDate date
SctFmtToDate date
</td>
</tr>
変更を保存します。
「Content Trackerレポートの生成」メイン・ページ・ファイル内に、カスタム・レポートへのリンクを入力します。
IntradocDir/components/ContentTrackerReports/templatesディレクトリにナビゲートします。テキスト・エディタでcontenttrackerreports_main_page.htmファイルを開きます。
属性を入力して、「Content Trackerレポートの生成」メイン・ページにリンクを表示します。
たとえば、メイン・ページ・ファイルの次の部分は、カスタム・レポート・リンクが選択可能なボタンとして表示され、ページ下部付近の「カスタム・レポート」見出しの下にCustom Users Reportリンクとしてリストされることを示しています。
<h4 class=xuiSubheading>Custom Reports</h4>
<table width=80% border=0>
<tr>
<td><span class="tableEntry"><input type="radio" name="radiobutton"
id="sctrCustomUsers" value="qSctrCustomUsers"
onClick="updateDrill(this.value);">
<label for="sctrCustomUsers"><$lc("wwSctrMainPageRLCustomUsers")$>
</label></span>
</td>
</tr>
</table>
変更を保存します。
前述の例のラベルには、ローカライズされた文字列が使用されています。ラベルおよびタイトルに、ハードコードされたテキストではなく、ローカライズされた文字列を使用する場合は、適切な言語ディレクトリの文字列リソースに文字列を追加します。たとえば、英語の文字列リソースを更新する手順は次のとおりです。
IntradocDir/components/ContentTrackerReports/resources/lang/enディレクトリにナビゲートします。ww_strings.htmファイルをテキスト・エディタで開きます。
ファイルで、適切な文字列グループのセクションを検索します。この例では、メイン・ページ・レポート・ラベルのセクションを検索します。
文字列の定義を追加します。次に例を示します。
<@wwSctrMainPageRLCustomUsers=Custom Users@>
変更を保存します。
「Content Trackerレポートの生成」メイン・ページ・ファイルで、drillReportTitle配列に問合せおよびラベルを追加します。
ファイルが開いていない場合は、IntradocDir/components/ContentTrackerReports/templatesディレクトリにナビゲートします。テキスト・エディタでcontenttrackerreports_main_page.htmファイルを開きます。
次に示すように、drillReportTitle配列に要素を追加します。
var drillReportTitle =new Array();
drillReportTitle["qSctrCustomUsers"] ="<$js(url(lc("wwSctrMainPageRLCustomUsers")))$>"
変更を保存します。
ユーザーに条件を求めるには、「Content Trackerレポートの生成」メイン・ページ・ファイルで、drillPromptList配列にプロンプトを追加します。このプロンプトは、ユーザーがレポートを選択した際に、「条件」フィールドに表示されます。
ファイルが開いていない場合は、IntradocDir/components/ContentTrackerReports/templatesディレクトリにナビゲートします。テキスト・エディタでcontenttrackerreports_main_page.htmファイルを開きます。
drillPromptList配列に要素を追加します。次に例を示します。
var drillReportTitle =new Array();
drillPromptList["qSctrCustomUsers"] ="<$lc("wwSctrMainPageDPCustomUsers")$>"
変更を保存します。
必要に応じて、手順0に説明したように、ローカライズされた文字列リソースに文字列を追加します。
Content Trackerレポートのテンプレート・リソース・ファイル内に、フォーマット要件を入力します。
IntradocDir/components/ContentTrackerReports/resourcesディレクトリにナビゲートします。
テキスト・エディタで、contenttrackerreports_template_resource.htmファイルを開きます。
生成されたカスタム・レポートおよびドリルダウン・レポートに使用する表示機能を入力します。
たとえば、テンプレート・リソース・ファイルの次の部分は、レポート・タイトルが文字列変数wwSctrQueryTRTCustomUsersで、ドリルダウン・レポートが「ユーザー別に表示されたコンテンツ・アイテム」レポートに基づくように指定します。
<!-- Custom Template -->
<@dynamichtml qSctrCustomUsers_vars@>
<$reportWidth ="100%"$>
<$title =lc("wwSctrQueryTTContentTrackerReport")$>
<$reportTitle=lc("wwSctrQueryTRTCustomUsers")$>
<$column1Width="35%"$>
<$column0Drill="qSctrDocsSeenByUser_Drill"$>
<@end@>
必要に応じて、手順0に説明したように、ローカライズされた文字列リソースに文字列を追加します。
コンテンツ・サーバーを再起動して、変更を適用します。
