Skip navigation.

eDocs ホーム > BEA WebLogic Portal 8.1 ドキュメント > ポータル アプリケーションでのルールの使用 > ポータル アプリケーションでのルールの使用

ポータル アプリケーションでのルールの使用

  前 次 前と次、目次/インデックス/pdf を分けるコロン 目次  

ポータル アプリケーションでのルールの使用

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 を使用することによって柔軟性と機能が強化されることを示しています。

表 1 WebLogic Portal のパーソナライゼーション コンポーネント 

コンポーネント

説明

入力オブジェクト

アクション (入力オブジェクトがルールの条件に一致した場合)

ユーザ セグメント

ユーザが特定の条件を満たしている場合、それらのユーザをグループまたはセグメントに動的に割り当てる。

セグメント ルールは WebLogic Workshop の User Segment Designer で作成する。ルールは WebLogic Administration Portal で変更できる。

セグメント ルールは、ユーザ プロファイル プロパティ、HTTP セッションとリクエストのプロパティ、日付と時間の値および範囲を使用して定義できる。

アクションは 1 つのみ : すべての条件が「true」であると評価された場合、ユーザはセグメントのメンバーと見なされる。セグメントは、キャンペーン、コンテンツ セレクタ、および <pz:div> JSP タグ内で使用できる。

キャンペーン

特定の条件を満たしているユーザにパーソナライズされたアクションを実行するか、または特定のアクションを実行する。

キャンペーン ルールは WebLogic Workshop の Campaign Designer で作成する。ルールは WebLogic Administration Portal で変更できる。

キャンペーン ルールは、ユーザ セグメント、ユーザ プロファイル プロパティ、HTTP セッションとリクエストのプロパティ、イベントの特性、日付と時間の値および範囲、ショッピング カートとカタログ条件、無作為抽出を使用して定義できる。

アクション タイプは最大 3 つまで : 1 つのパーソナライズされたコンテンツ項目を表示する、定義済み電子メールを自動送信する、割引を適用する。

コンテンツ セレクタ

特定の条件を満たしているユーザに特定のコンテンツ項目を表示する。

コンテンツ セレクタ ルールは WebLogic Workshop の Content Selector Designer で作成する。ルールは WebLogic Administration Portal で変更できる。

コンテンツ セレクタ ルールは、ユーザ セグメント、ユーザ プロファイル プロパティ、HTTP セッションとリクエストのプロパティ、日付と時間の値および範囲を使用して定義できる。

アクションは 1 つのみ : 1 つまたは複数のパーソナライズされたコンテンツ項目を表示する。

パーソナライゼーション (対話管理) JSP タグ

これらのタグの一部は、セグメント、キャンペーン、コンテンツ セレクタの各ルールの結果を表示する場合に使用される。

表示されるコンテンツは、ユーザ セグメント、キャンペーン、またはコンテンツ セレクタの各ルールに基づく。

アクションは 1 つのみ : パーソナライズされたコンテンツ項目を表示する。

ルール コントロール

Rules Executor コントロールを使用すると、定義済みのルール セットに対して入力オブジェクト (ユーザ プロファイルのプロパティなど) を評価できる。入力オブジェクトに基づいてルールが「true」であると評価された場合は、定義済みのアクション (特定の分類へのユーザの割り当てなど) が実行される。Rules Manager コントロールを使用すると、ルール セットに関する情報を検索できる。これらのルール コントロールは、RulesManager EJB へのインタフェースとして機能する。

ページフローまたは Web サービスでのルール コントロールの追加およびコンフィグレーションは、WebLogic Workshop のグラフィカル ユーザ インタフェースを使用して行う。ルールは手作業で XML 形式で作成する。

入力オブジェクト タイプに制限なし : XML 形式で作成したルールを使用して、作業メモリに配置したどのオブジェクトでも評価できる (後述の説明を参照)。

アクション タイプに制限なし : 作業メモリ内のオブジェクトをフィルタ処理し (後述の説明を参照)、ルール セットの XML で定義されているどのアクションでも実行できる。

RulesManager EJB

ページフローおよび Web サービス以外のアプリケーション領域で、ルール コントロールと同じ機能を提供する。RulesManager EJB を使用してルール サービスにアクセスするには、Java のコーディングが必要。


 

ルールの概要

