ポータル アプリケーションでのルールの使用
![]() |
![]() |
![]() |
![]() |
WebLogic Portal には、ポータル アプリケーションでユーザが行う操作をパーソナライズするための強力なツール セットが用意されています。各ユーザがブラウズするコンテンツや受信する自動電子メール メッセージをはじめ、コマース アプリケーションで各ユーザに適用される割引の種類などを、動的かつ的確に制御できます。このようなパーソナライゼーションの成果を達成するには、WebLogic Portal に付属する WebLogic Workshop の各種デザイナで、ユーザ セグメント、コンテンツ セレクタ、およびキャンペーンを作成します。これらのツールを用いたパーソナライゼーションの開発は簡単であり、Java を使用したコーディングもほとんど必要ありません (JSP タグのみを使用します)。このタイプのパーソナライゼーションは、開発後、ポータル管理者が WebLogic Administration Portal を使用して動作を修正することができ、コーディングはまったく必要ありません。
しかし、より強力で柔軟性のあるパーソナライゼーションの開発が必要となる場合もあります。たとえば、パーソナライゼーションを使用してページフローから各ユーザのパスを制御したり、実行時情報を動的な入力としてコード内の条件付きロジックに使用するなどが考えられます。このガイドでは、このような高度なパーソナライゼーションの開発について詳しく説明します (ユーザ セグメント、コンテンツ セレクタ、およびキャンペーンを使用したパーソナライゼーションの作成手順については、WebLogic Workshop のオンライン ヘルプを参照してください)。
高度なパーソナライゼーションを開発するには、XML とスキーマ (上級者向けの DTD) による作業経験があり、Java 開発について中級レベルの知識を持っていることが必要です。
このガイドでは、WebLogic Portal のルール サービスを使用して高度なパーソナライゼーションを開発する方法を説明します。
ルール サービスには、ルール コントロールと RulesManager EJB の 2 つのコンポーネントを使用してアクセスできます。ページフローまたは Web サービス内で使用できるルール コントロール (Rules Executor コントロールと Rules Manager コントロール) は、コードを記述せずにルールの機能をアプリケーションに追加できる便利な手段を提供します。たとえば、ドラッグアンドドロップ インタフェースを使用してページフローにルール コントロールを追加し、そのコントロールに使用するメソッドを選択してから、WebLogic Workshop のプロパティ エディタでコントロールをコンフィグレーションすることができます。
基盤となる RulesManager EJB に呼び出しを委託するルール コントロールは、ルール サービスとの基本的な対話手段となります。ただし、ページフローまたは Web サービス以外の場所でルール サービスを使用する場合は、コード内で RulesManager EJB を直接使用して、ルール サービスにアクセスできます。
次の表は、WebLogic Portal に用意されているパーソナライゼーション ツールの一覧です。このガイドでは、ユーザ セグメント、キャンペーン、コンテンツ セレクタ、およびパーソナライゼーション用の各 JSP タグについては詳しく説明しませんが、この表では、ルール サービスに直接アクセスする場合のプログラム能力がどのように強化されたかを強調するために、比較の目的で掲載しています。入力オブジェクトとアクションの列は、ルール コントロールと RulesManager EJB を使用することによって柔軟性と機能が強化されることを示しています。
このガイドは、WebLogic Portal のルール コントロールおよび RulesManager EJB を使用して、アプリケーションにパーソナライゼーションを追加する方法に焦点を置いています。ユーザ セグメント、キャンペーン、コンテンツ セレクタ、およびパーソナライゼーション JSP タグを使用したパーソナライゼーションの開発には、ルール サービス アーキテクチャから抽象化された使いやすいユーザ インタフェースが必要となります。この開発の詳細については、WebLogic Workshop のオンライン ヘルプを参照してください。
ルール サービスは、作業メモリに配置されているオブジェクトを読み込み、それらを XML ファイルに定義されている一連のルールと比較して評価します (「作業メモリ」は、ルール サービスでルールが処理される間、オブジェクトを一時的に格納する場所と考えてください)。メモリ内のオブジェクトが、ルール セットに定義されている条件 (複数のルールで構成することもできます) と一致すると、ルール セットに定義されているアクションが実行されます。たとえば、ユーザ プロファイルや、Web サービスの計算結果などから取得したユーザの信用度スコアを作業メモリに配置した場合、ルール セット内のルールとして、「ユーザの信用度スコアが 10 点以上であれば、そのユーザをゴールド カスタマとして分類する」などと定義することができます。ルールは XML 形式で記述します。このルール処理の結果は、さまざまな方法でアプリケーションに使用できます。たとえば、ページ フローを開発している場合は、「ゴールド カスタマ」だけを gold.jsp
ファイルに送信し、残りのすべてのカスタマを別の JSP ファイルに送信することができます。
注意 : Rules Manager コントロールは、ルールの開発デバッグ ツールとして使用すると非常に便利です。
ルール サービスは、前向き推論用に最適化されている Rete アルゴリズムに基づいています。ルールの評価プロセスは、以下の順序で実行されます。このプロセスでは、Rules Executor コントロールを例として使用しています。
evaluate*()
メソッドに渡されます。図 1 は、Rules Executor コントロールをページフローに使用した前述のプロセスを基本的な図で表したものです。この図では、ルール サービス プロセスから返された結果を、ページフローからのユーザのパスを特定することに使用しています。また、この図では、分かりやすいように、コードの代わりに自然言語を使用しています (実際のページフローでのパラメータの設定とコントロールの呼び出しについては、「ページフローでコントロールを使用してユーザのパスを特定する」を参照してください)。
ルール サービスは、コードで使用される単純な条件文よりも動的に扱うことができます。Web アプリケーションや他のアプリケーション コンポーネントを条件文 (if/then) を使用してハード コード化した場合、条件文を変更するには、コードを再コンパイルし、アプリケーションを再デプロイするしか方法はありません。これに対してルールは、Portal サーバを実行したまま変更し、ロードすることができます。つまり、管理者は、ドメイン エキスパートからビジネス ロジックを取得して、そのロジックを反映するルール式を作成し、サーバを停止せずにルールをアプリケーションにロードすることができます。
この節では、ルール コントロールと RulesManager EJB を使用してパーソナライゼーションを開発する方法を説明します。この開発には、以下の手順が伴います。
ルール セットは、ルール サービスが作業メモリ内のオブジェクトの評価に使用する命令セットを、XML 形式で記述したものです。ルール セットは、基本的に、「作業メモリ内の~が以下の条件を満たしている場合、これを実行する」というように記述されます。
WebLogic Portal には現在のところルール エディタがないので、ルール セットは手作業で作成します。ルール セットは、特定のスキーマに準拠している必要があります (ルール セットのスキーマは、アプリケーションのルート ディレクトリの p13n_ejb.jar
にあります)。ルールの言語として実際に使用するのは、ルール サービスの追加要件を満たすように拡張された WebLogic Portal の式パッケージです(使用できる式の詳細については、「WebLogic Portal Javadoc」にある com.bea.p13n.expression.operator.*
の各パッケージを参照してください)。
ルール セットの XML ファイル (拡張子は .rls
) は、以下の必須の基本要素で構成されます。
次の例は、「文字列 'Make an Integer 10' が作業メモリにある場合、オブジェクト '10' を作業メモリに追加する」という単純なルール セットを示しています。
<?xml version="1.0" encoding="UTF-8"?>
<!-- 名前 (会社名) が XMLSPY v5 rel. 4 U (http://www.xmlspy.com) で編集 -->
<rule-set xmlns="http://www.bea.com/servers/p13n/xsd/rules/core/2.1.1" xmlns:exp="http://www.bea.com/servers/p13n/xsd/expression/expressions/2.1.1" xmlns:literal="http://www.bea.com/servers/p13n/xsd/expression/literal/1.0.1" xmlns:string="http://www.bea.com/servers/p13n/xsd/expression/string/1.0.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/servers/p13n/xsd/rules/core/2.1.1
rules-core-2_1_1.xsd" is-complete="true">
<rule is-complete="true">
<name>Add Integer</name>
<description>Test Rule</description>
<conditions>
<exp:equal-to>
<exp:variable>
<exp:type-alias>java.lang.String</exp:type-alias>
</exp:variable>
<literal:string>Make an Integer 10</literal:string>
</exp:equal-to>
</conditions>
<actions>
<add-object>
<exp:type-alias>java.lang.Integer</exp:type-alias>
<exp:arguments>
<literal:string>10</literal:string>
</exp:arguments>
</add-object>
</actions>
</rule>
</rule-set>
スキーマを解読することや、スキーマのルールに基づいて有効な XML を手作業で作成することに慣れている場合以外は、XMLSpy などの XML エディタを使用してください (XMLSpy は WebLogic Platform の製品 CD からインストールできます)。XML エディタには、1 つのスキーマだけでなく、そのスキーマによってインポートされるすべてのスキーマが読み込まれ、XML ドキュメントの指定の位置に追加できる要素と属性が表示されます。使用できる要素と属性が表示されるため、有効な XML ルール セットを作成しやすくなります。
注意 : ルール セットを作成する最も簡単な方法は、既存のルール セットを修正することです。dev2dev サイト (http://www.beasys.co.jp/dev2dev/products/wlportal81/articles/portalrulesservice.html) には、いくつかのルール セットのサンプルが掲載されています。
以下のガイドラインを使用して、XML エディタでルール セットを作成 (または既存のルール セットを修正) します。
XML 形式でルール セットを作成する前に、次のように自然言語でルールを書き出して、すべての条件とアクション、およびデータ型を理解してください。作業メモリには何を配置するか ?オブジェクトが満たさなければならない条件は何か ? 作業メモリ内のオブジェクトがそれらの条件を満たしている場合、何を (どのようなアクションを) 実行するか ?
lib/schema/expression*.xsd
lib/schema/rules*.xsd
XML エディタで新しいドキュメントまたは既存のドキュメントを開き、そのドキュメントに rules-core-2_1_1.xsd スキーマを関連付けます。このスキーマには、式のスキーマをはじめ、ルール セットの作成に役立つ他のスキーマのインポートも含まれています。
新規 XML ドキュメントの場合は、XML ヘッダが自動的に挿入されます。また、インポート用に指定されたすべてのスキーマが自動的にインポートされて、<rule-set>、<rule>、<name>、<conditions>、<actions> などの必須の基本要素が挿入されます。
次の図は、XMLSpy で作成されるルール セットを示しています。<exp:greater-than-or-equal-to> 要素を選択すると、子として追加できる要素が [Elements] ペインに一覧表示されます。[Attributes] ペインには、この要素に設定できる属性が表示されます。
無効なルール セットを修正する方法については、「無効なルール セットの修正」を参照してください。
次の表は、ルール セットの XML ドキュメントでメソッドを使用して、ユーザ プロファイルのプロパティ値を取得し、ルール サービスで評価できるようにする方法を示しています。
p13n_ejb.jar
の parser-mapping-type.properties
ファイルで定義されているオブジェクト タイプのマッピング リストについては、「タイプのマッピング」を参照してください。
ルール セットの妥当性が立証されなかった場合、そのルール セットが無効であることを示す領域が表示されます。この場合は、以下のように対応します。
.rls
ファイルで参照されているすべてのスキーマがインポートされたことを確認する。これらのスキーマは、*.rls ファイルの先頭に表示されます。これらのスキーマは、.rls
ファイルと同じディレクトリに配置されている必要があります。.rls
で定義されている XML セクションが、スキーマに準拠していることを確認する。XMLSpy でスキーマを開いて、.rls
がスキーマの定義に対して有効かどうかをチェックすることができます。XMLSpy では、スキーマをデザイン ビューに視覚的に表示することができます。.rls
は、テキスト ビューおよび拡張グリッド ビューに表示できます。この節では、デプロイメント (WebLogic Workshop) 環境、テスト環境、またはプロダクション環境にルール セットをデプロイする方法について説明します。
ルール セットを作成して、アプリケーションの META-INF/data
ディレクトリ (または、その下の META-INF/data/rulesets
などの作成したサブディレクトリ) に保存すると、サーバが稼動していれば、ルール セットは自動的にデプロイされます。サーバが稼動していない場合は、サーバを起動した時点で自動的にデプロイされます(META-INF/data
は DataSync ディレクトリと呼ばれ、ユーザ セグメント、コンテンツ セレクタ、キャンペーンなど、ユーザが作成した他のアプリケーション メタデータも保存されています)。ルール セットは DataSync ディレクトリにデプロイする必要があり、ルール セットのファイル名には、ルール サービスで識別されるように拡張子 .rls
を付ける必要があります。
DataSync ディレクトリのルール セットを修正すると、そのルール セットは、稼動中のサーバで自動的に更新されます。
デプロイ済みのアプリケーションに存在するルール セットに追加、修正、または削除を行う必要がある場合は、次の手順を実行します。
ルール セットは、作業メモリ内に評価するオブジェクトが存在しなければ意味を成しません。たとえば、ルール セットに含まれる 1 つのルールに、「ユーザの信用度スコアが 10 以上である場合」という条件が設定されているとします。この条件は、信用度スコアの入力値が存在すること、または信用度スコアを取得する方法が指定されていることを意味します。作業メモリには、以下の 2 つのいずれかの方法で信用度スコアを挿入できます。
コードには、次の例に示す直接的な方法、またはフォーム入力値などを使用した間接的な方法で、信用度スコアを簡単に追加できます。
Integer value = new Integer(10);
Object [] inputObjects = { value };
(evaluate*()
メソッドへの必須の引数)
この後に、「value」整数を評価するルールの条件を作成できます。
より柔軟かつ動的な方法は、ユーザ プロファイルから信用度スコアを取得する方法です。
まず、コードを使用してユーザ プロファイルを取得し、作業メモリに配置します。
ProfileWrapper pw = SessionHelper.getProfile(request);
Object [] inputObjects = { pw };
(evaluate*()
メソッドへの必須の引数)
次に、ルール セットに条件を作成します。この条件には、特定のプロパティ セット (CreditPropertySet) から特定のプロパティ (CreditScore) を取得するメソッド (getProperty) を使用します。以下は、表 2 で使用した例と同じものです。
<exp:greater-than-or-equal-to>
<literal:integer>10</literal:integer>
<exp:instance-method>
<exp:variable>
<exp:type-alias>User</exp:type-alias>
</exp:variable>
<exp:name>getProperty</exp:name>
<exp:arguments>
<literal:string>CreditPropertySet</literal:string>
<literal:string>CreditScore</literal:string>
</exp:arguments>
</exp:instance-method>
</exp:greater-than-or-equal-to>
この条件は、取得した CreditScore が、<literal:integer> 値の 10 以上であるかどうかをチェックします。
注意 : User
タイプは、実際には ProfileWrapper クラスのオブジェクトのエリアスになります。この User
と「ProfileWrapper」のマッピングは、他の既知のタイプのマッピングと共に、次の節で示す p13n_ejb.jar
の parser-mapping-type.properties ファイルで定義されています。
以下のオブジェクト タイプのマッピングは、p13n_ejb.jar
の parser-mapping-type.properties
ファイルで定義されています。
User=com.bea.p13n.usermgmt.profile.ProfileWrapper
Classifier=com.bea.p13n.user.Classification
Capability=com.bea.p13n.entitlements.common.Capability
Role=com.bea.p13n.entitlements.common.Role
Context=com.bea.p13n.rules.internal.engine.Context
Email=com.bea.campaign.rules.MailActionDef
Placeholders=com.bea.campaign.rules.AddAdToPlaceholderActionDef
Discount=com.bea.commerce.ebusiness.campaign.AddUserDiscountActionDef
EndScenario=com.bea.campaign.rules.EndScenarioActionDef
CatalogQuery=com.beasys.commerce.ebusiness.catalog.rules.CatalogQueryWrapper
ContentQueryAdvice=com.bea.p13n.content.advislets.ContentQueryAdvice
ShoppingCartFacade=com.beasys.commerce.ebusiness.shoppingcart.ShoppingCartRulesFacade
前述の例と 表 2 の例は、User
タイプでの <type-alias>
要素を示しています。
user=com.bea.p13n.usermgmt.profile.ProfileWrapper
request=com.bea.p13n.http.Request
session=com.bea.p13n.http.Session
event=com.bea.p13n.events.Event
randomNumber=java.lang.Number
classification=com.bea.p13n.user.Classification
date=com.bea.p13n.xml.schema.Date
time=com.bea.p13n.xml.schema.Time
timeInstant=com.bea.p13n.xml.schema.TimeInstant
role=com.bea.p13n.entitlements.common.Role
resource=java.lang.String
shoppingCart=com.beasys.commerce.ebusiness.shoppingcart.ShoppingCart
ルール セットを作成し、作業メモリにオブジェクトを配置したら、ルール サービスを呼び出して、作成したルールで作業メモリ内のオブジェクトを評価することができます。
この節では、サンプルを示しながら、ページフローで Rules Executor コントロールを使用してルール サービスを呼び出す方法について説明します。
この節を通して使用するサンプルでは、「ユーザ プロファイルから作業メモリに信用度スコアを追加する」で使用した例と同様に、ユーザ プロファイルを読み込むことによってユーザを「GoldCardMembers」または「SilverCardMembers」に分類するルール セットが、/data/rulesets
ディレクトリにすでに作成されていることを前提としています。この節のページフローのサンプルは、作業メモリに追加されるユーザ プロファイルを示しています。このサンプルにはユーザ プロファイルが必要となるため、既存のページフローには、ユーザ プロファイルのプロパティの取得および設定を可能にする Profile コントロールがすでに追加されているものとします。
また、このサンプルには、ページフローがどのユーザ プロファイルを取得するのかを識別できるように、認証用の User Login コントロールも使用されています。
ページフローを作成する方法については、WebLogic Workshop オンライン ヘルプの「ページフロー構築ガイド」を参照してください。ページフローにポータル コントロールを追加する方法については、WebLogic Workshop オンライン ヘルプの「Java ページ フローにポータル コントロールを追加する」を参照してください。
ページフロー (WebLogic Workshop の .jpf
ファイル) にコントロールを挿入すると、そのコントロールに定義されているすべてのアクション (メソッド) が使用可能になります。Rules Executor コントロールには、次の 2 つのアクションのいずれかを選択できます。
evaluateRule
- 作業メモリ内のオブジェクトを、ルール セットの 1 つのルールに対して評価できます。evaluateRuleSet
- 作業メモリ内のオブジェクトを、ルール セットのすべてのルールに対して評価できます。アクション ビューでページフローを開くと、コントロールの境界線を選択して挿入済みのコントロールを選択したり、図 3 に示すように、プロパティ エディタでそのコントロールのプロパティを設定することができます。
プロパティ エディタは、Java コードを記述せずに RulesManager EJB (ルール サービスへの直接的なインタフェース) に引数を渡すことのできる便利なツールです。
たとえば、表 3 は、図 3 に示す Rules Executor コントロールのプロパティが、RulesManager EJB のメソッドとコンストラクタの引数にどのようにマップされるかを示しています。
|
|
---|---|
|
|
|
|
|
|
|
RulesManager EJB には、Rules Executor コントロールに含まれるメソッドと同じメソッド (evaluateRule()
と evaluateRuleSet()
) があることに注意してください。相違点は、Rules Executor コントロールのメソッドの場合、evaluateRuleSet(Object[] inputObjects)
など、引数を 1 つしか取らず、ルールおよびフィルタの引数をコントロールのプロパティを通じて指定する点です。
Rules Executor コントロールでは、filterResults プロパティを「true」に設定すると、filter
引数を持つ EJB メソッドが使用され、ユーザが入力したフィルタのプロパティがその引数に自動的に渡されます。
filterClassName プロパティと filterClassNames プロパティは、ほぼ同じ機能を持つオプションとして、どちらも filter
引数の入力に使用されます (1 つのフィルタ タイプを指定するか、複数のフィルタ タイプを指定するかの違いだけです)。コントロールには、filterClassName か filterClassNames のどちらかを設定してください。両方設定することはできません。
実行されたルール セットの特定のルールの結果をフィルタ処理するには、filterRuleName プロパティを使用します。このプロパティを使用すると、RuleResultClassFilter
コンストラクタが呼び出されます。このコンストラクタは、単一クラスのフィルタ (filterClassName で入力) のプロパティ、または複数クラスのフィルタ (filterClassNames で入力) のプロパティのいずれかを使用するために、オーバーロードされることに注意してください。filterRuleName プロパティを使用すると、実行された特定のルールの結果だけでなく、特定のデータ型についてもフィルタ処理できます。
META-INF/data
ディレクトリを基準とした相対パスです。たとえば、myruleset.rls
というルール セットを作成して data/rulesets
ディレクトリに保存した場合、URI は /rulesets/myruleset.rls
になります。ルール セットとルールを一覧するには、Rules Manager コントロールを使用します。java.lang.String
など) を入力する。入力しない場合、結果はフィルタ処理されません。クラス名は、このプロパティまたは filterClassNames のどちらかで指定します。両方使用することはできません。java.lang.String,java.lang.Integer
など)。入力しない場合、結果はフィルタ処理されません。クラス名は、このプロパティまたは filterClassName のどちらかで指定します。両方使用することはできません。前の節では、各プロパティにメソッドとコンストラクタがどのようにマップされるかを説明しましたが、これにより、Rules Executor コントロールを使用することの利点を確認できます。プロパティ値を指定することによって、次のような利点があります。
Rules Executor コントロールの詳細については、com.bea.p13n.controls.rules.RulesExecutorControl にある Rules Executor コントロールの Javadoc を参照してください。
ページ フローに Rules Executor コントロールを追加してプロパティを設定し、コントロールの execute*
アクションから使用するアクションを選択して、他のすべての前提条件 (「サンプルの前提条件」を参照) が準備されたら、ルールの評価プロセスから返された分類に基づいてユーザに個別のページを表示するよう、ページフローに別のコードを追加することができます。
以下のサンプルのページフロー コードは、ルール サービスの実行結果に基づいてユーザに特定のページを表示する方法を示しています。同様のサンプルは、http://www.beasys.co.jp/dev2dev/products/wlportal81/articles/portalrulesservice.html にある dev2dev の「Portal のルール サービス」 (examples/pageFlows/classifyAndFlow
サブディレクトリ内) にも掲載されています。
public class Controller extends PageFlowController
{
/**
* @common:control
*/
private com.bea.p13n.controls.login.UserLoginControl userLoginControl;
/**
* @common:control
*/
private com.bea.p13n.controls.profile.ProfileControl myProfileControl;// Rules Executor コントロールを追加する。
// プロパティ エディタでプロパティをコンフィグレーションする。
// これらはすべて、ページフローのアクション ビューで実行する。
/**
* @common:control
* @jc:rules-executor filterClassName="com.bea.p13n.user.Classification"
filterResults="true" rulesetUri="/rulesets/myruleset.rls"
*/
private com.bea.p13n.controls.rules.RulesExecutorControl
myRulesExecutorControl;/**
// 最初に、ルール サービスの作業メモリに配置するオブジェクトを
* @jpf:action
* @jpf:forward name="default" path="default.jsp"
* @jpf:forward name="goldCard" path="goldCard.jsp"
* @jpf:forward name="silverCard" path="silverCard.jsp"
* @jpf:catch type="com.bea.p13n.controls.exceptions.P13nControlException" path="error.jsp"
* @jpf:forward name="error" path="error.jsp"
*/
protected Forward evaulateRuleSetAction(EvaluateRuleSetActionForm form)
throws P13nControlException
{
// 追加する空白のリストを表示する。List wmObjects = new ArrayList();
// 以下に、ルールを実行する条件を指定する。
ProfileWrapper pw = myProfileControl.getProfileFromRequest(this.getRequest());
if ( pw == null)
{
throw new P13nControlException("Undable to retrieve profile from
request." + "Make sure PortalServletFilter is configured
in web.xml for an anonymous user, " + "or that a user
has logged in.");
}Integer value = new Integer(6);
myProfileControl.setProperty(pw, "FooPropertySet", "CreditScore", value);
wmObjects.add(pw);
// ルール セット内のすべてのルールを評価する。(アクション ビューにある) ページフローのプロパティ エディタ
// でコントロールに関するパラメータが宣言されている。Iterator iter = myRulesExecutorControl.evaluateRuleSet(wmObjects.toArray());
// GoldCardMembers を検索するように指定する。
List results = new ArrayList();Classification goldCardMembers = new Classification("GoldCardMembers");
// 次に、ルールの評価結果に従って分類されたユーザに
Classification silverCardMembers = new Classification("SilverCardMembers");
// 特定のページを表示する。Classification classification = (Classification)iter.next();
// 個別のページを表示するなどの
// アクションを指定できる。if (classification.equals(goldCardMembers))
// ユーザに高価格の商品を表示する。
{return new Forward("goldCard");
// ユーザに低価格の商品を表示する。
}
else if (classification.equals(silverCardMembers))
{return new Forward("silverCard");
// 上記以外の場合は、デフォルトのページを表示する。エラーが発生。
}
// ルールの条件を確認するか、コントロールのフィルタ処理をオフにして、
// 作業メモリ内の状況を確認する。}
}
return new Forward("default");
}
ルール サービスが停止した後、作業メモリにある特定のタイプのオブジェクトだけを使用する場合は、作業メモリ内のオブジェクトをフィルタ処理できます。フィルタ処理は、Java のタイプを使って設定します。Rules Executor コントロールのフィルタ タイプは、プロパティ エディタで設定できます。「5. 結果のフィルタ処理」を参照してください。
Rules Executor コントロールの詳細については、WebLogic Portal Javadoc の com.bea.p13n.controls.rules.RulesExecutorControl を参照してください。RulesManager EJB の詳細については、「com.bea.p13n.rules.manager Package」を参照してください。
ルール コントロールと RulesManager EJB のその他の使用例については、dev2dev サイトの「Portal のルール サービス」 (http://www.beasys.co.jp/dev2dev/products/wlportal81/articles/portalrulesservice.html) を参照してください。
「4. ルール サービスの呼び出しによるオブジェクトの評価」で説明したように、ルール サービスを実行して作業メモリ内のオブジェクトを評価する場合、ルール サービスが停止したときに、特定タイプのオブジェクトだけを返すように作業メモリ内のオブジェクトをフィルタ処理できます。
作業メモリに存在するオブジェクトは、次のいずれかになります。
ルール サービスが停止した時点の作業メモリには、ユーザが最初に追加したオブジェクトを含み、いくつかのオブジェクトが残されている可能性があります。たとえば、指定したルールの評価が true の場合に、ルールによって新しい Classification オブジェクトのインスタンスが作業メモリに作成されることがあります。また、ルールのアクションによってユーザ プロファイルが更新されている可能性があるため、作業メモリからプロファイルを取得する必要があります。
ルール サービスの API は、ルールを実行すると、結果がフィルタ処理されない限り、作業メモリの内容全体に関するイテレータを返します。Classification オブジェクトのみを検索する場合は、そのオブジェクトのみを返すフィルタを指定することができます。このフィルタは、「ページフローにコントロールを挿入する」で説明したように、単一のクラス名、複数のクラス名、または特定のルールに基づいて作成できます。
Rules Executor コントロールを使用したフィルタ処理は、コントロールの実装時にフィルタが自動的に作成されるため、簡単です。必要な操作は、フィルタ処理を行うかどうかと、フィルタ クラス名 (複数も指定可能) をコントロールのプロパティとして指定することだけです。フィルタは、コントロールによって自動的に適用されます (フィルタ処理を指定した場合)。
RulesManager EJB を使用したフィルタ処理は、以下のようにユーザ自身がフィルタを作成する必要があるため、多少手間がかかります。
String filterRuleName = null;
Class filterClass = com.bea.p13n.user.Classification.class;
ObjectFilter filter = new RuleResultClassFilter(filterRuleName, filterClass);
Class [] filterClasses = { java.lang.String.class, com.bea.p13n.usermgmt.profile.ProfileWrapper.class};
ObjectFilter filter = new RuleResultClassFilter(filterRuleName, filterClasses);
次の例に示すように、この後、フィルタを RulesManager EJB の一部として使用することができます。
public Iterator evaluateRule(String ruleSetUri, String ruleName, Object[] inputObjects, ObjectFilter filter)
上記のように結果をフィルタ処理した場合は、指定したクラス タイプの結果のみがイテレータに含まれます。したがって、次のようなアクションを実行できます。
while (iter.hasNext())
{
Classification c = (Classification)iter.next();
if (c.equals(silverCardMembers))
{
// 何かアクションを実行する
}
}
ルール サービスを実行する最大の理由は、おそらく、ルール サービスに実行時の処理の判断を委ねることにあります。ルールのフレームワークは、コンポーネントにロジック (if/then) をハードコードするよりも柔軟性があります。コードを修正せずにルールを修正できるからです。
「4. ルール サービスの呼び出しによるオブジェクトの評価」で紹介したサンプルの他にも、dev2dev サイトの「Portal のルール サービス」 (http://www.beasys.co.jp/dev2dev/products/wlportal81/articles/portalrulesservice.html) に、ルール コントロールおよび RulesManager EJB のサンプルが掲載されています。
![]() |
![]() |
![]() |