対話管理ガイド
|
 |
 |
|
ユーザが Web インタフェースと対話する (ログイン、グラフィックのクリックや表示、ボタンのクリック、ポータル内の別のページへの移動、などを行う) と、イベントが生成されます。
WebLogic Portal には、さまざまな方法でイベントを活用できるイベント フレームワークがあります。イベントが発生したときに、キャンペーンのトリガ、イベント データのデータベースへの保存、およびその他のプログラム機能を実行できます。
注意 : 対話管理イベントは、ポートレット イベントとは異なります。ポートレット イベントは、ポートレット間通信のためのフレームワークを提供します。
イベント フレームワークにより提供できる機能の例を次に示します。
各イベントは Event オブジェクトのインスタンスであり、ユニークな名前 (またはタイプ) によって識別されます。各イベント タイプは、その機能に応じて、特定の属性を取得および設定できます。上に挙げた例の場合、イベントが特定の情報を取り込む必要があります。たとえば、ユーザがポータル ページにアクセスした回数を取り込むには、ClickPage イベントが、クリックされたページの名前を取得して設定します。コンテンツのどの部分が表示されたか識別するために、DisplayContent イベントが、表示されたコンテンツ項目の ID とタイプを取得して設定する場合があります。
イベントが各自の属性値を設定した後、それらの値を任意の方法で永続化できます。WebLogic Portal には、イベントの属性を XML としてデータベースに永続化するメカニズムがデフォルトで用意されています。イベント データがデータベースに保存されると、それらのデータを検索して分析したり、レポートを発行したり、アプリケーションにイベント データを供給したりできます。たとえば、データベースに対して SQL クエリを実行し、各ポータル ページの表示回数を返すポートレットを作成できます。独自の永続化機能を開発することもできます。たとえば、イベント データをファイルに保存したり、データを XML で構造化せずにデータベース テーブルに書き込んだりできます。
イベントが属性も永続化も必要としない場合があります。それらのイベントの唯一の目的は、何らかの別の機能をトリガすることです。たとえば、ダウンロード リンクについて、誰がクリックしたかに関係なく、何回クリックされたかを調べる場合は、ClickDownloadLink イベント (および付随するイベント リスナ) によってデータベース フィールドの値を 1 ずつインクリメントすることができます。
キャンペーン定義内でイベントを使用して、キャンペーンをさらに有効にすることもできます。たとえば、ユーザのポータルへの登録によって UserRegistration イベントが生成したときに、定義済みの電子メールを自動的にユーザに送信したり、特定の属性値を持つイベントが生成されたときに、パーソナライズされたコンテンツを表示したりできます。
この章では、イベント フレームワークのコンポーネントについて説明します。フレームワークの各部分の目的と使い方、WebLogic Portal の定義済みイベント、およびアプリケーション内でのイベントの使用に関するガイダンスと手順の説明を参照して、イベントの使用方法を考慮してください。
イベント フレームワーク (図 6-1) を使用して、イベントをさまざまな方法で柔軟に処理できます。図に続く表は、このフレームワークを部分ごとに説明しています。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
WebLogic Portal のイベント フレームワークには、前の節で説明したように、イベントを生成して処理するための複数のオプションが用意されています。この節では、必要な機能を実装するためにイベント フレームワークのどの部分を使用するかを判断するためのガイドラインを示します。
WebLogic Portal には、「WebLogic Portal で提供される定義済みイベント」で説明しているように、アプリケーションで使用できる定義済みの行動追跡イベントが多数用意されています。各イベントは、特定の属性を収集し、収集した属性を XML として構造化します。その後、行動追跡リスナが、BT_EVENT データベース テーブルに挿入するためにその XML をバッファに配置します。
ほとんどの定義済みイベントには、WebLogic Workshop に定義済みのイベント プロパティ セットがあり、それらは、ポータル アプリケーションの data/events ディレクトリに格納されています。これらのプロパティ セットをキャンペーン定義内のイベントで使用して、イベントが発生した、またはイベントに特定の属性値があったときにキャンペーン アクションをトリガできます。
WebLogic Portal の定義済みイベントは、次の場合に使用します。
必要な属性を取り込む WebLogic Portal の定義済みイベントがない場合は、カスタム イベントを作成します。行動追跡イベントと標準イベントという 2 種類のカスタム イベントを作成できます。
カスタム行動追跡イベントを作成する唯一の理由は、目的のイベント属性を取り込む WebLogic Portal の定義済みイベントがない場合に、WebLogic Portal の行動追跡フレームワークを使用して、イベント データを XML として BT_EVENT テーブルに永続化するためです。これらのイベントをキャンペーンで使用し、イベントに対して特殊な処理を行うカスタム リスナを作成できますが、行動追跡フレームワークを使用してイベント データを XML として保存するのでない限り、カスタム行動追跡イベントを作成する理由はありません。
Behavior Tracking Service を使用しない場合は、カスタム標準イベントを作成します。
カスタム標準イベントは、目的のイベント属性を取り込む WebLogic Portal の定義済みイベントがなく、Behavior Tracking Service を使用してイベント データを XML として BT_EVENT テーブルに永続化しない場合に作成します。
WebLogic Portal には、キャンペーン リスナと行動追跡リスナという 2 つのリスナが用意されています。
キャンペーン リスナは、イベントが発生すると、Campaign Service に通知します (wps.jar ファイルの listener.properties ファイル内の無視されるイベントを除く)。Campaign Service は、現在の要求を読み込み、要求されたデータがいずれかのキャンペーンの条件と一致している場合はキャンペーン アクションを実行します。キャンペーン定義に、イベント プロパティ セットによって指定したイベント条件が含まれている場合、Campaign Service は、それらの条件も同様に評価して、キャンペーン アクションを実行する必要があるかどうかを決定します。
行動追跡リスナは、Behavior Tracking Service によって登録された行動追跡イベントだけをリスンします。行動追跡リスナは、リスンすべきイベントを受信すると、そのイベントの XML ドキュメントをバッファに移動します。XML ドキュメントは、その後、指定された間隔で BT_EVENT テーブルに永続化されます。
カスタム イベント リスナは、キャンペーン リスナまたは行動追跡リスナでは提供されない機能を実行する場合に作成します。たとえば、イベント データの独自の永続化やユーザ プロファイルの変更、ページ フローの別の部分へのユーザのリダイレクト、イベントに対するその他のリアルタイム応答を実行する場合は、目的の機能を提供するカスタム イベント リスナを作成します。
カスタム イベント、リスナ、およびイベント プロパティ セットの作成には、アプリケーションへのファイルの追加とアプリケーションのクラスパスの更新が関係します。デプロイ済みのアプリケーションにイベントとプロパティ セットを追加する場合は、アプリケーションを再デプロイメントしてイベントとクラスパスを更新し、Datasync Web Application を実行してデータベース内のイベント プロパティを更新する必要があります。デプロイメントと Datasync Web アプリケーションの詳細については、『プロダクション業務ユーザーズ ガイド』を参照してください。
この節では、WebLogic Portal で提供される定義済みの行動追跡イベントの使用方法について詳しく説明します。イベントが生成またはディスパッチされると、イベントは、異なる属性を取り込み、行動追跡リスナと Behavior Tracking Service を使用して、属性を XML として BT_EVENT テーブルに永続化します。イベント属性を永続化するには、行動追跡を有効にする必要があります (「行動追跡の有効化とコンフィグレーション」を参照してください)。イベントを使用してキャンペーンをトリガすることもできます。
従来の WebLogic Portal コマース アプリケーションと互換性がある定義済みイベントは、AddToCartEvent、PurchaseCartEvent、および RemoveFromCartEvent だけです。これらのイベントは、コマース アプリケーションのフローの一部であったパイプライン コンポーネントによってディスパッチされていました。WebLogic Portal の旧バージョンでは、アプリケーション フローとカタログ管理は、別々のフレームワークを使用して、イベント プロパティ値の取得とイベントのディスパッチを行っていました。これらのイベントを新しいコマース アプリケーションでディスパッチする場合は、イベント プロパティ値の設定と取得を行うための独自のコードとコンテンツ管理プロパティを作成し、アプリケーション コード (ページ フローや JSP など) からこれらのイベントをディスパッチする必要があります。
定義済みイベントがディスパッチされたときにカスタムイベント処理を実行する場合は、「カスタム イベント リスナの作成 」の説明に従って、カスタム イベント リスナを作成します。
ユーザがポータルにログインした (認証された) ときにイベントをディスパッチするには、SessionLoginEvent を使用します。
行動追跡が有効になっている場合は、イベントが生成され、図 6-3 に示すように、Behavior Tracking Service によって永続化イベントとして登録されたときに、イベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれます。
|
|
|
|
|
|
SessionBeginEvent と SessionEndEvent は、自動的に生成されます。SessionBeginEvent は、WebLogic Portal で実行中の Web サイトにユーザがアクセスしたときに生成されます。SessionEndEvent は、ユーザがブラウザを閉じるかセッションがタイムアウトしたときのように、セッションが終了したときに生成されます。
行動追跡が有効になっている場合は、イベントが生成され、図 6-3 に示すように、Behavior Tracking Service によって永続化イベントとして登録されたときに、イベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれます。
SessionBeginEvent と SessionEndEvent には、ポータル アプリケーションに対応するプロパティ セットがありません。デフォルトでは、キャンペーン リスナはこれらのイベントをリスンしないので、これらのイベントを使用してキャンペーンをトリガすることはできません。詳細については、このガイドの「キャンペーン」の章の「キャンペーンをトリガする方法｣を参照してください。
ユーザがポータルに登録した (ユーザが登録ポートレットなどを使用してプログラム的にユーザ ストアに追加された) ときにイベントをディスパッチするには、UserRegistrationEvent を使用します。
行動追跡が有効になっている場合は、イベントが生成され、図 6-3 に示すように、Behavior Tracking Service によって永続化イベントとして登録されたときに、イベント プロパティ値 (特にユーザ ID の) がデータベースの BT_EVENT テーブルに書き込まれます。
|
|
|
|
|
|
ユーザがショッピング カートに商品を追加したときにイベントをディスパッチするには、AddToCartEvent を使用します。このイベントを使用すると、通貨の種類、追加された商品の数量、単価、sku などの情報を取り込むことができます。このイベントを使用するには、これらのプロパティを何らかの形でショッピング カートとコンテンツ タイプ内に表現する必要があります。
行動追跡が有効になっている場合は、イベントが生成され、図 6-3 に示すように、Behavior Tracking Service によって永続化イベントとして登録されたときに、イベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれます。
|
|
|
|
|
|
ユーザがショッピング カートから商品を削除したときにイベントを生成するには、RemoveFromCartEvent を使用します。このイベントを使用すると、通貨の種類、追加された商品の数量、単価、sku などの情報を取り込むことができます。このイベントを使用するには、これらのプロパティを何らかの形でショッピング カートとコンテンツ タイプ内に表現する必要があります。
行動追跡が有効になっている場合は、イベントが生成され、図 6-3 に示すように、Behavior Tracking Service によって永続化イベントとして登録されたときに、イベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれます。
|
|
|
|
|
|
|
|
ユーザが商品を購入したときにイベントをディスパッチするには、PurchaseCartEvent を使用します。このイベントを使用すると、通貨の種類、注文番号、購入金額の合計などの情報を取り込むことができます。このイベントを使用するには、これらのプロパティを何らかの形でショッピング カート内に表現する必要があります。
行動追跡が有効になっている場合は、イベントが生成され、図 6-3 に示すように、Behavior Tracking Service によって永続化イベントとして登録されたときに、イベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれます。
|
|
|
|
|
|
|
|
WebLogic Portal には、Rules Executor コントロールを使用してページ フロー内でルールが適用されたときに常に行動追跡イベントを生成できるルール イベント コントロールが用意されています。ルール イベント コントロールは、必要なすべてのプロパティを取得します。プロパティには、ルール セットの名前と適用されたルールが含まれます。
行動追跡が有効になっている場合は、イベントが生成され、図 6-3 に示すように、Behavior Tracking Service によって永続化イベントとして登録されたときに、イベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれます。
ルール イベントには、ポータル アプリケーション内に対応するプロパティ セットがありません。ルールのほうが柔軟性が高く強力なので、ルールは、しばしばキャンペーンの代わりに使用されます。したがって、ルールが適用されたときにキャンペーンをトリガするためにルール イベント プロパティ セットを作成するのは、現実的なシナリオではありません。それでもルールが適用されたときにキャンペーンをトリガするルール プロパティ セットを作成する場合は、RuleEvent.evt という名前のイベント プロパティ セットを作成し、ruleset-name と rule-name という制限のない単一の String プロパティを追加します。プロパティ セットの作成手順については、WebLogic Workshop ヘルプ システムの 「カスタム イベントを登録する｣を参照してください。
ルールの使用手順については、「ルール イベント コントロール」と「ポータル アプリケーションでのルールの使用」を参照してください。
行動追跡が有効になっている場合、DisplayCampaignEvent は、キャンペーンによってコンテンツ項目がプレースホルダに配置されたときに自動的に生成されます。イベント プロパティ値は、イベントが生成され、図 6-3 に示すように Behavior Tracking Service によって永続化イベントとして登録されたときに、データベースの BT_EVENT テーブルに書き込まれます。
WebLogic Portal には、JSP でコンテンツの一部を表示したときに行動追跡イベントを生成できるコンテンツ表示イベントと <BehaviorTracking:displayContentEvent/> JSP タグが用意されています。
document-id プロパティと document-type プロパティの取得方法については、表 6-1 を参照してください。
行動追跡が有効になっている場合は、イベントが生成され、図 6-3 に示すように、Behavior Tracking Service によって永続化イベントとして登録されたときに、イベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれます。
コンテンツ表示イベントには、ポータル アプリケーション内に対応するプロパティ セットがありません。デフォルトでは、Campaign Service はこれらのイベントをリスンしないので、これらのイベントを使用してキャンペーンをトリガすることはできません。詳細については、このガイドの「キャンペーン」の章の「キャンペーンをトリガする方法｣を参照してください。
WebLogic Portal には、カタログから商品を表示したときに行動追跡イベントを生成できる <productTracking:displayProductEvent/> JSP タグが用意されています。
application-name、category-id、document-id、document-type、および sku の各プロパティの取得方法については、表 6-1 を参照してください。
行動追跡が有効になっている場合は、イベントが生成され、図 6-3 に示すように、Behavior Tracking Service によって永続化イベントとして登録されたときに、イベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれます。
商品表示イベントには、ポータル アプリケーション内に対応するプロパティ セットがありません。デフォルトでは、Campaign Service はこれらのイベントをリスンしないので、これらのイベントを使用してキャンペーンをトリガすることはできません。詳細については、このガイドの「キャンペーン」の章の「キャンペーンをトリガする方法｣を参照してください。
キャンペーンによって表示されたコンテンツ項目をユーザがクリックしたときにイベントを生成するには、ClickCampaignEvent を ClickThroughEventFilter と組み合わせて使用します。
コンテンツのクリックを有効にするには、次の操作を行う必要があります。
web.xml ファイルと weblogic.xml ファイルに適切なエントリを入力します。行動追跡が有効になっている場合は、イベントが生成され、図 6-3 に示すように、Behavior Tracking Service によって永続化イベントとして登録されたときに、イベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれます。
|
|
|
|
|
|
ユーザが「商品」コンテンツ項目をクリックしたときにイベントを生成するには、ClickProductEvent を ClickThroughEventFilter と組み合わせて使用します。商品コンテンツ項目は、通常は、カタログまたはショッピング カート内の商品です。ClickProductEvent を使用して、商品カテゴリや sku などの情報を取り込むことができます。このイベントを使用するには、これらのプロパティを何らかの形でコンテンツ タイプ内に表現する必要があります。
コンテンツのクリックを有効にするには、「コンテンツのクリックに対応したイベントの生成」の説明に従って、ポータル Web プロジェクトの web.xml ファイルと weblogic.xml ファイルに適切なエントリを入力します。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは Behavior Tracking Service に永続化イベントとして登録されます。図 6-3 を参照してください。
|
|
|
|
|
|
|
|
ユーザがポータルでキャンペーンの結果としてではなく仮想コンテンツ リポジトリから取得されたコンテンツ項目をクリックしたときにイベントを生成するには、ClickContentEvent を ClickThroughEventFilter と組み合わせて使用します。
コンテンツのクリックに対応したイベントの生成を有効にするには、「コンテンツのクリックに対応したイベントの生成」の説明に従って、ポータル Web プロジェクトの web.xml ファイルと weblogic.xml ファイルに適切なエントリを入力します。
行動追跡が有効になっている場合は、イベントが生成されるとイベント プロパティ値がデータベースの BT_EVENT テーブルに書き込まれ、イベントは Behavior Tracking Service に永続化イベントとして登録されます。図 6-3 を参照してください。
|
|
|
|
|
|
WebLogic Portal には、ユーザがポータルのコンテンツ項目をクリックしたときに生成することが可能な定義済みイベントが用意されています。たとえば、コンテンツ クリック イベントは、<BehaviorTracking:clickContentEvent> と <productTracking:clickProductEvent> という JSP タグによって有効になります。ClickCampaignEvent も、コンテンツ クリック イベントを生成します。コンテンツがクリックされたときに Event Service にイベントがディスパッチされるようにするには、以降の節の手順に従います。
URL で /ShowBinary を使用するときは、常に ClickThroughEventFilter を使用します。ShowBinary (ShowPropertyServlet にマップされる) は、グラフィックなどのバイナリ Web コンテンツを表示します。/ShowBinary は、JSP のコンテンツ URL で使用します。ClickThroughEventFilter を /ShowBinary の URL パターンにマップした後、JSP で /ShowBinary をクリック イベント JSP タグと組み合わせ、URL の一部として使用します。これで、ユーザがコンテンツをクリックしたときに、ClickThroughEventFilter によってコンテンツ クリック イベントが生成されます。
注意 : バイナリ コンテンツを表示する場合、最も妥当な選択は、/ShowBinary を URL パターンとして使用することです。ただし、/ShowBinary を必ず使用しなければならないというわけではありません。
この機能を有効にするには、次のフィルタとフィルタ マッピングをポータル 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>
前の節で説明した ClickThroughEventFilter は Event Service を参照するので、ポータル Web プロジェクトの web.xml ファイルと weblogic.xml ファイルに Event Service が挿入されていることを確認する必要があります。
新しいポータル Web プロジェクトを作成すると、web.xml と weblogic.xml に次のエントリがデフォルトで入力されます。ただし、これらのエントリがファイルに含まれているか、必ず確認してください。
<ejb-ref>
<description>Event Service</description>
<ejb-ref-name>ejb/EventService</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.bea.p13n.events.EventServiceHome</home>
<remote>com.bea.p13n.events.EventService</remote>
</ejb-ref>
<ejb-reference-description>
<ejb-ref-name>ejb/EventService</ejb-ref-name>
<jndi-name>${APP_NAME}.BEA_personalization.EventService</jndi-name>
</ejb-reference-description>
注意 : ${APPNAME} は変数です。ハードコード化されたアプリケーション名に変更しないでください。
定義済みのClickCampaignEvent をトリガするキャンペーンのクリックスルーを有効にするには、このガイドの「コンテンツの設定」の説明に従って、コンテンツ項目に特定のプロパティをコンフィグレーションする必要があります。
WebLogic Portal の定義済みイベントでは、属性値の多くは自動的に設定されます。ただし、コード内に手動で設定する必要がある属性があります。表 6-1 で、定義済みイベントに必要な属性について説明し、コード内に属性を設定するために使用できるメソッドを示します。これらのメソッドを使用して、カスタム イベントに属性を設定することもできます。
一部の属性は、生成された他のイベントから取得できます。たとえば、キャンペーンによってコンテンツの一部が表示されたときは、常に DisplayCampaignEvent が生成されます。DisplayCampaignEvent は、placeholder-id とその他の属性を設定します。カスタム イベントのために placeholder-id を設定する場合は、そのイベントに対して getAttribute() メソッドを使用することで、DisplayCampaignEvent から属性を取得できます。例 : DisplayCampaignEvent.getAttribute( "aPlaceholderId" );
WebLogic Portal ドメインのデフォルトである PointBase データベース (および他のデータベース タイプのポータル データベースを構築するために使用される SQL スクリプト) には、行動追跡データを保存するために使用できる行動追跡テーブルが含まれています。ただし、行動追跡イベントを使用するには、行動追跡を手動でアクティブにする必要があります。
行動追跡をアクティブにするには、次の手順に従って、BehaviorTrackingListener クラスを Event Service に登録します。
注意 : この手順は、開発環境またはテスト環境で、展開されたアプリケーションを使用していることを前提とします。EAR ファイルのアプリケーションに対して行動追跡を有効にしても、コンフィグレーションはメモリのみに保存され、サーバを再起動したときに行動追跡は有効になりません。コンフィグレーションは META-INF/application-config.xml ファイルに書き込む必要があるためです。このファイルは、EAR 内では読み取り専用です。
com.bea.p13n.tracking.listeners.BehaviorTrackingListener
注意 : 同期リスナは、イベントを直ちに受信します。非同期リスナは、スレッド スケジューラを使用してイベントを受信します。
application-config.xml ファイルが更新されます。これで、行動追跡がアクティブになりました。サーバの再起動や再デプロイメントの必要はありません。デフォルトでは、行動追跡データは行動追跡イベントが発生した瞬間にデータベースに書き込まれるのではありません。イベントはバッファに格納されます。行動追跡データをバッファからデータベースに移動する頻度を決定できます。
行動追跡をコンフィグレーションするには、WebLogic Administration Portal で [サービス管理｜行動追跡サービス] を選択し、表 6-2 の説明に従って、図 6-3 のように設定を変更します。
この変更を有効にするには、サーバを再起動する必要があります。
データソースの JNDI 名 (p13n.trackingDataSource) と永続化クラス名 (null) はデフォルトのままにします。これらは、イベント データをバッファからデータベース内の BT_EVENT テーブルに移動するためのデフォルトの動作を指定します。他の永続化については、「他の方法での行動追跡データの保存」を参照してください。
[永続化イベント タイプ] フィールドの詳細については、「行動追跡イベント クラスの作成」を参照してください。
開発環境またはテスト環境で、[最大バッファ サイズ]、[バッファ スイープ間隔]、および [バッファ スイープ最長時間] に基準値を設定します。その後、値を変更しながら Web アプリケーションによるサイトのピーク時の使用量でテストを行い、データベース操作の回数と保存されるデータ量のバランスが最適になる値を見つけます。
デフォルトでは、行動追跡イベント データは BT_EVENT テーブルのデータベースに保存されます。イベント データを別の場所や別の方法で (別のデータベース テーブルやファイルに) 永続化する場合は、異なる永続化ロジックを提供するカスタム イベント リスナを作成します。カスタム リスナの作成については、「カスタム イベント リスナの作成」を参照してください。
行動追跡の使用頻度が高い場合は、パフォーマンス向上のために行動追跡データを別のデータベースに保存できます。『WebLogic Portal データベース管理ガイド』では、行動追跡データベースの作成手順をデータベース タイプごとに説明しています。
必要を満たす WebLogic Portal の定義済みイベントがない場合は、独自のカスタム イベントを作成できます。どのような場合にどのようなタイプのカスタム イベントを作成するかについては、「イベントの使用方法の計画｣を参照してください。
カスタム イベントを作成するには、次の手順を実行する必要があります。
WebLogic Portal には、Event Service で動作する Event と TrackingEvent という基本イベント オブジェクトが用意されています。これらの基本クラスは、Event Service によって要求されるメソッドを提供します。
イベント クラスを作成するときは、いずれかの基本クラスを拡張し、必要なイベント属性を宣言し、イベント データ (イベント タイプなど) を基本クラス コンストラクタに渡します。
この節では、カスタム標準イベントとカスタム行動追跡イベントを作成するときの手順について説明します。
カスタム標準イベントは、WebLogic Portal の定義済みイベントに目的のイベント属性を取り込むイベントがなく、さらに Behavior Tracking Service を使用してイベント データを XML として BT_EVENT テーブルに永続化しない場合に作成します。カスタム イベント リスナを作成すると、カスタム標準イベントを使用してキャンペーンをトリガし、独自のイベント処理を実行できます。
次の手順は、カスタム イベント クラスの作成方法を示しています。
注意 : http://edocs.bea.com/wlp/docs81/interm/src/sample_events.zip ファイルのサンプル イベント クラス ResourceDisplayedEvent.java を参照することもできます。
com.bea.p13n.events.Event クラスを拡張するイベント クラスを作成します。次に例を示します。public class MyEvent
extends com.bea.p13n.events.Event
public static final String TYPE = "MyEvent";
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));
Event クラス コンストラクタを呼び出して、イベント タイプを渡します。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" );
wherefooAttributeValueis the variable that stores the value you retrieved in your code (not shown here).
javac -classpath D:\bea\weblogic\<portalApp>\p13n_ejb.jar MyEvent.java
これで、「イベントのディスパッチ｣の説明に従って、JSP、Java コード、またはページ フローからイベントをディスパッチできます。
キャンペーン定義でイベントを使用する場合は、「キャンペーン用のイベントの登録」の説明に従って、イベントのイベント プロパティ セットを作成します。
イベントが生成されたときにカスタム機能を実行する場合は、「カスタム イベント リスナの作成」の説明に従って、イベントをリスンするカスタム イベント リスナを作成します。
カスタム行動追跡イベントを作成する唯一の理由は、目的のイベント属性を取り込む WebLogic Portal の定義済みイベントがない場合に、WebLogic Portal の行動追跡フレームワークを使用して、イベント データを XML として BT_EVENT テーブルに永続化するためです。これらのイベントをキャンペーンで使用し、イベントに対して特殊な処理を行うカスタム リスナを作成できますが、行動追跡フレームワークを使用してイベント データを XML として保存するのでない限り、カスタム行動追跡イベントを作成する理由はありません。Behavior Tracking Service を使用しない場合は、カスタム標準イベントを作成します。
行動追跡イベントは独自の XML スキーマと連携して動作し、イベント データを XML として BT_EVENT データベース テーブルに保存します。次の手順に従って、スキーマに関する情報をイベント クラスに含める必要があります。
次の手順は、カスタム行動追跡イベント クラスの作成方法を示しています。
注意 : http://edocs.bea.com/wlp/docs81/interm/src/sample_events.zip ファイルのサンプル イベント クラス ResourceDisplayedEventBT.java を参照することもできます。
com.bea.p13n.tracking.events.TrackingEvent クラスを拡張するイベント クラスを作成します。次に例を示します。public class MyEventBT
extends com.bea.p13n.tracking.events.TrackingEvent
public static final String TYPE = "MyEventBT";
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 MyEventBT(
String pageLabel,
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" );
}
p13n_ejb.jar をクラスパスに配置します。次に例を示します。javac -classpath D:\bea\weblogic\<portalApp>\p13n_ejb.jar MyEventBT.java
WebLogic Workshop でエンタープライズ アプリケーションを開き、[ツール｜アプリケーション プロパティ] を選択します。[アプリケーション プロパティ] ウィンドウで、[WebLogic Server] を選択し、ウィンドウを最下部までスクロールし、[サーバ クラスパスの追加] リストにパスを追加します。
キャンペーン定義でイベントを使用する場合は、「キャンペーン用のイベントの登録」の説明に従って、イベントのイベント プロパティ セットを作成します。
イベントが生成されたときにカスタム機能を実行する場合は、「カスタム イベント リスナの作成」の説明に従って、イベントをリスンするカスタム イベント リスナを作成します。
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 を使用しますが、標準イベントもディスパッチします。
イベントが生成されたときにカスタム機能を実行する場合は、「カスタム イベント リスナの作成」の説明に従って、イベントをリスンするカスタム イベント リスナを作成します。
デフォルトでは、行動追跡イベントのプロパティ値は XML としてデータベースに保存されます。Event Service は、行動追跡イベントのタイプごとに特定の XML スキーマを使用して XML を作成します。カスタム行動追跡イベントを作成するときは、Behavior Tracking Service が使用する XML スキーマも作成する必要があります。
カスタム行動追跡イベントの XML スキーマを作成するときは、スキーマとイベント クラス間の次の接続ポイントを考慮します。
localSchemaKeys[] 配列にリストされている順序と一致する必要があります。http://edocs.bea.com/wlp/docs81/interm/src/sample_events.zip ファイルのサンプル XSD ファイル ResourceDisplayedEventBT.xsd を参照することもできます。
XSD の大部分は定型表現です。単に targetNamespace と xmlns= 属性の値を目的のネームスペースに変更し、カスタム イベント属性に順に追加します。
weblogic81\p13n\lib\p13n_ejb.jar に定義されている WebLogic Portal 用の XSD を参照できます。
イベントにユーザが関係しない場合があります。このような場合は、XSD ファイルの user-id 属性に対して atminOccurs="0" を使用します。次に例を示します。
<xsd:element ref="user-id" minOccurs="0"/>
スキーマを作成した後、次の手順に従って、ポータル アプリケーションの p13n_ejb.jar ファイルに追加します。
スキーマが JAR ファイルに追加されます。p13n_ejb.jar を再デプロイします。
イベント リスナの目的は 1 つしかありません。それは、リスンしているイベントが発生したときに、何らかのプログラム機能を実行することです。WebLogic Portal には、イベントを特別な方法で処理する次の 2 つのリスナが用意されています。
wps.jar の listeners.properties ファイルで無視するように設定されたイベントを除く) をリスンし、Campaign Service を呼び出して評価を行い、キャンペーン アクションをトリガします。カスタム行動追跡イベントを作成して登録した場合、そのイベントは BehaviorTrackingListener と CampaignEventListener によって処理されます。カスタム標準イベントを作成した場合、そのイベントは CampaignEventListener によって処理されます。
ただし、イベントのタイプがカスタム イベントか WebLogic Portal の定義済みイベントかにかかわらず、イベントが発生したときに、よりプログラム的な機能を実行したい場合があります。たとえば、イベント データをファイルや別のデータベース テーブルに永続化したり、ユーザが商品イメージをクリックしたときに関連情報を表示したり、ユーザがフォームを送信したときにユーザのプロファイルを変更したりする場合です。このような種類の機能を追加するには、カスタム イベント リスナを作成する必要があります。
WebLogic Portal には、EventListener と呼ばれる基本イベント リスナ オブジェクトが用意されています。カスタム リスナで実装する必要があるこの基本クラスは、イベントをリスンし、それに対応するために次の 2 つのメソッドを提供します。
getTypes() - リスナがリスンするイベントのタイプを Event Service に通知します。handleEvent() - リスナがリスンすべきイベントを受信したときに実行するカスタム機能を挿入できます。この節では、1 つまたは複数のイベントをリスンするカスタム リスナを記述する方法について説明します。リスナは、標準イベントまたは行動追跡イベント、あるいはその両方をリスンできます。
注意 : http://edocs.bea.com/wlp/docs81/interm/src/sample_events.zip ファイルのサンプル イベント リスナ customEventListener.java を参照することもできます。
public class MyEventListener
implements EventListener
{
private String[] eventTypes = {"MyEvent", "ClickContentEvent"};
public MyEventListener()
{
}
public String[] getTypes()
{
return eventTypes;
}
public void handleEvent( Event ev )
{
//ここにカスタム コードを入力する。
//イベントが発生すると、このコードが実行される。
}
}
javac -classpath D:\bea\weblogic\<portalApp>\p13n_ejb.jar MyEventListener.java
イベントとリスナの準備ができたら、JSP、Java コード、およびページ フロー内でイベントを生成またはディスパッチできます。イベントのディスパッチとは、イベント オブジェクトが Event Service からイベントをリスンしているリスナに送信されることです。イベント オブジェクトを受信したリスナは、独自の方法でイベントを処理します。
http://edocs.bea.com/wlp/docs81/interm/src/sample_events.zip に用意されているサンプル イベントの ResourceDisplayedEventBT は、book.jsp と page.jsp という 2 つのポータル フレームワーク スケルトン JSP ファイルからディスパッチされます。book.jsp スケルトンは、ポータル ブックの表示とページのナビゲーション (タブなど) を処理し、page.jsp スケルトンは、ポートレットが表示される領域を提供します。
これらのファイルには、コード リスト 6-1 に示すコードが挿入されています。このサンプルでは、page.jsp のコードを使用しています。このコードは、ポートレットがページに表示されたときに ResourceDisplayEventBT イベントをディスパッチします。
コード リスト 6-1 page.jsp からのイベントのディスパッチ
<%@ page import="com.bea.p13n.tracking.TrackingEventHelper,
examples.events.ResourceDisplayedEventBT" %>
...
ResourceDisplayedEventBT rde;
...
rde = new ResourceDisplayedEventBT( ppc.getLabel(), // resourceId,
portletTitle, // resourceLabel
"portlet", // resourceType
sessionId,
userId,
"true", // ポートレットを表示する
request,
session );
...
TrackingEventHelper.dispatchEvent( rde );
TrackingEventHelper をインポートします。rde が割り当てられます。TrackingEventHelper.dispatchEvent( rde ) メソッドによってイベントが Event Service にディスパッチされます。イベントは、そのイベントを受信するように登録されたリスナに送信され、リスナがイベントを独自の方法で処理します。図 6-1 に、イベントのライフサイクルを示します。スケルトン JSP は、この図の項目 2 に該当します。
「スクリプトレットを使用したイベントの作成」では、イベント クラスを作成していないイベントをディスパッチする方法についても説明しています。
コンテンツがクリックされたときにイベントをディスパッチする場合は、「コンテンツのクリックに対応したイベントの生成」で説明している特別な手順に従う必要があります。
定義済みイベントの一部には、独自のディスパッチ メソッドがあります。「WebLogic Portal で提供される定義済みイベント」を参照してください。
イベントを使用して Campaign Service をアクティブ化し、イベントとイベントの属性値に基づいてキャンペーン アクションをトリガすると、より強力なキャンペーンを実装できます。
キャンペーンでイベントを使用するために、Campaign Service に対してイベントを明示的に通知する必要はありません。キャンペーン リスナは、wps.jar の listeners.properties ファイルで明示的に除外されたイベント以外のすべてのイベントをリスンします。
キャンペーン リスナがリスンしているイベントが発生した場合、リスナは Campaign Service を呼び出します。Campaign Service は、現在の要求のスナップショットを作成し、ユーザが定義したすべてのキャンペーン ルールに照らして要求データを評価し、アクションを実行する必要があるかどうかを確認します。
さらに、別の方法でイベントをキャンペーンに使用できます。キャンペーン アクションの一部として使用する方法です。たとえば、ユーザがポータルでホーム ページをクリックしたときにのみパーソナライズされたコンテンツを表示するキャンペーン アクション (何らかのページ クリック イベントによってトリガされる) を定義できます。イベントをキャンペーン定義の一部として使用するには、「キャンペーン用のイベントの登録」の説明に従って、イベント プロパティ セットを作成する必要があります。
図 6-4 に、キャンペーン定義でのイベントの使用例を示します。この例では、イベントが特定のプロパティ値 (特性) を持つ場合に、キャンペーン シナリオがトリガされます。キャンペーン シナリオに [イベントが特定の特性を備えている] を追加し、キャンペーン エディタで [特性] リンクをクリックすることで、イベント プロパティを選択し、キャンペーン アクションの発生をトリガするプロパティ値を決定できます。作成されたイベント プロパティ セットによって、プロパティの選択が可能になります。
図 6-4 イベントを使用したキャンペーン シナリオのトリガ
キャンペーンに最大限の制御を行う場合、たとえば表示されるパーソナライズされたコンテンツを厳密に制御する場合は、厳密な制御を実施するアプリケーションの主要な場所に、キャンペーン アクションをトリガするイベントを作成します。パーソナライズされたコンテンツの制御の詳細については、このガイドの「プレースホルダ」の章の「プレースホルダでのデフォルト クエリとキャンペーン クエリの併用」を参照してください。
キャンペーンの作成の詳細については、このガイドの「キャンペーン」の章を参照してください。
キャンペーンをトリガするカスタム イベントを使用する場合は、イベント プロパティ セットを作成する必要があります。イベントに対して作成するプロパティは、イベント クラスで定義した属性名と一致します。
たとえば、サンプルの ResourceDisplayedEvent クラスでは、resourceId、resourceLabel、resourceType、session-id、user-id、および resourceSelected の各プロパティを使用します。作成するイベント プロパティ セットには、これらの属性のいずれか、またはすべてのプロパティを定義できますが、プロパティ名はイベントの属性名と正確に一致している必要があります。
イベント プロパティ セットの作成に関する手順については、WebLogic Workshop ヘルプ システムの「カスタム イベントを登録する」を参照してください。
アプリケーションをデプロイした後にイベント プロパティ セットを作成、変更、または削除した場合は、WebLogic Portal Datasync Web アプリケーションを使用してデータベース内のプロパティ セット定義を更新する必要があります。Datasync Web アプリケーションの詳細については、『プロダクション業務ユーザーズ ガイド』を参照してください。
Event Service をデバッグするには、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
|
|
|