このガイドは、WebLogic Portal のルール コントロールおよび RulesManager EJB を使用して、アプリケーションにパーソナライゼーションを追加する方法に焦点を置いています。ユーザ セグメント、キャンペーン、コンテンツ セレクタ、およびパーソナライゼーション JSP タグを使用したパーソナライゼーションの開発には、ルール サービス アーキテクチャから抽象化された使いやすいユーザ インタフェースが必要となります。この開発の詳細については、WebLogic Workshop のオンライン ヘルプを参照してください。

ルール サービスは、作業メモリに配置されているオブジェクトを読み込み、それらを XML ファイルに定義されている一連のルールと比較して評価します (「作業メモリ」は、ルール サービスでルールが処理される間、オブジェクトを一時的に格納する場所と考えてください)。メモリ内のオブジェクトが、ルール セットに定義されている条件 (複数のルールで構成することもできます) と一致すると、ルール セットに定義されているアクションが実行されます。たとえば、ユーザ プロファイルや、Web サービスの計算結果などから取得したユーザの信用度スコアを作業メモリに配置した場合、ルール セット内のルールとして、「ユーザの信用度スコアが 10 点以上であれば、そのユーザをゴールド カスタマとして分類する」などと定義することができます。ルールは XML 形式で記述します。このルール処理の結果は、さまざまな方法でアプリケーションに使用できます。たとえば、ページ フローを開発している場合は、「ゴールド カスタマ」だけを gold.jsp ファイルに送信し、残りのすべてのカスタマを別の JSP ファイルに送信することができます。

ルール サービスのプロセス

ルール サービスは、前向き推論用に最適化されている Rete アルゴリズムに基づいています。ルールの評価プロセスは、以下の順序で実行されます。このプロセスでは、Rules Executor コントロールを例として使用しています。

  1. Portal のルール サービスが初期化され、「作業メモリ」が作成されます。
  2. Rules Executor コントロールによって、使用するルール セット、評価するルール (デフォルトはすべてのルール)、および結果をフィルタ処理するかどうか (オプションで指定した場合) が識別されます。これらのパラメータはすべて、コントロールにコンフィグレーションできます。
  3. 開発者が「作業メモリ」にオブジェクトを作成 (または追加) します。オブジェクトの例としては、ユーザのプロファイル、Request などがあります。これらのパラメータは引数としてルール コントロールの evaluate*() メソッドに渡されます。
  4. Rules Executor コントロールによってルール サービスが呼び出され、以下のアルゴリズムが使用されます。
    1. 照合 : ルールの左側 (Left Hand Side : LHS) を評価し、作業メモリ内で指定された現在の内容と合致しているものを判別します。
    2. 衝突の解決 : LHS が満たされているルールを 1 つ選択します。LHS が満たされているルールがない場合、インタープリタは停止します。
    3. 実行 : 選択されたルールの右側 (Right Hand Side : RHS) に定義されているアクションを実行します。
    4. 手順 1 に戻ります。
  5. ルール サービスが繰り返し実行され、入力オブジェクトの状態とルール条件に従ってルールが適用されます。一度に適用できるルールは 1 つだけです。条件が満たされ、ルールが適用されたら、別のオブジェクトを作業メモリに追加して評価することができます。
  6. 適用するルールがこれ以上ない状態に達すると、ルール サービスが停止します。作業メモリには、最初の入力オブジェクトの他に、ルールの評価の結果として作成された新しいオブジェクトも存在している場合があります。
  7. 入力オブジェクトは結果の一部であるため、クラスに基づいて結果をフィルタ処理することができます。たとえば、クラス com.bea.p13n.usermgmt.profile.ProfileWrapper の結果だけを返すように指定できます。
  8. オブジェクトが呼び出し元に返されます。返されたデータをどのように使用するかは呼び出し元が決定します。たとえば、ユーザに新しいページを表示したり、ユーザ プロファイルのプロパティを更新することができます。

図 1 は、Rules Executor コントロールをページフローに使用した前述のプロセスを基本的な図で表したものです。この図では、ルール サービス プロセスから返された結果を、ページフローからのユーザのパスを特定することに使用しています。また、この図では、分かりやすいように、コードの代わりに自然言語を使用しています (実際のページフローでのパラメータの設定とコントロールの呼び出しについては、「ページフローでコントロールを使用してユーザのパスを特定する」を参照してください)。

