8 Content Trackerの管理

Content TrackerおよびContent Trackerレポートはオプションのコンポーネントで、Content Serverとともに自動的にインストールされます。これらは個別のモジュールですが、有効化すると、連携動作してシステムの使用状況に関する情報を提供します。提供された情報を使用することで、最もアクセス頻度の高いコンテンツ・アイテムや、ユーザーまたは特定グループにとって最も価値の高いコンテンツを判断できます。組織のコンテンツの消費パターンを理解することは、コンテンツ管理を適切に行うために不可欠です。これによって、ユーザーを中心に据えた適切な情報をより効率的に提供することが可能になります。

この項の内容は次のとおりです。

• パフォーマンス最適化機能

• Content Trackerのコンポーネントおよび機能について

• 操作の概要

• データ追跡機能

• レポートの生成

• サービス・コール構成

• 構成およびカスタマイズ

• トラブルシューティング

8.1 パフォーマンス最適化機能

現在のバージョンのContent Trackerには、情報の追跡プロセスが可能なかぎり効率的に実行されるように、いくつかの最適化機能が組み込まれています。これらの機能は、適用可能なインストール・プリファレンス変数を使用して実装されます。さらに、これらの変数のデフォルト値によって、大規模な本番環境で可能なかぎり効率的に機能するようにContent Trackerを構成できます。

注意: デフォルトでは、Content Trackerで収集および記録されるのは、コンテンツ・アクセス・イベントのデータのみです。この処理には、検索などのコンテンツ・アクセス・イベント以外での情報収集や、ユーザー・プロファイルの概要の収集および統合は除外されます。この構成によって、Content Trackerの機能が簡素化され、全体のパフォーマンスが最大になります。 ただし、Content Serverのインストール・プロセス中に、オプションで各種プリファレンス変数に別の値を入力することもできます。最初にデフォルト値を受け入れても、その値は後で手動で変更できます。これは、適用可能な場合、sct.cfgファイルを編集するか(プリファレンス変数を除く)、またはコンポーネント・マネージャの更新機能を使用して行います。「パフォーマンス最適化機能の変数設定の変更」を参照してください。

パフォーマンス最適化機能の内容は、次のとおりです。

• コンテンツ・アクセスのみ: この操作モードにより、収集される情報のタイプが決定します。有効(デフォルト)にすると、コンテンツ・アクセス・イベントのみが記録され、コンテンツ検索やユーザー・プロファイル情報は除外されます。その結果、Content TrackerではSctAccessLog表のみ移入されます(「結合された出力表」を参照)。対応するインストール・プリファレンス変数はSctTrackContentAccessOnlyです。

  
  

  注意: Content Trackerでは、デフォルトで、静的URLのアクセス・イベント詳細がデータ削減プロセスのイベント・ログに収集され、サービスがリアルタイムでログに記録されます。ただし、ログに記録されるのは、コンテンツ・アクセスのイベント・タイプを持つサービスのみです。 例外として、DocHistory表への入力が発生するサービスはすべて追跡されます。これは、サービス(DELETE_REVなど)がContent Trackerサービス表に定義されているかどうかに関係なく行われます(「サービス・コール」および「サービス・コール構成」を参照)。

  
  
  
  

  注意: コンテンツ・アクセスのみモードが「オン」(デフォルト)の場合、「サービス」タブは表示されません。

  
  
  
  

  注意: アクティビティ・スナップショット機能が有効な場合、Content Trackerでは、コンテンツ・アクセスのみ操作モードの設定に関係なく、メタデータ・フィールドが変更されます。これは、データ削減中にユーザー・メタデータ表が移入されることを意味します。

  
  
  
  

  注意: ユーザー・レポートが表示されるのは、コンテンツ・アクセスのみ操作モードが無効な場合のみです。「レポートの生成」を参照してください。

  
  

• 列の除外: これは、Content TrackerでSctAccessLog表に移入されない列のリストです。デフォルトでは、出力表のサイズを削減するために、大規模な情報やほとんど使用しない情報は収集されません。対応するインストール・プリファレンス変数はSctDoNotPopulateAccessLogColumnsです。

• ユーザー・エージェントの簡素化: この機能を有効(デフォルト)にすると、SctAccessLog表のcs_userAgent列に格納される情報が最小限になります。対応するインストール・プリファレンス変数はSctSimplifyUserAgentです。

• アーカイブしない: この機能を有効(デフォルト)にすると、データベース表には最近のデータが格納され、期限切れの表行はアーカイブされずに破棄されます。対応するインストール・プリファレンス変数はSctDoNotArchiveです。

  
  

  注意: この最適化機能は、すべてのContent Trackerデータベース表(SctAccessLog表およびユーザー・メタデータ表)に適用できます。デフォルトでは、SctAccessLog表のみ移入され、期限切れの行はアーカイブされません。ただし、コンテンツ・アクセスのみとアーカイブしないの両方の機能を無効にすると、すべての表が移入され、期限切れデータがアーカイブされます。

  
  

8.2 Content Trackerのコンポーネントおよび機能について

Content Trackerでは、コンテンツ・サーバー・インスタンスのアクティビティが監視され、それらのアクティビティについて選択した詳細が記録されます。さらに、システムで使用している方法を理解する上で役立つレポートが生成されます。この項では、Content TrackerおよびContent Trackerレポートの機能について簡単に概要を説明します。ここでは、コンポーネントの基本的背景について説明し、「操作の概要」で説明する詳細情報を理解するための準備を整えることを目的にしています。

この項の内容は次のとおりです。

• Content Trackerの概要

• Content Trackerレポートの概要

• データ記録の概要

• データ削減の概要

• データ・レポート作成の概要

• Content Trackerの用語

• 一般的な制限事項

• 一般的な考慮事項

8.2.1 Content Trackerの概要

Content Trackerでは、システムが監視され、様々なアクティビティに関する情報が記録されます。この情報は様々なソースから収集され、マージされてコンテンツ・サーバー・データベース内の一連の表に書き込まれます。収集する情報のタイプは、Content Trackerをカスタマイズして変更または拡張できます。

注意: デフォルトでは、Content Trackerで収集および記録されるのは、コンテンツ・アクセス・イベントのデータのみです。この処理には、検索などのコンテンツ・アクセス・イベント以外での情報収集や、ユーザー・プロファイルの概要の収集および統合は除外されます。ただし、管理者は必要に応じて、Content Serverのインストール・プロセス中に、様々なカテゴリからすべての情報を収集するようにContent Trackerを構成することもできます。詳細は、「パフォーマンス最適化機能」を参照してください。

Content Trackerでは、次に基づいてアクティビティが監視されます。

• コンテンツ・アイテム・アクセス: Content Trackerではコンテンツ・アイテムの使用状況に関する情報が収集されます。データは、Webフィルタ・ログ・ファイル、コンテンツ・サーバー・データベース、およびその他の外部アプリケーション(ポータルやWebサイトなど)から取得されます。コンテンツ・アイテム・アクセスのデータには、日付、時刻、コンテンツIDおよび現在のメタデータが含まれます。

• コンテンツ・サーバー・サービス: Content Trackerでは、検索リクエストを処理するサービスとともに、コンテンツを返すすべてのサービスを追跡できます。ただし、Content Trackerでは、デフォルトで、コンテンツ・アクセスのイベント・タイプを持つサービスのみがログに記録されます。またContent Trackerでは、簡単な構成変更により、カスタム・サービスも含めてほとんどすべてのコンテンツ・サーバー・サービスを監視できます。

• ユーザー・アクセス: Content Trackerでは、ユーザー・プロファイルの概要の収集や統合など、コンテンツ・アクセス・イベント以外の他の情報を収集できます。このデータには、ユーザー名およびユーザー・プロファイル情報が含まれます。

8.2.2 Content Trackerレポートの概要

Content Trackerでデータが抽出され、適用可能なデータベース・リポジトリ表に移入されると、その情報を使用してレポートを生成できます。Content Trackerレポートを使用すると、次のことを実行できます。

• レポートの生成: Content Trackerレポートでは、Content Trackerで作成された表を問い合せて、特定のコンテンツ・アイテムの各種アクティビティのサマリー・レポートおよび使用状況履歴が生成されます。これらのレポートを使用すると、コンテンツまたはユーザーの特定グループを、メタデータ、ファイル拡張子またはユーザー・プロファイルに基づいて分析できます。提供されている事前定義済レポートを使用したり、使用するインストールにあわせて事前定義済レポートをカスタマイズしたり、互換性のあるサード・パーティのレポート作成パッケージを使用することができます。

• コンテンツ管理プラクティスの最適化: レポートされたデータを、コンテンツ保存管理に使用することもできます。つまり、特定の間隔における特定のコンテンツ・アイテムのアクセス頻度に応じて、一部のアイテムをアーカイブしたり削除することを決定できます。同様に、アプリケーションではこのデータを使用して、特定タイプのユーザーの上位アクセス・コンテンツをポートレットに提供できます。

8.2.3 データ記録の概要

Content Trackerでは、次のソースからデータが記録されます。

• Webサーバー・フィルタ: コンテンツが静的URLを介してリクエストされると、Webサーバー・フィルタによってリクエストの特定の詳細が記録され、1つ以上のイベント・ログ・ファイルに情報が保存されます。イベント・ログ・ファイルは、情報が収集された日付に従って編成されます。イベント・ログ・ファイルは最終的に、Content Trackerデータ削減プロセスで入力として使用されます。

• サービス・ハンドラ・フィルタ: Content Trackerには、監視対象となるサービスのリストがあります。これには、デフォルトで、コンテンツを返すサービスのみが含まれます。これらのサービスの1つが呼び出されると、そのサービスの詳細がコピーされ、SctAccessLog表に保存されます。監視対象となるサービスおよび記録される詳細は変更できます。

• Content Trackerロギング・サービス: Content Trackerでは、汎用のロギング・サービス(イベントの記録に使用できる単一サービス・コール)がサポートされています。これは、URLを介して直接呼び出すか、サービス・スクリプト内のアクションとして呼び出すか、またはIdocScriptから呼び出すことができます。

• コンテンツ・サーバー・データベース表: ユーザー・プロファイル情報を収集して処理するように構成すると、Content Trackerデータ削減プロセスでは、選択されたコンテンツ・サーバー・データベース表を問い合せます。これは主に、レポート作成期間中にアクティブであったユーザーの名前およびアカウントに関する情報を取得するために行われます。

• アプリケーションAPI: Content Trackerには、他のコンポーネントやアプリケーションを追跡対象として登録できるインタフェースが用意されており、それらのアクティビティに関する情報を記録できます。たとえば、このインタフェースを使用すると、Site Studioなどの協調アプリケーションでイベント情報をリアルタイムで記録できます。

  
  

  注意: アプリケーションAPIは、SctApplicationFilter.hdaファイルに含まれています。このインタフェースは、コンテンツ・サーバー・サービスを使用しないコールをコーディングするためのコードとして設計されています。アプリケーションAPIは、汎用的には使用できません。このインタフェースを使用してアプリケーションを構築する場合は、コンサルティング・サービスにお問い合せください。

  
  

8.2.4 データ削減の概要

データ削減プロセスでは、データ記録ソースから取得されたデータが収集されてマージされます。この削減プロセスが完了するまで、Content Tracker表のデータは完成しません。通常は、毎日の収集データに対して削減を1回実行します。削減は手動で実行するか、または自動的に実行するようにスケジュールでき、通常はシステム負荷が少ないピーク外の時間帯にスケジュールします。

8.2.5 データ・レポート作成の概要

Content Trackerレポートには、コンテンツ・サーバーのアクティビティおよび使用状況に関するよくある質問の答えを示す一連のレポートが用意されています。たとえば、最もアクセス頻度が高い管理対象オブジェクトを特定できます。また、Content Trackerの構成に応じて、これらのレポートから、最も使用頻度が高い検索および最もアクティブなユーザーを特定することもできます。

これらのレポートは、Content Trackerレポートの生成メイン・ページから直接使用したり、コンテンツ情報ページでアクションとして間接的に使用できます。事前定義済レポート・オプションの使用可能なカテゴリは、Content Trackerに構成されている収集対象がコンテンツ・アクセス・イベントのみか、またはすべてのタイプの追跡情報かによって異なります。レポート、基礎となる問合せ、および出力書式はカスタマイズできます。

8.2.6 Content Trackerの用語

Content TrackerおよびContent Trackerレポートを使用する際は、次の用語を理解している必要があります。

• データ収集: プログラムを使用してコンテンツ・アクセス情報を収集し、情報をイベント・ログ・ファイルに書き込むこと。

• データ削減: データ収集からの情報を処理してデータベース表にマージすること。

• データ・エンジン・コントロール・センター: データ・エンジンのユーザー制御機能へのアクセスを提供するアプレット・インタフェース。データ・エンジン・コントロール・センターは、データ収集を有効化、スケジュールおよび監視する場合に使用されます。また、ユーザー・アクティビティおよびサービス・コールに関するデータを収集して管理する場合にも使用されます。

• コレクション: データ収集を有効化するために使用するタブ。

• 削減: データ削減(データをデータベース表内にマージすること)を停止および開始するために使用するタブ。

• スケジュール: 自動データ削減を有効化するために使用するタブ。

• スナップショット: アクティビティ・メトリックを有効化するために使用するタブ。また、スナップショットという語は、過去の特定の時点で存在した状態を表す情報セットを示す場合に使用されます。これは、特定の時点で特定のコンテンツ・アイテムにアクセスしたユーザーを特定する瞬間的な履歴情報です。

• サービス: ログに記録するコンテンツ・サーバー・サービス・コールを追加、構成および編集するために使用するタブ。また、これは、指定されたサービスについてログに記録する具体的なイベント詳細を定義する場合にも使用します。

• サービス定義: サービス・コール構成ファイル(SctServiceFilter.hda)内のResultSet構造で、ログに記録する各コンテンツ・サーバー・サービス・コールを定義するエントリが含まれます。サービス定義ResultSetは、ServiceExtraInfoという名前です。

• ServiceExtraInfo ResultSet: 「サービス定義」を参照。

• サービス・エントリ: ログに記録されるコンテンツ・サーバー・サービス・コールを定義する、サービス定義ResultSet(ServiceExtraInfo)内のエントリ。ServiceExtraInfo ResultSetには、ログに記録されるサービスごとに1つのサービス・エントリが含まれます。

• フィールド・マップ: サービス・コール・データおよび特定のデータ記録場所を定義する、サービス・コール構成ファイル(SctServiceFilter.hda)内の2次的なResultSet。

• 上位アクセス・コンテンツ・アイテム: システム内の最も頻繁にアクセスされているコンテンツ・アイテム。

• コンテンツ・ダッシュボード: 特定のコンテンツ・アイテムのアクセスに関する概要情報が表示されるHTMLページ。

8.2.7 一般的な制限事項

Content Trackerは、ほとんどのハードウェアおよびネットワーク構成でサポートされます。ただし、ハードウェアとソフトウェアの組合せによっては、特別な考慮が必要になります。次のような制限事項がすでに報告されています。

• 静的URLを介して、またはWebDAVによってリクエストされたコンテンツの正確なアクセス数が保証されない場合があります。「静的URLおよびWebDAVに関連する追跡の制限事項」を参照してください。

• アクセス・アクティビティを正常に記録するには、ユーザーのアカウントにContent Trackerのデータ・ディレクトリに対する書込みアクセス権が必要です。そうでない場合、一部のアクセス・リクエストがイベント・ログに記録されません。「追跡の制限事項およびデータ・ディレクトリの保護」を参照してください。

• ExtranetLookコンポーネントを有効化すると、ユーザー・アクセス・リクエストがContent TrackerのRawイベント・ログに記録されない場合があります。「ExtranetLookコンポーネントに関連する追跡の制限事項」を参照してください。

• コンテンツ・サーバー・データベースとしてOracleまたはDB2を使用している場合、メタデータ値は大文字と小文字が区別されます。「OracleおよびDB2の大/小文字の区別」を参照してください。

• コンテンツ・サーバー・インスタンスに対してアクセス制御リスト(ACL)が有効な場合、Content Trackerレポートのセキュア・モードは機能しません。「アクセス制御リストおよびContent Trackerレポートのセキュア・モード」を参照してください。

• コンテンツ・サーバー・データベースとしてOracleを使用している場合、エイリアスを使用して列名を表示するには、追加のカスタマイズ済ファイル構成が必要になります。「カスタム・レポート問合せとOracle」を参照してください。

8.2.8 一般的な考慮事項

現行バージョンのContent TrackerおよびContent Trackerレポートのコンポーネントには、次の一般的な考慮事項が適用されます。

• ブラウザのハング:

  データ・エンジン・コントロール・センターの実行中にコンテンツ・サーバーが終了した場合、ブラウザもハングすることがあります。この問題は、ハングしたブラウザ・ウィンドウを閉じると簡単に解決します。

• ローカル時間とGMT:

  構成パラメータを使用すると、ユーザー・アクセス時間の記録にグリニッジ標準時(GMT)ではなくローカル時間を使用できます。

  • SctUseGMT=trueに設定すると、GMTを使用するようにContent Trackerが構成されます。

  • SctUseGMT=falseに設定すると、ローカル時間を使用するようにContent Trackerが構成されます。これはデフォルトの設定です。

  Content Trackerの新規インストールを実行する場合、SctUseGMTにデフォルト設定を使用すると、ユーザー・アクセスはローカル時間で記録されます。以前のバージョンのContent Trackerをアップグレードする場合、SctUseGMTにデフォルト設定を使用すると、アクセス時間が1回前に戻ります(地域によっては先に進みます)。また、年2回のサマー・タイム実施に対応するために、記録されるユーザー・アクセス時間に中断が生じます(ローカル時間を使用しているかどうか、および地域によって異なります)。

8.3 操作の概要

Content Trackerでは、コンテンツ・アイテムの消費パターンに関する情報が取得されます。アクティビティ情報が毎日収集され、これには、エンド・ユーザーが直接またはポータルやWebサイトなどの外部アプリケーションを介してコンテンツ・サーバーからアクセスしたコンテンツの追跡が含まれます。情報は、コンテンツ・サーバーWebフィルタ・ログ・ファイル、コンテンツ・サーバー・データベース、およびその他の外部アプリケーション(ポータルやWebサイトなど)から収集されます。

データが収集されると、Content Trackerではイベント情報が結合、分析および統合され、要約されたアクティビティがデータベース表にロードされます。削減後に、このデータはレポート作成目的で使用できるようになります。Content Trackerレポートの生成メイン・ページを使用して、コンテンツ使用状況の傾向を示すレポートを生成できます。これはシステムの使用状況の把握に役立つため、コンテンツ管理の向上につながります。

この項の内容は次のとおりです。

• データ収集および処理

• データ収集

• データ削減

• データ出力

• 追跡の制限事項

8.3.1 データ収集および処理

Content Trackerでは、構成に応じて、動的および静的なコンテンツ・アクセスやサービス・コールなどのイベント情報が収集されます。データの収集には、複数のメカニズムが使用されます。

• サービス・ハンドラ・フィルタ: コンテンツ・サーバー・サービス・リクエストが調査され、その中の特定の詳細が直接SctAccessLog表にリアルタイムで書き込まれます。SctServiceFilter.hdaファイルにリストされているサービスのみがログに記録されます。

• Webサーバー・フィルタ: 静的URLからデータ値が収集され、RAWデータ・ファイルに記録されます。

• Content Trackerロギング・サービス: 適切に構成されたアプリケーションによって生成されたイベント情報をログに記録するために使用されます。

この項の内容は次のとおりです。

• 標準的なデータ削減プロセス

• アクティビティ・メトリックを使用するデータ削減プロセス

8.3.1.1 標準的なデータ削減プロセス

データ削減プロセス中に、静的URL情報がRAWデータ・ファイルから抽出され(「Content Trackerイベント・ログ」を参照)、すでにSctAccessLog表に格納されているサービス情報と結合されます(「結合された出力表」を参照)。

注意: Content Trackerでは、デフォルトで、SctAccessLog表のデータのみが収集および記録されます。ユーザー・データ出力表が存在しても、Content Trackerではその出力表に移入されません。「パフォーマンス最適化機能」を参照してください。

Content Trackerの構成に応じて、この削減プロセスでは次の処理が実行されます。

• 静的URLコンテンツ・アクセスのアクセス情報がサービス詳細と結合されます。

• レポート作成期間中にアクティブであったユーザー・アカウントに関する情報が要約されます。この情報はロールアップされ、Content Trackerのユーザー・メタデータ・データベース表に書き込まれます。詳細は、「データ出力」を参照してください。

8.3.1.2 アクティビティ・メトリックを使用するデータ削減プロセス

Content Trackerには、検索関連データを選択的に生成してカスタム・メタデータ・フィールドに格納するためのオプションが用意されています。スナップショット機能を使用すると、アクティブにするアクティビティ・メトリックを選択できます。ログに記録されたデータには、コンテンツ・アイテムの人気度を示すコンテンツ・アイテム使用状況情報が含まれます。

注意: Content Trackerでは、デフォルトで、SctAccessLog表のデータのみが収集および記録されます。スナップショット機能がアクティブでないかぎり、ユーザー・データ出力表が存在しても、Content Trackerではその出力表に移入されません。ただし、スナップショット機能を使用すると、Content Trackerのパフォーマンスに影響します。詳細は、「パフォーマンス最適化機能」を参照してください。

スナップショット機能およびアクティビティ・メトリックをアクティブにした場合は、削減処理フェーズに続いて、カスタム・メタデータ・フィールドの値が更新されます。ユーザーがコンテンツ・アイテムにアクセスすると、適用可能な検索関連メタデータ・フィールドの値がそれに応じて変わります。その後、Content Trackerでは、削減後の手順の中で、適用可能なSQL問合せを使用して、レポート作成期間中にアクセスされたコンテンツ・アイテムが特定されます。

Content Trackerでは、適用可能なデータベース表メタデータ・フィールドが新しい値で更新され、再索引付けサイクルが開始されます。ただし、再索引付けされるのは、アクセス・カウント・メタデータ値が変更されたコンテンツ・アイテムのみです。スナップショット機能、ユーザー・インタフェース画面、およびアクティビティ・メトリックのアクティブ化の詳細は、「「スナップショット」タブ」を参照してください。アクティビティ・メトリックのSQL問合せおよびそのカスタマイズ方法の詳細は、「アクティビティ・メトリックのSQL問合せ」を参照してください。

削減後の処理手順は、次の処理を実行するために必要です。

• 影響を受けるコンテンツ・アイテムごとにアクティビティ・メトリックを処理して表を作成し、割り当てられたカスタム・メタデータ・フィールドにデータをロードします。

• アクティビティ・メトリック値が変更されたコンテンツ・アイテムに対して再索引付けサイクルを開始します。これによって、確実にデータが検索索引に含まれるため、検索結果を選択したり並べ替えるためにアクセスできるようになります。

8.3.2 データ収集

Content Trackerのデータ収集には、静的URL参照およびコンテンツ・サーバー・サービス・コール・イベントからの情報の収集が含まれます。どちらのタイプのデータも、結合された出力表(SctAccessLog)に記録されます。ただし、サービス・コールはリアルタイムでログに挿入されますが、静的URL情報は最初に(手動またはスケジュール実行で)削減プロセスを実行する必要があります。

この項の内容は次のとおりです。

• サービス・ハンドラ・フィルタ

• Webサーバー・フィルタ

• Content Trackerロギング・サービス

8.3.2.1 サービス・ハンドラ・フィルタ

コンテンツ・サーバー・サービス・ハンドラ・フィルタは、Content Trackerの主要なデータ収集メカニズムです。このフィルタによって、Content Trackerは、Webサーバー経由の動的コンテンツ・リクエストに関する情報や、その他のタイプのコンテンツ・サーバー・アクティビティ(アプリケーションからのコールなど)に関する情報を取得できます。サービス・リクエスト詳細は、サービス・コールに付随するDataBinderから取得され、情報は結合された出力表(SctAccessLog)にリアルタイムで格納されます。SctAccessLog表の詳細は、「結合された出力表」を参照してください。

ログに記録するコンテンツ・サーバー・サービス・コールを指定するために使用する、ユーザーが変更可能な構成ファイルがあります。このファイル(SctServiceFilter.hda)では、ログに記録されるサービスごとにサービス定義エントリが1つずつ含まれるResultSet構造が使用されています。拡張されたサービス・ロギング機能を使用している場合、SctServiceFilter.hdaファイルには、様々なサービス定義エントリに対応するフィールド・マップも含まれます(「「サービス」タブ」を参照)。サービス・ハンドラ・フィルタを使用してサービス・コールを構成する方法の詳細は、「サービス・コール構成」を参照してください。

SctServiceFilter.hdaファイルに含まれるResultSetの名前は、ServiceExtraInfoです。このResultSetには、ログに記録されるサービスを定義する1つ以上のサービス・エントリが含まれます。拡張されたサービス・ロギング機能をサポートするために、追加のResultSetが使用されます。これらは、フィールド・マップResultSetと呼ばれます。追加のデータ値を追跡するサービスごとに、SctServiceFilter.hdaファイル内には、対応するフィールド・マップResultSetが存在する必要があります。フィールド・マップResultSetによって、関連するサービスのデータ・フィールド、場所およびデータベース宛先列が定義されます。

8.3.2.2 Webサーバー・フィルタ

静的URLを介して取得された管理対象コンテンツは、通常、コンテンツ・サーバー・サービスを起動しません。したがって、Content TrackerのWebサーバー・フィルタによってアクセス・イベント詳細(静的URL参照)が収集され、RAWイベント・ログ(sctlogファイル)に記録されます。これらのファイル内の情報は、結合された出力表(SctAccessLog)にサービス・コール・データとともに挿入される前に、明示的な削減を(対話式またはスケジュール実行で)実行する必要があります。

sctlogファイルの詳細は、「Content Trackerイベント・ログ」を参照してください。SctAccessLog表の詳細は、「結合された出力表」を参照してください。

8.3.2.3 Content Trackerロギング・サービス

Content Trackerロギング・サービスは、URLを介して直接、またはサービス・スクリプト内のアクションとして呼び出すことができる単一サービス・コールです。また、executeService()関数を使用して、IdocScriptから呼び出すこともできます。呼出し元アプリケーションによって、記録する必要のある付随のサービスDataBinder内のすべてのフィールドが設定され、これには、Content Trackerサービス・フィルタ構成ファイル(SctServiceFilter.hda)にリストされている記述フィールドが含まれます。Content Trackerロギング・サービスを使用してサービス・コールを構成する方法の詳細は、「サービス・コール構成」を参照してください。

注意: サービス・ハンドラ・フィルタを介して記録されるサービスと、Content Trackerロギング・サービスを介して記録されるサービスとの間に、重複や競合はないはずです。サービスの名前がContent Trackerサービス・ハンドラ・フィルタ・ファイルに指定されている場合、それらのサービスは自動的にログに記録されるため、Content Trackerロギング・サービスによる記録は不要です。ただし、Content Trackerでは、このような重複を回避する処理は行われません。

8.3.3 データ削減

Content Trackerデータ削減中に、Webサーバー・フィルタによって取得された静的URL情報がサービス・コール・データとともにマージされ、出力表(SctAccessLog)に書き込まれます。削減時には、Content Trackerの構成に応じて、Content Trackerユーザー・メタデータ・データベース表が、静的URLアクセスから収集された情報、およびレポート作成期間中に収集されたサービス・コール・イベント・レコードから収集された情報で更新されます。

この項の内容は次のとおりです。

• Content Trackerイベント・ログ

• 結合された出力表

8.3.3.1 Content Trackerイベント・ログ

Content TrackerのWebサーバー・フィルタによってアクセス・イベント詳細(静的URL参照)が収集されると、情報がRAWイベント・ログ(sctLogファイル)に記録されます。これらのファイル内の情報は、結合された出力表(SctAccessLog)にサービス・コール・データとともに挿入される前に、明示的な削減を(対話式またはスケジュール実行で)実行する必要があります。

Content Trackerでは、様々なイベント・ログ・タイプ、および複数のWebサーバーを含む構成に対応するために、複数の入力ファイルがサポートされています。このため、各Webサーバー・フィルタ・インスタンスでは、Content Trackerイベント・ログ用のファイル名接尾辞として固有のタグが使用されます。固有の識別接尾辞は、Webサーバー・ホスト名とサーバー・ポート番号で構成されます。削減プロセスでは、sctLog-yyyymmdd-<myhostmyport>.txtという名前の複数のRAWイベント・ログが検索されてマージされます。RAWイベント・ログは、個別に処理されます。

この項の内容は次のとおりです。

• コンテンツ・アクセス・エントリ内に記録されるユーザー名

• データ削減後のファイル・ストレージ

8.3.3.1.1 コンテンツ・アクセス・エントリ内に記録されるユーザー名

RAWイベント・ログ・エントリを調べると、ユーザーがコンテンツ・サーバーにログインしていても、Content Trackerでコンテンツ・アクセス・イベントのユーザー名が取得されていない場合があります。たとえば、ログインしているユーザーが検索を実行し、アイテムのコンテンツ情報を表示し、Webロケーション・リンクをクリックしたとします。RAWイベント・ログ・エントリには、ユーザー名を除く情報が含まれます。

この場合、アイテムは静的URLリクエストを介してアクセスされており、通常、Webサーバーによってユーザーの資格証明の送信を要求されないかぎり、ブラウザにユーザー名は表示されません。特に、アイテムがパブリック・コンテンツの場合、Webサーバーはユーザーの資格証明の送信をブラウザに要求しないため、URLにアクセスするユーザーは不明となります。

