| Oracle Real-Time Decisionsプラットフォーム開発者ガイド リリース3.0 B54059-01 |
|
 戻る |
 次へ |
Oracle RTDは、ビジネス・プロセス・トランザクションの実行時に、そのトランザクションをリアルタイムで継続的に学習するプロセスにより、適応型のエンタープライズ・ソフトウェア・ソリューションを実現します。リアルタイムで継続的に学習することで、適応型のソリューションは、各トランザクションと関連ビジネス・プロセスの結果を最適化できます。Oracle RTDのデシジョン・プロセスの基本フレームワークは、次のとおりです。
Oracle RTDでは各相互作用に対して分析的なデシジョンを作成します。
ルールと予測モデルに基づき、Oracle RTDデシジョンでリアルタイムのデータと履歴データを使用して、様々な選択肢から最適な提案を作成します。
最適な提案の作成に際して、潜在的に競合するビジネス目標における最適化をOracle RTDで行います。
次の図では、Oracle RTDの意思決定プロセスのフレームワークを形成する標準要素が示されています。また、外部アプリケーションとOracle RTDが連携して、エンド・ユーザーに対して複合的なデシジョン・サービスを実現するうえで重要な一連の入力も示されています。
Oracle RTDの意思決定プロセスの標準要素は、デシジョン、エンティティ、選択肢、ルール、モデルおよびパフォーマンス目標です。これらはDecision Studioで定義されます。これらの要素の概要は、第11章「Decision Studioについて」および第12章「Decision Studioの要素とAPIについて」を参照してください。
Oracle RTDは、外部のコンテンツ管理システムで保持される選択肢など、外部データ・システムのオブジェクトにリアルタイムで変更を適用できます。
Oracle RTDを使用するアプリケーションにより、ルールの作成や変更を行ったり、デシジョン・プロセス全体の導出と制御を行うパフォーマンス目標を変更することで、ユーザーが重要な変更を即座に意思決定プロセスに加えることができます。
この章では、Oracle RTDの基本要素に対してこのような拡張機能を定義し、複合的な意思決定プロセスにおいて使用する方法と、対応する外部アプリケーションにこれらを統合する方法について説明します。
この章の内容は次のとおりです。
Oracle RTDにおいて、選択肢は代替案の母集団を表します。これらから、抱合せ販売アプリケーションにおける最適なオファーなどの提案を選択できます。
選択肢には、静的選択肢と動的選択肢があります。
静的選択肢の場合、リクエスト元アプリケーションまたは自己学習モデルに提示される選択肢は、Oracle RTD内で完全に定義されます。静的選択肢は、選択肢が既知の場合と、一定期間にわたって一定の場合に役に立ちます。
動的選択肢は、実行時に動的に構築される選択肢です。この選択肢は通常、外部データソースに保持されます。これにより、オファー管理システムで定義したオファーに基づく選択肢など、ソース・システムで選択肢を管理できます。
|
注意: 動的選択肢の主要ソースが外部データソースの場合でも、カスタマイズされたJavaコードで動的選択肢を作成できます。 |
アプリケーションに提示される動的選択肢は時間の経過に応じて変化する場合がありますが、常にアプリケーション・データの最新状態が反映されます。動的選択肢の内容が更新されたときにOracle RTDインライン・サービスを再デプロイする必要はありません。
|
注意: この項では動的選択肢に焦点を絞りますが、選択肢グループは静的選択肢と動的選択肢を組み合せて構成できます。デシジョンは、選択肢グループにどの種類の選択肢が含まれているかに関係なく、1つ以上の選択肢グループに関連付けることができます。 |
この項の内容は次のとおりです。
簡単な例として、図16-1のInsurance_Proposalsテーブルで説明します。このテーブルはOracle RTD環境の外部で定義され、Oracle RTDが評価して優先度を設定する選択肢に関する情報を保持しています。
Insurance_Proposalsテーブルには、様々な保険商品を示す行があり、ChoiceGroupId列のInsuranceProducts共通値で識別されます。動的選択肢をカテゴリ化したりグループ化する列は、動的選択肢を設定する際に重要な必須キー識別子です。
グループにある各行は、AutoInsuranceやDisabilityInsuranceなど、様々な種類の提供対象保険商品を示しています。この各行が動的選択肢に相当します。
1つの列を使用して、グループ内で特定の動的選択肢を識別します。この例では、ChoiceID列が動的選択肢の識別列です。
テーブルの他の列（ProfitMarginなど）は、Oracle RTDによって評価プロセスで使用できます。これらの列も、定義された選択肢属性の値として、提案される動的選択肢の一部としてアプリケーションに送信できます。
要約すると、Oracle RTDにおける設定プロセスとは、動的選択肢に対して選択肢グループを設定し、その選択肢グループを必要な外部データソースまたは外部ソースに関連付けることです。これにより、動的選択肢はOracle RTDによって提案可能になります。
対応する選択肢グループで十分な数の提案を作成してモデルを更新した後は、図16-2に示すように、Decision Centerにより様々な動的選択肢のパフォーマンスを分析できます。
動的選択肢の基本的な設計プロセスは、静的選択肢の場合と同様です。最初に選択肢グループを設定してから、選択肢グループの動的選択肢で必要な要素とパラメータを定義する必要があります。設定方法の詳細は、第16.1.5項「Decision Studioにおける動的選択肢の設定の概要」を参照してください。
この項では、Insurance_Proposalsの例を使用して、設計プロセスの概要を説明します。また、設計プロセスで使用される主要な用語についても次に示します。
すべての動的選択肢のセットは、グループ化列またはカテゴリ化列に共通値を持つすべての行と識別されます。Insurance_Proposalsの例では、カテゴリ化列（またはセット識別子）はChoiceGroupId列です。
データベース・セットの各行は、1つの動的選択肢を示します。Insurance_Proposalsの例では、動的選択肢自体がChoiceId列の一意の値によって識別されます。
Oracle RTDで動的選択肢の選択肢グループを定義する場合、動的選択肢が格納されている行のセットにグループをリンクする必要があります。
Oracle RTDで選択肢グループの動的選択肢を定義する場合、グループの各動的選択肢を、データソースで対応する動的選択肢の単一行にリンクする必要があります。
最も単純な動的選択肢では、データベース・テーブルのすべての行が同じカテゴリに属します。つまり、カテゴリ化列の値がすべて同じです。
同じデータベース・テーブルや各種データソースから、異なる動的選択肢を渡すことができます。図16-3に示されている次の例では、Insurance_Proposalsテーブルが拡張され、保険商品と保険サービスの両方について選択肢が用意されています。
この場合、Oracle RTDで2つの選択肢グループを設定し、どちらのデータセットもアプリケーションで提案できるようにします。
対応する選択肢グループで十分な数の提案を作成してモデルを更新した後は、保険商品または保険サービス（あるいはその両方）の動的選択肢のパフォーマンスを分析できます。
たとえば、図16-4に示すように、Decision Centerにおいて選択肢グループをグループ階層で2つのグループとして設定すると、分析に使用できます。
保険商品の分析結果は、図16-2の結果と同じです。図16-5は、保険サービスに関して同等の分析レポートを示しています。
選択肢グループは選択肢とは異なり、事前に定義する必要があります。つまり、選択肢グループは静的です。レポートやデシジョンの要件をサポートするために必要な場合、動的選択肢を個々の選択肢グループにグループ化できます。
各選択肢グループの設計に関する考慮事項と対象コンポーネントは、第16.1.2項「動的選択肢の基本設計の概要」に説明されているとおりです。
選択肢グループの設定方法の概要は、第16.1.5項「Decision Studioにおける動的選択肢の設定の概要」を参照してください。
同じデータソースから異なる選択肢グループを設定する方法の詳細は、第16.1.12項「複数カテゴリの選択肢グループの作成」を参照してください。
動的選択肢に必要なデータは、外部のデータソースにあります。
説明を単純にするために、次の説明では、外部データソースがコール元アプリケーションのデータベース・テーブルまたはビューであると仮定します。
動的選択肢にとって有用にするには、データに次の列が含まれている必要があります。
データのカテゴリ化と抽出で使用する列が1列
動的選択肢が1つの場合は、カテゴリ化列に同じ値を持つ行がすべて抽出され、この列を使用して抽出を制御します。
次に例を示します。
データベース・テーブルのSpecial_EventsにEvent_Type列があります。
Event_Typeの値は、すべての行でPromotion、Product_Launch、Mailshotのいずれかです。
この例では、Event_Typeがカテゴリ化列で、動的選択肢が1つの場合、1つのイベント・タイプの行がすべて（すべてのPromotion行など）、Oracle RTDで抽出されます。
特定の動的選択肢用に抽出される行を一意に識別する列が1列
この列の値はすべての行で一意にする必要はありません。抽出されたデータセット内でのみ一意となります。
抽出されたデータ内で一意な識別子を提供する列であれば、どの列でもかまいません。この列の値には、なんらかのテキスト文字列を含めることをお薦めします。この値は、Decision Centerレポートでヘッダーとして表示されるため、現実の世界で意味を持つ識別子のほうが、数値だけの識別子より有用です。
図16-6は、サンプルのデータベース・テーブルであるWeb Offersを示しています。このテーブルは、動的選択肢データソースの外部データソースとして使用できるものです。
このテーブルには、次の特徴があります。
カテゴリ化列はCategoryで、すべてのCategory列の共通値はDynamicOffersCGです。
Name列またはID列を、DynamicOffersCGカテゴリの動的選択肢の識別子列として選択できます。
|
注意: 設定プロセスを示す図およびDecision Studioの画面ショットが、動的選択肢に関連して後述する各項に記載されていますが、それらはOracle RTDとともにリリースされるDC_Demoインライン・サービスに基づいています。 |
Decision Studioで動的選択肢を設定するプロセスの内容は、次のとおりです。
図16-7は、動的選択肢に対して単純な単一カテゴリの選択肢グループを設定する方法の概要を示しています。図の中の要素については、この章の以降の詳細なプロセス説明の中で説明します。
動的選択肢のデータソースを作成する手順は次のとおりです。
「Import」ボタンを使用して外部データソースをポイントします。第16.1.4項「動的選択肢の外部データソースの前提条件」で説明したテーブルにマップする新しいデータソースが作成されます。
「Output」列領域で、「Allow multiple rows」チェック・ボックスを選択し、動的選択肢に必要なすべての列を選択します。
「Input」列領域で、動的選択肢行をカテゴリ化しグループ化する共通値を含む列を選択します。
|
注意: この段階で、「Output」列から動的選択肢の識別子列を選択する必要はありません。 |
図16-8は、データソースのWeb Offers DSをテーブルのSDDS.WEBOFFERSから設定する方法を示しています。ここでは、Categoryが入力識別子で、他のいくつかの列は動的選択肢自体の属性となります。
動的選択肢のデータは、データソース内にあります。Oracle RTDでは、カテゴリ自体の情報ではなく、特定のカテゴリに関連するすべての情報で構成されるように動的選択肢の単一エンティティを作成する必要があります。
作成したデータソースでは、そのデータソースの出力属性が動的選択肢の単一エンティティのエンティティ属性になります。
動的選択肢の単一エンティティを作成する手順は次のとおりです。
「Import」機能を使用して、動的選択肢データのエンティティを作成します。これによって、第16.1.4項「動的選択肢の外部データソースの前提条件」で説明したデータソースのすべての「Output」列が取り込まれます。
データソースを選択する場合、インポート時に表示される「Select」ウィンドウの「Build data mappings for the selected data source」オプションの選択が解除されていることを確認します。
図16-9は、動的選択肢の単一エンティティであるWeb Offersを設定する「Definition」タブを示しています。属性は、データソースであるWeb Offers DSの「Output」列です。
動的選択肢の単一エンティティに加えて、動的選択肢のセット・エンティティを作成する必要があります。このセット・エンティティには、次の属性を含めます。
Key属性: データソースの入力でありカテゴリ化列になります。これには、動的選択肢のデータが含まれます。
配列属性: 動的選択肢の単一エンティティのデータが格納されます。
この配列属性は、第16.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティと同じエンティティ・タイプである必要があります。この配列は、カテゴリ化属性を除いて動的選択肢で必要なデータソースから抽出されるデータのすべての属性のコンテナです。
動的選択肢のセット・エンティティを作成する手順は次のとおりです。
Oracle RTDでエンティティを作成します。
Key属性の場合は、「Add Key」をクリックし、データソースから動的選択肢のカテゴリ化属性を選択します。
属性を作成し、そのタイプを第16.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前にします。
このエンティティ・タイプ属性を、「Array」として選択します。
図16-10は、動的選択肢のセット・エンティティであるWeb Offers Listを設定する「Definition」タブを示しています。Key属性はデータソースであるWeb Offers DSの「Input」列のCategoryで、2番目の属性はWeb Offersタイプの配列属性です。
「Mapping」タブをクリックし、エンティティ・タイプ属性内の各属性を、元のデータソースで適切な列にマップします。
「Data Source Input Values」領域で、データソースの入力値として、手順2で作成した動的選択肢カテゴリ化属性を選択します。
図16-11は、動的選択肢のセット・エンティティであるWeb Offers Listを設定する「Mapping」タブを示しています。配列属性内の各属性は、Web Offers DSデータソース内の対応する列にマップされます。「Data Source Input Values」領域で、入力値に対して選択された属性は、Key属性のCategoryです。
「Cache」タブをクリックします。
「Enable caching for this entity type」チェック・ボックスを選択します。
|
注意: 動的選択肢のセット・エンティティでは、キャッシュを有効にすることが重要です。キャッシュを有効にすると、新しいセッションのたびにデータソースから動的選択肢を繰り返し取得する状態がReal-Time Decision Serverで回避されます。 |
データベースから動的選択肢データを抽出するには、データ取得を行う関数を作成する必要があります。この関数は、この後の手順で作成する選択肢グループによってコールされます。関数の特徴は次のとおりです。
関数では値を返します。
戻り値は配列型です。
配列要素のデータ型は、前に作成した動的選択肢の単一エンティティです。
前に作成した動的選択肢のセット・エンティティのデータソース入力値と同じパラメータを関数では持ちます。
関数のロジックによって動的選択肢のセット・エンティティの新しいインスタンスが作成され、パラメータを使用して、動的選択肢データを配列に取得します。
動的選択肢のデータ取得関数を作成する手順は次のとおりです。
関数を作成し、「Return value」チェック・ボックスを選択します。
「Array」オプションを選択して、戻り値が配列型であることを指定します。
「Data Type」で、第16.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前を選択します。
「Parameters」領域で、第16.1.8項「動的選択肢のセット・エンティティの作成」の手順2で作成したKey属性の「Name」と「Type」を追加します。
「Logic」フィールドで、次のようなコードを入力します。エンティティと属性の名前は、必要に応じて変更します。
WebOffersList list = new WebOffersList(); list.setCategory(category); return list.getWebOffers();
前述のコードに関する説明を次に示します。
WebOffersListは、第16.1.8項「動的選択肢のセット・エンティティの作成」で作成したエンティティのオブジェクト名で、単語と単語との間の空白が削除されています。
list.setCategoryでは、第16.1.8項「動的選択肢のセット・エンティティの作成」の手順2で作成したエンティティ・キーを参照します。
getWebOffers()では、第16.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティを参照します。これは、動的選択肢のセット・エンティティ内でマップされているエンティティです。
図16-12は、GetWebOffers関数の定義を示しています。
アプリケーション・データの管理者は、動的選択肢によって、Oracle RTDがアプリケーションに提案する選択肢を制御できます。静的選択肢とは異なり、動的選択肢は、Oracle RTDインライン・サービスとのインタフェースを変更することなく、アプリケーション・テーブルにおいて追加、編集および削除ができます。
1つのインライン・サービスで両方の種類の選択肢を使用する必要がある場合、選択肢グループを設計する際に、静的選択肢と動的選択肢を明確に分けることをお薦めします。この項では、動的選択肢の選択肢グループの設計についてのみ説明します。
動的選択肢は次の場所に設計できます。
単一の選択肢グループ内
完全に別個の選択肢グループ内: つまり、独立した単一選択肢グループの集まり
選択肢グループ階層内
設計に影響を及ぼす要因は数多く存在します。たとえば、次のような場合があります。
動的選択肢の明示的なセットに関して、顧客が選択肢グループのレポートを必要とするレポート要件がある場合
他のセットとは異なり動的選択肢の1つのセットに、共有される適格性ルールを適用する必要があるデシジョン要件がある場合
この項では、単一の選択肢グループおよび選択肢グループ階層で必要で高レベルな設計手順を示します。
単一の選択肢グループ
すべての動的選択肢を1つの選択肢グループにまとめる必要がある場合、次の方法で設計することをお薦めします。
1つの選択肢グループを設計します。
選択肢グループの「Group Attributes」タブ、「Choice Attributes」タブおよび「Dynamic Choices」タブで、必要なパラメータを入力して選択します。
Decision Studioでは、この選択肢グループにはサブグループがありません。
選択肢グループ階層
設計要件によっては、動的選択肢を選択肢グループ階層にグループ化する場合があります。次の手順は、2レベル階層の設定の概要を示しています。
最上位レベルの選択肢グループの場合、「Choice Attributes」タブで、必要なパラメータを入力して選択します。「Group Attributes」タブと「Dynamic Choices」タブでは設定しません。
個々の動的選択肢カテゴリについて、1つ下のレベルの選択肢グループを指定します。下位レベルの各選択肢グループの場合、「Group Attributes」タブと「Dynamic Choices」タブで、必要なパラメータを入力して選択します。「Choice Attributes」タブは設定しません。
|
注意: 複数レベルの選択肢グループ階層の最下位レベルの選択肢グループでは、「Dynamic Choices」タブのパラメータのみ入力する必要があります。 |
Decision Studioでは、下位レベルの選択肢グループにはサブグループがありません。
動的選択肢を使用するには、1つ以上の選択肢グループを作成する必要があります。動的選択肢が参照するデータが1つのタイプまたはカテゴリに属している場合、単一カテゴリの選択肢グループを作成します。
|
注意: Decision Studioで動的選択肢の選択肢グループを作成する場合、Decision Studioのどのウィンドウにも個々の動的選択肢は表示されません。Decision Centerのレポートでは、次の条件を満たす動的選択肢をすべて表示できます。
|
Decision Studioでは、次のタブで設定するオプションを介して、選択肢が実行時に動的に抽出できるように選択肢グループを構成します。
動的選択肢を構成するタブは、主にこれらのタブです。
|
注意: 「Choice Eligibility」タブを使用して、データソースから抽出する際に動的選択肢データのフィルタリングもできます。動的選択肢に対して作成される適格性ルールは、同じ動的選択肢グループで取得されるすべての選択肢で共有されます。 |
図16-13は、単一カテゴリの選択肢グループであるDynamic Offersを設定するのに必要な主要要素の例を示しています。
グループ属性の設定は、動的選択肢として取得されるすべてのデータが1つのカテゴリにのみ属していることを表します。ここでは、正確なカテゴリを指定する必要があります。
選択肢属性の設定は、取得される個々の属性を指定します。
グループ属性と選択肢属性は、この単一カテゴリ選択肢グループの「Dynamic Choices」タブで参照されます。
「Group Attributes」タブでは、第16.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティ・タイプの配列属性を指定します。単一カテゴリの動的選択肢の設定プロセスに関する概要を示す図16-7では、この属性は動的選択肢の配列エンティティに対応します。
このレベルでは、動的選択肢データを取得する関数も指定します。関数のパラメータ値を選択する必要があります。これにより、現実世界に対応し1つの具体的なタイプやカテゴリに関連する動的選択肢データのみを関数で取得できます。
選択肢グループを作成しグループ属性を指定する手順は次のとおりです。
選択肢グループを作成します。
「Group Attributes」タブをクリックします。
新しいエンティティ・タイプのグループ属性（動的選択肢の配列エンティティ）を作成し、そのタイプを、第16.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前にします。
この属性を「Array」として指定します。
「Value」ボックスの右端をクリックして省略記号（...）ボタンを表示します。次に、その省略記号ボタンをクリックして「Value」ウィンドウを開きます。
「Value」ウィンドウで、「Value for array as a whole」オプションを選択します。
「Value Source」で、「Function or rule call」を選択し、第16.1.9項「動的選択肢のデータ取得関数の作成」で作成した関数を選択します。
「Parameters」領域の「Value」でパラメータ値を選択し、入力属性にこの値が含まれるデータソースの対応行が取得されるようにします。
|
注意: 「Value」のこの文字列は、選択肢グループのすべての動的選択肢行をカテゴリ化する、データベース内の値と同じです。たとえば、第16.1.1項「動的選択肢の簡単な例」で説明したようにInsurance_Proposalsテーブルの選択肢グループの設定では、この値はInsuranceProductsです。 |
図16-14は、選択肢グループであるDynamic Offersの「Group Attributes」タブを示しています。コールする関数はGetWebOffersです。「Parameters」領域の「Value」には、文字列のDynamicOffersCGが指定されています。
「Choice Attributes」タブでは、次を行う必要があります。
第16.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティと同じタイプのエンティティ・タイプ属性を指定します。
この属性は、単一カテゴリの動的選択肢の設定プロセスに関する概要を示す図16-7では、動的選択肢の行エンティティに対応します。
この動的選択肢の行エンティティ内のコンポーネント属性ごとに、個々の選択肢属性を作成します。作成したばかりの動的選択肢の行エンティティ内の対応属性にこれをマップする必要があります。
選択肢グループの選択肢属性を指定する手順は次のとおりです。
「Choice Attributes」タブをクリックします。
新しいエンティティ・タイプの属性（動的選択肢の行エンティティ）を作成します。そのタイプは、第16.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前です。
「Array」チェック・ボックスの選択が解除されていることを確認します。
新しい動的選択肢の行エンティティの各属性に対して、対応する選択肢属性を作成します。
前の手順で作成した各選択肢属性について、手順2で作成した動的選択肢の行エンティティ内の対応する属性にその値をマップします。
図16-15は、選択肢グループであるDynamic Offersの「Choice Attributes」タブを示しています。選択肢属性は次のとおりです。
1つの動的選択肢行エンティティであるWeb Offer Entity
複数の他の属性: それらの各値は、動的選択肢行エンティティであるWeb Offer Entityの対応属性から導出されます。
「Dynamic Choices」タブでは、次の情報を指定します。
動的選択肢の選択肢グループとして、この選択肢グループを明示的に選択します。
対応する「Group Attributes」タブと「Choice Attributes」タブで設定したグループ属性と選択肢属性を指定します。
各動的選択肢を識別する属性を選択します。
Decision Centerのレポートにおいて動的選択肢が表示される方法を指定します。動的選択肢の数が多い場合、動的選択肢の長いリストをより小さな単位（つまり、フォルダ）に分割できます。その際、フォルダにおいてデータをグループ化する方法を指定します。
動的選択肢のパラメータを指定する手順は次のとおりです。
「Dynamic Choices」タブをクリックします。
「Use Dynamic Choices for this Choice Group」チェック・ボックスを選択します。
「Group attribute containing the list of Entities for choices」で、第16.1.11.1項「「Group Attributes」タブ」で作成した動的選択肢の配列属性を選択します。
「Choice attribute to assign the entity data」で、第16.1.11.2項「「Choice Attributes」タブ」で作成した動的選択肢の行属性を選択します。
「Entity attribute that contains the choices id」で、抽出される動的選択肢行ごとに一意な識別子である属性を選択します。
「Distribution mode for choices over choice group folders」で、「Spill」または「Even」を選択します。
「Maximum number of choices within one choice group folder on decision center」を選択します。
動的選択肢を使用するには、1つ以上の選択肢グループを作成する必要があります。同じデータソースから異なるグループのデータを選択できる必要がある場合、複数カテゴリの選択肢グループを作成します。この項では、複数カテゴリの選択肢グループを設定する一般的方法について説明します。
|
注意: Decision Studioで動的選択肢の選択肢グループを作成する場合、個々の動的選択肢は表示されません。Decision Centerのレポートでは、次の条件を満たす動的選択肢をすべて表示できます。
|
Decision Studioでは、次のタブで設定するオプションを介して、選択肢が実行時に動的に抽出できるように選択肢グループを構成します。
「Group Attributes」タブ
「Choice Attributes」タブ
「Dynamic Choices」タブ
動的選択肢を構成するタブは、主にこれらのタブです。
|
注意: 「Choice Eligibility」タブを使用して、データソースから抽出する際に動的選択肢データのフィルタリングもできます。動的選択肢に対して作成される適格性ルールは、同じ動的選択肢グループで取得されるすべての選択肢で共有されます。 |
複数の動的選択肢カテゴリを使用するには、選択肢グループの階層を作成し、異なるレベルで選択肢グループの要素を設定する必要があります。
図16-17は、2つのカテゴリを持つ選択肢グループであるIncentive Choicesを設定するのに必要な主要要素の例を示しています。
選択肢グループのIncentive Choicesは親選択肢グループで、DiscountsおよびGiftsという2つの子選択肢グループを持ちます。
最上位レベルの選択肢属性は親選択肢グループで指定します。この選択肢属性は、2つの子選択肢グループに継承されます。
|
注意: 親選択肢グループの場合、または複数レベルの選択肢グループ階層の上位レベル・グループの場合、「Dynamic Choices」タブで値の入力や選択は行いません。動的選択肢パラメータは、選択肢グループ階層の最下位レベルのグループに対してのみ指定します。 |
それぞれの子選択肢グループにグループ属性を設定すると、異なるカテゴリのデータセットを取得できます。どちらの子選択肢グループの「Dynamic Choices」タブでも、グループ属性と選択肢属性が参照されます。
このプロセスと、同等な単一カテゴリの選択肢グループの設定を比較するには、図16-7を参照してください。
「Choice Attributes」タブでは、第16.1.7項「動的選択肢の単一エンティティの作成」で作成したものと同じタイプのエンティティ・タイプの選択肢属性を指定します。
この選択肢属性は、図16-7に示されている同等な単一カテゴリの動的選択肢の設定プロセスと同様、動的選択肢の行エンティティとも呼ばれています。
この動的選択肢行エンティティ内の属性ごとに、個々の選択肢属性を作成します。これを、作成した動的選択肢行エンティティ内の対応属性にマップする必要があります。
親選択肢グループおよび選択肢属性を作成する手順は次のとおりです。
親選択肢グループを作成します。
「Choice Attributes」タブをクリックします。
新しいエンティティ・タイプの選択肢属性を作成します。そのタイプは、第16.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前です。
「Array」の選択が解除されていることを確認します。
新しいエンティティ・タイプの選択肢属性の各属性について、対応する選択肢属性を作成します。
前の手順で作成した各選択肢属性について、手順2で作成した選択肢属性内の対応属性にその値をマップします。
「Gruop Attributes」タブでは、第16.1.7項「動的選択肢の単一エンティティの作成」で作成したものと同じタイプのエンティティ・タイプの配列属性を指定します。
このグループ属性は、図16-7に示されている同等な単一カテゴリの動的選択肢の設定プロセスと同様、動的選択肢の配列エンティティとも呼ばれています。
このレベルでは、動的選択肢データを取得する関数も指定します。関数のパラメータ値を選択する必要があります。これにより、現実世界に対応し1つの具体的なタイプやカテゴリに関連する動的選択肢データのみを関数で取得できます。
前に作成した親選択肢グループの下に子選択肢グループを最初に作成してから、必要な要素を「Group Attributes」タブで入力する必要があります。
子選択肢グループおよびグループ属性を作成する手順は次のとおりです。
第1の子選択肢グループを作成します。
動的選択肢カテゴリごとに1つの子選択肢グループを、必要に応じて追加作成します。
それぞれの子選択肢グループでは、必要な要素とパラメータを「Group Attributes」タブと「Dynamic Choices」タブで設定する必要があります。
この項の以降の手順では、それぞれの子選択肢グループの「Group Attributes」タブで必要な操作について説明します。それぞれの子選択肢グループの「Dynamic Choices」タブで必要な操作の詳細は、第16.1.12.3項を参照してください。
子選択肢グループの「Group Attributes」タブをクリックします。
新しいエンティティ・タイプのグループ属性を作成します。そのタイプは、第16.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前です。
この属性を「Array」として指定します。
「Value」ボックスの右端をクリックして省略記号（...）ボタンを表示します。次に、その省略記号ボタンをクリックして「Value」ウィンドウを開きます。
「Value」ウィンドウで、「Value for array as a whole」オプションを選択します。
「Value Source」で、「Function or rule call」を選択し、第16.1.9項「動的選択肢のデータ取得関数の作成」で作成した関数を選択します。
「Parameters」領域の「Value」でパラメータ値を選択し、入力属性にこの値が含まれるデータソースの対応行が取得されるようにします。
それぞれの子選択肢グループの「Dynamic Choices」タブでは、次の情報を指定する必要があります。
動的選択肢の選択肢グループとして、この選択肢グループを明示的に選択します。
対応する「Group Attributes」タブと「Choice Attributes」タブで設定したグループ属性と選択肢属性を指定します。
各動的選択肢を識別する属性を選択します。
Decision Centerのレポートにおいて動的選択肢が表示される方法を指定します。動的選択肢の数が多い場合、動的選択肢の長いリストをより小さな単位（つまり、フォルダ）に分割できます。その際、フォルダにおいてデータをグループ化する方法を指定します。
動的選択肢のパラメータを指定する手順は次のとおりです。
「Dynamic Choices」タブをクリックします。
「Use Dynamic Choices for this Choice Group」チェック・ボックスを選択します。
「Group attribute containing the list of Entities for choices」で、第16.1.12.2項「子選択肢グループの「Gruop Attributes」タブ」で作成した属性を選択します。
「Choice attribute to assign the entity data」で、第16.1.12.1項「親選択肢グループの「Choice Attributes」タブ」で作成した属性を選択します。
「Entity attribute that contains the choices id」で、抽出される動的選択肢行ごとに一意な識別子である属性を選択します。
「Distribution mode for choices over choice group folders」で、「Spill」または「Even」を選択します。
「Maximum number of choices within one choice group folder on decision center」を選択します。
この項の内容は次のとおりです。
静的選択肢のみを使用するようにアプリケーションが構成されている場合、Decision Centerのレポートへの影響はありません。図16-18の例に示すように、Decision Centerナビゲータには、Decision Studioで定義した選択肢グループ、サブグループおよび静的選択肢が同じ階層レイアウトで表示されます。
動的選択肢はその性質上、Decision Studioで事前に定義できません。動的に抽出された外部データを保持するように選択肢グループを構成し、そこから動的選択肢を提案できます。図16-19は、保険サービスの動的選択肢を表示するように設定された選択肢グループの例を示しています。
Decision Centerでは、実際に提案されモデルの学習データに追加された動的選択肢のみがDecision Centerナビゲータに表示され、パフォーマンス・レポートと分析レポートが生成されます。
Decision Centerでの動的選択肢の表示に影響する別の要因は、動的選択肢グループを定義する際に指定する「Maximum number of choices within one choice group folder on decision center」パラメータです。選択肢の数がこの最大値を超えた場合、選択肢はシステム生成の範囲フォルダの下に表示されます。最大値を超えない場合、選択肢グループ名の直下に表示されます。
範囲フォルダの詳細は、第16.1.13.3項「システム生成の範囲フォルダ」を参照してください。
図16-20のDecision Supportナビゲータ・メニューの例では、次のように表示されています。
モデルの学習データに5つの動的選択肢が提案され追加されています。
選択肢グループ当たりの選択肢の最大数は3です。
それぞれの動的選択肢は、2つのシステム生成フォルダ名のいずれかに表示されます。
各システム生成フォルダの名前は、そのフォルダ内の最初と最後の選択肢の名前を文字列（...）で区切った名前になります。システム生成フォルダは、範囲フォルダとも呼ばれています。
|
注意: 範囲フォルダには、静的選択肢と動的選択肢を混在できます。したがって、範囲フォルダ名を構成する2つの要素は、静的選択肢と動的選択肢のどちらでもかまいません。通常、静的選択肢と動的選択肢は、個別の選択肢グループまたは個別の選択肢グループ階層に保存することをお薦めします。 |
選択肢の総数（静的選択肢およびモデル学習データに提案および追加された動的選択肢）が、選択肢グループ・フォルダに定義した最大値を超えた場合、選択肢はシステム生成のグループまたはサブフォルダに表示されます。最大値を超えない場合は、選択肢グループ名の直下に表示されます。
Decision Studioで動的選択肢の選択肢グループを構成する場合、Decision Centerでの選択肢の表示方法に影響するパラメータは2つあります。
どちらのパラメータも「Dynamic Choices」タブにあり、動的選択肢での選択肢グループの使用を選択した場合のみ有効化されます。パラメータは次のとおりです。
Distribution mode for choices over choice group folders
Maximum number of choices within one choice group folder on decision center
説明を簡略化するために、この項ではこれらのパラメータをそれぞれDistribution modeとMaximum number of choicesで表します。
Maximum number of choicesパラメータは、Decision Centerにおいて、選択肢グループ名の直下またはシステム生成の範囲フォルダの下で、選択肢がどのように表示されるかを決定します。範囲フォルダの詳細は、第16.1.13.3項「システム生成の範囲フォルダ」を参照してください。
|
注意: Decision Centerのレポートでは、範囲フォルダは静的選択肢専用または動的選択肢専用ではありません。つまり、同じ範囲フォルダに静的選択肢と動的選択肢の両方が混在して表示される場合があります。 |
Maximum number of choicesパラメータにより、静的選択肢または動的選択肢に関係なく、各範囲フォルダ内の選択肢の数を制限します。
Distribution modeパラメータにより、範囲フォルダへの移入方法を指定します。
「Spill」モードでは、各範囲フォルダに最大数の選択肢が配分されます。最後の範囲フォルダには、通常、最大数より少ない選択肢が配分されます。
「Even」モードでは、範囲フォルダ全体に選択肢が均等に配分されます。
たとえば、Decision Centerに表示される静的選択肢と動的選択肢の総数が106個で、範囲フォルダ当たりの最大数が25個であると仮定します。
「Spill」モードの場合、各範囲フォルダの配分数は25、25、25、25、6になります。
「Even」モードの場合、各範囲フォルダの配分数は22、21、21、21、21になります。
Decision Centerを使用して、コンテンツ・データベースに定義されている各動的選択肢のレポートを表示できます。これらの動的選択肢は、モデル学習データに実際に提案され追加されたものです。これを行うには、Decision Centerのインライン・サービスにログインし、Decision Centerナビゲータ内で「Decision Process」セクションを開きます。
ここには、定義されている動的選択肢グループが一覧表示され、各動的選択肢グループに対してデータベース・テーブル内で定義されているすべての動的オファーが含まれます。それらは、モデル学習データに提案され追加されたものです。データベース・テーブルの選択肢でモデル学習データに追加されなかったものは、Decision Centerレポートに表示されません。
次の図はDecision Centerレポートの例で、ナビゲータ・ツリーにはDC_Demoの動的選択肢が表示されています。
Oracle RTDに統合されたアプリケーションを実行しているエンド・ユーザーは、外部ルールにより、インライン・サービスを再コンパイルすることなく、Oracle RTDのデシジョン・ロジック自体に実行時に影響を及ぼすことができます。
一般的に、選択肢の適格性ルールや選択肢グループの適格性ルールなど、特定のルールを動的選択肢にアタッチし、インライン・サービスを再コンパイルせずに実行時に変更する必要がある場合に使用されます。
外部ルールは、静的選択肢にもアタッチできます。
この項の内容は次のとおりです。
外部ルール機能の主要コンポーネントは次のとおりです。
外部ルール・エディタ
Oracle RTDは、たとえばHTML iframeを使用して、顧客のフロントエンド型Webベース・アプリケーションにプラグインできる埋込み可能ルール・エディタ・ウィジェットを備えています。
外部ルール・フレームワーク
外部ルール・フレームワークは、次のもので構成されています。
外部ルール関数
コールして外部ルールを評価できるルール評価関数をDecision Studioでユーザーが指定します。関数には、選択肢ルールを評価する関数、選択肢グループ・ルールを評価する関数およびフィルタリング・ルールを評価する関数の3種類があります。
外部ルール・キャッシュ
外部ルール・キャッシュは、外部ルール評価のパフォーマンスを向上するために用意されています。
キャッシュされているルールの新バージョンが評価を目的として発行された場合、失効バージョンは実行されません。ルールのキャッシュ・ミスによりリクエスト全体がタイムアウトになることを防止するために、Oracle RTDには、インライン・サービスの開発者に対して、即時に返すデフォルト・レスポンスを指定するためのメカニズムがあります。
外部ルールAPI
Oracle RTDには、外部ルールに関するJava APIのセットが用意されています。これらは、Decision StudioのJava関数およびロジック・セクションで使用できます。
外部ルールのプロセスの概要
図16-21は、ルールの編集と評価における外部ルールのプロセス・フローを示しています。
外部ルールは、外部コンテンツ・リポジトリにメタデータ形式で格納されます。これはどのような外部データ・システムでもかまいませんが、通常はデータベースです。コンテンツ管理サーバーにより、外部コンテンツ・リポジトリに格納されているルールへの読取りアクセスと書込みアクセスを制御します。
ビジネス・ユーザーは、コンテンツ管理製品によって用意されているサード・パーティ製外部インタフェースに埋め込まれたOracle RTDルール・エディタによりルールを編集します。
外部インタフェースが動的に設定するコンテキストの中で、埋込みルール・エディタでルールを編集する必要があります。たとえば、特定のグループの選択肢、選択肢グループまたはフィルタリング・ルールにルールをアタッチできます。
ルール・エディタで、ビジネス・ユーザーはルールの作成と編集を行います。これらのルールは、動的選択肢、関数、セッション属性など、インライン・サービスで定義されるすべてのオブジェクトを参照できます。
ユーザーがルール・エディタでのルール編集を終了した後、ルールのメタデータは外部インタフェースに渡され、そこから外部コンテンツ・リポジトリに保存されます。
実行時に、インライン・サービスは、外部コンテンツ・リポジトリから編集済の外部ルールにアクセスします。
DC_Demoインライン・サービス・ヘルパー・ファイルの外部インタフェースの例
サード・パーティ製外部インタフェースの出発点として、DC_Demoインライン・サービスには外部ルールのデプロイ・ヘルパーHTMLファイルがOracle RTDに付属しています。
このヘルパーの設定方法および使用方法の詳細は、第16.3項「動的選択肢および外部ルールを使用したエンドツーエンド開発の例」を参照してください。
Oracle RTDは、外部ルールを編集するために埋込み可能なブラウザ・ユーザー・インタフェースを備えています。このルール・エディタ・ウィジェットには、Decision Studioに含まれているルール・エディタと同程度の機能が含まれています。
サード・パーティ製ユーザー・インタフェースと埋込みOracle RTDルール・エディタは、次の操作を実行できる必要があります。
外部ルール・メタデータを埋込みルール・エディタへロードする操作
ロードされた外部ルール・メタデータを埋込みルール・エディタで編集する操作
埋込みルール・エディタにロードされたルールの新しいルール・メタデータを一意のIDとタイムスタンプでエクスポートする操作
その中でルールを編集する必要があるコンテキストを動的に設定する操作。たとえば、特定のグループの選択肢、選択肢グループまたはフィルタリング・ルールにルールをアタッチできます。
埋込みルール・エディタによって発行された各アクションの後でコールされるユーザー定義型コールバックJavascript関数を設定する操作
編集された外部ルールが有効または変更されているかどうかを判定するJavascriptメソッドを提供する操作
外部ルール・フレームワークは、3つのルール評価関数、外部ルール・キャッシュおよびJava APIのセットで構成されています。
この項の内容は次のとおりです。
Decision Studioには、外部ルール・メタデータの評価に使用できるルール評価関数が3つあります。各関数は、渡された外部ルール・メタデータを、選択肢、選択肢グループまたはフィルタリング・ルールに対して評価します。ルールが正常に評価されたかどうかを示すブール値が、各関数から返されます。3つの関数は次のとおりです。
External Rules - Evaluate Choice Eligibility Rule
External Rules - Evaluate Choice Group Eligibility Rule
External Rules - Evaluate Filtering Rule
表16-1は、これらの関数のパラメータを示しています。
|
注意: 適格性ルール関数では、パラメータの1つがルール評価のコンテキストを設定します。たとえば、「External Rules - Evaluate Choice Eligibility Rule」関数のchoiceパラメータでは、外部ルールの評価における特定の選択肢名を指定します。 |
表16-1 外部ルール関数のパラメータ
| 関数 | パラメータ | 説明 |
|---|---|---|
|
External Rules - Evaluate Choice Eligibility Rule |
Rule Metadata |
外部ルールのメタデータ形式を含む属性 |
|
choice |
外部ルールが評価される選択肢 |
|
|
Return value |
ルールが無効の場合のステータス |
|
|
External Rules - Evaluate Choice Group Eligibility Rule |
Rule Metadata |
外部ルールのメタデータ形式を含む属性 |
|
choice group |
外部ルールが評価される選択肢グループ |
|
|
Return value |
ルールが無効の場合のステータス |
|
|
External Rules - Evaluate Filtering Rule |
Rule Metadata |
外部ルールのメタデータ形式を含む属性 |
|
Return value |
ルールが無効の場合のステータス |
「External Rules - Evaluate Choice Eligibility Rule」および「External Rules - Evaluate Choice Group Eligibility Rule」のコール・テンプレートは、次のとおりです。
Value of rule {0} evaluated in context of Choice {1}, {2} if rule is invalid
「External Rules - Evaluate Filtering Rule」のコール・テンプレートは、次のとおりです。
Value of rule {0}, {1} if rule is invalid
ルールに対して関数を選択すると、ルール・エディタにこれらのテンプレートが表示されます。DC_Demoインライン・サービスにおける次の図は、Dynamic Offers選択肢グループの「Choice Eligibility」タブのコール・テンプレートと選択パラメータを示しています。
評価のブロック・オプション
各関数では、評価オプションを設定できます。
オプションの1つに、評価のブロックおよび非ブロックを制御するオプションがあります。評価のブロック・オプションを設定すると、Real-Time Decision Serverが評価結果とともに戻るのをルール評価のコール元では待機します。評価をブロックしない場合は、ルール評価のコール元にデフォルト値が返されます。
デフォルトでは、各外部ルール評価関数は、渡された外部ルール・メタデータを、非ブロック方式で評価します。Decision Studioユーザーは、ブロック・オプションを設定した状態でルールを評価するように、選択した関数のJavaコードを編集することで、この動作を変更できます。
外部ルール関数の変更
外部ルール関数は、個々のインライン・サービスに合せて変更できます。考えられる変更の1つは、ルール評価のブロック動作の変更です。各関数は、渡されたルール・メタデータを、デフォルトでは非ブロック方式で評価します。ブロック動作、デフォルトの戻り値および例外をスローするかどうかを制御するAPIは、次のとおりです。
public interface EvaluationOptions {
public static EvaluationOptions getEvaluationOptions(
boolean defaultReturnValue,
boolean blockEvaluationUntilCached,
boolean propagateExceptions);
}
外部ルール関数は、ルール定義の作成、ルール・エバリュエータとルール・キャッシュの取得、評価オプションの定義およびルールの評価を行うという点で、どの関数も似ています。これらの関数の違いは、それらの対象範囲にあります。つまり、フィルタリング・ルールとして評価するのか、選択肢または選択肢グループを対象にするのかです。次の例は、選択肢評価関数を詳細に示しています。
//compile, cache and evaluate the eligibility rule and return a boolean if (ruleMetadata == null || ruleMetadata.trim().equals("")) return true; RuleDefinition def = new RuleDefinitionImpl(ruleMetadata); RuleEvaluator evaluator = Application.getRuleEvaluator(); RuleCache cache = Application.getRuleCache(); // public static EvaluationOptions getEvaluationOptions( // boolean defaultReturnValue, // boolean blockEvaluationUntilCached, // boolean propagateExceptions) // boolean defaultReturnValue: Return this value when rule evaluation fails // with an exception or while the rule is being compiled // during non-blocking evaluation // boolean blockEvaluationUntilCached: Wait for the rule to be compiled before // returning a value. (May cause integration point timeout) // boolean propagateExceptions: Set to true if ILS developer decides to // handle ValidationException and EvalutionException thrown by // RuleEvaluator.evaluate() instead of returning defaultReturnVal EvaluationOptions opts = EvaluationOptions.getEvaluationOptions( returnValue, false, false); /* The evaluate method attempts to retrieve the compiled bytecode for the rule definition from the cache. If the bytecode for the rule is found in the cache, the rule is evaluated and the resulting boolean is returned. Otherwise, the rule is queued for compilation. Until the rule is compiled and cached, evaluate function behaves as specified by the EvaluationOptions. */ return evaluator.evaluate(choice, def, cache, opts);
// parameters: ruleMetadata, choice // return: boolean
外部ルール関数のいずれかまたはすべてにおいて、getEvaluationOptionsコールのblockEvaluationUntilCachedパラメータとpropagateExceptionsパラメータを変更できます。
|
注意: 各外部ルール関数の変更は、インライン・サービス・レベルで影響します。 |
Real-Time Decision Serverは、ルール評価のパフォーマンスを向上するために、外部ルール・キャッシュを備えています。各インライン・サービス・アプリケーションはそれぞれのルール・キャッシュを保持しており、各アプリケーション・ルール・キャッシュは、クラスタ内の各Real-Time Decision Serverにレプリケートされます。外部ルール・キャッシュ機能によって、次の追加機能が用意されています。
ルール・キャッシュのメンテナンス操作
Decision Studioが用意しているメンテナンス操作関数を使用すると、ルール・キャッシュのサイズを決定したり、キャッシュをクリアできます。これらの関数は次のとおりです。
External Rules - Clear Cache
External Rules - Get Cache Size
External Rules - Remove Inactive Cached Rules
これらの操作は、JConsoleなどのMBeanクライアントによって外部でトリガーし、Real-Time Decision Serverにデプロイされたインライン・サービスのキャッシュをクリアできます。各操作では、外部ルール・キャッシュのJava APIを使用して、インライン・サービスのルール・キャッシュをクリアしたり、ルール・キャッシュの現在のサイズ（バイト単位）を取得します。
ルール評価の非ブロック
この機能により、キャッシュでルールが見つからないと、ルールの評価はブロックされません。1つのルールのコンパイル時間が非常に短い場合、バックグラウンドでルールをコンパイルしながら、キャッシュされていないルールに対してデフォルトのtrue/false値が返されます。
JMXクライアント（JConsole）
ルール・キャッシュのメンテナンス操作は、Sun社のJConsoleなどのJMXクライアントでMBean操作としてアクセスできます。これらのメンテナンス操作は、デプロイされたインライン・サービスごとに作成され、「MBean」→「OracleRTD」→「InlineServiceManager」ツリー・パスにあります。次の図は、DC_DemoのMBean操作を示しています。
外部ルール・フレームワークは、外部ルール・キャッシュ機能とともに導入されたJava APIのセットを備えています。APIは次のJavaインタフェースで用意されており、Decision StudioのJava関数およびロジック・セクションで使用できます。
Rule: 返されるルール・インスタンス。
RuleDefinition: ユーザーによって作成されアプリケーションのルール・エバリュエータに渡されるルール定義。
RuleCache: デプロイされたインライン・サービスによって保持され、インライン・サービスのアプリケーション・インタフェースを介して公開されるルール・キャッシュ。
RuleEvaluator: デプロイされたインライン・サービスによって保持され、インライン・サービスのアプリケーション・インタフェースを介して公開されるルール・エバリュエータ。
EvaluationOptions: ルール・エバリュエータに渡すことができるユーザー定義オプションのコレクション。これらのオプションには、ランタイム例外ポリシーのオプションとエバリュエータのオプションが含まれます。
また、これらのAPIインタフェースの使用時に、2種類の新しい外部ルール例外を検出できます。
ValidationException: ルール・メタデータに問題があるためにルールをコンパイルできない場合にスローされます。
EvaluationException: RuntimeExceptionでルールの実行が失敗したときにスローされます。
次の表は、外部ルール・エラーおよび対応するOracle RTD動作を示しています。動作は、外部ルールの評価関数を変更することで調整できます。
表16-2 外部ルール・エラーおよびOracle RTD動作
| エラー・イベント | Oracle RTDアクション |
|---|---|
|
ルール・コンパイル・エラー - 解析不能なルール・メタデータ - ルール・メタデータがスキーマに従っていない - インライン・サービス属性参照の欠落またはスペルミス - Javaコンパイル・エラー |
if (RuleCache.get(rule) == null) if (propagateExceptions && blockEvaluationUntilCached) /*これらの条件が成立する場合は原因の例外をValidationExceptionでラップしてスローし、ログには記録しない*/ else log.ERROR /*原因のルール・メタデータおよび全体のスタック・トレース*/ else if (propagateExceptions) /*この条件が成立する場合は一般的なValidationExceptionをスローする*/ else log.ERROR /*1行の一般的なエラー・メッセージ*/ |
|
ルール実行エラー - 参照されたインライン・サービス属性が実行時に初期化されない - Rule.execute()のコール先によってスローされた他の例外 |
if (propagateExceptions) /*この条件が成立する場合は原因の例外をEvaluationExceptionでラップしてスローし、ログには記録しない*/ else log.WARN /*原因の1行*/ |
|
ルールUUIDエラー - 解析不能なUUID - 解析不能なタイムスタンプ - UUIDまたはタイムスタンプ（あるいはその両方）の欠落 |
if (propagateExceptions) /*この条件が成立する場合は原因とともにValidationExceptionをスローし、ログには記録しない*/ else log.ERROR /*原因の1行*/ |
次の種類の外部ルールを設定できます。
選択肢グループの適格性ルール
選択肢の適格性ルール
フィルタリング・ルール
適格性ルールは、選択肢または選択肢グループの定義の一部として定義されます。フィルタリング・ルールはスタンドアロン・ルールで、他のOracle RTDオブジェクトとは独立して作成されます。作成したフィルタリング・ルールは、1つ以上のデシジョンにアタッチできます。
この項では、外部ルールの設定プロセスについて説明します。
この項の例は、Oracle RTDとともにリリースされているDC_Demoインライン・サービスに基づいています。
この項の内容は次のとおりです。
外部ルールのメタデータ・バージョンは、外部データソースに格納されます。通常、これはデータベース・テーブルの列で、WEBOFFERSテーブルのRuleMetadata列などがその例です。
ルールが動的選択肢に関係する場合、関連する動的選択肢を、同じ外部データソースの別の列に格納するのが普通です。動的選択肢関連の詳細は、第16.1.4項「動的選択肢の外部データソースの前提条件」を参照してください。
たとえば、SDDS.WEBOFFERSテーブルでは、RuleMetadata列に外部ルールが格納され、Category列およびId列は、動的選択肢の識別で使用されます。
インライン・サービスでは、外部オブジェクトを格納するデータソースを定義してから、そのデータソースに基づいてエンティティを定義します。
外部ルールを必要とする選択肢グループおよび選択肢では、適切なエンティティ属性から導出される選択肢属性を定義する必要があります。
例
ルールの設定の場合、Web Offers DSデータソースはSDDS.WEBOFFERSテーブルに基づき、Web Offers DSから導出されるWeb Offersエンティティは、Rule Metadata属性を含みます。
動的選択肢の設定の場合、Web OffersエンティティはIdを含み、Web Offers Listエンティティ（Web Offers DSから導出される）はCategory属性を含みます。
Dynamic Offers選択肢グループは、その選択肢属性の中にRule Metadataと、動的選択肢定義に必要な属性を含みます。
詳細は、第16.3項「動的選択肢および外部ルールを使用したエンドツーエンド開発の例」を参照してください。
Decision Studioで完全に定義され作成されるルールとは対照的に、外部ルールはその性質上、Decision Studioの外部で作成されます。ただし、次に示すように、オブジェクトに対してDecision Studio内で適切なルール・エディタを起動することで、オブジェクトの外部ルールを定義する必要があります。
外部フィルタリング・ルールの場合は、フィルタリング・ルールを作成するか編集します。概要は、第12.8項「フィルタリング・ルール」を参照してください。
選択肢および選択肢グループの外部ルールの場合は、「Choice Eligibility」タブまたは「Group Eligibility」タブを選択します。概要は、第12.7.5項「適格性ルールについて」を参照してください。
どちらの場合も、ルールのブール文を編集する際、必要な外部ルール評価関数を最初に選択します。
External Rules - Evaluate Choice Eligibility Rule
External Rules - Evaluate Choice Group Eligibility Rule
External Rules - Evaluate Filtering Rule
次に、関数パラメータの値を選択するか入力します。
たとえば、DC_Demoインライン・サービスの場合、Dynamic Offers選択肢グループの外部ルールは、次に示すように「Choice Eligibility」タブで定義します。
外部ルール関数およびパラメータの詳細は、第16.2.3.1項「外部ルール評価関数」を参照してください。
サード・パーティ製外部インタフェース・エディタは、Oracle RTDに接続し、Oracle RTDに十分な情報を渡して、サード・パーティ製インタフェース内でルール・エディタを起動します。詳細は、第16.2.2項「外部ルール・エディタ」を参照してください。
外部インタフェースと埋込みルール・エディタの設定を示している例は、DC_Demoインライン・サービスとともにリリースされる外部ルール開発ヘルパーに基づいています。このヘルパーを生成するファイルは、DC_Demoのdc/jspフォルダにあります。
この項の内容は次のとおりです。
ルール・エディタは、ルール・エディタ・ウィジェット用に、サード・パーティ製エディタのHTML内にHTMLフォームを作成することで、サード・パーティ製インタフェースに埋め込むことができます。
フォームはアクションを/ui/workbenchに設定し、埋込みエディタを囲むiframeを作成する必要があります。
|
注意: クロスドメイン・アクションに対して、コンテンツが別のドメインに基づくフレームまたはウィジェットをJavascriptで操作することを防止するセキュリティ・メカニズムをWebブラウザは備えています。クロスドメインの問題を解決する方法は次のとおりです。
|
表16-3は、各タイプのルールのパラメータを示しています。HTMLフォームは、表16-3に示されている各パラメータの値を使用して、フォーム入力を作成する必要があります。
表16-3 埋込みルール・エディタのパラメータ
| パラメータ | 説明 |
|---|---|
|
app |
インライン・サービスの識別子。 |
|
url |
sdo/editor.jsp これは、エディタのjspファイルのURLです。 変更しないでください。 |
|
object |
ルールを格納しているオブジェクトの識別子。詳細は、表16-4を参照してください。 |
|
type |
ルールを格納しているオブジェクトの型。詳細は、表16-4を参照してください。 |
|
editingAspect |
編集に関する側面。詳細は、表16-4を参照してください。 |
|
callback |
Javascriptコールバック関数の名前。エディタ・イベントが返されるたびに、この関数がコールされます。 |
表16-4は、ルール固有のパラメータのオプションを示しています。
表16-4 ルール固有のパラメータ・オプション
| ルール・タイプ | object | type | editingAspect |
|---|---|---|---|
|
グループの適格性ルール |
グループ識別子 |
choiceGroup |
rule |
|
グループの選択肢の適格性ルール |
グループ識別子 |
choiceGroup |
choiceRule |
|
選択肢の適格性ルール |
選択肢識別子 |
choice |
rule |
|
フィルタリング・ルール |
<このパラメータは省略します> |
"" |
whole |
フォーム入力は、埋込みルール・エディタの初期コンテキストと範囲の作成に役立ちます。
例の詳細は、「DC_Demo外部ルール・ヘルパーでのルール・エディタのIFrameの定義」を参照してください。
埋込みルール・エディタのコンテキストと範囲も、Javascript関数で動的に変更できます。
例の詳細は、「DC_Demo外部ルール・ヘルパーでのルール・エディタのコンテキストと範囲の変更」を参照してください。
埋込みルール・エディタが返すイベントに応答するには、Javascriptコールバック関数を作成する必要があります。埋込みルール・エディタでは、1つのオブジェクト・パラメータでコールバック関数をコールします。このオブジェクトは、発生しているイベント・タイプを指定するtypeプロパティを常に持ちます。各イベント・タイプは、dataプロパティを使用して追加情報を渡す場合があります。
埋込みルール・エディタの現在の状態を表すイベントは、次のとおりです。
editorReady
埋込みルール・エディタによって必要なルール処理が完了した後、editorReadyイベントが起動されます。
データ・オブジェクトのプロパティとして、以降のコールで使用できる関数が3つあります。
ブール値を返すisValid()
ブール値を返すisModified()
文字列値を返すgetXml()
modified
modifiedイベントは、ルールの変更のたびにコールされます。dataプロパティは使用しません。
例の詳細は、「DC_Demo外部ルール・ヘルパーでのコールバック関数の定義」を参照してください。
DC_DemoはOracle RTDとともにリリースされるインライン・サービスで、動的選択肢および外部ルールの設定方法と使用方法を示すものです。
次の各項では、Oracle RTDでDC_Demoが動的選択肢の外部ルールをどのように使用するか、そしてこれが完全なアプリケーション開発プロセスにどのように該当するかについて、その概要を説明します。
要約すると、この項で説明する主な開発手順は次のとおりです。
動的選択肢の適格性評価において、標準の外部ルール評価関数を使用します。
インライン・サービスのWebページに外部ルール・エディタを埋め込みます。
動的選択肢のコンテンツ・データベースを統合します。
外部ルールを編集します。
Decision Centerで動的選択肢のレポートを確認します。
この項の内容は次のとおりです。
動的選択肢は、コンテンツ管理サーバーで管理し、コンテンツ・データベースに格納できます。
DC_Demoインライン・サービスは、その動的選択肢のWebオファーを、WEBOFFERSというテーブルから導出します。このテーブルにはRULEMETADATAという列が含まれています。この列には、選択肢の適格性評価で使用される外部ルール・メタデータが格納されています。テーブルには、親の動的選択肢のIDを指定するCATEGORYという列も含まれています。
データベースの列は、次の図に示すように、Web Offers DSデータソースを介して、Oracle RTDエンティティ・オブジェクト属性にマップされます（サード・パーティ製ツールを使用してWEBOFFERS行を取得）。
動的選択肢は、次のように2つのエンティティ・オブジェクトを作成することで設定されます。
Web Offersエンティティには、1つの動的選択肢の属性情報が格納されます。
Web Offers Listエンティティには、データベースによって取得される動的オファーのセットが格納され、動的選択肢のテーブル情報を記述するデータソースにマップされます。
Dynamic Offers選択肢グループを作成し、その動的選択肢構成を有効にし、選択肢属性データの割当てにWeb Offersエンティティを使用することを設定します。
次の図は、Dynamic Offers選択肢グループの動的選択肢定義を示しています。
次の図は、Web Offersエンティティ属性にマップされる動的選択肢属性を示しています。外部ルール・メタデータが格納され選択肢の適格性の評価に使用されるRule Metadata選択肢属性に注意してください。
動的選択肢の設定方法の概要は、第16.1.5項「Decision Studioにおける動的選択肢の設定の概要」を参照してください。
動的選択肢の適格性評価ルールは、Decision Studioで用意されている外部ルール評価関数を使用することで、動的選択肢属性にルール・メタデータとして格納されている外部ルールを参照できます。動的選択肢グループのDynamic Offersは、次の図に示すように、外部ルール関数の「External Rules - Evaluate Choice Eligibilty Rule」関数を使用します。
Oracle RTDの外部ルール・エディタは、動的選択肢の外部ルールを作成したり編集できるグラフィカル・ユーザー・インタフェースを備えています。
外部インタフェースにルール・エディタを埋め込む方法の概要は、第16.2.5.1項「ルール・エディタ・ウィジェットの定義」を参照してください。
要約すると、ルール・エディタのIframeを設定するフォームでは、次のフォーム入力を定義する必要があります。
app: インライン・サービスの名前（DC_Demoなど）
url: sdo/editor.jsp（エディタのjspファイルのURL）
object: デフォルトの親インライン・サービス選択肢タイプ（AllOffersCGなど）
type: エディタのデフォルト範囲（値: choiceGroup、choice、""はフィルタリング・ルールを表す）
editingAspect: デフォルトの編集側面（値: choiceRule、rule、whole）
callback: エディタ・イベントが返されるたびにコールされるJavascriptコールバック関数
フォーム入力は、埋込みルール・エディタの初期コンテキストと範囲の作成に役立ちます。
DC_Demo外部ルール・ヘルパーでのルール・エディタのIFrameの定義
埋込みルール・エディタをDC_Demo外部ルール・エディタ・ヘルパーに統合する方法の例を次に示します。
<!-- form attributes: name: form name (i.e. editorViewForm) target: form iframe target name (i.e. editorViewIFrame) method: post (required) action: /ui/workbench (editor servlet url; required) --> <form name="editorViewForm" target="editorViewIFrame" method="post" action="/ui/workbench"> <iframe frameborder="0" name="editorViewIFrame"/> <!-- form inputs: app: inline service name (for example, DC_Demo) url: embedded editor url (a constant) object: parent dynamic choice group ID (for example, AllOffersCG) type: rule evaluation scope or context (for example, choiceGroup) editingAspect: editor aspect view (for example, choiceRule) callback: javascript callback function (for example, callbackFunction) --> <input type=hidden name=app value=DC_Demo> <input type=hidden name=url value=sdo/editor.jsp> <input type=hidden name=object value=AllOffersCG> <input type=hidden name=type value=choiceGroup> <input type=hidden name=editingAspect value=choiceRule> <input type=hidden name=callback value=callbackFunction> </form>
DC_Demo外部ルール・ヘルパーでのルール・エディタのコンテキストと範囲の変更
埋込みルール・エディタのコンテキストと範囲も、Javascript関数で動的に変更できます。
DC_Demoにおいて、定義されているJavascript関数を使用してフォーム入力値を変更することで、ルール・エディタのコンテキストと範囲を動的に変更する方法の例を次に示します。
<!--
editorViewForm: name of the form containing the rule editor
editorViewForm.object: ID of the choice or choice group context
editorViewForm.type: scope or context type (for example, choiceGroup)
editorViewForm.editingAspect: editor aspect view (for example, choiceRule)
-->
<script>
groupChoiceScope: function() {
editorViewForm.object.value = "DynamicOfferCG";
editorViewForm.type.value = "choiceGroup";
editorViewForn.editingAspect.value = "choiceRule";
loadRule();
}
</script>
DC_Demo外部ルール・ヘルパーでのコールバック関数の定義
Javascriptコールバック関数は、埋込みルール・エディタが返すイベントに応答します。返されるイベントには、埋込みルール・エディタの現在の状態を表すeditorReadyとmodifiedが含まれます。
DC_Demoのエディタ・ヘルパーのJavascriptコールバック関数であるcallbackFunctionの例を次に示します。この関数は、editorReadyイベントを起動した後に、isValidとisModifiedのブール値およびルール・メタデータをエディタから取得します。
<!--
event.type: the event type name (for example, editorReady)
event.data.isValid: the is valid rule return boolean
event.data.isModified: the is modified rule return boolean
event.data.getXml: returns the metadata of the rule in the editor
-->
<script>
callbackFunction: function(event) {
switch(event.type) {
case "editorReady":
isValid = event.data.isValid;
isModified = event.data.isModified;
getXml = event.data.getXml;
break;
case "modified":
log("is modified");
break;
default:
throw "unexpected callback event type: " + event.type;
}
}
</script>
Oracle RTDでは、DC_Demoインライン・サービスにおいて、external_rules_deployment_helper.htmlおよびdatabase.jspという2つのファイルの形式で外部ルール・エディタ・ヘルパーが用意されています。これらは、Decision Studio内では、dc/jspフォルダ・パスの下にあります。
このエディタ・インタフェースは、外部ルール・エディタ・ウィジェットをサード・パーティ製インタフェースに統合する方法の例として用意されています。このインタフェースを介して、ユーザーは、WEBOFFERSデータベース・テーブルに定義されている動的選択肢の外部ルールを編集できます。
DC_Demoエディタ・ヘルパーは、4つのセクションに分かれています。
「Graphical View」には、実際の外部ルール・エディタが含まれており、これを使用してルールを編集できます。
「Metadata View」には、動的選択肢のテーブル行に保存できる外部ルールのメタデータ・バージョンが格納されています。
「Tabular View」はデータベース管理セクションで、ユーザーはこのセクションを使用して、WEBOFFERSデータベース・テーブルに格納されている動的選択肢の外部ルールを検索、編集および保存できます。
「Log」セクションには、エディタ・ヘルパーで実行されるアクションが表示されます。
次の図はヘルパー・ウィンドウの例で、「Graphical View」には編集されたルールが表示され、「Metadata View」には編集済のルール・メタデータが表示されています。
「Tabular View」にはWEBOFFERSデータベース・テーブルの行が表示されます。重要な列は次のとおりです。
CATEGORY: 動的選択肢グループのIDが格納されます。
RULEMETADATA: 外部ルールのメタデータが格納されます。
「Graphical View」のルール・エディタでルールを編集した後、ユーザーが「generate metadata」リンクをクリックすると、生成されたメタデータが「Metadata View」に表示されます。
外部ルール・エディタの主要な目的の1つは、更新された動的選択肢の外部ルールを、本番環境に戻すことです。通常、サード・パーティのコンテンツ・データベースを使用して、動的選択肢およびその外部ルールを格納します。DC_Demoでは、WEBOFFERSテーブルに動的選択肢が格納されています。このテーブルには、外部ルール・メタデータを格納するために使用するRULEMETADATAという列が含まれています。親の動的選択肢グループのIDを格納するには、CATEGORYという別の列が使用されます。
動的選択肢テーブルの行を選択し行の「Save」リンクをクリックすると、DC_Demo外部ルール・エディタ・ヘルパーでは外部ルールがデータベースに保存されます。
|
注意: 外部ルール・エディタでルールを編集した場合でも、Decision Centerにはデフォルトでは、動的選択肢の適格性ルールが表示されません。 |
Decision Centerを使用して、コンテンツ・データベースに定義されている各動的選択肢のレポートを表示できます。これらの動的選択肢は、モデル学習データに実際に提案され追加されたものです。これを行うには、Decision Centerのインライン・サービスにログインし、Decision Centerナビゲータ内で「Decision Process」セクションを開きます。
ここには、定義されている動的選択肢グループが一覧表示され、各動的選択肢グループに対してデータベース・テーブル内で定義されているすべての動的オファーが含まれます。それらは、モデル学習データに提案され追加されたものです。データベース・テーブルの選択肢でモデル学習データに追加されなかったものは、Decision Centerレポートに表示されません。
次の図はDecision Centerレポートの例で、ナビゲータ・ツリーにはDC_Demoの動的選択肢が表示されています。
Oracle RTDのデシジョン・プロセスでは、デシジョンは母集団のセグメントをターゲットとし、セグメントごとにそのデシジョンにアタッチされているパフォーマンス・メトリックに重み付けすることもできます。
パフォーマンス目標に必要な重み付けの種類に応じて、デシジョンは2種類の方法で設定できます。
事前定義済の重み付け: インライン・サービスで値が指定されます。
カスタムの重み付け: 実行時に値の計算や変更ができます。
インライン・サービスでパフォーマンス目標に対してカスタム重み付けを選択することで、エンド・ユーザーはデシジョン・プロセスに変更を即座に反映でき、異なる母集団のセグメントが実行時に効果的にセグメント化されます。
インライン・サービスでパフォーマンス目標のカスタム重み付けを定義して使用する方法の詳細は、次の各項を参照してください。