図 1 ルールによるページフローの制御


 

ルール サービスが if/then 文より優れている理由

ルール サービスは、コードで使用される単純な条件文よりも動的に扱うことができます。Web アプリケーションや他のアプリケーション コンポーネントを条件文 (if/then) を使用してハード コード化した場合、条件文を変更するには、コードを再コンパイルし、アプリケーションを再デプロイするしか方法はありません。これに対してルールは、Portal サーバを実行したまま変更し、ロードすることができます。つまり、管理者は、ドメイン エキスパートからビジネス ロジックを取得して、そのロジックを反映するルール式を作成し、サーバを停止せずにルールをアプリケーションにロードすることができます。

 

ルール サービスの使用

この節では、ルール コントロールと RulesManager EJB を使用してパーソナライゼーションを開発する方法を説明します。この開発には、以下の手順が伴います。

1. ルール セットの作成

2. ルール セットのデプロイ

3. 作業メモリへのオブジェクトの追加

4. ルール サービスの呼び出しによるオブジェクトの評価

5. 結果のフィルタ処理

6. アプリケーションでの結果の使用

1. ルール セットの作成

ルール セットは、ルール サービスが作業メモリ内のオブジェクトの評価に使用する命令セットを、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 形式でルール セットを作成する前に、次のように自然言語でルールを書き出して、すべての条件とアクション、およびデータ型を理解してください。作業メモリには何を配置するか ?オブジェクトが満たさなければならない条件は何か ? 作業メモリ内のオブジェクトがそれらの条件を満たしている場合、何を (どのようなアクションを) 実行するか ?

  1. ポータル アプリケーションのルートにある p13n_ejb.jar ファイルから、以下のスキーマをルート セットを作成するディレクトリに解凍します。

    2. lib/schema/expression*.xsd
    lib/schema/rules*.xsd

    XML エディタで新しいドキュメントまたは既存のドキュメントを開き、そのドキュメントに rules-core-2_1_1.xsd スキーマを関連付けます。このスキーマには、式のスキーマをはじめ、ルール セットの作成に役立つ他のスキーマのインポートも含まれています。

    新規 XML ドキュメントの場合は、XML ヘッダが自動的に挿入されます。また、インポート用に指定されたすべてのスキーマが自動的にインポートされて、<rule-set>、<rule>、<name>、<conditions>、<actions> などの必須の基本要素が挿入されます。

  2. <conditions> および <rules> 要素を選択して、条件とルールを作成 (または修正) します。

    3. 次の図は、XMLSpy で作成されるルール セットを示しています。<exp:greater-than-or-equal-to> 要素を選択すると、子として追加できる要素が [Elements] ペインに一覧表示されます。[Attributes] ペインには、この要素に設定できる属性が表示されます。

    図 2 XML エディタでのルールの作成


     
  3. ルール セットを作成したら、XML エディタの機能を使用して XML が整形式であるかどうかをチェックし、その後でスキーマに対する妥当性を検査します (XMLSpy では、これらの機能はそれぞれ 〔F7〕、〔F8〕 を押すと実行できます)。

    4. 無効なルール セットを修正する方法については、「無効なルール セットの修正」を参照してください。

  4. ルール セットを保存します (XMLSpy では、無効なルール セットを保存しようとすると、そのことを示すメッセージが表示されますが、保存することは可能です)。
  5. ポータル アプリケーションの META-INF/data ディレクトリ、またはその下のサブディレクトリにルール セットをコピーします。たとえば、META-INF/data/rulesets ディレクトリを作成して、そこにルール セットを保存します。

例 : ルール内でのメソッドの使用

次の表は、ルール セットの XML ドキュメントでメソッドを使用して、ユーザ プロファイルのプロパティ値を取得し、ルール サービスで評価できるようにする方法を示しています。

表 2 XML ルールでのメソッドの使用法

条件

 
<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>

条件がマップされるメソッド

以下は User タイプのオブジェクトを取得する。

ProfileWrapper pw = SessionHelper.getProfile(request);
Object value = pw.getProperty("CreditPropertySet", "CreditScore");


 

XML とメソッドのマッピングの詳細は次のとおりです。

無効なルール セットの修正