Content Trackerですべてのドキュメント・アクセスについてユーザー名を記録するには、すべてのコンテンツ・アイテム・アクセスに対してユーザー・ログインを求めるようにシステムを構成する必要があります。このためには、コンテンツをゲスト・ロールに対してアクセス不可能にしておく必要があります。つまり、コンテンツがパブリックでない場合、アイテムにアクセスするにはユーザーの資格証明が必要になります。これによって、確実にユーザー名がRAWイベント・ログ・エントリに記録されます。

8.3.3.1.2 データ削減後のファイル・ストレージ

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)がタイムスタンプ・ファイルとして生成されます。RAWデータ・ファイル処理での削減サイクル状態の詳細は、「「削減」タブ」を参照してください。

8.3.3.2 結合された出力表

SctAccessLog表には、静的および動的なすべてのコンテンツ・アクセス・イベント・レコードのエントリが含まれます。SctAccessLog表は、レポート作成期間中のイベントごとに1行ずつ使用して編成されます。表の列には、タイプに従ってタグが付けられます。

• Sは、サービス・コールについて記録されたレコードを表します。

• Wは、静的URLリクエストについて記録されたレコードを表します。

この項の内容は次のとおりです。

• SctAccessLogのエントリのファイル・タイプ

• SctAccessLogのエントリについて収集されるURL

• SctAccessLogのエントリについて収集される情報

8.3.3.2.1 SctAccessLogのエントリのファイル・タイプ

デフォルトでは、Content TrackerによってGIF、JPG、JS、CSS、CABおよびCLASSファイル・タイプへのアクセスはログに記録されません。これは、GIF、JPG、JS、CSS、CABおよびCLASSが関連するWebアクティビティは、Webサーバー・フィルタのイベント・ログ・ファイルのエントリにならないことを意味します。したがって、これらのファイル・タイプのエントリは、データ削減後、結合された出力表(SctAccessLog)に挿入されません。

これらのファイル・タイプのロギング・ステータスを変更するには、IntradocDir/custom/ContentTracker/resources/ディレクトリにあるsct.cfgファイル内で目的のファイル・タイプを有効化する必要があります。これらのファイル・タイプのロギングを有効化するには、SctIgnoreFileTypes構成変数(gif、jpg、js、css)のデフォルト設定を調整してください。デフォルト設定では、これらのファイル・タイプは除外されます。これらのファイル・タイプの一部のみを含めるには、リストから目的の各ファイル・タイプを削除します。この変更を有効にするには、Webサーバーおよびコンテンツ・サーバーを再起動する必要があります。

構成変数およびsct.cfgファイルの詳細は、「構成変数」を参照してください。

8.3.3.2.2 SctAccessLogのエントリについて収集されるURL

Content TrackerのWebサーバー・フィルタでは、ユーザー・コンテンツのURLと、コンテンツ・サーバー・ユーザー・インタフェースによって使用されるURLを区別できません。このため、client.cabなどのUIオブジェクトへの参照が静的アクセス・ログ内に含まれることがあります。このような誤検出を防ぐために、Content Trackerフィルタで無視されるディレクトリ・ルートのリストを定義できます。

ディレクトリのリストは、<cs_root>/data/contenttracker/config/ディレクトリにあるsct.cfgファイル内のSctIgnoreDirectories構成変数に格納されています。このリストによって、ユーザー・インタフェース・オブジェクト参照のほとんどが排除されます。「構成変数」を参照してください。

SctIgnoreDirectories値の内容を手動で変更して、コンテンツを無視する必要があるすべてのディレクトリをリストできます。次の場合は、デフォルト値を変更する必要があります。

• ユーザー・コンテンツとともにログに記録するUIオブジェクトにアクセスする場合

• ログに記録するディレクトリ、およびログから除外するディレクトリを変更する場合

8.3.3.2.3 SctAccessLogのエントリについて収集される情報

次の表では、SctAccessLog表の各レコードについて収集される情報について説明します。

注意: Content Trackerでは、デフォルトで、大規模なアイテムやほとんど使用しないアイテム(cs_referrer、cs_cookieなど)のデータは収集されず、それらの列は移入されません。これにより、最適なパフォーマンスが確保されます。詳細は、「パフォーマンス最適化機能」を参照してください。

列名	タイプ/サイズ	列の定義
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]	問合せの一部("IdcService=GET_FILE&dID=42..."など)
cs_host	varchar / 255	コンテンツ・サーバーのサービス名
cs_userAgent	varchar / 255	クライアント・ユーザー・エージェントのID デフォルトでは、この列には「browser」、または「java:」で始まる文字列の接尾辞が含まれます。この簡略化によって、Content Trackerの最適なパフォーマンスが確保されます。
cs_cookie	varchar / [maxUrlLen]	現在のCookie
cs_referer	varchar / [maxUrlLen]	このリクエストに至るURI
sc_scs_dID	int / 8	dID データ・ソース: 問合せから、またはURLから導出(逆引き参照)
sc_scs_dUser	varchar / 50	dUser データ・ソース: サービスDataBinder「dUser」
sc_scs_idcService	varchar / 255	IdcServiceの名前(GET_FILEなど) データソース: 問合せまたはサービスDataBinder「IdcService」
sc_scs_dDocName	varchar / 30	dDocName データ・ソース: 問合せまたはサービスDataBinder「dDocName」
sc_scs_callingProduct	varchar / 255	任意の識別子 データソース: SctServiceFilter構成ファイルまたはサービスDataBinder「sctCallingProduct」
sc_scs_eventType	varchar / 255	任意の識別子 データソース: SctServiceFilter構成ファイルまたはサービスDataBinder「sctEventType」
sc_scs_status	varchar / 10	サービス実行ステータス データ・ソース: サービスDataBinder「StatusCode」
sc_scs_reference	varchar / 255	「web」、「native」、「sdc_url」 値はアクセスされるファイルのレンディションを表します(「web」は変換済ファイル(PDF)、「native」は実際の元ファイル、および「sdc_url」はHTML)。 データソース: アルゴリズムを使用した問合せパラメータまたはServiceFilter構成ファイル
comp_username	varchar / 50	計算されたユーザー名。サービスの場合、UserDataサービス・オブジェクトから取得するか、あるいはHTTP_INTERNETUSER、REMOTE_USERまたはdUserです。静的URLの場合は、認可ユーザーまたはインターネット・ユーザーから取得されます。
comp_validRef	char / 1	アクセスがWeb参照(W)であった場合、ispromptloginとisaccessdeniedの両方がNULLで、削減時に静的URLが存在していれば「1」です。アクセスがサービス・コール(S)で、sc_scs_statusフィールドがNULLの場合も同様です。 削減時に静的URLが存在していなかった場合、ユーザー・ログオンが失敗した場合、またはログオンは成功したがユーザーにオブジェクトの表示権限がなかった場合は「NULL」です。 参照されるオブジェクトが存在するかどうか、およびリクエスト・ユーザーに対して使用可能かどうかを示します。
sc_scs_isPrompt	char / 1	trueの場合は「1」 データソース: プラグインimmediateResponseEventフィールド「ispromptlogin」
sc_scs_isAccessDenied	char / 1	trueの場合は「1」 データソース: プラグインimmediateResponseEventフィールド「isaccessdenied」
sc_scs_inetUser	varchar / 50	インターネット・ユーザー名(セキュリティ問題の場合) データソース: プラグインimmediateResponseEventフィールド「internetuser」
sc_scs_authUser	varchar / 50	認可ユーザー名(セキュリティ問題の場合) データソース: プラグインimmediateResponseEventフィールド「auth-user」
sc_scs_inetPassword	varchar / 8	インターネット・パスワード(セキュリティ問題の場合) データソース: プラグインimmediateResponseEventフィールド「internetpassword」
sc_scs_serviceMsg	varchar / 255	コンテンツ・サーバー・サービス完了ステータス データ・ソース: サービスDataBinder「StatusMessage」
extField_1からextField_10	varchar / 255	拡張されたサービス・トラッキング機能で使用する汎用目的の列。フィールド・マップResultSet内では、DataBinderフィールドがこれらの列にマップされます。

8.3.4 データ出力

Content Trackerでは、静的URLアクセスのスナップショットが作成され、サービス・コールがログに記録されて、結合された出力表にリアルタイムで書き込まれます。静的URL情報を処理して、結合された出力表に追加するには、データ削減が必要です。Content Trackerの構成に応じて、データ削減プロセスにより、関連するユーザー・メタデータ・データベース表が、静的URLデータおよびサービス・コール・データの処理から導出された情報で更新されます。

さらに、Content Trackerが適切に構成されている場合は、静的および動的なコンテンツ・アクセス・リクエスト情報に加えて、すべてのメタデータ・フィールドが、Content Trackerレポート・コンポーネントによって生成されるレポートで使用できるようにアクセス可能になります。ログに記録されるメタデータには、コンテンツ・アイテムおよびユーザー・メタデータが含まれます。

この項の内容は次のとおりです。

• コンテンツ・アイテム・メタデータ

• ユーザー・メタデータ

• 削減ログ・ファイル

8.3.4.1 コンテンツ・アイテム・メタデータ

Content Trackerでは、コンテンツ・アイテム・メタデータ情報は収集されず、コンテンツ・アイテム・メタデータ用の標準のコンテンツ・サーバー・メタデータ表が使用されます。これは、Content Trackerレポートが必然的に現在のコンテンツ・アイテム・メタデータを反映することを意味します。したがって、コンテンツ・アイテムがアクセスされた後にコンテンツ・アイテム・メタデータが変更された場合、生成されるレポートは変更済のメタデータを反映します。

8.3.4.2 ユーザー・メタデータ

Content Trackerでは、適切に構成されている場合、データ削減プロセス中にユーザー・プロファイルの概要が収集および統合されます。このため、Content Trackerユーザー・メタデータ・データベース表は、レポート作成期間中にアクティブであったユーザーに関して収集された情報で更新されます。これらの表には、ユーザー・メタデータが正確な履歴順に保持されます。ユーザー・メタデータ表の名前は、ルート(含まれている情報のクラスを示す)、およびContent Tracker表とネイティブのコンテンツ・サーバー表を区別するための接頭辞「Sct」で構成されます。

注意: デフォルトでは、Content Trackerでデータはアーカイブされません。これは、Content Trackerでは期限切れの行をプライマリ表からアーカイブ表に移動しないことを意味します。かわりに、期限切れの行が破棄されて最適なパフォーマンスが確保されます。詳細は、「パフォーマンス最適化機能」を参照してください。

ユーザー・メタデータ・データベース表の2つの完全セットが作成されます。

• プライマリ

  プライマリ表(SctUserInfoなど)には、「新規」および「最新」サイクルにおける削減データの出力が含まれます。

• アーカイブ

  アーカイブ表(SctUserInfoArchiveなど)には、「アーカイブ」サイクルにおける削減データの出力が含まれます。

削減データ・ファイルが「最新」から「アーカイブ」に移行すると、関連付けられた表レコードがプライマリ表からアーカイブ表に移動します。これにより、プライマリ表に余分な行が構築されることがなく、最新データに対して実行された問合せは短時間で完了します。アーカイブ表の行は削除されません。これらは、履歴レコード用の代替ストレージに移動したり、SQL問合せツールを使用して削除できます。削減プロセスおよびデータ・サイクルの詳細は、「「削減」タブ」を参照してください。

ヒント: アーカイブ表のすべての行を削除する場合は、単に表自体を削除します。これらは、コンテンツ・サーバーが次に再起動されるときに再作成されます。

レポートは、アーカイブ・データに対しては実行されません。したがって、「最新」から「アーカイブ」に移行したデータは、生成されるレポートに含まれません。

この項の内容は次のとおりです。

• SctAccounts表

• SctGroups表

• SctUserAccounts表

• SctUserGroups表

• SctUserInfo表

8.3.4.2.1 SctAccounts表

SctAccounts表には、すべてのアカウントのリストが含まれます。SctAccounts表は、アカウントごとに1行ずつ使用して編成されます。

フィールド名	タイプ/サイズ/フィールド定義
SctDateStamp	datetime データが収集されたGMT日付
dDocAccount	varchar / 30 コンテンツ・サーバー・アカウントの名前

8.3.4.2.2 SctGroups表

SctGroups表には、削減時のすべての現行ユーザー・グループのリストが含まれます。SctGroups表は、コンテンツ・アイテム・グループごとに1行ずつ使用して編成されます。

フィールド名	タイプ/サイズ/フィールド定義
SctDateStamp	datetime データが収集されたGMT日付
dGroupName	varchar / 30 コンテンツ・アイテム・グループの名前

8.3.4.2.3 SctUserAccounts表

SctUserAccounts表には、SctUserInfo表にリストされていて、かつ現行インスタンス内で定義されているアカウントを割り当てられた全ユーザーのエントリが含まれます。ユーザーとアカウントの組合せごとに、個別のエントリが存在します。

Content Trackerによってユーザーのグループおよびアカウント情報が判別されない特殊な状況があります。これは、複数のプロキシ・インスタンスが存在するプロキシ構成において発生します。現行インスタンスがプロキシの場合、別のプロキシで定義されているアクティブ・ユーザーのグループ情報が、そのユーザーのSctUserGroups内の単一プレースホルダ行で置換されます。この行には、ユーザー名と、グループの「-」プレースホルダが含まれます。現行インスタンス内で少なくとも1つのアカウントが定義されている場合は、別のプロキシで定義されているユーザーのSctUserAccounts内に同様のエントリが作成されます。

SctUserAccount表は、コンテンツ・サーバー・ユーザーおよびユーザーのアカウントごとに1行ずつ使用して編成されます。

フィールド名	タイプ/サイズ/フィールド定義
SctDateStamp	datetime データが収集されたGMT日付
dUserName	varchar / 100 ユーザー名です。プロキシ・インスタンスに対してローカルの場合は、コンテンツ・サーバーの相対URLが接頭辞として付加されます(例: cs_2/user1)。
Account	varchar / 30 ユーザーにアクセス権があるアカウントの名前です。現行プロキシ・インスタンスに少なくとも1つのアカウントが存在する場合は、複数のプロキシを経由する構成におけるプレースホルダです。

8.3.4.2.4 SctUserGroups表

SctUserGroups表は、データ収集期間中にログオンしたユーザーのみを参照します。Content Trackerがプロキシ・コンテンツ・サーバー構成で実行されている場合は、現行インスタンス内で定義されているグループのみがリストされます。たとえば、「joe」という名前のユーザーがマスター・インスタンスで定義され、そのユーザーにはマスター・インスタンス内のグループ「Public」および「Plastics」へのアクセス権があるとします。「joe」がプロキシ・インスタンスにログオンし、そのプロキシ内にグループ「Plastics」が定義されていない場合、SctUserGroupsには「joe」と「Public」の関連のみが示されます。

SctUserGroups表は、レポート作成期間中にアクティブな各ユーザーのユーザー・グループごとに1行ずつ使用して編成されます。

フィールド名	タイプ/サイズ/フィールド定義
SctDateStamp	datetime データが収集されたGMT日付
dUserName	varchar / 100 ユーザー名です。プロキシ・インスタンスに対してローカルの場合は、コンテンツ・サーバーの相対URLが接頭辞として付加されます(例: cs_2/user1)。
dGroupName	varchar / 30 ユーザーにアクセス権があるグループの名前です。アクセスのタイプ(R、RWなど)は区別されません。

8.3.4.2.5 SctUserInfo表

SctUserInfo表には、現行インスタンスに既知のすべてのユーザー、およびデータ収集期間中に現行インスタンスにログオンした別のインスタンスからの追加ユーザーが含まれます。プロキシ構成においては、あるインスタンスに対してローカルなユーザーは、通常、他のインスタンスに対して既知(UserAdminアプリケーションから可視)となります。(この可視性を実現するには、通常、ローカル・ユーザーを追加した後にコンテンツ・サーバー・インスタンスを再起動する必要があります。)ただし、同じユーザーが2つのインスタンスに同名でローカルに定義されている場合、各インスタンスではローカル・ユーザーのみが可視になります。

たとえば、マスターで定義されているユーザー「sysadmin」は、プロキシのUserAdminアプリケーションで表示される「sysadmin」ユーザーとは異なります。プロキシには、独自の「sysadmin」ユーザーがローカルに定義されています。この2つの異なるユーザーが両方とも同じデータ収集期間中にログオンすることも考えられます(たとえば、マスターからのユーザーが「sysadmin」としてログオンし、プロキシからのユーザーが「cs_2/sysadmin」としてログオンするような場合)。この場合、cs_2/がプロキシ・ユーザー名に付加する必要のあるサーバー相対URLです。この期間について生成されるSctUserInfoファイルには、「sysadmin」と「cs_2/sysadmin」に対する別々のエントリが記載されます。

SctUserInfo表は、コンテンツ・サーバー・ユーザーごとに1行ずつ使用して編成されます。

フィールド名	タイプ/サイズ/フィールド定義
SctDateStamp	datetime データが収集されたGMT日付
dUserName	varchar / 100 ユーザー名です。プロキシ・インスタンスに対してローカルの場合は、コンテンツ・サーバーの相対URLが接頭辞として付加されます(例: cs_2/user1)。
dUserType	varchar / 30 ユーザーのタイプです。ユーザーにタイプがない場合はプレースホルダです。

8.3.4.3 削減ログ・ファイル

データ削減が実行されると、Content Trackerデータ・エンジンによって、<cs_root>/data/contenttracker/log/内にサマリー結果ログ・ファイルが生成されます。削減ログ・ファイルは、reduction-yyyymmdd.logというフォーマットを使用して名前が付けられます。削減ログは、データ削減プロセス中に発生したエラーを診断する際に役立ちます。RAWイベント・ログ・ファイルおよびそれらに対応する削減ログの詳細は、「Content Trackerイベント・ログ」を参照してください。

8.3.5 追跡の制限事項

現行バージョンのContent TrackerおよびContent Trackerレポートには、追跡に関する既知の制限事項があります。

この項の内容は次のとおりです。

• 静的URLおよびWebDAVに関連する追跡の制限事項

• 追跡の制限事項およびデータ・ディレクトリの保護

• ExtranetLookコンポーネントに関連する追跡の制限事項

8.3.5.1 静的URLおよびWebDAVに関連する追跡の制限事項

Content Trackerでは、静的URLを介して、またはWebDAVクライアントによってリクエストされたコンテンツについて、正確なアクセス・カウントを保証できません。Content Trackerによって判別されたアクセス・カウントは通常は正確ですが、コンテンツが実際にリクエスト・ユーザーに配信されたかどうか、または配信された場合にコンテンツの特定のリビジョンが配信されたかどうかをTrackerで判別できない例外的な状況もあります。この項では、アクセス・カウントが正確でなくなる状況について説明します。

この項の内容は次のとおりです。

• WebDAV経由で繰返しリクエストされたコンテンツのアクセス・カウントの欠落

• 保存済(失効)静的URLによるアクセスの誤検出

• 保存済の静的URLによるアクセスについて報告される間違ったdID

8.3.5.1.1 WebDAV経由で繰返しリクエストされたコンテンツのアクセス・カウントの欠落

シナリオ: ユーザーがWebDAVクライアント経由でドキュメントにアクセスした後、同じ方法で同じドキュメントにアクセスします。記録されるのは、ドキュメントに対する最初のWebDAVリクエストのみです。このようなコンテンツについて報告されるアクセス・カウントは、実際よりも少なくなる傾向があります。

詳細: WebDAVクライアントは通常、ネットワーク・トラフィックの量を減らすためになんらかの形態のオブジェクト・キャッシングを使用します。ユーザーが特定のオブジェクトをリクエストすると、クライアントは最初に、ローカル・ストア内にオブジェクトのコピーが存在しているかどうかを判別します。存在していない場合、クライアントはサーバーに接続し、転送をネゴシエートします。この転送は、COLLECTION_GET_FILEサービス・リクエストとして記録されます。

クライアントにすでにオブジェクトのコピーが存在する場合、クライアントはサーバーに接続して、クライアント・ローカル・コピーが取得された後にオブジェクトが変更されたかどうかを判別します。変更されている場合は、新しいコピーが転送され、COLLECTION_GET_FILEサービス詳細が記録されます。

クライアントのオブジェクト・コピーが現行のままである場合、転送は行われず、クライアントは保存済のオブジェクト・コピーをユーザーに表示します。この場合、ユーザーが元のコンテンツの新しいコピーを取得したようにみえても、コンテンツ・アクセスはカウントされません。

8.3.5.1.2 保存済(失効)静的URLによるアクセスの誤検出

シナリオ: ユーザーがコンテンツ・ファイルの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ロケーションは、DomainHome/ucm/cs/groups/public/documents/adacct/xyzzy.docから

DomainHome/ucm/cs/groups/public/documents/adacct/xyzzy.xmlに変更されます。

ここで、xyzzyは割り当てられたコンテンツIDです。

元のリビジョンは、DomainHome/ucm/cs/groups/public/documents/adacct/xyzzy~1.docに名前変更されます。

これは、元のWebロケーションは静的URLとして機能しなくなることを意味します。ただし、元のURLから取得されたコンテンツIDは最新リビジョンと一致します。したがって、Webサーバーがリクエストされたファイルをユーザーに配信できなかった場合でも、Content TrackerではこれがコンテンツID「xyzzy」へのアクセスとして報告されます。

8.3.5.1.3 保存済の静的URLによるアクセスについて報告される間違ったdID

シナリオ: ユーザーが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リビジョンがユーザーに表示されたと報告されます。

8.3.5.2 追跡の制限事項およびデータ・ディレクトリの保護

Content TrackerのWebサーバー・フィルタは、アクセス・リクエストが処理されているユーザーの認可コンテキスト内で実行されます。リクエスト処理スレッドの所有者は、システム・アカウントである場合があります。そうでない場合、これはリクエスト・ユーザーか、またはアプリケーションで使用されるシステム以外の別のタイプのアカウントです。いずれの場合も、リクエスト・ユーザーまたはシステムに関連付けられたアカウントによって、Webサーバー・フィルタを最終的に付与する権限が決定されます。

Webサーバー・フィルタによってアクセス・イベント詳細が収集され、情報がRAWイベント・ログ(Content Trackerのデータ・ディレクトリ内にあるsctlogファイル)に記録されます。アクセス・イベントが発生したときに既存のsctlogファイルが存在しない場合、Content Trackerでは、このファイルが作成され、イベント・スレッドを所有するユーザーの保護および認可のデフォルト資格証明が使用されます。また、アクセスするユーザー・アカウントにデータ・ディレクトリに対する書込み権限がある場合は、コンテンツ・アクセス・データがsctlogファイルに記録されます。そうでない場合、ログへのリクエストの記録は失敗し、アクセス・イベント詳細は記録されません。

Content Trackerでユーザー・アクセス・リクエストを適切に記録するには、すべてのユーザーについてアカウント認可の資格照明を受け入れるようにデータ・ディレクトリを構成する必要があります。1つの方法は、すべてのユーザーに書込み権限(または同等の権限)を付与することです。アクセス権限を無制限に付与できる状況でない場合を除いて、Content Trackerのデータ・ディレクトリに対しては、可能なすべてのユーザーに無制限の書込みアクセス権を付与することをお薦めします。

8.3.5.3 ExtranetLookコンポーネントに関連する追跡の制限事項

ExtranetLookコンポーネントを使用すると、Cookieベースのログイン形式とページを匿名タイプのユーザー向けにカスタマイズできます。このコンポーネントでは組込みのWebサーバー・プラグインを使用して、リクエストを監視し、リクエストがCookie設定に基づいて認証されているかどうかを判別します。ユーザーがコンテンツ・アイテムへのアクセスをリクエストした場合、Content Trackerはそのユーザーのアカウントの認可コンテキスト内で機能する必要があります。

アクセス情報が収集された後に、Content Trackerではイベント・データをsctlogファイルに記録しようとします。ユーザーのアカウントにContent Trackerのデータ・ディレクトリにアクセスする権限がある場合、リクエスト・アクティビティはsctlogファイルに記録されます。ただし、アカウントに書込み認可がない場合、ログへのリクエストの記録は失敗し、リクエスト・アクティビティは記録されません。

Content Trackerのデータ・ディレクトリに対するアクセス権の詳細は、「追跡の制限事項およびデータ・ディレクトリの保護」を参照してください。

8.4 データ追跡機能

この項の内容は次のとおりです。

• データ削減機能

• アクティビティ・スナップショット

• サービス・コール

• Webビーコン・オブジェクト

• Content Trackerの使用

8.4.1 データ削減機能

データ削減プロセス中に、特定の日付について蓄積されたすべてのRAWデータが収集およびマージされ、完全な情報が作成されます。この項では、データ削減の主要な概念について説明します。

注意: デフォルトでは、Content Trackerは効率が最大になるように構成されます。これはパフォーマンス最適化機能を使用して行われ、Content Serverのインストール・プロセス中に設定されます。したがって、データ削減プロセスの一部は、これらの変数設定の影響を直接受けます。

この項の内容は次のとおりです。

• データ削減サイクル

• アクセス・モードおよびデータ削減

• イベント・ログの削減順序

• 削減スケジュール

8.4.1.1 データ削減サイクル

削減された表データは、関連付けられたRAWデータが「最新」ステータスから「アーカイブ」ステータスに移行すると、プライマリ表から対応するアーカイブ表に移動します。プライマリ表には「新規」サイクルおよび「最新」サイクルにおける削減データの出力が含まれ、アーカイブ表には「アーカイブ」サイクルにおける削減データの出力が含まれます。

データが削減されて1日経過すると、RAWデータは「新規」から「最新」に移行します。このように、「新規」サイクルは、データが現在の日付のものであり、以前の日付から削減されていないことを示しています。「最新」サイクルは、データが前日以前のものであり、すでに削減されていることを示します。

「最新」セットの数が構成済のしきい値に達した場合、手動またはスケジューラによって削減プロセスが実行されると、RAWデータは「アーカイブ」に移行します(また、SctAccessLog表の対応する行がSctAccessLogArchive表に移動します)。「最新」セットのしきい値の構成方法の詳細は、sct.cfg表のSctMaxRecentCount構成変数を参照してください。「構成変数」を参照してください。削減プロセスが実行されていない場合、RAWデータはいつまでも「最新」サイクルのままです。

8.4.1.2 アクセス・モードおよびデータ削減

ユーザーがコンテンツ・アイテムにアクセスした方法によって、それらのアクセスがSctAccessLog表に記録される方法が決まります。基本的なユーザー・アクセス・モードは、(実際のネイティブ・ファイルを表示する)サービス・アクセスと(Webロケーション・ファイルを表示する)静的URLアクセスの2つですサービスを介してコンテンツ・アイテムがアクセスされると、イベントがリアルタイムでSctAccessLog表に記録されます。この場合、アクティビティは即時に記録され、削減プロセスには依存しません。

ただし、静的URLを介してコンテンツ・アイテムがアクセスされると、Webサーバー・フィルタによって静的ログ・ファイルにイベントが記録されます。データ削減プロセス中に、指定された日付の静的ログ・ファイルが収集され、データがSctAccessLog表に移動します。この場合、特定の日付についてデータ削減が実行されないと、静的URLはSctAccessLogに記録されず、これらのアクセスが行われた証拠は残りません。

このため、間隔カウントについては、静的アクセスとサービス・アクセスの処理方法の違いを考慮する必要があります(「「スナップショット」タブ」を参照)。たとえば、ユーザーが土曜日にコンテンツ・アイテムに2回アクセスした場合、1回はWebロケーション・ファイルを介して(静的アクセス)、もう1回はネイティブ・ファイルを介して(サービス・アクセス)アクセスしたとします。サービス・アクセスはSctAccessLog表に記録されますが、Webロケーション・アクセスはSctAccessLog表に記録されません。

次に、日曜日のデータが削減された場合、(静的アクセスでなく)サービス・アクセスのみが短期および長期のアクセス・カウント間隔のサマリーに含められます。ただし、土曜日のデータも削減された場合は、サービス・アクセスと静的アクセスの両方がSctAccessLog表に記録され、短期および長期のアクセス間隔に含められます。

8.4.1.3 イベント・ログの削減順序

一般に、生成されるレポートにできるかぎり最新の情報が含められるように、データ・セットは発生時間順に削減されます。特に、RAWデータ・ログ・ファイルが削減される順序によって、記録およびカウントされるユーザー・アクセス・データの種類が決まります。削減中に、SctAccessLog表およびユーザー・メタデータ・データベース表が、RAWデータ・ファイルからのデータで変更されます。

スナップショット機能を使用して検索関連情報を収集する場合は、アクティブ化されたアクティビティ・メトリックに関連付けられているメタデータ・フィールドもデータ削減中に更新されます。アクティビティ・メトリックでは、コンテンツ・サーバーのDocMetaデータベース表に含まれているカスタム・メタデータ・フィールドが使用されます。詳細は、「「スナップショット」タブ」を参照してください。

様々なデータベース表の情報が最新かどうかは、データ・セットを削減する順序によって決まります。Content Trackerでは常に、削減データ・セット内の適用可能データに従ってアクティビティ・メトリック値が変更されます。通常、アクティビティ・メトリックが予測どおりに進行するように、データ・セットは日付順に削減されます。実際には、常にデータ値を完全かつ最新に保つために、毎日データ削減を実行する必要があります。

