| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 12c (12.2.1.2.0) E82756-01 |
|
 前へ |
 次へ |
Content TrackerはOracle WebCenter Content Serverオプションのコンポーネントで、Oracle WebCenter Contentとともにインストールされます。このコンポーネントが有効になっているときには、最もアクセス頻度の高いコンテンツ・アイテムや、ユーザーまたは特定グループにとって最も価値の高いコンテンツなど、システム使用に関する情報が提供されます。このコンポーネントをカスタマイズして、組織のコンテンツの消費パターンに関する特定の情報を提供できます。
この章の内容は次のとおりです。
デフォルト設定でのContent Trackerの使用の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージメント』のコンテンツ・アクセスの追跡に関する項を参照してください。
.
Content Trackerでは、コンテンツ・サーバーのインスタンスのアクティビティが監視され、それらのアクティビティについて選択した詳細が記録されます。この項では、Content Trackerの機能について概要を説明します。
Content Trackerには、構成変数によって制御されるいくつかの最適化機能が組み込まれています。変数のデフォルト値によって、大規模な本番環境で可能なかぎり効率的に機能するようにContent Trackerを設定できます。Content Trackerの構成変数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』のContent Trackerに関する項を参照してください。
Content Trackerでは、様々なアクティビティに関するシステムおよびレコードの情報が監視されます。この情報は様々なソースから収集され、マージされてコンテンツ・サーバー・データベース内の一連の表に書き込まれます。Content Trackerでは、次のアクセスおよびサービスに基づいてアクティビティを監視できます。
コンテンツ・アイテム・アクセス: コンテンツ・アイテムの使用に関する情報
データは、Webフィルタ・ログ・ファイル、コンテンツ・サーバー・データベースおよびその他の外部アプリケーション(ポータルやWebサイトなど)から取得されます。コンテンツ・アイテム・アクセスのデータには、日付、時刻、コンテンツIDおよび現在のメタデータが含まれます。
コンテンツ・サーバー・サービス: コンテンツを返すすべてのサービス、および検索リクエストを処理するサービス。デフォルトでは、Content Trackerがログに記録するのは、コンテンツ・アクセス・イベント・タイプを持つサービスのみですが、構成を変更すれば、Content Trackerは、カスタム・サービスまで含め、コンテンツ・サーバーのいかなるサービスでも監視できます。
ユーザー・アクセス: ユーザー・プロファイルのサマリーの収集や統合など、コンテンツ・アクセス・イベント以外の他の情報。このデータには、ユーザー名およびユーザー・プロファイル情報が含まれます。
Content Trackerにはデバッグ構成変数SctDebugServiceBinderDumpEnableがあり、有効にすると、サービス・ハンドラ・フィルタが構成されてサービスDataBinderオブジェクトがダンプ・ファイルに書き込まれます。フィールド・マップ画面を開発するときに、これを診断ツールとして使用できます。ダンプ・ファイルを使用すると、特定のサービス・イベントが記録されるときに使用可能なデータを参照できます。
Content Trackerによって特定のサービスがログ・ファイルに記録されると、そのサービスのDataBinderオブジェクトの内容が、シリアル化されたダンプ・ファイルに書き込まれます。これらのファイルの内容は、拡張されたサービス・コール・トラッキング機能を使用するためのフィールド・マップを作成する際に、デバッグ用に役立ちます。これらのダンプ・ファイルを使用して、記録されたサービスに使用可能なLocalDataフィールドを確認できます。
Content Trackerサービス・ハンドラ・フィルタによってDataBinderオブジェクトのダンプ・ファイルが作成されるのは、関連付けられたサービスがSctServiceFilter.hdaファイル内に定義されている場合のみです。
注意:
DataBinderオブジェクトのダンプ・ファイルは、手動で削除しないかぎり蓄積され続けます。SctDebugServiceBinderDumpEnabled構成変数は、必要な場合にのみ使用してください。
この構成変数の値は、FalseまたはTrueになります。
SctDebugServiceBinderDumpEnabled=Falseに設定すると、Content Trackerサービス・ハンドラ・フィルタによってDataBinderオブジェクトはダンプ・ファイルに書き出されません。これはデフォルト値です。
SctDebugServiceBinderDumpEnabled=Trueに設定すると、DataBinderオブジェクトがダンプ・ファイルに書き出されるようにContent Trackerサービス・ハンドラ・フィルタが構成されます。ダンプ・ファイルは、拡張されたサービス・ロギング用のフィールド・マップを開発する際の診断ツールとして使用します。サービス用のフィールド・マップを作成する場合は、ダンプ・ファイルを使用すると、サービス・イベントの記録時に使用可能なデータを確認できます。
シリアル化されたDataBinderオブジェクトは、ダンプ・ファイルに書き込まれます。
IntradocDir/data/ContentTracker/DEBUG_BINDERDUMP/dump_file_name
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
Content Trackerでは、コンテンツ・アクセス・イベントのデータのみが収集および記録されます。この処理では、検索などのコンテンツ・アクセス・イベント以外での情報収集や、ユーザー・プロファイルのサマリーの収集および統合は除外されます。
Content Trackerには、構成変数で制御される最適化関数がいくつか組み込まれています。変数のデフォルト値は、Content Trackerが大規模な本番環境で可能なかぎり効率的に機能するようにを設定できます。代替値は、インストール時に設定するか、または後で変更できます。
次のパフォーマンス変数を使用できます。
SctTrackContentAccessOnly
コンテンツ・アクセスのみ: この変数により、収集される情報のタイプが決定します。これを有効(デフォルト)にすると、コンテンツ・アクセス・イベントのみが記録されます。
SctDoNotPopulateAccessLogColumns
列の除外: この変数の値は、Content TrackerでSctAccessLog表に移入されない列のリストです。デフォルトでは、出力表のサイズを削減するために、大規模な情報やほとんど使用しない情報は収集されません。
SctSimplifyUserAgent
ユーザー・エージェントの簡素化: この変数によって、SctAccessLog表のcs_userAgent列に格納される情報が最小限になります。
SctDoNotArchive
アーカイブしない: この変数によって、すべてのContent Trackerデータベース表には最近のデータが格納され、期限切れの表行はアーカイブされずに破棄されます。デフォルトでは、SctAccessLog表のみ移入され、期限切れの行はアーカイブされません。ただし、SctTrackContentAccessOnlyとSctDoNotArchiveの両方を無効にすると、すべての表が移入され、期限切れデータがアーカイブされます。
Content Trackerのカスタマイズには、構成変数を使用できます。
次の表に、現行バージョンのContent Trackerで使用される構成設定のデフォルト値を示します。これらの構成変数は、Content Tracker構成ファイルに含まれています。
cs_root/data/contenttracker/config/sct.cfg
| 構成設定 | デフォルト値 | 注釈 |
|---|---|---|
SctAutoTruncateDataStrings |
FALSE |
使用: JAVA削減プロセスでデータ文字列を対応する表列に収まるように切り捨てるかどうかを指定します。 |
SctComponentDir |
cs_root/data/ contenttracker/ |
使用: JAVAContent Trackerがインストールされているディレクトリへのパス。 |
SctDebugLogEnabled |
FALSE |
使用: JAVA
|
SctDebugLogFilePath |
cs_root/data/ contenttracker/log/ SCT_DEBUG_TRACE.log |
使用: JAVAJavaコード実行トレースのディレクトリ。 |
SctDebugServiceBinderDumpEnabled |
FALSE |
使用: JAVA
|
SctExternalUserLogEnabled |
TRUE |
使用: JAVA
|
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/ |
使用: JAVAContent Trackerが未加工のイベント・ログ( |
SctLogEnabled |
TRUE |
使用: フィルタ・プラグイン、JAVA
|
SctMaxRecentCount |
5 |
使用: JAVA削減済のデータが |
SctMaxRereadTime |
3600 |
使用: JAVA特定のユーザーが特定のコンテンツ・アイテム(PDFファイルなど)を連続して参照したとき、連続する参照が1つの持続するアクセスとしてみなされる最大の秒間隔。連続する参照の時間間隔がこの値より大きい場合、別々のアクセスとしてカウントされます。 |
SctReductionAvailableDatesLookback |
0 |
使用: JAVA使用可能な日付範囲を制限するために |
SctReductionLogDir |
cs_root/data/ contenttracker/log/ |
使用: JAVAContent Tracker削減ログが格納されるディレクトリへのパス。 |
SctReductionRequireEventLogs |
TRUE |
使用: JAVA添付解除された構成で使用されます。 |
SctScheduledReductionEnable |
TRUE |
使用: JAVA複数JVM構成において、削減を実行するコンテンツ・サーバー・インスタンスを選択するために使用されます。 |
SctSnapshotEnable |
FALSE |
使用: JAVA
|
SctSnapshotLastAccessEnable |
FALSE |
使用: JAVA
|
SctSnapshotLastAccessField |
[なし] |
使用: JAVA最終アクセス日付のメタデータ・フィールド名( |
SctSnapshotLongCountEnable |
FALSE |
使用: JAVA
|
SctSnapshotLongCountField |
[なし] |
使用: JAVA長期間隔カウントのメタデータ・フィールド名( |
SctSnapshotLongCountInterval |
[なし] |
使用: JAVA長期間隔の日数。データ・エンジン・コントロール・センターから設定します。 |
SctSnapshotShortCountEnable |
FALSE |
使用: JAVA
|
SctSnapshotShortCountField |
[なし] |
使用: JAVA短期間隔カウントのメタデータ・フィールド名( |
SctSnapshotShortCountInterval |
[なし] |
使用: JAVA短期間隔の日数。データ・エンジン・コントロール・センターから設定します。 |
SctUseGMT |
FALSE |
使用: フィルタ・プラグイン、JAVA
|
次の変数は、sct.cfgファイルでは利用できず、コンポーネント・マネージャを使用した場合にのみアクセスできます。
| 構成設定 | デフォルト値 | 注釈 |
|---|---|---|
SctPostReductionExec |
[なし] |
使用: JAVA削減後実行可能ファイルへのパス( |
SctProxyNameMaxLength |
50 |
使用: JAVA構成内のコンテンツ・サーバー・プロキシ・サーバー名の最大文字数。Content Trackerの表作成でユーザー名フィールドのサイズを増やす場合に使用されます。 |
SctUrlMaxLength |
3000 |
使用: JAVAURLフィールドの予測される最大長(文字数)。表の作成時に列幅を決定するために使用されます。1つの特定の表にこのような列が複数存在する場合があります。 |
SctWebBeaconIDList |
[なし] |
使用: フィルタ・プラグイン Webビーコン・オブジェクトのリスト(オブジェクトがゼロの場合もあります)。クライアント側タグを使用してデータをContent Trackerにフィードする機能を追加する場合に必要です。Content Trackerで、キャッシュされたページのデータや、キャッシュされたサービスから生成されたページのデータを収集できるようになります。 |
Content Trackerの構成変数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』のContent Trackerに関する項を参照してください。
インストール時は、セキュリティ・チェック・プリファレンス・チェックボックスを空白にしておきます。これは、ACLベースのシステムでは、セキュア・モードが無効になっている必要があることを意味します。この場合、システム管理者以外のユーザーに、本来はアクセスと表示の権限を付与していないコンテンツ・アイテムの情報が表示される可能性があります。
セキュリティ・チェック・プリファレンス変数は、次の値のいずれかになります。
SctrEnableSecurityChecks=Trueに設定すると、セキュリティ・チェック・インストール・プリファレンスが有効化されます。
セキュア・モードでは、コンテンツ・サーバーの検索結果を制限するために使用されたのと同じセキュリティ基準(ロールおよびアカウントの制限)が、生成されるレポートにも適用されます。このため、2つの異なるユーザーが「上位アクセス・コンテンツ・アイテム」レポートを実行した場合、異なる結果が表示されることがあります。
SctrEnableSecurityChecks=Falseに設定すると、セキュリティ・チェック・インストール・プリファレンスが無効化されます。これがデフォルトの設定です。
非セキュア・モードの場合、コンテンツ・サーバーの検索結果を制限するのに使用された追加のロールおよびアカウント基準は、生成されるレポートに適用されません。このため、システム管理者以外のユーザーに、アクセスと表示の権限を付与していないコンテンツ・アイテムの情報が表示される可能性があります。
デフォルトでは、Content TrackerによってGIF、JPG、JS、CSS、CABおよびCLASSファイル・タイプへのアクセスはログに記録されません。したがって、これらのファイル・タイプのエントリは、データ削減後、結合された出力表に挿入されません。
これらのファイル・タイプをログに記録するには、IntradocDir/custom/ContentTracker/resources/ディレクトリにあるsct.cfgファイル内でファイル・タイプを有効化する必要があります。SctIgnoreFileTypes構成変数(gif,jpg,js,css)のデフォルトの設定を変更します。デフォルト設定では、これらのファイル・タイプは除外されます。これらのファイル・タイプの一部のみを含めるには、リストから目的の各ファイル・タイプを削除します。この変更を有効にするには、Webサーバーおよびコンテンツ・サーバーを再起動する必要があります。
Content Tracker構成変数を設定または編集する手順は、次のとおりです。
データ・エンジン・コントロール・センターに組み込まれているユーザー・インタフェースを使用して、アクティビティ・メトリック・メタデータ・フィールドの構成変数を追加または編集します。次のような変数があります。
SctSnapshotEnable
SctSnapshotLastAccessEnable
SctSnapshotLastAccessField
SctSnapshotLongCountEnable
SctSnapshotLongCountField
SctSnapshotLongCountInterval
SctSnapshotShortCountEnable
SctSnapshotShortCountField
SctSnapshotShortCountInterval
ユーザー・インタフェースとアクティビティ・メトリック関数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のデータ追跡関数に関する項を参照してください。
Content Trackerで適用可能レポートに外部ユーザー・アクセスに関するデータを含めるかどうかを制御するオプションがあります。これらの認証済ユーザーは、ユーザー・ロールおよびアカウントに基づいて権限を与えられています。デフォルトでは、構成パラメータSctExternalUserLogEnabledはtrue(有効)に設定されています。これによって、Content Trackerでは、外部ユーザー・ログインが監視され、そのロールおよびアカウント情報がUserSecurityAttributes表に自動的に伝播されます。
SctExternalUserLogEnabled構成変数が有効か無効かに関係なく、外部ユーザーのコンテンツ・アイテム・アクセス情報はすべて追跡されて記録されます。ただし、この構成変数が有効化されている場合は、外部で認証されたユーザー名とそれに関連付けられたユーザー・ロールおよびアカウントとの相関関係を明示的に示すレポートに、このデータが含められます。具体的には、「ユーザー・ロール別上位アクセス・コンテンツ・アイテム」レポートおよび「ユーザー・ロール別ユーザー」レポートに、外部ユーザーによるすべてのコンテンツ・アイテム・アクセス・アクティビティが含められます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のContent Trackerレポートに関する項を参照してください。
注意:
SctExternalUserLogEnabled構成変数を手動で無効にする方法の詳細は、「Content Tracker構成変数の設定」を参照してください。
サービス・コール構成ファイルでサービス・コールを構成し、イベントをログに記録するようにContent Trackerロギング・サービスを構成して、サービス・コール情報を管理できます。
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ファイルにサービスを追加するか、またはファイルから除外します。この方法は、特定のサービスまたはすべてのサービスに対するロギングを制御する場合に効率的です。また、拡張されたサービス・コール・トラッキング機能を使用すると、特定のサービスに対してログに記録されるデータのタイプをカスタマイズできます。
SctServiceFilter.hdaファイルにリストされたサービスはContent Trackerサービス・ハンドラ・フィルタによって検出され、選択されたデータ・フィールドの値が取得されます。その後に、Content Trackerでは指定されたサービス・コールがログに記録されます。タイムスタンプなどとともに、情報がSctAccessLog表に動的に書き込まれます。
Content Trackerでは、有効になっているサービスごとに、dUserやdDocNameなど、特定の標準のDataBinderフィールドが自動的にログに記録されます。また、拡張されたサービス・コール・トラッキング機能に関連付けられているDataBinderフィールドのログが、SctAccessLog表の汎用の列に記録されます。
データは、Content Tracker固有のサービス順序番号およびサービスのタイプ指定Sを使用して、SctAccessLog表にリアルタイムで挿入されます。(Wの指定は、静的URLイベント・タイプを示します。)手動削減、スケジュールされた削減、あるいはその両方での削減が必要になるのは、Webサーバー・フィルタによって収集された静的URLアクセス情報を処理する場合のみです。
拡張されたサービス・コール・トラッキング機能を使用すると、コンテンツ・サーバーのサービス・コールをログに記録でき、構成された各サービス・コールでログに記録される標準のDataBinderフィールド以外に1つ以上の追加DataBinderフィールドから関連データ値をログに記録することによって、この情報を補完することもできます。
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列の内容をオーバーライドできます。この場合は、MyUserNameとsc_scs_dUserを結合して、データ・フィールド、格納場所、およびフィールド・マップResultSet内の表列のセットとして使用します。
ログに記録されるデータがSctAccessLogの列タイプと適合していることを確認する必要があります。
リンクされたサービス・エントリおよびResultSetの例は、「リンクされたサービス・エントリおよびフィールド・マップResultSet」を参照してください。SctAccessLog表とデータ・フィールドにマップされる汎用列の内容の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』の結合された出力表に関する項を参照してください。
拡張されたサービス・トラッキング用のフィールド・マップResultSet内で、DataBinderフィールドをSctAccessLog表の列にマップします。汎用列(extField_1からextField_10)はマッピングに使用できます。これらの列には、特定のサービスに対するロギングおよびトラッキングに適した任意のデータ値を挿入できます。標準の表列がオーバーライドされることを回避するために、これらの列を使用することをお薦めします。
ヒント:
サービスの名前は常にsc_scs_idcService列に記録されます。拡張フィールドのコンテンツを使用する問合せには、修飾子としてこれを含めます。SctAccessLog表の列が関わる特定のSQL問合せが含まれているカスタム・レポートの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のレポート作成タイプに関する項を参照してください。
最初のサービス・コール構成ファイル(SctServiceFilter.hda)は、共通に使用されてコンテンツ・サーバーに固有のコンテンツ・アクセス、検索およびユーザー認証サービスで構成されます。このファイルには、ログに記録される各サービスに1つずつエントリが存在するResultSet構造が含まれます。拡張されたサービス・コール・トラッキング機能をサポートするために、ServiceExtraInfo ResultSet内のサービス・エントリにリンクされたフィールド・マップResultSetをこのファイルに含めることもできます。
データ・エンジン・コントロール・センターからアクセスする「サービス」ユーザー・インタフェースを使用して、SctServiceFilter.hdaファイルに新規のエントリを追加するか、既存のエントリを編集するか、またはその両方を行います。あるいは、ファイル内のエントリを手動で変更します。詳細は、「SctServiceFilter.hdaファイルの手動編集」を参照してください。
注意:
Content TrackerによってSctAccessLog表に記録される最初のサービスのセットを確認するには、次のSctServiceFilter.hdaファイルを参照してください。
cs_root/data/contenttracker/config/SctServiceFilter.hda
次の表に、サービス・コール構成ファイルのResultSetスキーマの詳細を示します。値は、SctAccessLog表内の対応する列に直接コピーされます。
ServiceExtraInfo ResultSetのコンテンツ
| 機能 | 説明 |
|---|---|
サービス名( |
ロギングされるサービスの名前。 |
呼出し元製品( |
任意の文字列。この文字列は、通常、すべての標準コンテンツ・サーバー・エントリに対して「Core Server」に設定されています。 |
イベント・タイプ( |
任意の文字列。この文字列は、通常、すべての標準コンテンツ・サーバー・エントリに対して「Content Access」に設定されています。 |
参照 ( |
|
フィールドの変更( |
|
フィールド・マップResultSetの内容
| 機能 | 説明 |
|---|---|
「フィールドの変更」リンク |
フィールド・マップResultSetの名前。 サービスDataBinderオブジェクトを書き出す構成変数を設定できます。これにより、イベントが記録されるときに使用可能なデータを参照できます。 |
「DataBinder」フィールド( |
SctAccessLog表の汎用列にデータ値が記録される |
データの場所( |
ログに記録されるフィールドが配置されているコンテンツ・サーバー・サービスDataBinderのセクション。「フィールドの変更」画面の「フィールドの場所」フィールドも参照してください。 |
アクセス・ログ列( |
指定したDataBinderフィールドのデータ値がロギングされる |
DataBinderからコピーされてSctAccessLog表に挿入されるフィールドには、dID、dDocName、IdcService、dUser、SctCallingProduct、SctEventTypeおよびSctReferenceがあります。最後の3つのフィールドの値がSctServiceFilter.hdaファイル内のサービスのエントリに含まれている場合は、それらの値はデータ・フィールド内の対応する値をオーバーライドします。
サービス・ハンドラ・フィルタを介してログに記録されるサービスと、Content Trackerロギング・サービスを介してログに記録されるサービスとの間に、重複や競合はないはずです。サービスの名前がContent Trackerサービス・ハンドラ・フィルタ・ファイルに指定されている場合、そのサービスは自動的にログに記録されるため、Content Trackerロギング・サービスによる記録は不要です。
注意:
必要なサービス・コールをSctServiceFilter.hdaファイルに追加し、この方法を使用して特定のアクティビティを記録すると、CallingProduct、EventTypeおよびReferenceフィールドの値を指定できる長所があります。割り当てた値は、SctAccessLog表内の対応する列に直接コピーされます。
デフォルトのSctServiceFilter.hdaファイルには、各種の共通のサービス・コールが含まれています。
注意:
Content TrackerによってSctAccessLog表に記録される最初のサービスのセット、サービス・エントリおよびフィールド・マップResultSetを確認するには、次のSctServiceFilter.hdaファイルを参照してください。
cs_root/data/contenttracker/config/SctServiceFilter.hda
これらのサービスの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentサービス・リファレンス』のコアContent Serverサービスに関する項を参照してください。
次のリストに、SctServiceFilter.hdaファイルのServiceExtraInfo ResultSetに含まれるサービス・エントリの例をいくつか示します。
GET_FILE_BY_NAME
コア・サーバー
コンテンツ・アクセス
GET_DYNAMIC_URL
コア・サーバー
コンテンツ・アクセス
GET_DYNAMIC_CONVERSION
コア・サーバー
コンテンツ・アクセス
GET_EXTERNAL_DYNAMIC_CONVERSION
コア・サーバー
コンテンツ・アクセス
GET_ARCHIVED_FILE
コア・サーバー
コンテンツ・アクセス
COLLECTION_GET_FILE
Folders
コンテンツ・アクセス
次の表に、フィールド・マップResultSetにリンクされたサービス・エントリの例をいくつか示します。これらの例やその他の類似する例は、最初のSctServiceFilter.hdaファイルに含まれています。
| サービス・エントリ | フィールド・マップResultSet |
|---|---|
|
|
|
|
|
|
Content Trackerロギング・サービスは、アプリケーションによって1つのイベントをSctAccessLog表に記録できる単一のサービス・コール(SCT_LOG_EVENT)です。このサービスは、URLを介して直接呼び出すか、サービス・スクリプト内のアクションとして呼び出すか、またはIdoc ScriptからexecuteService()を使用して呼び出すことができます。呼出し元アプリケーションによって、記録されるサービスDataBinder内の一部または全部のフィールドが設定され、これには、Content TrackerのSctServiceFilter.hda構成ファイルにリストされている記述フィールドが含まれます。
SCT_LOG_EVENTサービスによって、サービスDataBinderから情報がコピーされます。このデータは、Content Tracker固有のサービス順序番号およびサービスのタイプ指定「S」を使用して、SctAccessLog表にリアルタイムで挿入されます。手動またはスケジュール実行、あるいはその両方での削減が必要になるのは、Webサーバー・フィルタによって収集された静的URLアクセス情報を処理する場合のみです。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のデータの削減に関する項を参照してください
注意:
サービス・ハンドラ・フィルタを介してログに記録されるサービスと、Content Trackerロギング・サービスを介してログに記録されるサービスとの間に、重複や競合はないはずです。サービスの名前がContent Trackerサービス・ハンドラ・フィルタ・ファイルに指定されている場合、それらのサービスは自動的にログに記録されるため、Content Trackerロギング・サービスによる記録は不要です。ただし、Content Trackerでは、このような重複を回避する処理は行われません。
この項では、コンテンツ・サーバー・サービスからのデータを結合された出力データベース表(SctAccessLog)にマップして記録するための情報およびタスクの手順について説明します。
次の表に、Content Trackerロギング・サービス(SCT_LOG_EVENT)が呼び出されたときにContent Trackerで検索されるSctAccessLogの列名および対応するDataBinderフィールドを示します。アプリケーションでは、Content Trackerロギング・サービスを呼び出すときに、Content Trackerで検索されるサービスDataBinder内の必要なフィールドを設定します。SctAccessLogフィールドの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』の結合された出力表に関する項を参照してください
| SctAccessLogの列名 | サービスDataBinder LocalDataフィールド |
|---|---|
|
[計算される] |
|
|
|
|
|
[計算される] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[計算される - |
|
N/A |
|
N/A |
|
N/A |
|
N/A |
|
N/A |
|
|
SCT_LOG_EVENTサービスをアプリケーションから呼び出すことができます。これは、アプリケーション開発者、またはアプリケーション・サービス・スクリプトを変更するユーザーが実行できます。
SCT_LOG_EVENTを呼び出すことができます。SCT_LOG_EVENTへのコールをサービス・スクリプトに含めることもできます。Content Trackerでは、サービス・コールを、関連付けられたサービスに関連するデータ値とともにログに記録できます。ログに記録する各サービスには、サービス・コール構成ファイル(SctServiceFilter.hda)内にサービス・エントリが存在している必要があります。ログに記録するサービスに加えて、対応するフィールド・マップResultSetをSctServiceFilter.hdaに含めることができます。
Content Trackerでは、コンテンツ・アクセスのイベント・タイプを持つサービス、またはDocHistory表への入力が発生するサービスのみがログに記録されます。これにより、パフォーマンスは最大になりますが、一部のサービス・イベントはログに記録されません。
有効化されたサービスによって、一般的なDataBinderフィールド(dUser、dDocNameなど)が自動的に記録されます。フィールド・マップResultSetをサービス・エントリにリンクすると、拡張されたサービス・コール・トラッキング機能を使用できます。
SctAccessLogデータベース表には、拡張されたサービス・コール・トラッキング機能で使用できる追加の列が用意されていて、この列には、関連付けられたサービス・コールに適した任意のデータ値を入力できます。フィールド・マップResultSet内にデータ・フィールド名をリストする場合は、データ・フィールドのソースの格納場所名、およびデータの記録先の表列名もリストします。
注意:
フィールド・マップResultSetでは、SctAccessLog表の既存の標準列にデータ・フィールドをマップできます。標準のフィールド・データ値が収集されると、拡張されたサービス・マッピングが実行されます。したがって、表の標準の列フィールドは、いずれもオーバーライドできます。
たとえば、ログに記録するサービスのデータ・フィールドに特定のユーザー名(MyUserName=john)が含まれるとします。拡張されたトラッキング機能を使用して、sc_scs_dUser列の内容を上書きできます。この場合は、MyUserNameとsc_scs_dUserを結合して、データ・フィールド、格納場所、およびフィールド・マップResultSet内の表列のセットとして使用します。
ログに記録されるデータがSctAccessLogの列タイプと適合していることを確認する必要があります。
サービスを追加または編集するには、次の手順を実行します。
エントリを削除するには、前の手順を実行してエントリを選択し、「削除」を選択します。
拡張されたサービス・コール・トラッキング機能を実装するには、サービス・エントリをSctServiceFilter.hdaファイル内のフィールド・マップResultSetにリンクする必要があります。
フィールド・マップを追加してリンクするには、次の手順を実行します。
Content Trackerでは、データ・エンジン・コントロール・センターの拡張されたサービス・トラッキング機能に対して、エラー・チェック(フィールド・タイプやスペルの検証など)は実行されません。削減が実行されるまで、エラーは生成されません。これらのフィールドでは、大/小文字が区別されます。新規のフィールド・マップResultSetを追加したり、既存のフィールド・マップResultSetを編集する場合は、正確な名前を入力し、フィールドの値がすべて、スペルも大文字/小文字も正しいことを確認してください。
フィールド・マップを編集するには、前の手順を実行し、必要に応じてエントリを編集します。
エントリを削除するには、前の手順を実行してサービス・エントリを選択し、「削除」を選択します。
スナップショット機能を使用すると、検索関連カスタム・メタデータ・フィールドをログに記録して追跡できます。Content Trackerでは、特定のコンテンツ・アイテムの人気度を反映するコンテンツ・アイテム使用状況およびアクセス情報がこれらのフィールドに挿入されます。この情報には、2つの異なる時間間隔における最新アクセスの日付およびアクセス数が含まれます。スナップショット機能の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のアクティビティ・スナップショットに関する項を参照してください。
スナップショット機能およびアクティビティ・メトリックが有効化されている場合は、削減処理フェーズに続いて、カスタム・メタデータ・フィールドの値が更新されます。ユーザーがコンテンツ・アイテムにアクセスすると、適用可能な検索関連メタデータ・フィールドの値がそれに応じて変わります。その後、Content Trackerでは、削減処理後の手順として3つのSQL問合せが実行され、レポート作成期間中にアクセスされたコンテンツ・アイテムが特定されます。処理後の削減ステップの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のアクティビティ・メトリックによるデータ削減プロセスに関する項を参照してください。
SQL問合せは、リソースとして使用可能であり、最終トラッキング・データから情報をフィルタ処理するようにカスタマイズできます。たとえば、表形式の結果から、特定のユーザーによるアクセスを除外できます。
SQL問合せは、sctQuery.htmファイルに含まれています。
IntradocDir/custom/ContentTracker/resources/SctQuery.htm
注意:
通常、SQL問合せ内のWHERE句は変更できます。これ以外は変更しないことをお薦めします。
検索関連カスタム・メタデータ・フィールドには、次のSQL問合せが使用されます。
qSctLastAccessDate: 最終アクセス機能の場合、この問合せではSctAccessLog表が使用されます。この問合せでは、削減日におけるすべてのコンテンツ・アイテム・アクセスがチェックされ、dIDごとに最新のタイムスタンプが収集されます。この問合せのパラメータは、削減日です。この場合、最終アクセス日付の比較テストによって変更が示されるのは、提示された新しい値よりも既存のDocMeta値が古い場合のみであるため、日付はランダムな順序で削減できます。
qSctAccessCountShortおよびqSctAccessCountLong: 短期と長期のアクセス・カウント機能の場合、SQL問合せのqSctAccessCountShortおよびqSctAccessCountLongは、カウントの列名以外は同じです。これらの問合せでは、SctAccessLog表を使用して、それぞれに指定された時間間隔(日数)にわたる各dIDの全アクセスについて合計が計算されます。パラメータは、適用可能なロールアップの開始日および終了日です。
Content Trackerで適用可能レポートに外部ユーザー・アクセスに関するデータを含めるかどうかを制御するオプションがあります。これらの認証済ユーザーは、ユーザー・ロールおよびアカウントに基づいて権限を与えられています。デフォルトでは、構成パラメータSctExternalUserLogEnabled はtrue(有効)に設定されています。これによって、Content Trackerでは、外部ユーザー・ログインが監視され、そのロールおよびアカウント情報がUserSecurityAttributes表に自動的に伝播されます。
SctExternalUserLogEnabled 構成変数が有効か無効かに関係なく、外部ユーザーのコンテンツ・アイテム・アクセス情報はすべて追跡されて記録されます。ただし、この構成変数が有効化されている場合は、外部で認証されたユーザー名とそれに関連付けられたユーザー・ロールおよびアカウントとの相関関係を明示的に示すレポートに、このデータが含められます。具体的には、「ユーザー・ロール別上位アクセス・コンテンツ・アイテム」レポートおよび「ユーザー・ロール別ユーザー」レポートに、外部ユーザーによるすべてのコンテンツ・アイテム・アクセス・アクティビティが含められます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のカスタム・レポート問合せに関する項を参照してください。
注意:
SctExternalUserLogEnabled構成変数を手動で無効化する方法は、「Content Tracker構成変数の設定」を参照してください。
注意:
Webビーコン機能の実装要件は、関連するシステム構成に依存しています。このドキュメントでは、すべての要素には対応できません。Content Trackerで収集および処理されるアクセス・レコードに関する情報は、正確なカウントではなく、一般的なユーザー・アクティビティを示すものです。
Webビーコンは、Webページまたは他の管理対象コンテンツへの間接ユーザー・アクセスを容易に追跡するための特別サポートを提供する管理対象オブジェクトです。Content Trackerの以前のリリースでは、キャッシュされたページのデータや、キャッシュされたサービスから生成されたページのデータは収集できませんでした。キャッシュされたWebページやコンテンツ・アイテムにユーザーがアクセスした場合、コンテンツ・サーバーやContent Trackerではこれらのリクエストが発生したことを認識できていません。Webビーコン参照を使用しないと、Content Trackerではこのようなリクエストを記録してカウントできません。
Webビーコンを使用すると、クライアント側では、コンテンツ・サーバー内の管理対象ビーコン・オブジェクトへの目にみえない参照として埋込み参照を使用できます。これにより、Content Trackerでは、コンテンツ・サーバーからコンテンツを直接取得せずに、再配布のために外部エンティティによってコピーされた管理対象コンテンツ・アイテムに対するユーザー・アクセス・リクエストを記録してカウントできます。これが使用されるような状況の詳細は、「Webビーコンのユースケース」を参照してください。
キャッシュされたコンテンツがコンシューマに提供されると、ユーザーは、リクエストされたオブジェクトがコンテンツ・サーバーで提供されていたことを認識します。管理対象コンテンツは実際には、動的ではないコンテンツ配信方法を使用して提供されます。この状況では、管理対象コンテンツは静的Webサイト、リバース・プロキシ・サーバーまたはファイル・システム外から対応されます。Webビーコン機能によって、このタイプのアクティビティが確実に追跡されます。
特に、Webビーコン機能を使用するだけの価値があると思われる状況は、リバース・プロキシ・アクティビティとSite Studio使用の2つです。
リバース・プロキシ・シナリオでは、リバース・プロキシ・サーバーは、ユーザーとコンテンツ・サーバーの間に位置します。リバース・プロキシ・サーバーはリクエストされたオブジェクトのコピーを作成することにより、管理対象コンテンツ・アイテムをキャッシュします。別のユーザーが次回にドキュメントを要求すると、プライベート・キャッシュ内のコピーが表示されます。リバース・プロキシ・サーバーのキャッシュ内にオブジェクトが存在しない場合は、コピーがリクエストされます。
リバース・プロキシ・サーバーはキャッシュされたコンテンツを配信するため、コンテンツ・サーバーと直接相互作用することはありません。したがって、Content Trackerではこれらのリクエストを検出できないため、このユーザー・アクセス・アクティビティを追跡できません。
リバース・プロキシ・サーバーは、キャッシュしたり、ファイアウォールの内側にあるアプリケーションやサイトへのWebアクセスを管理することによって、Webパフォーマンスを向上させるために使用されることがよくあります。そのような構成では、頻繁にアクセスされるコンテンツのコピーをWebサーバーに移動し、そこでスケジュールに基づいて構成を更新することによってロード・バランシングが実現します。
Webビーコン機能を有効にするために、各ユーザー・アクセスには、コンテンツ・サーバーの管理対象ビーコン・オブジェクトへの追加リクエストが含まれています。これによって通常のリクエストよりもオーバーヘッドが増加しますが、Webビーコン・オブジェクトは非常に小さいため、リバース・プロキシ・サーバーのパフォーマンスに大きな影響を与えることはありません。必要なのが、特に追跡するオブジェクトにWebビーコン参照を埋め込む操作のみであることに注意してください。
別の使用シナリオに関係するのがSite Studioです。これは、コンテンツ・サーバーで格納および管理されるWebサイトを作成するために使用される製品です。Site StudioとContent Serverが同じサーバーに存在する場合、Content Trackerは適用可能なユーザー・アクセスを自動的に追跡するように構成されます。収集されたSite Studioアクティビティ・データは、事前定義済レポートで使用されます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentのマネージング』のSite Studio Webサイトのアクティビティ・レポートに関する項を参照してください。
注意:
Site StudioとContent Trackerの統合には2つのモードを使用できます。1つは、Site Studioがインストールされたときに自動的に行われる既存の組込み統合のタイプです。通常、これが使用されるのは、Webサイトが作成中で、Webページがコンテンツ・サーバーで管理されている場合です。
もう1つは、Webビーコン機能を使用して、Content TrackerがSite Studioを他のWebサイト・ジェネレータと同様に扱う形式です。通常、これが使用されるのは、Webサイトが本番モードで、コンテンツがコンテンツ・サーバーで管理されなくなった場合です。
Webサイトが外部対象者向けの場合は、サイトのコピーを作成して、別のサーバーに転送できます。このソリューションでは、サイトをパブリックに表示すること以外に、開発サイトと本番サイトを別々にすることも可能です。ただし、この配置の場合は、Webビーコン機能を実装して、Content Trackerでユーザー・アクティビティを収集および処理できるようにします。
Content Trackerでは、コンテンツ・サーバーで管理されているオブジェクトに対するリクエストが記録されカウントされます。Webビーコン機能を使用すると、外部エンティティ(リバース・プロキシ・サーバーや、コンテンツ・サーバーに関与しない他の機能など)でコピーされた管理対象オブジェクトに対するリクエストがカウントされます。
次のリストでは、Webビーコン機能および実装要件の概要を簡単に説明します。
Webビーコン機能の実装を開始するには、Webビーコン・オブジェクトを作成します。これは通常、小さなオブジェクト(縦横1ピクセルの透明なイメージなど)です。次に、このオブジェクトをチェックインし、Content TrackerのWebビーコン・オブジェクト名リストに追加します。
次に、チェックインしたWebビーコン・オブジェクトへのWebビーコン参照を作成して、キャッシュされたHTMLページまたは管理対象コンテンツ・アイテムに埋め込みます。参照の最初の部分はWebビーコン・オブジェクトへのURL参照であり、2番目の部分は疑似問合せパラメータとしてエンコードされている識別情報です。
Content Trackerでは、ビーコン・オブジェクトに対するWebビーコン参照がログに記録され、Webビーコン参照に対して削減処理が実行されます。データ削減中に、Content Trackerでは、登録されたWebビーコンのリストと照合して各参照先オブジェクトのdDocName値が確認されます。dDocName値がリストに存在する場合、問合せパラメータは、URLリクエストがWebビーコン・オブジェクトではなくタグ付きオブジェクト(Webページや管理対象コンテンツ・アイテム)に対するリクエストとしてログに記録されるように処理されます。
Webビーコン・オブジェクトとして使用するには、1つ以上のコンテンツ・アイテムを作成する必要があります。これらは通常、縦横1ピクセルの透明なイメージなど、オーバーヘッドが小さくページのレンダリングを妨げないものが適しています。コンテンツがないWebビーコン・オブジェクトが理想的です。複数のWebビーコン・オブジェクトを作成できますが、必要なのは1つのみです。オブジェクトが、SctIgnoreFileType構成変数に含まれるファイル・タイプでないことを確認してください。
完成したオブジェクトをチェックインして、Content TrackerのSctWebBeaconIDList構成変数を更新します。データ削減中に、Content Trackerでは、SctWebBeaconIDList設定が確認され、イベント・ログ内のWebビーコン参照リストの処理方法が決定されます。適用可能なWebビーコン・オブジェクトがリストされている場合、Content Trackerではデータが適切に処理されます。構成変数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』を参照してください
インストール中に、Webビーコン・オブジェクトのdDocName値をSctWebBeaconIDListプリファレンス変数に入力できます。また、後で追加または編集することもできます。IDリストでオブジェクト名を追加または編集するには、次の手順を実行します。
Webビーコン・オブジェクトを作成してチェックインした後で、対応する参照を作成します。異なる問合せ文字列がWebビーコンの静的URLに付加されることによって各参照が一意になるため、ほとんどのシステムでWebビーコン・オブジェクトは1つで十分です。また、各問合せパラメータ・セットは、キャッシュされた特定のWebページまたは管理対象コンテンツ・アイテムを識別する変数の個別の組合せで構成されます。
WebビーコンURL参照は、コンテンツ・サーバーで管理されるWebビーコン・オブジェクトへのアクセスに使用するWebビーコン静的URL、およびコンテンツ・アイテム変数を指定した擬似問合せ文字列で構成されます。
参照を作成するときは、コンテンツ・サーバー内のWebビーコン静的URLに、SctIgnoreDirectories構成変数に含まれるディレクトリ・ルートが使用されていないことを確認してください。URLが、リストされている値のいずれかである場合は、Content Trackerではアクティビティ・データが収集されません。SctIgnoreDirectories構成変数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』のSctIgnoreDirectoriesに関する項を参照してください。
問合せパラメータ・セットは、ユーザーがアクセスした実際の管理対象コンテンツ・アイテムをContent Trackerに通知するコードとして機能します。問合せパラメータの1つがアイテムのdIDです。問合せパラメータ値の一意のセットを含めることによって、コピーおよびキャッシュされた管理対象オブジェクトに対する間接ユーザー・アクセス・アクティビティを監視できます。問合せ文字列が実際に実行されることはありませんが、問合せパラメータ値によって、関連付けられている管理対象オブジェクトをContent Trackerが識別するために十分な情報が提供されます。
次の例では、Webビーコン機能に関連する一般的なフォーマット構造について説明します。これらの例では、異なる問合せ文字列を数に制限なく作成しながら、1つのWebビーコン・オブジェクトを使用する方法について説明します。すべての例で、同じWebビーコン・オブジェクト(dDocName = bcn_2.txt)を使用します。このWebビーコン・オブジェクトに対するリクエストは、問合せパラメータを変えることによって、リポジトリ内のすべての管理対象オブジェクトに対するリクエストをContent Trackerに通知できます。
これらの例では、次のことを想定しています。
Webビーコン・オブジェクト(bcn_2.txt)はチェックインされ、Webビーコン・リスト(SctWebBeaconIDList)に含まれています。
適用可能なWebビーコン参照は、関連付けられた管理対象コンテンツ・アイテム(doc1、doc2およびdoc3)に埋め込まれています。
Webビーコン参照を解決するために、ブラウザではWebビーコン・オブジェクトのコピーをコンテンツ・サーバーからリクエストする必要があります。
ユーザーが関連するコンテンツ・アイテムを間接的にリクエストするため、Webビーコン・リクエストが発生します。
例15-1 問合せパラメータを使用しないWebビーコン・リクエスト
http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt
これは、Webビーコン・オブジェクトへの静的Web参照から始まります。これはWebビーコン・オブジェクトへの正当な直接アクセスですが、問合せパラメータは追加されていません。Content Trackerでは、このアクセス・イベントをWebビーコン・オブジェクト自体に対するリクエストとして処理します。
例15-2 doc1を追跡するためのWebビーコン・リクエスト
http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=doc1&sct_dID=1234&...
これも、このビーコン・オブジェクトへの通常の静的Web参照から始まります。これには任意の数の問合せパラメータを含む擬似問合せ文字列が追加されています。これらの問合せパラメータに含まれる値によって、ユーザーがリクエストした特定の管理対象オブジェクト(doc1)に関する情報が通知されます。
例15-3 doc2を追跡するためのWebビーコン・リクエスト
http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=doc2&sct_Ext_2=WebSite4
これは、{例 - doc3を追跡するためのWebビーコン・リクエスト}に似ています。パラメータ値によって、ユーザーがリクエストしたコンテンツ・アイテム(doc2)に関する情報が提供されます。この例では、問合せ文字列に、タグ付きアイテムに関する追加情報を通知するための別のパラメータが含まれています。追加されたパラメータではextField列名が使用されます。値WebSite4はSctAccessLog表のextField_2列にコピーされます。extField列の置換はオプションで、アプリケーションに依存しています。
例15-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列名を追加することによって、{例 - doc2を追跡するためのWebビーコン・リクエスト}を変更します。この場合、WebSite4はSctAccessLog表のextField_2列にコピーされ、SubscriptionClass6はextField_8列にコピーされます。extField列の置換はオプションで、アプリケーションに依存しています。
追跡する管理対象オブジェクトに、特別に作成されたWebビーコン参照を埋め込む必要があります。Webビーコン参照はHTMLページに埋め込むことができます。ユーザーは、変更された管理対象コンテンツ・アイテムへのアクセスを、外部のSite Studio Webサイトまたはリバース・プロキシ・サーバーを介して、間接的にリクエストします。
ブラウザでは、ページのレンダリング中にWebビーコン参照を検出します。管理対象オブジェクトを表示するたびに(オブジェクトの取得方法に関係なく)、ブラウザではWebビーコン・オブジェクトのコピーをコンテンツ・サーバーから直接リクエストします。ブラウザがWebビーコン参照を解決すると、Content Trackerでは、Webビーコン参照、および管理対象コンテンツ・アイテムを識別するための擬似問合せパラメータを含むデータを取得します。
データ削減中に、特別に作成されたWebビーコン参照が処理されると、Content Trackerでは、WebビーコンのdDocName値をSctWebBeaconIDリストのdDocName値のリストと比較して、通常のコンテンツ・アイテムではなくWebビーコン・オブジェクトに対するリクエストであるかどうかを判別します。
一致するものがない場合、または問合せパラメータがWebビーコン参照に追加されていない場合、Content Trackerではアクセス・イベントを通常どおりに処理します。WebビーコンのdDocNameが特定された場合、Content Trackerでは処理を続行し、関連付けられたURLの問合せパラメータを解釈します。また、データ削減プロセスでは、Webビーコン・アクセス・リクエストが、Webページまたはコンテンツ・アイテムへのリクエストとして扱われます。
データ削減中に、Content Trackerでは、問合せパラメータを解析し、最終的にSctAccessLogに書き込まれるフィールドの様々な値の置換を実行します。問合せパラメータ値は次のようにマップされます。
sct_dIDはWebビーコン・オブジェクトのdID値を置換します。sct_dDocNameはWebビーコン・オブジェクトのdDocName値を置換します。sct_uriStemはWebビーコン・オブジェクトのURIステム(疑問符?より前の部分)を置換します。sct_uriQueryはWebビーコン・オブジェクトのURI問合せ部分(疑問符?より後の部分)を置換します。sct_Ext_nはSctAccessLogの拡張フィールドnに直接コピーされます。例15-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つのフィールド置換はオプションで、アプリケーションに依存しています。)
Content TrackerのWebビーコン機能を実装するには、次の手順を実行します。
次の制限事項を検討してください。
1つの難点は、Webビーコン参照をタグ付きオブジェクトに添付する方法を決定することです。リクエストされたオブジェクトに参照を埋め込むことができない場合があります(PDF文書やWord文書など)。この場合は、実際のコンテンツ・アイテムがリクエストされる前に、Webビーコン・オブジェクトをコンテンツ・サーバーから直接リクエストする必要があります。
Webビーコン機能は、特定のブラウザ構成の場合など、多くの状況で動作しません。ユーザーがブラウザのクロスドメイン参照を無効化し、Webページとコンテンツ・サーバー・インスタンスが異なるドメインに存在する場合、Webビーコン・オブジェクトはコンテンツ・サーバーからリクエストされることはなく、ユーザー・アクセスはカウントされません。
リバース・プロキシ・サーバーを経由して最初に管理対象コンテンツ・アイテムにアクセスすると、コンテンツ・サーバーがアイテムをリバース・プロキシ・サーバーに提供したときに1回、ブラウザがWebビーコン・オブジェクトをリクエストしたときに1回の計2回カウントされます。
特定の構成によっては、リバース・プロキシ・サーバーおよび外部のSite StudioがWebビーコン・オブジェクト自体をキャッシュしない方法を考案する必要があります。ブラウザでもキャッシュが行われます。この状況では、コンテンツ・サーバーは関連するコンテンツ・アクセスをカウントできません。これを回避するには、この例にあるように、乱数を含む1回かぎりの問合せパラメータをWebビーコン参照に追加します。
dDocName=vvvv_1_21&FoolTheProxyServer=12345654321
各リクエストの数値を変更することによって、キャッシュ、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では、キャッシュされたコンテンツ・アイテムが配信されたかどうかを確認できません。
Content Trackerでは、静的URLアクセスの通常の折りたたみ動作が実行されます。ユーザーが同じコンテンツ・アイテムを繰返しリクエストし、別のドキュメントに対するリクエストが途中で介入しない場合、Content Trackerでは連続するリクエストは同じドキュメントであるとみなされます。この場合、これらのアクセス・リクエストはすべて1つのアクセス・リクエストとみなされます。
問合せパラメータは任意の管理対象オブジェクトを表すことができ、必ずしもユーザーに実際に表示されている内容である必要はありません。
Webビーコン機能を実装するには、いくつかの埋込み方法を使用できます。各方法にはそれぞれ長所と短所があり、特定の状況に応じて最適な方法は異なります。システム構成には違いがあるため、最適な1つの方法があるわけではありません。
以降に示す例ではすべて、次の情報を使用しています。
WebBeacon.bmp Webビーコン・オブジェクト
コンテンツ・サーバーのインスタンスIFHE.comcast.net/idc/
dDocName値wb_bmp
すべての例のコード・フラグメント・ファイルは、Content Trackerのドキュメント・ディレクトリに含まれています。これらの例は、一般的なアプローチを示すことを意図したものであり、開始ポイントとして提供されています。使用しているアプリケーションやネットワーク・トポロジで機能するように調整が必要になります。
管理対象コンテンツ・アクセスを追跡するWebビーコンを最も簡単かつ直接的に使用するには、ビーコンへの参照を対象のWebページのHTLMソースに直接埋め込みます。リクエスト・ユーザーのブラウザでは、ページをレンダリングするとき、Webビーコン・オブジェクトが存在するインスタンスにリクエストが送信されます。
この例では、追跡対象のWebページにイメージ・タグが配置されます。イメージのsrc attributeは、インスタンスにチェックインされているWebビーコン・オブジェクト(wb_bmp)を参照します。ユーザーのブラウザでインスタンスからイメージをロードすると、追加の問合せ情報が記録され、最終的にdDocName BOPRへの参照として解釈されます。
この方法は簡単ですが、ユーザーのブラウザまたはリバース・プロキシ・サーバーでWebビーコン・オブジェクトのコピーがキャッシュされるという短所があります。このため、インスタンスに直接送信される追加リクエストはなく、この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" />
Webビーコンのキャッシュに関する問題は、HTMLのかわりにJavaScriptを使用することによって解決でき、このJavaScriptを埋め込む方法には、2つのスクリプト・タグが必要です。
cs_callWebBeacon関数は、実際のWebビーコン・リクエストを発行します。
名前の付いていないブロックでは、コンテキスト値を特定のJavaScript変数に割り当ててcs_callWebBeacon関数を呼び出します。
管理対象コンテンツ・オブジェクトに関して識別される情報は変数のリストに定義されるため、読みやすくなります。乱数を擬似問合せパラメータに追加することによって、Webビーコン・リクエストを効率的に一意にすることもできます。
デメリットとしては、管理対象のコードが増えることや、Webビーコン・サーバーのURLが各Webページにハードコードされることなどがあります。また、ユーザーのブラウザで、JavaScriptが有効になっていない場合も考えられます。
この方法のJavaScriptフラグメントは次のように記述できます。
// WebBeaconEmbeddedJavascript.js - Adjust the managed object and Web Beacon descriptors,
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>
「JavaScriptを埋め込む方法の例」で説明したWebビーコン・サーバーのハードコードに関する問題は、コードを2つのフラグメントに分割することによって解決します。
管理対象コード・フラグメントには、cs_callWebBeacon関数が含まれています。これは、コンテンツ・サーバー・インスタンス(Webビーコンを管理するインスタンス、または他のインスタンスのいずれか)にチェックインして管理できます。ページ内コード・フラグメントに含まれるsrc属性は管理対象コード・フラグメントを参照し、これによって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>