ルール セットの妥当性が立証されなかった場合、そのルール セットが無効であることを示す領域が表示されます。この場合は、以下のように対応します。

2. ルール セットのデプロイ

この節では、デプロイメント (WebLogic Workshop) 環境、テスト環境、またはプロダクション環境にルール セットをデプロイする方法について説明します。

WebLogic Workshop でのルール セットのデプロイ

ルール セットを作成して、アプリケーションの META-INF/data ディレクトリ (または、その下の META-INF/data/rulesets などの作成したサブディレクトリ) に保存すると、サーバが稼動していれば、ルール セットは自動的にデプロイされます。サーバが稼動していない場合は、サーバを起動した時点で自動的にデプロイされます(META-INF/data は DataSync ディレクトリと呼ばれ、ユーザ セグメント、コンテンツ セレクタ、キャンペーンなど、ユーザが作成した他のアプリケーション メタデータも保存されています)。ルール セットは DataSync ディレクトリにデプロイする必要があり、ルール セットのファイル名には、ルール サービスで識別されるように拡張子 .rls を付ける必要があります。

DataSync ディレクトリのルール セットを修正すると、そのルール セットは、稼動中のサーバで自動的に更新されます。

テスト環境またはプロダクション環境でのルール セットのデプロイ

デプロイ済みのアプリケーションに存在するルール セットに追加、修正、または削除を行う必要がある場合は、次の手順を実行します。

  1. デプロイメント環境のルール セットを修正し、デプロイ済みアプリケーション内のルール セットを置き換えます。アプリケーションが圧縮された EAR 内にある場合は、更新したルール セットを取り込むために EAR を再作成する必要があります。その後、EAR をサーバに再配置します。サーバ上の EAR を置き換えるとアプリケーションを再デプロイメントする必要がありません。
  2. Datasync Web アプリケーションを実行してルール セットを更新します。Datasync Web アプリケーションの使用の詳細については、『プロダクション業務ユーザーズ ガイド』を参照してください。

3. 作業メモリへのオブジェクトの追加

ルール セットは、作業メモリ内に評価するオブジェクトが存在しなければ意味を成しません。たとえば、ルール セットに含まれる 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 ファイルで定義されています。

<type-alias> タグのマッピング

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> 要素を示しています。

<variable> タグのマッピング

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

4. ルール サービスの呼び出しによるオブジェクトの評価

ルール セットを作成し、作業メモリにオブジェクトを配置したら、ルール サービスを呼び出して、作成したルールで作業メモリ内のオブジェクトを評価することができます。

この節では、サンプルを示しながら、ページフローで Rules Executor コントロールを使用してルール サービスを呼び出す方法について説明します。

サンプルの前提条件

この節を通して使用するサンプルでは、「ユーザ プロファイルから作業メモリに信用度スコアを追加する」で使用した例と同様に、ユーザ プロファイルを読み込むことによってユーザを「GoldCardMembers」または「SilverCardMembers」に分類するルール セットが、/data/rulesets ディレクトリにすでに作成されていることを前提としています。この節のページフローのサンプルは、作業メモリに追加されるユーザ プロファイルを示しています。このサンプルにはユーザ プロファイルが必要となるため、既存のページフローには、ユーザ プロファイルのプロパティの取得および設定を可能にする Profile コントロールがすでに追加されているものとします。

また、このサンプルには、ページフローがどのユーザ プロファイルを取得するのかを識別できるように、認証用の User Login コントロールも使用されています。

ページフローを作成する方法については、WebLogic Workshop オンライン ヘルプの「ページフロー構築ガイド」を参照してください。ページフローにポータル コントロールを追加する方法については、WebLogic Workshop オンライン ヘルプの「Java ページ フローにポータル コントロールを追加する」を参照してください。

ページフローにコントロールを挿入する

ページフロー (WebLogic Workshop の .jpf ファイル) にコントロールを挿入すると、そのコントロールに定義されているすべてのアクション (メソッド) が使用可能になります。Rules Executor コントロールには、次の 2 つのアクションのいずれかを選択できます。

アクション ビューでページフローを開くと、コントロールの境界線を選択して挿入済みのコントロールを選択したり、図 3 に示すように、プロパティ エディタでそのコントロールのプロパティを設定することができます。