データ・セットを順序どおりに削減しない場合は、現行または最新のデータ・セットを再削減すると、カウントが訂正されます。ただし、データは常に日付順に削減することをお薦めします。

次のシナリオに、削減順序によって格納されるデータがどのような影響を受けるかを示します。

シナリオ1:

特定の日(たとえば、土曜日と日曜日)のアクティビティが削減されていない場合、コンテンツ・アイテムへのアクセス方法によっては、これらの日に発生したアクセスが記録またはカウントされないことがあります(「アクセス・モードおよびデータ削減」を参照)。同様に、火曜日にコンテンツ・アイテムがアクセスされ、月曜日と水曜日に削減が実行された場合、そのコンテンツ・アイテムへの最後のアクセスに対して火曜日のアクセスがカウントされないことがあります。

シナリオ2:

過去数日間でアクセス数が大幅に増加し、2週間前からのデータを削減した場合、コンテンツ・アイテムの長期および短期のアクセス・メトリックは最新のアクティビティを反映しません。この場合、2週間前からの間隔値で本日の値がオーバーライドされます。現在または最新のデータ・セットを削減すると、カウントが訂正されます。

削減順序によって最終アクセス日付が誤って変更されることはありません。削減データ・セット内の最新のアクセスがコンテンツ・サーバーのDocMetaデータベース表の最終アクセス値よりも新しい場合にのみ、削減プロセスによって最終アクセス日付が変更されます。

最新のデータ・セットを削減し、特定のコンテンツ・アイテムがアクセスされた場合は、最終アクセス・フィールドが削減データ・セット内の最新のアクセス日付に更新されます。その後、それ以前のデータ・セットを再削減した場合、現行値は、このコンテンツ・アイテムに対する以前のアクセス日付でオーバーライドされません。

長期および短期のアクティビティ・メトリックの詳細は、「「スナップショット」タブ」、および適用可能なチェック・ボックスと対応する「フィールド」/「時間間隔」を参照してください。

シナリオ3:

任意の順序でデータ・セットを削減した場合は、「最新」データ・ファイルから「アーカイブ」データ・ファイルへの移行が妨げられます。関連付けられた表レコードは存続時間に基づいて移動し、アーカイブ表は最も古いデータを格納することを目的にしています。データ・セットがランダムな順序で削減された場合、どのデータが最も古いかは不明になります。

「最新」データ・ファイルおよび「アーカイブ」データ・ファイルの詳細は、「ユーザー・メタデータ」、「データ削減サイクル」、および「「削減」タブ」の「サイクル」列を参照してください。

8.4.1.4 削減スケジュール

スケジュールに基づいた削減の実行を構成できます。一般的に、スケジューラを使用して定期的にRAWデータを削減します。この場合、RAWデータは、「最新」リポジトリおよび「アーカイブ」リポジトリに安定して移動し、同様に、削減済データはプライマリ表からアーカイブ表に安定して移動します。RAWデータ、データ・ステータス、およびプライマリ表とアーカイブ表の詳細は、「「削減」タブ」を参照してください。

Content Trackerスケジュール・プロセスの主な特性は、次のとおりです。

• Content Trackerデータ・エンジンが、スケジュールされた削減実行の前日に無効化された場合、データは収集されません。Content Trackerデータ・エンジンが、スケジュールされた削減実行の日に有効化された場合、使用可能なデータが存在しないため、スケジューラは実行されません。

• 特定の日にスケジュールされたデータ削減は、その前日中に収集されたデータに対して実行されます。前日の定義は、午前0時(システム時間)に開始および終了する24時間です。

  
  

  注意: システム負荷の様々な条件によっては、削減が午前0時をすぎて数分以内に実行されるようにスケジュールされている場合、次のエラーが発生することがあります。 <date_time>: Cannot reduce data. A request is in progress to delete raw data that was generated on this date. このメッセージが発生した場合は、削減実行を5分または10分ほど後にスケジュールしてみてください。

  
  
  
  

  ヒント: CPUリソースを節約するには、システム負荷が一般に最も低い早朝時間帯に削減実行をスケジュールします。

  
  

8.4.2 アクティビティ・スナップショット

アクティビティ・スナップショット機能によって、記録された各コンテンツ・アイテム・アクセスに関連するユーザー・メタデータが取得されます。

注意: デフォルトでは、Content Trackerで収集および記録されるのは、コンテンツ・アクセス・イベントのデータのみです。この処理には、検索などのコンテンツ・アクセス・イベント以外での情報収集や、ユーザー・プロファイルの概要の収集および統合は除外されます。その結果、SctAccessLog表のみ移入されます。スナップショット機能がアクティブでないかぎり、ユーザー・データ出力表が存在しても、Content Trackerではその出力表に移入されません。詳細は、「パフォーマンス最適化機能」を参照してください。

この項の内容は次のとおりです。

• 検索関連メトリック

• 検索関連メタデータ・フィールド

8.4.2.1 検索関連メトリック

アクティブにすると、アクティビティ・メトリックおよび対応するメタデータ・フィールドに、コンテンツ・アイテムのユーザー・アクセスに関する検索関連情報が移入されます。オプションの自動ロード機能を使用すると、チェックインされたコンテンツ・アイテムのタイムスタンプが正確になるように、最終アクセス・アクティビティ・メトリックを更新できます。

Content Trackerでは、特定のコンテンツ・アイテムの人気度を示すコンテンツ・アイテム使用状況情報が検索関連カスタム・メタデータ・フィールドに挿入されます。この情報には、2つの異なる時間間隔における最新アクセスの日付およびアクセス数が含まれます。

ユーザーは、これらのアクティビティ・メトリック機能から生成された情報を様々な方法で適用できます。アクティビティ・メトリックを選択的に使用して、後でコンテンツ・アイテムの人気度に基づいて検索結果を並べ替えることができます。たとえば、最近表示されたコンテンツ・アイテムや、先週最も多く表示されたコンテンツ・アイテムに従って、検索結果を並べ替えることができます。

スナップショット機能がアクティブになっている場合は、削減後の手順で検索関連メタデータ・フィールドの値が更新されます。この処理手順の間、Content TrackerではSQL問合せを使用して、アクティビティ・メトリックの値を変更したコンテンツ・アイテムが判別されます。Content Trackerでは、適用可能なデータベース表が新しい値で更新され、再索引付けサイクルが開始されます。ただし、再索引付けされるのは、メタデータ値を変更したコンテンツ・アイテムのみです。「アクティビティ・メトリックを使用するデータ削減プロセス」を参照してください。

「スナップショット」タブを使用すると、スナップショット機能をアクティブ化し、各アクティブ・メトリックを選択的に有効化できます。アクティブ化する各機能には、カスタム・メタデータ・フィールドが関連付けられている必要があります。

詳細は、「スナップショット機能およびアクティビティ・メトリック・オプションの有効化」および「検索関連メタデータ・フィールドへのアクティビティ・メトリック機能のリンク」を参照してください。

または、Content Trackerのsct.cfgファイル内の適用可能な構成変数を手動で更新することもできます。「構成およびカスタマイズ」を参照してください。

8.4.2.2 検索関連メトリック・フィールド

アクティビティ・メトリック機能をカスタム・メタデータ・フィールドにリンクする場合は、これらのフィールドがすでに存在しており、適切なタイプが指定されている必要があります。最終アクセス・メトリックに関連付けるメタデータ・フィールドは日付型である必要があります。アクセス・カウント・メトリックに関連付けるメタデータ・フィールドは整数型である必要があります。「検索関連メタデータ・フィールドの作成」を参照してください。

アクティビティ・メトリックと組み合せて使用するカスタム・メタデータ・フィールドを作成する場合は、検索索引に対してフィールドを有効化することもできます。カスタム・メタデータ・フィールドが索引付けされている(および検索可能である)と、フィールドに格納されているアクセス値に、より効率的にアクセスできます。つまり、検索結果を関連別に選択したり並べ替える場合は、索引付けされたフィールドのほうが便利です。

索引付けは、特に全文検索が有効化されていると、高コストになります。索引付けされたメタデータ・フィールドの短所は、検索関連メタデータ・フィールドの値が変更された場合、影響を受けるコンテンツ・アイテムを再索引付けして、データベース表の値を更新する必要があることです。このため、多数のコンテンツ・アイテム・アクセスのある大きなインスタンスの場合は、検索関連フィールドを更新するとパフォーマンスが低下します。

あるいは、カスタム・メタデータ・フィールドの索引付け機能を無効化することもできます。この場合は、索引付けされていないメタデータ・フィールドを検索して値を検出することが可能ですが、検索のコストはより高くなります。

影響を受けるコンテンツ・アイテムの再索引付けによってパフォーマンスが非常に低下する場合は、必要に応じてスナップショット機能を非アクティブ化できます。ただし、これによって、アクティビティ・メトリック情報が収集されなくなります。その結果、現在の検索結果を使用状況別に並べ替える(たとえば、アクセスされたコンテンツ・アイテムを人気の高い順にリストする)ことができなくなります。

8.4.3 サービス・コール

Content Trackerでは、コンテンツ・サーバー・サービス・コールを、関連付けられたサービスに関連するデータ値とともにログに記録できます。ログに記録する各サービスには、サービス・コール構成ファイル(SctServiceFilter.hda)内にサービス・エントリが存在している必要があります。ログに記録するサービスに加えて、対応するフィールド・マップResultSetを必要に応じてSctServiceFilter.hdaに含めることができます。

注意: Content Trackerでは、デフォルトで、コンテンツ・アクセスのイベント・タイプを持つサービス、またはDocHistory表への入力が発生するサービスのみがログに記録されます。これにより、パフォーマンスは最大になりますが、一部のサービス・イベントはログに記録されなくなります。詳細は、「パフォーマンス最適化機能」を参照してください。

SctServiceFilter.hdaファイル内のサービス・エントリによって、Content Trackerではイベントおよび使用状況の情報を収集できます。有効化されたサービスによって、各種の一般的なDataBinderフィールド(dUser、dDocNameなど)が自動的に記録されます。フィールド・マップResultSetをサービス・エントリにリンクすると、拡張されたサービス・コール・トラッキング機能を使用できます。フィールド・マップResultSetは、データ・フィールド名、格納場所名、および出力データベース表(SctAccessLog)内の関連付けられた汎用表列名のリストで構成されます。

SctAccessLog表には、拡張されたサービス・コール・トラッキング機能で使用するための追加の汎用列が用意されています。これらの列に、関連付けられたサービス・コールに適した任意のデータ値を挿入できます。フィールド・マップResultSet内にデータ・フィールド名をリストする場合は、データ・フィールドのソースである格納場所名、およびデータの記録先の表列名もリストする必要があります。拡張されたサービス・トラッキング機能によって特定のサービス・コールに対する特定のデータが記録および追跡されるため、アクセスおよび使用状況の情報が含まれるカスタマイズ済レポートを生成できます。

注意: フィールド・マップResultSet内では、データ・フィールドを既存の標準のSctAccessLog表列に自由にマップできます。標準のフィールド・データ値が収集されると、拡張されたサービス・マッピングが実行されます。これにより、標準の表列フィールドをオーバーライドできます。 たとえば、ログに記録するサービスのデータ・フィールドに特定のユーザー名(たとえば、MyUserName=john)が含まれるとします。拡張されたトラッキング機能を使用して、sc_scs_dUser列の内容をオーバーライドできます。この場合は、MyUserNameとsc_scs_dUserを結合して、データ・フィールド、格納場所、およびフィールド・マップResultSet内の表列のセットとして使用します。 したがって、この場合も、ログに記録されるデータがSctAccessLogの列タイプと適合していることを確認する必要があります。

SctAccessLog表および汎用列の詳細は、「結合された出力表」を参照してください。SctServiceFilter.hdaファイル、拡張されたサービス・コール・トラッキング機能およびResultSet構成の詳細は、「サービス・コール構成」を参照してください。

8.4.4 Webビーコン・オブジェクト

Webビーコンは、Webページまたは他の管理対象コンテンツへの間接ユーザー・アクセスを容易に追跡するための特別サポートを提供する管理対象オブジェクトです。Content Trackerの以前のバージョンでは、キャッシュされたページのデータや、キャッシュされたサービスから生成されたページのデータは収集できませんでした。Webビーコン機能を使用すると、クライアント側では、コンテンツ・サーバー内の管理対象ビーコン・オブジェクトへの目にみえない参照として埋込み参照を使用できます。このシステムにより、Content Trackerでは、コンテンツ・サーバーからコンテンツを直接取得せずに、再配布のために外部エンティティによってコピーされた管理対象コンテンツ・アイテムに対するユーザー・アクセス・リクエストを記録してカウントできます。

簡単に説明すると、Webビーコン機能では、擬似問合せパラメータを使用してエンコードされ、管理対象コンテンツ・アイテムまたはWebページに埋め込まれた、特別に設計されたWebビーコン参照が使用されます。ユーザーがタグ付きオブジェクトをリクエストすると、ブラウザではページのレンダリング中にWebビーコン参照を検出します。この参照を解決するために、ブラウザではコンテンツ・サーバーからWebビーコン・オブジェクトをリクエストし、その最中にエンコードされた問合せ文字列を送信します。Content Trackerでは、問合せパラメータ値を解釈し、キャッシュされたアイテムまたはWebページへのアクセスを記録してカウントできます。

注意: Webビーコン機能の実装要件は、関連するシステム構成に大きく依存しています。Content Trackerのドキュメントでは対応できない要素も多くあります。少なくとも、Content Trackerで収集および処理されるすべてのアクセス・レコードは、正確なカウントではなく、一般的なユーザー・アクティビティを示すものです。

この項の内容は次のとおりです。

• Webビーコン参照のユースケース

• Webビーコンの操作と実装の概要

• Webビーコン・オブジェクト

• Webビーコン参照

• Webビーコン参照の削減処理

• 実装に関する一般的な考慮事項

• Webビーコン埋込みの例

8.4.4.1 Webビーコン参照のユースケース

Webビーコン機能を使用すると、コンテンツ・サーバーで作成されたが、現在はコンテンツ・サーバーによって提供されていない管理対象コンテンツ・アイテムやWebサイトへのユーザー・アクセスを追跡できます。キャッシュされたWebページやコンテンツ・アイテムにユーザーがアクセスした場合、コンテンツ・サーバーやContent Trackerではこれらのリクエストが発生したことを認識できません。したがって、Webビーコン参照を使用しないと、Content Trackerではこのようなリクエストを記録してカウントできません。

キャッシュされたコンテンツがコンシューマに提供されると、ユーザーは、リクエストされたオブジェクトがコンテンツ・サーバーで提供されていたことを認識します。ただし、実際は、管理対象コンテンツは動的ではないコンテンツ配信方法を使用して提供されます。この状況では、管理対象コンテンツは実際に静的Webサイト、リバース・プロキシ・サーバー、またはファイル・システム外からでも提供されます。このタイプのアクティビティを確実に追跡するには、Webビーコン機能を実装する必要があります。

この項の内容は次のとおりです。

• リバース・プロキシ・サーバー・アクティビティの追跡

• 外部のSite Studio Webサイト・アクティビティの追跡

8.4.4.1.1 リバース・プロキシ・サーバー・アクティビティの追跡

リバース・プロキシ・サーバーは、ユーザーとコンテンツ・サーバーの間に位置します。この構成では、リバース・プロキシ・サーバーはリクエストされた各オブジェクトのコピーを作成することにより、管理対象コンテンツ・アイテムをキャッシュします。別のユーザーが次回にドキュメントを要求すると、プライベート・キャッシュ内の独自のコピーが表示されます。リバース・プロキシ・サーバーのキャッシュ内にリクエストされたオブジェクトが存在しない場合は、コンテンツ・サーバーからコピーをリクエストする必要があります。

リバース・プロキシ・サーバーはキャッシュされたコンテンツを配信するため、コンテンツ・サーバーと直接相互作用することはありません。この場合、Content Trackerではこれらのリクエストを検出できないため、このようなユーザー・アクセス・アクティビティを追跡できません。ただし、Webビーコン機能を実装すると、Content Trackerでは、キャッシュされたページからユーザー・リクエスト・データを収集できるようになります。

注意: 一般的に、リバース・プロキシ・サーバー構成は、キャッシュしたり、ファイアウォールの内側にあるアプリケーションやサイトへのWebアクセスを管理することによって、Webパフォーマンスを向上させるために使用します。つまり、ロード・バランスを行い、頻繁にアクセスされるコンテンツのコピーを、スケジュールに基づいて更新されるWebサーバーに移動します。これは間接的な配信システムで、ユーザーは動的に作業しますが、コンテンツは静的に配信されます。 ただし、Webビーコン機能を有効にするために、各ユーザー・アクセスには、コンテンツ・サーバーに存在する管理対象ビーコン・オブジェクトへの追加の直接リクエストが含まれています。これによって通常のリクエストよりもオーバーヘッドが増加しますが、Webビーコン・オブジェクトは非常に小さいため、リバース・プロキシ・サーバーのパフォーマンスに大きな影響を与えることはありません。さらに、必要なのは、特に追跡するオブジェクトにWebビーコン参照を埋め込む操作のみです。

8.4.4.1.2 外部のSite Studio Webサイト・アクティビティの追跡

Site StudioはContent Serverに統合されており、これにより、ユーザーはコンテンツ・サーバー・インスタンスで格納および管理されるWebサイトを作成できます。Site StudioとContent Serverが同じサーバーに存在する場合、Content Trackerは適用可能なユーザー・アクセスを自動的に追跡するように構成されます。収集されたSite Studioアプリケーション・データは、事前定義済レポートで使用されます。「Site StudioのWebサイト・アクティビティ・レポート作成」を参照してください。

Webサイトが外部対象者向けの場合は、サイトのコピーを作成して、別のサーバーに転送できます。このソリューションでは、サイトをパブリックに表示すること以外に、開発サイトと本番サイトを別々にすることも可能です。ただし、この配置の場合は、Webビーコン機能を実装して、Content Trackerでユーザー・アクティビティを収集および処理できるようにする必要があります。

注意: 現在、Site StudioとContent Trackerの統合には2つのモードがあります。1つは、Site StudioがContent Serverとともにインストールされたときに自動的に行われる既存の組込み統合のタイプです。もう1つは、Webビーコン機能を使用して、Content TrackerがSite Studioを他のWebサイト・ジェネレータと同様に扱う形式です。

8.4.4.2 Webビーコンの操作と実装の概要

Content Trackerは、コンテンツ・サーバーで現在管理されているオブジェクトに対するリクエストを記録してカウントすることに重点を置いて設計されています。Webビーコン機能を使用すると、外部エンティティ(リバース・プロキシ・サーバー、またはコンテンツ・サーバーを使用しない再配布用のエンティティなど)でコピーされた管理対象オブジェクトに対するリクエストをカウントできます。「リバース・プロキシ・サーバー・アクティビティの追跡」および「外部のSite Studio Webサイト・アクティビティの追跡」を参照してください。

次のリストでは、Webビーコン機能および実装要件の概要を簡単に説明します。ここでは、一般的背景について説明し、後続の項で説明する詳細情報を理解するための準備を整えます。

• パート1: Webビーコン・オブジェクトの作成

  Webビーコン機能の実装を開始するには、Webビーコン・オブジェクトを作成する必要があります。これは、通常、非常に小さなオブジェクト(縦横1ピクセルの透明なイメージなど)です。次に、Webビーコン・オブジェクトをコンテンツ・サーバーにチェックインし、Content TrackerのWebビーコン・オブジェクト名リストに追加する必要があります。

• パート2: Webビーコン参照の作成

  次の実装ステップでは、チェックインしたWebビーコン・オブジェクトへのWebビーコン参照を作成して、キャッシュされたHTMLページまたは管理対象コンテンツ・アイテムに埋め込みます。この参照は、2つの部分から構成されています。最初の部分は、Webビーコン・オブジェクトへのURL参照です。2番目の部分は、リクエストされたコンテンツの識別に使用される追加情報で構成されます。この情報は、擬似問合せパラメータとしてエンコードされます。

  Webビーコン参照が埋め込まれた管理対象コンテンツ・アイテムまたはWebページにユーザーがアクセスすると、サーバー(Site Studioまたはリバース・プロキシ)ではキャッシュされたアイテムが配信されます。ただし、ブラウザでは、Webページまたはコンテンツ・アイテムをレンダリングするために、Webビーコン参照を解決する必要があります。このため、ブラウザでは、コンテンツ・サーバーからWebビーコン・オブジェクトをリクエストします。

  コンテンツ・サーバーへのこのアクセス・リクエストは、問合せパラメータのエンコードされた情報とともに送信されます。問合せパラメータ内の情報によって、Content Trackerはタグ付きのWebページまたは管理対象オブジェクトを識別できます。通常、Webブラウザでは、データ削減のためにContent TrackerのWebサーバー・フィルタでコピーおよび格納できる長さの問合せパラメータは無視されます。

• パート3: Content TrackerのWebビーコン参照の削減処理

  最後に、Content Trackerでは、ビーコン・オブジェクトへのWebビーコン参照を通常の方法でログに記録します。「データ削減」を参照してください。データ削減中に、Content Trackerでは、登録されたWebビーコンのリストと照合して各参照先オブジェクトのdDocNameが確認されます。「Webビーコン・オブジェクト」を参照してください。リクエストされたオブジェクトのdDocNameがリストに存在する場合、問合せパラメータは、URLリクエストがWebビーコン・オブジェクトではなくタグ付きオブジェクト(Webページや管理対象コンテンツ・アイテム)に対するリクエストとしてログに記録されるように処理されます。

8.4.4.3 Webビーコン・オブジェクト

Webビーコン機能を実装するときは、Webビーコン・オブジェクトとして使用するコンテンツ・アイテムを1つ以上作成する必要があります。通常、Webビーコン・オブジェクトは縦横1ピクセルの透明なイメージで、オーバーヘッドが小さくページのレンダリングを妨げないオブジェクトが適しています。コンテンツがないWebビーコン・オブジェクトが理想的です。複数のWebビーコン・オブジェクトを作成できますが、ほとんどの実装では1つのWebビーコン・オブジェクトのみを使用して適切に機能します。

注意: Webビーコン・オブジェクトを作成するときは、SctIgnoreFileType構成変数に含まれるファイル・タイプ値でないことを確認する必要があります。Webビーコン・オブジェクトのファイル・タイプがリスト内のいずれかの値と一致すると、Content Trackerでは、関連付けられたキャッシュ済コンテンツ・アイテムまたはWebページのアクティビティ・データが収集されません。SctIgnoreFileType構成変数の詳細は、「SctAccessLogのエントリのファイル・タイプ」を参照してください。

次に、完成したWebビーコン・オブジェクトをコンテンツ・サーバーにチェックインする必要があります。その後、Content TrackerのSctWebBeaconIDListプリファレンス/構成変数を更新する必要があります。データ削減中に、Content Trackerでは、SctWebBeaconIDList設定が確認され、イベント・ログ内のWebビーコン参照リストの処理方法が決定されます。適用可能なWebビーコン・オブジェクトがリストされている場合、Content Trackerではデータが適切に処理されます。

注意: Content Trackerをインストールするときは、Webビーコン・オブジェクトのdDocNamesをSctWebBeaconIDListプリファレンス変数に入力するオプションがあります。ただし、前もってWebビーコン・オブジェクトの名前がわからない場合は、SctWebBeaconIDList設定を手動で変更することもできます。これは、コンポーネント・マネージャで更新機能を使用して行います。「WebビーコンIDリストへのWebビーコン・オブジェクト名の追加または編集」を参照してください。

8.4.4.4 Webビーコン参照

Webビーコン・オブジェクトを作成してチェックインした後は、対応するWebビーコン参照を作成する必要があります。異なる問合せ文字列がWebビーコン静的URLに追加されることによって各参照が一意になるため、通常は、ほとんどのシステムでWebビーコン・オブジェクトは1つで十分です。さらに、各問合せパラメータ・セットは、キャッシュされた特定のWebページまたは管理対象コンテンツ・アイテムを識別するために、変数の個別の組合せから構成されています。

Webビーコン機能によって間接ユーザー・アクティビティを効率的に追跡するには、最初に、Webビーコンに対するWebビーコン参照が適切に書式設定され、必要な情報が含まれている必要があります。次に、キャッシュされたドキュメントまたはWebページに参照が適切に埋め込まれて、正しく実行されることが必要です。最後に、後で削減処理を行うために、Content Trackerで適用可能なデータを正確に取得して格納できる必要があります。

この項の内容は次のとおりです。

• WebビーコンURL参照のフォーマット構造

• Webビーコン参照の配置および取得スキーム

• キャッシュされた管理対象コンテンツ・アイテムのデータの取得と格納

8.4.4.4.1 WebビーコンURL参照のフォーマット構造

WebビーコンURL参照は、コンテンツ・サーバーで管理されるWebビーコン・オブジェクトへのアクセスに使用するWebビーコン静的URL、およびコンテンツ・アイテム変数を指定した擬似問合せ文字列の2つの部分から構成されます。Webビーコン静的URLに追加された問合せ文字列が実際に実行されることはありません。ただし、問合せパラメータ値のセットによって、Content Trackerが関連する管理対象オブジェクトを識別するのに十分な追加情報が提供されます。「キャッシュされた管理対象コンテンツ・アイテムのデータの取得と格納」を参照してください。

注意: Webビーコン参照を作成するときは、コンテンツ・サーバー内のWebビーコン静的URLに、SctIgnoreDirectories構成変数に含まれるディレクトリ・ルートが使用されていないことを確認する必要があります。 Webビーコン静的URLのルート・ディレクトリがリスト内のいずれかの値と一致すると、Content Trackerでは、関連付けられたキャッシュ済コンテンツ・アイテムまたはWebページのアクティビティ・データが収集されません。SctIgnoreDirectories構成変数の詳細は、「SctAccessLogのエントリのファイル・タイプ」を参照してください。

問合せパラメータ・セットは、ユーザーがアクセスした実際の管理対象コンテンツ・アイテムをContent Trackerに通知するコードとして機能します。問合せパラメータの1つがアイテムのdIDです。問合せパラメータ値の一意のセットを含めることによって、コピーおよびキャッシュされた管理対象オブジェクトに対する間接ユーザー・アクセスを監視できます。

次の例では、Webビーコン機能に関連する一般的なフォーマット構造について説明します。さらに、これらの例では、異なる問合せ文字列を数に制限なく作成しながら、1つのWebビーコン・オブジェクトのみを使用する方法についても説明します。すべての例で、同じWebビーコン・オブジェクト(dDocName = bcn_2.txt)を使用します。ただし、このWebビーコン・オブジェクトに対するリクエストは、問合せパラメータを変えることによって、リポジトリ内のすべての管理対象オブジェクトに対するリクエストをContent Trackerに通知できます。

ここで示す例は、次の前提条件に基づいています。

• Webビーコン・オブジェクト(bcn_2.txt)はコンテンツ・サーバーにチェックインされ、Webビーコン・リスト(SctWebBeaconIDList)に含まれています。「Webビーコン・オブジェクト」を参照してください。

• 適用可能なWebビーコン参照は、関連付けられた管理対象コンテンツ・アイテム(doc1、doc2およびdoc3)に埋め込まれています。「Webビーコン参照の配置および取得スキーム」を参照してください。

• Webビーコン参照を解決するために、ブラウザではWebビーコン・オブジェクトのコピーをコンテンツ・サーバーからリクエストする必要があります。「Webビーコン参照の配置および取得スキーム」を参照してください。

• ユーザーが関連するコンテンツ・アイテムを間接的にリクエストするため、Webビーコン・リクエストが発生します。「Webビーコン参照のユースケース」を参照してください。

例8-1 問合せパラメータを使用しないWebビーコン・リクエスト

http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt

この例は、Webビーコン・オブジェクトへの静的Web参照から始まります。これはWebビーコン・オブジェクトへの正当な直接アクセスですが、問合せパラメータは追加されていません。したがって、Content Trackerでは、このアクセス・イベントをWebビーコン・オブジェクト自体に対するリクエストとして処理します。「データ収集および処理」を参照してください。

例8-2 doc1を追跡するためのWebビーコン・リクエスト

http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=doc1&sct_dID=1234&...

この例も、このビーコン・オブジェクトへの通常の静的Web参照から始まります。ただし、これには任意の数の問合せパラメータを含む擬似問合せ文字列が追加されています。これらの問合せパラメータに含まれる値によって、ユーザーがリクエストした特定の管理対象オブジェクト(doc1)に関する情報が通知されます。

例8-3 doc2を追跡するためのWebビーコン・リクエスト

http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=doc2&sct_Ext_2=WebSite4

この例は、例8-2に似ています。パラメータ値によって、ユーザーがリクエストしたコンテンツ・アイテム(doc2)に関する情報が提供されます。ただし、この例では、問合せ文字列に、タグ付きコンテンツ・アイテムに関する追加情報を通知するための別のパラメータが含まれています。この場合は、追加されたパラメータでextField列名が使用されます。したがって、値WebSite4はSctAccessLog表のextField_2列にコピーされます。(extField列の置換はオプションで、アプリケーションに依存しています。)

例8-4 doc3を追跡するためのWebビーコン・リクエスト

http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=doc2&sct_Ext_2=WebSite4&sct_Ext_8=SubscriptionClass6

