| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 11gリリース1(11.1.1) B72427-01 |
|
 前 |
 次 |
ホーム > Oracle WebCenter Contentによる開発 > Content Trackerのカスタマイズ
| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 11gリリース1(11.1.1) B72427-01 |
|
前 |
次 |
ホーム > Oracle WebCenter Contentによる開発 > Content Trackerのカスタマイズ
Content Trackerと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を設定できます。Content Trackerの構成変数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』を参照してください。
Content Trackerでは、様々なアクティビティに関するシステムおよびレコードの情報が監視されます。この情報は様々なソースから収集され、マージされてコンテンツ・サーバー・データベース内の一連の表に書き込まれます。Content Trackerでは、次のアクセスおよびサービスに基づいてアクティビティを監視できます。
コンテンツ・アイテム・アクセス: コンテンツ・アイテムの使用に関する情報
データは、Webフィルタ・ログ・ファイル、コンテンツ・サーバー・データベースおよびその他の外部アプリケーション(ポータルやWebサイトなど)から取得されます。コンテンツ・アイテム・アクセスのデータには、日付、時刻、コンテンツIDおよび現在のメタデータが含まれます。
コンテンツ・サーバー・サービス: コンテンツを返すすべてのサービス、および検索リクエストを処理するサービス。デフォルトでは、Content Trackerがログに記録するのは、コンテンツ・アクセス・イベント・タイプを持つサービスのみですが、構成を変更すれば、Content Trackerは、カスタム・サービスまで含め、コンテンツ・サーバーのいかなるサービスでも監視できます。
ユーザー・アクセス: ユーザー・プロファイルの概要の収集や統合など、コンテンツ・アクセス・イベント以外の他の情報。このデータには、ユーザー名およびユーザー・プロファイル情報が含まれます。
Content Trackerによってデータが抽出され、データベース表に移入された後で、Content Trackerレポートを使用すると、次の処理ができます。
レポートの生成: Content Trackerレポートでは、表を問い合せて、コンテンツ・アイテムのアクティビティのサマリー・レポートおよび使用状況履歴が生成されます。これらのレポートを使用すると、コンテンツまたはユーザーの特定グループを、メタデータ、ファイル拡張子またはユーザー・プロファイルに基づいて分析できます。事前定義されたレポートを使用してカスタマイズするか、または互換性のあるサード・パーティのレポート作成パッケージを使用します。
コンテンツ管理プラクティスの最適化: レポートされたデータを、コンテンツ保存管理に使用できます。アクセス頻度に応じて、一部のアイテムをアーカイブまたは削除できます。同様に、アプリケーションではこのデータを使用して、特定タイプのユーザーの上位アクセス・コンテンツをポートレットに提供できます。
Content Trackerにはデバッグ構成変数があり、有効にすると、サービス・ハンドラ・フィルタが構成されてサービスDataBinderオブジェクトがダンプ・ファイル(SctDebugServiceBinderDumpEnable)に書き込まれます。フィールド・マップ画面を開発するときに、これを診断ツールとして使用できます。ダンプ・ファイルを使用すると、特定のサービス・イベントが記録されるときに使用可能なデータを参照できます。
Content Trackerによって特定のサービスがログ・ファイルに記録されると、そのサービスのDataBinderオブジェクトの内容が、シリアル化されたダンプ・ファイルに書き込まれます。これらのファイルの内容は、拡張されたサービス・コール・トラッキング機能を使用するためのフィールド・マップを作成する際に、デバッグ用に役立ちます。これらのダンプ・ファイルを使用して、記録されたサービスに使用可能なLocalDataフィールドを確認できます。
Content Trackerサービス・ハンドラ・フィルタによってDataBinderオブジェクトのダンプ・ファイルが作成されるのは、関連付けられたサービスがSctServiceFilter.hdaファイル内に定義されている場合のみです。
|
注意: DataBinderオブジェクトのダンプ・ファイルは、手動で削除しないかぎり蓄積され続けます。 |
この構成変数の値は、次のとおりです。
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
| 構成設定 | デフォルト値 | 注釈 |
|---|---|---|
|
FALSE |
使用: JAVA 削減プロセスでデータ文字列を対応する表列に収まるように切り捨てるかどうかを指定します。 |
|
|
cs_root/data/contenttracker/ |
使用: JAVA Content Trackerがインストールされているディレクトリへのパス。 |
|
|
FALSE |
使用: JAVA TRUEに設定すると、Javaコード実行トレースが有効化されます。SctDebugLogFilePathとともに使用されます。 |
|
|
cs_root/data/contenttracker/ |
使用: JAVA Javaコード実行トレースのディレクトリ。SctDebugLogEnabledとともに使用されます。 |
|
|
FALSE |
使用: JAVA TRUEに設定すると、サービス・ロギング中にサービスDataBinderオブジェクトの診断出力が有効化されます。 |
|
|
SctExternalUserLogEnabled |
TRUE |
使用: JAVA TRUEに設定すると、外部ユーザー・アカウントおよびロールの情報のUserSecurityAttributes表へのレプリケーションが有効化されます。 |
|
cs_root/data/contenttracker/ |
使用: フィルタ・プラグイン フィルタ・プラグインによってイベント・ログが格納されるディレクトリへのパス。 |
|
|
フィルタ・プラグインに渡され、Content Tracker起動フィルタによってidcAuthExtraConfigParamsにプログラムでマージされるContent Tracker構成パラメータのリスト。 |
||
|
|
使用: フィルタ・プラグイン リストされたディレクトリ・ルート内に含まれるURLを無視するようにフィルタ・プラグインに指示します。 |
|
|
gif、jpg、js、css |
使用: フィルタ・プラグイン リストされたファイルタイプを持つURLを無視するようにフィルタ・プラグインに指示します。 |
|
|
|
使用: JAVA 未加工のイベント・ログ(sctLogなど)をContent Trackerが探す1つ以上のディレクトリへのパス。このパラメータは、 |
|
|
TRUE |
使用: フィルタ・プラグイン、JAVA FALSEの場合、すべてのイベントを無視してログを作成しないようにサービス・ハンドラ・フィルタおよびWebサーバー・フィルタ・プラグインに指示します。これは、Content Trackerマスターのオン/オフのスイッチです。 |
|
|
TRUE |
使用: フィルタ・プラグイン、JAVA TRUEの場合、IMMEDIATE_RESPONSE_PAGEイベントをsctSecurityLogイベント・ログに記録するようにフィルタ・プラグインに指示し、イベント・ログを読み取るように削減プロセスに指示します。 |
|
|
5 |
使用: JAVA 削減済のデータが「最新」状態として保持される最大日数。「最新」からオーバーフローしたデータは「アーカイブ」状態に移行します。 |
|
|
3600 |
使用: JAVA 特定のユーザーが特定のコンテンツ・アイテム(PDFファイルなど)を連続して参照したとき、連続する参照が1つの持続するアクセスとしてみなされる最大の秒間隔。次の参照との時間間隔が大きい場合は、個別のアクセスとしてカウントされます。 |
|
|
0 |
使用: JAVA 使用可能な日付範囲を制限するためにSctReductionRequireEventLogsとともに使用されます。単位 = 日数。ゼロ = 無制限。 |
|
|
cs_root/data/contenttracker/log/ |
使用: JAVA Content Tracker削減ログが格納されるディレクトリへのパス。 |
|
|
TRUE |
使用: JAVA 添付解除された構成で使用されます。FALSEは、イベント・ログが見つからない場合でも削減を続行することを示します。 |
|
|
TRUE |
使用: JAVA 複数JVM構成において、削減を実行するコンテンツ・サーバー・インスタンスを選択するために使用されます。 |
|
|
FALSE |
使用: JAVA TRUEに設定すると、スナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。 |
|
|
FALSE |
使用: JAVA TRUEに設定すると、最終アクセス日付のスナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。 |
|
|
[なし] |
使用: JAVA 最終アクセス日付のメタデータ・フィールド名(xLastAccessDateなど)。データ・エンジン・コントロール・センターから設定します。 |
|
|
FALSE |
使用: JAVA TRUEに設定すると、長期間隔アクセス・カウントのスナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。 |
|
|
[なし] |
使用: JAVA 長期間隔カウントのメタデータ・フィールド名(xAccessesInLast90Daysなど)。データ・エンジン・コントロール・センターから設定します。 |
|
|
[なし] |
使用: JAVA 長期間隔の日数。データ・エンジン・コントロール・センターから設定します。 |
|
|
FALSE |
使用: JAVA TRUEに設定すると、短期間隔アクセス・カウントのスナップショット機能が有効化されます。データ・エンジン・コントロール・センターから設定します。 |
|
|
[なし] |
使用: JAVA 短期間隔カウントのメタデータ・フィールド名(xAccessesInLast10Daysなど)。データ・エンジン・コントロール・センターから設定します。 |
|
|
[なし] |
使用: JAVA 短期間隔の日数。データ・エンジン・コントロール・センターから設定します。 |
|
|
FALSE |
使用: フィルタ・プラグイン、JAVA 記録されたイベント時間を世界標準時に変換する場合は、TRUEに設定します。FALSEに設定すると、ローカル時間が使用されます。 |
次の変数は、sct.cfgファイルでは利用できず、コンポーネント・マネージャを使用した場合にのみアクセスできます。
| 構成設定 | デフォルト値 | 注釈 |
|---|---|---|
|
[なし] |
使用: JAVA 削減後実行可能ファイルへのパス(IntradocDir/custom/ContentTracker/bin/内と想定)。 |
|
|
50 |
使用: JAVA 構成内のコンテンツ・サーバー・プロキシ・サーバー名の最大文字数。Content Trackerの表作成でユーザー名フィールドのサイズを増やす場合に使用されます。 |
|
|
3000 |
使用: JAVA URLフィールドの予測される最大長(文字数)。表の作成時に列幅を決定するために使用されます。1つの特定の表にこのような列が複数存在する場合があります。 |
|
|
[なし] |
使用: フィルタ・プラグイン Webビーコン・オブジェクトのリスト(オブジェクトがゼロの場合もあります)。クライアント側タグを使用してデータをContent Trackerにフィードする機能を追加する場合に必要です。Content Trackerで、キャッシュされたページのデータや、キャッシュされたサービスから生成されたページのデータを収集できるようになります。 |
Content Trackerの構成変数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』を参照してください。
Content Trackerレポートのコンポーネントをインストールすると、セキュリティ・チェック・プリファレンス変数(SctrEnableSecurityChecks)が設定されます。このプリファレンス変数では、2つのセキュリティ・モード(セキュア・モードおよび非セキュア・モード)のいずれかを選択できます。セキュリティ・チェック・プリファレンスには、個々のユーザー・ロールおよびアカウント情報を使用して、レポート結果におけるコンテンツ・アイテム情報の表示を制限するためのオプションがあります。
これは、生成されるレポートでユーザーに表示されるコンテンツ・アイテム(およびその後のメタデータ)を制御することを意味します。ユーザーがコンテンツ・サーバー検索で見つけられなかった内容はContent Trackerレポートでも表示されないようにすることが理想的です。セキュア・モードを使用すると、生成されるレポートの情報は、ユーザーのロールおよびアカウント権限に基づいてフィルタ処理されます。
ただし、コンテンツ・サーバーのインスタンスに対してアクセス制御リスト(ACL)が有効化されている場合、Content Trackerレポートのセキュア・モード・オプションは機能しません。インストール時は、セキュリティ・チェック・プリファレンス・チェックボックスを空白にしておきます。これは、ACLベースのシステムでは、セキュア・モードが無効になっている必要があることを意味します。この場合、システム管理者以外のユーザーに、本来はアクセスと表示の権限を付与していないコンテンツ・アイテムの情報が表示される可能性があります。
セキュリティ・チェック・プリファレンス変数の値は、次のとおりです。
SctrEnableSecurityChecks=Trueに設定すると、セキュリティ・チェック・インストール・プリファレンスが有効化され、Content Trackerレポートがセキュア・モードで動作するように構成されます。
セキュア・モードでは、コンテンツ・サーバーの検索結果を制限するために使用されたのと同じセキュリティ基準(ロールおよびアカウントの制限)が、「Content Trackerレポートの生成」の問合せおよび生成されるレポートにも適用されます。このため、2つの異なるユーザーが「上位アクセス・コンテンツ・アイテム」レポートを実行した場合、異なる結果が表示されることがあります。
SctrEnableSecurityChecks=Falseに設定すると、セキュリティ・チェック・インストール・プリファレンスが無効化され、Content Trackerレポートが非セキュア・モードで動作するように構成されます。これがデフォルトの設定です。
非セキュア・モードの場合、コンテンツ・サーバーの検索結果を制限するのに使用された追加のロールおよびアカウント基準は、「Content Trackerレポートの生成」の問合せおよび生成されるレポートに適用されません。このため、システム管理者以外のユーザーに、アクセスと表示の権限を付与していないコンテンツ・アイテムの情報が表示される可能性があります。
デフォルトでは、Content TrackerによってGIF、JPG、JS、CSS、CABおよびCLASSファイル・タイプへのアクセスはログに記録されません。したがって、これらのファイル・タイプのエントリは、データ削減後、結合された出力表に挿入されません。
これらのファイル・タイプをログに記録するには、IntradocDir/custom/ContentTracker/resources/ディレクトリにあるsct.cfgファイル内でファイル・タイプを有効化する必要があります。SctIgnoreFileTypes構成変数(gif,jpg,js,css)のデフォルトの設定を変更します。デフォルト設定では、これらのファイル・タイプは除外されます。これらのファイル・タイプの一部のみを含めるには、リストから目的の各ファイル・タイプを削除します。この変更を有効にするには、Webサーバーおよびコンテンツ・サーバーを再起動する必要があります。
Content Tracker構成変数を設定または編集する手順は、次のとおりです。
テキスト・エディタで、sct.cfgファイルを開きます。
cs_root/data/contenttracker/config/sct.cfg
編集する構成ファイルを検索します。
適用可能な値を入力します。
sct.cfgファイルを保存して閉じます。
コンテンツ・サーバーを再起動して変更内容を適用します。
データ・エンジン・コントロール・センターに組み込まれているユーザー・インタフェースを使用して、アクティビティ・メトリック・メタデータ・フィールドの構成変数を追加または編集します。次のような変数があります。
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レポートに関する項を参照してください。
サービス・コール構成ファイルでサービス・コールを構成し、イベントをログに記録するようにContent Trackerロギング・サービスを構成して、サービス・コール情報を管理できます。
Content Trackerサービス・ハンドラ・フィルタを使用すると、コンテンツ・リクエスト以外のコンテンツ・サーバー・アクティビティに関する情報が収集できます。サービス・ハンドラ・フィルタによってサービス・リクエスト詳細が収集され、リアルタイムでSctAccessLog表に格納されます。詳細は、サービス・コールに付随するDataBinderから取得されます。コンテンツ・サーバー・サービス・コールをログに記録するには、サービス・コール構成ファイル(SctServiceFilter.hda)内にそのエントリが存在している必要があります。
SctServiceFilter.hdaファイルはユーザーが変更可能な構成ファイルで、ログに記録されるサービス・コールの数を制限するために使用されます。これによって、ログに記録されるサービスを選択的に管理できます。SctServiceFilter.hdaファイルに含まれている任意のサービス・コールのデータ・ロギング機能を拡張して、特定のサービスに関連する特定のDataBinderフィールドのデータ値を記録および追跡することもできます。詳細は、第14.3.1.2項「拡張されたサービス・コール・トラッキング機能」を参照してください。
サービス・トラッキングは、サーバー・ソケット・ポートを介してコールされる最上位レベルのサービスに制限されます。サブサービス、または内部で呼び出されるサービスは追跡できません。
SctServiceFilter.hdaファイルの目的は、ユーザーがコンテンツ・サーバーのどの部分に特に関心があるかを定義することです。SctServiceFilter.hdaファイルにリストされていないコンテンツ・サーバー・サービスは、Content Trackerで無視されます。また、このファイルにリストされていないサービスは、Content Trackerロギング・サービスでのみログに記録できます。詳細は、第14.3.2項「Content Trackerロギング・サービスについて」を参照してください。
SctServiceFilter.hdaファイルは、次の2つの方法で変更できます。
データ・エンジン・コントロール・センターから、新規サービスを追加し、ファイル内の既存のサービス・コール・パラメータを編集します。
SctServiceFilter.hdaファイルを手動で編集します。
詳細は、第14.3.3.1項「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の例については、第14.3.1.4.2項「リンクされたサービス・エントリとフィールド・マップResultSet」を参照してください。SctAccessLog表のコンテンツと、データ・フィールドにマップされる汎用列のコンテンツの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』の結合された出力表に関する項を参照してください。
拡張されたサービス・トラッキング用のフィールド・マップResultSet内で、DataBinderフィールドをSctAccessLog表の列にマップします。汎用列(extField_1からextField_10)はマッピングに使用できます。これらの列には、特定のサービスに対するロギングおよびトラッキングに適した任意のデータ値を挿入できます。標準の表列がオーバーライドされることを回避するために、これらの列を使用することをお薦めします。
|
ヒント: サービスの名前は常に |
最初のサービス・コール構成ファイル(SctServiceFilter.hda)は、共通に使用されてコンテンツ・サーバーに固有のコンテンツ・アクセス、検索およびユーザー認証サービスで構成されます。このファイルには、ログに記録される各サービスに1つずつエントリが存在するResultSet構造が含まれます。拡張されたサービス・コール・トラッキング機能をサポートするために、ServiceExtraInfo ResultSet内のサービス・エントリにリンクされたフィールド・マップResultSetをこのファイルに含めることもできます。
データ・エンジン・コントロール・センターからアクセスする「サービス」ユーザー・インタフェースを使用して、SctServiceFilter.hdaファイルに新規のエントリを追加するか、既存のエントリを編集するか、またはその両方を行います。あるいは、ファイル内のエントリを手動で変更します。詳細は、第14.3.3.1項「SctServiceFilter.hdaファイルの手動編集」を参照してください。
|
注意: Content TrackerによってSctAccessLog表に記録される最初のサービスのセットを確認するには、次の cs_root |
次の表に、サービス・コール構成ファイルのResultSetスキーマの詳細を示します。値は、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表内の対応する列に直接コピーされます。 |
デフォルトのSctServiceFilter.hdaファイルには、各種の共通のサービス・コールが含まれています。
|
注意: Content TrackerによってSctAccessLog表に記録される最初のサービスのセット、サービス・エントリおよびフィールド・マップResultSetを確認するには、次の cs_root これらのサービスの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentサービス・リファレンス』を参照してください。 |
次のリストに、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
次の表に、フィールド・マップResultSetにリンクされたサービス・エントリの例をいくつか示します。これらの例やその他の類似する例は、最初のSctServiceFilter.hdaファイルに含まれています。
| サービス・エントリ | フィールド・マップResultSet |
|---|---|
|
|
|
|
|
|
Content Trackerロギング・サービスは、アプリケーションによって1つのイベントをSctAccessLog表に記録できる単一のサービス・コール(SCT_LOG_EVENT)です。このサービスは、URLを介して直接コールするか、またはサービス・スクリプト内のアクションとしてコールすることができます。また、executeService()関数を使用して、Idocスクリプトから呼び出すこともできます。呼出し元アプリケーションによって、記録されるサービス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)にマップして記録するための情報およびタスクの手順について説明します。
SctServiceFilter.hdaファイルのエントリを追加または変更する手順は、次のとおりです。
テキスト・エディタで、SctServiceFilter.hdaファイルを開きます。
cs_root/data/contenttracker/config/.../SctServiceFilter.hd
既存のエントリを編集するか、または新規のサービス・エントリを追加します。たとえば、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をスキップします。
拡張されたサービス・トラッキングを使用する場合は、対応するフィールド・マップResultSetを追加または編集します。たとえば、SS_GET_PAGEサービスを追加し、追加のデータ・フィールド値を追跡するには、次のサービス・エントリおよび対応するフィールド・マップResultSetをファイルに入力します。
| サービス・エントリ | フィールド・マップResultSet |
|---|---|
|
|
|
注意: DataBinderフィールド、格納場所および表列名のセットは、必要な数だけ含めてください。 |
ファイルを保存して閉じます。
コンテンツ・サーバーを再起動して、新しい定義を適用します。
|
注意: 検索リクエスト・イベントはリアルタイムで |
次の表に、Content Trackerロギング・サービス(SCT_LOG_EVENT)がコールされたときにContent Trackerで検索されるSctAccessLogの列名および対応するDataBinderフィールドを示します。アプリケーションでは、Content Trackerロギング・サービスを呼び出すときに、Content Trackerで検索されるサービスDataBinder内の必要なフィールドを設定します。SctAccessLogフィールドの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』の結合された出力表に関する項を参照してください。
| 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 (or 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 |
SCT_LOG_EVENTサービスをアプリケーションから呼び出すことができます。これは、アプリケーション開発者、またはアプリケーション・サービス・スクリプトを変更するユーザーが実行できます。アプリケーションではJavaからSCT_LOG_EVENTを呼び出すことができます。または、アプリケーションでSCT_LOG_EVENTへのコールをサービス・スクリプトに含めることもできます。
Content Trackerでは、サービス・コールを、関連付けられたサービスに関連するデータ値とともにログに記録できます。ログに記録する各サービスには、サービス・コール構成ファイル(SctServiceFilter.hda)内にサービス・エントリが存在している必要があります。ログに記録するサービスに加えて、対応するフィールド・マップResultSetをSctServiceFilter.hdaに含めることができます。
Content Trackerでは、コンテンツ・アクセスのイベント・タイプを持つサービス、またはDocHistory表への入力が発生するサービスのみがログに記録されます。これにより、パフォーマンスは最大になりますが、一部のサービス・イベントはログに記録されません。
有効化されたサービスによって、一般的なDataBinderフィールド(dUser、dDocNameなど)が自動的に記録されます。フィールド・マップResultSetをサービス・エントリにリンクすると、拡張されたサービス・コール・トラッキング機能を使用できます。
SctAccessLogデータベース表には、拡張されたサービス・コール・トラッキング機能で使用できる追加の列が用意されていて、この列には、関連付けられたサービス・コールに適した任意のデータ値を入力できます。フィールド・マップResultSet内にデータ・フィールド名をリストする場合は、データ・フィールドのソースの格納場所名、およびデータの記録先の表列名もリストします。
|
注意: フィールド・マップResultSetでは、SctAccessLog表の既存の標準列にデータ・フィールドをマップできます。標準のフィールド・データ値が収集されると、拡張されたサービス・マッピングが実行されます。したがって、表の標準の列フィールドは、いずれもオーバーライドできます。 たとえば、ログに記録するサービスのデータ・フィールドに特定のユーザー名( ログに記録されるデータがSctAccessLogの列タイプと適合していることを確認する必要があります。 |
「メイン」メニューから「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センターが開きます。
「サービス」タブをクリックします。
「追加」をクリックしてサービス・エントリを新規作成するか、または「サービス名」リストから既存のサービス・エントリを選択し、「編集」をクリックします。
「拡張されたサービス・トラッキング」画面が開きます。新規のサービス・エントリを追加したときには、フィールドは空です。既存のサービス・エントリを編集する場合は、編集可能な値がフィールドに移入されます。
適用可能なフィールド値を入力または変更します(「フィールドの変更」フィールドの値を除く)。
このサービス・エントリをフィールド・マップResultSetにリンクするには、適用可能な名前を「フィールドの変更」フィールドに入力して、フィールドをリンクします。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のメタデータ・フィールドへのアクティビティ・メトリックのリンク関する項を参照してください。
「OK」をクリックします。
「確認」ダイアログ・ボックスが表示されます。
「OK」をクリックします。
「サービス」リストで、「サービス」タブが、新規のサービスまたは新たに編集されたサービスを反映して再表示されます。サービス状態およびContent TrackerのSctServiceFilter.hdaが更新されます。
Content Trackerでは、データ・エンジン・コントロール・センターの拡張されたサービス・トラッキング機能に対して、エラー・チェック(フィールド・タイプやスペルの検証など)は実行されません。削減が実行されるまで、エラーは生成されません。これらのフィールドでは、大/小文字が区別されます。新規のサービスを追加したり、既存のサービスを編集する場合は、サービス・コール名を正確に入力するように注意してください。すべてのフィールド値が正しいスペルおよび大/小文字になるようにします。
エントリを削除するには、前の手順を実行してエントリを選択し、「削除」を選択します。
拡張されたサービス・コール・トラッキング機能を実装するには、サービス・エントリをSctServiceFilter.hdaファイル内のフィールド・マップResultSetにリンクする必要があります。
フィールド・マップを追加してリンクするには、次の手順を実行します。
「メイン」メニューから「管理」→「Content Tracker管理」を選択します。「データ・エンジン・コントロール・センター」を選択します。
データ・エンジン・コントロール・センターが開きます。
「サービス」タブをクリックします。
新規のエントリを追加するには、第14.3.4.1項「サービス・エントリの追加、編集または削除」で説明した手順を実行します。「サービス名」リストからサービス・エントリを選択します。
「編集」をクリックします。
「拡張されたサービス・トラッキング」画面が開きます。必要な場合は、フィールド・マップResultSetの追加に加えて、このサービス・エントリの値をここで編集します。
このサービスがすでにフィールド・マップResultSetにリンクされている場合は「フィールドの変更」フィールドに名前がリストされ、データ・フィールド、格納場所および表列の1つ以上のセットが「フィールド」領域にリストされます。
選択したサービスがセカンダリResultSetにリンクされていない場合、「フィールドの変更」フィールドは空です。フィールド・マップResultSetの名前を入力してください。選択したサービスがすでにリンクされている場合は、この手順をスキップしてください。
「追加」をクリックします。
「フィールドの変更」画面が開きます。
次のフィールドに適切な値を入力します。
フィールド名: データ値がSctAccessLog表の汎用列にロギングされるサービスDataBinderのデータ・フィールドの名前。
フィールドの場所: ログに記録されるデータ・フィールドが配置されているOracle WebCenter Content ServerサービスDataBinderのセクション。次の値が使用できます。
LocalData (デフォルト値)
環境
BinderResultSet。これは、ResultSet内のすべての値を含むカンマ・デリミタを返します。サイズがカンマなども含めて255文字に制限されているため、この値が役立つのは、ResultSetが小さい場合のみです。
より多くの文字に対応するには、標準データベース・ツールを使用してSctAccessLog表の列を拡張/再定義します。たとえば、extField_3を2047に広げると、同量のデータが保持されます。ただし、ほとんどのデータベースには、ページ・サイズの制限があります。また、SQLでは文字列が効率的に解析されません。
列名: 指定したDataBinderフィールドのデータ値がロギングされるSctAccessLog表の列。
「OK」をクリックします。
「フィールドの変更」画面が閉じ、値が「フィールド名」および「列名」フィールドに追加されます。
「OK」をもう一度クリックします。
確認ダイアログ・ボックスが表示されます。
「サービス」タブが、更新された情報を反映して再表示されます。
「OK」をクリックします。
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の管理』のカスタム・レポート問合せの作成に関する項を参照してください。
|
重要: Webビーコン機能の実装要件は、関連するシステム構成に依存しています。このドキュメントでは、すべての要素には対応できません。Content Trackerで収集および処理されるアクセス・レコードに関する情報は、正確なカウントではなく、一般的なユーザー・アクティビティを示すものです。 |
Webビーコンは、Webページまたは他の管理対象コンテンツへの間接ユーザー・アクセスを容易に追跡するための特別サポートを提供する管理対象オブジェクトです。Content Trackerの以前のリリースでは、キャッシュされたページのデータや、キャッシュされたサービスから生成されたページのデータは収集できませんでした。キャッシュされたWebページやコンテンツ・アイテムにユーザーがアクセスした場合、Oracle WebCenter Content ServerやContent Trackerでは、これらのリクエストが発生したことを認識できませんでした。Webビーコン参照を使用しないと、Content Trackerではこのようなリクエストを記録してカウントできません。
Webビーコンを使用すると、クライアント側では、Oracle WebCenter Content Server内の管理対象ビーコン・オブジェクトへの目にみえない参照として埋込み参照を使用できます。これにより、Content Trackerでは、Oracle WebCenter Content Serverからコンテンツを直接取得せずに、再配布のために外部エンティティによってコピーされた管理対象コンテンツ・アイテムに対するユーザー・アクセス・リクエストを記録してカウントできます。これが使用されるような状況の詳細は、第14.5.1項「Webビーコンのユースケース」を参照してください。
キャッシュされたコンテンツがコンシューマに提供されると、ユーザーは、リクエストされたオブジェクトがOracle WebCenter Content Serverで提供されていたことを認識します。管理対象コンテンツは実際には、動的ではないコンテンツ配信方法を使用して提供されます。この状況では、管理対象コンテンツは静的Webサイト、リバース・プロキシ・サーバーまたはファイル・システム外から対応されます。Webビーコン機能によって、このタイプのアクティビティが確実に追跡されます。
特に、Webビーコン機能を使用するだけの価値があると思われる状況は、リバース・プロキシ・アクティビティとSite Studio使用の2つです。
リバース・プロキシ・シナリオでは、リバース・プロキシ・サーバーは、ユーザーとOracle WebCenter Content Serverの間に位置します。リバース・プロキシ・サーバーはリクエストされたオブジェクトのコピーを作成することにより、管理対象コンテンツ・アイテムをキャッシュします。別のユーザーが次回にドキュメントを要求すると、プライベート・キャッシュ内のコピーが表示されます。リバース・プロキシ・サーバーのキャッシュ内にオブジェクトが存在しない場合は、コピーがリクエストされます。
リバース・プロキシ・サーバーはキャッシュされたコンテンツを配信するため、Oracle WebCenter Content Serverと直接相互作用することはありません。したがって、Content Trackerではこれらのリクエストを検出できないため、このユーザー・アクセス・アクティビティを追跡できません。
リバース・プロキシ・サーバーは、キャッシュしたり、ファイアウォールの内側にあるアプリケーションやサイトへのWebアクセスを管理することによって、Webパフォーマンスを向上させるために使用されることがよくあります。そのような構成では、頻繁にアクセスされるコンテンツのコピーをWebサーバーに移動し、そこでスケジュールに基づいて構成を更新することによってロード・バランシングが実現します。
Webビーコン機能を有効にするために、各ユーザー・アクセスには、Oracle WebCenter Content Serverに存在する管理対象ビーコン・オブジェクトへの追加のリクエストが含まれています。これによって通常のリクエストよりもオーバーヘッドが増加しますが、Webビーコン・オブジェクトは非常に小さいため、リバース・プロキシ・サーバーのパフォーマンスに大きな影響を与えることはありません。必要なのが、特に追跡するオブジェクトにWebビーコン参照を埋め込む操作のみであることに注意してください。
別の使用例として、Oracle WebCenter Content Serverで格納および管理されるWebサイトの作成に使用されるSite Studioをあげることができます。Site StudioとOracle WebCenter 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ページがOracle WebCenter Content Serverで管理されている場合です。 もう1つは、Webビーコン機能を使用して、Content TrackerがSite Studioを他のWebサイト・ジェネレータと同様に扱う形式です。通常、これが使用されるのは、Webサイトが本番モードで、コンテンツがOracle WebCenter Content Serverで管理されなくなった場合です。 |
Webサイトが外部対象者向けの場合は、サイトのコピーを作成して、別のサーバーに転送できます。このソリューションでは、サイトをパブリックに表示すること以外に、開発サイトと本番サイトを別々にすることも可能です。ただし、この配置の場合は、Webビーコン機能を実装して、Content Trackerでユーザー・アクティビティを収集および処理できるようにします。
Content Trackerでは、Oracle WebCenter Content Serverで管理されているオブジェクトに対するリクエストが記録されカウントされます。Webビーコン機能を使用すると、外部エンティティ(リバース・プロキシ・サーバーや、Oracle WebCenter Content Serverに関与しない他の機能など)でコピーされた管理対象オブジェクトに対するリクエストがカウントされます。
次のリストでは、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ページや管理対象コンテンツ・アイテム)に対するリクエストとしてログに記録されるように処理されます。
1つ以上のコンテンツ・アイテムを作成して、Webビーコン・オブジェクトとして使用する必要があります。これらは通常、縦横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ビーコン・プリファレンス設定を変更するインスタンスの名前をクリックします。
「コンテンツ管理サーバー instance_name」ページが開きます。
「コンポーネント・マネージャ」をクリックします。
コンポーネント・マネージャ・ページが表示されます。
「コンポーネント構成の更新」フィールドで、リストから「Content Tracker」を選択します。
「更新」をクリックします。
コンポーネント構成の更新ページが表示されます。
SctWebBeaconIDListプリファレンス・フィールドに、適用可能なWebビーコン・オブジェクトのdDocNameをカンマで区切って入力します。
「更新」をクリックします。
Oracle WebCenter Content Serverを再起動して変更を適用します。
Webビーコン・オブジェクトを作成してチェックインした後で、対応する参照を作成します。異なる問合せ文字列がWebビーコンの静的URLに付加されることによって各参照が一意になるため、ほとんどのシステムでWebビーコン・オブジェクトは1つで十分です。また、各問合せパラメータ・セットは、キャッシュされた特定のWebページまたは管理対象コンテンツ・アイテムを識別する変数の個別の組合せで構成されます。
WebビーコンURL参照は、Oracle WebCenter Content Serverで管理されるWebビーコン・オブジェクトへのアクセスに使用するWebビーコン静的URL、およびコンテンツ・アイテム変数を指定した擬似問合せ文字列で構成されます。
参照を作成するときは、Oracle WebCenter Content Server内のWebビーコン静的URLに、SctIgnoreDirectories構成変数に含まれるディレクトリ・ルートが使用されていないことを確認してください。URLが、リストされている値のいずれかである場合は、Content Trackerではアクティビティ・データが収集されません。SctIgnoreDirectories構成変数の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content構成リファレンス』を参照してください。
問合せパラメータ・セットは、ユーザーがアクセスした実際の管理対象コンテンツ・アイテムを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ビーコン・オブジェクトのコピーをOracle WebCenter Content Serverからリクエストする必要があります。
ユーザーが関連するコンテンツ・アイテムを間接的にリクエストするため、Webビーコン・リクエストが発生します。
例14-1 問合せパラメータを使用しないWebビーコン・リクエスト
http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt
これは、Webビーコン・オブジェクトへの静的Web参照から始まります。これはWebビーコン・オブジェクトへの正当な直接アクセスですが、問合せパラメータは追加されていません。Content Trackerでは、このアクセス・イベントをWebビーコン・オブジェクト自体に対するリクエストとして処理します。
例14-2 doc1を追跡するためのWebビーコン・リクエスト
http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=doc1&sct_dID=1234&...
これも、このビーコン・オブジェクトへの通常の静的Web参照から始まります。これには任意の数の問合せパラメータを含む擬似問合せ文字列が追加されています。これらの問合せパラメータに含まれる値によって、ユーザーがリクエストした特定の管理対象オブジェクト(doc1)に関する情報が通知されます。
例14-3 doc2を追跡するためのWebビーコン・リクエスト
http://myhost.somewhere.else/idc/groups/public/documents/adacct/bcn_2.txt?sct_dDocName=doc2&sct_Ext_2=WebSite4
これは、例14-4に似ています。パラメータ値によって、ユーザーがリクエストしたコンテンツ・アイテム(doc2)に関する情報が提供されます。この例では、問合せ文字列に、タグ付きアイテムに関する追加情報を通知するための別のパラメータが含まれています。追加されたパラメータではextField列名が使用されます。値WebSite4はSctAccessLog表のextField_2列にコピーされます。extField列の置換はオプションで、アプリケーションに依存しています。
例14-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列名を追加することによって、例14-3を変更します。この場合、WebSite4はSctAccessLog表のextField_2列にコピーされ、SubscriptionClass6はextField_8列にコピーされます。extField列の置換はオプションで、アプリケーションに依存しています。
追跡する管理対象オブジェクトに、特別に作成されたWebビーコン参照を埋め込む必要があります。Webビーコン参照はHTMLページに埋め込むことができます。ユーザーは、変更された管理対象コンテンツ・アイテムへのアクセスを、外部のSite Studio Webサイトまたはリバース・プロキシ・サーバーを介して、間接的にリクエストします。
ブラウザでは、ページのレンダリング中にWebビーコン参照を検出します。管理対象オブジェクトを表示するたびに、オブジェクトの取得方法に関係なく、ブラウザではWebビーコン・オブジェクトのコピーをOracle WebCenter Content Serverから直接リクエストします。ブラウザがWebビーコン参照を解決すると、Content Trackerでは、Webビーコン参照、および管理対象コンテンツ・アイテムを識別するための擬似問合せパラメータを含むデータを取得します。
データ削減中に、特別に作成されたWebビーコン参照が処理されると、Content Trackerでは、WebビーコンのdDoc Nameを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に直接コピーされます。
例14-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ビーコン機能を実装するには、次の手順を実行します。
Webビーコン・オブジェクトを作成します。
これをチェックインします。
SctWebBeaconIDListを更新します。
Webビーコン参照を定義します。
これらを、追跡対象になるキャッシュ済コンテンツ・アイテムまたはWebサイト(あるいはその両方)に埋め込みます。
1つの難点は、Webビーコン参照をタグ付きオブジェクトに添付する方法を決定することです。リクエストされたオブジェクトに参照を埋め込むことができない場合があります(PDF文書やWord文書など)。この場合は、実際のコンテンツ・アイテムがリクエストされる前に、Webビーコン・オブジェクトをOracle WebCenter Content Serverから直接リクエストする必要があります。
Webビーコン機能は、特定のブラウザ構成の場合など、多くの状況で動作しません。ユーザーがブラウザでクロスドメイン参照を無効にしていて、WebページとOracle WebCenter Content Serverのインスタンスが両方とも別々のドメインにある場合は、Webビーコン・オブジェクトはOracle WebCenter Content Serverからリクエストされず、ユーザー・アクセスはカウントされません。
リバース・プロキシ・サーバーを経由して最初に管理対象コンテンツ・アイテムにアクセスすると、Oracle WebCenter Content Serverがアイテムをリバース・プロキシ・サーバーに提供したときに1回、ブラウザがWebビーコン・オブジェクトをリクエストしたときに1回の計2回カウントされます。
特定の構成によっては、リバース・プロキシ・サーバーおよび外部のSite StudioがWebビーコン・オブジェクト自体をキャッシュしない方法を考案する必要があります。ブラウザでもキャッシュが行われます。この状況では、コンテンツ・サーバーは関連するコンテンツ・アクセスをカウントできません。これを回避するには、この例にあるように、乱数を含む1回かぎりの問合せパラメータをWebビーコン参照に追加します。
dDocName=vvvv_1_21&FoolTheProxyServer=12345654321
各リクエストの数値を変更することによって、キャッシュ、Webサーバーおよびブラウザは、リクエストを新規とみなします。
Webビーコン参照のsct_dDocNameおよびsct_dIDパラメータ値は、リクエストされたWebビーコン・オブジェクトを提供する同じOracle WebCenter Content Serverのインスタンス内で、実際の管理対象コンテンツ・アイテムに解決される必要があります。
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)の変更後に、Oracle WebCenter Content Serverを再起動します。
ファイル・タイプを使用するWebビーコン・オブジェクトを作成したり、Content Trackerで無視するように構成されているディレクトリ内にWebビーコン・オブジェクトを配置しないでください。
Content Trackerでは、キャッシュされたコンテンツ・アイテムが配信されたかどうかを確認できません。
Content Trackerでは、静的URLアクセスの通常の折りたたみ動作が実行されます。ユーザーが同じコンテンツ・アイテムを繰返しリクエストし、別のドキュメントに対するリクエストが途中で介入しない場合、Content Trackerでは連続するリクエストは同じドキュメントであるとみなされます。この場合、これらのアクセス・リクエストはすべて1つのアクセス・リクエストとみなされます。
問合せパラメータは任意の管理対象オブジェクトを表すことができ、必ずしもユーザーに実際に表示されている内容である必要はありません。
Webビーコン機能を実装するには、いくつかの埋込み方法を使用できます。各方法にはそれぞれ長所と短所があり、特定の状況に応じて最適な方法は異なります。システム構成には違いがあるため、最適な1つの方法があるわけではありません。
以降に示す例ではすべて、次の情報を使用しています。
WebBeacon.bmp Webビーコン・オブジェクト
Oracle WebCenter Content ServerのインスタンスIFHE.comcast.net/idc/
wb_bmpのdDocName
すべての例のコード・フラグメント・ファイルは、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関数が含まれています。これは、Oracle WebCenter Content Serverのインスタンス(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>