図 3 コントロールのプロパティの設定


 

プロパティ エディタは、Java コードを記述せずに RulesManager EJB (ルール サービスへの直接的なインタフェース) に引数を渡すことのできる便利なツールです。

たとえば、表 3 は、図 3 に示す Rules Executor コントロールのプロパティが、RulesManager EJB のメソッドとコンストラクタの引数にどのようにマップされるかを示しています。

表 3 コントロールのプロパティにマップされるメソッドとコンストラクタの引数

Rules Executor コントロールのプロパティ

RulesManager EJB のメソッド (「com.bea.p13n.rules.manager」を参照)

rulesetUri

ruleName

filterResults

filterClassName

filterClassNames

evaluateRule(String ruleSetUri, String ruleName, Object[] inputObjects)

evaluateRule(String ruleSetUri, String ruleName, Object[] inputObjects, ObjectFilter filter)

evaluateRuleSet(String ruleSetUri, Object[] inputObjects)

evaluateRuleSet(String ruleSetUri, Object[] inputObjects, ObjectFilter filter)

filterRuleName

フィルタ コンストラクタ (「com.bea.p13n.rules.manager.RuleResultClassFilter」を参照)

RuleResultClassFilter(String ruleName, Class targetClass)

RuleResultClassFilter(String ruleName, Class targetClassArray)


 

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 プロパティを使用すると、実行された特定のルールの結果だけでなく、特定のデータ型についてもフィルタ処理できます。

コントロールのプロパティの詳細は次のとおりです。

コントロールの利点

前の節では、各プロパティにメソッドとコンストラクタがどのようにマップされるかを説明しましたが、これにより、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());
        List results = new ArrayList();
// GoldCardMembers を検索するように指定する。
         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) を参照してください。

5. 結果のフィルタ処理

「4. ルール サービスの呼び出しによるオブジェクトの評価」で説明したように、ルール サービスを実行して作業メモリ内のオブジェクトを評価する場合、ルール サービスが停止したときに、特定タイプのオブジェクトだけを返すように作業メモリ内のオブジェクトをフィルタ処理できます。

作業メモリに存在するオブジェクトは、次のいずれかになります。

ルール サービスが停止した時点の作業メモリには、ユーザが最初に追加したオブジェクトを含み、いくつかのオブジェクトが残されている可能性があります。たとえば、指定したルールの評価が true の場合に、ルールによって新しい Classification オブジェクトのインスタンスが作業メモリに作成されることがあります。また、ルールのアクションによってユーザ プロファイルが更新されている可能性があるため、作業メモリからプロファイルを取得する必要があります。

ルール サービスの API は、ルールを実行すると、結果がフィルタ処理されない限り、作業メモリの内容全体に関するイテレータを返します。Classification オブジェクトのみを検索する場合は、そのオブジェクトのみを返すフィルタを指定することができます。このフィルタは、「ページフローにコントロールを挿入する」で説明したように、単一のクラス名、複数のクラス名、または特定のルールに基づいて作成できます。

Rules Executor コントロールを使用したフィルタ処理は、コントロールの実装時にフィルタが自動的に作成されるため、簡単です。必要な操作は、フィルタ処理を行うかどうかと、フィルタ クラス名 (複数も指定可能) をコントロールのプロパティとして指定することだけです。フィルタは、コントロールによって自動的に適用されます (フィルタ処理を指定した場合)。

RulesManager EJB を使用してフィルタ処理を行う

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)) 
     {  
          // 何かアクションを実行する 
      } 
}

6. アプリケーションでの結果の使用

ルール サービスを実行する最大の理由は、おそらく、ルール サービスに実行時の処理の判断を委ねることにあります。ルールのフレームワークは、コンポーネントにロジック (if/then) をハードコードするよりも柔軟性があります。コードを修正せずにルールを修正できるからです。

ルールおよびルールの結果は、次のように利用できます。

ルール サービスのサンプル

「4. ルール サービスの呼び出しによるオブジェクトの評価」で紹介したサンプルの他にも、dev2dev サイトの「Portal のルール サービス」 (http://www.beasys.co.jp/dev2dev/products/wlportal81/articles/portalrulesservice.html) に、ルール コントロールおよび RulesManager EJB のサンプルが掲載されています。

 

ページの先頭 前 次