この例では、2番目(ただし、シーケンシャルでない)のextField列名を追加することによって、例8-3を変更します。この場合、WebSite4はSctAccessLog表のextField_2列にコピーされ、SubscriptionClass6はextField_8列にコピーされます。(ここでも、extField列の置換はオプションで、アプリケーションに依存しています。)

8.4.4.4.2 Webビーコン参照の配置および取得スキーム

Webビーコン機能を適切に使用するには、特別に作成されたWebビーコン参照が、追跡対象となる管理対象オブジェクトに埋め込まれている必要があります。一般に、Webビーコン参照はHTMLページに埋め込むことができます。ユーザーは、変更された管理対象コンテンツ・アイテムへのアクセスを(外部のSite Studio Webサイトまたはリバース・プロキシ・サーバーを介して)間接的にリクエストします。

次に、ブラウザでは、リクエストされたページのレンダリング中にWebビーコン参照を検出します。管理対象オブジェクトを表示するたびに(オブジェクトの取得方法に関係なく)、ブラウザではWebビーコン・オブジェクトのコピーをコンテンツ・サーバーから直接リクエストします。ブラウザがWebビーコン参照を解決すると、Content Trackerでは、Webビーコン参照、および管理対象コンテンツ・アイテムを識別するための擬似問合せパラメータを含むデータを取得します。

8.4.4.4.3 キャッシュされた管理対象コンテンツ・アイテムのデータの取得と格納

通常、静的URL内の問合せパラメータは、Webブラウザに対してなにも機能しません。ただし、Webビーコン静的URLを解決するとき、Webブラウザでは、Content TrackerのWebサーバー・フィルタで記録できる長さの追加問合せパラメータは無視されます。擬似問合せパラメータが実行されることはありませんが、Content Trackerでは、問合せパラメータ値とともに、クライアントIPアドレスや日時スタンプなどの他のデータも取得します。Content Trackerでは、データをWebアクセス・イベント・ログ(sctlogファイル)に記録します。「Content Trackerイベント・ログ」を参照してください。

8.4.4.5 Webビーコン参照の削減処理

Webビーコン機能を使用すると、Content Trackerでは、管理対象コンテンツ・アイテムに対する間接ユーザー・リクエストを取得して記録できます。データ削減中に、特別に作成されたWebビーコン参照が処理されると、Content Trackerでは、通常のコンテンツ・アイテムではなくWebビーコン・オブジェクトに対するリクエストであることが判別されます。Content Trackerでこの処理を行うには、SctWebBeaconIDListのdDocNamesのリストに対してWebビーコンのdDocNameを照合します。

リスト内に一致するものがない場合、または問合せパラメータがWebビーコン参照に追加されていない場合、Content Trackerではアクセス・イベントを通常どおりに処理します。「データ削減」を参照してください。WebビーコンのdDocNameがみつかった場合、Content Trackerでは処理を続行し、関連付けられたURLの問合せパラメータを解釈します。最終的に、データ削減プロセスでは、Webビーコン・アクセス・リクエストを、Webページまたはコンテンツ・アイテムに対するリクエストとして処理します。

データ削減中に、Content Trackerでは、問合せパラメータを解析し、最終的にSctAccessLogに書き込まれるフィールドの様々な値の置換を実行します。SctAccessLog表および各データ・フィールドの詳細は、「結合された出力表」を参照してください。問合せパラメータ値は、SctAccessLogのフィールドに次のようにマップされます。

• sct_dIDはWebビーコン・オブジェクトのdIDを置換します。

• sct_dDocNameはWebビーコン・オブジェクトのdDocNameを置換します。

• sct_uriStemはWebビーコン・オブジェクトのURIステム(「?」より前の部分)を置換します。

• sct_uriQueryはWebビーコン・オブジェクトのURI問合せ部分(「?」より後の部分)を置換します。

• sct_Ext_nはSctAccessLogの拡張フィールドnに直接コピーされます。

例8-5 問合せパラメータ値のデータ削減処理

/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=WW_1_21&sct_dID=42&sct_Ext_1=WillowStreetServer&sct_Ext_2=SubscriptionTypeA

データ削減処理の後、Content Trackerでは、このWebビーコン・タイプのリクエストを、bcn_2.txtではなくWW_1_21へのアクセスとしてSctAccessLog表に記録します。ユーザー名、アクセス時刻、クライアントIPなどの他のデータは、HTTPリクエストから導出されます。さらに、WillowStreetServerはSctAccessLog表のextField_1列にコピーされ、SubscriptionTypeAはextField_2列にコピーされます。(最後の2つのフィールド置換はオプションで、アプリケーションに依存しています。)

8.4.4.6 実装に関する一般的な考慮事項

Content TrackerのWebビーコン機能を実装するには、次のタスクを手動で実行する必要があります。

1. Webビーコン・オブジェクトを作成します。

2. コンテンツ・サーバーにチェックインします。

3. SctWebBeaconIDListを更新します。

4. Webビーコン参照を定義します。

5. 定義した参照を追跡対象になるキャッシュ済コンテンツ・アイテムまたはWebサイト(あるいはその両方)に埋め込みます。

Webビーコン機能を実装するときは、考慮する必要がある複数の問題、制限事項およびガイドラインがあります。

この項の内容は次のとおりです。

• Webビーコンの設計に関する制限事項

• Webビーコンの設計に関するガイドライン

8.4.4.6.1 Webビーコンの設計に関する制限事項

Webビーコン機能の実装に関する問題のタイプに応じて、次の制限事項を考慮する必要があります。

• Webビーコン機能の実装における問題の1つは、Webビーコン参照をタグ付きオブジェクトに添付する方法を決定することです。また、リクエストされたオブジェクトに参照を埋め込むことができない場合があります(PDFまたはWord文書など)。この場合は、実際のコンテンツ・アイテムがリクエストされる前に、Webビーコン・オブジェクトをコンテンツ・サーバーから直接リクエストする必要があります。

• 特定のブラウザ構成の場合など、Webビーコン機能が動作しない状況は多数あります。ユーザーがブラウザのクロスドメイン参照を無効化し、Webページとコンテンツ・サーバー・インスタンスが異なるドメインに存在する場合、Webビーコン・オブジェクトはコンテンツ・サーバーからリクエストされることはなく、ユーザー・アクセスはカウントされません。

  次に例を示します。

  • 静的WebサイトはABChost.XYZorg.comドメインに存在しており、

  • コンテンツ・サーバー(このWebサイトが構築され、Webビーコン・オブジェクトが格納されているサーバー)はmyhost.myorg.comドメインに存在しており、

  • ユーザーはクロスドメイン参照を無効化しているが、ABChost.XYZorg.comドメインからドキュメントにアクセスしている(このため、ブラウザはABChost.XYZorg.com以外のリンクにアクセスできません)場合は、

  • ユーザーのブラウザが埋め込まれたWebビーコン参照を検出し、ABChost.XYZorg.comドメインのコンテンツ・サーバー・インスタンスからWebビーコン・オブジェクトをリクエストすると、そのリクエストは失敗し、myhost.myorg.comドメインからのユーザーのコンテンツ・アイテム・アクセスはカウントされません。

• リバース・プロキシ・サーバーを経由して最初に管理対象コンテンツ・アイテムにアクセスすると、コンテンツ・サーバーがアイテムをリバース・プロキシ・サーバーに提供したときに1回、ブラウザがWebビーコン・オブジェクトをリクエストしたときに1回の計2回カウントされます。

• 特定の構成によっては、リバース・プロキシ・サーバーおよび外部のSite StudioがWebビーコン・オブジェクト自体をキャッシュしない方法を考案する必要があります。ブラウザでもキャッシュが行われます。この状況では、コンテンツ・サーバーは関連するコンテンツ・アクセスをカウントできません。

  
  

  ヒント: この状況を回避する方法の1つは、各Webビーコン・オブジェクト・リクエストを一意にすることです。これを行うには、乱数を含む1回かぎりの問合せパラメータをWebビーコン参照に追加します。次に例を示します。 dDocName=vvvv_1_21&FoolTheProxyServer=12345654321 各リクエストの数値を変更することによって、Webサーバーおよびブラウザはキャッシュを行わず、リクエストを新規とみなします。

  
  

8.4.4.6.2 Webビーコンの設計に関するガイドライン

Webビーコン機能の実装に関する問題のタイプに応じて、次のガイドラインを考慮する必要があります。

• Webビーコン参照のsct_dDocNameおよびsct_dIDパラメータ値は、リクエストされたWebビーコン・オブジェクトを提供するコンテンツ・サーバー・インスタンス内で実際の管理対象コンテンツ・アイテムに解決される必要があります。

• SctAccssLog表のExtField列の使用はオプションで、アプリケーションに完全に依存しています。

• ExtField_10は、Webビーコン・オブジェクトのdDocName用に使用するために予約されています。これによって、レポート作成者は、実際の管理対象コンテンツ・アイテムへのアクセスを通知するのに使用されたWebビーコン・オブジェクトを判別できます。

• 問合せパラメータ名のスペルおよび大/子文字は正確である必要があります。

• 問合せパラメータ値に、カンマや空白を埋め込むことはできません。

• 通常、Webビーコン参照には管理対象オブジェクトのdDocNameおよびdIDが含まれますが、正当なアクセス・リクエストとみなされるには、両方とも含まれる必要はありません。標準フィールドの一部が欠落している場合、Content Trackerでは次のように識別情報パラメータが解決されます。

  • dIDを指定すると、Content Trackerではコンテンツ・アイテムのdDocNameを判別できます。

  • dDocNameを指定すると、Content Trackerでは、次の規定に従ってコンテンツ・アイテムのdIDを判別できます。

    この場合、dIDはコンテンツ・アイテムの最新リビジョンです。コンテンツ・アイテムがキャッシュされた後にリビジョンが変更された場合、ユーザーには古いバージョンが表示されます。ただし、Content Trackerでは、コンテンツ・アイテムの最新リビジョンの表示としてこのアクセス・リクエストがカウントされます。

  • 適切なURIステムを指定すると、Content Trackerではコンテンツ・アイテムのdDocNameを判別できますが、最新リビジョンのdIDであるとみなされます。

• Webビーコン・リスト(SctWebBeaconIDList)を変更した場合は、コンテンツ・サーバーを再起動する必要があります。

• ファイル・タイプを使用するWebビーコン・オブジェクトを作成したり、Content Trackerで無視するように構成されているディレクトリ内にWebビーコン・オブジェクトを配置しないでください。Content TrackerのWebサーバー・フィルタによって、SctIgnoreFileTypeおよびSctIgnoreDirectories構成変数にリストされているファイル・タイプとディレクトリが区別されます。「Webビーコン・オブジェクト」および「WebビーコンURL参照のフォーマット構造」を参照してください。

• Content Trackerでは、キャッシュされたコンテンツ・アイテムが配信されたかどうかを確認できません。

• Content Trackerでは、静的URLアクセスの通常の折りたたみ動作が実行されます。ユーザーが同じコンテンツ・アイテムを繰返しリクエストし、別のドキュメントに対するリクエストが途中で介入しない場合、Content Trackerでは連続するリクエストは同じドキュメントであるとみなされます。この場合、これらのアクセス・リクエストはすべて1つのアクセス・リクエストとみなされます。

• 問合せパラメータは任意の管理対象オブジェクトを表すことができ、必ずしもユーザーに実際に表示されている内容である必要はありません。

8.4.4.7 Webビーコン埋込みの例

コンテンツ・サーバーのWebビーコン機能を実装するとき、Webビーコンを埋め込む方法は複数あります。各方法にはそれぞれ長所と短所があり、特定の状況に応じて最適な方法は異なります。システム構成には違いがあるため、1つの方法がすべての状況に適しているとはかぎりません。

この項では、3つの方法について説明します。

• HTMLに埋め込む方法の例

• JavaScriptに埋め込む方法の例

• JavaScriptを処理する方法の例

注意: すべての例のコード・フラグメント・ファイルは、Content Trackerのドキュメント・ディレクトリから入手できます。これらの例は、管理対象コンテンツへのアクセスを追跡する一般的な方法を示すことを目的にしています。コード・フラグメントは、作業の開始ポイントとして使用できるように提供されています。ただし、使用しているアプリケーションやネットワーク・トポロジで機能するように調整が必要な場合があります。 次のすべての例では、WebBeacon.bmpという同じWebビーコン・オブジェクトを使用します。このグラフィック・ファイルは、dDocNameに「wb_bmp」を指定して、コンテンツ・サーバー・インスタンスIFHE.comcast.net/idc/にチェックインされます。通常、Webビーコン・オブジェクトは縦横1ピクセルの透明なイメージですが、実際にはどのようなオブジェクトでも可能です。

8.4.4.7.1 HTMLに埋め込む方法の例

管理対象コンテンツ・アクセスを追跡するWebビーコンを最も簡単かつ直接的に使用するには、ビーコンへの参照を対象のWebページのHTLMソースに直接埋め込みます。リクエスト・ユーザーのブラウザでは、ページをレンダリングするとき、Webビーコン・オブジェクトが存在するコンテンツ・サーバー・インスタンスにリクエストが送信されます。Content Trackerでは、ビーコンURLに問合せパラメータ・セットとして追加されている追加情報が、Webビーコン・オブジェクトではなくWebページへの参照としてカウントされます。

この例では、追跡対象のWebページにイメージ・タグが配置されています。イメージのsrc attributeは、IFHE.comcast.net/idc/という名前のコンテンツ・サーバー・インスタンスにチェックインされているWebビーコン・オブジェクト(wb_bmp)を参照します。ユーザーのブラウザでIFHE.comcast.net/idc/からイメージをロードすると、追加の問合せ情報が記録され、最終的にdDocName「BOPR」への参照として解釈されます。

この方法が最も簡単ですが、ユーザーのブラウザまたはリバース・プロキシ・サーバー(あるいはその両方)でWebビーコン・オブジェクトのコピーがキャッシュされるという明らかな短所があります。このため、コンテンツ・サーバー・インスタンスIFHE.comcast.net/idc/に直接送信される追加リクエストはありません。さらに、このWebビーコンにタグ付けされたコンテンツへの追加アクセスもカウントされません。

この方法のHTMLフラグメントは次のように記述できます。

<!-- WebBeaconEmbeddedHtml.htm - Adjust the Web Beacon web location and managed object identfiers in the img src attribute, then paste into your web page -->
<img src="http://IFHE.comcast.net/idc/groups/public/documents/adacct/wb_bmp.bmp?sct_dID=1&sct_dDocName=BOPR&sct_uriStem=http://IFHE.comcast.net/idc/groups/public/documents/adacct/bopr.pdf&sct_Ext_1=Sample_Html_Beacon_Access" width="21" height="21" />

8.4.4.7.2 JavaScriptに埋め込む方法の例

「HTMLに埋め込む方法の例」で説明したWebビーコンのキャッシュに関する問題は、HTMLのかわりにJavaScriptを使用することによって解決でき、このJavaScriptを埋め込む方法には、2つのscriptタグが必要です。

• cs_callWebBeacon関数は、実際のWebビーコン・リクエストを発行します。

• 名前の付いていないブロックでは、コンテキスト値を特定のJavaScript変数に割り当ててcs_callWebBeacon関数を呼び出します。

この方法を使用すると、HTMLに埋め込む方法と比べて長所がいくつかあります。管理対象コンテンツ・オブジェクトに関して識別される情報は変数のリストに定義されるため、読みやすくなります。また、乱数を擬似問合せパラメータに追加することによって、Webビーコン・リクエストを効率的に一意にすることができます。

ただし、短所もいくつかあります。管理するコードの量が増えること、Webビーコン・サーバーのURLが各Webページにハードコードされること、およびユーザーのブラウザでJavaScriptが有効化されていない場合があることです。

この方法のJavaScriptフラグメントは次のように記述できます。

// WebBeaconEmbeddedJavascript.js - Adjust the managed object and Web Beacon descriptors,
and then paste this into your web page.
//

<script type="text/javascript" >

    var cs_obj_dID = "" ;
    var cs_obj_dDocName = "" ;
    var cs_obj_uriStem = "" ;
    var cs_extField_1 = "" ;
    var cs_extField_2 = "" ;
    var cs_extField_3 = "" ;
    var cs_extField_4 = "" ;
    var cs_extField_5 = "" ;
    var cs_extField_6 = "" ;
    var cs_extField_7 = "" ;
    var cs_extField_8 = "" ;
    var cs_extField_9 = "" ;
    var cs_beaconUrl = "" ;

    function cs_void( ) { return ; }

    function cs_callWebBeacon( ) {
        //
        var cs_imgSrc = "" ;
        var cs_inQry = false ;

        if ( cs_beaconUrl && cs_beaconUrl != "" ) {
            cs_imgSrc += cs_beaconUrl ;
        }

        if ( cs_obj_dID && cs_obj_dID != "" ) {
            if ( cs_inQry ) {
                cs_imgSrc += "&" ;
            } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
            }
            cs_imgSrc += "sct_dID=" + cs_obj_dID ;
        }

        if ( cs_obj_dDocName && cs_obj_dDocName != "" ) {
            if ( cs_inQry ) {
                cs_imgSrc += "&" ;
            } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
            }
            cs_imgSrc += "sct_dDocName=" + cs_obj_dDocName ;
        }
        if ( cs_obj_uriStem && cs_obj_uriStem != "" ) {
            if ( cs_inQry ) {
                cs_imgSrc += "&" ;
            } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
            }
            cs_imgSrc += "sct_uriStem=" + cs_obj_uriStem ;
        }

        if ( cs_extField_1 && cs_extField_1 != "" ) {
            if ( cs_inQry ) {
                cs_imgSrc += "&" ;
            } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
            }
            cs_imgSrc += "sct_Ext_1=" + cs_extField_1 ;
        } 

        if ( cs_extField_2 && cs_extField_2 != "" ) {
            if ( cs_inQry ) {
                cs_imgSrc += "&" ;
            } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
            }
            cs_imgSrc += "sct_Ext_2=" + cs_extField_2 ;
        } 

        <!-- and so on for the remaining extended fields -->

        if ( cs_inQry ) {
            cs_imgSrc += "&" ;
        } else {
            cs_imgSrc += "?" ;
            cs_inQry = true ;
        }

        var dc = Math.round( Math.random( ) * 2147483647 ) ;
        cs_imgSrc += "sct_defeatCache=" + dc ;

        var wbImg = new Image( 1, 1 ) ;
        wbImg.src = cs_imgSrc ;
        wbImg.onload = function( ) { cs_void( ) ; }

    }

</script>

<script type="text/javascript">
    //
    var cs_obj_dID = "1" ;
    var cs_obj_dDocName = "BOPR" ;
    var cs_obj_uriStem = "http://IFHE.comcast.net/idc/groups/public/documents/adacct/bopr.pdf" ;
    var cs_extField_1 = "Sample_Javascript_Beacon_Access" ;
    var cs_beaconUrl = "http://IFHE.comcast.net/idc/groups/public/documents/adacct/wb_bmp.bmp" ;

    cs_callWebBeacon( ) ;

</script>

8.4.4.7.3 JavaScriptを処理する方法の例

JavaScriptを埋め込む方法の例で説明したWebビーコン・サーバーのハードコートに関する問題は、コードを2つのフラグメントに分割することによって解決します。

• 管理対象コード・フラグメント:

  この例では、管理対象コード・フラグメントにcs_callWebBeacon関数が含まれています。これは、コンテンツ・サーバー・インスタンス(Webビーコンを管理するインスタンス、または他のインスタンスのいずれか)にチェックインして管理できます。ページ内フラグメントに含まれるsrc attributeは管理対象コード・フラグメントを参照し、これによってWebページに動的にロードされます。

• ページ内コード・フラグメント:

  ページ内コード・フラグメント部分は2つの<script>タグで構成されますが、最初のタグにはコードではなくcs_callWebBeaconコードへの参照のみが含まれます。この方法の長所は、cs_callWebBeacon関数に対する変更を一元管理できるため、すべてのタグ付きWebページをそれぞれ変更する必要がないことです。

  このソリューションでは管理対象コードをユーザーのブラウザ上のWebページにロードするため、追加のネットワーク・オーバーヘッドが発生することは明らかです。ただし、Webビーコンに対する要件は追跡処理の支援であるため、ネットワーク環境には効率的なリバース・プロキシ・サーバーや他のキャッシング・メカニズムが含まれています。また、管理対象オブジェクトへのアクセスに同じキャッシュを使用することによって、コードのダウンロードによる影響を最小限に抑えることもできます。

管理対象コード・フラグメント:

// WebBeaconServedJavascript_Checkin.js - Check this in to your Content Server, then fixup
// the Javascript include src attribute in WebBeaconManagedJavascriptIncludeSample.js
//
    var cs_obj_dID = "" ;
    var cs_obj_dDocName = "" ;
    var cs_obj_uriStem = "" ;
    var cs_extField_1 = "" ;
    var cs_extField_2 = "" ;
    var cs_extField_3 = "" ;
    var cs_extField_4 = "" ;
    var cs_extField_5 = "" ;
    var cs_extField_6 = "" ;
    var cs_extField_7 = "" ;
    var cs_extField_8 = "" ;
    var cs_extField_9 = "" ;
    var cs_beaconUrl = "http://IFHE.comcast.net/idc/groups/public/documents/adacct/wb_bmp.bmp" ;

    function cs_void( ) { return ; }

    function cs_callWebBeacon( ) {
        //
        var cs_imgSrc = "" ;
        var cs_inQry = false ;

        if ( cs_beaconUrl && cs_beaconUrl != "" ) {
            cs_imgSrc += cs_beaconUrl ;
        }

        if ( cs_obj_dID && cs_obj_dID != "" ) {
            if ( cs_inQry ) {
                cs_imgSrc += "&" ;
            } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
            }
            cs_imgSrc += "sct_dID=" + cs_obj_dID ;
        }

        if ( cs_obj_dDocName && cs_obj_dDocName != "" ) {
            if ( cs_inQry ) {
                cs_imgSrc += "&" ;
            } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
            }
            cs_imgSrc += "sct_dDocName=" + cs_obj_dDocName ;
        }

        if ( cs_obj_uriStem && cs_obj_uriStem != "" ) {
            if ( cs_inQry ) {
                cs_imgSrc += "&" ;
            } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
            }
            cs_imgSrc += "sct_uriStem=" + cs_obj_uriStem ;
        }

        if ( cs_extField_1 && cs_extField_1 != "" ) {
            if ( cs_inQry ) {
                cs_imgSrc += "&" ;
            } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
            }
            cs_imgSrc += "sct_Ext_1=" + cs_extField_1 ;
        }

        if ( cs_extField_2 && cs_extField_2 != "" ) {
            if ( cs_inQry ) {
                cs_imgSrc += "&" ;
            } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
            }
            cs_imgSrc += "sct_Ext_2=" + cs_extField_2 ;
        }

        <!-- and so on for the remaining extended fields -->

        if ( cs_inQry ) {
            cs_imgSrc += "&" ;
        } else {
                cs_imgSrc += "?" ;
                cs_inQry = true ;
        }

        var dc = Math.round( Math.random( ) * 2147483647 ) ;
        cs_imgSrc += "sct_defeatCache=" + dc ;

        var wbImg = new Image( 1, 1 ) ;
        wbImg.src = cs_imgSrc ;
        wbImg.onload = function( ) { cs_void( ) ; }

    }

ページ内コード・フラグメント:

<script type="text/javascript" src="http://IFHE.comcast.net/idc/groups/public/documents/adacct/wbmjcs.js" >
</script>

<script type="text/javascript">
    //
    var cs_obj_dID = "1" ;
    var cs_obj_dDocName = "BOPR" ;
    var cs_obj_uriStem = "http://IFHE.comcast.net/idc/groups/public/documents/adacct/bopr.pdf" ;
    var cs_extField_1 = "Sample_Managed_Javascript_Beacon_Access" ;

    cs_callWebBeacon( ) ;

</script>

8.4.5 Content Trackerの使用

この項では、Content Tracker機能およびタスクの手順について説明します。この項の内容は次のとおりです。

• パフォーマンス最適化機能の変数設定の変更

• データ・エンジン・コントロール・センターへのアクセス

• データ収集の有効化または無効化

• データ削減の手動実行

• データ削減の自動実行の設定

• 任意のサイクルのデータ・ファイルの削除

• 「アーカイブ」サイクルのデータ・ファイルの削除

• 検索関連メタデータ・フィールドの作成

• スナップショット機能およびアクティビティ・メトリック・オプションの有効化

• 検索関連メタデータ・フィールドへのアクティビティ・メトリック機能のリンク

• 最終アクセス・メタデータ・フィールドのチェックイン時刻値の設定

• スナップショット構成の編集

• サービス・エントリの追加または編集

• フィールド・マップResultSetの追加およびサービス・エントリへのリンク

• フィールド・マップResultSetの編集

• サービス・エントリの削除

• フィールド・マップResultSetの削除

• WebビーコンIDリストへのWebビーコン・オブジェクト名の追加または編集

8.4.5.1 パフォーマンス最適化機能の変数設定の変更

最適化機能のインストール・プリファレンス変数の値は、次のいずれかの方法を使用して変更できます。

• コンテンツ・マネージャ詳細を使用したインストール・プリファレンス変数の変更

• config.cfgファイルを使用したインストール・プリファレンス変数の変更

8.4.5.1.1 コンテンツ・マネージャ詳細を使用したインストール・プリファレンス変数の変更

1. コンテンツ・サーバーに管理者としてログインします。

2. 「管理」メニューから「管理サーバー」を選択します。

   「コンテンツ管理サーバー」ページが表示されます。

3. セキュリティ・チェック・プリファレンス設定を変更するコンテンツ・サーバー・インスタンスの名前をクリックします。

   コンテンツ管理サーバー<instance_name>ページが表示されます。

4. コンポーネント・マネージャ詳細をクリックします。

   コンポーネント・マネージャ・ページの詳細バージョンが表示されます。

5. 「コンポーネント構成の更新」フィールドで、リストから「Content Tracker」を選択します。

6. 「更新」をクリックします。

   コンポーネント構成の更新ページが表示されます。

7. 更新するインストール・プリファレンス変数を選択し、新しい設定を入力します。

8. 「更新」をクリックします。

   Content Trackerレポートが新しい設定で正常に更新され、即時に反映されます。コンテンツ・サーバーを再起動する必要はありません。

8.4.5.1.2 config.cfgファイルを使用したインストール・プリファレンス変数の変更

1. テキスト・エディタでconfig.cfgを開きます。

   IntradocDir/config/config.cfg

2. 更新するインストール・プリファレンス変数が見つかるまでスクロールし、値を変更します。

3. config.cfgファイルを保存して閉じます。

4. コンテンツ・サーバーを再起動して変更内容を適用します。

8.4.5.2 データ・エンジン・コントロール・センターへのアクセス

データ・エンジン・コントロール・センターは、データ収集およびデータ削減を有効化、スケジュールおよび監視する場合に使用されます。

データ・エンジン・コントロール・センターにアクセスする手順は、次のとおりです。

1. Content Trackerの管理ページを開きます。

   「管理」トレイを選択し、「Content Tracker管理」を選択します。

2. スクロール・ダウンして、「データ・エンジン・コントロール・センター」アイコンをクリックします。

   「Content Trackerデータ・エンジン・コントロール・センター」インタフェースが表示されます。

8.4.5.3 データ収集の有効化または無効化

データ収集が有効化されている場合、Content Trackerではコンテンツ・サーバーのWebトラフィック・アクティビティが記録されます。デフォルトでは、「データ・エンジン・コントロール・センター」の「コレクション」タブで、「データ収集の有効化」チェック・ボックスが選択されています。このチェック・ボックスを選択すると、データ収集が有効化されます。このチェック・ボックスの選択を解除すると、データ収集が無効化されます。

データ収集を有効化または無効化する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「コレクション」タブで、「データ収集の有効化」チェック・ボックスを選択(収集を有効化する場合)するか、選択を解除(収集を無効化する場合)します。

3. 「OK」をクリックします。

   
   

   注意: 「OK」をクリックした後、すぐにアプレットを終了しないでください。「データ収集の状態が更新されました。」という確認メッセージが表示されるまで待機する必要があります。これには、数秒間かかることがあります。確認メッセージが表示される前にアプレットを終了すると、要求した変更が有効にならない場合があります。

   
   

4. 「データ収集の状態が更新されました。」という確認メッセージが表示された後に、「OK」をクリックします。

5. コンテンツ・サーバーを再起動します。

   
   

   注意: チェック・ボックスの上のテキストをよく読んで、データ収集が有効化されているか無効化されているかを確認してください。 有効化されている場合は、「データ収集が有効化されています...」というテキストが表示されます。 無効化されている場合は、「データ収集が有効化されていません...」というテキストが表示されます。

   
   

8.4.5.4 データ削減の手動実行

データを手動で削減する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「削減」タブで、削減する入力データのセットをクリックして選択します。

3. 「データの削減」ボタンをクリックします。

   「確認」ダイアログ・ボックスが表示されます。

4. データを削減するには、「はい」をクリックします。

   「ステータス」が「準備完了」から「実行中」に変わり、「完了(%)」にデータ削減の進行状況が表示されます。データ削減が完了すると、終了日時にタイムスタンプが表示され、「サイクル」に「最新」と表示されます。

   
   

   注意: 現在の日付のデータを削減するように選択した場合、データは削減されますが、「サイクル」には引き続きデータ・セットが「新規」として表示されます。

   
   

