| Oracle® Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイド 11g リリース1 (11.1.1) B72429-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイド 11g リリース1 (11.1.1) B72429-01 |
|
前 |
次 |
この章では、Oracle RTDの基本要素で使用できる拡張機能について説明するとともに、拡張機能を定義して複合的な意思決定プロセスにおいて使用する方法と、対応する外部アプリケーションに拡張機能を統合する方法について説明します。
Oracle RTDは、ビジネス・プロセス・トランザクションの実行時にそのトランザクションからリアルタイムで継続的に学習するプロセスにより、適応型のエンタープライズ・ソフトウェア・ソリューションを実現します。リアルタイムで継続的に学習することで、適応型のソリューションは、各トランザクションと関連ビジネス・プロセスの結果を最適化できます。Oracle RTDのデシジョン・プロセスの基本フレームワークは、次のとおりです。
Oracle RTDでは各相互作用に対して分析的なデシジョンを作成します。
ルールと予測モデルに基づき、Oracle RTDデシジョンでリアルタイムのデータと履歴データを使用して、様々な選択肢から最適な提案を作成します。
最適な提案の作成に際して、潜在的に競合するビジネス目標における最適化をOracle RTDで行います。
第13章「デシジョン・スタジオの要素とAPIについて」の説明のとおり、Oracle RTDインライン・サービスの構成要素はすべて、デシジョン・スタジオを使用して構成されます。本番環境で変更を加える場合は、作業内容によってデシジョン・スタジオまたはデシジョン・センターのいずれかを使用できます。また、Oracle RTDプラットフォームでは、いくつかの主要構成要素が、外部アプリケーションと統合可能な外部オブジェクトとして公開されています。このため、Oracle RTDの作業とオブジェクトを既存のアプリケーションによって管理できます。Oracle RTDは引き続き意思決定エンジンとして機能しますが、管理は他の既存のビジネス・ツールによって行われます。
次の図では、Oracle RTDの意思決定プロセスのフレームワークを形成する標準要素が示されています。また、外部アプリケーションとOracle RTDが連携して、エンド・ユーザーに対して複合的なデシジョン・サービスを実現するうえで重要な一連の入力も示されています。
Oracle RTDの意思決定プロセスの標準要素(デシジョン、エンティティ、選択肢、ルール、モデルおよびパフォーマンス目標)は、デシジョン・スタジオで定義されます。これらの要素の概要は、第12章「デシジョン・スタジオについて」と第13章「デシジョン・スタジオの要素とAPIについて」を参照してください。
Oracle RTDは、外部のコンテンツ管理システムで保持される選択肢など、外部データ・システムのオブジェクトにリアルタイムで変更を適用できます。
Oracle RTDを使用するアプリケーションにより、ルールの作成や変更を行ったり、デシジョン・プロセス全体の導出と制御を行うパフォーマンス目標を変更することで、ユーザーが重要な変更を即座に意思決定プロセスに加えることができます。
この章では、Oracle RTDの基本要素に対してこのような拡張機能を定義し、複合的な意思決定プロセスにおいて使用する方法と、対応する外部アプリケーションにこれらを統合する方法について説明します。
この章には次のトピックが含まれます:
Oracle RTDにおいて、選択肢は代替案の母集団を表します。これらから、抱合せ販売アプリケーションにおける最適なオファーなどの提案を選択できます。
選択肢には、静的選択肢と動的選択肢があります。
静的選択肢の場合、リクエスト元アプリケーションまたは自己学習モデルに提示される選択肢は、Oracle RTD内で完全に定義されます。静的選択肢は、選択肢が既知の場合と、一定期間にわたって一定の場合に役に立ちます。
動的選択肢は、実行時に動的に構築される選択肢です。この選択肢は通常、外部データ・ソースに保持されます。これにより、オファー管理システムで定義したオファーに基づく選択肢など、ソース・システムで選択肢を管理できます。
|
注意: 動的選択肢の主要ソースが外部データ・ソースの場合でも、カスタマイズされたJavaコードで動的選択肢を作成できます。 |
アプリケーションに提示される動的選択肢は時間の経過に応じて変化する場合がありますが、常にアプリケーション・データの最新状態が反映されます。動的選択肢の内容が更新されたときにOracle RTDインライン・サービスを再デプロイする必要はありません。
|
注意: この項では動的選択肢に焦点を絞りますが、選択肢グループは静的選択肢と動的選択肢を組み合せて構成できます。 デシジョンは、選択肢グループにどの種類の選択肢が含まれているかに関係なく、1つ以上の選択肢グループに関連付けることができます。 |
この項には次のトピックが含まれます:
簡単な例として、図17-1のInsurance_Proposals表で説明します。この表はOracle RTD環境の外部で定義され、Oracle RTDが評価して優先度を設定する選択肢に関する情報を保持しています。
Insurance_Proposals表には、様々な保険商品を示す行があり、ChoiceGroupId列のInsuranceProducts共通値で識別されます。動的選択肢をカテゴリ化したりグループ化する列は、動的選択肢を設定する際に重要な必須キー識別子です。
グループにある各行は、AutoInsuranceやDisabilityInsuranceなど、様々な種類の提供対象保険商品を示しています。この各行が動的選択肢に相当します。
1つの列を使用して、グループ内で特定の動的選択肢を識別します。この例では、ChoiceID列が動的選択肢の識別列です。
表の他の列(ProfitMarginなど)は、Oracle RTDによって評価プロセスで使用できます。これらの列も、定義された選択肢属性の値として、提案される動的選択肢の一部としてアプリケーションに送信できます。
要約すると、Oracle RTDにおける設定プロセスとは、動的選択肢に対して選択肢グループを設定し、その選択肢グループを必要な外部データ・ソースまたは外部ソースに関連付けることです。これにより、動的選択肢はOracle RTDによって提案可能になります。
対応する選択肢グループで十分な数の提案を作成してモデルを更新した後は、図17-2に示すように、デシジョン・センターにより様々な動的選択肢のパフォーマンスを分析できます。
動的選択肢の基本的な設計プロセスは、静的選択肢の場合と同様です。最初に選択肢グループを設定してから、選択肢グループの動的選択肢で必要な要素とパラメータを定義する必要があります。設定方法の詳細は、第17.1.5項「デシジョン・スタジオにおける動的選択肢の設定の概要」を参照してください。
この項では、Insurance_Proposalsの例を使用して、設計プロセスの概要を説明します。また、設計プロセスで使用される主な用語についても次に示します。
すべての動的選択肢のセットは、グループ化列またはカテゴリ化列に共通値を持つすべての行と識別されます。Insurance_Proposalsの例では、カテゴリ化列(またはセット識別子)はChoiceGroupId列です。
データベース・セットの各行は、1つの動的選択肢を表します。Insurance_Proposalsの例では、動的選択肢自体がChoiceId列の一意の値によって識別されます。
Oracle RTDで動的選択肢の選択肢グループを定義する場合、動的選択肢が格納されている行のセットにグループをリンクする必要があります。
Oracle RTDで選択肢グループ内の動的選択肢を定義する場合、グループ内の各動的選択肢を、データ・ソース内の対応する動的選択肢の単一行にリンクする必要があります。
最も単純な動的選択肢では、データベース表のすべての行が同じカテゴリに属します。つまり、カテゴリ化列の値がすべて同じです。
同じデータベース表や各種データ・ソースから、異なる動的選択肢を渡すことができます。図17-3に示されている次の例では、Insurance_Proposals表が拡張され、保険商品と保険サービスの両方について選択肢が用意されています。
この場合、Oracle RTDで2つの選択肢グループを設定し、どちらのデータセットもアプリケーションで提案できるようにします。
対応する選択肢グループで十分な数の提案を作成してモデルを更新した後は、保険商品または保険サービス(あるいはその両方)の動的選択肢のパフォーマンスを分析できます。
たとえば、図17-4に示すように、デシジョン・センターにおいて選択肢グループをグループ階層で2つのグループとして設定すると、分析に使用できます。
保険商品の分析結果は、図17-2の結果と同じです。図17-5は、保険サービスに関して同等の分析レポートを示しています。
選択肢グループは選択肢とは異なり、事前に定義する必要があります。つまり、選択肢グループは静的です。レポートやデシジョンの要件をサポートするために必要な場合、動的選択肢を個々の選択肢グループにグループ化できます。
各選択肢グループの設計に関する考慮事項と対象コンポーネントは、第17.1.2項「動的選択肢の基本設計の概要」に説明されているとおりです。
選択肢グループの設定方法の概要は、第17.1.5項「デシジョン・スタジオにおける動的選択肢の設定の概要」を参照してください。
同じデータ・ソースから異なる選択肢グループを設定する方法の詳細は、第17.1.12項「複数カテゴリの選択肢グループの作成」を参照してください。
動的選択肢に必要なデータは、外部のデータ・ソースにあります。
説明を単純にするために、次の説明では、外部データ・ソースがコール元アプリケーションのデータベース表またはビューであると仮定します。
動的選択肢にとって有用にするには、データに次の列が含まれている必要があります。
データのカテゴリ化と抽出で使用する列が1列
動的選択肢が1つの場合は、カテゴリ化列に同じ値を持つ行がすべて抽出され、この列を使用して抽出を制御します。
例:
データベース表のSpecial_EventsにEvent_Type列があります。
Event_Typeの値は、すべての行でPromotion、Product_Launch、Mailshotのいずれかです。
この例では、Event_Typeがカテゴリ化列で、動的選択肢が1つの場合、1つのイベント・タイプの行がすべて(すべてのPromotion行など)、Oracle RTDで抽出されます。
特定の動的選択肢用に抽出される行を一意に識別する列が1列
この列の値はすべての行で一意にする必要はありません。抽出されたデータセット内でのみ一意となります。
抽出されたデータ内で一意な識別子を提供する列であれば、どの列でもかまいません。この列の値には、なんらかのテキスト文字列を含めることをお薦めします。この値は、デシジョン・センター・レポートでヘッダーとして表示されるため、現実の世界で意味を持つ識別子のほうが、数値だけの識別子より有用です。
|
注意: 識別子の列に格納できるのは、英数字の値と空白文字のみです。特殊文字は格納できません。 |
図17-6は、動的選択肢のデータ・ソースとして使用可能な、Web Offersデータベース表の例です。
この表には、次の特徴があります。
カテゴリ化列はCategoryで、すべてのCategory列の共通値はDynamicOffersCGです。
Name列またはID列を、DynamicOffersCGカテゴリの動的選択肢の識別子列として選択できます。
|
注意: 設定プロセスを示す図およびデシジョン・スタジオの画面ショットが、動的選択肢に関連して後述する各項に記載されていますが、それらはOracle RTDとともにリリースされるDC_Demoインライン・サービスに基づいています。 |
デシジョン・スタジオで動的選択肢を設定するプロセスの内容は、次のとおりです。
図17-7は、動的選択肢に対して単純な単一カテゴリの選択肢グループを設定する方法の概要を示しています。図の中の要素については、この章の以降の詳細なプロセス説明の中で説明します。
動的選択肢のデータ・ソースを作成する手順は次のとおりです。
「インポート」ボタンを使用して外部データ・ソースをポイントします。第17.1.4項「動的選択肢の外部データ・ソースの前提条件」で説明した表にマップする新しいデータ・ソースが作成されます。
「出力」列領域で、「複数の行を許可」チェック・ボックスを選択し、動的選択肢に必要なすべての列を選択します。
「入力」列領域で、動的選択肢行をカテゴリ化しグループ化する共通値を含む列を選択します。
|
注意: この段階で、「出力」列から動的選択肢の識別子列を選択する必要はありません。 |
図17-8は、データ・ソースのWeb Offers DSを表のSDDS.WEBOFFERSから設定する方法を示しています。ここでは、Categoryが入力識別子で、他のいくつかの列は動的選択肢自体の属性となります。
動的選択肢のデータは、データ・ソース内にあります。Oracle RTDでは、カテゴリ自体の情報ではなく、特定のカテゴリに関連するすべての情報で構成されるように動的選択肢の単一エンティティを作成する必要があります。
作成したデータ・ソースでは、そのデータ・ソースの出力属性が動的選択肢の単一エンティティのエンティティ属性になります。
動的選択肢の単一エンティティを作成する手順は次のとおりです。
「インポート」機能を使用して、動的選択肢データのエンティティを作成します。これによって、第17.1.4項「動的選択肢の外部データ・ソースの前提条件」で説明したデータ・ソースのすべての「出力」列が取り込まれます。
データ・ソースを選択する場合、インポート時に表示される「選択」ウィンドウの「選択したデータ・ソースのデータ・マッピングのビルド」オプションの選択が解除されていることを確認します。
図17-9は、動的選択肢の単一エンティティであるWeb Offersを設定する「定義」タブを示しています。属性は、データ・ソースであるWeb Offers DSの「出力」列です。
動的選択肢の単一エンティティに加えて、動的選択肢のセット・エンティティを作成する必要があります。このセット・エンティティには、次の属性を含めます。
Key属性: データ・ソースの入力でありカテゴリ化列になります。これには、動的選択肢のデータが含まれます。
配列属性: 動的選択肢の単一エンティティのデータが格納されます。
この配列属性は、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティと同じエンティティ・タイプである必要があります。この配列は、動的選択肢で必要なデータ・ソースから抽出されるデータの、カテゴリ化属性を除くすべての属性のコンテナです。
動的選択肢のセット・エンティティを作成する手順は次のとおりです。
Oracle RTDでエンティティを作成します。
Key属性の場合は、「キーの追加」をクリックし、データ・ソースから動的選択肢のカテゴリ化属性を選択します。
属性を作成し、そのタイプを第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前にします。
このエンティティ・タイプ属性を、「配列」として選択します。
図17-10は、動的選択肢のセット・エンティティであるWeb Offers Listを設定する「定義」タブを示しています。Key属性はデータ・ソースであるWeb Offers DSの「入力」列のCategoryで、2番目の属性はWeb Offersタイプの配列属性です。
「マッピング」タブをクリックし、エンティティ・タイプ属性内の各属性を、元のデータ・ソースで適切な列にマップします。
「データ・ソース入力値」領域で、データ・ソースの入力値として、手順2で作成した動的選択肢カテゴリ化属性を選択します。
図17-11は、動的選択肢のセット・エンティティであるWeb Offers Listを設定する「マッピング」タブを示しています。配列属性内の各属性は、Web Offers DSデータ・ソース内の対応する列にマップされます。「データ・ソース入力値」領域で、入力値に対して選択された属性は、Key属性のCategoryです。
「キャッシュ」タブをクリックします。
「このエンティティ・タイプのキャッシングの有効化」チェック・ボックスを選択します。
|
注意: 動的選択肢のセット・エンティティでは、キャッシュを有効にすることが重要です。キャッシュを有効にすると、新しいセッションのたびにデータ・ソースから動的選択肢を繰り返し取得する状態がReal-Time Decision Serverで回避されます。 |
データベースから動的選択肢データを抽出するには、データ取得を行う関数を作成する必要があります。この関数は、この後の手順で作成する選択肢グループによってコールされます。関数の特徴は次のとおりです。
関数では値を返します。
戻り値は配列型です。
配列要素のデータ型は、前に作成した動的選択肢の単一エンティティです。
前に作成した動的選択肢のセット・エンティティのデータ・ソース入力値と同じパラメータを関数では持ちます。
関数のロジックによって動的選択肢のセット・エンティティの新しいインスタンスが作成され、パラメータを使用して、動的選択肢データを配列に取得します。
動的選択肢のデータ取得関数を作成する手順は次のとおりです。
関数を作成し、「戻り値」チェック・ボックスを選択します。
「配列」オプションを選択して、戻り値が配列型であることを指定します。
「データ型」で、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前を選択します。
「パラメータ」領域で、第17.1.8項「動的選択肢のセット・エンティティの作成」の手順2で作成したKey属性の「名前」と「タイプ」を追加します。
「ロジック」フィールドで、次のようなコードを入力します。エンティティと属性の名前は、必要に応じて変更します。
WebOffersList list = new WebOffersList(); list.setCategory(category); return list.getWebOffers();
ここで:
WebOffersListは、第17.1.8項「動的選択肢のセット・エンティティの作成」で作成したエンティティのオブジェクト名で、単語と単語との間の空白が削除されています。
list.setCategoryでは、第17.1.8項「動的選択肢のセット・エンティティの作成」の手順2で作成したエンティティ・キーを参照します。
getWebOffers()では、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティを参照します。これは、動的選択肢のセット・エンティティ内でマップされているエンティティです。
図17-12は、GetWebOffers関数の定義を示しています。
アプリケーション・データの管理者は、動的選択肢によって、Oracle RTDがアプリケーションに提案する選択肢を制御できます。静的選択肢とは異なり、動的選択肢は、Oracle RTDインライン・サービスとのインタフェースを変更することなく、アプリケーション表において追加、編集および削除ができます。
1つのインライン・サービスで両方の種類の選択肢を使用する必要がある場合、選択肢グループを設計する際に、静的選択肢と動的選択肢を明確に分けることをお薦めします。この項では、動的選択肢の選択肢グループの設計についてのみ説明します。
動的選択肢は次の場所に設計できます。
単一の選択肢グループ内
完全に別個の選択肢グループ内 - つまり、独立した単一選択肢グループの集まり
選択肢グループ階層内
設計に影響を及ぼす要因は数多く存在します。例:
動的選択肢の明示的なセットに関して、顧客が選択肢グループのレポートを必要とするレポート要件がある場合
他のセットとは異なり動的選択肢の1つのセットに、共有される適格性ルールを適用する必要があるデシジョン要件がある場合
この項では、単一の選択肢グループおよび選択肢グループ階層で必要で高レベルな設計手順を示します。
単一の選択肢グループ
すべての動的選択肢を1つの選択肢グループにまとめる必要がある場合、次の方法で設計することをお薦めします。
1つの選択肢グループを設計します。
選択肢グループの「グループ属性」タブ、「選択肢属性」タブおよび「動的選択肢」タブで、必要なパラメータを入力して選択します。
デシジョン・スタジオでは、この選択肢グループにはサブグループがありません。
選択肢グループ階層
設計要件によっては、動的選択肢を選択肢グループ階層にグループ化する場合があります。次の手順は、2レベル階層の設定の概要を示しています。
最上位レベルの選択肢グループの場合、「選択肢属性」タブで、必要なパラメータを入力して選択します。「グループ属性」タブと「動的選択肢」タブでは設定しません。
個々の動的選択肢カテゴリについて、1つ下のレベルの選択肢グループを指定します。下位レベルの各選択肢グループの場合、「グループ属性」タブと「動的選択肢」タブで、必要なパラメータを入力して選択します。「選択肢属性」タブは設定しません。
|
注意: 複数レベルの選択肢グループ階層の最下位レベルの選択肢グループでは、「動的選択肢」タブのパラメータのみ入力する必要があります。 |
デシジョン・スタジオでは、下位レベルの選択肢グループにはサブグループがありません。
動的選択肢を使用するには、1つ以上の選択肢グループを作成する必要があります。動的選択肢が参照するデータが1つのタイプまたはカテゴリに属している場合、単一カテゴリの選択肢グループを作成します。
|
注意: デシジョン・スタジオで動的選択肢の選択肢グループを作成する場合、デシジョン・スタジオのどのウィンドウにも個々の動的選択肢は表示されません。 デシジョン・センターのレポートでは、次の条件を満たす動的選択肢をすべて表示できます。
|
デシジョン・スタジオでは、次のタブで設定するオプションを介して、選択肢が実行時に動的に抽出できるように選択肢グループを構成します。
動的選択肢を構成するタブは、主にこれらのタブです。
|
注意: 「選択肢の適格性」タブを使用して、データ・ソースから抽出する際に動的選択肢データのフィルタリングもできます。 動的選択肢に対して作成される適格性ルールは、同じ動的選択肢グループで取得されるすべての選択肢で共有されます。 |
図17-13は、単一カテゴリの選択肢グループであるDynamic Offersを設定するのに必要な主要要素の例を示しています。
グループ属性の設定は、動的選択肢として取得されるすべてのデータが1つのカテゴリにのみ属していることを表します。ここでは、正確なカテゴリを指定する必要があります。
選択肢属性の設定は、取得される個々の属性を指定します。
グループ属性と選択肢属性は、この単一カテゴリ選択肢グループの「動的選択肢」タブで参照されます。
「グループ属性」タブでは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティ・タイプの配列属性を指定します。単一カテゴリの動的選択肢の設定プロセスに関する概要を示す 図17-7では、この属性は動的選択肢の配列エンティティに対応します。
このレベルでは、動的選択肢データを取得する関数も指定します。関数のパラメータ値を選択する必要があります。これにより、現実世界に対応し1つの具体的なタイプやカテゴリに関連する動的選択肢データのみを関数で取得できます。
選択肢グループを作成しグループ属性を指定する手順は次のとおりです。
選択肢グループを作成します。
「グループ属性」タブをクリックします。
新しいエンティティ・タイプのグループ属性(動的選択肢の配列エンティティ)を作成し、そのタイプを、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前にします。
この属性を「配列」として指定します。
「値」ボックスの右端をクリックして省略記号(...)ボタンを表示します。次に、その省略記号ボタンをクリックして「値」ウィンドウを開きます。
「値」ウィンドウで、「全体的な配列の値」オプションを選択します。
「値ソース」で、「関数またはルール・コール」を選択し、第17.1.9項「動的選択肢のデータ取得関数の作成」で作成した関数を選択します。
「パラメータ」領域の「値」でパラメータ値を選択し、入力属性にこの値が含まれるデータ・ソースの対応行が取得されるようにします。
|
注意: 「値」のこの文字列は、選択肢グループのすべての動的選択肢行をカテゴリ化する、データベース内の値と同じです。 たとえば、第17.1.1項「動的選択肢の簡単な例」で説明したようにInsurance_Proposals表の選択肢グループの設定では、この値はInsuranceProductsです。 |
図17-14は、選択肢グループであるDynamic Offersの「グループ属性」タブを示しています。コールする関数はGetWebOffersです。「パラメータ」領域の「値」には、文字列のDynamicOffersCGが指定されています。
「選択肢属性」タブでは、次を行う必要があります。
第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティと同じタイプのエンティティ・タイプ属性を指定します。
この属性は、単一カテゴリの動的選択肢の設定プロセスに関する概要を示す図17-7では、動的選択肢の行エンティティに対応します。
この動的選択肢の行エンティティ内のコンポーネント属性ごとに、個々の選択肢属性を作成します。作成したばかりの動的選択肢の行エンティティ内の対応属性にこれをマップする必要があります。
選択肢グループの選択肢属性を指定する手順は次のとおりです。
「選択肢属性」タブをクリックします。
新しいエンティティ・タイプの属性(動的選択肢の行エンティティ)を作成します。そのタイプは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前です。
「配列」チェック・ボックスの選択が解除されていることを確認します。
新しい動的選択肢の行エンティティの各属性に対して、対応する選択肢属性を作成します。
前の手順で作成した各選択肢属性について、手順2で作成した動的選択肢の行エンティティ内の対応する属性にその値をマップします。
図17-15は、選択肢グループであるDynamic Offersの「選択肢属性」タブを示しています。選択肢属性は次のとおりです。
1つの動的選択肢行エンティティであるWeb Offer Entity
複数の他の属性: それらの各値は、動的選択肢行エンティティであるWeb Offer Entityの対応属性から導出されます。
「動的選択肢」タブでは、次の情報を指定します。
動的選択肢の選択肢グループとして、この選択肢グループを明示的に選択します。
対応する「グループ属性」タブと「選択肢属性」タブで設定したグループ属性と選択肢属性を指定します。
各動的選択肢を識別する属性を選択します。
デシジョン・センターのレポートで動的選択肢をどのように表示するかを指定します。動的選択肢の数が多い場合、動的選択肢の長いリストをより小さな単位(つまり、フォルダ)に分割できます。その際、フォルダにおいてデータをグループ化する方法を指定します。
動的選択肢のパラメータを指定する手順は次のとおりです。
「動的選択肢」タブをクリックします。
「この選択肢グループの動的選択肢の使用」チェック・ボックスを選択します。
「選択肢のエンティティのリストが含まれるグループ属性」で、第17.1.11.1項「「グループ属性」タブ」で作成した動的選択肢の配列属性を選択します。
「エンティティ・データを割り当てる選択肢属性」で、第17.1.11.2項「「選択肢属性」タブ」で作成した動的選択肢の行属性を選択します。
「選択肢のIDが含まれるエンティティ属性」で、抽出される動的選択肢行ごとに一意な識別子である属性を選択します。
|
注意: 識別子の列に格納できるのは、英数字の値と空白文字のみです。特殊文字は格納できません。 |
「選択肢グループ・フォルダに対する選択肢の分布モード」で、「オーバーフロー」または「偶数」を選択します。
「デシジョン・センター上の1つの選択肢グループ・フォルダ内の選択肢の最大数」を選択します。
動的選択肢を使用するには、1つ以上の選択肢グループを作成する必要があります。同じデータ・ソースから異なるグループのデータを選択できる必要がある場合、複数カテゴリの選択肢グループを作成します。この項では、複数カテゴリの選択肢グループを設定する一般的方法について説明します。
|
注意: デシジョン・スタジオで動的選択肢の選択肢グループを作成する場合、個々の動的選択肢は表示されません。 デシジョン・センターのレポートでは、次の条件を満たす動的選択肢をすべて表示できます。
|
デシジョン・スタジオでは、次のタブで設定するオプションを介して、選択肢が実行時に動的に抽出できるように選択肢グループを構成します。
「グループ属性」タブ
「選択肢属性」タブ
「動的選択肢」タブ
動的選択肢を構成するタブは、主にこれらのタブです。
|
注意: 「選択肢の適格性」タブを使用して、データ・ソースから抽出する際に動的選択肢データのフィルタリングもできます。 動的選択肢に対して作成される適格性ルールは、同じ動的選択肢グループで取得されるすべての選択肢で共有されます。 |
複数の動的選択肢カテゴリを使用するには、選択肢グループの階層を作成し、異なるレベルで選択肢グループの要素を設定する必要があります。
図17-17は、2つのカテゴリを持つ選択肢グループであるIncentive Choicesを設定するのに必要な主要要素の例を示しています。
選択肢グループのIncentive Choicesは親選択肢グループで、DiscountsおよびGiftsという2つの子選択肢グループを持ちます。
最上位レベルの選択肢属性は親選択肢グループで指定します。この選択肢属性は、2つの子選択肢グループに継承されます。
|
注意: 親選択肢グループの場合、または複数レベルの選択肢グループ階層の上位レベル・グループの場合、「動的選択肢」タブで値の入力や選択は行いません。動的選択肢パラメータは、選択肢グループ階層の最下位レベルのグループに対してのみ指定します。 |
それぞれの子選択肢グループにグループ属性を設定すると、異なるカテゴリのデータセットを取得できます。どちらの子選択肢グループの「動的選択肢」タブでも、グループ属性と選択肢属性が参照されます。
このプロセスと、同等な単一カテゴリの選択肢グループの設定を比較するには、図17-7を参照してください。
「選択肢属性」タブでは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したものと同じタイプのエンティティ・タイプの選択肢属性を指定します。
この選択肢属性は、図17-7に示されている同等な単一カテゴリの動的選択肢の設定プロセスと同様、動的選択肢の行エンティティとも呼ばれています。
この動的選択肢行エンティティ内の属性ごとに、個々の選択肢属性を作成します。これを、作成した動的選択肢行エンティティ内の対応属性にマップする必要があります。
親選択肢グループおよび選択肢属性を作成する手順は次のとおりです。
親選択肢グループを作成します。
「選択肢属性」タブをクリックします。
新しいエンティティ・タイプの選択肢属性を作成します。そのタイプは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前です。
「配列」の選択が解除されていることを確認します。
新しいエンティティ・タイプの選択肢属性の各属性について、対応する選択肢属性を作成します。
前の手順で作成した各選択肢属性について、手順2で作成した選択肢属性内の対応属性にその値をマップします。
「グループ属性」タブでは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したものと同じタイプのエンティティ・タイプの配列属性を指定します。
このグループ属性は、図17-7に示されている同等な単一カテゴリの動的選択肢の設定プロセスと同様、動的選択肢の配列エンティティとも呼ばれています。
このレベルでは、動的選択肢データを取得する関数も指定します。関数のパラメータ値を選択する必要があります。これにより、現実世界に対応し1つの具体的なタイプやカテゴリに関連する動的選択肢データのみを関数で取得できます。
前に作成した親選択肢グループの下に子選択肢グループを最初に作成してから、必要な要素を「グループ属性」タブで入力する必要があります。
子選択肢グループおよびグループ属性を作成する手順は次のとおりです。
第1の子選択肢グループを作成します。
動的選択肢カテゴリごとに1つの子選択肢グループを、必要に応じて追加作成します。
それぞれの子選択肢グループでは、必要な要素とパラメータを「グループ属性」タブと「動的選択肢」タブで設定する必要があります。
この項の以降の手順では、それぞれの子選択肢グループの「グループ属性」タブで必要な操作について説明します。それぞれの子選択肢グループの「動的選択肢」タブで必要な操作の詳細は、第17.1.12.3項を参照してください。
子選択肢グループの「グループ属性」タブをクリックします。
新しいエンティティ・タイプのグループ属性を作成します。そのタイプは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前です。
この属性を「配列」として指定します。
「値」ボックスの右端をクリックして省略記号(...)ボタンを表示します。次に、その省略記号ボタンをクリックして「値」ウィンドウを開きます。
「値」ウィンドウで、「全体的な配列の値」オプションを選択します。
「値ソース」で、「関数またはルール・コール」を選択し、第17.1.9項「動的選択肢のデータ取得関数の作成」で作成した関数を選択します。
「パラメータ」領域の「値」でパラメータ値を選択し、入力属性にこの値が含まれるデータ・ソースの対応行が取得されるようにします。
それぞれの子選択肢グループの「動的選択肢」タブでは、次の情報を指定する必要があります。
動的選択肢の選択肢グループとして、この選択肢グループを明示的に選択します。
対応する「グループ属性」タブと「選択肢属性」タブで設定したグループ属性と選択肢属性を指定します。
各動的選択肢を識別する属性を選択します。
デシジョン・センターのレポートで動的選択肢をどのように表示するかを指定します。動的選択肢の数が多い場合、動的選択肢の長いリストをより小さな単位(つまり、フォルダ)に分割できます。その際、フォルダにおいてデータをグループ化する方法を指定します。
動的選択肢のパラメータを指定する手順は次のとおりです。
「動的選択肢」タブをクリックします。
「この選択肢グループの動的選択肢の使用」チェック・ボックスを選択します。
「選択肢のエンティティのリストが含まれるグループ属性」で、第17.1.12.2項「子選択肢グループの「グループ属性」タブ」で作成した属性を選択します。
「エンティティ・データを割り当てる選択肢属性」で、第17.1.12.1項「親選択肢グループの「選択肢属性」タブ」で作成した属性を選択します。
「選択肢のIDが含まれるエンティティ属性」で、抽出される動的選択肢行ごとに一意な識別子である属性を選択します。
|
注意: 識別子の列に格納できるのは、英数字の値と空白文字のみです。特殊文字は格納できません。 |
「選択肢グループ・フォルダに対する選択肢の分布モード」で、「オーバーフロー」または「偶数」を選択します。
「デシジョン・センター上の1つの選択肢グループ・フォルダ内の選択肢の最大数」を選択します。
この項には、次の項目が含まれます。
静的選択肢のみを使用するようにアプリケーションが構成されている場合、デシジョン・センターのレポートへの影響はありません。図17-18の例に示すように、デシジョン・センター・ナビゲータには、デシジョン・スタジオで定義した選択肢グループ、サブグループおよび静的選択肢が同じ階層レイアウトで表示されます。
動的選択肢はその性質上、デシジョン・スタジオで事前に定義できません。動的に抽出された外部データを保持するように選択肢グループを構成し、そこから動的選択肢を提案できます。図17-19は、保険サービスの動的選択肢を表示するように設定された選択肢グループの例を示しています。
デシジョン・センターでは、実際に提案されモデルの学習データに追加された動的選択肢のみがデシジョン・センター・ナビゲータに表示され、パフォーマンス・レポートと分析レポートが生成されます。
デシジョン・センターでの動的選択肢の表示に影響する別の要因は、動的選択肢グループを定義する際に指定する「デシジョン・センター上の1つの選択肢グループ・フォルダ内の選択肢の最大数」パラメータです。選択肢の数がこの最大値を超えた場合、選択肢はシステム生成の範囲フォルダの下に表示されます。最大値を超えない場合、選択肢グループ名の直下に表示されます。
範囲フォルダの詳細は、第17.1.13.3項「システム生成の範囲フォルダ」を参照してください。
図17-20のDecision Supportナビゲータ・メニューの例では、次のように表示されています。
モデルの学習データに5つの動的選択肢が提案され追加されています。
選択肢グループ当たりの選択肢の最大数は3です。
それぞれの動的選択肢は、2つのシステム生成フォルダ名のいずれかに表示されます。
各システム生成フォルダの名前は、そのフォルダ内の最初と最後の選択肢の名前を文字列(...)で区切った名前になります。システム生成フォルダは、範囲フォルダとも呼ばれています。
|
注意: 範囲フォルダには、静的選択肢と動的選択肢を混在できます。したがって、範囲フォルダ名を構成する2つの要素は、静的選択肢と動的選択肢のどちらでもかまいません。 通常、静的選択肢と動的選択肢は、個別の選択肢グループまたは個別の選択肢グループ階層に保存することをお薦めします。 |
選択肢の総数(静的選択肢およびモデル学習データに提案および追加された動的選択肢)が、選択肢グループ・フォルダに定義した最大値を超えた場合、選択肢はシステム生成のグループまたはサブフォルダに表示されます。最大値を超えない場合は、選択肢グループ名の直下に表示されます。
デシジョン・スタジオで動的選択肢の選択肢グループを構成する場合、デシジョン・センターでの選択肢の表示方法に影響するパラメータは2つあります。
どちらのパラメータも「動的選択肢」タブにあり、動的選択肢での選択肢グループの使用を選択した場合のみ有効化されます。パラメータは次のとおりです。
選択肢グループ・フォルダに対する選択肢の分布モード
デシジョン・センター上の1つの選択肢グループ・フォルダ内の選択肢の最大数
説明を簡略化するために、この項ではこれらのパラメータをそれぞれDistribution modeとMaximum number of choicesで表します。
Maximum number of choicesパラメータは、デシジョン・センターにおいて、選択肢グループ名の直下またはシステム生成の範囲フォルダの下で、選択肢がどのように表示されるかを決定します。範囲フォルダの詳細は、第17.1.13.3項「システム生成の範囲フォルダ」を参照してください。
|
注意: デシジョン・センターのレポートでは、範囲フォルダは静的選択肢専用または動的選択肢専用ではありません。つまり、同じ範囲フォルダに静的選択肢と動的選択肢の両方が混在して表示される場合があります。 |
Maximum number of choicesパラメータにより、静的選択肢または動的選択肢に関係なく、各範囲フォルダ内の選択肢の数を制限します。
Distribution modeパラメータにより、範囲フォルダへの移入方法を指定します。
「オーバーフロー」モードでは、各範囲フォルダに最大数の選択肢が配分されます。最後の範囲フォルダには、通常、最大数より少ない選択肢が配分されます。
「偶数」モードでは、範囲フォルダ全体に選択肢が均等に配分されます。
たとえば、デシジョン・センターに表示される静的選択肢と動的選択肢の総数が106個で、範囲フォルダ当たりの最大数が25個であると仮定します。
「オーバーフロー」モードの場合、各範囲フォルダの配分数は25、25、25、25、6になります。
「偶数」モードの場合、各範囲フォルダの配分数は22、21、21、21、21になります。
デシジョン・センターを使用して、コンテンツ・データベースに定義されている各動的選択肢のレポートを表示できます。これらの動的選択肢は、モデル学習データに実際に提案され追加されたものです。これを行うには、デシジョン・センターのインライン・サービスにログインし、デシジョン・センター・ナビゲータ内で「デシジョン・プロセス」セクションを開きます。
ここには、定義されている動的選択肢グループが一覧表示され、各動的選択肢グループに対してデータベース表内で定義されているすべての動的オファーが含まれます。それらは、モデル学習データに提案され追加されたものです。データベース表内の選択肢でモデル学習データに追加されなかったものは、デシジョン・センター・レポートに表示されません。
次の図はデシジョン・センター・レポートの例で、ナビゲータ・ツリーにはDC_Demoの動的選択肢が表示されています。
Oracle RTDに統合されたアプリケーションを実行しているエンド・ユーザーは、外部ルールにより、実行時にインライン・サービスを再コンパイルすることなく、ルール・ロジックを変更できます。これにより、ユーザーのコンテンツが存在する既存のシステムでOracle RTDのルールを管理できます。また、ルール管理プロセスでのみOracle RTDに有効な属性が公開されます。
一般的に、選択肢の適格性ルールや選択肢グループの適格性ルールなど、特定のルールを動的選択肢にアタッチし、インライン・サービスを再コンパイルせずに実行時に変更する必要がある場合に使用されます。
外部ルールは、静的選択肢にもアタッチできます。
この項には次のトピックが含まれます:
外部ルール機能の主要コンポーネントは次のとおりです。
外部ルール・エディタ
Oracle RTDは、たとえばADFウィジェットまたはHTMLとJavaScriptコードを使用して、顧客のフロントエンド型Webベース・アプリケーションにプラグインできる埋込み可能なルール・エディタ・ウィジェットを備えています。
外部ルール・フレームワーク
外部ルール・フレームワークは、次のもので構成されています。
外部ルール関数
コールして外部ルールを評価できるルール評価関数をデシジョン・スタジオでユーザーが指定します。関数には、選択肢ルールを評価する関数、選択肢グループ・ルールを評価する関数、フィルタリング・ルールを評価する関数およびスコアリング・ルールを評価する関数の4種類があります。
外部ルール・キャッシュ
外部ルール・キャッシュは、外部ルール評価のパフォーマンスを向上するために用意されています。
キャッシュされているルールの新バージョンが評価を目的として発行された場合、失効バージョンは実行されません。ルールのキャッシュ・ミスによりリクエスト全体がタイムアウトになることを防止するために、Oracle RTDには、インライン・サービスの開発者に対して、即時に返すデフォルト・レスポンスを指定するためのメカニズムがあります。
外部ルールAPI
Oracle RTDには、外部ルールに関するJava APIのセットが用意されています。これらは、デシジョン・スタジオのJava関数およびロジック・セクションで使用できます。
外部ルールのプロセスの概要
図17-21は、ルールの編集と評価における外部ルールのプロセス・フローを示しています。
外部ルールは、外部コンテンツ・リポジトリにメタデータ形式で格納されます。これはどのような外部データ・システムでもかまいませんが、通常はデータベースです。コンテンツ管理サーバーにより、外部コンテンツ・リポジトリに格納されているルールへの読取りアクセスと書込みアクセスを制御します。
ビジネス・ユーザーは、コンテンツ管理製品によって用意されているサード・パーティ製外部インタフェースに埋め込まれたOracle RTDルール・エディタによりルールを編集します。
外部インタフェースが動的に設定するコンテキストの中で、埋込みルール・エディタでルールを編集する必要があります。たとえば、特定のグループの選択肢、選択肢グループまたはフィルタリング・ルールにルールをアタッチできます。
ルール・エディタで、ビジネス・ユーザーはルールの作成と編集を行います。これらのルールは、動的選択肢、関数、セッション属性など、インライン・サービスで定義されるすべてのオブジェクトを参照できます。
ユーザーがルール・エディタでのルール編集を終了した後、ルールのメタデータは外部インタフェースに渡され、そこから外部コンテンツ・リポジトリに保存されます。
実行時に、インライン・サービスは、外部コンテンツ・リポジトリから編集済の外部ルールにアクセスします。
DC_Demoインライン・サービス・ヘルパー・ファイルの外部インタフェースの例
サード・パーティ製外部インタフェースの出発点として、DC_Demoインライン・サービスには外部ルールのデプロイ・ヘルパーJSPファイルがOracle RTDに付属しています。
このヘルパーの設定方法および使用方法の詳細は、第17.3項「動的選択肢および外部ルールを使用したエンドツーエンド開発の例」を参照してください。
この項では、外部ルール・エディタの主な構成要素と、そのデプロイメントに必要な外部(Oracle RTD以外)の構成要素を図17-22に示します。
次の各項で、各構成要素とその主な機能について説明します。
外部ルール・エディタと外部ルール・エディタ・クライアントの主な機能は次のとおりです。
外部ルール・エディタはADFコンポーネントとしてラップされており、構築用アプリケーションでOracle Application Development Frameworkと一緒に使用できます。JDeveloper拡張として使用できるので、簡単に外部ルール・エディタをADFアプリケーションに統合できます。
外部ルール・エディタ・クライアントは外部ルールをレンダリングします。
ユーザーは、外部ルール・エディタ・クライアントでルールを更新できます。
ルールは更新時に検証されます。
無効なルールをユーザーが保存できないようにするのは、コンテナ・アプリケーションの責任です。
つまり、ユーザーは無効なルールを保存できます。RTD Serverは、外部ルールのロード時にその有効性を確認する必要があります。
外部ルール・エディタ・クライアントでは、無効なルールをユーザーがデータベースの表行に保存できます。RTD Serverはそのルールを初めてロードするときに、ルールを検証します。検証に失敗すると、そのルールを無効としてマークします。そのルールを参照するインライン・サービスは、無効なルールの例外の処理方法に従ってその無効なルールを処理します。
外部ルール・エディタ・クライアントは、旧リリースのOracle RTDにおける静的なルール・エディタと同じ機能をサポートしています。
ユーザーは、リソース・ファイルを手動で更新してラベルをカスタマイズできます。アプリケーション開発者は、リソース・バンドルのベース名を属性値として提供する必要があります。
Oracle Web Services Manager (OWSM)は、セキュリティ・ポリシーの設定と資格証明またはSAMLトークンの検証を担当します。
詳細は、『Oracle Fusion Middleware Webサービスの紹介』と『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。
セキュリティの主な2つの要素は認証と認可です。
認証は、コンテナUIが担当します。コンテナ・ベースの認証またはアプリケーション・レベルの認証を使用できます。
認可は、ロールと権限によって実装されます。JDeveloperで、アプリケーション開発者は外部ルール・エディタへのアクセス権を持つアプリケーション・ロールを定義できます。外部ルール・エディタへのアクセス権が持つロールは、デプロイ時やデプロイ後にも定義できます。
実行時に、ユーザーがコンテナ・アプリケーションのUIにログオンすると、そのユーザーが外部ルール・エディタへのアクセス権を持っている場合にかぎり、外部ルール・エディタがレンダリングされます。
ワークベンチは、外部ルールから参照できるインライン・サービスのすべての要素(エンティティ、セッション・オブジェクト、選択肢、選択肢グループ、関数など)をフェッチする役割を果たします。
外部ルール・エディタ・クライアントとRTD Serverの間のやり取りは、Webサービスを介して行われます。クライアント・アプリケーションのテクノロジ・スタックに応じて、Webサービスの呼出しはJRFテクノロジ・スタックをベースにすることも、SAAJを使用することもできます。
Oracle Web Services Managerによってエンドポイントを保護できます。これは、ワークベンチ・サービスでは必須です。
サーバー側のエンドポイントでは、2種類のセキュリティ・ポリシーを定義できます。ユーザー名トークンとSAMLです。セキュリティ管理者は、Oracle Web Services Managerを使用して、Oracle RTD Workbench Webサービスにセキュリティ・ポリシーを適用できます。
クライアント側のセキュリティは、クライアント・コードで定義されます。このポリシーは、ワークベンチのエンドポイントでサポートされているポリシーと一致する必要があります。アプリケーション開発者は、デプロイ時にこのポリシーを指定します。
サポートされている2種類のポリシーについて:
ユーザー名トークンは、ユーザーに対してユーザー名とパスワードの入力を要求します。外部ルール・エディタの呼出しで資格証明を提供する必要があります(資格証明はValueBinding言語で提供できます)。
|
注意: プロパティ・ファイルは外部ルール・エディタの範囲外です。プロパティ・ファイルを使用するアプリケーション開発者は、プロパティ・ファイルの管理およびアクセスについて責任を負います。 |
SAMLの場合、FusionクライアントとFusion Webサービスのエンドポイント間でSAMLトークンを自動的に伝播する役割をコンテナが果たします。
Fusion以外のOracle RTDクライアントでサポートできるのは、ユーザー名トークンによる認証のみです。SAMLはサポートできません。
ワークベンチWebサービスを保護するセキュリティ・ポリシーは無効にしないことをお薦めします。
Webサービスの呼出しでは、SOAP over HTTPまたはSOAP over HTTPSを使用します。
通常、Oracle RTDの外部ルール・エディタは、Oracle Fusion Middlewareの内側と外側を問わず、複数のアプリケーション・サーバーにデプロイできます。
|
注意: この項では、Oracle Fusion MiddlewareでサポートされているWebLogicアプリケーション・サーバーについて重点的に説明します。 |
この項では、Oracle RTDの外部ルール・エディタでサポートされる一連のトポロジの例を示します。
WebLogicドメインとは、管理サーバーで管理されるリソースおよびサービスの論理的な集まりです。こうしたリソースは管理対象サーバー上で実行でき、クラスタ化トポロジで構成可能です。
特に指定のないかぎり、この項で示すドメインはすべて、Oracle Fusion MiddlewareにデプロイされたWebLogicドメインです。
ADFコンポーネント - 単純な単一ドメイン・デプロイメント
最も単純なデプロイメント・トポロジでは、図17-23に示すように、Oracle RTDの外部ルール・エディタをRTD ServerとともにBIドメイン内にデプロイします。
外部ルール・エディタをADFコンポーネントとして使用できるようにします。これにより、外部ルール・エディタを任意のADF UIに埋め込むことが可能になります。ワークベンチ・サービスのエンドポイントは、OWSMを使用したセキュリティ・ポリシー・セットによって保護されます。詳細は、付録B「Oracle RTD Webサービスおよびクライアント」を参照してください。
ADFコンポーネント - 複数ドメイン・シナリオ
図17-24に示すように、アプリケーションをRTD Serverドメインとは異なるドメインに配置できます。
ADFコンポーネント - 単一ドメイン・デプロイメント(JSPアプリケーションを使用)
図17-25では、ADFベースの外部ルール・エディタがJSPベースの使用側アプリケーションUIに組み込まれています。ADF外部ルール・エディタは、JSPアプリケーションを標準JSFコンポーネントに統合する場合と同じように統合できます。使用側UIは、ADFが正しくインストールされ構成されており、rtd-adf-rt.jarがインクルードされていることを必要とします。このトポロジで使用できるセキュリティ・ポリシーはユーザー名トークンのみです。このデプロイメント・トポロジにクロスサイト・スクリプティングは不要です。
ADFコンポーネント - 複数ドメイン(JSPアプリケーションを使用)
図17-26に示すトポロジは、図17-25と似ていますが、使用側アプリケーションとADF外部ルール・エディタが別のドメインにデプロイされている点が異なります。このトポロジで使用できるセキュリティ・ポリシーはユーザー名トークンのみです。
デシジョン・センターの外部ルール・エディタ - 単一ドメイン・デプロイメント
図17-27では、使用側アプリケーションのHTML DIVタグ内にOracle RTDデシジョン・センター・バージョンの外部ルール・エディタが組み込まれています。このトポロジでサポートされているOWSMセキュリティ・ポリシーはありません。
使用側アプリケーションもOracle RTDデシジョン・センターも同じドメイン内にあるため、クロスサイト・スクリプティングは使用されません。
デシジョン・センターの外部ルール・エディタ - 複数ドメイン
図17-28に示すトポロジは図17-27のものに似ていますが、複数ドメインである点が異なります。このトポロジでは、使用側アプリケーションとOracle RTDデシジョン・センターへのリクエストがすべてプロキシ・サーバーを経由する場合を除き、クロスサイト・スクリプティングが使用されます。
Oracle Fusion Middlewareでサポートされていないアプリケーション・サーバー下の外部ルール・エディタ
図17-29では、Oracle RTDの外部ルール・エディタはアプリケーションで使用されるか、アプリケーション・サーバーに常駐していますが、そのアプリケーションもアプリケーション・サーバーもOracle Fusion Middlewareでサポートされていません。ワークベンチWebサービスのエンドポイントは、Oracle Fusion Middleware下のWebLogicドメインにデプロイされています。図17-28のトポロジと同様に、プロキシ・サーバーを経由する場合以外は、クロスサイト・スクリプティングが使用されます。
外部ルール・エディタを使用するための手順は、通常、次のとおりです。
構築
外部ルール・エディタを組み込むUIを作成します。
統合
コールバックを作成し、外部ルール・エディタとの間でパラメータ(値言語バインディング)をやり取りします。
パッケージ化
外部ルール・エディタを組み込んだアプリケーションを、JDeveloper環境またはJDeveloper以外の環境の必要なクラスとともにパッケージ化します。
デプロイ
同じWebLogicドメイン内または異なるWebLogicドメイン内の、RTD Serverと同じまたは異なるサーバーにデプロイします。
保護
呼出し元の外部ルール・エディタ・クライアントとワークベンチ・サービス・エンドポイントの両方を保護します(該当する場合)。
これらの手順について、次の各項で詳しく説明します
JDeveloperでは、ルール・エディタ・コンポーネントをJDeveloperプロジェクト内のJSFページにドラッグ・アンド・ドロップできます。
JDeveloperプロジェクトでルール・エディタADFコンポーネントを有効化してJSFページに追加する一般的な手順は、次のとおりです。
Oracle JDeveloperの「アプリケーション・ナビゲータ」プルダウン・ボックスで、「新規アプリケーション」を選択します。
アプリケーション名を指定し、「Fusion Webアプリケーション(ADF)」を選択して、「次へ」をクリックします。
これにより、2つのプロジェクトが作成されます。デフォルト名は「モデル」とビュー・コントローラですが、この名前をそのまま使用しても変更してもかまいません。以降の説明では、デフォルトのプロジェクト名を使用します。
「次へ」を2度クリックしてビュー・コントローラ設定画面に移動します。
「プロジェクト・テクノロジ」タブで、「RTD ADF」を「選択済」列へ移動し、「次へ」をクリックします。
「終了」をクリックします。
これにより、空のプロジェクトが作成されます。
外部ルール・エディタADFコンポーネントをJSFページに配置する必要があります。
ビュー・コントローラ・プロジェクトを右クリックし、「新規作成」を選択します。
「新規ギャラリ」ウィンドウの「カテゴリ」ペインで、「Web層」の下にある「JSF」を選択します。
「アイテム」ペインで「JSFページ」を選択し、「OK」をクリックします。
JSFページのファイル名(例: ruledit.jspx)を入力し、「OK」をクリックします。
これにより、空のページが作成され、右側のペインに「コンポーネント・パレット」タブと「リソース・パレット」タブが表示されます。
「コンポーネント・パレット」リストで任意のコンポーネント・エントリを右クリックし、「タグ・ライブラリの編集」を選択します。
RTD ADFコンポーネント11を「選択済のライブラリ」列に移動し、「OK」をクリックします。
これで、「コンポーネント・パレット」タブのプルダウン・リストにRTD ADFコンポーネントというエントリが追加されました。
「コンポーネント・パレット」タブのプルダウン・リストでRTD ADFコンポーネントを選択します。
「コンポーネント・パレット」タブにルール・エディタ・コンポーネントが表示されます。これをJSFページにドラッグ・アンド・ドロップできます。
|
注意: ルール・エディタをJSFページにドラッグ・アンド・ドロップしても、ページは空のままになります。ルール・エディタを他のアプリケーション・オブジェクトと完全に統合するには、JSFページの「ソース」にコードを入力します。詳細は、第17.2.4.2項「統合」を参照してください。 |
Oracle ADFを使用したエンタープライズ開発の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
JDeveloperを使用しない場合の手順は次のとおりです。
web.xmlにサーブレット・マッピングを追加します。
<servlet-mapping>
<servlet-name>resources</servlet-name>
<url-pattern>/rtd/*</url-pattern
</servlet-mapping>
JSPヘッダーにjstl名前空間を追加します。
xmlns:rtd="http://xmlns.oracle.com/rtd/faces/adf"
JSPヘッダーにルール・エディタ・タグを追加します。
<rtd:ruleEditor …
表17-1に、ルール・エディタの設定パラメータを示します。JDeveloperでは、「ソース」ビューで外部ルール・エディタADFコンポーネントを選択すると、「プロパティ・インスペクタ」ウィンドウに次のパラメータがすべて表示されます。
表17-1 外部ルール・エディタの統合用パラメータ
| 名前 | 説明 |
|---|---|
|
inlineService |
対象のインライン・サービス名。 |
|
sdoId |
編集するOracle RTDオブジェクトのID。 |
|
sdoType |
編集するOracle RTDオブジェクトのタイプ。 |
|
editingAspect |
編集するOracle RTDオブジェクトの編集する側面。 |
|
rule |
ルールxml。 |
|
inlineStyle |
ルール・エディタのインラインcssスタイル。 |
|
rtdUrl |
Oracle RTDサーバーのURL。 |
|
idPropagation |
ID伝播を有効にするか無効にするかを指定します。 |
|
username |
ワークベンチとインライン・サービスへのアクセス権を持つOracle RTDユーザーのID。ID伝播でのみ使用されます。 |
|
password |
ユーザー・パスワード。ID伝播でのみ使用されます。 |
|
overrideMessages |
Oracle RTDルール・エディタのデフォルト・メッセージをオーバーライドするリソース・バンドルのベース名。 |
|
partialTriggers |
部分ページ・レンダリングをサポートするADF属性。 |
|
rendered |
ルール・エディタのレンダリングを制御する設定条件。 |
|
workbenchClientType |
JRF (デフォルト)、SAAJまたはRTD3のいずれかを指定します。 (RTD3は、サーバーがRTD 3.xサーバーの場合にのみ選択します) |
また、ルール・エディタのイベントを通知するコールバックJS関数を指定する必要があります。
例
<rtd:ruleEditor id="rule1" inlineService="DC_DEMO" sdoId="AllOffersCG"
sdoType="choiceGroup" editingAspect="choiceRule"
rule="#{backbean.rule}"
inlineStyle="width:100%;height:280px;border:0;"
rtdUrl="http://localhost:8081/" idPropagation="true"
partialTriggers="clFiltering clGroup cbLoadRuleXml"
overrideMessages="override_rtd_resources">
<af:clientListener method="callbackFunction" type="callback"/>
</rtd:ruleEditor>
JDeveloperプロジェクトの場合、RTD ADFコンポーネント11をjstlタグ・ライブラリにインポートする必要があります。JDeveloper以外のプロジェクトの場合、rtd-adf-rt.jarランタイム・ライブラリをWEB-INF/libフォルダにパッケージ化する必要があります。
プロジェクトをFusionターゲットまたはFusion以外のターゲットにデプロイできます。Fusionターゲットの場合、ADF Facesランタイム・ライブラリと構成をパッケージに含める必要があります。
Oracle RTDは、外部ルールを編集するために埋込み可能なブラウザ・ユーザー・インタフェースを備えています。このルール・エディタ・ウィジェットには、デシジョン・スタジオに含まれているルール・エディタと同程度の機能が含まれています。
サード・パーティ製ユーザー・インタフェースと埋込みOracle RTDルール・エディタは、次の操作を実行できる必要があります。
外部ルール・メタデータを埋込みルール・エディタへロードする操作
ロードされた外部ルール・メタデータを埋込みルール・エディタで編集する操作
埋込みルール・エディタにロードされたルールの新しいルール・メタデータを一意のIDとタイムスタンプでエクスポートする操作
その中でルールを編集する必要があるコンテキストを動的に設定する操作。たとえば、特定のグループの選択肢、選択肢グループまたはフィルタリング・ルールにルールをアタッチできます。
埋込みルール・エディタによって発行された各アクションの後でコールされるユーザー定義型コールバックJavascript関数を設定する操作
編集された外部ルールが有効または変更されているかどうかを判定するJavascriptメソッドを提供する操作
外部ルール・フレームワークは、3つのルール評価関数、外部ルール・キャッシュおよびJava APIのセットで構成されています。
この項には、次の項目が含まれます。
デシジョン・スタジオには、外部ルール・メタデータの評価に使用できるルール評価関数が4つあります。各関数は、渡された外部ルール・メタデータを、選択肢、選択肢グループ、フィルタリング・ルールまたはスコアリング・ルールに対して評価します。
外部ルールが正常に評価されると、対応する関数からブール値(適格性ルールおよびフィルタリング・ルール)またはdouble型の値(スコアリング・ルール)のどちらかが返されます。
4つの関数は次のとおりです。
外部ルール - 選択肢適格性ルールの評価
外部ルール - 選択肢グループ適格性ルールの評価
外部ルール - フィルタリング・ルールの評価
外部ルール - スコアリング・ルールの評価
表17-2は、これらの関数のパラメータを示しています。
|
注意: 適格性ルール関数では、パラメータの1つがルール評価のコンテキストを設定します。たとえば、外部ルール - 選択肢適格性ルール関数の「選択肢」パラメータでは、外部ルールの評価における特定の選択肢名を指定します。 |
表17-2 外部ルール関数のパラメータ
| 関数 | パラメータ | 説明 |
|---|---|---|
|
外部ルール - 選択肢適格性ルールの評価 |
ルール・メタデータ |
外部ルールのメタデータ形式を含む属性 |
|
選択肢 |
外部ルールが評価される選択肢 |
|
|
戻り値 |
ルールが無効の場合のステータス |
|
|
外部ルール - 選択肢グループ適格性ルールの評価 |
ルール・メタデータ |
外部ルールのメタデータ形式を含む属性 |
|
選択肢グループ |
外部ルールが評価される選択肢グループ |
|
|
戻り値 |
ルールが無効の場合のステータス |
|
|
外部ルール - フィルタリング・ルールの評価 |
ルール・メタデータ |
外部ルールのメタデータ形式を含む属性 |
|
戻り値 |
ルールが無効の場合のステータス |
|
|
外部ルール - スコアリング・ルールの評価 |
スコアリング・ルール・メタデータ |
外部ルールのメタデータ形式を含む属性 |
|
デフォルト・スコア |
ルールが無効の場合のデフォルト・スコア。デフォルトの戻り値は0。 |
外部ルール - 選択肢適格性ルールの評価および外部ルール - 選択肢グループ適格性ルールの評価のコール・テンプレートは、次のとおりです。
Value of rule {0} evaluated in context of Choice {1}, {2} if rule is invalid
外部ルール - フィルタリング・ルールの評価のコール・テンプレートは、次のとおりです。
Value of rule {0}, {1} if rule is invalid
外部ルール - スコアリング・ルールの評価のコール・テンプレートは、次のとおりです。
Value of rule {0}, {1} if scoring rule is invalid
評価のブロック・オプション
各関数では、評価オプションを設定できます。
オプションの1つに、評価のブロックおよび非ブロックを制御するオプションがあります。評価のブロック・オプションを設定すると、Real-Time Decision Serverが評価結果とともに戻るのをルール評価のコール元では待機します。評価をブロックしない場合は、ルール評価のコール元にデフォルト値が返されます。
デフォルトでは、各外部ルール評価関数は、渡された外部ルール・メタデータを、非ブロック方式で評価します。デシジョン・スタジオ・ユーザーは、ブロック・オプションを設定した状態でルールを評価するように、選択した関数のJavaコードを編集することで、この動作を変更できます。
外部ルール関数の変更
外部ルール関数は、個々のインライン・サービスに合せて変更できます。考えられる変更の1つは、ルール評価のブロック動作の変更です。各関数は、渡されたルール・メタデータを、デフォルトでは非ブロック方式で評価します。ブロック動作、デフォルトの戻り値および例外をスローするかどうかを制御するAPIは、次のとおりです。
public class EvaluationOptions {
public static EvaluationOptions getEvaluationOptions(
boolean defaultReturnValue,
boolean blockEvaluationUntilCached,
boolean propagateExceptions);
public static EvaluationOptions getEvaluationOptions(
double defaultReturnValue,
boolean blockEvaluationUntilCached,
boolean propagateExceptions);
}
外部ルール関数は、ルール定義の作成、ルール・エバリュエータとルール・キャッシュの取得、評価オプションの定義およびルールの評価を行うという点で、どの関数も似ています。これらの関数の違いは、それぞれの対象範囲と戻り値にあります。
対象範囲: 関数がスコアリング・ルールまたはフィルタリング・ルールとして評価するのか、選択肢または選択肢グループを対象にするのか。
戻り値: 適格性関数とフィルタリング関数はboolean型の値を返し、スコアリング関数はdouble型の値を返します。
|
注意: 旧バージョンのRuleEvaluatorインタフェースには、次のような戻り値がboolean型のevaluate()メソッドが用意されていました。
interface RuleEvaluator {
boolean evaluate( Object context,
RuleDefinition def,
RuleCache cache,
EvaluationOptions opts)
throws ValidationException, EvaluationException;
}
evaluate()から次のメソッドに置き換わりましたが、後方互換性を保つためにevaluate()はAPIに残されています。
interface RuleEvaluator {
boolean evaluateEligiblityRule(Object context,
RuleDefinition def,
RuleCache cache,
EvaluationOptions opts)
throws ValidationException, EvaluationException;}
スコアリング・ルールに対応するために、RuleEvaluatorインタフェースが拡張され、double型を返すevaluateScoringRule()メソッドが追加されました。
interface RuleEvaluator {
boolean evaluateScoringRule(Object context,
RuleDefinition def,
RuleCache cache,
EvaluationOptions opts)
throws ValidationException, EvaluationException;}
|
次の例は、選択肢の適格性評価関数(DC_Demoインライン・サービス)を詳細に示したものです。
//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, true); /* 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.evaluateEligibilityRule(choice, def, cache, opts);
// parameters: ruleMetadata, choice // return: boolean
次の例は、スコアリング評価関数(DC_Demoインライン・サービス)の対応する行(コメント行を除く)を詳細に示したものです。
if (ruleMetadata == null || ruleMetadata.trim().equals(""))
return defaultValue;
RuleDefinition def = new RuleDefinitionImpl(ruleMetadata);
RuleEvaluator evaluator = Application.getRuleEvaluator();
RuleCache cache = Application.getRuleCache();
EvaluationOptions opts = EvaluationOptions.getEvaluationOptions(
defaultValue, false, true);
return evaluator.evaluateScoringRule(def, cache, opts);
外部ルール関数のいずれかまたはすべてにおいて、getEvaluationOptionsコールのblockEvaluationUntilCachedパラメータとpropagateExceptionsパラメータを変更できます。
|
注意: 各外部ルール関数の変更は、インライン・サービス・レベルで影響します。 |
Real-Time Decision Serverは、ルール評価のパフォーマンスを向上するために、外部ルール・キャッシュを備えています。各インライン・サービス・アプリケーションはそれぞれのルール・キャッシュを保持しており、各アプリケーション・ルール・キャッシュは、クラスタ内の各Real-Time Decision Serverにレプリケートされます。外部ルール・キャッシュ機能によって、次の追加機能が用意されています。
ルール・キャッシュのメンテナンス操作
デシジョン・スタジオが用意しているメンテナンス操作関数を使用すると、ルール・キャッシュのサイズを決定したり、キャッシュをクリアできます。これらの関数は次のとおりです。
外部ルール - キャッシュのクリア
外部ルール - キャッシュ・サイズの取得
外部ルール - キャッシュされた非アクティブなルールの削除
これらの操作をOracle Fusion Middleware Enterprise ManagerなどのMBeanクライアントによって外部でトリガーして、Real-Time Decision Serverにデプロイされたインライン・サービスのキャッシュをクリアできます。各操作では、外部ルール・キャッシュのJava APIを使用して、インライン・サービスのルール・キャッシュをクリアしたり、ルール・キャッシュの現在のサイズ(バイト単位)を取得します。
ルール評価の非ブロック
この機能により、キャッシュでルールが見つからないと、ルールの評価はブロックされません。1つのルールのコンパイルにかかる非常に短い時間の間、バックグラウンドでルールをコンパイルしながら、キャッシュされていない適格性ルールまたはフィルタリング・ルールに対してデフォルトのtrue/false値が返されます(または、キャッシュされていないスコアリング・ルールに対してデフォルトのスコアであるゼロが返されます)。
Enterprise Managerでのメンテナンス操作
外部ルール・キャッシュのメンテナンス操作は、Enterprise ManagerでMBean操作としてアクセスできます。これらのメンテナンス操作は、デプロイされたインライン・サービスごとに作成され、「MBean OracleRTD」→「InlineServiceManager」ツリー・パスにあります。次の図は、DC_Demo.DevelopmentのMBean操作を示しています。
外部ルール・フレームワークは、外部ルール・キャッシュ機能とともに導入されたJava APIのセットを備えています。APIは次のJavaインタフェースで用意されており、デシジョン・スタジオのJava関数およびロジック・セクションで使用できます。
Rule - 返されるルール・インスタンス。
RuleDefinition - ユーザーによって作成されアプリケーションのルール・エバリュエータに渡されるルール定義。
RuleCache - デプロイされたインライン・サービスによって保持され、インライン・サービスのアプリケーション・インタフェースを介して公開されるルール・キャッシュ。
RuleEvaluator - デプロイされたインライン・サービスによって保持され、インライン・サービスのアプリケーション・インタフェースを介して公開されるルール・エバリュエータ。
EvaluationOptions - ルール・エバリュエータに渡すことができるユーザー定義オプションのコレクション。これらのオプションには、ランタイム例外ポリシーのオプションとエバリュエータのオプションが含まれます。
また、これらのAPIインタフェースの使用時に、2種類の新しい外部ルール例外を検出できます。
ValidationException - ルール・メタデータに問題があるためにルールをコンパイルできない場合にスローされます。
EvaluationException - RuntimeExceptionでルールの実行が失敗したときにスローされます。
次の表は、外部ルール・エラーおよび対応するOracle RTD動作を示しています。動作は、外部ルールの評価関数を変更することで調整できます。
表17-3 外部ルール・エラーおよび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表のEligibilityRuleMetadata列などです。
|
注意: 旧リリースでは、WEBOFFERS表の定義にEligibilityRuleMetadata列とScoringRuleMetadata列が含まれていませんでした。 これらの列がないWEBOFFERS表をご使用の場合は、 詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のDC_Demoサンプル・データの移入に関する項を参照してください。 |
ルールが動的選択肢に関係する場合、関連する動的選択肢を、同じ外部データ・ソースの別の列に格納するのが普通です。動的選択肢関連の詳細は、第17.1.4項「動的選択肢の外部データ・ソースの前提条件」を参照してください。
たとえば、SDDS.WEBOFFERS表では、EligibilityRuleMetadata列とScoringRuleMetadata列に外部ルールのメタデータが格納され、Category列とId列は、動的選択肢の識別に使用されます。
インライン・サービスでは、外部オブジェクトを格納するデータ・ソースを定義してから、そのデータ・ソースに基づいてエンティティを定義します。
外部ルールを必要とする選択肢グループおよび選択肢では、適切なエンティティ属性から導出される選択肢属性を定義する必要があります。
例
ルールの設定の場合、Web Offers DSデータ・ソースはSDDS.WEBOFFERS表に基づき、Web Offers DSから導出されるWeb Offersエンティティは、Eligibility Rule MetadataとScoring Rule Metadataの2つの属性を含みます。
動的選択肢の設定の場合、Web OffersエンティティはIdを含み、Web Offers Listエンティティ(Web Offers DSから導出される)はCategory属性を含みます。
Dynamic Offers選択肢グループは、Rule MetadataやScoring Rule Metadataなどの選択肢属性のほかに、動的選択肢定義に必要な属性を含みます。
詳細は、第17.3項「動的選択肢および外部ルールを使用したエンドツーエンド開発の例」を参照してください。
デシジョン・スタジオで完全に定義され作成されるルールとは対照的に、外部ルールはその性質上、デシジョン・スタジオの外部で作成されます。ただし、次に示すように、オブジェクトに対してデシジョン・スタジオ内で適切なルール・エディタを起動することで、オブジェクトの外部ルールを定義する必要があります。
外部フィルタリング・ルールの場合は、フィルタリング・ルールを作成するか編集します。概要は、第13.9項「フィルタリング・ルール」を参照してください。
選択肢および選択肢グループの外部ルールの場合は、「選択肢の適格性」タブまたは「グループの適格性」タブを選択します。概要は、第13.8.5項「適格性ルールについて」を参照してください。
外部スコアリング・ルールの場合は、スコアリング・ルールを作成するか編集します。概要は、第13.10項「スコアリング・ルール」を参照してください。
どちらの場合も、ルールのブール文を編集する際、必要な外部ルール評価関数を最初に選択します。
外部ルール - 選択肢適格性ルールの評価
外部ルール - 選択肢グループ適格性ルールの評価
外部ルール - フィルタリング・ルールの評価
外部ルール - スコアリング・ルールの評価
次に、関数パラメータの値を選択するか入力します。
|
注意: 外部化されたフィルタリング・ルールおよびスコアリング・ルールは、外部ルール・エディタでの作成時や編集時に選択肢属性を直接参照できません。選択肢属性から値が取得されるセッション属性を参照します。 |
選択肢の適格性の例として、DC_Demoインライン・サービスの場合、Dynamic Offers選択肢グループの外部ルールは、次に示すように「選択肢の適格性」タブで定義しています。
DC_Demoインライン・サービスには、Dynamic Offers選択肢グループの外部スコアリング・ルールの例も含まれています。
「選択肢属性」タブでは、Dynamic Score選択肢属性の値が外部ルール - スコアリング・ルールの評価関数から導出されています。この関数のパラメータは、Scoring Rule MetadataおよびDefault Score選択肢属性です。
「スコア」タブでは、Offer Acceptanceパフォーマンス・メトリックのスコアがDynamic Score選択肢属性から導出されています。
外部ルール関数およびパラメータの詳細は、第17.2.6.1項「外部ルール評価関数」を参照してください。
サード・パーティ製外部インタフェース・エディタは、Oracle RTDに接続し、Oracle RTDに十分な情報を渡して、サード・パーティ製インタフェース内でルール・エディタを起動します。詳細は、第17.2.5項「外部ルール・エディタ・インタフェースの要件」を参照してください。
外部インタフェースと埋込みルール・エディタの設定を示している例は、DC_Demoインライン・サービスとともにリリースされる外部ルール開発ヘルパーに基づいています。このヘルパーを生成するファイルは、DC_Demoのdc/jspフォルダにあります。
この項には次のトピックが含まれます:
ルール・エディタは、ルール・エディタ・ウィジェット用に、サード・パーティ製エディタのHTML内にHTMLフォームを作成することで、サード・パーティ製インタフェースに埋め込むことができます。
フォームはアクションを/ui/workbenchに設定し、埋込みエディタを囲むフォームをHTML DIVタブ内に作成する必要があります。
|
注意: クロスドメイン・アクションに対して、コンテンツが別のドメインに基づくフレームまたはウィジェットをJavascriptで操作することを防止するセキュリティ・メカニズムをWebブラウザは備えています。 クロスドメインの問題を解決する方法は次のとおりです。
|
表17-4は、各タイプのルールのパラメータを示しています。HTMLフォームは、表17-4に示されている各パラメータの値を使用して、フォーム入力を作成する必要があります。
表17-4 埋込みルール・エディタのパラメータ
| パラメータ | 説明 |
|---|---|
|
app |
インライン・サービスの識別子。 |
|
url |
sdo/editor.jsp これは、エディタのjspファイルのURLです。 変更しないでください。 |
|
object |
ルールを格納しているオブジェクトの識別子。詳細は、表17-5を参照してください。 |
|
type |
ルールを格納しているオブジェクトの型。詳細は、表17-5を参照してください。 |
|
editingAspect |
編集に関する側面。詳細は、表17-5を参照してください。 |
|
hideInheritedRules |
継承されたルールを埋込みルール・エディタに表示しません。 |
|
callback |
Javascriptコールバック関数の名前。エディタ・イベントが返されるたびに、この関数がコールされます。 |
表17-5は、ルール固有のパラメータのオプションを示しています。
表17-5 ルール固有のパラメータ・オプション
| ルール・タイプ | object | type | editingAspect |
|---|---|---|---|
|
グループの適格性ルール |
グループ識別子 |
choiceGroup |
rule |
|
グループの選択肢の適格性ルール |
グループ識別子 |
choiceGroup |
choiceRule |
|
選択肢の適格性ルール |
選択肢識別子 |
choice |
rule |
|
フィルタリング・ルール |
<このパラメータは省略します> |
""またはeligibilityRule |
whole |
|
スコアリング・ルール |
<このパラメータは省略します> |
valueRule |
rule |
フォーム入力は、埋込みルール・エディタの初期コンテキストと範囲の作成に役立ちます。
例の詳細は、「DC_Demo外部ルール・ヘルパーでのルール・エディタの定義」を参照してください。
埋込みルール・エディタのコンテキストと範囲も、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ページに外部ルール・エディタを埋め込みます。
動的選択肢のコンテンツ・データベースを統合します。
外部ルールを編集します。
デシジョン・センターで動的選択肢のレポートを確認します。
この項には次のトピックが含まれます:
動的選択肢は、コンテンツ管理サーバーで管理し、コンテンツ・データベースに格納できます。
DC_Demoインライン・サービスは、その動的選択肢のWebオファーを、WEBOFFERSという表から導出します。この表には次の列が表示されます。
ELIGIBILITYRULEMETADATA: 選択肢の適格性評価で使用される外部ルール・メタデータが格納されています。
SCORINGRULEMETADATA: スコアリング・ルールの評価で使用される外部ルール・メタデータが格納されています。
CATEGORY: 親にあたる動的選択肢のIDを指定します。
|
注意: 旧リリースでは、WEBOFFERS表の定義にEligibilityRuleMetadata列とScoringRuleMetadata列が含まれていませんでした。 これらの列がないWEBOFFERS表をご使用の場合は、 詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のDC_Demoサンプル・データの移入に関する項を参照してください。 |
データベースの列は、次の図に示すように、Web Offers DSデータ・ソースを介して、Oracle RTDエンティティ・オブジェクト属性にマップされます。
動的選択肢は、次のように2つのエンティティ・オブジェクトを作成することで設定されます。
Web Offersエンティティには、1つの動的選択肢の属性情報が格納されます。
Web Offers Listエンティティには、データベースによって取得される動的オファーのセットが格納され、動的選択肢の表情報を記述するデータソースにマップされます。
Dynamic Offers選択肢グループを作成し、その動的選択肢構成を有効にし、選択肢属性データの割当てにWeb Offersエンティティを使用することを設定します。
次の図は、Dynamic Offers選択肢グループの動的選択肢定義を示しています。
次の図は、Web Offersエンティティ属性にマップされる動的選択肢属性を示しています。Eligibility Rule MetadataとScoring Rule Metadataの2つの選択肢属性に注目してください。これらは、外部ルール・メタデータの格納に使用され、選択肢の適格性とスコアリングの評価に使用されます。
動的選択肢の設定方法の概要は、第17.1.5項「デシジョン・スタジオにおける動的選択肢の設定の概要」を参照してください。
動的選択肢の適格性評価ルールは、デシジョン・スタジオで用意されている外部ルール評価関数を使用することで、動的選択肢属性にルール・メタデータとして格納されている外部ルールを参照できます。たとえば、動的選択肢グループのDynamic Offersは、次の図に示すように、外部ルール関数の外部ルール - 選択肢の適格性ルールの評価を使用します。
Oracle RTDの外部ルール・エディタは、動的選択肢の外部ルールを作成したり編集できるグラフィカル・ユーザー・インタフェースを備えています。
外部インタフェースにルール・エディタを埋め込む方法の概要は、第17.2.8.1項「ルール・エディタ・ウィジェットの定義」を参照してください。
要約すると、ルール・エディタを設定するフォームでは、次のフォーム入力を定義する必要があります。
app - インライン・サービスの名前(DC_Demoなど)
url - sdo/editor.jsp(エディタのjspファイルのURL)
object - デフォルトの親インライン・サービス選択肢タイプ(AllOffersCGなど)
type: エディタのデフォルト範囲(値: choiceGroup、choice、""はフィルタリング・ルールを表す)
editingAspect: デフォルトの編集側面(値: choiceRule、rule、whole)
hideInheritedRules: 継承されたルールを外部ルール・エディタに表示しません。
callback - エディタ・イベントが返されるたびにコールされるJavascriptコールバック関数
フォーム入力は、埋込みルール・エディタの初期コンテキストと範囲の作成に役立ちます。
DC_Demo外部ルール・ヘルパーでのルール・エディタの定義
埋込みルール・エディタを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=hideInheritedRules value="true"> <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.jspおよびdatabase.jspという2つのファイルの形式で外部ルール・エディタ・ヘルパーが用意されています。これらは、デシジョン・スタジオ内では、dc/jspフォルダ・パスの下にあります。
このエディタ・インタフェースは、外部ルール・エディタ・ウィジェットをサード・パーティ製インタフェースに統合する方法の例として用意されています。このインタフェースを介して、ユーザーは、WEBOFFERSデータベース表に定義されている動的選択肢の外部ルールを編集できます。
DC_Demoエディタ・ヘルパーは、4つのセクションに分かれています。
グラフィカル・ビューには、実際の外部ルール・エディタが含まれており、これを使用してルールを編集できます。
メタデータ・ビューには、動的選択肢の表行に保存できる外部ルールのメタデータ・バージョンが格納されています。
表形式ビューはデータベース管理セクションで、ユーザーはこのセクションを使用して、WEBOFFERSデータベース表に格納されている動的選択肢の外部ルールを検索、編集および保存できます。
「ログ」セクションには、エディタ・ヘルパーで実行されるアクションが表示されます。
次の図はヘルパー・ウィンドウの例で、グラフィカル表示には編集されたルールが表示され、メタデータ・ビューには編集済のルール・メタデータが表示されています。
表形式ビューにはWEBOFFERSデータベース表の行が表示されます。重要な列は次のとおりです。
CATEGORY: 動的選択肢グループのIDが格納されます。
ELIGIBILITYRULEMETADATA
SCORINGRULEMETADATA
グラフィカル・ビューのルール・エディタでルールを編集した後、ユーザーがメタデータの生成リンクをクリックすると、生成されたメタデータがメタデータ・ビューに表示されます。
外部ルール・エディタの主要な目的の1つは、更新された動的選択肢の外部ルールを本番環境に戻すことです。通常、サード・パーティのコンテンツ・データベースを使用して、動的選択肢およびその外部ルールを格納します。DC_Demoでは、WEBOFFERSという表に動的選択肢が格納されています。この表には、ELIGIBILTYRULEMETADATA列とSCORINGRULEMETADATA列があります。これらの列を使用して外部ルール・メタデータが格納されています。また、CATEGORYという別の列を使用して、親の動的選択肢グループのIDが格納されています。
動的選択肢表の行を選択し行の「保存」リンクをクリックすると、DC_Demo外部ルール・エディタ・ヘルパーでは外部ルールがデータベースに保存されます。
|
注意: 外部ルール・エディタでルールを編集した場合でも、デシジョン・センターにはデフォルトでは、動的選択肢のルールが表示されません。 |
デシジョン・センターを使用して、コンテンツ・データベースに定義されている各動的選択肢のレポートを表示できます。これらの動的選択肢は、モデル学習データに実際に提案され追加されたものです。これを行うには、デシジョン・センターのインライン・サービスにログインし、デシジョン・センター・ナビゲータ内で「デシジョン・プロセス」セクションを開きます。
ここには、定義されている動的選択肢グループが一覧表示され、各動的選択肢グループに対してデータベース表内で定義されているすべての動的オファーが含まれます。それらは、モデル学習データに提案され追加されたものです。データベース表内の選択肢でモデル学習データに追加されなかったものは、デシジョン・センター・レポートに表示されません。
次の図はデシジョン・センター・レポートの例で、ナビゲータ・ツリーにはDC_Demoの動的選択肢が表示されています。
Oracle RTDのデシジョン・プロセスでは、デシジョンは母集団のセグメントをターゲットとし、セグメントごとにそのデシジョンにアタッチされているパフォーマンス・メトリックに重み付けすることもできます。
パフォーマンス目標に必要な重み付けの種類に応じて、デシジョンは2種類の方法で設定できます。
事前定義済の重み付け: インライン・サービスで値が指定されます。
カスタムの重み付け: 実行時に値の計算や変更ができます。
インライン・サービスでパフォーマンス目標に対してカスタム重み付けを選択することで、エンド・ユーザーはデシジョン・プロセスに変更を即座に反映でき、異なる母集団のセグメントが実行時に効果的にセグメント化されます。
インライン・サービスでパフォーマンス目標のカスタム重み付けを定義して使用する方法の詳細は、次の各項を参照してください。
