| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Portal > 開発者ガイド > パーソナライゼーションおよび対話管理のセットアップ |
|
開発者ガイド
|
パーソナライゼーションおよび対話管理のセットアップ
WebLogic Portal には、堅牢な認証機能とパーソナライゼーション機能が用意されており、それを利用することで、管理者は、どのようなコンテンツを訪問者が操作できるか、そしてその情報が特定の訪問者にどう表示されるかを決定することができます。また、訪問者が自ら WebLogic Portal のパーソナライゼーション機能を利用して、自分専用のコンテンツを選択したり、独自のルック アンド フィール（見た目と使い心地）を作成することもできます。Advisor、ルール フレームワーク、コンテンツ セレクタなどのツールを用いて、そうした認可とパーソナライゼーションを実現するリソースを作成することが、ポータル開発プロセスの主要な要素になります。
この章では、以下の内容について説明します。
Advisor を用いたポータル アプリケーションのパーソナライズ
WebLogic Portal Advisor は、パーソナライズされたコンテンツ、ユーザのセグメント化、および基礎となるルール エンジンといったパーソナライゼーション サービスを利用するための、使いやすく柔軟性に富んだアクセス ポイントです。Advisor は、一連のルールとユーザ プロファイル情報に基づいて、パーソナライズされたアプリケーションにコンテンツを配信します。 また、ドキュメント管理システムから任意のタイプのコンテンツを取得し、JSP 内に表示することができます。
Advisor は、システム内のサービスとコンポーネントをすべて連携させ、パーソナライズされたコンテンツを配信します。Advisor コンポーネントとしては、WebLogic Portal の以下の中核的パーソナライゼーション サービスにアクセスする JSP タグ ライブラリと Advisor EJB（ステートレス セッション Bean）があります。
このタグ ライブラリとセッション Bean には、これらのサービスにアクセスしたり、パーソナライゼーション アクションの実行順序を決定したり、パーソナライズされたコンテンツをアプリケーションに返すためのパーソナライゼーション ロジックが組み込まれています。 また、独自の Advisor プラグインを作成し、独自に作成した JSP タグを使ってそれらにアクセスすることも可能です。
このアーキテクチャによって、JSP 開発者は Advisor JSP タグを使ってパーソナライゼーション サービスを利用できるようになります。 さらに Java 開発者は、Advisor Bean の公開インタフェースを通じて、基礎となる WebLogic Portal のパーソナライゼーション機能にアクセスすることができます。詳細については、『WebLogic Portal Javadoc API マニュアル 』を参照してください。
Advisorの使い方は以下の 2 通りあります。
Advisor JSP タグを用いて、パーソナライズされたポータル アプリケーションを作成する
Advisorには、パーソナライズされたアプリケーションを開発者が作成するのに役立つ JSP タグが 3 つ用意されています。表12-1 ではそれらについて説明します。これらのタグを用いれば、JSP から Advisor セッション Bean を利用することができ、開発者は Java ソース コードを書かなくても、パーソナライズされたデータを取得するページを作成できるようになります。
パーソナライズされたアプリケーションを作成する手段としては、JSP タグを用いるだけでなく、Advisor Bean を直接扱うこともできます。Advisor Bean の使い方の詳細については、 Advisor セッション Bean を用いて、パーソナライズされたアプリケーションを作成するを参照してください。 <pz:div> JSP タグでユーザを分類する <pz:div> タグは、ユーザから提供されるコンテンツの有効/無効を、分類ルールの実行結果に基づいて切り替えます。分類ルールの結果が true の場合にはコンテンツが有効になり、false の場合にはコンテンツが無効になります。 注意: ルールは、E-Business Control Center で作成します。E-Business Control Center を利用すれば、ユーザは独自の分類ルールを作成することができます。 ユーザがルールの概念を知る機会はないため、E-Business Control Center では、分類ルールは「顧客セグメント」と呼ばれます。 リスト 12-1 では、<pz:div> タグを用いて PremierCustomer という分類ルールを実行する方法を示すとともに、主要顧客へのお知らせを HTML ページの出力に表示します。 コード リスト 12-1 <pz:dev> による分類ルールの実行 <pz:contentQuery> JSP タグを用いてコンテンツを選択する <pz:contentQuery> タグを用いれば、コンテンツ管理システム内のコンテンツを、コンテンツ属性に基づいて検索することができます。このタグは、開発者がさまざまな方法で扱える Content オブジェクトの配列を返します。 リスト 12-2 に示すのは、コンテンツ管理システムに対してクエリを実行して、author 属性が「Hemingway」であるコンテンツをすべて検索したあと、見つかった Document のタイトルを表示する方法の例です。 コード リスト 12-2 CMS に対してクエリを実行して指定のコンテンツを見つける方法 <pz:contentSelector> JSP タグを用いてコンテンツをユーザに合わせる <pz:contentSelector> タグは、コンテンツ セレクタ ルールの分類部にユーザが一致すれば、推奨コンテンツを返します。ルールの条件にユーザが一致すると、 Advisor はそのルールに定義されているクエリを実行して、コンテンツを検索します。 リスト 12-3 に示す例では、主要顧客向けのコンテンツを Advisor に要求したあと、その結果としてドキュメント (Document) のタイトルを表示します。 コード リスト 12-3 Advisor に特定顧客向けのコンテンツを要求する方法 Advisor セッション Bean を用いて、パーソナライズされたアプリケーションを作成する Java 開発者は、一連の API を通じて Advisor Bean を直接操作して、パーソナライズされたアプリケーションを作成することができます。この方法は、JSP タグを用いて Advisor Bean を呼び出す方法の代わりとなるものです。 注意: このセッション Bean を用いてパーソナライズされたアプリケーションを作成する方法の詳細については、『WebLogic Portal Javadoc』を参照してください。 以下の手順は、アプリケーションで推奨コンテンツを Advisor から得る際に行われるプロセスの概要を示します。
<%@ taglib URI="pz.tld" prefix="pz" %>
.
.
.
<pz:div
rule="PremierCustomer">
<p>Please check out our new Premier Customer bonus program…</p>
</pz:div><%@ page import="com.bea.p13n.content.ContentHelper"%>
<%@ taglib URI="pz.tld" prefix="pz" %>
.
.
.
<pz:contentQuery id="docs" contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>" query="author = 'Hemingway'" /><ul>
<es:forEachInArray array="<%=docs%>" id="aDoc"
type="com.bea.p13n.content.Content">
<li>The document title is: <cm:printProperty id="aDoc"
name="Title" encode="html" />
</es:forEachInArray>
</ul><%@ page import="com.bea.p13n.content.ContentHelper" %>
<%@ taglib URI="cm.tld" prefix="cm" %>
<%@ taglib URI="pz.tld" prefix="pz" %>
<%@ taglib URI="es.tld" prefix="es" %>
.
.
.
<pz:contentSelector id="docs"
rule="PremierCustomerSpotlight"
contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>" />
<ul>
<es:forEachInArray array="<%=docs%>" id="aDoc"
type="com.bea.p13n.content.Content">
<li>The document title is: <cm:printProperty id="aDoc"
name="Title" encode="html" />
</es:forEachInArray>
</ul>
パーソナライズされたアプリケーションから Advisor にアドバイスを要求すると、Advisor Bean は、そのリクエストを処理できる登録済みアドバイズレットにそのリクエストを委託します。 Advisor では、その URI 接頭辞を用いて、アドバイス リクエストを受信する登録済みアドバイズレットを決定します。選ばれたアドバイズレットはアドバイスを行い、Advice オブジェクトを Advisor に返します。 この設計では、アドバイスに関するロジックがすべてアドバイズレットにカプセル化されているので、開発者は、より特化した目的に合うカスタム アドバイズレットを作成することができます。
属性オブジェクトはリクエストのパラメータの役目を果たします。 属性オブジェクトは AdviceRequest オブジェクトに対して設定することができ、属性の名前を表す String オブジェクトに関連付けられます。
システムには、Classifier、ContentQuery、および ContentSelector の 3 つのアドバイズレットが用意されています。 用意されているアドバイズレットに設定しなければならない属性の名前は、AdviceRequestConstants インタフェースに static String として定義されています。
アドバイス リクエストをアドバイズレットにマップする方法を決定するのに Advisor で用いられるロジックを表12-2 に示します。
以下の各節では、Advisor に直接アクセスして、JSP タグに用意されているのと同じ機能を実現する方法を示します。 Advisor セッション Bean を用いてユーザを分類する 分類に関する要求が JSP タグで対応できる範囲を越えている場合や、分類をサーブレットで用いる場合には、Advisor EJB を直接使用します。 Advisor に分類を要求するには、以下の手順に従います（API の詳細については、『Javadoc API マニュアル』を参照してください）。 注意: 特に断らないかぎり、ここで用いられるクラスはすべて、com.bea.p13n.advisor パッケージに入っています。
注意: AdviceRequest の省略可能パラメータ RULES_RULENAME_TO_FIRE を省略した場合には、そのユーザに関して複数の分類が返されることがあります。
Advisor セッション Bean を用いてコンテンツ管理システムにクエリを発行する
コンテンツ選択に関する要求が JSP タグで対応できる範囲を越えている場合や、コンテンツ選択をサーブレットで用いる場合には、開発者は Advisor EJB を直接使用することができます。
Advisor にコンテンツを要求するには、以下の手順に従います（API の詳細については、『Javadoc API マニュアル』を参照してください）。
注意: 特に断らないかぎり、ここで用いられるクラスはすべて、 com.bea.p13n.advisor パッケージに入っています。
Advisor セッション Bean を用いてコンテンツをユーザに合わせる
コンテンツ選択に関する要求が JSP タグで対応できる範囲を越えている場合や、コンテンツ選択をサーブレットで用いる場合には、開発者は Advisor EJB を直接使用することができます。
Advisor にコンテンツを要求するには、以下の手順に従います（API の詳細については、『Javadoc API マニュアル』を参照してください）。
注意: 特に断らないかぎり、ここで用いられるクラスはすべて、 com.bea.p13n.advisor パッケージに入っています。
ルール フレームワークの取り扱い
ルール管理は、ビジネス ルールを表現するための柔軟かつ強力なメカニズムを規定することで、パーソナライゼーション プロセスの主要な部分となります。これらのルールに組み込まれているビジネス ロジックのおかげで、それぞれのエンド ユーザ タイプ向けのパーソナライズされたコンテンツを確実に配信することが可能になります。
ルール フレームワークのさまざまなコンポーネントのコンフィグレーションは、rules.properties という外部コンフィグレーション ファイルを用いて行います。 このファイルは、どの WebLogic Portal アプリケーションでも、そのルート ディレクトリ内の p13n_util.jar ファイル（com/bea/p13n/rules ディレクトリ内）に入っています。この節では、このファイルで設定できる各コンフィグレーション プロパティについて説明します。
rules.properties ファイルへの変更は、そのファイルを持つアプリケーションからのみ参照されます。すなわち、このコンフィグレーション ファイルのスコープはそのアプリケーションに限定されています。これによって、ルール フレームワークのコンフィグレーションをアプリケーションごとに変えることが可能になります。
ルール式を検証する
ルール エンジンにすべてのルール式（条件とアクションの両方）をちょうど 1 回だけ検証させたい場合には、rules.engine.expression.validation を true に設定します。開発時やテスト時には、リスト 12-4 に示すようにこのプロパティを true に設定して、新たに加えた式を検証することができます。
コード リスト 12-4 rules.engine.expression.validation プロパティの設定
##
# ルール エンジンによる式の検証:
#
# このプロパティが true に設定されている場合、
# ルール エンジンは、式が最初に実行されるときに
# それらを検証する。
##
rules.engine.expression.validation=true
ルール エンジンによるエラーの処理と報告
ルール エンジンの実行中にユーザに通知される例外のタイプは、rules.engine.throw.expression.exceptions プロパティと rules.engine.ignorable.exceptions プロパティによって決まります。
これらのパラメータの設定例をリスト 12-5 に示します。
コード リスト 12-5 ルール エンジンによるパターン式実行時のエラー処理
##
# ルール エンジンによるパターン式実行時のエラー処理:
#
# rules.engine.throw.expression.exceptions
#
# このプロパティが true に設定されている場合には、
# パターン式実行例外が送出される。それ以外の場合には、
# パターン式例外が発生するとパターン条件が偽（false）と
# 評価される。
#
# デフォルトは true。
#
# rules.engine.ignorable.exceptions （クラス名のリスト）
#
# 上記のプロパティが true に設定されていると、
# 列挙されたクラス以外のタイプの式例外および
# 組み込み例外が送出される。クラス タイプが何も
# 指定されていなければ、すべての式例外が送出される。
#
# デフォルトは、すべての例外クラス タイプ。
##
rules.engine.throw.expression.exceptions=true
rules.engine.ignorable.exceptions=java.lang.NullPointerException
コンテンツ セレクタを用いたパーソナライゼーション
コンテンツ セレクタは、コンテンツ管理システムからドキュメントを取得するためのメカニズムとして WebLogic Portal に用意されているものの 1 つです。 コンテンツ セレクタを使用すれば、ドキュメントが WebLogic Portal で取得される際の条件を指定することで、ポータルやポートレットをパーソナライズすることができます。たとえば、 日付の範囲、ユーザのステータス、ユーザの電子メール アドレスなどの情報を指定することで、コンテンツ管理システム内のデータを表示するポートレットをパーソナライズすることができます。コンテンツ セレクタなら、選択条件に合うドキュメントだけを取得することになるでしょう。
注意: コンテンツ セレクタを扱うには、その前に顧客セグメントを作成しておく必要があります。セグメントの作成は管理作業であり、『管理者ガイド』で説明されています。詳細については、「顧客セグメントの作成」 (http://edocs.beasys.co.jp/e-docs/wlp/docs70/admin/usrgrp.htm#1184110) を参照してください。
E-Business Control Center を用いて、コンテンツ セレクタを起動する条件を定義するとともに、コンテンツ セレクタでドキュメントの検索と取得に使用されるクエリを定義します。そのあと、コンテンツ セレクタ JSP タグとその他の一連の JSP タグを用いて、コンテンツ セレクタで絞り込まれたコンテンツを取得し表示します。
E-Business Control Center を用いて、コンテンツ セレクタを起動する条件と、クエリ条件を定義するには、以下の手順に従います。
図12-1 E-Business Control Center の [新規作成] メニューで [コンテンツ セレクタ] を選択
図12-3 [Selection Rule] エディタ
図12-4 条件選択時の [Selection Rule] エディタ
図12-5 [顧客セグメントの選択] ダイアログ ボックス
これで、新しいコンテンツ セレクタがいつでも使用できるようになりました。
与えられた JSP でコンテンツ セレクタ機能を使用するには、コンテンツ セレクタ JSP タグと一連の関連タグを呼び出す必要があります。詳細については、コンテンツ セレクタ タグおよび関連する JSP タグの使い方を参照してください。
編集 JSP を用いたポートレットのパーソナライズ
訪問者は、必要なパーソナライゼーション属性や好みの設定を編集 JSP に記述することで、ポートレットをパーソナライズすることができます。編集 JSP とは、パーソナライゼーション データを収集し、それを用いて、要求されたデータをパーソナライズした形で表示する JSP のことです。
編集 JSP を用いて訪問者側からポートレットをパーソナライズできるようにするには、以下の 2 つのステップを実行します。
ステップ 1: 編集 JSP を作成する
他の JSP を作成するのと同じようにして、編集 JSP（Webflow が必要な場合には複数の JSP）を作成します。その名前は自由に付けることができ、ルック アンド フィールは、適切でさえあれば、どのようなものでもかまいません。この JSP の重要な機能は、パーソナライズされたコンテンツを訪問者側から入力したり検索できるようにする機能です。
たとえば、
これでわかるように、訪問者パーソナライゼーションの要件を満たしているかぎり、編集 JSP に組み込むべき内容にはほとんど制限はありません。
ステップ 2: ポートレットの編集を有効にする
次に、訪問者側でポートレットを編集してパーソナライゼーション情報を追加できるようにする必要があります。それには、以下の手順に従います。
図12-7 [編集を有効にする] チェックボックスが選択されているポートレット エディタ
ポートレット エディタの使い方の詳細については、『管理者ガイド』の「ポートレットの特性の変更」 (http://edocs.beasys.co.jp/e-docs/wlp/docs70/admin/frmwork.htm#1199768) を参照してください。
プレースホルダを用いたポータルまたはポートレットのパーソナライズ
プレースホルダは、表示可能なコンテンツを定義する特定の条件が満たされたときにコンテンツが表示される、ポータルまたはポートレット内の領域を表す手段です。プレースホルダは、任意の数のクエリが組み込まれた名前付きエンティティです。プレースホルダ タグが含まれた JSP を訪問者が要求すると、プレースホルダは（通常、設定されたルールや顧客プロパティに基づいて）単一のクエリを選択して実行し、ブラウザでのクエリ結果の表示に必要になる HTML を生成します。
この節では、以下のトピックを扱います。
プレースホルダの使い方
プレースホルダは、主にキャンペーンで使用され、訪問者の行動から訪問者が興味を持っていると判断される催しや商品などの情報に訪問者の注意を向けさせる働きをします。たとえば、オンラインのスポーツ用品店が、ある訪問者が特定のメーカーのルアー（釣りの擬似餌）を多数購入したことに気づいたとしましょう。あるルールが存在し、そこには、訪問者がそのメーカーの商品を一定額以上購入したときに、利用可能な割引についての情報をポータルに表示するよう指示してあります。その訪問者には、そのコンテンツのプレースホルダに指定された領域に、その情報が表示されることになります。また、別の訪問者が、キャンプ用具に興味を示しています（その訪問者が上記スポーツ用品店のカタログの「キャンプ」ページにアクセスした回数から判断される）。キャンプ好きの訪問者には、ルアーの割引ではなくキャンプ用具についての情報が、プレースホルダに指定された領域に表示されることになります。
上記の例は、情報を特定の訪問者向けにパーソナライズするための広告プレースホルダの使い方を示しています。同様に、広告以外のプレースホルダでも、同じレベルのパーソナライゼーションを提供することができます。たとえば、ある医師が製薬会社の Web サイトで薬品の調査を行っていて、その医師には特定の薬品群を調べる傾向があるとしましょう。その会社のポータルでは、その医師の行動を追跡して、医師がまだ調査していない関連薬品についての情報またはリンクをプレースホルダに表示することができます。
プレースホルダの作成は、JSP タグを使用し、E-Business Control Center でプレースホルダ クエリを定義することで行います。この節では、ポータルおよびポートレットのコンテンツをパーソナライズするためのプレースホルダを、これらの機能を用いてセットアップする方法を説明します。
プレースホルダ JSP タグ: <ph:placeholder>
プレースホルダ タグ <ph:placeholder> は、JSP 上にある、名前付きの位置です。 このタグは、JSP へのプレースホルダを識別し、E-Business Control Center で設定された動作を記述するものです。E-Business Control Center を用いてプレースホルダの動作をセットアップする方法については、プレースホルダ ファイルを作成する を参照してください。
注意: 以下の表の「必須」列では、属性が必須と省略可能のどちらであるかを「はい」または「いいえ」で示します。「R/C」列では、「C」は属性がコンパイル (Compile) 時表現であることを、「R」は属性が要求 (Request) 時表現とコンパイル時表現のいずれかであることを示します。
<ph:placeholder> タグ（表12-3）はプレースホルダを実装し、そのプレースホルダは、JSP ページ上のある位置での動作を記述します。
複数のプレースホルダ タグが同じプレースホルダを参照していてもかまいません。 プレースホルダ タグの各インスタンスは、それぞれのプレースホルダ定義を個別に呼び出します。 プレースホルダ定義で複数のクエリが指定されている場合には、たとえプレースホルダ タグの各インスタンスの定義が同じでも、インスタンスごとに異なる広告を表示することができます。
広告プレースホルダを含んだ JSP へのリクエストを WebLogic Portal が受信すると、プレースホルダ タグは AdService（ビジネス ロジックを呼び出して、表示すべき広告を決定するセッション EJB）に問い合わせます。
例 この例では、MainPageBanner プレースホルダで指定された広告を表示します。 プレースホルダを実装する プレースホルダを実装するには、以下の手順に従います。
<%@ taglib uri="ph.tld" prefix="ph" %>
. . .
<ph:placeholder name="/placeholders/MainPageBanner.pla"/>
<BEA_HOME>¥weblogic700¥samples¥portal¥<PORTAL_DOMAIN>¥beaApps¥
<PORTAL_APP>¥<PORTAL_APP>¥portlets¥campaigns
<%@ taglib uri="ph.tld" prefix="ph" %>
コード リスト 12-6 <ph:placeholder> タグ
<table class="homebackground" width="100%" height="100%"
border="0" cellspacing="0" cellpadding="0">
<tr>
<td align="center">
<ph:placeholder name="PrimaryCampaign"/>
</td>
</tr>
</table>
プレースホルダ ファイルを作成する
サイトの JSP に記述されているプレースホルダに合致するプレースホルダ ファイルを定義するには、E-Business Control Center を用います。以下の手順では、E-Business Control Center でプレースホルダ ファイルを作成する方法と、そのプレースホルダ内にデフォルト（キャンペーン以外）のクエリをセットアップする方法を示します。
注意: この手順を開始する前に、コンテンツ管理システム内のドキュメントの属性を定義しておく必要があります。
プレースホルダ ファイルを作成するには、以下の手順に従います。
図12-8 プレースホルダ エディタ
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