8.4.5.5 データ削減の自動実行の設定

データ削減の自動実行を設定する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「スケジュール」タブで、「スケジュール設定が有効化されています」チェック・ボックスを選択します。

3. データ収集を実行する日のチェック・ボックスを選択します。

4. データ収集を実行する時間および分を選択します。

5. 「OK」をクリックします。

   
   

   注意: 「OK」をクリックした後、すぐにアプレットを終了しないでください。「削減スケジュール情報が更新されました。」という確認メッセージが表示されるまで待機する必要があります。これには、数秒間かかることがあります。確認メッセージが表示される前にアプレットを終了すると、要求した変更が有効にならない場合があります。

   
   

6. 「削減スケジュール情報が更新されました。」という確認メッセージが表示された後に、「OK」をクリックします。

   データは、選択した日時に自動的に削減されます。

8.4.5.6 任意のサイクルのデータ・ファイルの削除

任意のサイクルのデータ・ファイルを削除する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「削減」タブで、削除する入力データのセットをクリックして選択します。

3. 「削除」ボタンをクリックします。

   「確認」ダイアログ・ボックスが表示されます。

4. データを削除するには、「OK」をクリックします。

   選択したデータ・セットが削除され、ウィンドウに表示されなくなります。

8.4.5.7 「アーカイブ」サイクルのデータ・ファイルの削除

「アーカイブ」サイクルのデータ・ファイルを削除する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「削減」タブで、「アーカイブの削除」ボタンをクリックします。

   「確認」ダイアログ・ボックスが表示されます。

3. データを削除するには、「OK」をクリックします。

   「アーカイブ」サイクルのすべてのデータ・セットが削除され、ウィンドウに表示されなくなります。

8.4.5.8 検索関連メタデータ・フィールドの作成

スナップショット機能を実装するには、その前に、有効化した各アクティビティ・メトリックに関連付けるカスタム・メタデータ・フィールドを決定する必要があります。また、このカスタム・メタデータ・フィールドはすでに存在し、正しい型である必要があります。有効化するアクティビティ・メトリックに応じて、適用可能な手順に従って1つ以上のカスタム・メタデータ・フィールドを作成する必要があります。

この項の内容は次のとおりです。

• 最終アクセス・メトリック用のカスタム・メタデータ・フィールドの作成

• 短期アクセスおよび長期アクセス・メトリック用のカスタム・メタデータ・フィールドの作成

8.4.5.8.1 最終アクセス・メトリック用のカスタム・メタデータ・フィールドの作成

最終アクセス・フィールドに割り当てるカスタム・メタデータ・フィールドを作成する手順は、次のとおりです。

1. Content Trackerの管理ページを開きます。

   「管理」トレイを選択し、「Content Tracker管理」を選択します。

2. 「構成マネージャ」アイコンをクリックします。

   「構成マネージャ」インタフェースが表示されます。

3. 「情報フィールド」タブで、「追加」をクリックします。

   カスタム情報フィールドの追加画面が表示されます。

4. 最終アクセス・メトリックに割り当てるメタデータ・フィールドの名前を入力します。たとえば、LastAccessのように入力します。

5. 「OK」をクリックします。

   カスタム情報フィールドの追加画面が表示されます。

6. 「フィールド・タイプ」メニューから「日付」を選択します。

   通常、「デフォルト値」フィールドに値を入力する必要はありません。ただし、デフォルト値が指定されていない場合にこのフィールドに値を入力しないと、コンテンツ・アイテムがチェックインされてデータ削減が実行されるまで、最終アクセス・フィールドは移入されません。ただし、一部のアプリケーションでは、最終アクセス・フィールドに常に有効な値を設定しておく必要があります。この場合、最終アクセス・フィールドにコンテンツのチェックインの日時が移入されるように、「デフォルト値」フィールドに値を入力する必要があります。詳細は、「「デフォルト値」を使用した最終アクセス・フィールドの移入」を参照してください。

   最終アクセス・カスタム・メタデータ・フィールドに必須の属性は、値が「日付」のフィールド・タイプのみです。ただし、最終アクセス・カスタム・メタデータ・フィールドを検索可能にする場合は、「検索索引の有効化」チェック・ボックスが選択されている必要があります。

   このカスタム・メタデータ・フィールドの索引付けはオプションですが、索引付けによってこのフィールドでの検索がより効率的になります。さらに、索引付けによって、蓄積された検索関連統計を問い合せて有用なデータを生成できます。たとえば、人気順に並べたコンテンツ・アイテムのリストを作成できます。

   検索関連メタデータ・フィールドの索引付けの長所および短所の詳細は、「「スナップショット」タブ」を参照してください。

7. 「OK」をクリックします。

   カスタム・メタデータ・フィールドが「情報フィールド」タブの「フィールド情報」リストに追加されます。

8. 「データベース設計の更新」をクリックして、現行データベースを検証し、カスタム・メタデータ・フィールドをシステムに追加します。

8.4.5.8.2 短期アクセスおよび長期アクセス・メトリック用のカスタム・メタデータ・フィールドの作成

短期アクセスおよび長期アクセス・フィールドに割り当てるカスタム・メタデータ・フィールドを作成する手順は、次のとおりです。

1. Content Trackerの管理ページを開きます。

   「管理」トレイを選択し、「Content Tracker管理」を選択します。

2. 「構成マネージャ」アイコンをクリックします。

   「構成マネージャ」インタフェースが表示されます。

3. 「情報フィールド」タブで、「追加」をクリックします。

   カスタム情報フィールドの追加画面が表示されます。

4. 短期アクセス・カウントおよび長期アクセス・カウント・メトリックに割り当てるメタデータ・フィールドの名前を入力します。たとえば、ShortAccess、LongAccessのように入力します。

5. 「OK」をクリックします。

   カスタム情報フィールドの追加画面が表示されます。

6. 「フィールド・タイプ」メニューから「整数」を選択します。

   短期アクセス・カウントおよび長期アクセス・カウント・カスタム・メタデータ・フィールドに必須の属性は、値が「整数」のフィールド・タイプのみです。ただし、短期アクセス・カウントおよび長期アクセス・カウント・カスタム・メタデータ・フィールドを検索可能にする場合は、両方のフィールドに対して「検索索引の有効化」チェック・ボックスが選択されている必要があります。

   これらのカスタム・メタデータ・フィールドの索引付けはオプションですが、索引付けによってこれらのフィールドでの検索はより効率的になります。さらに、索引付けによって、蓄積された検索関連統計を問い合せて有用なデータを生成できます。たとえば、人気順に並べたコンテンツ・アイテムのリストを作成できます。

   検索関連メタデータ・フィールドの索引付けの長所および短所の詳細は、「「スナップショット」タブ」を参照してください。

7. 「OK」をクリックします。

   カスタム・メタデータ・フィールドが「情報フィールド」タブの「フィールド情報」リストに追加されます。

8. 「データベース設計の更新」をクリックして、現行データベースを検証し、カスタム・メタデータ・フィールドをシステムに追加します。

8.4.5.9 スナップショット機能およびアクティビティ・メトリック・オプションの有効化

デフォルトでは、スナップショット機能およびアクティビティ・メトリックは無効になっています。これらのオプション機能を使用するには、最初に、アクティビティ・メトリック選択項目をアクティブにするスナップショット後処理機能を有効化する必要があります。次に、必要なアクティビティ・メトリックを選択して有効化し、事前に選択したカスタム・メタデータ・フィールドを割り当てます。

スナップショット機能を有効化し、アクティビティ・メトリックをアクティブ化する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「スナップショット」タブをクリックします。

3. 「スナップショットの後処理を有効化します。」チェック・ボックスを選択します。

   スナップショット機能が有効化され、アクティビティ・メトリック・オプションがアクティブ化されます。

4. 「OK」をクリックします。

   「確認」ダイアログ・ボックスが表示されます。

5. 「OK」をクリックします。

   スナップショットの状態およびContent Trackerの構成ファイル(sct.cfg)が更新されます。

   スナップショット機能およびアクティビティ・メトリックが有効化されていることを確認するには、次のディレクトリ内のContent Trackerのsct.cfgファイルにアクセスします。

   <cs_root>/data/contenttracker/config/sct.cfg

   オプションで、スナップショット機能を有効化し、アクティビティ・メトリック・オプションを手動でアクティブ化できます。特定のスナップショット構成変数の詳細は「構成変数」を、それらを手動で編集する方法の詳細は「Content Tracker構成変数の手動設定」を参照してください。

8.4.5.10 検索関連メタデータ・フィールドへのアクティビティ・メトリック機能のリンク

アクティビティ・メトリック・オプションは、アクティブ化した後、個別に選択して有効化する必要があります。アクティビティ・メトリックを有効化すると、対応するカスタム・メタデータ・フィールドもアクティブ化されます。

アクティビティ・メトリックを有効化し、対応するカスタム・メタデータ・フィールドをアクティブ化する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「スナップショット」タブをクリックします。

   スナップショット機能が有効化されている必要があり、そうでない場合は、アクティビティ・メトリック・オプションがアクティブ化されません。「スナップショット機能およびアクティビティ・メトリック・オプションの有効化」を参照してください。

3. 1つ以上のアクティビティ・メトリックのチェック・ボックスを選択します。

   選択した各アクティビティ・メトリックが有効化され、対応するカスタム・メタデータ・フィールドがアクティブ化されます。

4. 「フィールド」フィールドに、アクティビティ・メトリックにリンクするカスタム・メタデータ・フィールドの内部名を入力します。たとえば、xLastAccess、xShortAccess、xLongAccessのように入力します。

5. 短期アクセス・カウントおよび長期アクセス・カウントに、適用可能な時間間隔を日数で入力します。たとえば、短期アクセス・カウントに7日間、長期アクセス・カウントに28日間と入力します。

6. 「OK」をクリックします。

   「確認」ダイアログ・ボックスが表示されます。

7. 「OK」をクリックします。

   スナップショットの状態およびContent Trackerの構成ファイル(sct.cfg)が更新されます。

   Content Trackerでは、アクティビティ・メトリック・フィールド名に対して最小限のエラー・チェックが実行されます。「スナップショット」タブのフィールドでは大/小文字が区別されることに注意してください。すべてのフィールド値のスペルと大/小文字を正しく入力することが重要です。スナップショット機能に対する特定のContent Trackerエラー・チェックの詳細は、「「スナップショット」タブ」を参照してください。

   アクティビティ・メトリックが適切なカスタム・メタデータ・フィールドにリンクされていることを確認するには、次のディレクトリ内のContent Trackerのsct.cfgファイルにアクセスします。

   <cs_root>/data/contenttracker/config/sct.cfg

   オプションで、アクティビティ・メトリックをそれぞれのカスタム・メタデータ・フィールドに手動でリンクできます。特定のアクティビティ・メトリック構成変数の詳細は「構成変数」を、それらを手動で編集する方法の詳細は「Content Tracker構成変数の手動設定」を参照してください。

8.4.5.11 最終アクセス・メタデータ・フィールドのチェックイン時刻値の設定

通常、最終アクセス日付フィールドは、管理対象オブジェクトがユーザーおよびデータ削減実行によってリクエストされると、Content Trackerによって更新されます。このため、コンテンツ・サーバーのDocMetaデータベース表の最終アクセスフィールドは、次のデータ削減が実行されるまで空(NULL)になる場合があります。

ただし、アプリケーションによっては、最終アクセス・フィールドにコンテンツ・チェックインの日時が即時に記録される必要があります。この要件を満たすには、最終アクセス・フィールドに適切な日時の値が移入されている必要があります。Content Trackerでは、複数の方法を使用して最終アクセス・フィールドに値を移入できます。

この項の内容は次のとおりです。

• 「デフォルト値」を使用した最終アクセス・フィールドの移入

• 「自動ロード」オプションを使用した最終アクセス・フィールドの移入

• バッチロードおよびアーカイブのための最終アクセス・フィールドの移入

8.4.5.11.1 「デフォルト値」を使用した最終アクセス・フィールドの移入

通常、デフォルト値が指定されているフィールドに値を入力する必要はありません。ただし、デフォルト値が指定されていない場合に最終アクセス・フィールドに値を入力しないと、コンテンツ・アイテムのチェックイン時にフィールドは移入されません。チェックイン日付または最新アクセス日付は、データ削減が実行された後にのみ記録されます。

特定のアプリケーションの要件をサポートするには、「自動ロード」オプションを使用して、既存のコンテンツの最終アクセス・フィールドに値を移入できます(「「自動ロード」オプションを使用した最終アクセス・フィールドの移入」を参照)。将来のすべてのコンテンツ・アイテム・チェックイン用に、「デフォルト値」フィールドを設定することによって、最終アクセス・カスタム・メタデータ・フィールドを構成できます。

入力する値は、フィールドにコンテンツ・チェックインの日時を移入する関数または式である必要があります。これによって、現在の日時が最終アクセス・フィールドに自動的に入力されます。

「デフォルト値」を使用して最終アクセス・フィールドに移入する手順は、次のとおりです。

1. Content Trackerの管理ページを開きます。

   「管理」トレイを選択し、「Content Tracker管理」を選択します。

2. 「構成マネージャ」アイコンをクリックします。

   「構成マネージャ」インタフェースが表示されます。

3. 「情報フィールド」タブで、最終アクセス・メトリックにリンクしたカスタム・メタデータ・フィールドを選択し、「編集」をクリックします。

   カスタム情報フィールドの編集画面が表示されます。

   
   

   注意: 最終アクセス・カスタム・メタデータ・フィールドがすでに存在している必要があります。存在しない場合は作成して、最終アクセス・アクティビティ・メトリック機能にリンクする必要があります。「最終アクセス・メトリック用のカスタム・メタデータ・フィールドの作成」を参照してください。

   
   

4. 「デフォルト値」フィールドに、フィールドにコンテンツ・チェックインの日時を移入する式を入力します。

   たとえば、最終アクセス・フィールドに現在のチェックインの日時を移入するには、デフォルト値の<$dateCurrent()$>を指定できます。

5. 「OK」をクリックします。

   最終アクセス・カスタム・メタデータ・フィールドが更新されます。

6. 既存のコンテンツの最終アクセス・フィールドに値を移入します(「「自動ロード」オプションを使用した最終アクセス・フィールドの移入」を参照)。

8.4.5.11.2 「自動ロード」オプションを使用した最終アクセス・フィールドの移入

「スナップショット」タブの「自動ロード」オプションを使用すると、最終アクセス・フィールドのNULL値を遡って現在の日時に置き換えることができます。「自動ロード」オプションを使用すると、最終アクセス・メタデータ・フィールドが空(NULL)のDocMetaレコードのみが影響を受けます。

「自動ロード」オプションを使用して最終アクセス・フィールドに移入する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「スナップショット」タブをクリックします。

   スナップショット機能が有効化されている必要があり、そうでない場合は、アクティビティ・メトリック・オプションがアクティブ化されません。「スナップショット機能およびアクティビティ・メトリック・オプションの有効化」を参照してください。

3. 「最終アクセスの更新を有効化します。」チェック・ボックスを選択します。

4. 最終アクセス・メトリックを適用可能なカスタム・メタデータ・フィールドにリンクします(「検索関連メタデータ・フィールドへのアクティビティ・メトリック機能のリンク」を参照)。

5. 「自動ロード」チェック・ボックスを選択します。

6. 「OK」をクリックします。

   確認ダイアログ・ボックスが表示され、コンテンツ・サーバーのDocMetaデータベース表の適用可能な最終アクセス・フィールド(値がNULL)に現在の日時が挿入されます。

   
   

   ヒント: デフォルトでは、「自動ロード」問合せによって、最終アクセス・メタデータ・フィールドが現在の日時に設定されます。ただし、問合せをカスタマイズして、最終アクセス・フィールドを「dCreateDate」、「dReleaseDate」、またはアプリケーションのニーズを満たすその他の時刻に設定することもできます。「「自動ロード」オプションのSQL問合せのカスタマイズ」を参照してください。

   
   

8.4.5.11.3 バッチロードおよびアーカイブのための最終アクセス・フィールドの移入

アーカイブおよびバッチロードされたコンテンツを適切に保存するには、インポートまたは挿入用に最終アクセス・フィールドに日付を設定する必要があります。そうしないと、これらのコンテンツ・アイテムのアクセス日付はNULLになり、このフィールドに基づいた保存は失敗します。

注意: 最終アクセス日付をRetention Managerと組み合せて使用すると、保存スケジュールを保持できます。正常に保存するには、バッチロードおよびアーカイブ中にこのフィールドが適切に設定されていることを確認することが重要です。コンテンツが最後にアクセスされた時期を最も反映している日付を慎重に考慮してください。たとえば、1998年データのインポートは、インポートを実行する日付よりもその日付を使用したほうがタグ付けがうまくいく場合があります。

最終アクセス・フィールドの名前は、構成マネージャで指定した名前に基づいています(「最終アクセス・メトリック用のカスタム・メタデータ・フィールドの作成」を参照)。最終アクセスの場合は、xLastAccessがインポートまたは挿入で使用されます。「「スナップショット」タブ」で、「最終アクセスの更新を有効化します。」チェック・ボックスおよび対応するデータ・フィールドに関する項を参照してください。

コンテンツ・サーバーのバッチ・ローダーを使用して最終アクセス・フィールドに移入する手順は、次のとおりです。

1. バッチ・ローダーにアクセスします。

2. 適切な最終アクセス日付を確立するファイル・レコードを作成します。次に、適用可能なファイル・レコードの例を示します。

   # 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>>
   

3. バッチ・ローダーを実行して、ファイル・レコードを処理します。

   
   

   注意: 詳細は、『Oracle Fusion Middleware Content Serverシステム管理者ガイド』を参照してください。

   
   

8.4.5.12 スナップショット構成の編集

現行のスナップショット・アクティビティ・メトリック設定を変更する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「スナップショット」タブをクリックします。

   スナップショット機能が有効化されている必要があり、そうでない場合は、アクティビティ・メトリック・オプションがアクティブ化されません。「スナップショット機能およびアクティビティ・メトリック・オプションの有効化」を参照してください。

3. アクティビティ・メトリック・フィールドに必要な変更を加えます。

4. 「OK」をクリックします。

   「確認」ダイアログ・ボックスが表示されます。

5. 「OK」をクリックします。

   スナップショットの状態およびContent Trackerの構成ファイル(sct.cfg)が更新されます。

   Content Trackerでは、アクティビティ・メトリック・フィールド名に対して最小限のエラー・チェックが実行されます。「スナップショット」タブのフィールドでは大/小文字が区別されることに注意してください。すべてのフィールド値のスペルと大/小文字を正しく入力することが重要です。スナップショット機能に対する特定のContent Trackerエラー・チェックの詳細は、「「スナップショット」タブ」を参照してください。

   スナップショットおよびアクティビティ・メトリック構成変数の変更済の値を確認するには、次のディレクトリ内のContent Trackerのsct.cfgファイルにアクセスします。

   <cs_root>/data/contenttracker/config/sct.cfg

   オプションで、スナップショット・アクティビティ・メトリックの構成設定を手動で編集できます。特定のアクティビティ・メトリック構成変数の詳細は「構成変数」を、それらを手動で編集する方法の詳細は「Content Tracker構成変数の手動設定」を参照してください。

8.4.5.13 サービス・エントリの追加または編集

サービスを追加または編集する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「サービス」タブをクリックします。

3. 「追加」をクリックして、新規のサービス・エントリを作成します。

   または、「サービス名」リストから既存のサービス・エントリを選択し、「編集」をクリックします。

   「拡張されたサービス・トラッキング」画面が表示されます。新規のサービス・エントリを追加する場合、フィールドは空です。

   既存のサービス・エントリを編集する場合は、フィールドに値が移入されます。この場合、「サービス名」フィールドが非アクティブになります。

4. 適用可能なフィールド値を入力または変更します(「フィールドの変更」フィールドの値を除く)。

   このサービス・エントリをフィールド・マップResultSetにリンクする場合は、「フィールドの変更」フィールドに適用可能な名前を入力します。次に、「フィールド・マップResultSetの追加およびサービス・エントリへのリンク」の手順を参照してください。

5. 「OK」をクリックします。

   「確認」ダイアログ・ボックスが表示されます。

6. 「OK」をクリックします。

   「拡張されたサービス・トラッキング」画面が閉じ、データ・エンジン・コントロール・センターの「サービス」タブが表示されます。

   新規のサービス・エントリを追加した場合は、「サービス」リストにそのエントリが追加されます。既存のサービス・エントリを編集した場合は、「サービス」リストに更新済のフィールド値が追加されます。

   サービス状態およびContent TrackerのSctServiceFilter.hdaが更新されます。

   Content Trackerでは、データ・エンジン・コントロール・センターの拡張されたサービス・トラッキング機能に対して、エラー・チェック(フィールド・タイプやスペルの検証など)は実行されません。削減を実行するまで、エラーは生成されません。これらのフィールドでは大/小文字が区別されます。このため、新規のサービスを追加したり、既存のサービスを編集する場合は、サービス・コール名を正確に入力するように注意してください。すべてのフィールド値が正しいスペルおよび大/小文字になるようにします。

   サービス・エントリの値がSctServiceFilter.hdaファイルに追加されていること、または既存のサービス・エントリの値が適切に変更されていることを確認するには、次のディレクトリ内のContent TrackerのSctServiceFilter.hdaファイルにアクセスします。

   <cs_root>/data/contenttracker/config/SctServiceFilter.hda

   オプションで、サービスを手動で追加または編集できます。SctServiceFilter.hdaファイル内のサービス・エントリの詳細は「サービス・コール構成ファイルについて」を、それらを手動で編集する方法の詳細は「SctServiceFilter.hdaファイルの手動編集」を参照してください。

8.4.5.14 フィールド・マップResultSetの追加およびサービス・エントリへのリンク

拡張されたサービス・コール・トラッキング機能を実装するには、サービス・エントリをSctServiceFilter.hdaファイル内のフィールド・マップResultSetにリンクする必要があります。

フィールド・マップResultSetを追加してサービス・エントリにリンクする手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「サービス」タブをクリックします。

3. 「サービス名」リストから必要なサービス・エントリを選択します。

   新規のサービス・エントリを追加する必要がある場合は、「サービス・エントリの追加または編集」の手順を参照してください。

4. 「編集」をクリックします。

   「拡張されたサービス・トラッキング」画面が表示され、選択したサービス・エントリの値がフィールドに移入されます。この場合、「サービス名」フィールドが非アクティブになります。必要な場合は、フィールド・マップResultSetの追加に加えて、このサービス・エントリの値をここで編集できます。

   このサービスがすでにフィールド・マップResultSetにリンクされている場合は「フィールドの変更」フィールドに名前がリストされ、データ・フィールド、格納場所および表列の1つ以上のセットが「フィールド名」、「フィールドの場所」および「列名」フィールドにリストされます。既存のデータ・フィールド、格納場所および表列のセットを編集または削除する場合は、「フィールド・マップResultSetの編集」の手順を参照してください。

5. 選択したサービスがすでにフィールド・マップResultSetにリンクされている場合は、この手順をスキップしてください。ただし、選択したサービスがセカンダリResultSetにリンクされていない場合、「フィールドの変更」フィールドは空です。フィールド・マップResultSetの名前を入力してください。

6. 「追加」をクリックします。

   「フィールドの変更」画面が表示されます。

7. フィールドに適切な値を入力します。

8. 「OK」をクリックします。

   「フィールドの変更」画面が閉じ、値が「フィールド名」および「列名」フィールドに追加されます。

   
   

   注意: データ・フィールド、格納場所および表列の複数のセットを追加する場合は、必要に応じて手順6から8を繰り返します。

   
   

9. 「OK」をクリックします。

   「確認」ダイアログ・ボックスが表示されます。

   「拡張されたサービス・トラッキング」画面が閉じ、データ・エンジン・コントロール・センターの「サービス」タブが表示されます。

   サービス状態およびContent TrackerのSctServiceFilter.hdaファイルが更新されます。

10. 「OK」をクリックします。

    Content Trackerでは、データ・エンジン・コントロール・センターの拡張されたサービス・トラッキング機能に対して、エラー・チェック(フィールド・タイプやスペルの検証など)は実行されません。削減を実行するまで、エラーは生成されません。これらのフィールドでは、大/小文字が区別されます。このため、新規のフィールド・マップResultSetを追加したり、既存のフィールド・マップResultSetを編集する場合は、DataBinderフィールド名およびSctAccessLog表の列名を正確に入力するように注意してください。すべてのフィールド値が正しいスペルおよび大/小文字になるようにします。

    フィールド・マップResultSetの値がサービス・コール構成ファイルに追加されていること、または値が適切に変更されていることを確認するには、次のディレクトリ内のContent TrackerのSctServiceFilter.hdaファイルにアクセスします。

    <cs_root>/data/contenttracker/config/SctServiceFilter.hda

    オプションで、フィールド・マップResultSetを手動で追加し、サービス・エントリに手動でリンクできます。SctServiceFilter.hdaファイル内のサービス・エントリおよびフィールド・マップResultSetの詳細は「サービス・コール構成ファイルについて」を、それらを手動で編集する方法の詳細は「SctServiceFilter.hdaファイルの手動編集」を参照してください。

8.4.5.15 フィールド・マップResultSetの編集

フィールド・マップResultSetを編集する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「サービス」タブをクリックします。

3. 「サービス名」リストから必要なサービス・エントリを選択します。

4. 「編集」をクリックします。

   「拡張されたサービス・トラッキング」画面が表示され、選択したサービス・エントリの値がフィールドに移入されます。この場合、「サービス名」フィールドが非アクティブになります。必要な場合は、フィールド・マップResultSetの編集に加えて、このサービス・エントリの他のフィールド値も編集できます。

5. 次のいずれかの方法でフィールド・マップResultSetを編集します。

   • データ・フィールド、格納場所および表列のセットを1つ以上追加します。「フィールド・マップResultSetの追加およびサービス・エントリへのリンク」の手順を参照してください。

   • データ・フィールド、格納場所および表列のセットを1つ以上削除する手順は、次のとおりです。

   • 削除するフィールド、格納場所および表列のセットを選択します。

   • 「削除」をクリックします。

1. 「OK」をクリックします。

   「確認」ダイアログ・ボックスが表示されます。

2. 「OK」をクリックします。

   「拡張されたサービス・トラッキング」画面が閉じ、データ・エンジン・コントロール・センターの「サービス」タブが表示されます。サービス状態およびContent TrackerのSctServiceFilter.hdaファイルが更新されます。

   Content Trackerでは、データ・エンジン・コントロール・センターの拡張されたサービス・トラッキング機能に対して、エラー・チェック(フィールド・タイプやスペルの検証など)は実行されません。削減を実行するまで、エラーは生成されません。これらのフィールドでは、大/小文字が区別されます。このため、データ・フィールド、格納場所および表列のセットを1つ以上追加することによってフィールド・マップResultSetを編集する場合は、データ・フィールド名、格納場所名、およびSctAccessLog表の列名を正確に入力するように注意してください。すべてのフィールド値が正しいスペルおよび大/小文字になるようにします。

   フィールド・マップResultSet内にあるデータ・フィールド、格納場所および表列のセットの変更済の値を確認するには、次のディレクトリ内のContent TrackerのSctServiceFilter.hdaファイルにアクセスします。

   <cs_root>/data/contenttracker/config/SctServiceFilter.hda

   オプションで、フィールド・マップResultSet内にあるデータ・フィールド、格納場所および表列のセットの値を手動で変更できます。SctServiceFilter.hdaファイル内のフィールド・マップResultSetの詳細は「サービス・コール構成ファイルについて」を、それらを手動で編集する方法の詳細は「SctServiceFilter.hdaファイルの手動編集」を参照してください。

8.4.5.16 サービス・エントリの削除

サービスを削除する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「サービス」タブをクリックします。

3. 「サービス」リストで、削除するサービス・エントリを選択します。

4. 「削除」をクリックします。

   このサービス・エントリのサービス・ロギングを削除することを確認するように求められます。

5. 「はい」をクリックします。

   選択したサービス・エントリが「サービス」リストから削除され、SctServiceFilter.hdaファイルから削除されます。

   サービス・エントリが削除されたことを確認するには、次のディレクトリ内のContent TrackerのSctServiceFilter.hdaファイルにアクセスします。

   <cs_root>/data/contenttracker/config/SctServiceFilter.hda

   オプションで、特定のサービス・エントリを手動で削除できます。詳細は、「SctServiceFilter.hdaファイルの手動編集」を参照してください。

8.4.5.17 フィールド・マップResultSetの削除

フィールド・マップResultSetを削除する手順は、次のとおりです。

1. 「データ・エンジン・コントロール・センター」を開きます(「データ・エンジン・コントロール・センターへのアクセス」を参照)。

2. 「サービス」タブをクリックします。

3. 「サービス」リストで、削除するフィールド・マップResultSetにリンクされているサービス・エントリを選択します。

4. 「編集」をクリックします。

   「拡張されたサービス・トラッキング」画面が表示され、選択したサービス・エントリの値がフィールドに移入されます。

5. 「フィールドの変更」フィールドから、フィールド・マップResultSet名を削除します。

6. データ・フィールド、格納場所および表列のセットを選択し、「削除」をクリックします。

   データ・フィールド、格納場所および表列のセットがリストから削除されます。(必要に応じて)データ・フィールド、格納場所および表列のセットごとに、この手順を繰り返します。

