| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Portal > 開発者ガイド > イベントおよび行動追跡 |
|
開発者ガイド
|
イベントおよび行動追跡
イベント システムを利用すれば、訪問者とポータルすなわち Web サイトとのやり取りを識別することができます。
顧客とのやり取り: イベントの主たる用途の 1 つには、プロモーションやキャンペーンなどでの顧客とのやり取りがあります。 たとえば、顧客がショッピング カートに商品を入れたときに関連商品の広告表示をトリガするといったことは、キャンペーンにおけるイベントの利用法の簡単な例です。
行動追跡: イベントの主たる用途には、もう 1 つ、イベントを記録することで訪問者の行動を追跡することが挙げられます。 イベントを記録すると言っても、単なるナビゲーション ロギングではありません。このようなロギングからは、どのようなページが訪問されたかがわかるだけです。 これに対して、行動追跡を利用すれば、訪問者がページ上で何に注目し何に反応したかがわかります。あるいは、これも同じく重要ですが、ページ上で訪問者が何に「注目しなかったか」もわかります。 データベースにイベントを記録することで、最先端の e 解析システムや e マーケティング システムでイベント データを用いてデータ マイニングを行うことができます。 イベント情報を分析すると、サイトのコンテンツを各訪問者に合わせてカスタマイズするルールを作成または機能拡張したり、プロモーション用キャンペーンの有効性を評価するのに役立ちます。
カスタム イベント: イベント システムを利用すれば、独自のイベントを作成することができます。 たとえば、各ポートレットへの訪問者とアクセス頻度を記録するイベントを作成することもできるでしょう。 カスタム イベントを作成する場合、そのイベントは WebLogic Portal の永続性メカニズムを用いてデータベースに記録することもできますし、そうしないことも可能です。 永続化されるイベントは行動追跡イベントと呼ばれます。 永続化されないカスタム イベントの場合には、カスタム イベント クラスを作成するでの説明に従ってください。 また、カスタム行動追跡イベントを作成する場合には、行動追跡イベント クラスを作成するでの説明に従ってください。
この章の内容は主として、J2EE に精通した人を対象にしています。 扱うトピックは以下のとおりです。
キャンペーンにおけるイベントの動作の仕組み
イベントは、商品の閲覧などの訪問者のアクションによって発生します。 Event サービスは、そのイベントを検出したことをすべてのイベント リスナに通知します。 Campaign サービスのイベント リスナはそれを受けて、キャンペーン シナリオをアクティブにします。 キャンペーンでは、ユーザに合ったコンテンツを選択する一連のルールを用いて、アクションを開始します。 利用可能なアクションは、以下のとおりです。
注意: キャンペーンの詳細については、E-Business Control Center のオンライン ヘルプを参照してください。
Event サービスの動作の仕組み
Event サービスの動作の仕組みを理解すれば、イベントを利用する上で役に立つとともに、イベントの生成とカスタム イベントの設計に必要な情報も得られます。
Event サービスの概要: Event サービスは、拡張可能な汎用のイベント作成および伝達システムです。 図 15-1 に示すように、イベントは JSP タグなどのトリガによって生成されます。 トリガはイベント オブジェクトを作成し、Event サービス Bean を見つけ、そして作成したイベント オブジェクトをその Event サービスに渡します。 Event サービスはプラグイン リスナと連携して動作し、そのプラグイン リスナによって、当該イベントの受信登録を済ませているリスナにイベントが伝達されます。 各イベント リスナは作成される際に、受信を希望するイベント タイプのリストを返します。Event サービスは、イベントを受信すると、そのイベントのタイプをチェックし、そのイベント タイプの受信をサブスクライブ（登録）しているすべてのリスナにそのイベントを送信します。
リスナ タイプ: Event サービスにプラグインされるリスナには、 イベントに同期的に応答するものと非同期的に応答するものの 2 種類があります。 同期型リスナでは、送られてきたイベントの作成および送信元の実行スレッドをそのまま用いて、そのイベントに応答するアクションを実行します。 行動追跡リスナは、同期型リスナだけを使用します。 一方、非同期型リスナでは、送られてきたイベントをその作成元のスレッドから受信し、その後いつか、別の実行スレッド内でイベントを処理します。 非同期型サービスが用意されているのは、イベント ハンドラの実行に時間がかかる場合でも、Web サイト訪問者の目から見てアプリケーションの動作に遅延が生じないようにするためです。
個々のプラグイン リスナを Event サービスの同期側にインストールするか、非同期側にインストールするかは、アプリケーションの要件によって決まります。 Event サービスのコンフィグレーションは、WebLogic Server Administration Console を用いて行われます。
図15-1 イベントのメカニズム
最初のメソッドは、リスナで Event サービスから受信する対象となるイベント タイプのリストを返します。 たとえば、リスナで Foo タイプのイベントを受信するようになっている場合には、そのリスナ オブジェクトに対する getTypes() メソッドの呼び出しで返される配列には、Foo が要素として含まれています。 2 番目のメソッドは、イベントがリスナに渡されたときに呼び出されます。 リスナには、自分が同期型であるか非同期型であるかはわかりません。
キャンペーン イベントだけを受信するリスナを作成するのであれば、WebLogic Server Administration Console で、そのリスナの完全修飾クラス名を追加します。 作成されたリスナは EventListener インタフェースを実装し、その getTypes() メソッドが呼び出されたときに以下のイベント タイプを返します。
{"ClickCampaignEvent","DisplayCampaignEvent","CampaignUserActivityEvent" }このリスナをインストールすると、これら 3 つのタイプのイベントが、リスナの handleEvent( Event theEvent ) インタフェースに伝達されます。
図 15-1 に描かれた「非同期配信」の部分では、Event サービスの同期側から非同期的に送られてくるイベントが非同期型イベント ハンドラで受信されることを示しています。 このイベント ハンドラはそのあと、各リスナでの受信対象として登録されているイベント タイプに基づいて、プラグイン可能非同期型リスナにイベントをディスパッチします。
イベント シーケンスの動作
一連のイベントが発生する様子（サンプル）を図 15-2 と 図 15-3 に示します。 これらの図は、イベントの発生順序を直感的に理解していただくためのもので、イベントの順序付けを包括的に扱ったものではありません。 これらを取り上げたのは、イベントによって Web サイトにおける訪問者のライフ サイクルについてどのような洞察が得られるのかということと、アプリケーションでイベントをいつどのように用いればよいかを示すためです。
図15-2 イベント シーケンスのサンプル（その 1）
標準イベントの使い方
この節では、WebLogic Portal にあらかじめ用意されている標準イベントの使い方について大まかに説明します。 各イベントの詳細については、イベント解説を参照してください。付録 A には、各種イベントの解説、イベントの生成元（ジェネレータ）、イベント生成が行われるクラス、使用例、および各イベント オブジェクト内のデータのタイプが記載されています。
WebLogic Portal の標準イベントにはすべて、以下の基本情報が記載されています。
WebLogic Portal イベントはいくつかのカテゴリに分類されます。 以下では、各タイプのイベント カテゴリと、イベントを発生させるアクションについての簡単な説明を示します。
サーブレット ライフサイクル イベントとサーブレット フィルタ イベント
以下のイベントは、サーブレット仕様 2.3 API のライフサイクル イベントの一部として定義されています。
これらはセッションの Created() イベントおよび Destroyed() イベントのリスナで、この 2 つのイベントは、web.xml ファイルに定義されているサーブレットによって生成されます。 web.xml ファイルは、アプリケーションごとに 1 つ存在します。 たとえば、wlcsApp という e コマース アプリケーションの場合には、このファイルは以下の場所にあります。
<BEA_HOME>¥weblogic700¥portal¥applications¥wlcsApp¥wlcs¥WEB-INF
以下のイベントは JSP タグによって生成され、サーブレット仕様 2.3 の <filter> 要素によってフィルタ処理されます。
表示される Web ページごとに、Web アプリケーション サーブレットは HttpServletRequest 内にクリック イベントが存在するかどうかをチェックします。 各ページ クリックはそのあと、サーブレット仕様 2.3 の <filter> 要素で定義されているとおりに、Web アプリケーション サーブレットによってフィルタ処理されます。 クリック イベントは、サーブレットの呼び出しのたびに、<filter> 要素が呼び出されると自動的に生成されます。 生成されるイベントのタイプの決定は、ClickThroughFilter によって HttpServletRequest 内のイベント タイプをチェックすることで行われます。 有効なタイプは、以下のファイルに定義されています。
ログイン イベントと作成イベントを生成する
この節では、ログイン イベントおよびユーザ登録イベントを生成するいくつかの異なる方法について説明します。
SessionLoginEvent: SessionLoginEvent は、以下のいずれかの方法で生成することができます。
UserRegistrationEvent: UserRegistrationEvent の生成には、com.bea.p13n.tracking.TrackingEventHelper.dispatchUserRegistrationEvent() メソッドを使用します。 このイベントは、SessionLoginEvent（ユーザ作成中に発生するはず）のあとで生成しなければなりません。 入力プロセッサを使用してもよいし、JSP に記述してもかまいません。
Webflow: ポータル Webflow フレームワークを使用する場合には、SessionLoginEvent と UserRegistrationEvent は、必要に応じてセキュリティ Webflow 内の com.bea.portal.appflow.processor.security.PostLoginProcessor から自動生成されます。
イベント ジェネレータを追加またはカスタマイズする
標準イベントは、e コマース サイトにおける重要な局面で生成されます。 イベントを発生させるコンポーネントには、Java API、JSP タグ、JSP スクリプトレット、Webflow 入力プロセッサ、Pipeline コンポーネント、コンテンツ セレクタ、分類アドバイズレットなどがあります。 以下の各イベントについては、ジェネレータ（生成元）の追加またはカスタマイズが可能です。
これらの各イベントは JSP タグによって生成されます。 これらのイベントをトリガする JSP タグを用いて、どの商品やどのようなコンテンツによってこれらのイベントが生成されるかを指定することができます。 たとえば、wlcsApp という e コマース アプリケーションでは、DisplayProductEvent に対応する JSP タグが details.jsp に記述されています。
このタグ（リスト 15-1 に示す）では、カタログの詳細ページに商品が表示されると、それに対応するイベントを生成します。 ある特定の商品に対してイベントを生成したい場合には、その商品の SKU を手がかりに選択的処理を行うスクリプトレットを書くことができます。
コード リスト 15-1 JSP タグ
<%-- 商品が表示されたら、displayProductEvent を発生させる --%>
<productTracking:displayProductEvent documentId="<%= item.getName() %>"
documentType="<%= DisplayProductEvent.ITEM_BROWSE %>"
sku="<%= item.getKey().getIdentifier() %>" />
イベント用の JSP タグを追加する際には、以下のような、タグ ライブラリ記述子への参照をコードに挿入しなければなりません。
<%@ taglib uri="productTracking.tld" prefix="productTracking" %>
details.jsp は以下のディレクトリに入っています。
<BEA_HOME>¥weblogic700¥portal¥applications¥wlcsApp¥wlcs¥commerce¥catalog
カスタム イベントの作成
この節では、カスタム イベントの作成に必要な情報を提供します。 任意の追跡対象についてのカスタム イベントを作成することができます。 WebLogic Portal の永続性メカニズムを用いてイベントを記録させる場合には、行動追跡イベント クラスを作成するで説明しているように、行動追跡イベントを作成します。
カスタム イベントのアイデア: 顧客ごとにどのページが表示されているかを知らせるイベントを作成することもできます。 その場合には、その情報を用いて、セッションごとに閲覧された平均ページ数や最も人気があったページを決定することができます。 さらに、マーケティング担当者は、特定ページの表示に基づいたプロモーション用キャンペーンを開発する際にこのイベントを利用することもできます。
カスタム イベントの作成方法を説明するために、ここでは簡単な例を示します。 以下の各節では、この例を参照し、拡張します。
カスタム イベントの作成は、複数のステップから成るプロセスです。 以下のリストでは、このプロセスの概要と、ここで扱われない情報の参照先を示します。
カスタム イベント クラスを作成する
カスタム イベントを作成するには、以下の手順に従います。
すべてのカスタム イベントは、com.bea.p13n.events.Event クラスのサブクラスでなければなりません。 この基本クラスでは、イベントのタイムスタンプとタイプの設定および取得を処理し、カスタム イベントの属性にアクセスする手段を提供します。 Event クラスには、属性値を設定および取得する以下の 2 つのメソッドがあります。
setAttribute( String theKey, Serializable theValue )
getAttribute( String theKey )
カスタム イベントのコンストラクタからこれらのメソッドを呼び出して、新しいイベントに固有の属性を設定することができます。 なお、Event オブジェクト内に値として設定されるすべてのオブジェクトは、Java のシリアライズ可能なデータ型でなければならないことを覚えておいてください。
getTimeStamp() メソッドは、イベントの作成日時をミリ秒単位で返します。 イベントのタイプには、Event クラスの getType() メソッドを用いてアクセスします。 Event オブジェクト インスタンスのタイムスタンプとタイプの設定は、インスタンスの作成時に Event コンストラクタ内でのみ行うことができます。 イベントのタイムスタンプは、明示的に指定されない場合には、イベントの作成時に自動的に設定されます。 アプリケーション属性は、イベントの作成元のアプリケーションか Event サービス EJB (Enterprise JavaBean) アプリケーションのいずれかから自動的に設定されます。
例: カスタム イベントの作成プロセスの例を示すために、ここでは TestEvent という簡単な例を取り上げます。 この例は、イベント サブクラスの基本的な作成方法を示すものです。 実際のカスタム イベントは、おそらくこれよりも複雑でしょう。
/** イベント タイプ */
public static final String TYPE = "TestEvent";
/**
* 1 つ目のユーザ定義プロパティのイベント属性キーの名前。
* 属性値は String
*/
public static final String DESCRIPTION = "description";
/**
* 属性値はすべてシリアライズ可能でなければならないことに注意。
* 2 つ目のユーザ定義プロパティのイベント属性キーの名前。
* 属性値は Integer
*/
public static final String ZIP_CODE = "Zip Code";
最後に、イベント タイプと属性の設定に関する処理をコンストラクタにまとめ、そのコンストラクタでイベント オブジェクトを作成します。 コンストラクタは以下のようになります。
/**
* 新しい TestEvent を作成する
*
*
* @param desc このイベントの説明
* @param zip 郵便番号
*/
public TestEvent( String desc, Integer zip )
{
/* このイベントのタイプを指定して Event クラスのコンストラクタを呼び出す */
super( TYPE );
if( desc != null )
setAttribute( DESCRIPTION, desc );
if( zip != null )
setAttribute( ZIP_CODE, zip );
}
断片をすべて 1 つにまとめる: カスタム イベント クラス全体をリスト 15-2 に示します。
コード リスト 15-2 TestEvent クラス
/*TestEvent クラスの定義はここから */
public class TestEvent
extends com.bea.p13n.events.Event
{
/** イベント タイプ */
public static final String TYPE = "TestEvent";
/**
* 1 つ目のユーザ定義プロパティのイベント属性キーの名前。
* 属性値は String
*/
public static final String DESCRIPTION = "description";
/**
* 2 つ目のユーザ定義プロパティのイベント属性キーの名前。
* 属性値は Integer
*/
public static final String ZIP_CODE = "Zip Code";
/**
* 新しい TestEvent を作成する
*
*
* @param desc このイベントの説明
* @param zip 郵便番号
*/
public TestEvent( String desc, Integer zip )
{
/* このイベントのタイプを指定して Event クラスのコンストラクタを呼び出す
super( TYPE );
if( descriptionValue != null )
setAttribute( DESCRIPTION, desc );
if( ZipCodeValue != null )
setAttribute( ZIP_CODE, zip );
}
}
/*TestEvent クラスの定義はここまで */
サンプルについての補足: リスト 15-2 の例では、基本クラス Event と Event サービスの基本機能の使い方を示しています。 実際のカスタム イベントのコンストラクタは、おそらくこれよりも複雑でしょう。 たとえば、コンストラクタでデフォルト値のチェックを行ったり、null 属性を排除するなどの処理を行うかもしれません。 さらに、カスタム イベント オブジェクトに、もっと多くのメソッドやメンバー データが含まれる場合もあるでしょう。
注意: カスタム イベントをキャンペーンで使用するには、以下のオブジェクトを属性として追加する必要があります。
ファイルを保存する: WebLogic Server で使用されるエンタープライズ アプリケーション クラスパスに含まれている場所であれば、どこにファイルを保存してもかまいません。
カスタム イベント リスナを作成する
イベントをリスンするには、イベント リスナを定義する必要があります。 すべてのイベント リスナは com.bea.p13n.events.EventListener インタフェースを実装し、引数のないコンストラクタ（デフォルト コンストラクタ）を持つ必要があります。 このインタフェースには、指定されたタイプのイベントを、配信先として登録済みのリスナに送信するのに不可欠な 2 つのメソッドの仕様が、以下のとおり定義されています。
public String[] getTypes()
public void handleEvent( Event ev )
最初のメソッドは、リスナで受信されるイベントのタイプを文字列配列で返します。 Event サービスは、与えられたタイプのイベントを受信対象とする（上記のタイプ配列に含まれる）リスナに、そのイベントをディスパッチします。 特定のリスナが現在のイベント タイプを受信対象として登録済みであると Event サービスが判断すると、そのタイプのイベントは、handleEvent( Event ev ) の呼び出しを用いて、そのリスナにディスパッチされます。
イベント リスナの両メソッドを実装する: カスタム イベント リスナを作成する際には、EventListener インタフェースに定義されている 2 つのメソッドを両方とも実装する必要があります。 引き続き TestEvent の例を取り上げると、Event サービスを通じて送信される TestEvent インスタンスは、TestEventListener でリスンされます。 これは、以下のように記述することができます。
/** このリスナで受信するイベントのタイプ */
private String[] eventTypes = {"TestEvent"};
/**
このリスナに伝達するイベントのタイプを決定するために
Event サービスによって呼び出されるメソッド。
*/
public String[] getTypes()
{
return eventTypes;
}
受信したイベントを処理するには、handleEvent( Event evt ) メソッドを以下のように実装します。
/**
* Event サービスから送られたイベントを処理する
*/
public void handleEvent( Event ev )
{
System.out.println("TestListener::handleEvent " +
" -> received an event" +
" of type: " + ev.getType() );
/* ここで処理を行う */
}
これらの断片とコンストラクタをひとまとめにすると、リスト 15-3 に示すように、TestEvent オブジェクトの受信を登録する簡単なイベント リスナができあがります。
コード リスト 15-3 イベント リスナ
import com.bea.p13n.events.EventListener;
import com.bea.p13n.events.Event;
/**
* リスナを行動追跡システムに容易にプラグインできる
* ことを示す TestListener
*
* イベントを受信するには、このクラスをプロパティ eventService.listeners に
* 追加しなければならない。 このプロパティには完全修飾クラス名を
* 追加する必要がある。直前の行の終わりには必ず「,¥」 を追加すること。
* 付け忘れると、プロパティの解析時に新しいクラス名が認識されない。
*
* リスナで受信するイベントのタイプは、String 配列 eventTypes に
* 列挙される。 必要に応じて、イベント タイプの文字列を追加または削除する。
*
* @author Copyright (c) 2001 by BEA Systems, Inc. All Rights Reserved.
*/
public class TestListener
implements EventListener
{
private String[] eventTypes = {"TestEvent"};
public TestListener()
{
}
public String[] getTypes()
{
return eventTypes;
}
public void handleEvent( Event ev )
{
System.out.println("TestListener::handleEvent -> received an event" +
" of type: " + ev.getType() );
return;
}
}
イベント リスナは汎用的でなければならない: 単純なイベントを記述するのが簡単なように、単純な EventListener を作成するのも簡単な作業です。 イベント リスナがどのようなものであれ、その内部の実装は汎用的なものにすべきです。TestEventListener の同一インスタンスで、すべての TestEvent オブジェクトが処理されるとはかぎりません。 したがって、TestEventListener は完全にステートレスでなければならず、イベント オブジェクトまたは外部のデータベースに格納されているデータを操作するものでなければなりません。
注意: どのリスナでも、複数のインスタンスを同時に実行することができます。
Event サービスにリスナ クラスをインストールする
注意: この節では、サンプル ポータルにリスナ クラスを追加する方法を説明します。 実際のアプリケーションの場合も、同様の手順に従うことになるでしょう。
Event サービスがアプリケーションのサービスとして存在しない場合には、WebLogic Server Administration Console を用いて追加します。
行動追跡を有効にするには、行動追跡リスナを同期型リスナとして Event サービスに追加する必要があります。
リスナを追加する: 同期型リスナまたは非同期型リスナを追加するには、以下の手順に従います。
注意: 行動追跡リスナは、同期型リスナとしてのみ実装することができます。
図15-4 WebLogic Server Administration Console ― Event サービス
行動追跡イベント クラスを作成する
行動追跡イベントは、訪問者と Web サイトとのやり取りを追跡する特別なタイプのイベントです。 e 解析システムでは、行動追跡イベントから収集したデータを用いて、訪問者の行動を評価します。 その評価結果は主に、キャンペーンの開発と、Web サイトで訪問者に提供するコンテンツの最適化に利用されます。
例: 行動追跡イベントとそのリスナを作成する方法は、TestEvent クラスと TestEventListener の場合とよく似ています。 ここでも、簡単な例を示します。 ここで扱うサンプル追跡イベントを TestTrackingEvent とします。 データベースに永続化（記録）され BEA Behavior Tracking で使用されるすべての行動追跡イベントは、com.bea.p13n.tracking.listeners.BehaviorTrackingListener によって処理されます。 BehaviorTrackingListener は、com.bea.p13n.events.EventListener クラスを拡張したものです。
再デプロイ: BehaviorTrackingListener を Event サービスにおけるリスナとして定義したあと、そのリスナが行動追跡イベントを受信し永続化できるようになるには、アプリケーションを再デプロイする必要があります。
バッファについて: このリスナは Event サービスからイベントを受信し、バッファに格納します。バッファの内容は、データベース内のイベント用テーブルに断続的に永続化されます。 イベントをバッファからスイープする（データベースにフラッシュする）頻度は、Behavior Tracking サービスに関する以下のプロパティで指定します。
最適化: これらのプロパティを調整して、パフォーマンスを最適化します。 バッファ スイープの実行は、データベースへの書き込みに時間がかかりすぎるほど頻度が低くてもいけませんが、書き込み操作が無駄になるくらい頻繁であってもいけません。
イベント バッファ スイープのコンフィグレーション
注意: この節では、サンプル ポータルのバッファ スイープをコンフィグレーションする方法を説明します。 実際のアプリケーションの場合も、同様の手順に従うことになるでしょう。
Event サービスがアプリケーションのサービスとして存在しない場合には、WebLogic Server Administration Console を用いて追加します。
イベント バッファのスイープをコンフィグレーションするには、以下の手順に従います。
図15-5 WebLogic Server Administration Console ― Behavior Tracking サービス
オフライン処理を支援する
行動追跡イベントは、データベース内の EVENT テーブルに永続化（記録）されるように設計されています。 行動追跡イベントのデータを記録するプロセスの一環としてデータの XML 表現が作成され、EVENT テーブルの xml_definition カラムに格納されます。 ここでの説明は、BEA の行動追跡イベント永続性メカニズムを利用する場合には、この場所にイベントを永続化する必要があります。 そのため、あらかじめ用意されている EVENT テーブルにイベントを永続化するには、カスタム イベントは、作成と永続化が適切に行われるように、この節の説明に従ったものでなければなりません。
XML-XSD スキーマ: 行動追跡イベントに記載されているデータの仕様を形式的に記述するには、新しいイベントの XML-XSD スキーマを定義する必要があります。 XSD は XML 作成の検証に内部的に使用されるわけではありませんが、作成される XML はデータベース内のイベント データを表現しています。 イベント クラスが適切に作成され使用されれば、そのクラスは XML-XSD スキーマに準拠することになります。 XSD ドキュメントを用いれば、行動追跡イベントのコンストラクタと属性キーの作成は容易になります。 各標準イベントの具体的なデータ要素については、『管理者ガイド』の「XML_DEFINITION カラムのデータ要素」 (http://edocs.beasys.co.jp/e-docs/wlp/docs70/admin/sysadmin.htm#1195110) を参照してください。
ファイル間の関連: 行動追跡イベントを XML 表現に正しく変換するには、イベント タイプに関連付けられているスキーマの XML インスタンス ドキュメントを完全に記述するいくつかのメンバー データを、行動追跡イベントに定義する必要があります。 このデータは、イベントに関連付けられているネームスペースと XSD ファイルを記述したものです。 たとえば、リスト 15-4 と リスト 15-5 は、以下のファイル間の関連を示しています。
com.bea.campaign.tracking.events.ClickCampaignEvent と
/lib/schema/tracking-click-campaign-1_0_1.xsd （<BEA_HOME>¥weblogic700¥portal¥¥lib¥campaign¥ejb¥campaign.jar 内）
その他の例については、既存の XSD ファイルを参照してください。
コード リスト 15-4 ClickCampaignEvent.java
/**
キャンペーンのクリックを追跡するためのイベント
*/
public class ClickCampaignEvent
extends ClickEvent
{
/** イベント タイプ */
public static final String TYPE = "ClickCampaignEvent";
/**
このイベントの XML ネームスペース
*/
private static final String XML_NAMESPACE=
"http://www.bea.com/servers/commerce/xsd/tracking/click-campaign/1.01";
/**
このイベントのスキーマを記述した XSD ファイル
*/
private static final String XSD_FILE = "tracking-click-campaign-1_0_1.xsd";
/**
* キャンペーン ID のイベント属性キー名。
* 属性値は String
*/
public static final String CAMPAIGN_ID = "campaign-id";
/**
* シナリオ ID のイベント属性キー名。
* 属性値は String
*/
public static final String SCENARIO_ID = "scenario-id";
/**
* 店舗（アプリケーション名）のイベント属性キー名。
* 属性値は String
*/
public static final String APPLICATION_NAME = "application-name";
/**
* 商品アイテム カテゴリ ID のイベント属性キー名。
* 属性値は String
*/
public static final String PLACEHOLDER_ID = "placeholder-id";
/**
コンストラクタに渡される documentType データへの入力例
属性値は String
*/
public static final String BANNER_AD_PROMOTION = "bannerAdPromotion";
/**
このオブジェクトを表現する XML 内に存在する
要素のキーとそれらの順序。
*/
private static final String localSchemaKeys[] =
{
APPLICATION, SESSION_ID, USER_ID, DOCUMENT_TYPE, DOCUMENT_ID,
CAMPAIGN_ID, SCENARIO_ID, APPLICATION_NAME, PLACEHOLDER_ID
};
/**
* 新しい ClickCampaignEvent を作成する。
*
* @param theSessionId HttpSession.getId() で取得
* @param theUserId HttpServletRequest.getRemoteUser() または
* それに相当するメソッドで取得（不明の場合には null）
* @param theRequest HTTP サーブレット リクエスト オブジェクト
* @param aDocumentType クリックされたコンテンツのドキュメント タイプ (null も可)
*
* @param aDocumentId クリックされたコンテンツのドキュメント ID (null も可)
* @param aCampaignId アイテム クリック時のキャンペーンのキャンペーン ID
*
* @param aScenarioId アイテム クリック時の (キャンペーン内) シナリオの
* シナリオ ID
* @param aApplicationName アプリケーション名 (店舗) (null も可)
*
* @param aPlaceholderId プレースホルダ ID
*/
public ClickCampaignEvent( String theSessionId,
String theUserId,
HttpServletRequest theRequest,
String aDocumentType,
String aDocumentId,
String aCampaignId,
String aScenarioId,
String aApplicationName,
String aPlaceholderId )
{
super( TYPE,
theSessionId,
theUserId,
XML_NAMESPACE,
XSD_FILE,
localSchemaKeys,
theRequest,
aDocumentType,
aDocumentId);
if( aCampaignId != null ) setAttribute( CAMPAIGN_ID, aCampaignId );
if( aScenarioId != null ) setAttribute( SCENARIO_ID, aScenarioId );
if( aApplicationName != null ) setAttribute( APPLICATION_NAME,
aApplicationName );
if( aPlaceholderId != null ) setAttribute( PLACEHOLDER_ID,
aPlaceholderId );
}
}
イベントと XSD の間の相互参照: ClickCampaignEvent と XSD スキーマの間に相互参照があることに注目してください。 この関連のおかげで、行動追跡データをデータベースに適切に記録することができるのです。
コード リスト 15-5 対応する XSD スキーマ
<xsd:schema
targetNamespace="http://www.bea.com/servers/commerce/xsd/tracking/click-campaign/1.0.1"
xmlns="http://www.bea.com/servers/commerce/xsd/tracking/click-campaign/1.0.1"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema.xsd"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:element name="ClickCampaignEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="application"/>
<xsd:element ref="event-date"/>
<xsd:element ref="event-type"/>
<xsd:element ref="session-id"/>
<xsd:element ref="user-id" minOccurs="0"/>
<xsd:element ref="document-type" minOccurs="0"/>
<xsd:element ref="document-id" minOccurs="0"/>
<xsd:element ref="campaign-id"/>
<xsd:element ref="scenario-id"/>
<xsd:element ref="application-name" minOccurs="0"/>
<xsd:element ref="placeholder-id" minOccurs="0"/>
</xsd:sequence>
<!-- types = banner-ad-promotion -->
</xsd:complexType>
</xsd:element>
<xsd:element name="application" type="xsd:string"/>
<xsd:element name="event-date" type="xsd:string"/>
<xsd:element name="event-type" type="xsd:string"/>
<xsd:element name="session-id" type="xsd:string"/>
<xsd:element name="user-id" type="xsd:string"/>
<xsd:element name="document-type" type="xsd:string"/>
<!-- types = banner-ad-promotion -->
<xsd:element name="document-id" type="xsd:string"/>
<xsd:element name="campaign-id" type="xsd:string"/>
<xsd:element name="scenario-id" type="xsd:string"/>
<xsd:element name="application-name" type="xsd:string"/>
<xsd:element name="placeholder-id" type="xsd:string"/>
</xsd:schema>
キーの列挙: 行動追跡イベントのソース コードには、イベント オブジェクトからXML インスタンス ドキュメントを作成するためのキーを、その順序どおりに列挙しておくことも必要です。 たとえば、リスト 15-4 を参照してください。 XSD ドキュメントの構造と、XML ネームスペースの詳細については、http://www.w3.org/XML/Schema を参照してください。 BEA から提供される行動追跡イベントの XSD スキーマは、以下のファイル内の /lib/schema に収められています。
<BEA_HOME>¥weblogic700¥portal¥lib¥p13n¥ejb¥events.jar
ネームスペースとスキーマの指定: ネームスペースとスキーマは、以下のように指定します。
/**
このイベントの XML ネームスペース
*/
private static final String XML_NAMESPACE=
"http://<your URI>/testtracking";
/**
このイベントのスキーマを記述した XSD ファイル
*/
private static final String XSD_FILE="TestTrackingEvent.xsd";
注意: これらの値は、インスタンス ドキュメントの作成時に、その中の各フィールドに値を設定するときに使用されます。
schemaKeys は、イベント クラスの getAttribute メソッドと setAttribute メソッドに渡されるキーとなる文字列のリストです。 これらのキーは、行動追跡イベントを表現する XML インスタンス ドキュメント内の要素に設定されるデータを抽出するのに用いられます。 キーは、文字列型のオブジェクトから成る配列内に列挙しなければなりません。 キーの並びの順序は、XML インスタンス ドキュメントにおけるそれらのキーの出現順序を指定します。 行動追跡システムによって生成される XSD ファイルでは、要素の順序は重要です。要素の順序が正しくないと、XSD ファイルでの XML ファイルの検証は失敗します。 XML の numOccurs キーワードを使用し、その値をゼロに設定することで、要素を省略することができます。 その方法の例については、BEA から提供される行動追跡イベントの XSD スキーマを参照してください。このスキーマは、以下のファイル内の /lib/schema に収められています。
<BEA_HOME>¥weblogic700¥portal¥lib¥p13n¥ejb¥events.jar
配列の定義: 上記の行動追跡対応版 TestEvent の場合には、キーの配列は次のようになるでしょう。
/**
このオブジェクトを表現する XML 内に存在する
要素のキーとそれらの順序。
*/
private static final String localSchemaKeys[] =
{
SESSION_ID, USER_ID, USER_PROPERTY_ONE_KEY,
USER_PROPERTY_TWO_KEY
};
データ要素: SESSION_ID と USER_ID:は localSchemaKeys 配列内のデータ要素で、追跡イベントの実装に役立ちます。 SESSION_ID は WebLogic Server のセッション ID で、セッション オブジェクトごとに作成されます （詳細については、http://edocs.beasys.co.jp/e-docs/wls/docs70/index.html にアクセスしてWebLogic Server マニュアルを参照のこと）。 USER_ID フィールド（null の場合もある）は 、イベントの発生元のセッションに関連付けられている Web サイト訪問者のユーザ名です。 一部のイベントでは、ユーザがイベントに関連付けられていない場合があります。その場合には、先述のように、XSD ファイル内の USER_ID フィールドの numOccurs の値をゼロにする必要があります。 イベントを EVENT テーブルに永続化するには、SESSION_ID は null 以外のものでなければなりません。
その他の属性: すべての行動追跡イベントは、com.bea.p13n.tracking.events.TrackingEvent クラスを拡張する必要があります。 このクラスには、どの追跡イベントの場合にも属性を設定するのに役立つ、以下の 3 つのキーが定義されています。
これらのキーは、TrackingEvent コンストラクタにおいて SESSION_ID、USER_ID、および REQUEST（HttPServletRequest オブジェクト）の値をそれぞれ設定する際に行われる setAttribute の呼び出しで使用されます。 また、これらのキーは、TrackingEvent を拡張するイベント オブジェクトに対して Event.getAttribute (String Key) メソッドを呼び出す際に、各キーに関連付けられている値の取得にも使用しなければなりません。
基本クラス TrackingEvent のコンストラクタを作成する
基本クラス TrackingEvent のコンストラクタは、Event クラスのコンストラクタよりも複雑です。 Event のコンストラクタは、TrackingEvent のコンストラクタでの super( String eventType ) の呼び出しによって呼び出されます。 TrackingEvent のコンストラクタを 、リスト 15-6 と リスト 15-7 に示します。
コード リスト 15-6 TrackingEvent のコンストラクタ ― 例 1
/**
* 新しい TrackingEvent を作成する
*
* @param theEventType イベントのタイプ
* @param theSessionId HttpSession.getId() で取得
*@param theUserId HttpServletRequest.getRemoteUser() または
* それに相当するメソッドで取得 (不明の場合には null)
* @param theXMLNamespace このイベント タイプの XML 表現のネームスペース
* @param theXSDFile XML ファイル内のデータに対する型付けを指定し適用するスキーマを
* 記述したファイル
* @param theSchemaKeys このイベントの XML に永続化されるデータを表すキーの
* リスト (並びは XSD スキーマでの出現順序どおり)
*/
public TrackingEvent( String theEventType,
String theSessionId,
String theUserId,
String theXMLNamespace,
String theXSDFile,
String[] theSchemaKeys )
リスト 15-7 に示した TrackingEvent コンストラクタでは、HttpServletRequest オブジェクトを引数に取ります。
コード リスト 15-7 TrackingEvent コンストラクタ ― 例 2
/**
* 新しい TrackingEvent を作成する
*
* @param theEventType イベントのタイプ
* @param theSessionId HttpSession.getId() で取得
*@param theUserId HttpServletRequest.getRemoteUser() または
* それに相当するメソッドで取得（不明の場合には null）
* @param theXMLNamespace このイベント タイプの XML 表現のネームスペース
* @param theXSDFile XML ファイル内のデータに対する型付けを指定し適用するスキーマを
* 記述したファイル
* @param theSchemaKeys このイベントの XML に永続化されるデータを表すキーの
* リスト（並びは XSD スキーマでの出現順序どおり）
* @param theRequest HTTP サーブレット リクエスト オブジェクト
*/
public TrackingEvent( String theEventType,
String theSessionId,
String theUserId,
String theXMLNamespace,
String theXSDFile,
String[] theSchemaKeys,
HttpServletRequest theRequest )
コンストラクタについての補足: リスト 15-6 に示した最初のコンストラクタでは、null でもよいデータは theUerId だけで、それ以外のデータはすべて必須です。追跡イベントを EVENT テーブルに正しく永続化するためです。 リスト 15-7 に示した 2 番目のコンストラクタでは、イベントの発生元で HttpServletRequest オブジェクトが利用可能な場合には、そこから、コンストラクタの引数として HttpServletRequest オブジェクトを渡すことができます。 このオブジェクトには、イベント インスタンスに対してルールを適用するのに必要なデータが入っています。
注意: カスタム行動追跡イベントに対してルールを適用するには、HttpServletRequest と USER_ID が null 以外のものでなければなりません。 USER_ID が null でないことは通常、訪問者が Web サイトにログイン済みであることを意味します。 ユーザがいないときにトリガされたイベントに対して、ルールを適用することはできません。
TestTrackingEvent のコンストラクタをリスト 15-8 に示します。
コード リスト 15-8 TestTrackingEvent のコンストラクタ
/**
* 新しい TestTrackingEvent を作成する
*
* @param theSessionId HttpSession.getId() で取得
*@param theUserId HttpServletRequest.getRemoteUser() または
* それに相当するメソッドで取得（不明の場合には null）
* @param userPropertyOne String 型のユーザ定義プロパティ
* @param userPropertyTwo Double 型の別のユーザ定義プロパティ
*/
public TestTrackingEvent( String theSessionId,
String theUserId,
String userPropertyOneValue,
Double userPropertyTwoValue )
{
super( TYPE, theSessionId, theUserId, XML_NAMESPACE, XSD_FILE,
localSchemaKeys );
if( userPropertyOneValue != null )
setAttribute( USER_PROPERTY_ONE_KEY, userPropertyOneValue );
if( userPropertyTwoValue != null )
setAttribute( USER_PROPERTY_TWO_KEY, userPropertyTwoValue );
}
このコンストラクタは、TrackingEvent のコンストラクタを呼び出して必須属性に値を設定したあと、この特定の行動追跡イベント タイプに必要な属性を設定します。
TestTrackingEvent クラス全体をリスト 15-9 に示します。
コード リスト 15-9 TestTrackingEvent クラス
import com.bea.p13n.tracking.events.TrackingEvent;
/**
* テスト目的のユーザ定義行動追跡イベント
*
* このイベントはデータベースへの永続化が可能
*
*/
public class TestTrackingEvent
extends TrackingEvent
{
/** イベント タイプ */
public static final String TYPE = "TestTrackingEvent";
/**
このイベントの XML ネームスペース
*/
private static final String XML_NAMESPACE="http://<your URI>/testtracking";
/**
このイベントのスキーマを記述した XSD ファイル
*/
private static final String XSD_FILE="TestTrackingEvent.xsd";
/**
* 1 つ目のユーザ定義プロパティのイベント属性キーの名前。
* 属性値は String
*/
public static final String USER_PROPERTY_ONE_KEY = "userPropertyOne";
/**
* 2 つ目のユーザ定義プロパティのイベント属性キーの名前。
* 属性値は Double
*/
public static final String USER_PROPERTY_TWO_KEY = "userPropertyTwo";
/**
このオブジェクトを表現する XML 内に存在する
要素のキーとそれらの順序。
*/
private static final String localSchemaKeys[] =
{
SESSION_ID, USER_ID, USER_PROPERTY_ONE_KEY, USER_PROPERTY_TWO_KEY
};
/**
* 新しい TestTrackingEvent を作成する
*
* @param theSessionId HttpSession.getId() で取得
*@param theUserId HttpServletRequest.getRemoteUser() または
* それに相当するメソッドで取得（不明の場合には null）
* @param userPropertyOne String 型のユーザ定義プロパティ
* @param userPropertyTwo Double 型の別のユーザ定義プロパティ
*/
public TestTrackingEvent( String theSessionId,
String theUserId,
String userPropertyOneValue,
Double userPropertyTwoValue )
{
super( TYPE, theSessionId, theUserId, XML_NAMESPACE, XSD_FILE,
localSchemaKeys );
if( userPropertyOneValue != null )
setAttribute( USER_PROPERTY_ONE_KEY, userPropertyOneValue );
if( userPropertyTwoValue != null )
setAttribute( USER_PROPERTY_TWO_KEY, userPropertyTwoValue );
}
}
リスト 15-9 に示した TestTrackingEvent クラスでは、そのクラス独自の属性値を正しく設定するとともに、TrackingEvent をインスタンス化した部分の属性値を設定しています。 これによって、このイベントを表現する XML インスタンス ドキュメントを作成する際に、ドキュメント内の属性値が正しく設定されるようになります。 XML インスタンス ドキュメントは、データベースの EVENT テーブルに格納される TestTrackingEvent を表していることを思い出してください。
データベースへの永続化: カスタムの行動追跡イベント タイプをデータベースに永続化する場合には、application-config.xml ファイル内の behaviorTracking.persistToDatabase プロパティに、そのイベントを追加する必要があります。イベントを永続化しない場合には、イベント タイプをこのプロパティに追加する必要はありません。
行動追跡を有効にする方法
注意: Event サービスがアプリケーションのサービスとして存在しない場合には、WebLogic Server Administration Console を用いて追加します。
以下の手順では、行動追跡 (Behavior Tracking) をサンプル ポータルのサービスとして有効にする方法を示します。 実際のアプリケーションの場合も、同様の手順に従うことになるでしょう。
図15-6 WebLogic Server Administration Console ― Behavior Tracking サービス
行動追跡イベントを XML に変換する
行動追跡イベントを EVENT テーブルに永続化する際には、イベント オブジェクトに格納されているデータの大半を XML に変換する必要があります。 この XML ドキュメントは、XML インスタンス ドキュメントでの XML 要素の出現順序を指定する XML-XSD スキーマ（ユーザが作成する ）に準拠していなければなりません。 さらに、このスキーマには、要素のデータ型とその多重度も定義する必要があります。 イベント オブジェクトから XML ドキュメントを作成するプロセスは、行動追跡イベントのクラス ファイル内の変数と定数を利用するヘルパー クラスによって処理されます。 すべてのスキーマ ドキュメントでは、ネームスペース「http://www.w3.org/2000/10/XMLSchema」が使用され、行動追跡スキーマのすべてのインスタンスでは、ネームスペース「http://www.w3.org/2000/10/XMLSchema-instance」が使用されます。 作成される XML ドキュメント（リスト 15-10 に示す）は、XSD スキーマに準拠したものになります。
コード リスト 15-10 XSD ドキュメントの例
<xsd:schema
targetNamespace="http://www.bea.com/servers/commerce/xsd/tracking/buy/1.0.1"
xmlns="http://www.bea.com/servers/commerce/xsd/tracking/buy/1.0.1"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema.xsd"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:element name="BuyEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="application"/>
<xsd:element ref="event-date"/>
<xsd:element ref="event-type"/>
<xsd:element ref="session-id"/>
<xsd:element ref="user-id" minOccurs="0"/>
<xsd:element ref="sku"/>
<xsd:element ref="quantity"/>
<xsd:element ref="unit-price"/>
<xsd:element ref="currency" minOccurs="0"/>
<xsd:element ref="application-name" minOccurs="0"/>
<xsd:element ref="order-line-id"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="application" type="xsd:string"/>
<xsd:element name="event-date" type="xsd:string"/>
<xsd:element name="event-type" type="xsd:string"/>
<xsd:element name="session-id" type="xsd:string"/>
<xsd:element name="user-id" type="xsd:string"/>
<xsd:element name="sku" type="xsd:string"/>
<xsd:element name="quantity" type="xsd:double"/>
<xsd:element name="unit-price" type="xsd:double"/>
<xsd:element name="currency" type="xsd:string"/>
<xsd:element name="application-name" type="xsd:string"/>
<xsd:element name="order-line-id" type="xsd:long"/>
</xsd:schema>
XML の作成: イベントの XML 表現の作成は、一般に、イベントのタイプに応じて行われます。 そのため、正確な XML インスタンス ドキュメントを作成するには、各イベントで、ネームスペース、イベント タイプ、要素、および要素の出現順序を指定する必要があります。 TestTrackingEvent の例では、TestTrackingEvent のインスタンスを表す XML は以下のように作成されるでしょう。
注意: ここでは、testTrackingEvent が TestTrackingEvent の整形式インスタンスであるものとします。
TestTrackingEvent クラスに定義されているスキーマ キーを用いて、XML ドキュメントに値が挿入されます。 スキーマ キーと属性値のペアは、以下のような XML 要素に対応します。
<schema Key>value</schema Key>
行動追跡イベントの XML 表現を作成するヘルパー クラスでは、XML インスタンス ドキュメント内に挿入される要素のネストは深くないと仮定しています。 さらに、Event クラスの getAttribute( String Key ) メソッドの呼び出しを通じて取得される値オブジェクトの表現を作成するには、toString() メソッドが用いられます。 値オブジェクトに対する toString() メソッドの呼び出しの結果返される文字列の内容は、イベントのスキーマ ドキュメントで指定されているデータ型に一致しなければなりません。 TestTrackingEvent では、以下のキーを配列 schemaKeys で指定された順序で用いて、値を取得します。
これらのキーに対応する値は、testTrackingEvent.getAttribute( <schema Key> ) の呼び出しで取得されます。 XML 形式に書式化されたキーと値のペアがインスタンス ドキュメントに挿入される順序は、定数配列 schemaKeys で指定されます。この配列の定義と要素値の設定は、TestTrackingEvent クラスで行われます。
上記の手順によって作成された、TestTrackingEvent の XML インスタンス ドキュメントの例をリスト 15-11 に示します。
コード リスト 15-11 XML インスタンス ドキュメントの例
<TestTrackingEvent
xmlns="http://<your URI>/testtracking"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:schemaLocation="http://<your URI>/testtracking TestTrackingEvent.xsd"
>
<event_date>XML の時刻形式に書式化されたイベント発生日時</event_date>
<event_type>TestTrackingEvent</event_type>
<application>wlcsApp</application>
<session_id>theSessionIdValue</session_id>
<user_id>theUserIdValue</user_id>
<userPropertyOne>userPropertyOneValue</userPropertyOne>
<userPropertyTwo>userPropertyTwoValue</userPropertyTwo>
</TestTrackingEvent>
XML の作成は、イベントが com.bea.p13n.tracking.listeners.BehaviorTrackingListener に到着したときに自動的に実行され、それによって、WebLogic Portal における行動追跡が有効になります。 行動追跡リスナは、application-config.xml ファイル内の <EventService Listeners="..."> プロパティに追加することでインストールされます。 行動追跡リスナのインストール方法については、行動追跡を有効にする方法を参照してください。
警告: カスタム行動追跡イベントが EVENT テーブルに永続化される場合には特に、そのイベント クラスにおけるネームスペース、XSD ドキュメント、およびスキーマ キー変数を定義する際に注意が必要です。 上記で示した XML の作成および格納方法では、イベント クラスで指定されている変数と定数に厳密に従っています。 XML を作成および格納するための方法を他にも自由に開発することができます。この節では、あらかじめ用意されている EVENT テーブルに行動追跡イベントの XML 表現を永続化するプロセスだけに注目しています。
注意: イベントの日付は、Event クラスの getTimeStamp() メソッドを呼び出して取得されます。このメソッドは、Java の基本データ型である long 型の値を返します。 この long 型の値は、XSD スキーマ ドキュメントで指定されている event_date 要素のデータ型に変換されなければなりません。 この場合のデータ型は時刻です。 BehaviorTrackingListener を通じて作成されるすべての XML インスタンス ドキュメントの最初の 2 つの要素は、イベントの日付とイベント タイプです。
カスタム行動追跡イベント リスナを作成する
カスタム行動追跡リスナを作成して、デフォルトの BehaviorTrackingListener の他に追加するか、あるいはその代わりに用いるには、カスタム イベント リスナを作成するで示した例に従います。 カスタム リスナの eventTypes 配列に新しいイベント タイプ（たとえば、TestTrackingEvent）を追加します。 与えられたリスナは、行動追跡イベントであるかないかにかかわらず、任意の数のイベント タイプをリスンすることができます。 カスタム行動追跡リスナは、同期型リスナか非同期型リスナとして（どちらか適切なほうを選ぶ）、Event サービスにインストールすることができます。
カスタム イベント ジェネレータを作成する
イベント クラスを作成したら、イベントを生成するためのメカニズムをアプリケーションにセットアップする必要があります。 イベントの生成元になり得るのは、Pipeline コンポーネント、入力プロセッサ、JSP スクリプトレット、あるいは JSP タグです。 行動追跡イベントの中には、WebLogic Portal ソフトウェア内部から生成されるものもあります。
イベント生成メカニズムを決定したら、com.bea.p13n.tracking.TrackingEventHelper クラスを用いて、行動追跡イベントをイベント システムに送信することができます。 このクラスには、イベントを Event サービスに渡すヘルパー メソッドが定義されています。 TestTrackingEvent の受け渡しの例をリスト 15-12 に示します。
コード リスト 15-12 イベントのディスパッチ
/*
* イベントを作成する
*/
Event theEvent = new TestTrackingEvent( "<some session id>",
"<some user id> ",
new String("userPropertyOneValue"),
new Double( 3.14 ) );
/*
*イベントをディスパッチする
*/
EventService eventService = TrackingEventHelper.getEventService();
TrackingEventHelper.dispatchEvent( eventService, theEvent );
イベントのディスパッチ: Event サービスは EJB なので、イベントをディスパッチする前に、Event サービスを WebLogic Server インスタンスで稼働させておく必要があります。
複数のイベントをディスパッチする場合には、Event サービスのインスタンスを 1 つ取得し、以下のコードに示すように、アプリケーション クラス内の 1 つの属性として保存して再利用するのが一番よいでしょう。
/**
* Event サービスにアクセスし、起動する。
*/
private EventService eventService = com.bea.p13n.tracking.TrackingEventHelper.getEventService ( );
注意: イベント ディスパッチ用の API には 3 通りあります。 そのうちのどれを用いればよいかについては、『Javadoc』 (http://edocs.beasys.co.jp/e-docs/wlp/docs70/javadoc/index.html) を参照してください。
では、以下のように、Event サービスの上記インスタンスを用いてイベントをディスパッチしてみましょう。
/**
*イベントをディスパッチする
*/
EventService eventService = TrackingEventHelper.getEventService();
TrackingEventHelper.dispatchEvent ( eventService, theEvent )
Event サービスのデバッグ
Event サービスをデバッグするには、以下のディレクトリに debug.properties ファイルを作成します。
<BEA_HOME>¥weblogic700¥portal¥config¥<YourDomain>¥debug.properties
このファイルの内容は、リスト 15-13 に示すとおりです。
コード リスト 15-13 Event サービスのデバッグ
usePackageNames: on
# events 下のすべてのクラスについてデバッグを有効にする
com.bea.p13n.events: on
# com.bea.p13n.events.internal.EventServiceBean: on
# tracking 下のすべてのクラスについてデバッグを有効にする
com.bea.p13n.tracking: on
# あるいは、クラスを選んで、それらのデバッグを有効にする
com.bea.p13n.tracking.internal persistence: on
com.bea.p13n.mbeans.BehaviorTrackingListener: on
com.bea.p13n.tracking.listeners.BehaviorTrackingListener: on
com.bea.p13n.tracking.SessionEventListener: on
カスタム イベントの登録
この節では、カスタム イベントの登録（カスタム イベントについての背景的情報を含む）、BEA E-Business Control Center でイベント エディタを用いてイベントを登録する方法、およびカスタム イベントの修正時に必要な作業についての基本事項を説明します。
注意: WebLogic Portal にあらかじめ用意されている標準イベントは、どれも変更することはできません。
カスタム イベントの作成は、複数のステップから成るプロセスです。 以下のリストは、このプロセスの概要を示したものです。
注意: ステップ 1 と 2 はすでに完了しているはずです。
イベントを登録するタイミング
キャンペーンで用いるカスタム イベントを作成する際には、そのイベントを登録する必要があります。 イベントをキャンペーンで使用しない場合には、登録の必要はありません。 カスタム イベントを登録することで、そのカスタム イベントの存在が E-Business Control Center に認識されます。 また、登録すれば、キャンペーン開発者が E-Business Control Center を用いて、そのイベントを参照するシナリオ アクションを作成できるようになります。 さらに、登録によって、イベントのプロパティが識別されます。
警告: イベント コードを変更するたびに、イベント登録を更新する必要があります。 逆に、イベント登録を変更するたびに、イベント コードも更新する必要があります。 イベントを修正した結果、そのイベントのプロパティを参照するシナリオ アクションの修正が必要になる場合があります。
イベント プロパティ
E-Business Control Center のイベント エディタを利用すれば、カスタム イベントをたやすく登録することができます。 イベントを登録する際には、イベント プロパティを名前と値のペアとみなすことができます。 カスタム イベントの登録時には、イベントの名前、概要、および 1 つ以上のプロパティを指定します。 各プロパティには、値の範囲、取り得る値のデータ型、およびデフォルト値があります。 イベントの登録に必要な情報は、コマース ビジネス エンジニア (CBE) や Java 開発者から入手できるはずです。
カスタム イベントのプロパティには、以下の情報が含まれています。
注意: プロパティ値を設定する際には、プロパティが実行時にこれらの制限に従うかどうかは保証されません。 SchemaManager では、イベントをチェックして、プロパティ スキーマに従っているかどうかを調べることはありません。 そのため、イベント タイプ定義とイベント登録の同期を保つ必要があります。
上記リストからもわかるように、プロパティ値の組み合わせも可能です。 プロパティの有効な組み合わせは、以下のとおりです。
カスタム イベントの登録手順
カスタム イベントを登録するには、以下の手順を実行します。
図15-7 E-Business Control Centerウィンドウ
図15-8 イベント エディタ ウィンドウ
図15-9 [プロパティの編集] ウィンドウ
登録済みカスタム イベントを更新する
カスタム イベントのコードに変更を加えるたびに、そのイベントの登録を更新しなければなりません。 登録を更新すれば、カスタム イベントの変更が E-Business Control Center に認識され、 キャンペーン開発者がE-Business Control Center を用いて、そのイベントを参照するシナリオ アクション（キャンペーン内に定義）をすべて修正するのに役立ちます。
カスタム イベントを更新するには、以下の手順を実行します。
図15-11 イベント エディタ ウィンドウ
図15-12 [プロパティの編集] ウィンドウ
行動追跡のアクティブ化
オンライン訪問者が Web サイトとどのようにやり取りしているかを記録するために、イベント情報をデータベースに記録することができます。 こうした種類のイベントは行動追跡イベントと呼ばれます。 e 解析システムや e マーケティング システムでは、これらのイベントをオフラインで分析して、訪問者の行動とトランザクション データを評価することができます。
注意: イベント データを記録できるようにデータベースをコンフィグレーションする方法については、『管理者ガイド』の「行動追跡データの永続化」 (http://edocs.beasys.co.jp/e-docs/wlp/docs70/admin/sysadmin.htm#1194894) を参照してください。
この節では、以下のトピックを扱います。
行動追跡をアクティブ化する手順
行動追跡イベントをデータベースに記録できるようにするには、まず、行動追跡リスナを有効にする必要があります。 それには、リスナ クラスを追加します。
注意: Event サービスがアプリケーションのサービスとして存在しない場合には、WebLogic Server Administration Console を用いて追加します。
以下の手順では、リスナ クラスをサンプル ポータルに追加する方法を示します。 実際のアプリケーションの場合も、同様の手順に従うことになるでしょう。
図15-13 WebLogic Server Administration Console ― Event サービス
注意: 行動追跡をアクティブにする前に、データベースをコンフィグレーションする必要があります。 その方法については、『管理者ガイド』の「行動追跡データの永続化」 (http://edocs.beasys.co.jp/e-docs/wlp/docs70/admin/sysadmin.htm#1194894) を参照してください。
WebLogic Server における Behavior Tracking サービスをコンフィグレーションする
行動追跡イベントはいったんバッファに格納されたあと、データベース内のイベント用テーブルに断続的に永続化（記録）されます。データベースに格納されたイベントは、オフラインで分析することができます。 非同期型サービスが使用されるのは、イベント ハンドラの実行に時間がかかる場合でも、Web サイト訪問者の目から見てアプリケーションの動作に遅延が生じないようにするためです。
注意: 行動追跡イベントの各プロパティは、WebLogic Server Administration Console でコンフィグレーションする必要があります。
接続プール: バッファに格納された行動追跡イベントは、データ接続プールを用いてデータベースにスイープされます。 デフォルト データ ソースは weblogic.jdbc.jts.commercePool です。 別のデータ ソースを使用することもできます。 それには、新しいデータ ソースを作成およびコンフィグレーションし（データ ソースをコンフィグレーションするを参照）、WebLogic Server Administration Console で、デフォルト データ ソースの名前を新しいデータ ソースの名前に置き換えます。
プロパティ: データベースに永続化される特定のイベントは、PersistEventTypes プロパティで指定します。 WebLogic Server Administration Console で、永続化されるイベントのリストを確認したり変更することができます。 このリスト内のタイプは、イベントで指定されたタイプと一致する必要があります。たとえば、SessionBeginEvent のタイプを表す文字列は“SessionBeginEvent” です。
パフォーマンスの最適化: バッファ内のイベントをスイープする頻度は、Behavior Tracking サービスの以下のプロパティで指定します。
これらのプロパティを調整して、パフォーマンスを最適化しなければなりません。 バッファ スイープの実行は、データベースへの書き込みに時間がかかりすぎるほど頻度が低くてもいけませんが、書き込み操作が無駄になるくらい頻繁であってもいけません。
手順: Behavior Tracking サービスをコンフィグレーションするには、以下の手順に従います。
注意: 以下の手順では、サンプル ポータルのパフォーマンスを最適化する方法を示します。 実際のアプリケーションの場合も、同様の手順に従うことになるでしょう。
Event サービスがアプリケーションのサービスとして存在しない場合には、WebLogic Server Administration Console を用いて追加します。
注意: アプリケーションに Behavior Tracking サービスと Event サービスが用意されていない場合には、WebLogic Server Administration Console を用いて、それらを追加します。
データ ソースをコンフィグレーションする
この節では、サンプル ポータルでイベントの永続化に用いられる接続プールの新しいデータ ソースのコンフィグレーションについて簡単に説明します。 実際のアプリケーションの場合も、同様の手順に従うことになるでしょう。
新しいデータ ソースをコンフィグレーションするには、以下の手順に従います。
注意: WebLogic Server Administration Console の使い方の詳細については、WebLogic Server マニュアル (http://edocs.beasys.co.jp/e-docs/wls/docs70/index.html) を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
