|
|
イベントは、ユーザが Web インタフェースと対話したときに生成されます。イベントには、ログイン、グラフィックのクリックや表示、ボタンのクリック、ポータル内の別のページへの移動などがあります。
WebLogic Portal には、さまざまな方法でイベントを活用できるイベント フレームワークがあります。イベントが発生したときに、キャンペーンのトリガ、イベント データのデータベースへの保存、およびその他の機能を実行できます。
| 注意 : | 対話管理イベントは、ポートレット イベントとは異なります。ポートレット イベントは、ポートレット間通信のためのフレームワークを提供します。詳細については、『ポートレット開発ガイド』を参照してください。 |
イベント フレームワークにより提供できる機能の例を次に示します。
この章では、イベント フレームワークのコンポーネントについて説明します。フレームワークの各部分の目的と使い方、WebLogic Portal の定義済みイベント、およびアプリケーション内でのイベントの使用に関するガイダンスと手順の説明を参照して、イベントの使用方法を考慮してください。
各イベントは Event オブジェクトのインスタンスであり、ユニークな名前 (またはタイプ) によって識別されます。各イベント タイプは、その機能に応じて、特定の属性を取得および設定できます。上に挙げた例の場合、イベントが特定の情報を取り込む必要があります。たとえば、ユーザがポータル ページにアクセスする回数を取り込むために、ClickPage イベントがクリックされたページの名前を取得し、設定できます。コンテンツのどの部分が表示されたかを識別するために、DisplayContent イベントが表示された個々のコンテンツ項目の ID とタイプを取得し、設定できます。
イベントが各自の属性値を設定した後、それらの値を任意の方法で永続化できます。WebLogic Portal には、イベントの属性を XML としてデータベースに永続化するメカニズムがデフォルトで用意されています。イベント データがデータベースに保存されると、それらのデータを検索して分析したり、レポートを発行したり、アプリケーションにイベント データを供給したりできます。たとえば、データベースに対して SQL クエリを実行し、各ポータル ページの表示回数を返すポートレットを作成できます。独自の永続化機能を開発することもできます。たとえば、イベント データをファイルに保存したり、データを XML で構造化せずにデータベース テーブルに書き込んだりできます。
イベントが属性も永続化も必要としない場合があります。それらのイベントの唯一の目的は、何らかの別の機能をトリガすることです。たとえば、ダウンロード リンクについて、誰がクリックしたかに関係なく、何回クリックされたかを調べる場合は、ClickDownloadLink イベント (および付随するイベント リスナ) によってデータベース フィールドの値を 1 ずつインクリメントすることができます。
キャンペーン定義内でイベントを使用して、キャンペーンをさらに強力にすることもできます。たとえば、ユーザのポータルへの登録によって UserRegistration イベントが生成されたときに、定義済みの電子メールを自動的にユーザに送信したり、特定の属性値を持つイベントが生成されたときに、パーソナライズされたコンテンツを表示したりできます。
図 9-1 は、イベントをさまざまな方法で処理する柔軟性を提供するイベント フレームワークを示します。表 9-1 は、このフレームワークを部分ごとに説明しています。
Event または TrackingEvent クラスのいずれかを拡張するオブジェクトである。イベントは、イベント サービスに対してユニークな名前 (またはタイプ) を使用してそれ自身を識別させ、使用する属性を宣言し、イベント タイプと属性を基本クラス コンストラクタに渡す。
|
|
BT_EVENT テーブルに移動する。
|
|
wps.jar ファイルの listeners.properties ファイルに指定されている除外イベント以外のすべてのイベントをリスンして処理する。イベントが発生すると、キャンペーン イベント リスナは、キャンペーン サービスを呼び出す。キャンペーン サービスは、現在の HTTP リクエストのスナップショットを作成し、要求内のデータを作成済みのキャンペーンに突き合わせて評価し、キャンペーン アクションを実行する必要があるかどうかを確認する。
/data/src/events ディレクトリに格納される)。イベント プロパティ セットには、イベントに設定する属性の正確な名前を指定する。キャンペーン エディタ インタフェースは、このイベント プロパティ セットを、キャンペーン定義を作成するために使用するドロップダウン フィールドで使用する。
|
|
WebLogic Portal のイベント フレームワークには、前の節で説明したように、イベントを生成して処理するための複数のオプションが用意されています。イベント フレームワークのどの部分を実装する必要があるかを判断するには、「行動追跡方法の計画」のガイドラインを参照してください。
カスタム イベント、リスナ、およびイベント プロパティ セットの作成には、アプリケーションへのファイルの追加とアプリケーションの CLASSPATH の更新が関係します。デプロイ済みのアプリケーションにイベントとプロパティ セットを追加する場合は、アプリケーションを再デプロイメントしてイベントと CLASSPATH を更新し、BEA Propagation Utility を実行してデータベース内のイベント プロパティを更新する必要があります。デプロイメントの詳細については、『プロダクション業務ガイド』を参照してください。
その他のデプロイメントとプロダクション タスクについては、第 4 部の「プロダクション」を参照してください。
WebLogic Portal には事前定義された行動追跡イベントが用意されています。イベントが生成またはディスパッチされると、イベントは、異なる属性を取り込み、行動追跡リスナと行動追跡サービスを使用して、属性を XML として BT_EVENT テーブルに永続化します。イベント属性を永続化するには、行動追跡を有効にする必要があります (「行動追跡の有効化」を参照)。イベントを使用してキャンペーンをトリガすることもできます。
定義済みイベント AddToCartEvent、PurchaseCartEvent、および RemoveFromCartEvent は、従来の WebLogic Portal コマース アプリケーションと互換性があります。これらのイベントを新しいコマース アプリケーションでディスパッチする場合は、イベント プロパティ値の設定と取得を行うための独自のコードとコンテンツ管理プロパティを作成し、アプリケーション コードからこれらのイベントをディスパッチする必要があります (ページ フローや JSP などから)。
定義済みイベントがディスパッチされたときにカスタムイベント処理を実行する場合は、「カスタム イベント リスナの作成」の説明に従って、カスタム イベント リスナを作成します。
ユーザがポータルにログインした (認証された) ときにイベントをディスパッチするには、SessionLoginEvent を使用します。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
SessionBeginEvent と SessionEndEvent は自動的に生成されます。SessionBeginEvent は、WebLogic Portal で実行中の Web サイトにユーザがアクセスしたときに生成されます。SessionEndEvent は、ユーザがブラウザを閉じるかセッションがタイムアウトしたときのように、セッションが終了したときに生成されます。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
SessionBeginEvent と SessionEndEvent には、ポータル アプリケーションに対応するプロパティ セットがありません。デフォルトでは、キャンペーン リスナはこれらのイベントをリスンしないので、これらのイベントを使用してキャンペーンをトリガすることはできません。キャンペーンの開始の詳細については、「キャンペーンのトリガ」を参照してください。
ユーザがポータルに登録した (ユーザが登録ポートレットなどを使用してプログラム的にユーザ ストアに追加された) ときにイベントをディスパッチするには、UserRegistrationEvent を使用します。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値 (特にユーザ ID) がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
ユーザがショッピング カートに商品を追加したときにイベントをディスパッチするには、AddToCartEvent を使用します。このイベントを使用すると、通貨のタイプ、追加された商品の数量、単価、SKU などの情報を取り込むことができます。このイベントを使用するには、これらのプロパティを何らかの形でショッピング カートとコンテンツ タイプ内に表現する必要があります。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
RemoveFromCartEvent は、ユーザがショッピング カートから商品を削除したときに、イベントを送信します。このイベントを使用すると、通貨のタイプ、追加された商品の数量、単価、SKU などの情報を取り込むことができます。このイベントを使用するには、これらのプロパティを何らかの形でショッピング カートとコンテンツ タイプ内に表現する必要があります。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
PurchaseCartEvent は、ユーザが購入を実行したときに、イベントを送信します。このイベントを使用すると、通貨のタイプ、注文番号、購入金額の合計などの情報を取り込むことができます。このイベントを使用するには、これらのプロパティを何らかの形でショッピング カート内に表現する必要があります。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
WebLogic Portal には、Rules Executor コントロールを使用してページ フロー内でルールが適用されたときに常に行動追跡イベントを生成できるルール イベント コントロールが用意されています。ルール イベント コントロールは、必要なすべてのプロパティを取得します。プロパティには、ルール セットの名前と適用されたルールが含まれます。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
ルール イベントには、ポータル アプリケーション内に対応するプロパティ セットがありません。ルールのほうが柔軟性が高く強力なので、ルールは、しばしばキャンペーンの代わりに使用されます。したがって、ルールが適用されたときにキャンペーンをトリガするためにルール イベント プロパティ セットを作成するのは、現実的なシナリオではありません。それでもルールが適用されたときにキャンペーンをトリガするルール プロパティ セットを作成する場合は、RuleEvent.evt という名前のイベント プロパティ セットを作成し、ruleset-name と rule-name という制限のない単一の String プロパティを追加します。プロパティ セットの作成手順については、「プロパティ セットの作成」を参照してください。
ルールの使用の詳細については、「ルール イベント コントロール」と「ルールを使用した高度なパーソナライゼーションの作成」を参照してください。
DisplayCampaignEvent は、動作の追跡が有効である場合に、キャンペーンによってコンテンツ項目がプレースホルダに配置されたときに自動的に生成されます。イベント プロパティ値は、イベントが生成され、図 9-3 に示すように行動追跡サービスによって永続化イベントとして登録されたときに、データベースの BT_EVENT テーブルに書き込まれます。
<BehaviorTracking:displayContentEvent/> JSP タグで、コンテンツ表示イベント コントロールを使用すると、JSP 内のコンテンツの一部を表示したときに行動追跡イベントを生成できます。
document-id プロパティと document-type プロパティの取得方法については、表 9-2 を参照してください。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
コンテンツ表示イベントには、ポータル アプリケーション内に対応するプロパティ セットがありません。デフォルトでは、キャンペーン サービスはこれらのイベントをリスンしないので、これらのイベントを使用してキャンペーンをトリガすることはできません。詳細については、「キャンペーンのトリガ」を参照してください。
<productTracking:displayProductEvent> JSP タグを使用すると、カタログの商品を表示したときに行動追跡イベントを生成できます。
application-name、category-id、document-id、document-type、および SKU プロパティを取得する方法については、表 9-2 を参照してください。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
商品表示イベントには、ポータル アプリケーション内に対応するプロパティ セットがありません。デフォルトでは、キャンペーン サービスはこれらのイベントをリスンしないので、これらのイベントを使用してキャンペーンをトリガすることはできません。詳細については、「キャンペーンのトリガ」を参照してください。
CampaignUserActivityEvent は、汎用のキャンペーン イベントが発生したときに、イベントを送信します。このイベントは、新しい DisplayCampaignEvent を作成し、ユーザを特定のキャンペーンとシナリオ インスタンスに関連付けます。このイベントを使用するようにプロパティが設定されている必要があります。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
ClickCampaignEvent を ClickThroughEventFilter と共に使用すると、キャンペーンによって表示されたコンテンツ項目をユーザがクリックしたときにイベントが生成されます。
コンテンツのクリックを有効にするには、以下の手順を実行します。
web.xml ファイルと weblogic.xml ファイルに適切なエントリを入力します。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
ClickProductEvent を ClickThroughEventFilter と共に使用すると、製品コンテンツ項目をユーザがクリックしたときにイベントが生成されます。商品コンテンツ項目は、通常は、カタログまたはショッピング カート内の商品です。ClickProductEvent を使用して、商品カテゴリや SKU などの情報を取り込むことができます。このイベントを使用するには、これらのプロパティを何らかの形でコンテンツ タイプ内に表現する必要があります。
コンテンツのクリックを有効にするには、「コンテンツのクリックに対応したイベントの生成」の説明に従って、ポータル Web プロジェクトの web.xml ファイルと weblogic.xml ファイルに適切なエントリを入力します。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
ClickContentEvent を ClickThroughEventFilter と共に使用すると、キャンペーン以外の方法で仮想コンテンツ リポジトリから取得されたコンテンツ項目をユーザがクリックしたときにイベントが生成されます。
コンテンツのクリックに対応したイベントの生成を有効にするには、「コンテンツのクリックに対応したイベントの生成」の説明に従って、ポータル Web プロジェクトの web.xml ファイルと weblogic.xml ファイルに適切なエントリを入力します。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
WebLogic Portal には、ユーザがポータルのコンテンツ項目をクリックしたときに生成することが可能な定義済みイベントが用意されています。たとえば、コンテンツ クリック イベントは、<BehaviorTracking:clickContentEvent> と <productTracking:clickProductEvent> という JSP タグによって有効になります。ClickCampaignEvent も、コンテンツ クリック イベントを生成します。コンテンツがクリックされたときにイベント サービスにイベントがディスパッチされるようにするには、ClickThroughEventFilter を使用して、web.xml ファイルと weblogic.xml ファイルを EventService に追加し、キャンペーンのクリックスルーを有効にします。
URL で /ShowBinary パターンを使用するときは、常に ClickThroughEventFilter を使用します。ShowBinary (ShowPropertyServlet にマップされる) は、グラフィックなどのバイナリ Web コンテンツを表示します。/ShowBinary は、JSP のコンテンツ URL で使用します。ClickThroughEventFilter を /ShowBinary の URL パターンにマップした後、JSP で /ShowBinary をクリック イベント JSP タグと共に URL の一部として使用します。これで、ユーザがコンテンツをクリックしたときに、ClickThroughEventFilter によってコンテンツ クリック イベントが生成されます。
この機能を有効にするには、次のフィルタとフィルタ マッピングをポータル Web プロジェクトの web.xml ファイルに追加します。
<filter>
<filter-name>ClickThroughEventFilter</filter-name>
<filter-class>
com.bea.p13n.tracking.clickthrough.ClickThroughEventFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>ClickThroughEventFilter</filter-name>
<url-pattern>/ShowBinary/*</url-pattern>
</filter-mapping>
web.xml ファイルにフィルタ マッピングを追加していることを前提として、次の JSP コードは、ここには示されていないイテレータから取得した仮想コンテンツ リポジトリのコンテンツ項目を表示し、コンテンツ クリック イベントを生成するためのメカニズムを提供します。
<!-- JSP タグでコンテンツ項目の documentId を取得する。
documentId はイベント生成に必要なパラメータを
ClickThroughEventFilter に提供する。タグによって取得したデータを id 属性に
格納する。この JSP タグだけでは、イベントは生成されない。
<BehaviorTracking:clickContentEvent documentId="<%= node.getName() %>" id="eventInfo" /><!-- URL 変数で /ShowBinary を使用して、クリッカブルなリンクを提供する。
そのリンクは ClickThroughEventFilter にマップされている。ユーザがリンクをクリックしたとき、
eventInfo 変数によって、必要なイベント パラメータが
ClickThroughEventFilter に提供される。
<% String url = request.getContextPath() + "/ShowBinary"+node.getPath() + "?" + eventInfo;%><!-- これで、ユーザがリンクをクリックすると、ClickThroughEventFilter によって
ClickContentEvent が生成される。ShowBinary サーブレットにより、仮想コンテンツ リポジトリの
バイナリ形式のコンテンツ (グラフィックなど) を
表示する。
<a href="<%= url %>"><img src="<%=request.getContextPath() + "/ShowBinary" + node.getPath()%>" ></a>
定義済みの ClickCampaign Event をトリガするキャンペーンのクリックスルーの有効にするには、「コンテンツの設定」の説明に従って、特定のプロパティを持つコンテンツ項目をコンフィグレーションする必要があります。
その他の定義済みイベントは、仮想コンテンツ リポジトリまたはリポジトリ コンフィグレーションに加えられた変更を追跡します。イベントが生成またはディスパッチされると、イベントは、異なる属性を取り込み、行動追跡リスナと行動追跡サービスを使用して、属性を XML として BT_EVENT テーブルに永続化します。イベント属性を永続化するには、行動追跡を有効にする必要があります (「行動追跡の有効化」を参照)。
CampaignUserActivityEvent、ContentConfigEvent、ContentCreateEvent、ContentDeleteEvent、および ContentUpdateEvent イベントは、リポジトリの変更を追跡します。
定義済みイベントがディスパッチされたときにカスタムイベント処理を実行する場合は、「カスタム イベント リスナの作成」の説明に従って、カスタム イベント リスナを作成します。
ContentConfigEvent は、ユーザが仮想コンテンツ リポジトリのコンフィグレーションを変更したときに、新しいイベントを送信します。このイベントにより、リポジトリで実行されたアクションなどの情報を取り込むことができます。このイベントを使用するようにプロパティが設定されている必要があります。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
ContentCreateEvent は、ユーザが仮想コンテンツ リポジトリにコンテンツを追加したときに、イベントを送信します。このイベントにより、コンテンツ タイプ、新しいコンテンツが作成されたパス、コンテンツのステータスなどの情報を取り込むことができます。このイベントを使用するようにプロパティが設定されている必要があります。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
ContentDeleteEvent は、ユーザが仮想コンテンツ リポジトリからコンテンツを削除したときに、イベントを送信します。このイベントにより、コンテンツ タイプ、削除される前にコンテンツが存在したパス、コンテンツのステータスなどの情報を取り込むことができます。このイベントを使用するようにプロパティが設定されている必要があります。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
ContentDeleteEvent は、ユーザが仮想コンテンツ リポジトリのコンテンツを変更したときに、イベントを送信します。このイベントにより、コンテンツ タイプ、更新される前にコンテンツが存在したパス、コンテンツのステータスなどの情報を取り込むことができます。このイベントを使用するようにプロパティが設定されている必要があります。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは行動追跡サービスに永続化イベントとして登録されます。図 9-3 を参照してください。
WebLogic Portal の定義済みイベントでは、属性値の多くは自動的に設定されます。ただし、コード内に手動で設定する必要がある属性があります。
表 9-2 で、定義済みイベントに必要な属性について説明し、コード内に属性を設定するために使用できるメソッドを示します。 これらのメソッドを使用して、カスタム イベントに属性を設定することもできます。
一部の属性は、生成された他のイベントから取得できます。たとえば、キャンペーンによってコンテンツの一部が表示されたときは、常に DisplayCampaignEvent が生成されます。DisplayCampaignEvent は、placeholder-id とその他の属性を設定します。(その他の属性も設定します)。カスタム イベントのために placeholder-id を設定する場合は、そのイベントに対して getAttribute() メソッドを使用することで、DisplayCampaignEvent から属性を取得できます。例 : DisplayCampaignEvent.getAttribute( "aPlaceholderId" );
WebLogic Portal ドメインのデフォルトである PointBase データベース (および他のデータベース タイプのポータル データベースを構築するために使用される SQL スクリプト) には、行動追跡データを保存するために使用できる行動追跡テーブルが含まれています。ただし、行動追跡イベントを使用するには、行動追跡を手動でアクティブにする必要があります。
| 注意 : | この手順は、開発環境またはテスト環境で、展開されたアプリケーションを使用していることを前提とします。EAR ファイルのアプリケーションに対して行動追跡を有効にしても、コンフィグレーションはメモリのみに保存され、サーバを再起動したときに行動追跡は有効になりません。コンフィグレーションは META-INF/wps-config.xml ファイルに書き込む必要があるためです。このファイルは、EAR 内では読み込み専用です。 |
PointBase 以外のデータベースを使用している場合は、行動追跡イベント用の別個のデータベースの作成方法の詳細については、『データベース管理ガイド』を参照してください。
次の手順を実行して、BehaviorTrackingListener をイベント サービスに登録することで、行動追跡をアクティブにします。
com.bea.p13n.tracking.listeners.BehaviorTrackingListener| 注意 : | 同期リスナは、イベントを直ちに受信します。非同期リスナは、スレッド スケジューラを使用してイベントを受信します。 |
wps-config.xml ファイルが更新されます。図 9-2 に示すように、行動追跡がアクティブになります。サーバを再起動、またはアプリケーションを再デプロイする必要はありません。
デフォルトでは、行動追跡データは行動追跡イベントが発生した瞬間にデータベースに書き込まれるのではありません。イベントはバッファに格納されます。行動追跡データをバッファからデータベースに移動する頻度を決定できます。
次の手順を実行して、行動追跡データをデータベースに移動する頻度を決定します。
![[クラス名] フィールドでの新しいクラスの表示](wwimages/listener3.gif)
p13n.trackingDataSource) およびカスタム永続化クラス名 (null) はデフォルト値のままにします。これらのフィールドは、イベント データをバッファからデータベース内の BT_EVENT テーブルに移動するためのデフォルトの動作を指定します。他の永続化については、「他の方法での行動追跡データの保存」を参照してください。[永続化イベント タイプ] フィールドの詳細については、「行動追跡イベント クラスの作成」を参照してください。
行動追跡の設定を行う場合は、表 9-3 を使用します。
開発環境またはテスト環境で、[最大バッファ サイズ]、[バッファ スイープ間隔]、および [バッファ スイープ最長時間] に基準値を設定します。その後、値を変更しながら Web アプリケーションによるサイトのピーク時の使用量でテストを行い、データベース操作の回数と保存されるデータ量のバランスが最適になる値を見つけます。
| ヒント : | 行動追跡を使用しない場合は、イベント サービスを無効にする必要があります。「行動追跡の無効化」を参照してください。 |
デフォルトでは、行動追跡イベント データは BT_EVENT テーブルのデータベースに保存されます。イベント データを別の場所や別の方法で (別のデータベース テーブルやファイルに) 永続化する場合は、異なる永続化ロジックを提供するカスタム イベント リスナを作成します。カスタム リスナの作成については、「カスタム イベント リスナの作成」を参照してください。
行動追跡を使用している場合は、行動追跡データを別個のデータベースに保存することにより、パフォーマンスを向上させることができます。データベースのタイプごとに別個の行動追跡データベースを作成する方法の詳細については、『データベース管理ガイド』を参照してください。
必要な属性を取り込む WebLogic Portal の定義済みイベントがない場合は、独自のカスタム イベントを作成することができます。行動追跡イベントと標準イベントという 2 つのタイプのカスタム イベントを作成できます。
カスタム イベントと作成するタイプに関するガイダンスについては、「カスタム イベントの作成について」と「定義済みイベントを使用する場合について」を参照してください。カスタム イベントを作成するには、イベント クラスの作成と XML スキーマの作成が必要になります。
WebLogic Portal には、イベント サービスで動作する Event と TrackingEvent という基本イベント オブジェクトが用意されています。これらの基本クラスは、イベント サービスによって要求されるメソッドを提供します。
イベント クラスを作成するときは、いずれかの基本クラスを拡張し、必要なイベント属性を宣言し、イベント データ (イベント タイプなど) を基本クラス コンストラクタに渡します。
この節では、カスタム標準イベントとカスタム行動追跡イベントを作成するときの手順について説明します。
カスタム標準イベントは、WebLogic Portal の定義済みイベントに目的のイベント属性を取り込むイベントがなく、さらに行動追跡サービスを使用してイベント データを XML として BT_EVENT テーブルに永続化しない場合に作成します。カスタム イベント リスナを作成すると、カスタム標準イベントを使用してキャンペーンをトリガし、独自のイベント処理を実行できます。
この手順では、ユーティリティ プロジェクトを作成します。ユーティリティ プロジェクトでは、Web サービス、制御、EJB など、直接的に特別なエンティティの一部にはならない汎用的な Java コードを開発します。
| 注意 : | http://edocs.bea.com/wlp/docs81/interm/src/sample_events.zip ファイルのサンプル イベント クラス ResourceDisplayedEvent.java を参照することもできます。 |
この章で示す手順は、[パッケージ・エクスプローラ] ビューの \src フォルダに関係します。src ディレクトリは、名前が変更されている可能性があります。
カスタム イベント クラスを作成するには、以下の手順を実行します。
p13n-app-lib ライブラリ モジュールの CLASSPATH コンテナをプロジェクトに追加します。次の手順を実行します。
public static final String FOO_ATTRIBUTE = "fooAttribute";
public static final String SESSION_ID = "session-id";
public static final String USER_ID = "user-id";public MyEvent(
String fooAttributeValue,
String user_id,
HttpServletRequest request,
HttpSession session| 注意 : | イベントを使用してキャンペーンをトリガする場合は、ユーザのプロファイル名を含む user-id と呼ばれる文字列が必要です。タイプ com.bea.p13n.http.Request の request 属性も必要です。ただし、request 属性は、次のコードによって実行時に追加できます。event.setAttribute("request", new Request(request, true)); |
super( TYPE );setAttribute( FOO_ATTRIBUTE, fooAttributeValue );
setAttribute( SESSION_ID, session_id );
if( user_id != null )
setAttribute( USER_ID, user_id );
else
setAttribute( USER_ID, "unknown" );
ここで、fooAttributeValueはここには示されていないコードによって取得された値を格納する変数です。
カスタム イベントを作成するのは、WebLogic Portal の定義済みイベントに目的のイベント属性を取り込むイベントがなく、WebLogic Portal の行動追跡フレームワークを使用して、イベント データを XML として BT_EVENT テーブルに永続化するためです。
これらのイベントをキャンペーンで使用し、イベントに対して特殊な処理を行うカスタム リスナを作成できますが、行動追跡フレームワークを使用してイベント データを XML として保存するのでない限り、カスタム行動追跡イベントを作成する必要はありません。行動追跡サービスを使用しない場合は、「標準イベント クラスの作成」の説明に従って、カスタム標準イベントを作成します。
行動追跡イベントは独自の XML スキーマと連携して動作し、イベント データを XML として BT_EVENT データベース テーブルに保存します。次の手順に従って、スキーマに関する情報をイベント クラスに含める必要があります。
この手順では、ユーティリティ プロジェクトを作成します。ユーティリティ プロジェクトでは、Web サービス、制御、EJB など、直接的に特別なエンティティの一部にはならない汎用的な Java コードを開発します。
| 注意 : | http://edocs.bea.com/wlp/docs81/interm/src/sample_events.zip ファイルのサンプル イベント クラス ResourceDisplayedEventBT.java を参照することもできます。 |
この章で示す手順は、[パッケージ・エクスプローラ] ビューの \src フォルダに関係します。src ディレクトリは、名前が変更されている可能性があります。
動作追跡イベント クラスを作成するには、以下の手順を実行します。
p13n-app-lib ライブラリ モジュールの CLASSPATH コンテナをプロジェクトに追加します。次の手順を実行します。
XML_NAMESPACE キーを宣言します。これは、行動追跡イベントの XML スキーマをユニークに識別するために使用されるネームスペースの URL です。次に例を示す。private static final String XML_NAMESPACE = "http://www.yourdomain.com/myschemas/tracking/mytrackingschema";
private static final String XSD_FILE = "mytrackingschema.xsd";
TrackingEvent コンストラクタに渡されるキーとして宣言します。次に例を示す。public static final String SESSION_ID = "session-id";
public static final String USER_ID = "user-id";
public static final String PAGE_LABEL = "pageLabel";
TrackingEvent の基本コンストラクタに渡される String です。これらのキーを使用して、データベースに配置される行動追跡データを取得します。キーを、String オブジェクトの配列として表示します。private static final String localSchemaKeys[] =
{
SESSION_ID, USER_ID, PAGE_LABEL
};
localSchemaKeys の順序は、XML スキーマが XML を出力するために必要とするイベント プロパティの順序と対応していなければなりません。XML ファイルは、要素の順序が一致していない場合は無効になります。
SESSION_ID と USER_ID は、localSchemaKeys 配列のデータ要素であり、追跡イベントを実装する際に有用です。SESSION_ID (null 以外) は、すべてのセッション オブジェクトに対して作成される WebLogic Server のセッション ID です。USER_ID は、イベントをトリガしたユーザのユーザ名です。
public MyEvent(
String fooAttributeValue,
String user_id,
HttpServletRequest request,
HttpSession session| 注意 : | イベントを使用してキャンペーンをトリガする場合は、ユーザのプロファイル名を含む user-id と呼ばれる文字列が必要です。タイプ com.bea.p13n.http.Request の request 属性も必要です。ただし、request 属性は、次のコードによって実行時に追加できます。event.setAttribute("request", new Request(request, true)); |
TrackingEvent コンストラクタを呼び出し、必要な引数を必要な順序で渡します。次に例を示す。{super(
TYPE,
session,
XML_NAMESPACE,
XSD_FILE,
localSchemaKeys,
request );
setAttribute( PAGE_LABEL, pageLabelValue );
setAttribute( SESSION_ID, session_id );
if( user_id != null )
setAttribute( USER_ID, user_id );
else
setAttribute( USER_ID, "unknown" );
}
\src フォルダ内の Java ファイルは、通常の方法でコンパイルされ、アプリケーションの一部としてデプロイされます。「イベントのディスパッチ｣の説明に従って、JSP、Java コード、またはページ フローからイベントをディスパッチできます。キャンペーン定義で行動追跡イベントを使用する場合は、「キャンペーン用のイベントの登録」の説明に従って、イベントのイベント プロパティ セットを作成します。イベントが生成されたときにカスタム機能を実行する場合は、「カスタム イベント リスナの作成」の説明に従って、イベントをリスンするカスタム イベント リスナを作成します。
JSP 内でスクリプトレットを使用することにより、イベント クラスを記述せずにイベントを作成できます。このテクニックは、キャンペーンをトリガするために使用される行動追跡以外の単純なイベントに最も適しています。このテクニックを複雑なイベントで使用すると、JSP が混乱します。このテクニックは、イベント プロパティに値を提供できるフォームがある JSP で使用します。
スクリプトレットを使用してイベントを作成するには、次の手順に従います。
たとえば、fooAttribute と呼ばれる制限のない属性が 1 つだけ含まれる MyEvent.evt という名前のイベント プロパティを作成し、プロパティ セットファイルを JSP にドラッグした場合は、次のスクリプトレットが生成されます。
// ここに Event オブジェクトを生成する。
// イベント タイプ用のカスタム Event サブクラスがある場合は、
// 代わりにそれを使用するようにこのコードを変更する。
com.bea.p13n.events.Event event = new com.bea.p13n.events.Event("MyEvent");// fooProperty は String にする。
event.setAttribute("fooProperty", "");
// 次の属性はすべてのイベントで標準である。event.setAttribute("request", new com.bea.p13n.http.Request(request, true));event.setAttribute("user-id", com.bea.p13n.usermgmt.SessionHelper.getUserId(request));
// イベントを EventService にディスパッチする。com.bea.p13n.tracking.TrackingEventHelper.dispatchEvent(request, event);
%>
このスクリプトレットは、キャンペーンをトリガするために必要な request と user-id を取得し、イベントをディスパッチするためのコードです。ディスパッチ コードは行動追跡 API を使用しますが、標準イベントもディスパッチします。
フォーム フィールドの値などから、fooProperty に値を供給する必要があります。
イベントが生成されたときにカスタム機能を実行する場合は、「カスタム イベント リスナの作成」の説明に従って、イベントをリスンするカスタム イベント リスナを作成します。
デフォルトでは、行動追跡イベントのプロパティ値は XML としてデータベースに保存されます。イベント サービスは、行動追跡イベントのタイプごとに特定の XML スキーマを使用して XML を作成します。カスタム行動追跡イベントを作成するときは、行動追跡サービスが使用する XML スキーマも作成する必要があります。
カスタム行動追跡イベントの XML スキーマを作成するときは、スキーマとイベント クラス間の次の接続ポイントを考慮します。
XSD_FILE キーの値が、実際の XSD ファイルの名前と一致する必要があります。XSD_NAMESPACE キーの値が、XSD ファイルの targetNamespace 属性値と一致する必要があります。localSchemaKeys[] 配列にリストされている順序と一致する必要があります。
たとえば、イベント クラスに、次のスキーマ キー リストが含まれている場合、XSD ファイルにも、これらのプロパティが同じ順序でリストされている必要があります。
private static final String localSchemaKeys[] =
{
SESSION_ID, USER_ID, PAGE_LABEL_KEY
};
http://edocs.bea.com/wlp/docs81/interm/src/sample_events.zip ファイルのサンプル XSD ファイル ResourceDisplayedEventBT.xsd を参照することができます。
XSD を使用する場合は、targetNamespace と xmlns= 属性だけを目的のネームスペースに変更し、カスタム イベント属性に順に追加します。
weblogic81\p13n\lib\p13n_app.jar に定義されている WebLogic Portal 用の XSD を参照できます。
イベントにユーザが関係しない場合があります。このような場合は、XSD ファイルの user-id 属性に対して minOccurs="0" を使用します。次に例を示す。
<xsd:element ref="user-id" minOccurs="0"/>
スキーマを作成した後、次の手順に従って、ポータル アプリケーションの p13n_app.jar ファイルに追加します。
p13n_app.jar ファイルをコピーしてバックアップを作成し、p13n_ejb.orig などの名前を付けます。lib/schema/ ディレクトリに <yourschema>.xsd ファイルを一時的に追加します。p13n_app.jar ファイルにスキーマを追加します。環境に JAR ユーティリティがあるコマンド ウィンドウで、アプリケーション ディレクトリに切り替え、次のコマンドを実行します。jar uvf p13n_app.jar lib\schema\<yourschema>.xsd
p13n_app.jar ファイルを再デプロイします。
イベント リスナの目的は 1 つしかありません。それは、リスンしているイベントが発生したときに、何らかのプログラム機能を実行することです。WebLogic Portal には、イベントを特別な方法で処理する次の 2 つのリスナが用意されています。
wps.jar の listeners.properties ファイルで無視するように設定されたイベントを除く) をリスンし、キャンペーン サービスを呼び出して評価を行い、キャンペーン アクションをトリガします。BT_EVENT データベース テーブルに移されます (行動追跡リスナを有効にするには、「行動追跡の有効化」の説明に従って、行動追跡リスナを手動で登録する必要があります)。たとえば、SessionLoginEvent、SessionBeginEvent、および SessionEndEvent をリスンするカスタム イベント リスナを作成する場合があります。これらのイベントの [user-id] フィールドをログインしているユーザの記録を保存するリストに追加できます。
カスタム行動追跡イベントを作成して登録した場合、そのイベントは BehaviorTrackingListener と CampaignEventListener によって処理されます。カスタム標準イベントを作成した場合、そのイベントは CampaignEventListener によって処理されます。
ただし、イベントのタイプがカスタム イベントか WebLogic Portal の定義済みイベントかにかかわらず、イベントが発生したときに、よりプログラム的な機能を実行したい場合があります。たとえば、イベント データをファイルや別のデータベース テーブルに永続化したり、ユーザが商品イメージをクリックしたときに関連情報を表示したり、ユーザがフォームを送信したときにユーザのプロファイルを変更したりする場合です。このようなタイプの機能を追加するには、カスタム イベント リスナを作成する必要があります。
WebLogic Portal には、EventListener と呼ばれる基本イベント リスナ オブジェクトが用意されています。カスタム リスナで実装する必要があるこの基本クラスは、イベントをリスンし、それに対応するために次の 2 つのメソッドを提供します。
カスタム イベント リスナを作成する手順では、ユーティリティ プロジェクトを作成します。ユーティリティ プロジェクトでは、Web サービス、制御、EJB など、直接的に特別なエンティティの一部にはならない汎用的な Java コードを開発します。
| 注意 : | http://edocs.bea.com/wlp/docs81/interm/src/sample_events.zip ファイルのサンプル イベント リスナ customEventListener.java を参照することもできます。 |
この章で示す手順は、[パッケージ・エクスプローラ] ビューの \src フォルダに関係します。src ディレクトリは、名前が変更されている可能性があります。
標準イベントまたは行動追跡イベントのカスタム イベント リスナを作成するには、以下の手順を実行します。
p13n-app-lib ライブラリ モジュールの CLASSPATH コンテナをプロジェクトに追加します。次の手順を実行します。EventListener を実装します。次に例を示す。
public class MyEventListener
implements EventListener
{
private String[] eventTypes = {"MyEvent, ClickContentEvent"};
public String[] getTypes()
{
return eventTypes;
}
handleEvent() メソッドをオーバーライドして、リスンすべきイベントが発生したときにリスナが実行するプログラム機能を用意します。
public void handleEvent( Event ev )
{
//ここにカスタム コードを入力する。
//イベントが発生すると、このコードが実行される。
}
}
\src フォルダ内の Java ファイルは、通常の方法でコンパイルされ、アプリケーションの一部としてデプロイされます。「イベントのディスパッチ｣の説明に従って、JSP、Java コード、またはページ フローからイベント リスナをディスパッチできます。キャンペーン定義でイベント リスナを使用する場合は、「キャンペーン用のイベントの登録」の説明に従って、イベントのイベント プロパティ セットを作成します。com.bea.p13n.events.custom.listeners.MyEventListener
| 注意 : | 同期リスナは、イベントを直ちに受信します。非同期リスナは、スレッド スケジューラを使用してイベントを受信します。 |
イベントとリスナの準備ができたら、JSP、Java コード、およびページ フロー内でイベントをディスパッチできます。イベントのディスパッチとは、イベント オブジェクトがイベント サービスからイベントをリスンしているリスナに送信されることです。イベント オブジェクトを受信したリスナは、独自の方法でイベントを処理します。
http://edocs.bea.com/wlp/docs81/interm/src/sample_events.zip に用意されているサンプル イベントでは、ResourceDisplayedEventBT というサンプル イベント ファイルが 2 つのポータル フレームワーク スケルトン JSP ファイル book.jsp と page.jsp からディスパッチされます。book.jsp スケルトンは、ポータル ブックの表示とページのナビゲーション (タブなど) を処理し、page.jsp スケルトンは、ポートレットが表示される領域を提供します。
コード リスト 9-1 に示すコードは、book.jsp および page.jsp ファイルに挿入されます。このサンプルでは、page.jsp ファイルのコードを使用しています。このコードは、ポートレットがページに表示されたときに ResourceDisplayEventBT イベントをディスパッチします。
<%@ page import="com.bea.p13n.tracking.TrackingEventHelper,
examples.events.ResourceDisplayedEventBT" %>
...
ResourceDisplayedEventBT rde;
...
ResourceDisplayedEvent rde = new ResourceDisplayedEvent(
ppc.getLabel(),
portletTitle,
"portlet",
sessionID,
userId,
"true", // ポートレットを表示する
request,
session );
// 9.2 のイベントをディスパッチする新しいメカニズム:
EventService es = TrackingEventHelper.getEventService();
TrackingEventHelper.dispatchEvent(es, rde);
...
イベントは、そのイベントを受信するように登録されたリスナに送信され、リスナがイベントを独自の方法で処理します。図 9-1 に、イベントのライフサイクルを示します。スケルトン JSP は、この図の項目 2 に該当します。
「スクリプトレットを使用したイベントの作成」では、イベント クラスを作成していないイベントをディスパッチする方法についても説明しています。コンテンツがクリックされたときにイベントをディスパッチする場合は、「コンテンツのクリックに対応したイベントの生成」で説明している特別な手順に従う必要があります。定義済みイベントの一部には、独自のディスパッチ メソッドがあります。「事前定義されたイベントの使用」を参照してください。
イベントを使用してキャンペーン サービスをアクティブ化し、イベントとイベントの属性値に基づいてキャンペーン アクションをトリガすると、より強力なキャンペーンを実装できます。
キャンペーンでイベントを使用する場合、キャンペーン サービスに対してイベントを明示的に通知する必要はありません。キャンペーン リスナは、wps.jar ファイルの listeners.properties ファイルで明示的に除外されたイベント以外のすべてのイベントをリスンします。
キャンペーン リスナがリスンしているイベントが発生した場合、リスナはキャンペーン サービスを呼び出します。キャンペーン サービスは、現在の要求のスナップショットを作成し、ユーザが定義したすべてのキャンペーン ルールに照らして要求データを評価し、アクションを実行する必要があるかどうかを確認します。
さらに、別の方法でイベントをキャンペーンに使用できます。キャンペーン アクションの一部として使用する方法です。たとえば、ユーザがポータルでホーム ページをクリックしたときにのみパーソナライズされたコンテンツを表示するキャンペーン アクション (何らかのページ クリック イベントによってトリガされる) を定義できます。イベントをキャンペーン定義の一部として使用するには、「キャンペーン用のイベントの登録」の説明に従って、イベント プロパティ セットを作成する必要があります。
図 9-12 に、キャンペーン定義でのイベントの使用例を示します。この例では、イベントが特定のプロパティ値 (特性) を持つ場合に、キャンペーン シナリオがトリガされます。キャンペーン シナリオに [イベントが特定の特性を備えている] を追加し、キャンペーン エディタで [特性] リンクをクリックすることで、イベント プロパティを選択し、キャンペーン アクションの発生をトリガするプロパティ値を決定できます。作成されたイベント プロパティ セットによって、プロパティの選択が可能になります。
キャンペーンを制御する場合、特に表示されるパーソナライズされたコンテンツを制御する場合は、アプリケーションの主要な場所にキャンペーン アクションをトリガするイベントを作成します。パーソナライズされたコンテンツの制御の詳細については、「パフォーマンスを最適化するためのプレースホルダの管理」を参照してください。キャンペーンの作成手順については、「キャンペーンの構築」を参照してください。
キャンペーンをトリガするカスタム イベントを使用する場合は、イベント プロパティ セットを作成する必要があります。イベントに対して作成するプロパティは、イベント クラスで定義した属性名と一致します。
たとえば、sample ResourceDisplayedEvent クラスは、resourceId、resourceLabel、resourceType、session-id、user-id、および resourceSelected プロパティを使用します。作成するイベント プロパティ セットには、これらの属性のいずれか、またはすべてのプロパティを定義できますが、プロパティ名はイベントの属性名と正確に一致している必要があります。
イベント プロパティ セットの作成手順については、「カスタム イベントの作成」を参照してください。イベント プロパティ セットの登録手順については、「行動追跡の有効化」を参照してください。
アプリケーションをデプロイした後にイベント プロパティ セットを作成、変更、または削除する場合は、BEA Propagation Utility を使用してデータベース内のプロパティ セット定義を更新する必要があります。詳細については、『プロダクション業務ガイド』を参照してください。
イベント サービスをデバッグし、コンソールの出力を確認することができます。
イベント サービスをデバッグするには、以下の手順を実行します。
weblogic81\portal\debug.properties ファイルを作成します。usePackageNames: on
com.bea.p13n.cache: on
# イベントのすべてのクラスのデバッグをオンにする
com.bea.p13n.events: on
# com.bea.p13n.events.internal.EventServiceBean: on
# すべてのクラスのデバッグをオンにする
# com.bea.p13n.tracking: on
com.bea.p13n.tracking.internal persistence: on
# クラスを選択的にオンにする
com.bea.p13n.mbeans.BehaviorTrackingListerner: on
com.bea.p13n.tracking.listeners.BehaviorTrackingListerner: on
com.bea.p13n.tracking.SessionEventListerner: on
| ヒント : | イベントは 9.2 にアップグレードされたコンテンツ リポジトリに対して発生します (イベント追跡をリポジトリ レベルでオフにしている場合を除く)。イベントは、リポジトリのコンテンツの追加、更新、および削除だけでなく、リポジトリ コンフィグレーションの変更に対しても発生する場合があります。アップグレードの実行の詳細については、『WebLogic Portal 9.2 へのアップグレード』を参照してください。 |
コンテンツ イベントを使用して、仮想コンテンツ リポジトリに対するコンテンツ変更やリポジトリのコンフィグレーションに対する変更を追跡することができます。コンテンツの変更には、コンテンツまたはコンテンツ プロパティを追加、更新、削除した担当者、およびリポジトリ内で変更が行われた日付と時刻が含まれます。リポジトリのコンフィグレーション、コンテンツ タイプ、またはコンテンツ ワークフローに対して変更を行った担当者 (変更した日付と時刻を含む) を追跡することもできます。これらのイベントの詳細については、「コンテンツ イベントの生成」を参照してください。
コンテンツの変更を監視し、アクションを実行するコンテンツ イベントをコンフィグレーションすることもできます。たとえば、ユーザがコンテンツ リポジトリに履歴書ドキュメントを追加すると、人事担当部長に電子メールが送信されます。
これらのコンテンツ イベントは、履歴追跡のために行動追跡データベースに保存されます。コンテンツ管理の詳細については、『コンテンツ管理ガイド』を参照してください。
com.bea.p13n.tracking.listeners.BehaviorTrackingListener」と入力します。図 9-13 を参照してください。
![[イベント タイプの追加] のクリック](wwimages/audittrail2.gif)
ContentCreateEvent を追加して、コンテンツ リポジトリに追加された新しいコンテンツ、追加した担当者、および追加した日付と時刻を判断できます。| ヒント : | コンテンツ リポジトリの変更の追跡を表示するために、行動追跡データベース テーブルに含まれるリポジトリ コンテンツの変更のログ ファイルを作成するか、またはリスナが特定のログ出力を表示できるようにすることができます。 |
行動追跡リスナの登録を解除し、または個別のイベントを削除することで、行動追跡イベントの永続性を無効にすることができます。
行動追跡リスナの登録を解除するには、以下の手順を実行します。
| 注意 : | イベントをトリガしてアプリケーションで起動できますが、データベース テーブルには保持されなくなります。 |
デフォルト イベントを削除するには、以下の手順を実行します。
  
|
![[削除] チェック ボックスの選択](wwimages/eventremove.gif)