7. 「OK」をクリックします。

   フィールド・マップResultSetがSctServiceFilter.hdaファイルから削除されます。サービス・エントリへのリンクが解除されます。

   フィールド・マップResultSetが削除されたことを確認するには、次のディレクトリ内のContent TrackerのSctServiceFilter.hdaファイルにアクセスします。

   <cs_root>/data/contenttracker/config/SctServiceFilter.hda

   オプションで、フィールド・マップResultSetを手動で削除できます。詳細は、「SctServiceFilter.hdaファイルの手動編集」を参照してください。

8.4.5.18 WebビーコンIDリストへのWebビーコン・オブジェクト名の追加または編集

Webビーコン・オブジェクト・リストのプリファレンスを設定したり、設定を編集する手順は、次のとおりです。

1. コンテンツ・サーバーに管理者としてログインします。

2. 「管理」メニューから「管理サーバー」を選択します。

   「コンテンツ管理サーバー」ページが表示されます。

3. Webビーコン・プリファレンス設定を変更するコンテンツ・サーバー・インスタンスの名前をクリックします。

   コンテンツ管理サーバー<instance_name>ページが表示されます。

4. 「コンポーネント・マネージャ」をクリックします。

   コンポーネント・マネージャ・ページが表示されます。

5. 「コンポーネント構成の更新」フィールドで、リストから「Content Tracker」を選択します。

6. 「更新」をクリックします。

   コンポーネント構成の更新ページが表示されます。

7. SctWebBeaconIDListプリファレンス・フィールドに、適用可能なWebビーコン・オブジェクトのdDocNameをカンマで区切って入力します。

8. 「更新」をクリックします。

9. コンテンツ・サーバーを再起動して変更内容を適用します。

8.5 レポートの生成

Content Trackerレポートでは、取得されて削減されたデータを使用して、特定のコンテンツ部分の使用状況履歴の概要を示すレポートが生成されます。提供されている事前定義済レポートを使用したり、追跡する情報に対するカスタム問合せを作成できます。オプションで、外部の市販レポート作成ツールを使用することもできます。「外部レポート作成ツール」を参照してください。

注意: デフォルトでは、Content Trackerは複数の最適化機能を使用してパフォーマンスが最大になるように構成されます(「パフォーマンス最適化機能」を参照)。このため、Content Trackerでは、コンテンツ・アクセス・イベントのデータのみが収集および記録されます。この処理には、検索などのコンテンツ・アクセス・イベント以外での情報収集や、ユーザー・プロファイルの概要の収集および統合は除外されます。 コンテンツ・イベント以外のデータは収集されないため、Content Trackerレポートの生成メイン・ページには様々な事前定義済レポートのオプションは表示されません。ただし、Content Trackerを再構成した場合は、事前定義済レポートのすべてのオプションが使用可能になります。これを行うには、最適化機能の設定を変更します(「パフォーマンス最適化機能の変数設定の変更」を参照)。

注意: ユーザー・レポートが表示されるのは、コンテンツ・アクセスのみ操作モードが無効な場合のみです。「パフォーマンス最適化機能」を参照してください。

レポートは、特定のユーザー、ユーザー・グループ、およびメタデータ値の問合せやグループによって定義可能なコンテンツのセットなど、広範な基準から導出できます。Content Trackerレポートでは、システム内の変数(ユーザーの数、コンテンツの量、メタデータ・カウントなど)に基づいて、数百個もの主要なメトリックをレポートに含めることができます。特化したレポートによって、ユーザーに最も関連性の高いコンテンツを把握して公開できます。

この項の内容は次のとおりです。

• OracleおよびDB2の大/小文字の区別

• アクセス制御リストおよびContent Trackerレポートのセキュア・モード

• 事前定義済レポート

• カスタム・レポート

• 外部レポート作成ツール

• ユーザー認証/認可および監査

• Site StudioのWebサイト・アクティビティ・レポート作成

• セキュリティ・チェックと問合せ結果

• Content Trackerレポートの使用

8.5.1 OracleおよびDB2の大/小文字の区別

OracleまたはDB2をコンテンツ・サーバー・データベースとして使用する場合、メタデータ値は大/小文字が区別されるため、適用可能な問合せレポート基準にコンテンツ・メタデータ値を入力する際に注意する必要があります。このため、対応するフィールドにどのように値を入力したかによって、Content Trackerレポートで一部の可能な一致ファイルが返されない場合があります。

OracleまたはDB2のコンテンツ・サーバー・データベースを使用する場合、値はコンテンツ・サーバーで入力されたとおりに正確に入力する必要があります。したがって、コンテンツ・サーバー内の値の文字構造に基づいて、問合せメタデータ・フィールドに、すべて小文字、すべて大文字、または大文字と小文字の組合せで値を入力する必要があります。そうしないと、Content Trackerレポートでは、一致するファイルの一部が返されません。

たとえば、OracleまたはDB2のコンテンツ・サーバー・データベースがAdAccであるのに、ユーザーが問合せフィールドにadacc、ADACCまたはAdaccと入力した場合、Content Trackerレポートでは結果が返されません。この場合、大文字と小文字の組合せを使用してコンテンツ・タイプ・メタデータ値を入力する必要があります。これは、各事前定義問合せレポートのすべてのメタデータ・フィールドに適用されます。

8.5.2 アクセス制御リストおよびContent Trackerレポートのセキュア・モード

Content Trackerレポートのコンポーネントをインストールすると、セキュリティ・チェック・プリファレンス変数(SctrEnableSecurityChecks)が設定されます。基本的に、このプリファレンス変数では、2つのセキュリティ・モード(セキュア・モードおよび非セキュア・モード)のいずれかを選択できます。セキュリティ・チェック・プリファレンスには、個々のユーザー・ロールおよびアカウント情報を使用して、レポート結果におけるコンテンツ・アイテム情報の表示を制限するためのオプションがあります。

これは、生成されるレポートでユーザーに表示されるコンテンツ・アイテム(およびその後のメタデータ)を制御することを意味します。ユーザーがコンテンツ・サーバー検索で見つけられなかった内容はContent Trackerレポートでも表示されないようにすることが理想的です。したがって、セキュア・モードを選択すると、生成されるレポートの情報は、ユーザーのロールおよびアカウント権限に基づいてフィルタ処理されます。

ただし、コンテンツ・サーバー・インスタンスに対してアクセス制御リスト(ACL)を有効化した場合、Content Trackerレポートのセキュア・モード・オプションは機能しません。インストール時は、セキュリティ・チェック・プリファレンス・チェック・ボックスを空白にしておく必要があります。これは、ACLベースのシステムでは、セキュア・モードが無効になっている必要があることを意味します。この場合、システム管理者以外のユーザーに、本来はアクセスと表示の権限を付与していないコンテンツ・アイテムの情報が表示される可能性があります。

注意: セキュリティ・チェック・インストール・プリファレンスの詳細、およびそれがレポート問合せとレポート結果に与える影響の詳細は、「セキュリティ・チェックと問合せ結果」を参照してください。

8.5.3 事前定義済レポート

Content Trackerレポートには、最も頻繁にリクエストされるトピックのレポートを生成するのに使用できる多くの事前定義済レポート・オプションが用意されています。

この項の内容は次のとおりです。

• デフォルトのレポート・フォーマット

• コンテンツ・ダッシュボード機能

• ドリルダウン・レポート機能

8.5.3.1 デフォルトのレポート・フォーマット

Content Trackerレポートの生成メイン・ページを使用して生成される各レポートは、全般のフォーマットや視覚的なレイアウトが同じです。次に、Content Trackerレポートの生成メイン・ページにアクセスするとデフォルトで選択される「上位アクセス・コンテンツ・アイテム」レポートを示します。レポートで提供される情報は、SctAccessLogデータベース表およびその他のコンテンツ・サーバー・データベース表(必要な場合)の削減済データから抽出されます。

「Content Trackerレポートの生成」のコンパイル済結果に含まれるのは、コンテンツ・アイテムを実際にリクエストして開いたユーザーのみです。開かれるコンテンツ・アイテムは、Webロケーション・ファイル(コンテンツ・アイテムへの絶対パス)、HTMLバージョン(Dynamic Converterを使用)、または実際のネイティブ・ファイルです。コンテンツ情報ページのみを開いたユーザーは、追跡データに含まれません。

通常、ユーザーがコンテンツ・アイテムにアクセスしてから、その情報が「Content Trackerレポートの生成」のアクセス履歴結果に含められるまでに、1日の遅れがあります。情報は最初にContent Trackerによって蓄積され、次にデータ削減サイクルを経過する必要があります。このため、コンテンツ・アイテムのアクセス履歴結果は、SctAccessLogおよびその他のコンテンツ・サーバー・データベース表の削減済データから導出されます。データを手動で削減すると即時にデータベース表が更新され、その後、生成された問合せレポートにも更新済の情報が表示されます。削減プロセスの詳細は、「「削減」タブ」を参照してください。

フィールド	説明
「レポート名」フィールド	選択された問合せレポートの名前です。
「日付」フィールド	「開始日」フィールドおよび「終了日」フィールドに入力された日付です。具体的な日付を入力していない場合、問合せでは、デフォルトの日付が使用されます。
結果表の列	選択されたレポートに関連する情報が表示されます。
「印刷用バージョン」リンク	新しいブラウザ・ウィンドウを開いて、ナビゲーション・トレイのないレポートが表示されます。

8.5.3.2 コンテンツ・ダッシュボード機能

生成された問合せレポートに特定のコンテンツ・アイテムへのアクティブなリンクが含まれる場合は、リンクをクリックすると、対応するコンテンツ・ダッシュボードが表示されます。次の画面キャプチャのコンテンツ・ダッシュボードは、特定のコンテンツ・アイテムの2つのバージョンがそれぞれ3回アクセスされたことを示しています。このビューでは、リビジョン・アクセス結果が個別に示されています。

コンテンツ・ダッシュボードの「すべてのバージョン」リンクをクリックすると、両方のバージョンのアクセス結果が結合されます。

8.5.3.3 ドリルダウン・レポート機能

事前定義済レポートごとに、様々なレベルのレポート結果が生成されます。Content Trackerレポートの生成メイン・ページで入力した検索条件に基づいて、結果が適宜フィルタ処理されます。最上位レベルのレポートはサマリー・レポートで、一般性の高い情報が示されます。最上位レベルのレポートにあるリンクを使用して、より具体的な情報にドリルダウンできます。

8.5.4 カスタム・レポート

Content Trackerレポートで提供されているサンプル・レポートに加えて、情報を追跡するためのカスタム問合せも作成できます。ただし、カスタム・レポート問合せの作成を開始する前に、問合せの設計方法に関連するいくつかの問題に注意する必要があります。

この項の内容は次のとおりです。

• カスタム・レポート問合せとOracle

• カスタム・レポート問合せと拡張されたサービス・トラッキング

• カスタム・レポート問合せの表示結果

8.5.4.1 カスタム・レポート問合せとOracle

Oracleおよびエイリアスを使用して、生成されるレポートに列名を表示するには、次のファイルに別名を追加する必要があります。

/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>

8.5.4.2 カスタム・レポート問合せと拡張されたサービス・トラッキング

拡張されたサービス・トラッキング機能を使用する場合は、SQL問合せを設計する前に、SctAccessLog表の特定の列に書き込まれるデータ値に注意する必要があります。特に、サービスの名前は常にsc_scs_idcService列に記録されることに注意してください。このため、拡張フィールドのコンテンツを使用する問合せには、修飾子としてサービス名を含める必要があります。

拡張されたサービス・トラッキング機能の詳細は、「サービス・コール構成ファイルについて」および「「サービス」タブ」を参照してください。

8.5.4.3 カスタム・レポート問合せの表示結果

カスタム・レポート問合せをレポート問合せファイルに追加した後は、それを使用して結果を表示できるようになります。

図8-1 カスタム・レポート・リンク

図8-2 生成されたカスタム・レポート

図8-3 ドリルダウン・レポート

8.5.5 外部レポート作成ツール

市販のレポート生成ツールを使用して、Content Trackerで収集されたデータから基本的なテキスト・レポートや、より高度なグラフィック(棒グラフや円グラフなど)を生成できます。

注意: このガイドでは、カスタム・レポートの作成で使用する外部レポート作成ツールについての包括的な操作知識がユーザーにあること、またはユーザーがツールを使い慣れていることを前提としています。このため、この項では、ほとんどの市販のレポート作成製品に適用できるごく基本的なガイドラインのみ示しています。

8.5.6 ユーザー認証/認可および監査

Content Trackerレポートは、システムまたは権限で保護されたコンテンツ・アイテムへの失敗したアクセス試行を監視できる監査機能を備えています。セキュリティ違反のアクセス試行の分析に役立つ2つのレポートが用意されており、これらのレポートには、失敗したユーザー・ログオン、およびセキュアなコンテンツ・アイテムへの失敗したアクセス試行が表示されます。この情報は、システムやコンテンツのセキュリティを保護したり、監査証跡およびレコードを適切に保持するために不可欠です。

使用可能な監査レポートは次のとおりです。

• ユーザーによる認可の失敗

  このレポートには、ユーザー名とそのIPアドレスを含む、アクセス認可の否認情報が示されます。これらのユーザーにはシステム・アクセス権限がありますが、ユーザーのロールまたはアカウントのメンバーシップによって特定のコンテンツ・アイテムへのアクセス(給与コンテンツへのアクセスなど)が制限される場合があります。

• ログイン失敗

  このレポートには、ユーザー名とそのIPアドレスを含む、ログインおよび認証の失敗情報が示されます。ログインが成功しないとユーザー・タイプを区別できないため、ログに記録されたデータでは、外部ユーザー、内部ユーザーおよびグローバル・ユーザーは区別されていません。

8.5.7 Site StudioのWebサイト・アクティビティ・レポート作成

Site Studioを使用している場合は、Site Studioアクティビティが追跡されるようにContent Trackerが自動的に構成されます。Content Trackerレポートでは、ログに記録されたデータを使用して、Webサイト・アクセス結果を要約する事前定義済レポートが生成されます。

この項の内容は次のとおりです。

• メイン・ページのSite Studioレポート・リンク

• Site Studioの事前定義済レポート

8.5.7.1 メイン・ページのSite Studioレポート・リンク

Site Studioをインストールしている場合は、Content Trackerレポートの生成メイン・ページに、Site Studioに固有のWebアクセス・レポートが表示されます。

8.5.7.2 Site Studioの事前定義済レポート

Site Studioの事前定義済レポートでは、Content Trackerレポートのデフォルト・フォーマットが使用され、ドリルダウン・レポート機能が提供されます。どちらの場合も最上位レベル・レポートは、「サイトID」および「アクセス」を汎用基準として使用したサマリー・レポートです。ドリルダウン・レポートには、関連する統計が示されます。

• Webサイト・コンテンツへのアクセス

  このレポートは、最上位レベルではIDベースで、それ以降のドリルダウン・レポートでは結果がコンテンツID別および相対URL別にリストされます。この情報によって、Webサイトへのアクセスに使用されているURLが示されます。ただし、実際には、多数の異なるURLで同じページが表示される場合もあります。このため、このレポートの結果には、ユーザーがノードにアクセスした方法に関係なく、ノードの合計ヒット数も含まれます。

• URLを使用したWebサイト・アクセス

  このレポートには、Webサイト相対URLおよび関連するアクティビティ合計が要約されます。

  
  

8.5.8 セキュリティ・チェックと問合せ結果

Content Trackerレポートのインストール・プロセス中に、個々のユーザー・ロールおよびアカウント情報を使用して、レポート結果におけるコンテンツ・アイテム情報の表示を制限することもできます。これは、生成されるレポートでユーザーに表示されるコンテンツ・アイテム(およびその後のメタデータ)を制御することを意味します。ユーザーがコンテンツ・サーバー検索で見つけられなかった内容はContent Trackerレポートでも表示されないようにすることが理想的です。

注意: コンテンツ・サーバー・インスタンスに対してアクセス制御リスト(ACL)を有効化した場合、Content Trackerレポートのセキュア・モード・オプションは機能しません。詳細は、「アクセス制御リストおよびContent Trackerレポートのセキュア・モード」を参照してください。

この項の内容は次のとおりです。

• セキュリティ・チェック・プリファレンス変数

• レポート問合せとセキュリティ・モード

• セキュリティ・モードの選択

• レポート問合せセキュリティのカスタマイズ

8.5.8.1 セキュリティ・チェック・プリファレンス変数

Content Trackerレポートのコンポーネントをインストールすると、セキュリティ・チェック・プリファレンス変数(SctrEnableSecurityChecks)が設定されます。このプリファレンス変数では、2つのセキュリティ・モード(セキュア・モードおよび非セキュア・モード)のいずれかを選択できます。セキュア・モードではレポート問合せを実行しているユーザーが考慮されますが、非セキュア・モードでは考慮されません。

注意: インストール時に、使用するモードを選択するには、セキュリティ・チェック・チェック・ボックスを選択するか、またはこのチェック・ボックスを空白のままにします。インストール後に、コンポーネント・マネージャを使用して設定を変更することもできます(「セキュリティ・チェック・プリファレンス設定の変更」を参照)。

この項の内容は次のとおりです。

• セキュリティ・チェック・プリファレンス変数の値

• セキュリティ・モードの例

8.5.8.1.1 セキュリティ・チェック・プリファレンス変数の値

セキュリティ・チェック・プリファレンス変数の値は、次のとおりです。

• SctrEnableSecurityChecks=True(チェック・ボックスが選択された状態)に設定すると、セキュリティ・チェック・インストール・プリファレンスが有効化され、Content Trackerレポートがセキュア・モードで動作するように構成されます。

  セキュア・モードでは、コンテンツ・サーバーの検索結果を制限するのに使用されたのと同じセキュリティ基準(ロールおよびアカウントの制限)が、「Content Trackerレポートの生成」の問合せおよび生成されるレポートにも適用されます。このため、2つの異なるユーザーが「上位アクセス・コンテンツ・アイテム」レポートを実行した場合、異なる結果が表示されることがあります。「セキュア・モードの例」の項でセキュア・モードの例を参照してください。

• SctrEnableSecurityChecks=False(チェック・ボックスが選択解除された状態)に設定すると、セキュリティ・チェック・インストール・プリファレンスが無効化され、Content Trackerレポートが非セキュア・モードで動作するように構成されます。これはデフォルトの設定です。

  非セキュア・モードの場合、コンテンツ・サーバーの検索結果を制限するのに使用された追加のロールおよびアカウント基準は、「Content Trackerレポートの生成」の問合せおよび生成されるレポートに適用されません。このため、システム管理者以外のユーザーに、アクセスと表示の権限を付与していないコンテンツ・アイテムの情報が表示される可能性があります。「セキュア・モードの例」の項で非セキュア・モードの例を参照してください。

8.5.8.1.2 セキュリティ・モードの例

ユーザーが、管理者権限、コントリビュータ権限、ゲスト権限およびシステム・マネージャ権限を持っている(準管理者ユーザー)が、特定のコンテンツ・アイテム(給与レポートなど)を表示するための適切なロールまたはアカウントのメンバーシップを持っていないとします。割り当てられた権限を使用すると、このユーザーはコンテンツ・サーバー管理者ページにアクセスでき、結果的には、Content Trackerレポートの生成メイン・ページにアクセスできます。ただし、このユーザーがコンテンツ・サーバーで標準検索を実行した場合、結果ページには給与レポートが存在することは示されません。

セキュリティ・チェック・プリファレンス変数が有効化されている場合、Content Trackerレポートでは、同じロールおよびアカウントのメンバーシップ・チェックが実施されます。次に、特定のレポートをリクエストしたユーザーに応じて、ロールおよびアカウントの照合アクティビティが実行され、対象になるコンテンツ・アイテム使用状況データが決まります。

次の各例に示すように、特定のユーザー(前述の準管理者ユーザー)に対して生成されるレポート結果は、プリファレンス変数が有効化されているかどうかによって異なります。

• セキュア・モードの例:

  セキュリティ・チェック・プリファレンスが有効化されている場合、Content Trackerレポートはセキュア・モードで実行され、ロールおよびアカウントの一致がチェックされます。この場合、準管理者ユーザーは機密データを取得および表示する資格がありません。このユーザーのロールおよびアカウント権限に関連付けられた制限によって、給与コンテンツ・アイテムは常にまったく表示されません。データはレポート結果に含まれず、ユーザーはデータの存在も認識できません。

• 非セキュア・モードの例:

  セキュリティ・チェック・プリファレンスが無効化されている場合、Content Trackerレポートは非セキュア・モードで実行され、ロールおよびアカウントの一致はチェックされません。この場合、準管理者ユーザーは、給与レポートに対してアクセスまたは表示する資格がなくても、給与コンテンツ・アイテムに関連付けられた機密情報の一部を取得できます。

  少なくとも、ユーザーは給与レポートの存在を知り、そのメタデータの一部を表示できます。この状況における危険性は、メタデータに含まれている情報の種類によって異なります。場合によっては、コンテンツ・アイテムが存在することを知るだけでも、重大なセキュリティ違反になることがあります。

  
  

  注意: このようなセキュリティ違反は、準管理者ユーザーにかぎらず発生します。たとえば、権限のないユーザー(つまり、通常は検索結果ページの特定のコンテンツ・アイテムを表示する権限のないユーザー)がContent Trackerレポートの生成メイン・ページにアクセスできることがあります。これは、管理者ページにアクセスしたり、URLを推測することによって可能になります。この場合、制限されているコンテンツ・アイテムを記述したメタデータの一部を含むレポートがユーザーに表示されます。

  
  

8.5.8.2 レポート問合せとセキュリティ・モード

contenttrackerreports_query.htmファイルには、事前定義済レポートおよびカスタム・レポートを生成する「Content Trackerレポートの生成」のすべての問合せが含まれます。非セキュア・モードおよびセキュア・モードをサポートするために、このファイルには2つの問合せセットが含まれます。一方のセットでは問合せを実行するユーザーが考慮され(セキュア・モード)、もう一方のセットでは考慮されません(非セキュア・モード)。セキュリティ・チェック・プリファレンス設定によって、使用される問合せセットが決まります(「セキュリティ・チェック・プリファレンス変数」を参照)。

注意: ローカライゼーションのサポートのために、事前定義済レポート名の「document」という語は「content item」に変更されています。ただし、これまでと同様に、対応するレポート問合せにはWordドキュメントの略語(doc)が含まれます。contenttrackerreports_query.htmファイル内のレポート問合せ名は変更されていません。 たとえば、「上位アクセス・コンテンツ・アイテム」レポートは、Content Trackerレポートの生成メイン・ページにリストされる事前定義済レポートの1つです。contenttrackerreports_query.htmファイル内の対応するレポート問合せには、既存のネーミング規則が使用されます。 qSctrTopDocs(非セキュア・バージョン) qSctrTopDocs_SEC(セキュア・バージョン)

この項の内容は次のとおりです。

• 事前定義済レポートとセキュリティ・モード

• カスタム・レポートとセキュリティ・モード

8.5.8.2.1 事前定義済レポートとセキュリティ・モード

ほとんどすべての事前定義済レポート問合せでは、contenttrackerreports_query.htmファイルにセキュア・フォームと非セキュア・フォームの両方が含まれます。一般に、問合せの検索結果がユーザー・ロールおよびアカウント権限の影響を受ける可能性がある場合は、非セキュアな問合せのセキュアなバリアントが含められます。また、セキュリティ・チェック・プリファレンス変数が有効化されている場合は、問合せのセキュア・フォームが優先され、対応する非セキュアな問合せにかわって実行されます。

レポート問合せごとにセキュリティ・チェック・プリファレンス変数を選択的に有効化または無効化することはできません。ただし、contenttrackerreports_query.htmファイルをカスタマイズして、セキュアな問合せおよび非セキュアな問合せを管理することは可能です。実際には、特定の問合せのセキュア・フォームを削除または名前変更することによって、その問合せのセキュリティ・チェック(アカウント照合)を無効化できます。このため、セキュリティ・チェック・プリファレンス変数が有効化されていても、特定の問合せのセキュア・フォームがcontenttrackerreports_query.htmファイル内に見つからない場合、レポートの生成には問合せの非セキュア・フォームが使用されます。

特定の事前定義済問合せに対してセキュリティ・チェックを使用する方法の詳細は、「レポート問合せのセキュリティ・チェックの有効化または無効化」を参照してください。すべてのレポート問合せに対してセキュリティ・チェックをまとめて有効化または無効化する方法の詳細は、「セキュリティ・チェック・プリファレンス設定の変更」を参照してください。

8.5.8.2.2 カスタム・レポートとセキュリティ・モード

事前定義済レポートに加えて、特定のニーズにあわせて調整した検索問合せに基づくカスタム・レポートを作成することもできます。カスタム・レポートを作成するだけでなく、カスタム・レポートにセキュリティ・チェックを選択的に実装することもできます。つまり、新しいカスタム・レポートに対してセキュリティ・チェックを実行する場合は、contenttrackerreports_query.htmファイルに問合せの非セキュア・フォームとセキュア・フォームの両方を含めることができます。

たとえば、両方の問合せフォームを備えたカスタム・レポートを追加できます。非セキュアな問合せの名前がqMyTopTwentyの場合、セキュアな問合せの名前はqMyTopTwenty_SECになります。セキュリティ・チェック・プリファレンス変数が有効化されている場合は、セキュアな問合せ(qMyTopTwenty_SEC)を使用してレポートが生成されます。セキュリティ・チェック・プリファレンス変数が有効化されていない場合は、非セキュアな問合せ(qMyTopTwenty)を使用してレポートが生成されます。

注意: カスタム問合せのセキュア・フォームは、contenttrackerreports_query.htmファイル内にある既存のセキュアな問合せの特定パターンに準拠している必要があります。詳細は、「セキュアなレポート問合せの作成」を参照してください。

特定のカスタム問合せに対してセキュリティ・チェックを使用する方法の詳細は、「レポート問合せのセキュリティ・チェックの有効化または無効化」を参照してください。すべてのレポート問合せに対してセキュリティ・チェックをまとめて有効化または無効化する方法の詳細は、「セキュリティ・チェック・プリファレンス設定の変更」を参照してください。

8.5.8.3 セキュリティ・モードの選択

Content Trackerレポートでは、リクエストされたレポートを生成するために、適用可能な非セキュアな問合せまたはセキュアな問合せを選択して実行する必要があります。

この項の内容は次のとおりです。

• 問合せタイプ選択プロセス

• レポート問合せ選択の例

8.5.8.3.1 問合せタイプ選択プロセス

Content Trackerレポートでは、次のプロセスに基づいてレポート問合せが選択されます。

• ユーザーがレポート・リクエストを発行すると、レポート問合せの名前が専用のContent Trackerレポート・サービスに送信されます。

• Content Trackerレポート・サービスによって、次のようにしてセキュリティ・チェック設定が実施されます。

  • セキュリティ・チェック・プリファレンスが無効化されている場合:

    Content Trackerレポートは非セキュア・モードで実行され、ロールおよびアカウント照合(ユーザー・ロールおよびアカウント権限の検証)は実行されません。Content Trackerレポート・サービスでは、問合せの非セキュア・バージョンが検索され、リクエストされたレポートの生成に使用されます。レポート問合せのセキュア・バージョンが存在しているかどうかは関係ありません。

    非セキュア・モードでは、非セキュアな問合せのみがレポートの生成に使用されます。その結果、ユーザーの各ロールおよびアカウントのメンバーシップに関係なく、すべてのユーザーに同じレポート結果が表示されます。

  • セキュリティ・チェック・プリファレンスが有効化されている場合:

    Content Trackerレポートはセキュア・モードで実行され、ロールおよびアカウント照合(ユーザー・ロールおよびアカウント権限の検証)が実行されます。

    処理の開始時:

    Content Trackerレポート・サービスによって、発行された問合せ名に接尾辞「_SEC」が付加され、リクエストされた問合せのこのバリアントがcontenttrackerreports_query.htmファイル内で検索されます。

    検索時:

    • 問合せのセキュア・フォームが検出されると、リクエストされたレポートの生成にそのフォームが使用されます。

      これは、ロールおよびアカウント照合を実施するセキュリティ・チェックが実行され、レポートをリクエストしたユーザーのロールおよびアカウント権限によって問合せ結果が制限されることを意味します。したがって、ユーザーごとに異なるデータ結果を表示できます。

    • 問合せのセキュア・フォームが検出されない場合は、非セキュアな変数が使用されます。

      この場合、実際には、セキュリティ・チェック・プリファレンスが無効化されているときと同じ結果になります。これは、ロールおよびアカウント権限は認証されず、コンテンツ・アイテム・データはフィルタ処理されないことを意味します。したがって、レポートに表示される結果はすべてのユーザーについて同じになります。適切な権限のないユーザーに機密情報が表示される可能性もあります。

8.5.8.3.2 レポート問合せ選択の例

ユーザーが「ユーザー・タイプ」レポートをリクエストすると、次の処理が実行されます。

1. レポート問合せ名(qSctrUsersByType)がContent Trackerレポート・サービスに渡されます。

2. Content Trackerレポート・サービスで、セキュリティ・チェック・プリファレンス変数に基づいてリクエストが評価されます。

   1. セキュリティ・チェックが無効化されている(falseに設定されている)場合、サービスでは、contenttrackerreports_query.htmファイル内でqSctrUsersByType問合せが検索されます。

   2. セキュリティ・チェックが有効化されている(trueに設定されている)場合、サービスでは、問合せ名にセキュリティ接尾辞が追加され(qSctrUsersByType_SEC)、contenttrackerreports_query.htmファイル内でこのバリアントが検索されます。

3. Content Trackerレポートでは、セキュリティ・チェック・ステータスに応じて、適用可能な問合せを使用して「ユーザー・タイプ別ユーザー」レポートが生成されます。

8.5.8.4 レポート問合せセキュリティのカスタマイズ

セキュア・モードの場合、Content Trackerレポートでは常にセキュア・フォームの問合せが優先されます。これは、セキュア・フォームの問合せがcontenttrackerreports_query.htmファイル内に見つかると、レポートの生成には、対応する非セキュアな問合せではなくセキュア・フォームの問合せが使用されます。

レポート問合せごとにセキュリティ・チェック・プリファレンス変数を選択的に有効化または無効化することはできません。ただし、contenttrackerreports_query.htmファイルをカスタマイズして、セキュアな問合せおよび非セキュアな問合せを管理することは可能です。レポート・データのセキュリティ要件に応じて、オプションで、レポート問合せファイルをカスタマイズすることもできます。

レポート問合せファイルのカスタマイズでは、次の操作を実行します。

• 特定のレポート問合せに対してセキュリティ・チェック(アカウント照合)を選択的に有効化または無効化します。

• 1つ以上の非セキュア・カスタム・レポート問合せを作成し、情報のセキュリティ要件に応じて、対応するセキュア・バージョンを選択的に追加します。

8.5.9 Content Trackerレポートの使用

この項では、Content Trackerレポート機能およびタスクの手順について説明します。

この項の内容は次のとおりです。

• レポートの生成

• ドリルダウン・レポートへのアクセス

• 情報ページからのレポートへのアクセス

• リビジョン別アクセス結果の表示

• すべてのバージョンが結合されたアクセス結果の表示

• カスタム・レポート問合せの作成

• セキュリティ・チェック・プリファレンス設定の変更

• レポート問合せのセキュリティ・チェックの有効化または無効化

• セキュアなレポート問合せの作成

• 外部レポート作成ツールの使用

8.5.9.1 レポートの生成

事前定義済レポートまたはカスタム・レポートを生成する手順は、次のとおりです。

1. 「管理」トレイの「Content Trackerレポート」リンクをクリックして、Content Trackerレポートの生成メイン・ページを開きます。

2. 必要なレポート・タイプのラジオ・ボタンを選択します。

3. 該当するフィールドに、必要な検索基準およびフィルタ処理基準を入力します。

4. 「送信」をクリックします。

   選択したレポート・タイプが表示されます。

8.5.9.2 ドリルダウン・レポートへのアクセス

1つ以上のドリルダウン・レポートにアクセスする手順は、次のとおりです。

1. 事前定義済レポートまたはカスタム・レポートを生成します。「レポートの生成」を参照してください。

2. 事前定義済レポートを生成すると、特定の行アイテム結果にアクティブなドリルダウン・レポート・リンクが設定されます。必要なリンクをクリックします。

   選択したドリルダウン・レポートが表示されます。

   
   

   注意: レポートに複数レベルのドリルダウン・レポートが含まれる場合があります。たとえば、「上位アクセス・コンテンツ・アイテム」レポートには「DocName」ドリルダウン・レポート・リンクが含まれます。このリンクをクリックすると、選択したコンテンツ・アイテムの適用可能なコンテンツ・アイテム詳細が表示される別のレポートが生成されます。このレポート内には、さらに2つの使用可能なドリルダウン・レポート(アクセス用とユーザー用)があります。

   
   

8.5.9.3 情報ページからのレポートへのアクセス

コンテンツ・アイテムの情報ページからそのコンテンツ・アイテムのアクセス履歴レポートを生成する手順は、次のとおりです。

1. コンテンツ・アイテムを検索し、関連付けられた「情報」アイコンをクリックします。

   コンテンツ情報ページが表示されます。

2. グローバル・アクション・リストから「アクセス履歴レポートの表示」を選択します。

   コンテンツ・アイテムの最新のコンテンツ・アクセス・レポートが表示されます。

3. コンテンツ・アクセス・レポートで、アクティブな「アクセス」リンクをクリックします。

   コンテンツ・アイテムの最新の日付別アクセス・レポートが表示されます。

4. コンテンツ・アクセス・レポートで、アクティブな「ユーザー」リンクをクリックします。

   コンテンツ・アイテムの最新のユーザー別アクセス・レポートが表示されます。

8.5.9.4 リビジョン別アクセス結果の表示

デフォルトでは、1つのコンテンツ・アイテムの複数バージョンのアクセス結果は、コンテンツ・ダッシュボードで個別に表示されます。コンテンツ・ダッシュボード・レポートの個別のアクセス結果ビューを表示する手順は、次のとおりです。

1. Content Trackerレポートの生成メイン・ページから、コンテンツ・アイテム・ベースの問合せレポートを生成します。「レポートの生成」を参照してください。Content Trackerレポートの生成メイン・ページで「上位アクセス・コンテンツ」オプションを選択して、適用可能なレポートを生成します。

2. 結果レポートからコンテンツ・アイテムを選択し、「DocName」列にリストされているコンテンツ識別番号をクリックします。

   選択したコンテンツ・アイテムのコンテンツ・ダッシュボードが表示されます。デフォルトでは、このビューに、選択したコンテンツ・アイテムの中でアクセスされたコンテンツ・アイテムの各リビジョンについてアクセス結果が表示されます。詳細は、「コンテンツ・ダッシュボード機能」を参照してください。

8.5.9.5 すべてのバージョンが結合されたアクセス結果の表示

コンテンツ・ダッシュボード・レポートの結合されたアクセス結果ビューを表示する手順は、次のとおりです。

1. Content Trackerレポートの生成メイン・ページから、コンテンツ・アイテム・ベースの問合せレポートを生成します。「レポートの生成」を参照してください。Content Trackerレポートの生成メイン・ページで「上位アクセス・コンテンツ」オプションを選択して、適用可能なレポートを生成します。

2. 結果レポートからコンテンツ・アイテムを選択し、「DocName」列にリストされているコンテンツ識別番号をクリックします。

   選択したコンテンツ・アイテムのコンテンツ・ダッシュボードが表示されます。

3. 「すべてのバージョン」リンクをクリックします。

   結果のコンテンツ・ダッシュボード・ビューに、両方のバージョンの結合されたアクセス結果が表示されます。

8.5.9.6 カスタム・レポート問合せの作成

この項では、非セキュアなカスタム・レポート問合せの作成方法を説明する例を示します。この特定の問合せでは、ユーザーとその個人属性がリストされたレポートが生成されます。データは、コンテンツ・サーバーのUsersデータベース表から導出されます。

注意: この項の例では、非セキュアな問合せを使用しています。このため、生成されたレポート結果は、ユーザーのロールおよびアカウント権限に関係なく、すべてのユーザーが表示できます。すべてのレポートは、非セキュアまたはセキュアな問合せを使用して生成されます。問合せの選択項目は、セキュリティ・モードによって異なります。オプションのセキュリティ・チェック・プリファレンス変数の詳細は、「セキュリティ・チェックと問合せ結果」を参照してください。セキュアなレポート問合せを作成する場合は、「セキュアなレポート問合せの作成」を参照してください。

カスタム・ユーザー・レポートを作成する手順は、次のとおりです。

1. SQLレポート問合せを設計します。

2. カスタム・レポート問合せをContent Trackerレポートの問合せファイルに入力します。

   1. テキスト・エディタで、contenttrackerreports_query.htmファイルを開きます。

      IntradocDir/custom/ContentTrackerReports/resources/contenttrackerreports_query.htm

   2. カスタム・レポート名、列数およびソース・データベース表を入力します。

      たとえば、問合せファイルの次の部分は、カスタム問合せレポートによってUsersデータベース表のすべての列から情報が抽出されることを示しています。

      <tr>
          <td>qCustomUsers</td>
          <td>
          SELECT *
          FROM Users
          </td>
      </tr>
      

3. Content Trackerレポートの生成メイン・ページ・ファイル内に、カスタム・レポートへのリンクを入力します。

   1. 次のディレクトリを開きます。

      IntradocDir/custom/ContentTrackerReports/templates

   2. テキスト・エディタで次のファイルを開きます。

      contenttrackerreports_main_page.htm

   3. 属性を入力して、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" value="qCustomUsers">
          Custom Users Report </span></td>
          </tr>
      </table>
      

4. Content Trackerレポートのテンプレート・リソース・ファイル内に、フォーマット要件を入力します。

   1. 次のディレクトリを開きます。

      IntradocDir/custom/ContentTrackerReports/resources

   2. テキスト・エディタで次のファイルを開きます。

      contenttrackerreports_template_resource.htm

      結果のカスタム・レポート・フォーマットを表示する場合は、「カスタム・レポート問合せの表示結果」の「生成されたカスタム・レポート」を参照してください。

   3. 生成されたカスタム・レポートおよび必要なドリルダウン・レポートに対して使用する表示機能を入力します(「カスタム・レポート問合せの表示結果」の「ドリルダウン・レポート」を参照してください)。

      たとえば、テンプレート・リソース・ファイルの次の部分は、リンクのリスト以外に、レポート・タイトルが「Deanna's First Report」で、「ユーザー別に表示されたコンテンツ・アイテム」レポートに基づいてドリルダウン・レポートが生成されることを示しています。

      <!-- Custom Template -->
      <@dynamichtml qCustomUsers_vars@>
          <$reportWidth = "100%"$>
          <$title = "<i>Content Access Report</i>"$>
          <$reportTitle="Deanna's First Report"$>
          <$column1Width="35%"$>
          <$column0Drill="qSctrDocsSeenByUser_Drill"$>
      <@end@>
      

5. コンテンツ・サーバーを再起動して、変更を適用します。

8.5.9.7 セキュリティ・チェック・プリファレンス設定の変更

ScrtEnableSecurityChecksプリファレンス設定を手動で有効化または無効化できます。

1. コンテンツ・サーバーに管理者としてログインします。

2. 「管理」メニューから「管理サーバー」を選択します。

   「コンテンツ管理サーバー」ページが表示されます。

3. セキュリティ・チェック・プリファレンス設定を変更するコンテンツ・サーバー・インスタンスの名前をクリックします。

   コンテンツ管理サーバー<instance_name>ページが表示されます。

4. 「コンポーネント・マネージャ」をクリックします。

   コンポーネント・マネージャ・ページが表示されます。

5. 「コンポーネント構成の更新」フィールドで、リストから「Content Trackerレポート」を選択します。

6. 「更新」をクリックします。

   コンポーネント構成の更新ページが表示されます。

7. ScrtEnableSecurityChecksプリファレンス・フィールドに、新しい設定(trueまたはfalse)を入力します。

8. 「更新」をクリックします。

   Content Trackerレポートが新しい設定で正常に更新され、即時に反映されます。コンテンツ・サーバーを再起動する必要はありません。

8.5.9.8 レポート問合せのセキュリティ・チェックの有効化または無効化

セキュリティ・チェック・プリファレンス変数が有効化され、セキュア・バージョンの問合せがcontenttrackerreports_query.htmファイル内に存在する場合、Content Trackerレポートでは、リクエストされたレポートの生成にセキュアな問合せが使用されます。ただし、レポートによってはセキュリティ・チェックを使用して生成する必要がない場合もあります。その場合は、任意のレポート問合せのセキュア・バージョンを選択的に無効化できます。

特定のレポート問合せに対してセキュリティ・チェック(アカウント照合)を無効化する手順は、次のとおりです。

1. テキスト・エディタで、contenttrackerreports_query.htmファイルを開きます。

   IntradocDir/custom/ContentTrackerReports/resources/contenttrackerreports_query.htm

2. 無効化する問合せのセキュア・バージョンを検索します。

3. 問合せの名前を変更します。たとえば、qSctrUsersByType_SEC問合せを無効化する場合は、接尾辞「_disabled」を問合せ名に追加します。

   qSctrUsersByType_SEC_disabled
   

   問合せの名前を変更すると、Content Trackerレポート・サービスでは、contenttrackerreports_query.htmファイル内にセキュアな問合せを検出できなくなります。かわりに、非セキュア・バージョン(qSctrUsersByType)が使用されます。

   
   

   注意: セキュアな問合せの名前変更は、一時的に問合せを無効化する手段です。後で、セキュア・バージョンの問合せを使用することにした場合は、問合せを元の名前に戻すことによって、セキュア・バージョンを簡単に再有効化できます。 または、セキュア・バージョンの問合せを削除することもできます。ただし、後でセキュア・バージョンの問合せを使用することにした場合は、セキュア・バージョンの問合せ全体を再作成する必要があります。

   
   

4. contenttrackerreports_query.htmファイルを保存して閉じます。

5. コンテンツ・サーバーを再起動して、変更を適用します。

8.5.9.9 セキュアなレポート問合せの作成

ほとんどの事前定義済レポート問合せでは、contenttrackerreports_query.htmファイル内に非セキュア・バージョンとセキュア・バージョンの両方が存在します。オプションで、セキュア・バージョンが存在しない問合せに対して、セキュア・バージョンを作成できます。具体的には、すでに追加した非セキュアなカスタム問合せなどがあります。

非セキュアなレポート問合せのセキュア・バージョンを作成する手順は、次のとおりです。

1. テキスト・エディタで、contenttrackerreports_query.htmファイルを開きます。

   IntradocDir/custom/ContentTrackerReports/resources/contenttrackerreports_query.htm

2. セキュア・バージョンを作成する問合せを検索します。一貫性を維持するために、セキュアな問合せは対応する非セキュア・バージョンの直後に追加してください。

3. セキュアなSQLレポート問合せを設計します(「カスタム・レポート問合せの作成」の手順2を参照)。

4. 既存のセキュアな問合せのパターンに従って問合せを調整します。

   1. FROM句にRevisions表を含めます。

   2. WHERE句に%SCTR_SECURITY_CLAUSE%トークンを含めます。これは、Content Trackerレポート・サービスによって挿入されるWHERE句のプレースホルダとして機能します。

   3. 既存のセキュアな問合せで確立されているパターンに従って、問合せを完成します。

      図8-4に、一般的なレポート問合せのペアを示します。

5. contenttrackerreports_query.htmファイルを保存して閉じます。

6. コンテンツ・サーバーを再起動して、変更を適用します。

図8-4 非セキュア・バージョンおよびセキュア・バージョンのレポート問合せの例

8.5.9.10 外部レポート作成ツールの使用

外部レポート作成ツールを使用してカスタム・レポートを生成する手順は、次のとおりです。

1. 外部レポート作成ツール・アプリケーションを開きます。

2. コンテンツ・サーバー・データベースへのODBC接続(適用可能な場合)を設定します。

3. レポートに使用するデータベース表を選択します。

4. ファイル内で共通のキーIDまたはフィールドに基づいて、選択した複数の表をリンクします。選択した各表は、各表に共通している同じキーIDまたはフィールドを使用してリンクすることが理想的です。

5. 各表から必要なフィールドを選択して、レポート・フォームに統合します。ほとんどの場合、フィールドを選択してフォームにドラッグ・アンド・ドロップできます。

   この手順では、カスタマイズ・レポートを設計します。外部レポート作成アプリケーションによって生成される最終的な基本テキスト・レポートでは、選択した特定のフィールドは列として表示されます。

6. 外部レポート作成アプリケーションでサポートされている場合は、オプションで、カスタム・パラメータや基準を作成できます。

   たとえば、問合せされた情報を最終レポートでハードコードにしたり、プロンプトを使用してエンド・ユーザーから直接入力を取得するようなタイプのカスタム・パラメータを作成できます。さらに、特定のソート基準を作成すると、最終レポートに含める集計データを戦略的に制限および最適化できます。

7. 選択したフィールドのソート順序を指定し、最終レポート出力をフォーマットします。

8. 最終レポートをプレビューします(オプション)。

9. レポートを配信メカニズムにチェックインします。

   一般に、最終レポートは、Web表示可能ページまたは印刷可能ファイルとしてフォーマットして配信できます。また、外部レポート作成アプリケーションでデータ結果を使用して、棒グラフや円グラフなどの有用なグラフを作成することもできます。

   さらに、保存したファイルをMicrosoft ExcelやWordファイルなどの他の製品にインポートすることもできます。

8.6 サービス・コール構成

この項の内容は次のとおりです。

• サービス・コール構成ファイルについて

• Content Trackerロギング・サービスについて

• サービス・コール情報の管理

8.6.1 サービス・コール構成ファイルについて

Content Trackerサービス・ハンドラ・フィルタを使用すると、コンテンツ・リクエスト以外のコンテンツ・サーバー・アクティビティに関する情報が収集できます。サービス・ハンドラ・フィルタによってサービス・リクエスト詳細が収集され、リアルタイムでSctAccessLog表に格納されます。詳細は、サービス・コールに付随するDataBinderから取得されます。コンテンツ・サーバー・サービス・コールをログに記録するには、サービス・コール構成ファイル(SctServiceFilter.hda)内にそのエントリが存在している必要があります。

SctServiceFilter.hdaファイルはユーザーが変更可能な構成ファイルで、ログに記録されるサービス・コールの数を制限するために使用されます。これによって、ログに記録されるサービスを選択的に管理できます。さらに、オプションで、SctServiceFilter.hdaファイルに含まれているサービス・コールのデータ記録機能を拡張できます。つまり、特定のサービスに関連する特定のDataBinderフィールドのデータ値を記録および追跡することもできます。「拡張されたサービス・コール・トラッキング機能」を参照してください。

サービス・トラッキングは、サーバー・ソケット・ポートを介して呼び出される最上位レベルのサービスに制限されます。サブサービス、または内部で呼び出されるサービスは追跡できません。

SctServiceFilter.hdaファイルの目的は、ユーザーがコンテンツ・サーバーのどの部分に特に関心があるかを定義することです。SctServiceFilter.hdaファイルにリストされていないコンテンツ・サーバー・サービスは、Content Trackerで無視されます。また、このファイルにリストされていないサービスは、Content Trackerロギング・サービスでのみログに記録できます。「Content Trackerロギング・サービスについて」を参照してください。

SctServiceFilter.hdaファイルを変更するには、2つの方法があります。ファイルへの新規サービスの追加、およびファイル内の既存サービス・コール・パラメータの編集は、データ・エンジン・コントロール・センターから実行できます(「「サービス」タブ」を参照)。または、SctServiceFilter.hdaファイルを手動で編集することもできます(「SctServiceFilter.hdaファイルの手動編集」を参照)。

ヒント: ログに記録するサービスを制御するには、SctServiceFilter.hdaファイルにサービスを追加するか、またはファイルから除外します。この方法は、特定のサービスまたはすべてのサービスに対するロギングを制御する場合に効率的です。また、拡張されたサービス・コール・トラッキング機能を使用すると、特定のサービスに対してログに記録されるデータのタイプをカスタマイズできます。

この項の内容は次のとおりです。

• 一般的なサービス・コール・ロギング

• 拡張されたサービス・コール・トラッキング機能

• サービス・コール構成ファイルの内容

• ResultSetの例

8.6.1.1 一般的なサービス・コール・ロギング

SctServiceFilter.hdaファイルにリストされたサービスはContent Trackerサービス・ハンドラ・フィルタによって検出され、選択されたデータ・フィールドの値が取得されます。その後に、Content Trackerでは指定されたサービス・コールがログに記録されます。タイムスタンプなどとともに、情報がSctAccessLog表に動的に書き込まれます。

Content Trackerでは、有効化されているサービスごとに、特定の標準DataBinderフィールド(dUser、dDocNameなど)が自動的に記録されます。また、拡張されたサービス・コール・トラッキング機能に関連付けられたDataBinderフィールドが、SctAccessLog表の汎用列に記録されます。

データは、Content Tracker固有のサービス順序番号およびサービスのタイプ指定「S」を使用して、SctAccessLog表にリアルタイムで挿入されます。(「W」指定は、静的URLイベント・タイプを示します。)手動またはスケジュール実行(あるいはその両方)での削減が必要になるのは、Webサーバー・フィルタによって収集された静的URLアクセス情報を処理する場合のみです。詳細は、「Webサーバー・フィルタ」を参照してください。

8.6.1.2 拡張されたサービス・コール・トラッキング機能

拡張されたサービス・コール・トラッキング機能を使用すると、コンテンツ・サーバー・サービス・コールをログに記録でき、オプションで、構成された各サービス・コールでログに記録される標準のDataBinderフィールド以外に1つ以上の追加DataBinderフィールドから関連データ値をログに記録することによって、この情報を補完することもできます。

この項の内容は次のとおりです。

• サービス・コールResultSetの組合せ

• 出力表の汎用列

8.6.1.2.1 サービス・コールResultSetの組合せ

SctServiceFilter.hdaファイルに含まれるServiceExtraInfo ResultSet内に、Content Trackerによってログに記録される各サービスのエントリが存在している必要があります。Content Trackerでは、各種の標準のDataBinderフィールド(dUser、dDocNameなど)が自動的にログに記録されます。ただし、追加のDataBinderフィールドから関連データ値を記録および追跡することによって、Content Trackerで記録されるサービス関連データを拡張できます。

拡張されたサービス・コール・トラッキング機能を実装するには、ServicesExtraInfo ResultSet内のエントリをフィールド・マップResultSetにリンクします。各フィールド・マップResultSetには、データ・フィールド名、ソース格納場所、およびSctAccessLog表内の宛先表列名のセットが1つ以上含まれます。このグループ化によって、関連付けられたサービス・コールに関連するデータ・フィールドを選択し、SctAccessLog表の指定された列にデータ値を記録できます。

拡張されたトラッキング機能を使用すると複数の拡張サービスを記録できるため、記録されるサービスが不明な場合は、SctAccessLog表の汎用列の内容を適切に解釈できません。サービス名は常にsc_scs_idcService列に記録されます。問合せでは、この列と任意のサービス名を一致させてください。

注意: フィールド・マップResultSet内では、データ・フィールドを既存の標準のSctAccessLog表列に自由にマップできます。標準のフィールド・データ値が収集されると、拡張されたサービス・マッピングが実行されます。これにより、標準の表列フィールドをオーバーライドできます。 たとえば、ログに記録するサービスのデータ・フィールドに特定のユーザー名(たとえば、MyUserName=john)が含まれるとします。拡張されたトラッキング機能を使用して、sc_scs_dUser列の内容をオーバーライドできます。この場合は、フィールド・マップResultSet内のデータ・フィールド、格納場所、および表列のセットとして、MyUserNameとsc_scs_dUserを結合します。 したがって、この場合も、ログに記録されるデータがSctAccessLogの列タイプと適合していることを確認する必要があります。

リンクされたサービス・エントリおよびResultSetの例は、「リンクされたサービス・エントリおよびフィールド・マップResultSet」を参照してください。SctAccessLog表の内容、およびデータ・フィールドにマップするための汎用列の詳細は、「結合された出力表」を参照してください。サービス・コール・ユーザー・インタフェースの詳細は、「「サービス」タブ」を参照してください。

8.6.1.2.2 出力表の汎用列

拡張されたサービス・トラッキング用のフィールド・マップResultSet内で、DataBinderフィールドをSctAccessLog表の列にマップする必要があります。汎用列(extField_1からextField_10)はマッピングに使用できます。これらの列には、特定のサービスに対するロギングおよびトラッキングに適した任意のデータ値を挿入できます。標準の表列がオーバーライドされることを回避するために、これらの列を使用することをお薦めします。

ヒント: サービスの名前は常にsc_scs_idcService列に記録されます。このため、拡張フィールドのコンテンツを使用する問合せには、修飾子としてサービス名を含める必要があります。SctAccessLog表の列が関連する特定のSQL問合せが含まれたカスタム・レポートの詳細は、「カスタム・レポート問合せの作成」を参照してください。

8.6.1.3 サービス・コール構成ファイルの内容

最初のサービス・コール構成ファイル(SctServiceFilter.hda)は、共通に使用されてコンテンツ・サーバーに固有のコンテンツ・アクセス、検索およびユーザー認証サービスで構成されます。このファイルには、ログに記録される各サービスに1つずつエントリが存在するResultSet構造が含まれます。オプションで、拡張されたサービス・コール・トラッキング機能をサポートするために、ServiceExtraInfo ResultSet内のサービス・エントリにリンクされたフィールド・マップResultSetをこのファイルに含めることもできます。

データ・エンジン・コントロール・センターからアクセスする「サービス」ユーザー・インタフェースを使用して、SctServiceFilter.hdaファイルに新規のエントリを追加したり、既存のエントリを編集できます。また、オプションで、ファイル内のエントリを手動で変更することもできます。「「サービス」タブ」または「SctServiceFilter.hdaファイルの手動編集」を参照してください。

注意: Content TrackerによってSctAccessLog表に記録される最初のサービスのセットを確認するには、次のディレクトリ内のSctServiceFilter.hdaファイルにアクセスします。 <cs_root>/data/contenttracker/config/SctServiceFilter.hda

次の表に、サービス・コール構成ファイルの結果セット・スキーマの詳細を示します。値は、SctAccessLog表内の対応する列に直接コピーされます。

ServiceExtraInfo ResultSetの内容:

機能	説明
サービス名(sctServiceName)	ロギングされるサービスの名前。たとえば、GET_FILEです。指定されたサービスについてResultSet内に行が存在しない場合、そのサービスは記録されません。
呼出し元製品(sctCallingProduct)	任意の文字列。この文字列は、通常、すべての標準コンテンツ・サーバー・エントリに対して「Core Server」に設定されています。
イベント・タイプ(sctEventType)	任意の文字列。この文字列は、通常、すべての標準コンテンツ・サーバー・エントリに対して「Content Access」に設定されています。
参照(sctReference)	SctAccessLog表のsc_scs_referenceフィールドを設定するために使用します。空白の場合は、内部getReferenceロジックが使用されます。
フィールドの変更(sctFieldMap)	SctServiceFilter.hdaファイルに追加されるフィールド・マップResultSetの名前。このフィールドは、拡張されたサービス・コール・トラッキング機能を使用する場合にのみ必要です。この機能を使用すると、DataBinderフィールド情報をSctAccessLog表の1つ以上の汎用列に記録できます。

フィールド・マップResultSetの内容:

機能	説明
「フィールドの変更」リンク	フィールド・マップResultSetの名前。 フィールド・マップを作成する場合は、サービスDataBinderオブジェクトを書き出す構成変数を設定できます。これにより、イベントが記録されるときに使用可能なデータを参照できます。
DataBinderフィールド(dataFieldName)	SctAccessLog表の汎用列にデータ値が記録されるDataBinderフィールドの名前。「「フィールドの変更」画面」の「「フィールド名」フィールド」も参照してください。
データの場所(dataLocation)	フィールドが記録されるコンテンツ・サービス・サービスDataBinder内のセクション。「「フィールドの変更」画面」の「「フィールドの場所」フィールド」も参照してください。
アクセス・ログ列(accessLogColumnName)	指定したDataBinderフィールドのデータ値がロギングされるSctAccessLog表の特定の汎用列。「「フィールドの変更」画面」の「「列名」フィールド」も参照してください。

DataBinderからコピーされてSctAccessLog表に挿入されるフィールドには、dID、dDocName、IdcService、dUser、SctCallingProduct、SctEventTypeおよびSctReferenceが含まれます。最後の3つのフィールドの値がSctServiceFilter.hdaファイル内のサービスのエントリに含まれている場合は、それらの値はデータ・フィールド内の対応する値をオーバーライドします。

サービス・ハンドラ・フィルタを介して記録されるサービスと、Content Trackerロギング・サービスを介して記録されるサービスとの間に、重複や競合はないはずです。サービスの名前がContent Trackerサービス・ハンドラ・フィルタ・ファイルに指定されている場合、それらのサービスは自動的にログに記録されるため、Content Trackerロギング・サービスによる記録は不要です。

ヒント: 必要なサービス・コールをSctServiceFilter.hdaファイルに追加し、この方法を使用して特定のアクティビティを記録すると、CallingProduct、EventTypeおよびReferenceフィールドの値を指定できる長所があります。割り当てた値は、SctAccessLog表内の対応する列に直接コピーされます。

8.6.1.4 ResultSetの例

デフォルトのSctServiceFilter.hdaファイルには、各種の共通のサービス・コールが含まれています。

注意: Content TrackerによってSctAccessLog表に記録される最初のサービスのセット、サービス・エントリおよびフィールド・マップResultSetを確認するには、次のディレクトリ内のSctServiceFilter.hdaファイルにアクセスします。 <cs_root>/data/contenttracker/config/SctServiceFilter.hda これらのサービス、またはサービス・コール構成ファイルに追加するその他のサービスの詳細は、Oracle Fusion Middleware Universal Content Managementサービス・リファレンス・ガイドを参照してください。

この項の内容は次のとおりです。

• ServiceExtraInfo ResultSetのエントリ

• リンクされたサービス・エントリとフィールド・マップResultSet

8.6.1.4.1 ServiceExtraInfo ResultSetのエントリ

次のリストに、SctServiceFilter.hdaファイルのServiceExtraInfo ResultSetに含まれるサービス・エントリの例をいくつか示します。

• GET_FILE_BY_NAME

  Core Server

  Content Access

• GET_DYNAMIC_URL

  Core Server

  Content Access

• GET_DYNAMIC_CONVERSION

  Core Server

  Content Access

• GET_EXTERNAL_DYNAMIC_CONVERSION

  Core Server

  Content Access

• GET_ARCHIVED_FILE

  Core Server

  Content Access

• COLLECTION_GET_FILE

  Folders

  Content Access

8.6.1.4.2 リンクされたサービス・エントリとフィールド・マップResultSet

次の表に、フィールド・マップResultSetにリンクされたサービス・エントリの例をいくつか示します。これらの例やその他の類似する例は、最初のSctServiceFilter.hdaファイルに含まれています。

サービス・エントリ	フィールド・マップResultSet
GET_SEARCH_RESULTS Core Server Search SearchFieldMap	@ResultSet SearchFieldMap 3 dataFieldName 6 255 dataLocation 6 255 accessLogColumnName 6 255 MiniSearchText LocalData extField_1 TranslatedQueryText LocalData extField_2 IsSavedQuery LocalData extField_7 @end
PNE_GET_SEARCH_RESULTS Core Server Search SearchFieldMap	@ResultSet SearchFieldMap 3 dataFieldName 6 255 dataLocation 6 255 accessLogColumnName 6 255 MiniSearchText LocalData extField_1 TranslatedQueryText LocalData extField_2 IsSavedQuery LocalData extField_7 @end
GET_FILE Core Server Content Access GetFileFieldMap	@ResultSet GetFileFieldMap 3 dataFieldName 6 255 dataLocation 6 255 accessLogColumnName 6 255 RevisionSelectionMethod LocalData extField_1 Rendition LocalData extField_2 @end

8.6.2 Content Trackerロギング・サービスについて

Content Trackerロギング・サービスは、アプリケーションによって1つのイベントをSctAccessLog表に記録できる単一のサービス・コール(SCT_LOG_EVENT)です。このサービスは、URLを介して直接呼び出すか、またはサービス・スクリプト内のアクションとして呼び出すことができます。また、executeService()関数を使用して、IdocScriptから呼び出すこともできます。呼出し元アプリケーションによって、記録されるサービスDataBinder内の一部または全部のフィールドが設定され、これには、Content TrackerのSctServiceFilter.hda構成ファイルにリストされている記述フィールドが含まれます。

SCT_LOG_EVENTサービスによって、サービスDataBinderから情報がコピーされます。このデータは、Content Tracker固有のサービス順序番号およびサービスのタイプ指定「S」を使用して、SctAccessLog表にリアルタイムで挿入されます。手動またはスケジュール実行(あるいはその両方)での削減が必要になるのは、Webサーバー・フィルタによって収集された静的URLアクセス情報を処理する場合のみです。「Webサーバー・フィルタ」を参照してください。

注意: サービス・ハンドラ・フィルタを介して記録されるサービスと、Content Trackerロギング・サービスを介して記録されるサービスとの間に、重複や競合はないはずです。サービスの名前がContent Trackerサービス・ハンドラ・フィルタ・ファイルに指定されている場合、それらのサービスは自動的にログに記録されるため、Content Trackerロギング・サービスによる記録は不要です。ただし、Content Trackerでは、このような重複を回避する処理は行われません。

8.6.3 サービス・コール情報の管理

この項では、コンテンツ・サーバー・サービスからのデータを結合された出力データベース表(SctAccessLog)にマップして記録するための情報およびタスクの手順について説明します。

この項の内容は次のとおりです。

• SctServiceFilter.hdaファイルの手動編集

• Content Trackerロギング・サービスを呼び出すための必要なDataBinderフィールドの設定

• アプリケーションからのContent Trackerロギング・サービスの呼出し

• IdocScriptからのContent Trackerロギング・サービスの呼出し

8.6.3.1 SctServiceFilter.hdaファイルの手動編集

SctServiceFilter.hdaファイルのエントリを追加または変更する手順は、次のとおりです。

1. テキスト・エディタで、SctServiceFilter.hdaファイルを開きます。

   <cs_root>/data/contenttracker/config/.../SctServiceFilter.hd

2. 既存のエントリを編集するか、または新規のサービス・エントリを追加します。たとえば、GET_FILE_FORMサービスを追加する場合は、次のサービス・エントリをファイル内のServiceExtraInfo ResultSetに入力します。

   GET_FORM_FILE
   Threaded Discussion
   Content Access
   <optional_reference_value>
   <optional_field_map_link_value>
   

   optional_field_map_link_valueは、拡張されたサービス・コール・トラッキング機能を実装する場合に使用します。この場合、対応するフィールド・マップResultSetも追加または編集する必要があります。拡張されたサービス・トラッキングを別の方法で実装する場合は、手順3をスキップします。

3. 拡張されたサービス・トラッキングを使用する場合は、対応するフィールド・マップResultSetを追加または編集する必要があります。たとえば、SS_GET_PAGEサービスを追加し、追加のデータ・フィールド値を追跡するには、次のサービス・エントリおよび対応するフィールド・マップResultSetをファイルに入力します。

   サービス・エントリ	フィールド・マップResultSet
   SS_GET_PAGE Site Studio Web Hierarchy Access web SSGetPageFieldMap	@ResultSet SSGetPageFieldMap 3 dataFieldName 6 255 dataLocation 6 255 accessLogColumnName 6 255 <DataBinder_field_name> <data_field_location_name> <access_log_column_name> @end

   
   
   
   

   注意: DataBinderフィールド、格納場所および表列名のセットは、必要な数だけ含めてください。

   
   

4. ファイルを保存し、閉じます。

5. コンテンツ・サーバーを再起動して、新しい定義を適用します。

   
   

   注意: 検索リクエスト・イベントはリアルタイムでSctAccessLog表に記録され、削減する必要はありません。オプションで、データ・エンジン・コントロール・センターに組み込まれているユーザー・インタフェースを使用して、サービスを追加または編集できます。詳細は、「データ・エンジン・コントロール・センター」および「「サービス」タブ」を参照してください。

   
   

8.6.3.2 Content Trackerロギング・サービスを呼び出すための必要なDataBinderフィールドの設定

次の表に、Content Trackerロギング・サービス(SCT_LOG_EVENT)が呼び出されたときにContent Trackerで検索されるSctAccessLogの列名および対応するDataBinderフィールドを示します。アプリケーションでは、Content Trackerロギング・サービスを呼び出すときに、Content Trackerで検索されるサービスDataBinder内の必要なフィールドを設定します。SctAccessLogフィールドの詳細は、「結合された出力表」を参照してください。

SctAccessLogの列名	サービスDataBinder LocalDataフィールド
SctDateStamp	[計算される]
SctSequence	SctSequence
SctEntryType	S
eventDate	[計算される]
SctParentSequence	SctParentSequence
c_ip	REMOTE_HOST
cs_username	HTTP_INTERNETUSER
cs_method	REQUEST_METHOD
cs_uriStem	HTTP_CGIPATHROOT
cs_uriQuery	QUERY_STRING
cs_host	SERVER_NAME
cs_userAgent	HTTP_USER_AGENT
cs_cookie	HTTP_COOKIE
cs_referer	HTTP_REFERER
sc_scs_dID	dID
sc_scs_dUser	dUser
sc_scs_idcService	IdcService(またはSctIdcService)
sc_scs_dDocName	dDocName
sc_scs_callingProduct	sctCallingProduct
sc_scs_eventType	sctEventType
sc_scs_status	StatusCode
sc_scs_reference	sctReference(...も同様)
comp_username	[計算される - HTTP_INTERNETUSERまたは...]
sc_scs_isPrompt	該当なし
sc_scs_isAccessDenied	該当なし
sc_scs_inetUser	該当なし
sc_scs_authUser	該当なし
sc_scs_inetPassword	該当なし
sc_scs_serviceMsg	StatusMessage

8.6.3.3 アプリケーションからのContent Trackerロギング・サービスの呼出し

SCT_LOG_EVENTサービスをアプリケーションから呼び出すことができます。これは、アプリケーション開発者、またはアプリケーション・サービス・スクリプトを変更するユーザーが実行できます。アプリケーションではJavaからSCT_LOG_EVENTを呼び出すことができます。または、アプリケーションでSCT_LOG_EVENTへのコールをサービス・スクリプトに含めることもできます。

8.6.3.4 IdocScriptからのContent Trackerロギング・サービスの呼出し

executeService()関数を使用して、IdocScriptから間接的にSCT_LOG_EVENTサービスを呼び出すことができます。これは、アプリケーションからのSCT_LOG_EVENTサービスの呼出しと同じですが、アプリケーションJavaコードではなくIdocScriptから呼び出されます。Content Trackerでは、SCT_LOG_EVENTサービスの呼出し元がJavaかIdocScriptかは区別できません。

8.7 構成およびカスタマイズ

この項の内容は次のとおりです。

• 構成変数

• Content Tracker構成変数の手動設定

• アクティビティ・メトリックのSQL問合せ

• 外部ユーザーおよびコンテンツ・アイテムの追跡

8.7.1 構成変数

次の表に、現行バージョンのContent Trackerで使用される構成設定のデフォルト値を示します。これらの構成変数は、Content Tracker構成ファイルに含まれています。

<cs_root>/data/contenttracker/config/sct.cfg

構成設定	デフォルト値	備考
SctAutoTruncateDataStrings	FALSE	使用: JAVA 削減プロセスでデータ文字列を対応する表列に収まるように切り捨てるかどうかを指定します。
SctComponentDir	<cs_root>/data/contenttracker/	使用: JAVA Content Trackerがインストールされているディレクトリへのパス。
SctDebugLogEnabled	FALSE	使用: JAVA TRUEに設定すると、Javaコード実行トレースが有効化されます。SctDebugLogFilePathとともに使用されます。
SctDebugLogFilePath	<cs_root>/data/contenttracker/log/SCT_DEBUG_TRACE.log	使用: JAVA Javaコード実行トレースのディレクトリ。SctDebugLogEnabledとともに使用されます。
SctDebugServiceBinderDumpEnabled	FALSE	使用: JAVA TRUEに設定すると、サービス・ロギング中にサービスDataBinderオブジェクトの診断出力が有効化されます。
SctExternalUserLogEnabled	TRUE	使用: JAVA TRUEに設定すると、外部ユーザー・アカウントおよびロールの情報のUserSecurityAttributes表へのレプリケーションが有効化されます。
SctFilterPluginLogDir	<cs_root>/data/contenttracker/data/	使用: フィルタ・プラグイン フィルタ・プラグインによってイベント・ログが格納されるディレクトリへのパス。
SctIdcAuthExtraConfigParams		フィルタ・プラグインに渡され、Content Tracker起動フィルタによってidcAuthExtraConfigParamsにプログラムでマージされるContent Tracker構成パラメータのリスト。
SctIgnoreDirectories	DomainHome/ucm/cs/resources/;DomainHome/ucm/cs/common/	使用: フィルタ・プラグイン リストされたディレクトリ・ルート内に含まれるURLを無視するようにフィルタ・プラグインに指示します。
SctIgnoreFileTypes	gif、jpg、js、css	使用: フィルタ・プラグイン リストされたファイルタイプを持つURLを無視するようにフィルタ・プラグインに指示します。
SctLogDir	<cs_root>/data/contenttracker/data/	使用: JAVA Content TrackerがRAWイベント・ログ(sctLogなど)を検索するディレクトリへのパス。複数の値を指定することもできます(たとえば、dir1;dir2;…;dirnなど)。
SctLogEnabled	TRUE	使用: フィルタ・プラグイン、JAVA FALSEの場合、すべてのイベントを無視してログを作成しないようにサービス・ハンドラ・フィルタおよびWebサーバー・フィルタ・プラグインに指示します。これは、Content Trackerマスターのオン/オフのスイッチです。
SctLogSecurity	TRUE	使用: フィルタ・プラグイン、JAVA TRUEの場合、IMMEDIATE_RESPONSE_PAGEイベントをsctSecurityLogイベント・ログに記録するようにフィルタ・プラグインに指示し、イベント・ログを読み取るように削減プロセスに指示します。
SctMaxRecentCount	5	使用: JAVA 削減済のデータが「最新」状態として保持される最大日数。「最新」からオーバーフローしたデータは「アーカイブ」状態に移行します。
SctMaxRereadTime	3600	使用: JAVA 特定のユーザーが特定のコンテンツ・アイテム(PDFファイルなど)を連続して参照したとき、連続する参照が1つの持続するアクセスとしてみなされる最大の秒間隔。次の参照との時間間隔が大きい場合は、個別のアクセスとしてカウントされます。
SctReductionAvailableDatesLookback	0	使用: JAVA 使用可能な日付範囲を制限するためにSctReductionRequireEventLogsとともに使用されます。単位 = 日数。ゼロ = 無制限。
SctReductionLogDir	<cs_root>/data/contenttracker/log/	使用: JAVA Content Tracker削減ログが格納されるディレクトリへのパス。
SctReductionRequireEventLogs	TRUE	使用: JAVA 添付解除された構成で使用されます。FALSEは、イベント・ログが見つからない場合でも削減を続行することを示します。
SctScheduledReductionEnable	TRUE	使用: JAVA 複数JVM構成において、削減を実行するコンテンツ・サーバー・インスタンスを選択するために使用されます。
SctSnapshotEnable	FALSE	使用: JAVA TRUEに設定すると、スナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。
SctSnapshotLastAccessEnable	FALSE	使用: JAVA TRUEに設定すると、最終アクセス日付のスナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。
SctSnapshotLastAccessField	[なし]	使用: JAVA 最終アクセス日付のメタデータ・フィールド名(xLastAccessDateなど)。データ・エンジン・コントロール・センターから設定します。
SctSnapshotLongCountEnable	FALSE	使用: JAVA TRUEに設定すると、長期間隔アクセス・カウントのスナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。
SctSnapshotLongCountField	[なし]	使用: JAVA 長期間隔カウントのメタデータ・フィールド名(xAccessesInLast90Daysなど)。データ・エンジン・コントロール・センターから設定します。
SctSnapshotLongCountInterval	[なし]	使用: JAVA 長期間隔の日数。データ・エンジン・コントロール・センターから設定します。
SctSnapshotShortCountEnable	FALSE	使用: JAVA TRUEに設定すると、短期間隔アクセス・カウントのスナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。
SctSnapshotShortCountField	[なし]	使用: JAVA 短期間隔カウントのメタデータ・フィールド名(xAccessesInLast10Daysなど)。データ・エンジン・コントロール・センターから設定します。
SctSnapshotShortCountInterval	[なし]	使用: JAVA 短期間隔の日数。データ・エンジン・コントロール・センターから設定します。
SctUseGMT	FALSE	使用: フィルタ・プラグイン、JAVA 記録されたイベント時間を世界標準時に変換する場合は、TRUEに設定します。FALSEに設定すると、ローカル時間が使用されます。

次の変数はsct.cfgファイルで使用できません。これらには、コンポーネント・マネージャからのみアクセスできます。

構成設定	デフォルト値	備考
SctPostReductionExec	[なし]	使用: JAVA 削減後実行可能ファイルへのパス(IntradocDir/custom/ContentTracker/bin/内と想定)。
SctProxyNameMaxLength	50	使用: JAVA 構成内のコンテンツ・サーバー・プロキシ・サーバー名の最大文字数。Content Trackerの表作成でユーザー名フィールドのサイズを増やす場合に使用されます。
SctUrlMaxLength	3000	使用: JAVA URLフィールドの予測される最大長(文字数)。表の作成時に列幅を決定するために使用されます。1つの特定の表にこのような列が複数存在する場合があります。
SctWebBeaconIDList	[なし]	使用: フィルタ・プラグイン Webビーコン・オブジェクトのリスト(オブジェクトがゼロの場合もあります)。クライアント側タグを使用してデータをContent Trackerにフィードする機能を追加する場合に必要です。Content Trackerで、キャッシュされたページのデータや、キャッシュされたサービスから生成されたページのデータを収集できるようになります。

8.7.2 Content Tracker構成変数の手動設定

Content Tracker構成変数を設定または編集する手順は、次のとおりです。

1. テキスト・エディタで、sct.cfgファイルを開きます。

   <cs_root>/data/contenttracker/config/sct.cfg

2. 編集する構成ファイルを検索します。

3. 適用可能な値を入力します。

4. sct.cfgファイルを保存して閉じます。

5. コンテンツ・サーバーを再起動して変更内容を適用します。

オプションで、データ・エンジン・コントロール・センターに組み込まれているユーザー・インタフェースを使用して、アクティビティ・メトリック・メタデータ・フィールドの構成変数を追加または編集できます。次のような変数があります。

• SctSnapshotEnable

• SctSnapshotLastAccessEnable

• SctSnapshotLastAccessField

• SctSnapshotLongCountEnable

• SctSnapshotLongCountField

• SctSnapshotLongCountInterval

• SctSnapshotShortCountEnable

• SctSnapshotShortCountField

• SctSnapshotShortCountInterval

ユーザー・インタフェースおよびアクティビティ・メトリック機能の詳細は、「データ・エンジン・コントロール・センター」および「「スナップショット」タブ」を参照してください。

8.7.3 アクティビティ・メトリックのSQL問合せ

スナップショット機能を使用すると、検索関連カスタム・メタデータ・フィールドをログに記録して追跡できます。Content Trackerでは、特定のコンテンツ・アイテムの人気度を反映するコンテンツ・アイテム使用状況およびアクセス情報がこれらのフィールドに挿入されます。この情報には、2つの異なる時間間隔における最新アクセスの日付およびアクセス数が含まれます。スナップショット機能の詳細は、「「スナップショット」タブ」を参照してください。

スナップショット機能およびアクティビティ・メトリックが有効化されている場合は、削減処理フェーズに続いて、カスタム・メタデータ・フィールドの値が更新されます。ユーザーがコンテンツ・アイテムにアクセスすると、適用可能な検索関連メタデータ・フィールドの値がそれに応じて変わります。その後、Content Trackerでは、削減処理後の手順として3つのSQL問合せが実行され、レポート作成期間中にアクセスされたコンテンツ・アイテムが特定されます。削減処理後の手順の詳細は、「アクティビティ・メトリックを使用するデータ削減プロセス」を参照してください。

この項の内容は次のとおりです。

• アクティビティ・メトリックのSQL問合せのカスタマイズ

• 「「自動ロード」オプションのSQL問合せのカスタマイズ」

8.7.3.1 アクティビティ・メトリックのSQL問合せのカスタマイズ

SQL問合せはリソースとして使用可能で、特定のニーズにあわせてカスタマイズできます。最終トラッキング・データから、特定の情報をフィルタで除外できます。たとえば、表形式の結果から、特定のユーザーによるアクセスを除外できます。SQL問合せは、sctQuery.htmファイルに含まれています。

IntradocDir/custom/ContentTracker/resources/SctQuery.htm

注意: 通常、SQL問合せ内のWHERE句は自由に変更できます。ただし、その他の内容は変更しないことをお薦めします。

検索関連カスタム・メタデータ・フィールドには、次のSQL問合せが使用されます。

• qSctLastAccessDate

• qSctAccessCountShort and qSctAccessCountLong

この項の内容は次のとおりです。

• qSctLastAccessDate

• qSctAccessCountShort and qSctAccessCountLong

8.7.3.1.1 qSctLastAccessDate

最終アクセス機能の場合、qSctLastAccessDate SQL問合せではSctAccessLog表が使用されます。この問合せでは、削減日におけるすべてのコンテンツ・アイテム・アクセスがチェックされ、dIDごとに最新のタイムスタンプが収集されます。この問合せのパラメータは、削減日です。この場合、最終アクセス日付の比較テストによって変更が示されるのは、既存のDocMeta値が提示された新しい値よりも古い場合のみであるため、日付はランダムな順序で削減できます。

最終アクセス・フィールドの詳細は、「「スナップショット」タブ」を参照してください。

8.7.3.1.2 qSctAccessCountShort and qSctAccessCountLong

短期アクセス・カウントおよび長期アクセス・カウント機能の場合、SQL問合せのqSctAccessCountShortおよびqSctAccessCountLongは、カウントの列名以外は同じです。これらの問合せでは、SctAccessLog表を使用して、それぞれに指定された時間間隔(日数)にわたる各dIDの全アクセスについて合計が計算されます。パラメータは、適用可能なロールアップの開始日および終了日です。

短期アクセス・カウントおよび長期アクセス・カウント・フィールドの詳細は、「「スナップショット」タブ」を参照してください。

8.7.3.2 「自動ロード」オプションのSQL問合せのカスタマイズ

データ・エンジン・コントロール・センターの「スナップショット」タブで「自動ロード」オプションを使用すると、すべての既存コンテンツの最終アクセス・フィールドに値を移入できます。「自動ロード」を起動すると、qSctLastAccessDateAutoload問合せが実行され、コンテンツ・サーバーのDocMetaデータベース表の空(NULL)の最終アクセス・フィールドに現在の日時が移入されます。

ただし、qSctLastAccessDateAutoload問合せはリソースとして使用可能で、特定のニーズにあわせてカスタマイズできます。たとえば、最終アクセス・フィールドを「dCreateDate」、「dReleaseDate」、またはアプリケーションの要件を満たすその他の時刻に設定できます。qSctLastAccessDateAutoload問合せは、sctQuery.htmファイルに含まれています。

IntradocDir/custom/ContentTracker/resources/SctQuery.htm

最終アクセス・フィールドおよび「自動ロード」オプションの詳細は、「「スナップショット」タブ」を参照してください。

8.7.4 外部ユーザーおよびコンテンツ・アイテムの追跡

Content Trackerで適用可能レポートに外部ユーザー・アクセスに関するデータを含めるかどうかを制御できます。これらの認証済ユーザーは、ユーザー・ロールおよびアカウントに基づいて権限を与えられています。デフォルトでは、構成パラメータSctExternalUserLogEnabledはtrue(有効)に設定されています。これによって、Content Trackerでは、外部ユーザー・ログオンが監視され、そのロールおよびアカウント情報がUserSecurityAttributes表に自動的に伝播されます。

SctExternalUserLogEnabled構成変数が有効か無効かに関係なく、外部ユーザーのコンテンツ・アイテム・アクセス情報はすべて追跡されて記録されます。ただし、この構成変数が有効化されている場合は、外部で認証されたユーザー名とそれに関連付けられたユーザー・ロールおよびアカウントとの相関関係を明示的に示すレポートに、このデータが含められます。具体的には、「ユーザー・ロール別上位アクセス・コンテンツ・アイテム」レポートおよび「ユーザー・ロール別ユーザー」レポートに、外部ユーザーによるすべてのコンテンツ・アイテム・アクセス・アクティビティが含められます。「Content Trackerレポートの生成メイン・ページ」を参照してください。

注意: オプションで、手動でSctExternalUserLogEnabled構成変数を無効化できます。ただし、無効化した場合、外部で認証されたユーザーによるコンテンツ・アイテム・アクセスは、より一般的なレポート(「上位アクセス・コンテンツ・アイテム」レポートなど)に含められます。このデータは、ユーザー・ロールおよびアカウント情報によって限定されたドキュメント・アクセス・カウントを使用するレポートからは除外されます。 SctExternalUserLogEnabled構成変数を手動で無効化する方法は、「Content Tracker構成変数の手動設定」を参照してください。

8.8 トラブルシューティング

Content Trackerは、Webサーバー・フィルタおよびJavaコードの2つの実行トレース・メカニズムを備えています。これらは、顧客のインストールにおける問題を診断することを目的としており、本番環境では使用されません。

この項の内容は次のとおりです。

• Webサーバー・フィルタのデバッグ・サポート

• デバッグ・プラグインの設定

• Javaコードのデバッグ・サポート

• DataBinderダンプ機能

• DataBinderオブジェクトのダンプ・ファイルへのアクセス

• デバッグ構成変数の設定

8.8.1 Webサーバー・フィルタのデバッグ・サポート

Webサーバー・フィルタでは、PLUGIN_DEBUGが重要です。コンテンツ・サーバーのフィルタ管理ページでPLUGIN_DEBUGを有効化すると、Content TrackerのWebサーバー・フィルタによって実行トレース情報が発行されます。トレースは、ソースにアクセスするユーザーに対してのみ意味があります。顧客は、問題が発生した場合に、PLUGIN_DEBUGを有効化し、テスト・シナリオを実行して、ログ・セグメントをカスタマ・サービスに送信して評価を受ける必要があります。それ以外の場合は、PLUGIN_DEBUGをオフのままにしてください。

8.8.2 デバッグ・プラグインの設定

PLUGIN_DEBUGを設定する手順は、次のとおりです。

1. コンテンツ・サーバーで、「管理」トレイの「管理アプレット」リンクをクリックします。

   管理ページが表示されます。

2. 「フィルタ管理」アイコンまたはリンクをクリックします。

   Webサーバー・フィルタの構成ページが表示されます。

3. PLUGIN_DEBUGオプション・チェック・ボックスを選択します。

4. 「更新」をクリックします。

8.8.3 Javaコードのデバッグ・サポート

デバッグをサポートするために、コンテンツ・サーバーのシステム監査機能を使用できます。詳細は、『Oracle Fusion Middleware Content Serverシステム管理者ガイド』のシステム監査情報に関する項を参照してください。contenttrackerを「アクティブなセクション」リストに追加します。リストが更新されると、Content Trackerの実行トレース情報が他のアクティブなセクションとともに表示されます。

8.8.4 DataBinderダンプ機能

この項の内容は次のとおりです。

• DataBinderダンプ機能の値

• DataBinderオブジェクトのダンプ・ファイルについて

• DataBinderオブジェクトのダンプ・ファイルの場所

• DataBinderオブジェクトのダンプ・ファイルの名前

8.8.4.1 DataBinderダンプ機能の値

この構成変数の値は、次のとおりです。

• SctDebugServiceBinderDumpEnabled=Falseに設定すると、Content Trackerサービス・ハンドラ・フィルタによってDataBinderオブジェクトはダンプ・ファイルに書き出されません。これがデフォルト値になります。

• SctDebugServiceBinderDumpEnabled=Trueに設定すると、DataBinderオブジェクトがダンプ・ファイルに書き出されるようにContent Trackerサービス・ハンドラ・フィルタが構成されます。このため、ダンプ・ファイルは、拡張されたサービス・ロギング用のフィールド・マップを開発する際の診断ツールとして使用できます。サービス用のフィールド・マップを作成する場合は、ダンプ・ファイルを使用すると、サービス・イベントの記録時に使用可能なデータを確認できます。

8.8.4.2 DataBinderオブジェクトのダンプ・ファイルについて

Content Trackerによって特定のサービスがログ・ファイルに記録されると同時に、そのサービスのDataBinderオブジェクトの内容が、シリアル化されたダンプ・ファイルに書き込まれます。これらのファイルの内容は、拡張されたサービス・コール・トラッキング機能を使用するためのフィールド・マップを作成する際に、デバッグ用に役立ちます。これらのダンプ・ファイルを使用して、記録されたサービスに使用可能なLocalDataフィールドを確認できます。

Content Trackerサービス・ハンドラ・フィルタによってDataBinderオブジェクトのダンプ・ファイルが作成されるのは、関連付けられたサービスがSctServiceFilter.hdaファイル内に定義されている場合のみです。このファイルの詳細は、「サービス・コール構成ファイルについて」を参照してください。

注意: DataBinderオブジェクトのダンプ・ファイルは、手動で削除しないかぎり蓄積され続けます。このため、SctDebugServiceBinderDumpEnabled構成変数は、必要な場合のみ使用することをお薦めします。

8.8.4.3 DataBinderオブジェクトのダンプ・ファイルの場所

シリアル化されたDataBinderオブジェクトは、次の場所に書き込まれます。

IntradocDir/data/ContentTracker/DEBUG_BINDERDUMP/<dump_file_name>

8.8.4.4 DataBinderオブジェクトのダンプ・ファイルの名前

DataBinderオブジェクトのダンプ・ファイルはテキスト・ファイルで、その名前は次の3つの部分で構成されます。

<service_name>_<filter_function>_<serial_number>.hda

要素の説明:

• service_nameは、ログに記録されたサービスの名前(GET_FORM_FILEなど)です。

• filter_functionは次のいずれかです。

  • End: フィルタ・イベント「on EndServiceRequestActions」: 正常なサービス終了イベント。

  • EndSub: フィルタ・イベント「on EndScriptSubServiceActions」: サブサービスとして呼び出されたサービスの正常なサービス終了。

  • Error: フィルタ・イベント「on ServiceRequestError」: エラーが発生したサービスの終了。Endと同時に発生する場合があります。

• serial_numberは、ファイルに割り当てられた一意の識別番号です。これによって、Content Trackerでは、1つの特定のサービスに対してDataBinderオブジェクトのダンプ・ファイルを複数作成できます。

例:

GET_SEARCH_RESULTS_End_1845170235.hda

8.8.5 DataBinderオブジェクトのダンプ・ファイルへのアクセス

特定の記録済サービスに対するDataBinderオブジェクトのダンプ・ファイルにアクセスする手順は、次のとおりです。

1. テキスト・エディタで、次のディレクトリ内の特定のデータ・バインダ・ファイルを開きます。

   <cs_root>/data/contenttracker/DEBUG_BINDERDUMP/

2. 内容を確認します。

   DataBinderオブジェクトのダンプ・ファイルは、無限に蓄積され続けます。このため、終了後にダンプ・ファイルを手動で削除することをお薦めします。

8.8.6 デバッグ構成変数の設定

Content Tracker構成変数の設定方法の詳細は、「Content Tracker構成変数の手動設定」を参照してください。