| 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 |
|
前 |
次 |
デシジョン・スタジオの要素はデシジョン・スタジオ内で構成され、ロジックがJavaスクリプトレットの形式で追加されます。この章では、各要素のプロパティおよび要素に含まれるJavaスクリプトレット(存在する場合)について、例とともに説明します。
この章には次のトピックが含まれます:
Oracle RTDの意思決定プロセスは、組織に関連する全体的パフォーマンス目標、その目標を測定するパフォーマンス・メトリック、各選択肢のスコアリングに必要なアクション、および母集団のセグメントに基づくそのスコアの重み付けをそれぞれ考慮したフレームワークをベースとしています。
このフレームワークには、次のような要素があります。
パフォーマンス目標
意思決定
選択肢グループおよび選択肢
フィルタリング・ルール
スコアリング・ルール
予測モデル
これらの要素が通常のOracle RTD意思決定プロセスに取り込まれ、インライン・サービスの基礎を形成する様子を次の図に示します。
各入力の拡張機能により外部アプリケーションとOracle RTDで複合的なデシジョン・サービスをエンド・ユーザーに提供できる仕組みの詳細は、第17章「外部化されたオブジェクト管理」を参照してください。
この項では、Oracle RTDの一般的な意思決定プロセス・フローについて説明します。
Oracle RTDの意思決定プロセスは、次の要素を考慮したフレームワークに基づいています。
組織の全体的なパフォーマンス目標
パフォーマンス目標に応じた各選択肢のスコアリング方法
母集団のセグメントに基づくパフォーマンス目標の重み付け
デシジョンは、アドバイザによって選択肢をスコアリングするために呼び出され、選択肢グループの中から1つまたは複数の選択肢を返します。デシジョンの設定には、選択肢の選択元である選択肢グループが少なくとも1つと、選択肢をスコアリングするための関数またはルールが必須です。実行時にデシジョンは、それぞれの選択肢グループにある適格な選択肢をすべて収集します。その後、アドバイザによって各選択肢がスコアリングされ、最終的にランク付けられた順序が決定されて送り返されます。
図13-1は、Oracle RTDの基本的なプロセスを示したもので、セッションの開始と終了、およびOracle RTD意思決定プロセスの各手順で構成されています。
|
注意: この項の例では、Oracle RTDに付属のCrossSellインライン・サービスの要素に言及します。 |
次の手順では、必要なデータを取得してデシジョンを処理するプロセス全体の様々なステージを示します。
システムがセッションを開始します。
ユーザーがログオンし、外部アプリケーションがOracle RTDに接続し、Oracle RTDがセッションを確立します。
通常、外部アプリケーションがユーザーに関する情報をできるだけ多くの収集し、 1つまたは複数のインフォーマントを使用してその情報をOracle RTDに渡します。
Oracle RTDが、外部アプリケーションに関連付けられたインライン・サービスで定義されているデータ・ソースとエンティティからさらに情報を抽出する場合もあります。
アドバイザがデシジョンを呼び出します。
アドバイザ・コールによるリクエストによって意思決定プロセスが開始されます。関連する選択肢グループごとに、意思決定の評価対象となる一連の選択肢が決定されます。
Oracle RTDの意思決定プロセスの主な目的は、最適な選択肢を評価してアプリケーションに提案することです。
「最適な選択肢」とは
アプリケーションの目的に最も適った、最も妥当な選択肢です。
アプリケーションの「目的」とは
次のようなパフォーマンス目標です。
Revenue
Customer Retention
パフォーマンス目標は、それぞれ相反する目標という可能性があります。そのため、相反する可能性のある目標同士の折り合いをつける手段が必要になります。
各選択肢の適格性が決定されます。
選択肢によっては、現実の世界においては不合理な場合もあります。このため、選択肢を除外する仕組みが意思決定プロセスの早い段階で必要になります。それが適格性ステージです。
選択肢の適格性ルールが起動され、潜在的な多くの選択肢の中から、意思決定プロセスの次のステージに進む選択肢が決定されます。
必要に応じて、ユーザー・セグメントが決定されます。
選択肢の妥当性は、最終的に選択肢の提案を受けるユーザーのグループによって異なる可能性があります。そのため、様々なユーザー・セグメントを定義します。その特性は、フィルタリング・ルールで明示的に定義するか、またはデータをフィルタリングするカスタム関数によって暗黙的に定義します。
たとえば、Segment to Retainフィルタリング・ルールは次のように定義できます。
Segment to Retainがtrueになる条件
次のすべて:
1. session / customer / callsAbandoned >= 6
2. session / customer / tenure >= 2
[セグメントは常に必要なわけではありません。「最適な」選択肢がすべてのユーザーに最適という場合もあります。実際には、Oracle RTDにはDefaultセグメントがあります。つまり、他にセグメントがない場合は、すべてのユーザーが次のステージ(スコアリング・ステージ)の対象になります。]
通常、明示的なフィルタリング・ルールによってユーザーの母集団がセグメント化されます。そのセグメントに基づいて、それぞれのパフォーマンス目標に指定された重み付けを使用して、適格な各選択肢がスコアリングされます。
セグメントと重み付けされたパフォーマンス目標
一連の適格な選択肢の中で最適な選択肢はどれでしょうか。
デシジョンを設定するときに、ターゲット・セグメント、つまり対象となるセグメントを指定します。実行時の意思決定プロセスでOracle RTDはユーザーの該当する(最初の)セグメントを設定リストから判断します。
デシジョンの設定には、デシジョンにどのパフォーマンス目標を適用するかも指定します。
次に、各セグメントにどのパフォーマンス目標が関係するかを指定し、セグメントにおける各パフォーマンス目標の相対的な優先順位をつけます。
つまり、セグメントごとに次の要素を指定します。
適用するパフォーマンス目標(複数指定可)
そのセグメントに対して選択した各パフォーマンス目標の重み付け係数
重み付け係数は、実行時にスコアリング・プロセスで使用されます。
Offersデシジョンには、Segment to RetainとDefaultという2つのセグメントがあり、インライン・サービスにはCustomer RetentionとRevenueという2つのパフォーマンス目標があります。
Segment to Retainセグメントには、各パフォーマンス目標の重み付けを次のよう設定できます。
Customer Retentionの重み付け = 70%
Revenueの重み付け = 30%
Defaultセグメントには、各パフォーマンス目標の重み付けを次のよう設定できます。
Customer Retentionの重み付け = 30%
Revenueの重み付け = 70%
各選択肢がスコアリングされます。
要約すると、関連付けられた各パフォーマンス目標に適格なすべての選択肢がスコアリングされます。
詳細説明:
デシジョンの最終目的は、最適な選択肢を見つけることです。選択肢を比較するとき、各選択肢の数値スコアが生成され、スコアによって選択肢がランク付けされ、最高スコアの選択肢が選択されます。
Oracle RTDでは、現実世界の多様な要件に対応できるように 様々なタイプのスコアリング・モデルがサポートされています。
最も単純なケースでは、各選択肢が一定の定数スコアを持ちます。たとえば、プレミアム・サービスが10、標準サービスが8、基本サービスが6などです。
選択肢のスコアは、選択肢に密に関連する属性から直接導出できます。たとえば、営業戦略として、各Product Offer選択肢のスコアを、その商品の現在の利益率に設定できます。
より複雑な現実世界の要件も、スコアリング・ルール、関数およびモデルからの予測値を使用することで実現できます。
スコアリング方法は、パフォーマンス目標に対する選択に応じて、選択肢および選択肢グループに適用されます。複数のパフォーマンス目標を持つ1つ選択肢に対して複数のスコアリング方法を設定できます。たとえば、Gold選択肢のスコアを、Revenueパフォーマンス目標については40、Customer Retentionパフォーマンス目標については10にすることができます。
スコアリング・ルール
スコアリング・ルールは、通常、1つ以上の条件とそれに関連付けられたスコアで構成されます。たとえば、クレジット・カードの利率に関するスコアは次のように定義できます。
表13-1 Credit Protection Retentionスコアリング・ルール
| 条件 | 値 |
|---|---|
|
条件 次のすべて: 1. session / customer / hasCreditProtection = "YES" |
その場合 0.0 |
|
それ以外の場合... |
値は次のとおりです: 7.0 |
この例は、限定条件が1つのスコアリング・ルールです。通常、スコアリング・ルールでは、様々な属性を持つ複数の条件を組み合せることができます。一方、単純なスコアリング・ルールでは、単一の定数値を条件なしで指定できます。
関数
関数は、その性質上、現実世界の多様なシナリオや特殊な状況を扱うことができます。したがって、選択肢のスコアを生成する最も柔軟性の高い方法です。唯一の要件として、スコアリングに使用する関数はすべて数値を返す必要があります。
モデル予測
スコアを、過去および現在のリアルタイムの経験的データに関連付け、Oracle RTDモデルに格納されているデータから導出できます。モデル予測をスコアリング方法として定義した場合、選択肢を予測するにはモデル内に十分なデータが必要です。
スコアリング方法を選択肢に関連付ける例
インライン・サービスでスコアリング方法を選択肢に関連付ける標準的な方法は、特定の選択肢または選択肢グループの「スコア」タブを使用する方法です。
たとえば、Offers選択肢グループでは、Credit Protection選択肢に2種類のスコアリング方法が(パフォーマンス目標ごとに1つずつ)定義されています。
表13-2 Credit Protection選択肢のスコア定義
| パフォーマンス・メトリック | 継承したスコア(継承元) | スコア |
|---|---|---|
|
Custom Retention |
- |
Credit Protection Retention |
|
Revenue |
OfferAcceptanceによる予測:Profit Margin (Offers)を乗算したPurchased |
- |
Credit Protection選択肢のスコアは次のように評価されます。
Custom Retentionパフォーマンス目標では、スコアリング・ルールCredit Protection Retentionからスコアが導出されます。
Revenueパフォーマンス目標では、 肯定的結果のPurchasedにOffers選択肢グループの属性Profit Marginを掛けて求めたOfferAcceptanceモデルの予測からスコアが導出されます。
選択肢のスコアに重みが付けられます。
ユーザーのセグメントに明示的または暗黙的に適用される適格な各選択肢のスコアが計算されます。
スコアリング・ステージに到達した選択肢ごとに、セグメントとパフォーマンス目標の組合せに対して指定した必要な重み付けを適用して、各パフォーマンス目標のスコアが評価されます。詳細は、「セグメントと重み付けされたパフォーマンス目標」を参照してください。
各選択肢の合計スコアは、重み付けされたすべてのパフォーマンス目標のスコアの合計です。
合計スコアが最も高い選択肢が最適な選択肢となります。
1つまたは複数の選択肢が外部アプリケーションに返されます。
選択肢の名前と外部アプリケーションが必要とする指定の選択肢属性を渡すことで、Oracle RTDは外部アプリケーションに1つまたは複数の選択肢を返します。外部アプリケーションは返された選択肢を表示するか、適宜に情報を処理します。
セッション情報が更新されます。
この手順は、意思決定プロセスのどのステージでも実行できます。その主な結果として、特定のセクションに関する新しい情報でOracle RTDサーバーが更新されます。
また、指定の統合点またはセッション終了時に、セッション情報に基づいてモデルを更新できます。
セッションがクローズします。
アクティブなOracle RTDセッションがクローズし、終了時のロジックが実行されます。これには、セッションのクローズ時に学習するように定義されているモデルの学習などが含まれます。
要素を作成する際、その要素の表示ラベルを入力します。表示ラベルを入力すると、オブジェクトIDが自動的に生成されます。
オブジェクトIDはJava命名規約に準拠するように自動的に作成されます。変数名は大文字と小文字が混在し、最初の1文字は小文字になります。クラス名は大文字と小文字が混在し、最初の1文字は大文字になります。ラベル名に空白が含まれている場合、オブジェクトIDの作成時に空白は削除されます。オブジェクトIDを手動で入力すると、自動的に作成されたオブジェクトIDを上書きできます。
「インライン・サービス・エクスプローラ」のタスク・バーにある「トグル」アイコンを使用すると、オブジェクトの表示ラベルとそのオブジェクトIDとの間で表示の切替えができます。
|
注意: 新しいオブジェクトを作成する際、オブジェクト名が既存のオブジェクトで使用されていると、競合を防止するためにデシジョン・スタジオによって自動的にオブジェクトIDに番号が割り当てられます(1、2など)。 |
デシジョン・スタジオで新しいプロジェクトを開始すると、「サーバー・メタデータ」フォルダにアプリケーション・オブジェクトが作成されます。アプリケーション・オブジェクトのプロパティでは、次の特性が定義されます。
アプリケーション・パラメータ
制御グループ
モデルのデフォルト値
ロジック
これらすべての値は、デシジョン・スタジオ・インタフェースを使用して定義されます。
この項には次のトピックが含まれます:
この項では、アプリケーション・パラメータについて説明します。この項には次のトピックが含まれます:
本番データベースに対してデプロイされているインライン・サービスをテストする場合、モデル・データを混在させないようにするには、デバッグ・オプションを使用してデータが書き込まれないようにします。デバッグ・オプションは次のとおりです。
学習の無効化: モデルの現在の状態を維持して、テストにより追加的な学習が導入されないようにします。
データベース書込みの無効化: データがデータベースに書き込まれないようにします。
親が最初のクラスロード: Javaクラスのロードを制御します。
デフォルトでは、このオプションが選択されており、親(RTDサーバー)レベルですでに定義されているクラスが先にロードされます。
このオプションの選択を解除すると、インライン・サービス・レベルで定義されているJavaクラスが先にロードされます。これは、既存の機能をオーバーライドするときに便利です。
|
注意: WebSphere上でOracle RTDシステムを実行している場合は、このオプション(「親が最初のクラスロード」)の選択を必ず解除してください。 また、WebSphereシステム構成の一環として、これに対応するクラス・ローディングのオプションをWebSphereの管理コンソールで設定する必要があります。詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドの親クラスのロードの無効化に関する項を参照してください。 |
アプリケーション・パラメータは、すべてのセッションについて定義および保存できるグローバルレベルのパラメータです。
「アプリケーション・パラメータ」タブで「追加」をクリックしてパラメータを追加します。パラメータを追加する際、「名前」、「タイプ」、「配列」および「デフォルト値」を入力します。
オプションとして、パラメータに型制約を追加できます。これは、ルールでパラメータを使用する際のパラメータ値の設定に役立ちます。型制約の作成と使用の詳細は、第13.19項「型制約について」を参照してください。
「削除」をクリックすると、パラメータは削除されます。
次のコードはそれぞれ、オブジェクトのラベルとIDを返します。
public String getSDOLabel(); public String getSDOId();
グローバル・パラメータが設定されると、コード内にゲッターとセッターが生成されます。アプリケーション・パラメータ(たとえば、string型のmyApplicationParameter)にアクセスするには、次を使用します。
String param = Application.getApp().getMyApplicationParameter();
逆に、アプリケーション・パラメータを設定するには、次のように指定します。
Application.getApp().setMyApplicationParameter("my parameter");
制御グループは、ビジネス・ユーザーがOracle RTDの意思決定プロセスと既存のランキング・プロセスまたはランダムな選択とを比較できるようにするベースラインとして機能します。制御グループのデシジョンは、Oracle RTDがインストールされていないときのデシジョンを正しく反映するように、正確に定義することが重要です。
たとえば、コール・センター用の抱合せ販売インライン・サービスでは、Oracle RTDの導入前に抱合せ販売がランダムに行われていた場合、制御グループのデシジョンではランダムなデシジョンが反映されるようにする必要もあります。
表13-3 制御グループのオプション
| オプション名 | 説明 |
|---|---|
|
制御グループなし |
これを選択すると、制御グループは使用されず、「選択値」が0に設定され、「値の逐語的使用」が選択されて無効になります。制御グループを有効にして設定を変更するには、「制御グループなし」を選択解除します。 |
|
選択値 |
属性値への参照。この値を使用して、リクエストのランダムな選択を制御グループに生成します。 |
|
値の逐語的使用 |
「値の逐語的使用」を選択解除する場合、制御グループの選択値は、セッション・キーまたは顧客を一意に識別する属性を参照する必要があります。制御グループの参加は、選択値の疑似乱数ハッシュを使用して決定されます。計算の結果は決定論的であり、制御グループの選択値と指定されたサイズにのみ依存します。制御グループの実際のサイズは、指定されたサイズと微妙に異なります。 「値の逐語的使用」を選択すると、選択値により制御グループの参加が直接決定されます。この場合の選択値には、ブール(制御グループの参加をtrue値で示す)または整数(制御グループの参加を0以外の値で示す)を指定できます。 たとえば、顧客の制御グループへの割当てをOracle RTD以外で行う場合に「値の逐語的使用」を選択します。制御グループの選択値として使用する属性は、この割当てを示す必要があります。 |
|
母集団のパーセント |
「値の逐語的使用」がFalseに設定されている場合にのみ、このオプションはアクティブになります。その場合、制御グループに割り当てる必要があるセッションの総数に対するパーセンテージをユーザーは決定します。 |
|
分析に使用 |
制御グループの参加を解析モデルにより追跡するかどうかを制御します。 |
|
分析の名前 |
解析モデルが制御グループの参加の追跡に使用する名前。 |
モデルのデフォルト値は、使用するモデルおよびモデルの設定方法を制御します。ほとんどのモデルのデフォルト値は、Oracleサポート・サービスによる指示のないかぎり変更しないでください。
表13-4 モデルのデフォルト値
| オプション名 | 説明 |
|---|---|
|
スタディ名 |
インライン・サービスで使用するスタディの名前。通常は、インライン・サービスごとに個別のスタディを持ちます。これは、スタディ名をインライン・サービス名と同じにすると実現できます。ただし、既存のスタディはインライン・サービスのテスト時に使用されることがあります。そのような場合は、学習を無効にして本番データが失われないようにする必要があります。 |
|
連続性間隔 |
モデル・データをデータベースに保存する時間間隔。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。 |
|
時間ウィンドウ期間 |
デフォルト値は「四半期」です。この値はモデルごとにオーバーライドできます。 |
|
週の最初の曜日 |
デフォルト値はロケールにより異なります。米国では、デフォルト値は「日曜日」です。 |
|
年の最初の月 |
デフォルト値は「1月」です。 |
|
データの変更時にビルド |
新しい予測モデルを構築する新規レコードのパーセンテージ。デフォルト値は「20%」です。 たとえば10%に設定した場合、前回予測モデルが構築されたのが13400レコードに達した時点であったと仮定すると、次回予測モデルが構築されるのは1340レコードに達した時点になります。 |
|
重要度しきい値 |
デフォルト値は「25」です。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。 |
|
相関しきい値 |
デフォルト値は「0」です。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。 |
|
最大入力カーディナリティ |
個々の属性で追跡される値の最大数。デフォルト値は「500」です。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。 |
|
最大入力バケット |
数値属性の入力バケットの最大数。デフォルト値は「200」です。値が「100」でも十分有効な場合があります。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。 |
アプリケーション要素の「ロジック」タブにある「初期化ロジック」および「クリーンアップ・ロジック」パネルを使用して、インライン・サービスを初期化およびクリーンアップするスクリプトレットがデシジョン・スタジオを介して追加されます。
これらのスクリプトレットは、ApplicationクラスのinitおよびcleanUpメソッドに挿入されます。initメソッドは、インライン・サービスがロードされるときにコールされます。cleanUpメソッドは、インライン・サービスがアンロードされるときにコールされます。アプリケーションが再デプロイされると、initが再度コールされます。
ユーザーの設定したJavaクラスをinitまたはcleanUpメソッドで参照する場合、それらのクラスがインポートされている必要がある可能性があります。import文を追加するには、説明の横にある「詳細」をクリックします。詳細は、表12-1のフォルダ名libの説明を参照してください。
インライン・サービス内のデータにアクセスするには、エンティティ、データ・ソースおよびセッションの各要素を使用します。
エンティティは、複数のソースからのデータをまとめて、インライン・サービス全体で使用されるオブジェクトを形成する論理的な方法を提供します。エンティティは、その内容を記述するいくつかの属性で構成されます。また、エンティティは属性にアクセスするメソッドも備えています。
Customerなどのエンティティは、様々なソースから着信するデータを組み合せます(IVRを介して入力されたアカウント番号や企業データベースから取得した顧客履歴など)。エンティティの属性の1つがキー(一意の識別子)の場合もあります。着信したデータは、エンティティの適切な属性にマップされます。セッションの存続期間中に、インライン・サービスにコーディングされている追加ロジックによってエンティティ属性を移入できます。
データ・ソースは、データのサプライヤとして機能します。これは、リレーショナル・データベース表およびストアド・プロシージャへの接続を管理する方法を提供します。データ・ソースは、データベース表の列、またはストアド・プロシージャからの結果セットを属性として識別します。これらの属性は、エンティティ属性にマップされます。
セッション・オブジェクトは、インライン・サービスに対してメモリー内の使用可能な属性を識別する特別なエンティティです。これらの属性は、前述のCustomerなどのエンティティと、計算などの他のソースで設定された属性で構成できます。セッション・オブジェクトを使用して、ユーザー・セッションの情報を保存します。セッションに保存された属性はインライン・サービス全体で使用でき、セッションを閉じたときに破棄されます。セッションに関連付けられている属性は、特定のモデルで明示的に除外されている場合や、解析対象から完全に除外されている場合を除いて、デフォルトでOracle RTD学習モデルの入力として使用されます。
データにアクセスするには、通常、次の手順を実行します。
SQL表またはストアド・プロシージャに基づいてデータ・ソースを作成します。
ゼロ以上のデータ・ソースにマッピングされた属性を持つエンティティを作成します。
キー値をエンティティに追加します。
エンティティを属性としてセッションに追加し、セッション・キーを割り当てます。
エンティティ属性をデータ・ソース列または出力値にマップします。
エンティティ・キーをセッション・キーまたは関数にマップします。
この項には次のトピックが含まれます:
データはインライン・サービス内でデータ・ソース要素およびエンティティ要素を使用してアクセスします。データ・ソースはデータの抽象プロバイダです。データ・ソースは、インライン・サービスに対するデータのサプライヤとして機能します。
データ・ソースには、SQLデータ・ソースとストアド・プロシージャ・データ・ソースの2種類があります。
この項では、SQLデータ・ソースを作成する方法について説明します。この項には次のトピックが含まれます:
表13-5はSQLデータ・ソースのプロパティを示します。
表13-5 SQLデータ・ソースのプロパティ
| データ・ソースのプロパティ名 | 説明 |
|---|---|
|
説明 |
データ・ソースの説明。 |
|
JDBCデータ・ソース |
JDBCデータ・ソースのJNDI名。新しいデータ・ソースの作成方法は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsのデータ・アクセスの構成に関する項を参照してください。 |
|
表名 |
表の名前。大文字と小文字が区別されるデータベースを使用している場合は、この名前の大文字と小文字が区別されます。 |
|
出力列名 |
データ・ソースから選択する列。 |
|
出力タイプ |
出力列のデータ型。 |
|
入力列名 |
データ・ソースに対する問合せのWHERE句に使用する列。これは、データ・ソースからデータを選択する際に一致させる列です。 |
|
入力タイプ |
入力列のデータ型。 |
|
複数の行を許可 |
複数行が返されることを許可します。このオプションを選択しない場合に複数行が返されると、最初の1行のみが使用されます。 |
|
詳細 |
「詳細」ボタンを使用すると、デシジョン・センターに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。 |
「追加」または「削除」をクリックすると、データ・ソースに列を追加または削除できます。複数の行が想定される場合、「複数の行を許可」を選択します。このオプションを選択しない場合に複数行が返されると、最初の1行のみが使用されます。
「インポート」をクリックすると、JDBCデータ・ソースに接続して、使用可能な表が表示されます。追加のJDBCデータ・ソース(『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsのデータ・アクセスの構成に関する項を参照)をまだ作成してない場合は、SDDS JDBCデータ・ソースのみが選択可能になります。
構成ウィザードを使用して、Oracle RTDを構成し、ドメインを作成します。『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsのデータ・アクセスの構成に関する項を参照してください。この構成を行うには、ソフトウェアのみのインストール後にOracle RTDを構成するための手順に従います。
「すべてのスキーマのオブジェクトを含む」を選択すると、JDBC接続で指定したデータベース・ユーザーがアクセスできる表がすべて表示されます。アクセス可能なスキーマが別の列に表示されます。
インポートする表を選択すると、それらの列の列名とデータ型がインポートされます。不要な列がある場合、「削除」をクリックしてそれらを削除します。
「入力列」は、セッションに必要な行を取得するために、データベース表に対して一致させる列です。ほとんどの場合、これは単一レコードを返すための主キーまたは一意の索引列の値になります。大きな結果セットが必要な場合は、一意でない索引列にすることもできます。「追加」をクリックして、一致させる属性を選択します。
この項では、ストアド・プロシージャ・データ・ソースを作成する方法について説明します。この項には次のトピックが含まれます:
表13-6はストアド・プロシージャ・データ・ソースのプロパティを示します。
表13-6 ストアド・プロシージャ・データ・ソースのプロパティ
| データ・ソースのプロパティ名 | 説明 |
|---|---|
|
説明 |
データ・ソースの説明。 |
|
JDBCデータ・ソース |
JDBCデータ・ソースのJNDI名。 |
|
プロシージャ名 |
ストアド・プロシージャの名前。データベースで大文字と小文字が区別される場合であっても、この名前の大文字と小文字は常に区別されません。 |
|
入力と出力 |
ストアド・プロシージャの入出力パラメータ。各入出力パラメータには、Name、Type、およびDirectionがあります。 |
|
結果セット |
ストアド・プロシージャからの結果セット。 |
|
複数の行を許可 |
複数行が返されることを許可します。このオプションを選択しない場合に複数行が返されると、最初の1行のみが使用されます。 |
|
結果セットの詳細 |
列名と予想される結果の型。 |
|
詳細 |
「詳細」ボタンを使用すると、デシジョン・センターに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。 |
「インポート」をクリックして、データ・ソースに直接接続します。指定されたデータ・ソースのすべてのストアド・プロシージャが表示されます。データ・ソースが指定されない場合は、デフォルトのデータ・ソースSDDSが使用されます。
「すべてのスキーマのオブジェクトを含む」を選択すると、すべてのデータ・ソース・スキーマのストアド・プロシージャが表示されます。
インポートするストアド・プロシージャを選択すると、そのパラメータの名前とデータ型がインポートされ、データ・ソースの属性になります。その後、「終了」をクリックします。不要なパラメータがある場合は、「削除」をクリックすると削除できます。
「追加」または「削除」をクリックすると、データ・ソースに属性を追加または削除できます。属性が「入力」、「出力」、または「入力/出力」かを選択します。
属性は順に並べる必要があります。「上へ」または「下へ」を使用して属性の順番を変更します。
ストアド・プロシージャに1つ以上の結果セットがある場合、各結果セットに対して次の手順を実行します:
「結果セット」の「追加」ボタンをクリックして、結果セットをデータ・ソースに追加します。
「結果セットの詳細」の「追加」ボタンを使用すると、結果セットの列名および型を追加できます。
列名とデータ型を手動で入力して、次に示すようにストアド・プロシージャの結果セットの列に一致させる必要があります。
データ・ソースの列名は、結果セットの列名と正確に一致している必要があります。
データ・ソースのデータ型は、結果セットの対応データ型で有効である必要があります。
たとえば、結果セットの列がVARCHARまたはVARCHAR2の場合、データ・ソースの対応する列のデータ型としてStringを入力します。SQL ServerまたはOracleのストアド・プロシージャの列がFLOATの場合や、DB2のストアド・プロシージャの列がREALの場合、データ・ソースの対応する列のデータ型としてDoubleを入力します。
付録C「ストアド・プロシージャからのデータ・ソースの例」では、Oracle、SQL ServerおよびDB2の各データベースからデータ・ソースを設定し、データ・ソースから属性を導出するエンティティを作成する例について説明しています。
Oracle Business Intelligence Enterprise Editionでは、OLTPデータベースおよびOLAPデータベースに格納されているデータにアクセスするためのODBCクライアント・インタフェースを公開しています。RTDデシジョン・サービスは、Java Runtime Environment (JRE)に含まれているJDBC-ODBCブリッジを使用して、Oracle Business Intelligence Enterprise Editionに付属のODBCドライバに接続します。
RTDデシジョン・サービスから見れば、Oracle Business Intelligence Enterprise Editionは通常のデータベースと同様のSQLデータ・ソースです。Oracle Business Intelligence Enterprise Editionのサブジェクト領域は、インライン・サービスではデータベース表として扱われます。列名は、プレゼンテーション・オブジェクト階層の2つのレベルを組み合せたものです。
デシジョン・スタジオ・データ・ソースによってアクセスできるJDBCデータ・ソースを追加する方法は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsのデータ・アクセスの構成に関する項を参照してください。
エンティティは、名前付き属性とその属性にアクセスするためのメソッドのセットです。通常、1つの属性がエンティティのキーとして指定されます。たとえば、単純な顧客エンティティは次のようになります。
Customer customerId: string, key name: string age: integer accounts: collection of Account entities
このエンティティでは、customerIdがエンティティのキーで、nameとageは単純な属性です。accountsは、Customerヘッダーに関連付けられているAccountエンティティのコレクションです。
この項には次のトピックが含まれます:
Sessionエンティティは、インライン・サービスごとに自動的に作成される特別なエンティティです。
特定のフロント・エンド・セッションの存続期間中、Sessionエンティティによって、インライン・サービスで使用可能なメモリー内の属性が識別されます。これらの属性は、Customerなどのエンティティと、計算などの他のソースで設定された属性で構成できます。Sessionオブジェクトを使用して、ユーザー・セッションの情報を保存します。セッションに保存された属性はインライン・サービス全体で使用でき、セッションを閉じたときに破棄されます。
セッションは統合点によって明示的にクローズされるか、またはタイムアウトによってクローズされます。
セッション・キーはリクエストに渡すフィールドの1つで、統合点で使用可能な、Real-Time Decision Serverサーバーに存在するSessionオブジェクトのインスタンスを識別します。
セッションの使用例として、クライアントWebアプリケーションについて考えます。ここでは、各リクエストがセッション・キーとしてWebアプリケーションのCustomerIdを渡します。新しいCustomerIdを持つ最初のリクエストが到着すると、Real-Time Decision Serverではそのセッション・キーが新しいことを認識し、新しいSessionオブジェクトを作成して、リクエストの実行時に統合点で使用できるようにします。これと同じCustomerIdを使用する後続のリクエストは、同じSessionオブジェクトにアクセスします。
統合点の処理により、後で呼び出される統合点で使用できるように、セッションの情報が明示的または暗示的に保存されます。
エンティティは、デシジョン・スタジオを使用して定義します。エンティティ名は、大文字で開始する必要があります。エンティティでは、次の特性が定義されます。
説明:デシジョン・スタジオに入力されたエンティティの説明。
キー: エンティティの一意のID。「キーの追加」をクリックすると、キーがエンティティに追加されます。
エンティティ属性にはプロパティもあります。属性のプロパティを表13-7に示します。
表13-7 エンティティ属性のプロパティ
| エンティティ属性のプロパティ名 | 説明 |
|---|---|
|
説明 |
デシジョン・スタジオに入力された属性の説明。 |
|
タイプ |
属性タイプは、基本型、Javaクラス、エンティティ・タイプ、選択肢または選択肢グループのいずれかです。 |
|
配列 |
単一値かコレクションかどうか。 |
|
タイプ制約 |
ルールでエンティティ属性を使用する場合、属性の型制約を選択できます。これは必須要件ではありませんが、ルールの定式化に役立ちます。型制約の作成と使用の詳細は、第13.19項「型制約について」を参照してください。 |
|
デフォルト値 |
デフォルト値。定数、関数、または属性への参照を指定できます。 |
|
分析に使用 |
このオプションを選択して、予測モデル内の解析にこの属性を使用します。デフォルトでは、これはtrueに設定されています。 |
|
カテゴリ |
属性のカテゴリ。カテゴリは、デシジョン・センターでの属性の表示の編成に役立ちます。 |
|
分析オプション |
Date属性の追加の解析オプションが使用できます。解析にDateを使用するには、解析に使用するパターンを指定します。月、日、曜日、時刻の影響を個別に、または任意の組合せで解析できます。 |
「属性の追加」または「キーの追加」をクリックして、属性をエンティティに追加します。属性がコレクションの場合は、「配列」列を選択します。
|
警告: Key属性を追加する場合、データ型は自動的にStringになります。データ・ソース列または出力パラメータのデータ型がString以外の場合は、データ・ソースの入力の設定時に変換関数を使用します。 |
データ・ソースのすべての出力列を自動的にエンティティ属性として追加するには、「インポート」をクリックしてインポート元のデータ・ソースを選択します。複数のデータ・ソースからインポートする場合は、この手順を繰り返します。「削除」をクリックすると、不要な属性を削除できます。
「インポート」を使用する際、「選択したデータ・ソースのデータ・マッピングのビルド」を選択すると、属性がデータ・ソースに自動的にマップされます。エンティティがネストされ(たとえば、1対多関係)、属性が間接的にマップされる場合は、このオプションを選択しません。
「分析に使用」を選択して、解析モデルに属性を追加します。
各エンティティ属性の「分析に使用」オプションはデフォルトでtrueに設定されており、Oracle RTDのモデルの入力として使用されます。その必要がない場合は、ユーザーがこのオプションの選択を明示的に解除できます。適切な属性を右クリックして「プロパティ」を選択することで、この設定にアクセスします。
このオプションの選択を解除する場合の一般的な例として、属性自体はモデリングに有効でないが、別の属性の値を計算する関数で使用されている場合があげられます。
|
注意: 値がNULLや空文字列になる可能性がある属性には注意してください。 NULLは学習モデルに渡されず、予測の計算にも使用されません。また、標準のパーティション化されていない属性の場合、デシジョン・センター・レポートに表示されません。 NULLは、データ値が不明な場合にのみ使用してください。特殊なケースの疑似値としては使用しません。たとえば、Number_of_children属性の値がNULLの場合は子供の数が不明であることを示し、値が0の場合は子供の数が0人であることを示します。 空文字列は学習モデルに渡されますが、意味のある予測を生成しません。デシジョン・センター・レポートには「NOT KNOWN」と表示されます。 Oracle RTDモデルでは空文字列を使用しないことをお薦めします。 |
「デシジョン・センターで表示」オプションは、デフォルトで選択されます。デシジョン・センター・ユーザーに対して属性を表示しないようにする場合は、このオプションを選択解除します。必要に応じて、「カテゴリ」を選択すると、デシジョン・センターの属性の表示を制御できます。適切な属性を右クリックして「プロパティ」を選択することで、この設定にアクセスします。
第13.6.5項「解析の属性の使用」のNULLと空文字列に関する注意も参照してください。
使用するセッション・キー値がエンティティの属性である場合、最初にエンティティをセッションに追加します。そのためには、セッション・エンティティで「属性の追加」をクリックして、このエンティティをそのエンティティ・タイプの新しい属性としてそのセッションに追加します。
たとえば、セッション・キーをCustomerエンティティのcustomerId属性にするとします。「属性の追加」をクリックして、属性をcustomerというセッションに追加します。この属性の型は、エンティティ・タイプ(つまり、Customer)です。
エンティティ・タイプにアクセスするには、「タイプ」列のドロップダウン・リストを使用して「その他」を選択します。「タイプ」ウィンドウが表示されます。この属性の「エンティティ・タイプ」を選択します。
セッション・キーを追加するには、「依存エンティティのセッション・キー」から「選択」をクリックします。セッションの属性であるエンティティからのキー値はすべて、セッションのキー値として選択できます。そのセッションのベースにするキーを選択します。この例では、customerIdです。
「属性の追加」をクリックして、セッション全体で使用可能にする属性を追加します。セッション属性も他のエンティティ属性もゲッターおよびセッターが生成されます。これにより、作成するカスタム・ロジックでこれらの属性を使用できるようになります。
デシジョン・スタジオを使用してエンティティを作成したら、エンティティの属性を定数、計算済、データ・ソースの属性への参照、またはセッション・キーのいずれかの値にマップします。
構成されているデータ・ソースへのマッピングは、エンティティ・オブジェクトの「マッピング」タブで実行します。エンティティの属性をデータ・ソースにマップするには、「ソース」列を使用して、データ・ソース列のパスまたはデータの属性を提供する出力パラメータを選択します。
キー値をマップするには、「データ・ソース入力値」から「入力値」をクリックします。ここで、属性をデータ・ソース値にマップすると、キー値が表示されます。キーは、セッション・キー属性、別のエンティティ・キー値、または関数にマップできます。入力タイプは、String型にする必要があります。String型でない場合は、非文字列値を変換する関数を使用します。
1対多の外部キー関係のエンティティのデータにアクセスするには、関係するエンティティを最初のエンティティの属性にします。たとえば、Customers表にキーCustomerIDがあると仮定します。Customersには多数のOrdersがあり、OrderIDと外部キーCustomerIDで識別されます。
1対多の外部キー関係のエンティティのデータにアクセスする手順を、CustomersとOrdersを例に使用して、次に示します:
|
注意: この例は、Orders表にCustomerIDが外部キーとして存在していることを前提としています。このCustomerIDはOrdersデータ・ソースの入力列として使用されます。また、Ordersデータ・ソースの「複数の行を許可」設定がtrueに設定されています。 |
デシジョン・スタジオで、各表のデータ・ソースを定義します。
CustomersおよびOrdersのエンティティを作成します。
Customerをセッションに追加します。これは、次のデータ・レベルを取得する際のキーとなります。
セッション・キーとしてCustomerIDを選択します。
OrdersとCustomersの間の1対多関係を関連付けるには、Ordersエンティティ・タイプのOrdersという属性をCustomerに追加します。1つのCustomerに対して多数のOrdersがあるので、これを配列にします。
Customerエンティティのマッピング・タブを使用して、CustomerエンティティとOrdersエンティティ両方のすべての属性値をマップできます。
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。
セッション要素は、セッションの初期化および終了で実行されるスクリプトレットを受け入れます。cleanUpスクリプトレットは、セッションがクローズされるときにコールされます。
次のコードはそれぞれ、オブジェクトのラベルとIDを返します。
public String getSDOLabel(); public String getSDOId();
session()を使用して、インライン・サービスの別のエンティティにアクセスできます。例:
session().getCustomer().getCustomerId();
ここで、Customerはエンティティ、customerIdはそのエンティティの属性です。
session()を使用して、アプリケーション・セッションのインスタンスにアクセスします。セッションでは、次のAPIが使用できます。
public boolean isTemporary();
セッション・キーが渡されなかった場合、セッションは一時的であるとみなされます。
次のコードは、統合点の外側の統合点リクエストへのアクセスに使用され、現在のリクエストを返します。
public IntegrationPointRequestInterface getRequest();
次のコードは、現在のセッション・インスタンスが閉じているかどうかを返します。
boolean isClosed();
次のコードは、既知のセッション・キーを返します。これは、コールされた場所により、完全なセットである場合もそうでない場合もあります。
Set getKeys();
次のコードは、現在のセッション・インスタンスを閉じます。
public void close();
次のコードは、現在のセッションのアプリケーション・オブジェクトを取得します。
public ApplicationInterface getApp();
次のコードはそれぞれ、オブジェクトのラベルとIDを返します。
public String getSDOLabel(); public String getSDOId();
生成される通常のクラスに加え、各エンティティには配列クラスも生成されます。生成されるクラスには、各属性のプロパティ、ゲッターおよびセッターがあります。したがって、Customer、Account、Callなどのエンティティを定義すると、これらの名前を持つクラスとそのクラスのコレクションを示すもう1つのクラスが生成されます。
たとえば、Accountエンティティの場合、次の2つのクラスが生成されます。
Account SDAccountArray
2番目のクラスは、Accountのコレクションを表します。そのため、Customerエンティティに、名前がaccountsでタイプがAccountの属性がある場合(多重性に1超の値が設定されている場合)、Customerに次のゲッターが生成されます。
Customer {
SDAccountArray getAccounts() {
}
void setAccounts(SDAccountArray accounts) {
}
void addToAccounts(Account account) {
}
}
クラスはエンティティ・タイプごとに生成されるため、他のJavaオブジェクトと同様に、new演算子でエンティティを作成します。例:
Customer cust = new Customer();
エンティティが別のエンティティの子である場合は、オプションで親エンティティの名前を渡します。セッションは、別のエンティティの親エンティティになることもあります。
Customer cust = new Customer(entityParent);
ほとんどのエンティティは、キー属性の値がなければ有用ではありません。キー属性は、他の属性と同様に、生成されたセッターを使用して設定されます。
Customer cust = new Customer(); String newKey = '12345'; cust.setCustomerId(newKey);
前述のように、ゲッターは属性ごとに生成されます。ゲッターの形式は、属性が1つの値を持つか複数の値を持つかによって異なります。サンプルのCustomerエンティティは次のゲッターを持ちます。
String id = cust.getCustomerId(); String name = cust.getName(); double age = cust.getAge(); Collection accounts = cust.getAccounts();
対応するセッターも生成されます。customerIdのセッターを見てきましたが、ここでは別のCustomerの例を示します。
cust.setName("Fred Johnson");
cust.setAge(42);
cust.setAccounts(newCollection);
また、Accountsは複数の値を持つ属性であるので、コレクションに追加することもできます。
cust.addToAccounts(anotherAccountObject);
配列は、次を使用して追加できます。
cust.addAllAccounts(anotherAccountArray);
エンティティをリセットおよび入力するために、3つの特別なメソッドが用意されています。
cust.reset();
セッション・キー以外のすべてのキーとすべての属性をリセットします。
cust.resetAttributes();
すべての属性をリセットしますが、キーはリセットしません。
cust.fill();
fillにより、エンティティ・マッピングに従って属性の値が再帰的に入力されます。データ・ソース、計算済の値または定数値によってデータが強制的にリフレッシュされます。また、エンティティ・タイプの任意の属性も入力されます。
resetおよびfillは、キャッシュされたエンティティに対してはコールしないでください。
エンティティは、アクセスしやすいようにサーバー上にキャッシュできます。エンティティをキャッシュするには、エンティティの「キャッシュ」タブをクリックします。
エンティティには次のキャッシュ関連オプションを持たせることができます。
このエンティティ・タイプのキャッシングの有効化: このオプションを選択してキャッシュを有効にします。キャッシュされたエンティティはキャッシュされていないエンティティと同様に処理され、同じAPIを持ちますが、キャッシュされたエンティティのキーをセッション・キーとして使用することはできません。
キャッシュする項目の最大数: キャッシュするアイテムの最大数。アイテムは先入れ先出し方式でフラッシュされます。
さらに、エンティティには次の「キャッシング方針」関連オプションを持たせることができます。
固定存続期間の使用: リフレッシュされるまで各オブジェクトをキャッシュに維持する秒数。
固定期間の使用: キャッシュ全体がリフレッシュされるまでの秒数。
キャッシュをリフレッシュしない: キャッシュされたアイテムは、最大数に達するまでキャッシュに維持されます。
エンティティがキャッシュにマークされている場合、次のコードを使用して属性を設定します。エンティティを作成したら、キー値を設定して、キャッシュから属性値を取得します。キャッシュされたエンティティ属性(キー以外)には、セッターがありません。そのため、エンティティはキャッシュされたバージョンと常に同期します。
Customer cust = new Customer(); String newKey = '12345'; cust.setCustomerId(newKey); cust.getCustomerId(); cust.getName(); cust.getAge(); cust.getAccounts();
問題
デバッグやロギングを行うには、設定しているOracle RTDエンティティの現在値を調べるために、logDebugやlogInfoなどのログ記録文を開発者は記述する必要があります。通常は、Oracle RTDログに値を出力する必要がある各エンティティ属性に対して1行以上のコードが必要です。これによって、出力をログに記録することのみを目的とするコードが大量に追加されます。
解決策
Oracle RTDプラットフォームには、すべてのセッション・エンティティ属性の値または指定したエンティティとその属性の値をOracle RTDログに出力できるAPIが用意されています。出力は、情報、デバッグ、エラー、警告およびトレースのすべてのログ・レベルで行われます。
APIの一般形式
|
注意:
|
セッションのすべての属性をログに記録するには、次のように記述します。
logInfo(session());
エンティティのすべての属性をログに記録するには、次のように記述します。この場合、エンティティはセッション属性である必要があります。
logInfo (session().getEntity_id());
APIからエンティティ名、属性名および値が次の形式で出力されます。
Entity > ExternalName: <label> ; InternalName: <id> ; Attribute <n> Name: <attribute_name>; Type: <attribute_type>; Value: <value> or [<list_of_array_values>];
例
インライン・サービスのsessionエンティティには、次の2つの属性があります。
customer(Customer)
customer id(Integer)
customerは、次の3つの属性を持つエンティティです。
assets(String配列)
productId(String配列)
unfilled(String)
次の行があるとします。
logInfo(session());
前述の行から次のような出力がインライン・サービスの「テスト」→「ログ」タブに表示されます。
Entity > ExternalName: ; InternalName: ApplicationSession; Attribute 1> Name: customer; Type: Customer; Value:
Entity > ExternalName: Customer; InternalName: Customer; Attribute 1> Name: assets; Type: SDStringArray; Value: [1, 7, 8, 9, 9, null];
Entity > ExternalName: Customer; InternalName: Customer; Attribute 2> Name: productId; Type: SDStringArray; Value: [1, 7, 8, 9, 1];
Entity > ExternalName: Customer; InternalName: Customer; Attribute 3> Name: unfilled; Type: String; Value: <unfilled>;
Entity > ExternalName: ; InternalName: ApplicationSession; Attribute 2> Name: customerId; Type: int; Value: 2;
組織の意思決定プロセスの設計では、まず、Oracle RTDデシジョンの導入によって改善する必要のある具体的なメトリックを検討します。一般的なパフォーマンス・メトリックとして、次の2つがあります。
Webサイトを訪問した顧客当たりの売上
コンタクト・センターにおける顧客通話当たりの処理コスト
パフォーマンス・メトリックは、最適化の方向(最大化または最小化)と正規化ファクタで構成されます。
パフォーマンス目標の特徴は次のとおりです。
パフォーマンス・メトリック: 組織がデシジョンの成功の度合いを測定するように選択したメトリック。
最適化: パフォーマンス・メトリックを最適化する方向を示す値、「最小化」または「最大化」。
必須:パフォーマンス・メトリックのスコアリングが必要な場合は選択します。メトリックが必須としてマークされていない場合、データ不足によってスコアが使用できないと、Oracle RTDは別のスコアを調べてスコアを提供します。メトリックが必須としてマークされている場合、全体的なスコアは提供されません。そのメトリックは使用不可とマークされ、スコアリング・プロセスから削除されます。
正規化係数: このパフォーマンス・メトリックの組織の相対値。
この項には次のトピックが含まれます:
パフォーマンス目標要素を選択してから、「追加」をクリックしてパフォーマンス・メトリックを追加します。メトリック(例: 収益)、最適化の方向(最大化)、メトリックで意思決定を行うためのスコアを使用可能にする必要があるかどうかを追加します。
メトリックをすべて追加したら、正規化ファクタを決定する必要があります。
インライン・サービス開発者やビジネス・ユーザーが本来の測定スケールが異なるパフォーマンス目標に対するスコアリング関数を表現するには、Oracle RTDではインライン・サービス開発者が正規化ファクタによりパフォーマンス目標を正規化する必要があります。
パフォーマンス目標を定義する場合、各パフォーマンス目標に対して正規化ファクタが1つ適用されます。それ以降、1つ以上のデシジョンで使用されるようにパフォーマンス目標が選択されます。スコアで正規化された結果、ビジネス・ユーザーはデシジョンのためのパフォーマンス目標に適用する相対的な重み付けを変更できます。重み付け自体は0から100の範囲のパーセント値で表現されます。
一般的に数値が大きいほど良好なので、目標ごとにスコアを最大化することを選択します。リスクや経費のように数値が小さいほど良好な目標については、最小化することを選択します。
正規化に関する考慮事項
ビジネス分野によっては、複数のパフォーマンス目標において共通するメトリックが1つ使用される場合があります。一般的に、異なるパフォーマンス目標は測定単位と重要性が異なるので、複数のパフォーマンス目標において正規化を行わないと、あるパフォーマンス目標がスコアリングの結果とデシジョンの結果に予想外の影響を与える可能性があります。
Oracle RTDでは、ビジネス・ユーザーがパフォーマンス目標ごとに固有のセマンティクスを使用してスコアを表現できます。
正規化の例
次に2つのパフォーマンス目標を使用する例を示し、スコアを正規化することが重要である理由を説明します。前提条件は次のとおりです。
パフォーマンス目標は売上と受入れ確率です。
売上の測定単位は$0から$1000の金額であり、受入れ確率の測定単位は0から100の数値です。
1回のセールス当たりの平均売上は$500です。
売上を生み出すオファーと顧客の受入れ確率の高いオファーとにおいて相対的な重要性のバランスを取ることがビジネスでは必要になります。
たとえば、受入れ確率100%と売上増$500を線形に交換する用意がビジネス・ユーザーにできている場合があります。つまり、売上が$50多いオファーよりも受入れ確率が10%低いオファーを提示することをビジネス・ユーザーが検討することを意味します。
正規化ファクタを使用しないでこのバランスを実現するには、デシジョンの際に次の重み付けを適用する必要があります。
売上の重み付け = 1/500 = 0.002
受入れ確率の重み付け = 1 – (1/500) = 0.998
このような重み付けの適用は、その値を少し大きくするだけでデシジョンの結果が大幅に変わるので、管理するのは非常に困難です。この設計において重要な要因を次に示します。
売上と受入れ確率では本来の測定スケール単位が異なるものが使用されること
ビジネス・ユーザーは、デシジョンの際にこの2つの単位をどのように比較するかを表現する必要があること
したがって、この場合は正規化ファクタを適用する必要があります。
受入れ確率のスコアと売上のスコアの重要性を等しくするには、売上の線形正規化ファクタとして500、受入れ確率の線形正規化ファクタとして1を定義します。デシジョンの際は、売上と受入れ確率の重み付けをどちらも0.5に設定します。
一般の設計要因
インライン・サービス開発者にとって、パフォーマンス目標の正規化を実行する必要があることを理解することは重要です。この正規化は、次の2つの方法で実装できます。
線形正規化は、各パフォーマンス目標の正規化ファクタを設定する際に適用されます。
一部のスコアリング関数では、線形スケール・ファクタのみでは十分ではない場合があります。たとえば、売上が$1500から$1650の範囲のときは、正規化ファクタではなくカスタム・スコアリング関数を定義することが適切である場合があります。
パフォーマンス目標の「必須」フラグは、デシジョンを処理するために実際の値が必要かどうかを示します。
このフラグが「True」に設定されていると、適格な各選択肢でこのパフォーマンス目標のスコアが必要です。
選択肢にそのような値が見つからない場合、すなわちスコアがNaNの場合、ランダム・スコアが生成されます。
このフラグが「False」に設定されていると、適格な各選択肢でこのパフォーマンス目標のスコアは必要ありません。
選択肢スコアにそのような値が見つからない場合、すなわちスコアがNaNの場合、このパフォーマンス目標はその選択肢では無視され、デシジョンで使用される他のパフォーマンス目標の重み付けにおいて、不要とマークされたパフォーマンス目標の重み付けが均等に分配され調整されます。
|
注意: 外部化されたパフォーマンス目標とその重み付けのコンテキストでは、インライン・サービス開発者が重み付けを正規化する必要があります。 |
選択肢は、意思決定プロセスで評価されるオブジェクトです。また、ビジネス・プロセスをモデル化するためのスタディ対象になる場合もあります。意思決定プロセスで使用された場合、候補となる選択肢のリストから最適な選択肢がアドバイザ・コールを介して返されます。意思決定プロセスにおける選択肢の例を次に示します。
マーケティング・オファーの選択元リスト
推奨製品リスト
タスクのリソース・リスト
選択肢は、選択肢グループにまとめることができます。選択肢グループと選択肢は階層ツリーに似た構造として編成され、1つの親選択肢グループの下に複数の子選択肢グループが存在できます。候補となる選択肢のリストから選択肢を選択すること、すなわちデシジョン・プロセスは、次のロジックに従って段階的に行う操作です。
適格性: デシジョンに対して選択肢を検討する必要があるかどうかを決定するルールのセットです。適格性ルールは、選択肢グループと選択肢の階層の各レベルで定義できます。
スコアリング: デシジョンに対して定義されている各パフォーマンス目標に沿ったスコアの計算です。
正規化: 様々なパフォーマンス・メトリックに沿ってスコアを一般のスケールに移行して、スコアを比較できるようにします。
総計化: 選択肢ごとに1つの数値を生成します。この数値は、デシジョンの適用先セグメントの各パフォーマンス目標の正規化済スコアを重み付けして合計した値です。
選択: 選択肢の合計スコアに基づいて最適な選択肢の設定数を選択します。
選択肢には、静的選択肢と動的選択肢があります。
静的選択肢の場合、リクエスト元アプリケーションまたは自己学習モデルに提示される選択肢は、Oracle RTD内で完全に定義されます。静的選択肢は、選択肢が既知の場合と、一定期間にわたって一定の場合に役に立ちます。
動的選択肢は、実行時に動的に構築される選択肢です。この選択肢は通常、外部データ・ソースに保持されます。これにより、オファー管理システムで定義したオファーに基づく選択肢など、ソース・システムで選択肢を管理できます。
|
注意: 選択肢グループは常に静的であり、Oracle RTDインライン・サービスで定義されます。 |
この項では、選択肢グループおよび静的選択肢と動的選択肢の両方に該当する一般的な特徴とプロセスについて説明します。動的選択肢の詳細は、第17章「外部化されたオブジェクト管理」を参照してください。
この項には次のトピックが含まれます:
選択肢グループと選択肢には次の特徴があります。
属性: 選択肢を構成する属性。これらは、親の選択肢グループから継承されるか、選択肢レベルで割り当てられます。
スコア: 各選択肢は、「スコア」タブの定義に従ってスコアリングされます。選択肢は、デシジョンで定義されているすべてのパフォーマンス・メトリックに対してスコアリングされます。
選択肢イベント: 選択肢イベントは、グループ・レベルでのみ記述されます。これらのイベントによって、選択肢のライフサイクルで重要なイベントが識別されます。たとえば、実行されるCross Selling Offerには、Offered、Accepted、Product First Usedなどのイベントがあります。
ルール: 選択肢に適用可能なルールには2つのタイプがあり、デシジョン・センター・ユーザーはどちらのルールも作成や変更ができます。
適格性ルールにより、デシジョンで選択肢を検討する条件を制御します。適格性ルールは、選択肢グループ階層のどのレベルでも定義できます。選択肢は、その上位階層で定義されている適格性条件を継承します。
スコアリング・ルールを使用して、選択肢に数値スコアを関連付けることができます。これらのスコアは、パフォーマンス目標スコアリング・ロジックの一部として使用したり、選択肢の属性として使用できます。
スコアリング・ルールは別個の要素として定義され、該当する選択肢に適用されるのに対し、適格性ルールは選択肢グループ・レベルまたは選択肢レベルで直接定義されます。
詳細: 「詳細」ボタンを使用すると、デシジョン・センターに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。
選択肢グループ属性を使用して、グループ・レベルで属性を定義します。グループ属性は選択肢グループ・レベルにのみ適用され、個々の選択肢には割り当てられません。
選択肢属性は、グループ内の各選択肢が同じ属性のセットを持つように選択肢グループ・レベルで定義されます。選択肢属性の値は、選択肢レベルで個別に定義します。選択肢属性にはデフォルト値を設定できます。これは、低位レベルでオーバーライドできます。
選択肢グループおよび選択肢は階層的に定義されます。階層は、選択肢の論理分類に準拠します。最上位レベルでは、サブツリー全体で一貫性のある選択肢属性の定義を考慮する必要があります。低位レベルでは、階層の形は通常、組織の事情を考慮して決定されます。
選択肢属性は、通常、階層の高位レベルで定義します。属性の中にはオーバーライド不可とマークされているデフォルト値を持つものもあります。これは、デフォルトで設定された値が使用される値になることを示します。これは一般に計算が含まれる場合に設定されます。これはデプロイ後、ビジネス・ユーザーに属性を更新させないようにする場合に有用です。
選択肢属性の値は次のいずれかにできます。
定数
属性または変数
関数またはルール・コール
モデル予測
図13-3に、CrossSellインライン・サービスで構成されている選択肢グループの例を示します。
この例のOffersレベルで設定されている選択肢属性を表13-8に示します。
表13-8 Offers選択肢グループの例のOffersレベルで設定されている選択肢属性
| 属性 | 型 | 値 |
|---|---|---|
|
Message |
String |
デフォルト値なし。各選択肢の値は選択肢レベルで割り当てられます。 |
|
shouldRespondPositively |
Boolean |
特定の選択肢に対して顧客が肯定的に反応するかどうかを示すブール値を返す |
|
Likelihood of Purchase |
Double |
この選択肢グループが登録されている選択肢モデルまたは選択肢イベント・モデルによって割り当てられるプレースホルダ属性。選択肢が購入される確率に使用します。実行時に計算されるため、デフォルト値はありません。 |
|
Profit Margin |
Double |
提示するオファーの収益性の指標(%)。デフォルト値は0.5です。各選択肢の値は選択肢レベルで割り当てられます。 |
各選択肢は、Profit MarginおよびMessageの値を、その選択肢を示す値で上書きします。ただし、有効な期間にサーバーが応答できない場合は、実行時にデフォルト値が使用されます。
どの選択肢もshouldRespondPositively属性をオーバーライドしません。これは、すべての選択肢が同じ関数を使用してその値を決定するためです。Likelihood of Purchaseは、実行時に選択肢ごとにモデルで計算されます。
選択肢属性の特徴は次のとおりです。
名前: 属性の名前。
カテゴリ: 属性が属するカテゴリ。カテゴリは、Category要素で定義されます。
タイプ: 属性のデータ型。
配列: 属性がコレクションであるかどうか。
タイプ制約: ルールで選択肢属性または選択肢グループ属性を使用する場合、属性の型制約を選択できます。これは必須要件ではありませんが、ルールの定式化に役立ちます。型制約の作成と使用の詳細は、第13.19項「型制約について」を参照してください。
継承した値: 存在する場合は、選択肢グループまたは選択肢の属性が親から継承した値。
値: 属性の値。この値は、常に継承した値を上書きします。
デシジョン・センターで表示: このオプションを選択すると、ビジネス・ユーザーに対して属性がデシジョン・センターで表示されるようになります。属性を内部的に使用する場合は、選択解除します。
第13.6.5項「解析の属性の使用」のNULLと空文字列に関する注意も参照してください。
索引付けに使用: 指定した属性で選択肢を検索できるようにする場合、このオプションを選択します。たとえば、nameという選択肢属性があるとします。選択肢グループに、getChoiceWithName(String name)という名前の静的メソッドが生成されます。このメソッドは選択肢を1つ返します。
このオプションを選択する場合、この属性の値がすべての選択肢の中で一意であることが必要です。
クライアントへ送信: この選択肢を返すインライン・サービスをコールする外側のクライアントに属性を送信する場合は、このオプションを選択します。
選択肢属性を追加または削除するには、「追加」または「削除」をクリックします。
選択肢属性を編集するには、属性を右クリックして、「プロパティ」を選択します。選択肢属性は、定義されている最上位レベルでのみ編集できます。
選択肢は、その親からスコアリング関数を継承します。選択肢のスコアリングで、その選択肢に適用するパフォーマンス・メトリックを特定して、スコアリング・メソッドをそれに適用します。スコアリング・メソッドには、スコアリング・ルール、関数、定数、選択肢イベント・モデルでのイベントの発生率などを指定できます。
たとえば、図13-3に示す選択肢グループ構造を仮定すると、一部の選択肢は次のようなスコアリングを持つ場合があります。
Mileage Plus Card
パフォーマンス・メトリック: 売上の増加
スコア: 顧客がオファーを受け入れる可能性と、オファーの潜在的売上を計算するためにカードの期待利益を使用する関数。可能性はモデルで計算されます。
Gold Card
パフォーマンス・メトリック: 売上の増加
スコア: 選択肢グループ・レベルから継承された定数
Credit Analysis
パフォーマンス・メトリック: 顧客維持の増加
スコア: 顧客データを使用してスコアを割り当てるスコアリング・ルール
|
注意: 選択肢または選択肢グループの「スコア」タブの「スコア」列で定義されるスコアの値は、任意の実数(つまり、正の値、負の値またはゼロ)にできます。 |
適格性ルールは、選択肢グループ・レベルおよび選択肢レベルで次のように使用できます。
選択肢グループには選択肢適格性ルールとグループ適格性ルールを設定でき、それぞれ選択肢グループ・エディタの「選択肢の適格性」タブと「グループの適格性」タブにあります。
選択肢グループのグループ適格性ルールは、選択肢グループ・レベルで定義される属性に適用されます。
選択肢グループの選択肢適格性ルールは、一般的にその選択肢グループに定義されている選択肢の属性に適用されます。
選択肢には選択肢適格性ルールを設定でき、選択肢エディタの「適格性ルール」タブにあります。
選択肢および選択肢グループに対するこれらのルールによって、意思決定の参加の適格性が判断されます。適格性ルールにより、目的の選択肢が、選択関数やデシジョンのルールまたは選択肢を選択するロジックへの参加に適格かどうかを判断します。
適格性ルールにより、選択肢グループまたは選択肢の先頭となるサブツリーが意思決定に適格かどうかを判断します。選択肢自身が適格であっても、そのすべての子孫が適格でないと、それらは適格となりません。
これらのルールのエディタを使用する方法の詳細は、第13.11項「ルール・エディタの使用」を参照してください。
選択肢グループおよび選択肢のルールは、継承され、追加されるようになっています。つまり、選択肢グループ(GroupおよびChoiceルール)および選択肢レベルでルールがある場合、それは論理積が適用されるようにルールが拡張されます。継承されたルールは、「継承された適格性条件」というラベルの付いたルールの最上位の展開可能なセクションに表示されます。「ルールの移動」アイコンを使用して、セクションを開いたり閉じたりします。
次に、選択肢グループ・ルールと選択肢ルールとの間における相互作用の例を示します。
Group1 has rules GroupRule1 and ChoiceRule1 Group2 is a child of Group1 and has rules GroupRule2 and ChoiceRule2 Group2 has a Choice, Choice1, and it has a rule, Rule1
Choice1のルールを評価する際、各ルールは次の順序で起動されます。
GroupRule1 AND GroupRule2 AND ChoiceRule1 AND ChoiceRule2 AND Rule1
選択肢の適格性を判断する場合、選択肢に対して不必要に適格性ルールが評価されないように、最初に親の適格性がテストされます。
次のコードはそれぞれ、オブジェクトのラベルとIDを返します。
public String getSDOLabel(); public String getSDOId();
次のコードは、選択肢グループから選択肢オブジェクトを返します。
public Choice getChoice(String internalNameOfChoice);
選択肢属性が索引にマークされていると、次のメソッドを使用して、索引付き属性で参照される選択肢を返します。
public Choice getChoiceWithAttributeID(AttributeType val);
次のコードはそれぞれ、オブジェクトのラベルとIDを返します。
public String getSDOLabel(); public String getSDOId();
選択肢が含まれる選択肢グループを取得するには、次のコードを使用します。
public ChoiceGroup getGroup();
APIを追跡する選択肢イベントは、次に示すように、選択肢に定義された2つのメソッドで構成されます。
void recordEvent(String eventName); void recordEvent(String eventName, String channel);
選択肢イベントを記録する統合点の一般的なコードは、次のようになります。
String choiceName = request.getChoiceName(); String choiceOutcome = request.getChoiceOutcome(); ChoiceGroup.getChoice(choiceName).recordEvent(choiceOutcome);
適格性ルールは過去に同じ顧客に受け入れられ展開された前のオファーに依存するので、展開され受け入れられたオファーは、多くのインライン・サービスで適格性ルールに対して追跡する必要があります。
選択肢イベント履歴により、特定の顧客に関する2つの質問に答えることができます。
オファーが展開され受け入れられたのはどのくらい前か。
最近の特定の期間でオファーが展開され受け入れられた回数。
これらの質問の答えは、選択肢および選択肢グループに定義された次のAPIメソッドで提供されます。
int daysSinceLastEvent(String eventName); int daysSinceLastEvent(String eventName, String channel); int numberOfEventsDuringLastNDays(String eventName, int numberOfDays); int numberOfEventsDuringLastNDays(String eventName, int numberOfDays, String channel);
フィルタリング・ルールは、スタンドアロン・ルールとして、母集団のセグメント化に使用したり、他のルールのコンポーネントとして使用できます。スタンドアロン・ルールは、様々な要素で再利用可能です。
母集団のセグメントの識別に通常使用されるルールを図13-4に示します。
図13-4のルールは、年齢が18歳以上で信用限度額が$8000以上の顧客をターゲットとしています。
ルールの編集の詳細は、第13.11項「ルール・エディタの使用」を参照してください。
ブール値を返す適格性ルールと異なり、スコアリング・ルールでは数値を返します。返された値は、Oracle RTDのデシジョン・ロジック全体で使用できます。通常は次のような場合に使用されます。
特定のパフォーマンス目標の選択肢のスコアを設定する場合
選択肢属性の値を設定する場合
スコアリング・ルールには、どのルール・セグメントもtrueに評価されない場合のデフォルト値があります。
値を追加するには、「値」列の「その場合」または「値は次のとおりです」の下をクリックします。ここで、他のルール値と同様に、省略記号をクリックして値を編集します。
たとえば、図13-5に示すスコアリング・ルールでは、顧客の信用限度額に基づいてスコアが割り当てられます。いずれの信用限度額の範囲のカテゴリにも該当しないと、スコアはデフォルトの3.25になります。
また、スコアリング・ルールには次のオプションがあります。
説明: スコアリング・ルールはデシジョン・センター・ユーザーが調整できるため、スコアリング・ルールを適切に記述することが重要です。スコアの範囲を記入することをお薦めします。
詳細: 「詳細」ボタンを使用すると、デシジョン・センターに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。
ルールの編集の詳細は、第13.11項「ルール・エディタの使用」を参照してください。
ルールは、デシジョン・スタジオ内およびデシジョン・センター内で、様々な目的に使用します。具体的には次のような目的があります。
選択肢グループや選択肢をデシジョンに含めるかどうかの適格性を判断するため
スタンドアロンとして、意思決定のために母集団セグメントの作成に使用するフィルタリング・ルールを作成するため
スタンドアロンとして、選択肢のスコアリングに使用するスコアリング・ルールを作成するため
ルール・エディタのツールバーを使用すると、ルールの編集に使用する機能にアクセスできます。エディタのツールバーには、各ルール・エディタでルールを作成する際に必要な機能が用意されています。これらの機能は、ユーザーが実行するルール作成やルール編集のコンテキストに応じてアクティブになります。
ツールバーには、左から順に次の機能があります。
ルール・プロパティを編集
条件値の追加
ルールの追加
ルール・セットの追加
削除
反転
上に移動
下に移動
コピー
切取り
貼付け
ルールの作成に使用するエディタは、それぞれよく似ています。次の各項では、これらのエディタを使用してルールを作成する方法について説明します。
この項には次のトピックが含まれます:
Oracle RTDには次の3種類のルールがあります。
フィルタリング・ルール
スコアリング・ルール
適格性ルール
Oracle RTDのルールは、1つ以上のルール条件および条件の結合を制御する論理演算子から構成されます。これらの条件は、この項で説明するようにルール文の形式で表現されます。
|
注意: この項では、条件付きルール(常に真になるとはかぎらないルール)について説明します。 |
この項で単純なフィルタリング・ルールの例を次に示します。これは、ルール文の説明に使用します。
Select List Rule is true when All of the following 1. session / customer / Age > 21 2. session / customer / MaritalStatus = "MARRIED"
表13-9に、Oracle RTDのルール文で使用される項目を記述するBNF (Backus-Naur Form)タイプの規約を使用して、Oracle RTDのルール文法をより正式な表現で示します。
表13-9 Oracle RTDのルール文法
| 項目 | 項目のコンポーネント | 注意 |
|---|---|---|
|
|
|
なし |
|
|
|
ルールに名前を割り当てます。 ルールが作成された後は、ヘッダー行の編集はできません。 |
|
|
次のすべて | 次のいずれか | 次のいずれでもない | 次の一部 |
論理演算子により、直後に続く |
|
|
|
ルール・エントリには必ず番号が付与されます。ルール・エントリには、ブール文などのルール・エントリを記述できます。 |
|
|
|
2番目の |
|
|
|
|
|
|
|
配列処理ルール・セットでのみ使用されます。詳細は、「数量詞および配列処理ルール」を参照してください。 |
|
|
すべて | 次が存在 |
なし |
前述のSelect List Ruleの例は、次のように分類できます:
Select List Rule is true when: <header line>の部分
All of the following: <logical operator>の部分
<rule entry>の残りの部分は、次の2つの文で構成されています。
session / customer / Age > 21: <boolean statement>の部分
session / customer / MaritalStatus = "MARRIED": <boolean statement>の部分
ルール・セットおよびブール文
「ルール・セット」(表13-9では<ルール・セット>)は、1つ以上の番号付きルール・エントリで構成される複合文です。各ルール・エントリは、ブール文か、別のルール・セットです。
「ブール文」 (表13-9では<ブール文)には、評価結果がtrueまたはfalseになる条件が含まれています。この評価は、ルールが処理されるときに行われます。ブール文は、ルール・セットの最小レベルの要素であり、さらに分解することはできません。
オプションで、上位レベルのルール・セット内で定義されているルール・セットに名前を付与できます。
|
注意: Oracle RTDの各ルールには、暗黙で無名の最上位レベル・ルール・セットがあります。 |
各ルール・セットは、ルール・セット文の処理を制御する論理演算子によって修飾されます。詳細は、「論理演算子」を参照してください。
次のExclusion Rule例は、ルール・セット内にルール・セットが存在します。
この例は、次のことを表しています。
上位レベルの無名ルール・セットには、論理演算子のAll of the followingおよび2つのルール・エントリがあります。1番目のルール・エントリはブール文、2番目のルール・エントリはルール・セットです。
上位レベルのルール・セット内にあるルール・セットには、論理演算子のNone of the followingおよび3つのルール・エントリがあります。これらのルール・エントリはそれぞれがブール文です。
論理演算子
Oracle RTDの論理演算子を次に示します。
次のすべて(論理積、and)。ルール・セットでは、ブール文または下位レベルのルール・セットがすべてtrueになる場合にtrueと評価されます。
次のいずれか(論理和、or)。ルール・セットでは、ブール文または下位レベルのルール・セットのいずれか1つがtrueになる場合にtrueと評価されます。
次のいずれでもない(否定論理積、not and)。ルール・セットでは、ブール文または下位レベルのルール・セットがすべてfalseになる場合にtrueと評価されます。
次の一部(否定論理和、not or)。ルール・セットでは、ブール文または下位レベルのルール・セットのいずれか1つがfalseになる場合にtrueと評価されます。
数量詞および配列処理ルール
次に示すように、ルール・セットでは配列に出現する値に依存する場合があります。
ルール・セットで配列の要素を評価できる場合
ルール・セット内の式で配列の要素を参照できる場合
このようなタイプのルールを「配列処理ルール」と呼びます。
配列処理ルールには、「数量詞」式(数量詞とも呼ばれる)によってルール・セットの論理演算子が修飾されるルール・セットがあります。ルール・セットの文は、すべての配列要素に対して満たされるか、1つ以上の配列要素に対して満たされるかのどちらかである必要があります。
次の例では、配列属性のsession/agentsに含まれるすべてのエージェントを調べるルールが作成されています。この例では、すべてのエージェントが30歳以上でありステータスがQualifiedである場合に、ルールがtrueと評価されます。
Agent Rule is true when For all people in session/agents, All of the following 1. people / Age >= 30 2. people / Status = "Qualified"
配列処理ルールの構文の詳細は、次の項を参照してください。前述の例では、項目のpeopleはユーザー定義項目であり、ルール・セット内で個々の配列要素を識別するために使用されています。
配列処理ルールの修飾
配列処理ルールの修飾処理の一般的な計算式を次に示します。
<数量子> <配列変数> in <配列名>, <論理演算子>
ここで:
quantifierは、For allまたはThere existsのどちらかです。
すべて: この数量子は、ルール・セットの論理演算子と連携して、各配列要素の検査が必須であることを示します。また、各配列要素について、被修飾ルール・セット内のブール文と下位ルール・セットがすべて満たされている必要があります。
被修飾ルール・セット内のすべてのブール文および下位ルール・セットが満たされていない配列要素が見つかると、ルール評価による配列処理は終了します。配列の残りの要素はスキップされます。
次が存在: この数量子は、ルール・セットの論理演算子と連携して、被修飾ルール・セット内のすべてのブール文と下位ルール・セットが少なくとも1個の配列要素について満たされている必要があることを示します。
修飾されるルール・セットにあるすべてのブール文と下位レベルのルール・セットが満たされる配列要素が1つ見つかった時点で、ルールの評価は中止されます。配列の残りの要素はスキップされます。
array_variableは、修飾されるルール・セットにあるブール文と下位レベルのルール・セットにおいて配列のarray_nameにある個々の配列要素を識別するための任意の名前です。
|
注意:
|
array_nameは調査対象となる配列です。
logical_operatorは、All of the following、Any of the following、None of the following、Not all of the followingのいずれか1つです。
配列処理ルール・セットの例として、sessionとcustomerの2つのエンティティについて考えます。
sessionエンティティには、次の属性が含まれています。
Integer型の属性のAgentDept
customer型の配列属性のCustInfo
customerエンティティには、次の属性が含まれています。
Integer型の属性のCompSize
String型の属性のRegion
次の条件を両方とも満たすフィルタリング・ルールが必要です。
AgentDeptの値は42である必要があります。
CustInfo配列において1人以上の顧客について、CompSizeが100未満でさらにRegionがWestである必要があります。
このフィルタリング・ルールは、たとえば次のように定義できます(配列を修飾する式が強調されています)。
Cust Rule is true when
All of the following
1. session / AgentDept = 42
2. There exists some_customer in session / CustInfo, All of the following
1. some_customer / CompSize > 100
2. some_customer / Region = "West"
ルール・セットの追加
ルール・セットを追加するには、「ルール・セットの追加」アイコンをクリックします。
ルールに最初に作成する要素の場合、ルールに次の文が表示されます。
デフォルト論理演算子のAll of the following
ルールの番号付きの先頭行として表示されるルール・セット・エントリ: デフォルト論理演算子のAll of the followingが含まれます
オペランドが2つで空のブール文: 新たに定義されるルール・セット内にあります
これ以外の場合、現在のルール・セットで次のエントリとして、オペランドが2つで空のブール文を含む新規ルール・セット・エントリが追加されます。たとえば、ブール文が1つ含まれている既存ルール・セットにルール・セットを追加すると、追加されたルール・セット・エントリは、次に示すように、行番号2の横に表示されます。
ルール・セットの右上隅をクリックすると、名前を付与できます。ルール・セットに名前を付与する際、ルール・セット・ボックスの右上隅にある山形記号アイコンをクリックすると、ルール・セットを開いたり閉じることができます。
ルールへの(ブール文の)追加
ブール文を追加するには、「ルールの追加」アイコンをクリックします。
ルールに最初に作成する要素の場合、次に示すように、デフォルト論理演算子のAll of the followingが表示され、その後にオペランドが2つで空のブール文が表示されます。
これ以外の場合、オペランドが2つで空のブール文が現在のルール・セットに追加されます。ブール文が1つ存在する場合の例を次に示します。
デフォルトでは、ブール文には2つのオペランドとそれらの間に演算子があります。
ブール文を1オペランドと2オペランドで切り替えるには、次の例に示すように、ブール文の行番号をクリックし、ブール文ボックスの右下隅の矢印アイコンをクリックします。
1オペランドは、常にブールとして評価されます。
ルールのブール文を編集するには、左側をクリックしてから、省略記号をクリックします。定数、属性、関数コールのいずれかを選択できます。配列の値を指定するには、ページの最上部で「配列」を選択します。
|
注意: 演算子ダイアログは、[Esc]キーを使用していつでも閉じることができます。 |
「定数」を選択した場合、項目の「データ型」および「値」を指定します。「配列」を選択した場合、必要な数の項目を配列に追加します。次に、各項目について「データ型」を選択し、「値」を指定します。
「属性」を選択した場合は、次のいずれかを指定します。
グループ属性: ルールのプロパティで選択されている選択肢グループまたはその選択肢の一部である属性。
セッション属性: セッション・エンティティの一部である属性。
アプリケーション属性: アプリケーション要素のメンバーである属性。
配列変数: 数量化された論理演算子式内にあるルール・セットの個々の配列要素を識別するための名前。詳細は、「数量詞および配列処理ルール」を参照してください。
フィルタ・タイプの適用を選択し、「データ型」を選択して、型別に属性をフィルタリングします(必須ではない)。「配列」を選択した場合は、必要な数の項目を配列に追加してから、それぞれに属性値を割り当てます。
「関数コール」を選択した場合は、次のいずれかを指定します。
フィルタリング・ルール: インライン・サービス用に定義されているスタンドアロンのフィルタリング・ルール。
スコアリング・ルール: インライン・サービス用に定義されているスタンドアロンのスコアリング・ルール。
関数コール: インライン・サービス用に定義されているスタンドアロンの関数。
フィルタ・タイプの適用を選択し、「データ型」を選択して、型別に属性をフィルタリングします(必須ではない)。「配列」を選択した場合は、必要な数の項目を配列に追加してから、それぞれに関数またはルールを割り当てます。
オペランドまたはオペランドの一部として型が制約されたオブジェクトを選択すると、他のオペランドの値が含まれるドロップダウン・リストから値を表示できます。このドロップダウン・リストから値を選択できますが、値の選択は必須ではありません。
型制約と型制約オブジェクトの詳細は、第13.19項「型制約について」を参照してください。
フィルタリング・ルールにもスコアリング・ルールにもルールのプロパティがあり、そのプロパティは設定可能です。ルールのプロパティを編集するには、「ルール・プロパティ」アイコンをクリックします。
「ルール・プロパティを編集」が表示されます。
ルールのプロパティには、コール・テンプレートとネガティブ・コール・テンプレートがあります。コール・テンプレートを使用すると、別のルールからルールをコールする方法がわかりやすくなります。
コール・テンプレートを定義するには、「パラメータ」の下の「追加」ボタンをクリックして、ルールのパラメータの数を増やします。{0}や{1}などを引数として使用し、ルールを説明する表現を設定して、コールのテンプレートを定義します。この表現はルール使用時に表示されるため、わかりやすい表現を使用することが重要です。
たとえば、ユーザーから最近y日間にx回以上の通話があったことを確認するルールは、次のように表現できます。
There were at least {0} calls in the last {1} days
ネガティブ・コール・テンプレートは、ルールを逆にする場合に使用し、次のように逆の表現になります。例:
There were less than {0} calls in the last {1} days
ルールのプロパティを使用すると、ルールで使用する選択肢グループを割り当てることもできます。「選択肢グループで使用」を選択することにより、パラメータで使用する選択肢属性を提供する選択肢グループまたはその中の選択肢を指定できます。これらの属性は、オペランドの値を編集するときに使用できます。
「反転」アイコンは、ルールで複数の要素を逆にします。ブール文の番号を選択することで、ブール文の演算子を逆にできます。たとえば、演算子が=であった場合は、反転して<>になります。
ルール・セットの論理演算子も逆にできます。それには、論理演算子を選択して「反転」をクリックします。たとえば、「次のすべて」は「次の一部」になります。
「反転」の最後の使用方法は、ブール、つまり1オペランドのルールを逆にすることです。このタイプのルールを逆にすると、ルールを定義する関数のネガティブ・コール・テンプレートに変換されます。
デシジョンは、適格な選択肢のグループから1つ以上の選択肢を選択するために使用します。デシジョンは、アドバイザ内で使用するのが最も一般的です。アドバイザでは、2つのデシジョンをコールできます。1つは、通常の処理に使用するデシジョンで、もう1つはインライン・サービスでコントロール・グループ機能を使用する場合のデシジョンです。
デシジョンの設定には、選択肢の選択元である選択肢グループを1つ以上だけでなく、選択肢に順序を付けるための数値選択基準も含まれている必要があります。
選択肢の選択は、ランダムにもできますし、カスタム選択関数によってもできます。また、関連するパフォーマンス目標ごとに選択肢グループ・レベルで構成されているユーザー定義スコアリング・ロジックに基づいても選択できます。
静的スコア、関数ドリブン値、ルールベースのスコアまたは予測スコアなど、様々なスコアリング手法を使用して、選択肢ごとに複数のスコアを定義できます。
実行時に、デシジョンでは、関連付けられた選択肢グループのサブツリーで適格な選択肢をすべて識別します。次に、適格な選択肢がすべてスコアリングされ(1つ以上のスコアを使用して)、順序付けされます。
選択肢のスコアリング手法の例を次に示します。
選択肢に関心を持つ確率(Oracle RTDの自己学習予測モデルで計算)
選択肢のビジネス価値(ユーザー定義のルールまたは関数で計算)
あるいは、カスタム選択関数を作成して選択肢を選択することもできます。
選択基準は次のとおりです。
選択肢を次から選択: デシジョンでの検討対象となる選択肢グループ(複数可)の割当てに使用します。
選択する選択肢の数: デシジョンで選択される選択肢の最大数を示します。実行時に返される選択肢の実際の数は、適格性ルールに基づいて、この数と同等以下になる場合もあります。
複数の接点で1つのデシジョンがコールされ、そのたびに異なる数の選択肢を返す必要がある場合、この数をアドバイザ・レベルで上書きできます。
デフォルトであり、最も一般的に使用される数値は1です。
選択のタイプ用ラジオ・ボタン: 選択されたラジオ・ボタンによって、ランダムな選択肢を選択するか、選択肢を選択する手順の一部として重み付けされたパフォーマンス目標を使用するかが制御されます。
「固定目標加重で選択」オプションにより、母集団セグメントを指定し、各セグメントのパフォーマンス目標の重み付けを設定できます。このオプションを選択すると、画面に次に示す領域が表示されます。
ターゲット・セグメント: フィルタリング・ルールを使用してセグメント化されている母集団のセグメント。デフォルトのセグメントは全員(everyone)です。
優先度: 特定のセグメントのパフォーマンス目標の重み付けの設定に使用します。スコアリングで使用されるパフォーマンス目標は、デシジョンで選択されます。したがって、指定された各目標は、デシジョンで選択されている各選択肢グループのスコアリング方法に適合している必要があります。
「カスタム目標加重で選択」オプションにより、パフォーマンス目標のカスタム重み付けを設定できます。通常は実行時にパフォーマンス目標の重み付けを返す関数を実行します。
「カスタム目標加重で選択」オプションを選択し、その横にある省略記号ボタンをクリックした場合、「値」ウィンドウで次のいずれかを選択する必要があります。
「関数またはルール・コール」を選択してから、データ型がcom.sigmadynamics.sdo.GoalValuesを返す関数を選択します。
「属性または変数」を選択してから、型がcom.sigmadynamics.sdo.GoalValuesであるアプリケーション・パラメータまたはセッション属性を選択します。
「ランダムに選択」オプションを選択すると、選択肢グループからランダムに選択した選択肢を割り当てます。これは主として、Control Groupデシジョンに使用します。
「固定目標加重で選択」オプションと「カスタム目標加重で選択」オプションの詳細は、第13.12.1項「母集団のセグメント化と目標の重み付け」を参照してください。
選択肢グループを追加するには、「選択」をクリックしてから、使用する選択肢グループ(複数可)を選択します。
デシジョンのパフォーマンス目標を選択するには、「目標」をクリックしてから、適切な目標を選択します。
この項には次のトピックが含まれます:
デシジョンでは、母集団のセグメントをターゲットとし、セグメントごとにそのデシジョンにアタッチしているパフォーマンス・メトリックに重みを付けることができます。
|
注意: ビジネス・ユーザーは、デシジョンのライフサイクル全体の任意の時点で、デシジョン・センターでデシジョンの優先度(特定セグメントのデシジョンに適用される重み付け)を変更できます。優先度は、デシジョン・センターの次の図と同様のウィンドウで変更できます。次に示すウィンドウは、Oracle RTDに付属のCross Sellアプリケーションのものです。  |
パフォーマンス目標に必要な重み付けの種類に応じて、デシジョンは2種類の方法で設定できます。
事前定義済の重み付け: インライン・サービスで値が指定されます。
カスタムの重み付け: 実行時に値の計算や変更ができます。
事前定義済の重み付けの場合、デシジョン設定プロセスを開始するには、デシジョンの「選択基準」で「固定目標加重で選択」を選択します。
次に、1つ以上のターゲット・セグメントを追加します。これは、次に示すように、ルールまたは関数で定義します。
セグメントを追加するには「追加」、削除するには「削除」をクリックします。
最後に、各セグメントで次の手順を実行することで、各セグメントで選択したパフォーマンス目標ごとに固定パーセンテージの重み付けを指定します。
セグメントをクリックします。
「目標」をクリックし、このデシジョンで使用するパフォーマンス目標を選択します。
選択したパフォーマンス目標が「優先度」領域に表示されます。
「優先度」領域で各パフォーマンス目標の重み付けを指定します。
たとえば、インライン・サービスのSelect Best Offerというデシジョンに、Customer RetentionとRevenueという2つのパフォーマンス目標が定義されていると仮定します。また、フィルタリング・ルールによりPeople to retainという母集団のセグメントが定義されています。デフォルトの残りは、抱合せ販売の対象となるセグメントです。
重み付けは、パフォーマンス目標ごと、かつセグメントごとに行います。
People to retain
Customer Retention: 90%
Revenue: 10%
デフォルト
Customer Retention: 20%
Revenue: 80%
カスタムの重み付けの場合、デシジョン設定プロセスを開始するには、デシジョンの「選択基準」で「カスタム目標加重で選択」を選択します。主な特徴は、実行時にパフォーマンス目標の重み付けを取得したり計算するために作成する必要がある関数です。この関数は、com.sigmadynamics.sdo.GoalValuesデータ型を返す必要があります。
|
用語: この項では、この関数を目標のカスタム重み付け関数と呼びます。 |
通常は、関数には目標の重み付けの値に影響を与える場合があるパラメータがありますが、必ずしも必須ではありません。
目標のカスタム重み付け関数内では、明示的にセグメントを作成しません。かわりに、母集団を細分化した部分ごとにパフォーマンス目標の重み付けを返す条件を1つ以上指定できます。
デシジョンを設定する際、プロセスの推進パラメータとして明示的に目標のカスタム重み付け関数を選択できます。また、目標のカスタム重み付け関数または他のソースから目標を受け取るアプリケーション・パラメータまたはエンティティ属性を選択できます。
たとえば、ターゲット母集団を効果的にセグメント化する条件としてIsMarriedが定義されていると仮定します。パフォーマンス目標としてMax RevおよびMin Costsの2つを使用します。
パフォーマンス目標の重み付けを計算してからcom.sigmadynamics.sdo.GoalValuesデータ型で返す関数のGet GoalValuesを作成します。
|
注意: 原理を示すために、次の例ではパフォーマンス目標として特定の数値を使用しています。これらの数値は、関数の別の場所でその値が評価される変数で置換できます。 |
目標のカスタム重み付け関数のGet GoalValuesの主要部分は次のように記述できます。
if (IsMarried)
{return new GoalValues().buildValueForMaxRev(100).buildValueForMinCosts(50);}
else
{return new GoalValues().buildValueForMaxRev(80).buildValueForMinCosts(120);}
事前定義済の重み付けとカスタムの重み付けの両方を使用する場合、このデシジョンが呼び出されると、パフォーマンス・メトリックのスコアリング(whether関数、スコアリング・ルール、関数など)が、適格な選択肢すべてに適用されます。スコアは、パフォーマンス・メトリックの正規化ファクタを使用して均一化されます。次に、デシジョンに含まれているパフォーマンス・メトリックの重み付けに従って、スコアに重みが付けられます。全体のスコアが得られ、スコアが最も高い選択肢が選択されます。
標準のスコアリング・デシジョン・プロセスではなく、カスタム選択関数を使用する場合は、「カスタム選択」タブで「カスタム選択」オプションを選択します。リストから選択関数を選択し、関数に必要なパラメータを追加します。
「選択前/後」タブのスクリプトレットは、スコアリングが完了してデシジョンが作成される前または後に実行されます。
選択前ロジックは、適格な選択肢をすべて収集してから選択が行われるまでの間に実行されます。選択後ロジックは、選択後、選択した選択肢が返されるまでの間に実行されます。選択後ロジックの方が一般的です。たとえば、この部分を使用して、Oracle RTDから推奨された選択肢を記録できます。
このロジックでは、選択肢の計算用に定義されている変数を使用できます。たとえば、選択前は適格な選択肢、選択後は選択した選択肢を含む選択肢配列の名前が、「選択前/後」タブで設定されます(デフォルトはchoices)。
デシジョンはchoiceArrayを返します。個々の要素にアクセスするには、配列のインデックスを使用します。次の例では、choiceArrayを読み取って、ベース・イベントDeliveredを選択肢イベント・モデルに記録します。メソッドchoice.recordEventは、モデルrecordEventをコールして、記録する選択肢に渡します。
for (int i = 0; i < outputChoiceArray.size(); i++) {
Choice choice = outputChoiceArray.get(i);
choice.recordEvent("Delivered");
}
session().addAllToPresentedOffers(outputChoiceArray); /* Store presented offers for future reference */
重み付けパラメータの型はGoalValuesです。GoalValuesクラスには、デシジョンで定義されている目標ごとに、getValueメソッドがあります。たとえば、目標がCustomerRetentionとRevenueの場合、メソッドは次のようになります。
public double getValueForCustomerRetention(); public double getValueForRevenue();
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。デシジョン・センターの表示ラベルを変更して、その要素をデシジョン・センターNavigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
標準のスコアリング・デシジョン・プロセス以外の方法として、デシジョンでは選択関数を使用できます。選択関数はすべてユーザーが定義します。ただし、選択関数には明確な特性があります。選択肢配列を入力すると、出力として選択肢配列が返されます。
選択関数には、説明および次に示すパラメータがあります。
入力選択肢配列: 選択関数に対する入力パラメータ。この変数のデータ型はSDChoiceArrayです。
出力選択肢配列: 選択した選択肢を含む変数の名前を指定し、この選択関数のコール元に返す必要のある戻り変数。この戻り値は、この選択関数に渡される「入力選択肢配列」、または「ロジック」パネル内でローカルに定義した別の変数になります。この変数のデータ型はSDChoiceArrayです。
選択肢パラメータの数: 選択関数で返す必要のある選択肢の数を表す関数の引数の名前。このパラメータのデフォルト名はnumChoicesです。この引数のデータ型はintです。
加重: この選択関数を使用するデシジョンに目標が定義されている場合は、その目標が、「加重」で指定されているパラメータの下の選択関数に渡されます。この型はGoalValueです。GoalValueの詳細は、デシジョンに関する項を参照してください。
追加のパラメータ: 選択関数で必要なその他すべてのパラメータ。
この項には次のトピックが含まれます:
選択関数は、選択条件のカスタム関数として使用します。数多くの標準的な優先度関数が、テンプレートを使用して利用できます。優先度関数や選択関数はJavaで定義します。これらのセットはテンプレートで事前に定義され、通常の場合、必要な箇所に記入されるか、拡張プロトタイプが用意されてそれを変更します。
「入力選択肢配列」として渡されるリストから選択肢を実際に選択するJavaコードは、「ロジック」ペインに入力します。多くの場合、「ロジック」セクションのJavaコードは、他のクラスを参照します。Javaコードと関数を正しくコンパイルするには、該当するクラスを関数にインポートする必要があります。
executeメソッドによって選択関数がコールされます。
選択関数の簡単な例を次のサンプル・コードに示します。
double maxL = -1.0;
Choice ch = null;
for (int i = 0; i < eligibleChoices.size(); i++) {
Cross_Selling_OfferChoice cso = (Cross_SellingOfferChoice)eligibleChoices.
get(i);
double likelihood = cso.getLikelihood();
if (ch == null || (!Double.isNaN(likelihood) && likelihood > maxL)) {
maxL = likelihood;
ch = cso;
}
}
SDChoiceArray selectedChoices = new SDChoiceArray(1);
if (ch != null)
selectedChoices.add(ch);
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。デシジョン・センターの表示ラベルを変更して、その要素をデシジョン・センターNavigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
モデルは、主に予測およびレポートの2つの目的で使用します。モデルは、次の目的を達成できるように定義する必要があります。
選択肢に関連付けられている特定イベントの発生率の予測
それらのイベントと相関関係にあるデータの分析
Oracle RTDのモデルでは、ビジネス・プロセスでデシジョンを改善するために予測モデルを設計して統合する際に対処が必要な作業の多くが自動化されます。自動化される作業は次のとおりです。
予測モデルを適用する前に入力データにデータ変換を適用する作業
モデルの品質を検証する作業
新しいターゲット属性が出現した場合にモデルの再構築と再較正を行う作業
新しいデータや新しい結果によりモデルの精度を検証する作業
調査を可能にする意思決定プロセスにおいてある程度のランダム性を導入する作業
この項の以降の部分では、Oracle RTDのモデル機能によってこれらの様々な状況に対処する方法について説明します。
|
注意: また、Oracle RTDの予測モデルに累積されたデータを外部データベースの表にエクスポートして、レポートとビジネス・インテリジェンスに関して標準的な製品や手法を使用して分析できます。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「モデル・スナップショットの設定と使用」を参照してください。 |
モデルは次のデータによって更新され、次のデータから学習します。
セッション・エンティティ内のすべてのデータ。特に、すべてのセッション属性(インライン・サービスの構成によって分析から明確に除外されている場合を除く)
また、選択肢イベント・モデルもイベントに関する詳細を必要とします。詳細は、第13.14.1項「モデルの種類」を参照してください。
モデルは、デザイン・タイムに選択肢グループに関連付けられます。これにより、予測とレポートの適用先となる選択肢のリストが定義されます。Oracle RTDのモデルが適用される選択肢の特性には、次の例に示すように非常に柔軟性があります。
長期間にわたって顧客に提示されて購入されたオファーのリストが含まれるMarketing Offers選択肢グループにモデルを関連付けることができます。このモデルは次の目的で使用できます。
予測: 特定の顧客がリスト内の特定オファーを購入する確率を計算するため
分析: 購入イベントと相関関係がある顧客特性を明らかにするレポートを作成するため
Call was transferredとCall was not transferredの2つの選択肢が含まれるCall Transfer選択肢グループにモデルを関連付けることができます。このモデルは次の目的で使用できます。
予測: 特定の顧客通話が転送される確率または転送されない確率を計算するため
分析: 転送イベントと相関関係がある通話、エージェントおよび顧客の特性を明らかにするレポートを作成するため
Oracle RTDの用語では(他の手法と比較して)、Oracle RTDの1つのモデルは、1つのターゲット属性ではなく、複数のターゲット属性の一覧に適用されます。したがって、Oracle RTDのモデルによって、このモデルが適用されるすべての選択肢に適用される一連の共有パラメータが定義されます。Oracle RTDのモデルによって実質的には共有メタデータが定義されるので、Oracle RTDのモデルは時間とともに変化する選択肢の集合に適用できます。例:
Marketing Offer選択肢グループに新しいオファーを追加すると、Oracle RTDによって自動的に共有モデル・パラメータが新しいオファーに適用できます。
|
注意: Oracle RTDのモデルのパラメータは、モデルのライフサイクルの任意の時点で追加的に変更でき、この変更はそれ以降のすべてのモデル操作に対して適用されます。 |
Oracle RTDモデルの技術的な詳細は、付録A「Oracle RTDモデルの機能と戦略」を参照してください。
この項の以降の内容は次のとおりです。
Oracle RTDでモデルを定義する場合、選択肢イベント・モデル、選択肢モデルおよびモデルの3種類から選択できます。
モデルの各種類は、事前定義済の使用パターンに対応しています。ほとんどの特性は共通していますが、ビジネス・デシジョンを向上する目的で予測を使用する際の自動化の度合いが異なります。すべての種類のモデルを予測とレポートに使用できます。
選択肢モデルと選択肢イベント・モデル: これらのモデルは、選択肢グループ型のターゲット属性に関連付けられます。
選択肢イベント・モデルは、ベース・イベントに応じて、イベント発生の条件付き確率の予測と分析に使用します。選択肢イベント・モデルは、1つのベース・イベントとポジティブ・イベント一覧によって定義されます。このモデルを使用して、ベース・イベントが発生した場合にポジティブ・イベントが発生する条件付き確率を予測できます。モデルでは、ポジティブ・イベント一覧は順序として解釈されます。
複数の選択肢イベント・モデルを定義して特定の選択肢グループで発生する同一イベント・グループを追跡することは可能であり、一般的に行われます。モデルごとの違いは、時間枠、ベース・イベントまたはパーティション化属性に関するものがほとんどです。
選択肢モデルは、一般的な選択肢の発生率の予測と分析に使用します。選択肢モデルでは、選択肢に関連するイベントは定義されません。このモデルで予測するのは、選択肢が存在するかどうかです。
これは、選択肢がビジネス・プロセスに存在する可能性がある項目を表す場合に便利です。たとえば、通話理由、購入対象製品、訪問先Webページなどがあります。
モデル: このモデルは、セッション属性型のターゲット属性に関連付けられます。プレーン・モデルまたはモデルは通常は使用されませんが、選択肢、選択肢グループおよびイベントなどの抽象的概念固有の知識のない汎用予測モデルを表します。
選択肢モデルと選択肢イベント・モデルのどちらの場合も、そのモデルに存在しない数値属性値に基づく予測は、次のように最も近い数値属性値から生成されます。
最高値より大きい属性値については、最高値が取得されます。
最低値より小さい属性値については、最低値が取得されます。
既存の属性値の間にあたる属性値については、予測の実行に十分なデータがあれば、最も近い値が取得されます。
いくつかのモデル・パラメータは、3種類のモデルに共通しています。
アルゴリズム
「アルゴリズム」ドロップダウン・リストで、モデルで使用する予測アルゴリズムのタイプを定義します。
Oracle RTDでは、次の2種類のアルゴリズムがサポートされています。
Bayesianアルゴリズム
Regressionアルゴリズム
オプションを選択すると、確率のスコアを算出するための入力属性とターゲット属性との間における相関関係の処理方法が決まります。2つのアルゴリズムの違いについて理解を深めるには、数学の文献を参考にすることをお薦めします。一般論で言えば、Bayesianアルゴリズムはポジティブ結果の比率が低い場合に適しており、Regressionアルゴリズムはポジティブ結果の比率が高い(通常は15%以上)場合に適しています。
時間ウィンドウ
「デフォルトの時間ウィンドウ」チェック・ボックスと「時間ウィンドウ」ドロップダウン・リストによって、モデルで時間的なライフサイクルが定義されます。デフォルトの時間ウィンドウはアプリケーション・レベルで定義され、「デフォルトの時間ウィンドウ」の選択を解除し、「時間ウィンドウ」ドロップダウン・リストから選択した場合を除いて、モデルでデフォルトで使用されます。
モデルの時間枠は、次の値に設定できます。
「週」、「半月」、「月」、「2か月」、「四半期」、「半年」または「年」
古いデータが新しいデータと同じ影響を予測に与えないように、定義されたモデル時間枠に基づいて適切なタイミングで、Oracle RTDに新しいモデル・インスタンスが作成されます。
時間ウィンドウは、Oracle RTDのモデル学習、レポートおよび予測の重要なパラメータです。
モデル学習はすべての時間ウィンドウで発生し、学習した知識はそれぞれの時間ウィンドウ内で蓄積されます。
各時間ウィンドウの終了時に、その時間ウィンドウ内に学習したすべての知識がアーカイブされます。これらのアーカイブと現在の時間ウィンドウ内の知識によって、デシジョン・センター・ユーザーが時間ウィンドウ・ベースのレポートを生成する際に情報が提供されます。
デシジョン・センター・ユーザーは、次の時間ウィンドウ内に学習された情報をレポートできます。
任意の特定の時間ウィンドウ(「時間ウィンドウ」値リストから目的の時間ウィンドウを選択)
現在の時間ウィンドウのみ(「時間ウィンドウ」値リストから現在の時間ウィンドウを選択し、「不完全な時間ウィンドウの表示」を選択)
現在の時間ウィンドウと過去の時間ウィンドウを組み合せた特殊なケース(「時間ウィンドウ」値リストから現在の時間ウィンドウを選択し、「不完全な時間ウィンドウの表示」の選択を解除したままにする)
モデルで「予測に使用」オプションが選択されている場合は、現在の時間ウィンドウ内のその時点までの学習内容と、過去の時間ウィンドウにおけるすべての学習内容から予測が行われます。これにより、古いデータより新しいデータのほうが優先的に予測で使用されるようになります。
「予測に使用」と「可能性のランダム化」
すべての種類のモデルを予測とレポートに使用できます。予測目的で使用するモデルでは、「予測に使用」オプションを選択する必要があります。このオプションを選択した場合、さらに「可能性のランダム化」オプションを使用するかどうかを決定できます。
予測に使用するモデルは、Decision Serverの実行時に、適格な各選択肢の数学的確率の計算に使用できます。
「可能性のランダム化」オプションにより、局所的に最小または最大になる状況を予防するために、スコアに対してランダム化式が適用されます。このような状況は発生頻度が高く、モデルのライフサイクル中に新しい選択肢が導入された場合や新しく導入された選択肢に関連付けられたモデルが既存の選択肢のモデルと競合する場合に発生します。
新しい選択肢のコンテキストでは、新しい選択肢が提示される機会が実現されるように、そして学習を積み重ねた結果として、ある程度のランダム化を導入することが役に立つ場合があります。「可能性のランダム化」オプションを選択することで、モデルのスコアをランダム化する度合いをOracle RTDで決定できます。Oracle RTDは、モデル成熟度の第2および第3段階で、平均0、肯定的結果の平均確率に比例した標準偏差の正規確率変数を肯定的結果の確率に加えます。このプロセスの詳細は、付録A「モデルのランダム化された確率計算」を参照してください。
前提ノイズの削減
デシジョンのために予測モデルを使用する場合に対処が必要な1つの既知データ・パターンとして、自己達成型予測があります。この状況は一般的に、入力データ属性が常にモデルのターゲット属性に関連付けられている場合に発生します。この状況の発生が予測される場合、「前提ノイズの削減」オプションを選択します。
このオプションによって、モデル出力と高い相関関係にある入力属性値が自動的に識別され、予測から除外されます。
例:
ショッピング・カートに追加される製品を予測するためのモデルが構築されているものと仮定します。
ショッピング・カートに存在する製品の配列が、このモデルの入力として使用されるものとします。
「前提ノイズの削減」オプションを選択すると、製品と製品自身の間で観察される自己達成型相関関係が無視されます。Oracle RTDではさらに、入力製品に常に関連付けられている製品(たとえばセットの一部)が無視されます。
ノイズの削減は、非常に高い相関関係(約99から100%)を除外します。また、ノイズの削除は「最大入力カーディナリティ」モデル・パラメータに左右されます。このデフォルト値は500です。これは、最初の500個の異なる値を調べて、高い相関関係が判断されることを意味します。 一般的な値はこの中で発生する可能性が高いと考えられます。
ノイズとみなされた入力属性値は、予測では無視されますが、デシジョン・センターではこれまでどおり表示可能であり、グラフでは灰色の棒グラフで表示されます。
詳細: 「詳細」ボタンを使用すると、デシジョン・センターに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。
選択肢イベントと選択肢モデルの「選択肢」タブ
選択肢イベントと選択肢モデルの場合、「選択肢」タブには次に示す共通オプションがあります。
選択肢グループ
選択肢のラベル:デシジョン・センターで表示される選択肢グループのラベル
選択肢イベント・モデルの場合、「選択肢」タブには次に示す固有オプションがあります。
ベース・イベント: 選択肢イベント・モデルにより計算する条件付き確率のベースラインを表す選択肢に関連付けられているイベント。イベントは、選択肢グループ・レベルで定義されているイベントのリストから選択できます。
ベース・イベント・ラベル
正の結果イベント: モデルにより条件付き確率を計算する対象となるイベントのリスト。
たとえば、Product選択肢グループに関連付けられているモデルに、ベースライン・イベントとしてDelivered、ポジティブ・イベントとしてInterestedとPurchasedの2つが存在するものと仮定します。特定の製品を購入する確率は、次のように計算します。
このモデルにより、最初にDeliveredイベントが既知であることに基づいて、Purchasedイベントの確率を計算します。この値を計算できた場合は、それを使用します。
データが不十分でそのような予測ができない場合(つまり、モデルからNaNが返された場合)、モデルの確率関数で、Deliveredイベントが既知であることに基づいて、Interestedイベントの確率を計算します。この値を計算できた場合はそれを返します。
データが不十分でそのような予測ができない場合、モデルの確率関数からNaNが返されます。
このとき、ポジティブ結果のリストは、予測を試みたポジティブ・イベントの順序付きリストを表します。モデルの確率関数により、イベントの順序付きリストから最もポジティブなイベントを選択できます。
選択肢モデルの場合、「選択肢」タブには次に示す固有オプションがあります。
相互に排他的な選択肢: このオプションは選択肢モデルの場合に使用できます。モデルのターゲットを表す選択肢が相互に排他的であることを示します。
選択肢イベントと選択肢モデルの「属性」タブ
選択肢イベントと選択肢モデルの場合、「属性」タブには次に示す共通オプションがあります。
パーティション属性
パーティション化属性を追加してモデルをパーティション化することは、パーティション化属性の値ごとに個別にモデルを作成することと同等です。
たとえば、オファーの受入れ確率を予測するモデルを構築する場合、このオファーが提供され、受け入れられた対話チャネルを示すパーティション化属性を作成することが考えられます。Webオファーの受入れとコンタクト・センター・オファーの受入れを表すモデルを作成した場合、オファーを提示するチャネルが異なると、同じ特性を持つ顧客がオファーを受け入れる確率が大きく異なることが判明し、優れた予測モデルが実現されます。
パーティション化属性を選択した場合のデフォルト動作は、実行時に新しい各パーティション化属性値が学習プロセスに渡されると、モデルに新しいパーティションが自動的に作成されるというものです。パーティションの数を、指定した値のセットに制限できます。この入力は、選択したパーティション化属性の「値ドメイン」フィールドで行います。実行時に、指定した各値が初めて学習サーバーに渡された時点で、別個のパーティションが作成されます。指定していないすべての値に関する学習データを保持するために、Oracle RTDでは、指定していない値が初めて学習サーバーに渡された時点で、「その他」パーティションが作成されます。
多くのデシジョン・センター・レポートでは、レポート・ヘッダーでパーティション属性値を選択することで、結果をフィルタリングできます。これらのレポートで、パーティション化属性のフィルタリング値リストに「(なし)」という値がある場合は、その属性に対するNULL値が少なくとも一度は渡されたことを示します。
|
注意:
|
モデルをパーティション化するかどうかの決定は、次の理由から、非常に慎重に行う必要があります。
属性を作成することで選択肢と属性値の組合せごとの観察頻度が減少し、その結果としてモデル対話プロセスの速度が低下します。
モデルのサイズは、パーティション化属性のカーディナリティに大きく左右されます。
属性の除外:デフォルトでは、セッション属性とエンティティ属性はすべて、モデル入力として使用されます。モデル入力のリストから特定の属性を除外するには、除外する属性を「除外された属性」リストに追加します。
|
注意: パーティション属性を既存のモデルに追加したり、既存のモデルから削除したりすると、レポート、スナップショット、予測およびデプロイメントとの互換性が損なわれます。エラーを防止するために、Enterprise Managerを使用して古い学習データを削除してください。既存のデータを保持するには、既存のモデルをクローニングした新しいモデルを作成し、デシジョン・ロジックを更新して学習内容をこの新しいモデルに記録します。 |
選択肢モデルの場合、「属性」タブには次に示す固有オプションがあります。
集計方法: パーティション化属性の1つを選択すると、属性を学習するためのサブモデルを追加作成できます。パーティション化と同様に、ある属性に基づいて集計するデシジョンは、問題の属性の値に応じて、予測される可能性の抜本的相違に基づく必要があります。
選択肢イベントと選択肢モデルの「場所の学習」タブ
選択肢イベントと選択肢モデルの場合、「場所の学習」タブには次に示す共通オプションがあります。
(学習)「セッションのクローズ」または「統合点」
デフォルトでは、すべてのモデル学習操作は、セッションの終了時に行われます。あるいは、モデル学習操作のトリガー処理が必要な特定統合ポイント(インフォーマントまたはアドバイザ)も選択できます。
選択肢イベント・モデルの「一時データ記憶域」タブ
選択肢イベント・モデルの場合、あるセッションでベース・イベントが発生し、対応する肯定的イベントがそれより後のセッションで発生する場合に遅延学習を有効にするためのフィールドが「一時データ記憶域」タブに用意されています。
「一時データ記憶域」タブには次に示す共通オプションがあります。
一時データ記憶域の使用
一般的なデータ・パターンとして、選択肢に関連するイベントがすべて、Oracle RTDセッションの存続期間中に発生するわけではありません。予測に使用された元の入力値が、肯定的結果が遅れて発生した場合のモデルの更新にも使用されるようにするには、「一時データ記憶域の使用」オプションを選択します。
保存日数: 一時データをサーバーに格納しておく日数を指定します。
キー: 一時データ記憶域に格納されているデータは、「一時データ記憶域」タブで定義されているセッション・キーのいずれか1つがあれば取得できます。
「一時データ記憶域の使用」を選択すると、あるセッションで発生したベース・イベントの選択肢および選択肢属性が(「保存日数」で指定した期間だけ)保存されます。それぞれの選択肢および選択肢属性は、「キー」で指定した各セッション・キーIDによって識別されます。
以降のセッション(先行セッションで保存されたいずれかのキーと同じセッション・キー値を持つセッション)で、肯定的イベントが発生しましたが、対応するベース・イベントがそのセッション内にないとします。すると、Oracle RTDは先行セッションで保存したデータを検索し、現セッションのセッション・キー値と先行セッションのセッション・キー値を照合して、先行セッション内の対応するベース・イベントを探します。
先行セッションのベース・イベントの選択肢および選択肢属性と、現セッションの肯定的イベント・データが、次の学習時(セッション・クローズまたは指定の統合点)に学習モデルへ送られます。
次のコードはそれぞれ、オブジェクトのラベルとIDを返します。
public String getSDOLabel(); public String getSDOId();
この項には次のトピックが含まれます:
モデルは、次のサンプル・コードに示すgetChoiceEventLikelihoodメソッドのいずれかで問合せを実行できます。この問合せは、ある選択肢がモデルによって選択される確率と任意の選択肢が特定のイベントを持つ確率を返します。
public static double getChoiceEventLikelihoods(GENOffersChoice choice, String eventName); public static double getChoiceEventLikelihoods(GENOffers choiceGroup, String eventName);
選択肢イベント・モデルの場合、選択肢のメソッドrecordEventがコールされたときに、モデルのメソッドrecordEventが実行されます。したがって、このメソッドをモデル上で直接起動する必要はありません。このメソッドは通常、選択肢がコール元のアプリケーションに拡張された統合点内からコールされます。
たとえば、アドバイザの統合点では、次のようになります。
if (choices.size() > 0) {
Choice ch = choices.get(0);
ch.recordEvent("Presented");
session().setOfferExtended(ch.getSDOId());
}
この選択肢モデルに使用できるAPIは次のとおりです。
public static SDStringArray getChoice() public static void setChoice(SDStringArray _v) public static void addToChoice(String _a) public static void addAllToChoice(SDStringArray _c)
インフォーマントは通常、選択肢をモデルとともに記録します。たとえば、通話理由コードの選択肢をモデルReason Analysisとともに記録する場合は、次のようになります。
if (code == 17)
ReasonAnalysis.addToChoice("BalanceInquiry");
else if (code == 18)
ReasonAnalysis.addToChoice("MakePayment");
else if (code == 19)
ReasonAnalysis.addToChoice("RateInquiry");
else
ReasonAnalysis.addToChoice("Other");
次に示すAPIにより、ユーザーは文字列名を指定してモデル・オブジェクトを取得できます。選択肢モデル用APIと選択肢イベント・モデル用APIがあります。
APIの一般形式
ChoiceModel <cm_model_instance_name> = Application.getApp().getChoiceModel(<model_name>);
ChoiceEventModel <cem_model_instance_name> = Application.getApp().getChoiceEventModel(<model_name>);
ここで:
<model_name>はString型のモデル名である必要があります。
例
getChoiceEventModel APIの使用例は、「選択肢イベント・モデルAPIの例」を参照してください。
getChoiceModel APIの使用例は、「選択肢モデルAPIの例」を参照してください。
次に示すAPIにより、ユーザーは選択肢IDとイベントを渡して関連する選択肢イベント・モデルを自動的に更新できます。開発者が作成するイベント記録ロジックは1つで済みます。作成したコードは、それ以降にインライン・サービスに追加される選択肢および選択肢グループでも再利用可能であり、さらに編集する必要はありません。
APIの一般形式
<cem_model_instance_name>.recordEvent(<choiceId>,<eventId>);
ここで:
<cem_model_instance_name>はChoiceEventModel型で、事前にgetChoiceEventModel APIで取得済である必要があります。
<choiceId>はString型の選択肢識別子である必要があります。
<eventId>はString型のイベント識別子である必要があります。
選択肢イベント・モデルAPIの例
次にgetChoiceEventModel APIとrecordEvent APIの例を示します。
// Select the choice for the given classification int classification = session().getDnaRecord().getClassification(); String modelName = "DnaClassesAPITest"; ChoiceEventModel model = Application.getApp().getChoiceEventModel(modelName); // Definitions SDChoiceArray choices = new SDChoiceArray(); ChoiceGroupInterface group = ClassificationsTestApi.getPrototype().cloneGroup(); // Get the group of choices to simulate //group = ClassificationsTestApi.getPrototype().cloneGroup(); // Get all eligible choices group.getEligibleChoices(choices); int sz = choices.size(); // Iterate through all eligible choices in the group for (int i = 0; i < sz; i++) { ClassificationsTestApiChoice ch = (ClassificationsTestApiChoice) choices.get(i); String choiceId = ch.getSDOId(); String eventId = "record"; model.recordEvent(choiceId, eventId); if (ch.getClassification() == classification) { String cnm = ch.getSDOId(); eventId = "identified"; model.recordEvent(choiceId, eventId); logInfo("ID " + session().getDnaRecord().getId() + " Classification: " + classification + " choice: " + ch.getSDOId() + " size was: " + sz); } }
次に示すAPIにより、ユーザーは選択肢IDを渡して関連する選択肢モデルを自動的に更新できます。
APIの一般形式
<cm_model_instance_name>.recordChoice(<choiceId>);
ここで:
<cm_model_instance_name>はChoiceModel型で、事前にgetChoiceModel APIで取得済である必要があります。
<choiceId>はString型の選択肢識別子である必要があります。
APIの一般形式
<cm_model_instance_name>.recordChoice(<choiceId>);
ここで:
<cm_model_instance_name>はChoiceModel型で、事前にgetChoiceModel APIで取得済である必要があります。
<choiceId>はString型の選択肢識別子である必要があります。
選択肢モデルAPIの例
次にgetChoiceModel APIとrecordChoice APIの例を示します。
double amount = targetNumber;
double spacing = Application.getApp().getSpacing();
double max = Application.getApp().getMaxOutput();
double min = Application.getApp().getMinOutput();
//Application.logInfo("amount is: "+amount);
int nDigits = (int)Math.log10(max);
nDigits = nDigits + 3;
//Application.logInfo("nDigits in Dynamic Choices: "+nDigits);
String targetChoiceGroupName = Application.getApp().getTargetChoiceGroupName();
String targetChoiceBaseName = Application.getApp().getTargetChoiceBaseName();
double t_max = max-spacing;
double t_min = min-spacing;
ChoiceModel model = Application.getApp().getChoiceModel(modelName);
for (double t= t_max; t>t_min; t = t-spacing) {
String id;
if (amount > t) {
id = String.format(targetChoiceGroupName+"$"+targetChoiceBaseName+"%0 "+nDigits+".1fAbove", t);
model.recordChoice(id);
for (double it = t-spacing; it>t_min; it= it-spacing) {
id = String.format(targetChoiceGroupName+"$"+targetChoiceBaseName+"%0 "+nDigits+".1fAbove", it);
model.recordChoice(id);
}
break;
}
}
次に示すAPIにより、モデルのすべてのバージョンについて、またはパーティションが存在する場合はモデルの特定のパーティションについて、選択肢モデルまたは選択肢イベント・モデルの確率のスコアをユーザーは取得できます。
APIの一般形式
<cm_model_instance_name>.getChoiceLikelihood(<choiceId>);
<cem_model_instance_name>.getChoiceEventLikelihood(<choiceId>,<eventId>);
ここで:
<cm_model_instance_name>はChoiceModel型で、事前にgetChoiceModel APIで取得済である必要があります。
<cem_model_instance_name>はChoiceEventModel型で、事前にgetChoiceEventModel APIで取得済である必要があります。
<choiceId>はString型の選択肢識別子である必要があります。
<eventId>はString型のイベント識別子である必要があります。
例
次にgetChoiceEventLikelihood APIの例を示します。
ChoiceEventModel model = Application.getApp().getChoiceEventModel(modelName);
return model.getChoiceEventLikelihood(choiceId, eventId);
Oracle RTDには、インフォーマントとアドバイザの2種類の統合点があります。これらは、外部システムとOracle RTDの間の統合点を表します。
外部システムと順序番号も統合点ごとに定義されます。これらは、デシジョン・センターで表示されるプロセス・マップの生成に使用します。システムによって、スイムレーンと位置の順序(左から右)が決定されます。この順序は、整数のみでなくどんな数値でも可能であり、既存の統合点を変更しないで新しい統合点を導入できます。
この項には次のトピックが含まれます:
インフォーマントは、外部システムとOracle RTDとの間の非同期統合点を表します。
インフォーマントは通常、次に示すように、コンテキスト情報をOracle RTDに渡して意思決定プロセスをサポートするためにトリガーされます。
インフォーマントは、クローズ・ループ情報をOracle RTDに渡して、その予測モデルを更新します。
インフォーマントは、Oracle RTDにセッション識別子を渡して、外部データ・ソースから関連情報をフェッチします。
インフォーマントをインライン・サービスに追加する手順は次のとおりです。
外部システムを作成して、どのシステムが統合点にアクセスするかを特定します。
分析のターゲットを表す選択肢グループを作成します。たとえば、サービス・センターへの通話理由を表す選択肢グループなどです。
セッション・キー情報を受信し、セッションに基づいてデータを収集および処理するインフォーマントを作成します。
データのリポジトリであり、データを分析する分析モデルを作成します。
インフォーマントには、説明および次に示すリクエストの特徴があります。
セッション・キー: セッションを一意に特定するために使用される1つ以上のセッション・キー。メッセージ内のどのセッション・キーでも、セッションを十分に特定できるため、このメッセージに関連する情報をすでに含むセッションが存在する場合、メッセージはそのセッションにディスパッチされます。
外部システム: インフォーマントにリクエストを送信する外部システムを特定します。インフォーマントと外部システムを関連付けると、そのインフォーマントを、デシジョン・センターのプロセス・マップに、他のインフォーマントおよびアドバイザとともに表示できます。
順序: この番号は、デシジョン・センターのプロセス・マップに表示される一連の統合点における、このインフォーマントの位置を特定します。他の統合点より順番が小さい統合点は、他の統合点より前に表示されます。小数も使用できます。たとえば、2.1は2.2.の前に表示されます。
セッションの強制クローズ: これを選択すると、このインフォーマントの非同期ロジックがすべて実行された後に、このインフォーマントのセッションが、インライン・サービスによって自動的に停止されます。インフォーマントの「ロジック」タブのサブタブ内のどこかにJava文session().close();を配置しても、同じ効果が得られます。
この項には次のトピックが含まれます:
「リクエスト」タブで「選択」をクリックして、統合点のセッション・キーを選択します。これは、運用システムから統合点に提供される値の1つです。
「リクエスト」タブでドロップダウン・リストを使用して、統合点にアクセスする外部システムを選択します。このメニューは、外部システム要素を使用して外部システム識別子を作成することによって移入されます。
統合点にアクセスする順序は、「順序」に表されます。この番号と「外部システム」によって、デシジョン・センターでのエンドツーエンド・プロセスの表示が決まります。
「リクエスト」タブで「追加」をクリックして、リクエスト・データを追加します。Assignmentは、運用システムから統合点に提供される値です。Assignmentの特徴は次のとおりです。
受信パラメータ: インフォーマントに送信されるリクエスト内のフィールドの名前。このフィールドの値が、リクエストからセッション属性にコピーされます。この名前は、セッション属性と同じである必要はありませんが、普通は同じ名前が付けられます。
セッション・キーが作成されると、入力されたパラメータがセッション・キーの属性に割り当てられます。
タイプ: これはセッション属性のデータ型で、入力された引数はそこにコピーされます。有効な型は、integer、string、dateまたはdoubleです。
|
注意: リクエスト・フィールドの型とセッション・キーの属性が一致しない場合、変換メソッドを使用する必要があります。 |
配列: 型がコレクションの場合にマークされます。
セッション属性: リクエストの入力パラメータのマップ先となるセッションの属性。
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。デシジョン・センターの表示ラベルを変更して、その要素をデシジョン・センターNavigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
次のコードはそれぞれ、オブジェクトのラベルとIDを返します。
public String getSDOLabel(); public String getSDOId();
インフォーマントのロジックは、「ロジック」タブと「非同期ロジック」タブで操作します。インフォーマントのリクエスト・データは、この2つのタブのどちらかを使用するとアクセスできます。
この項には次のトピックが含まれます:
このスクリプトは、Request Dataで宣言されたいずれかのリクエスト・データの実行後に実行されます。インフォーマントの主要な目的が、運用システムのリクエスト・フィールドからセッション・キーおよびリクエスト・データにデータを転送することである場合、この処理は「データのリクエスト」タブでの宣言に従って自動的に行われるため、ロジックが不要な場合があります。
インフォーマントのロジックは通常、ログ・ファイルでメッセージ受信をトレースするため、またはインフォーマントのメッセージによってキーが提供されるエンティティを事前移入するために使用します。ロジックを使用すると、レスポンス時間がより重要なアドバイザで、後にこの処理を行う必要がなくなります。ロジックは、リクエスト・データの直後に実行されます。
インフォーマントのロジックは、選択肢を選択肢モデルとともに記録する場合にも使用できます。コールするメソッドについては、選択肢モデルのAPIを参照してください。
このスクリプトは、前項で説明した「ロジック」タブで定義したスクリプトの後に実行されます。ほかに必要な処理があったら、この領域に配置できます。非同期ロジックの実行順序は保証されません。
インフォーマントからリクエスト・データには、様々な方法でアクセスできます。入力されたパラメータがセッション属性にマップされる場合は、そのパラメータにgetメソッドがあります。
request.get$()
この$は、先頭が大文字のパラメータ名です。
この属性がマップされない場合は、パラメータのフィールド名を使用して、同じ結果をもたらすメソッドがあります。
String request.getStringValue(fieldName) SDStringArray request.getStringArrayValue(fieldName) boolean request.isArgPresent(fieldName)
アドバイザは、外部システムとOracle RTDとの間の同期統合点を表します。アドバイザは通常、Oracle RTDデシジョンを起動するためにトリガーされます。
アドバイザごとに、最適化されたデシジョンとControl Groupデシジョンの2つのデシジョンを使用できます。したがって、ユーザーは2つのオプションのパフォーマンスをそれぞれ比較できます。
一般的に、2つのデシジョンは次のように設定されます。
最適化されたデシジョンでは、Oracle RTDのデシジョン・フレームワークの拡張機能を利用したデシジョン・ロジックが実装されます。
Control Groupデシジョンは、最適化されたデシジョンの比較基準となるように、既存のビジネス・プロセスにできるかぎり近いものにします。
アドバイザにデフォルトの選択肢を定義できます。これらの選択肢は、サーバーでの計算を時間内に完了できない場合や、クライアントとサーバーの通信が切断された場合に使用されます。
アドバイザには、説明および次に示すリクエストの特徴があります。
セッション・キー: セッションを一意に特定するために使用される1つ以上のセッション・キー。メッセージ内のどのセッション・キーでも、セッションを十分に特定できるため、このメッセージに関連する情報をすでに含むセッションが存在する場合、メッセージはそのセッションにディスパッチされます。
アドバイザがコールされると、まずセッション・キーの作成が実行されます。
外部システム: アドバイザのリクエストをトリガーする外部システムを特定します。アドバイザと外部システムを関連付けると、そのアドバイザを、デシジョン・センターのプロセス・マップに、他のインフォーマントおよびアドバイザとともに表示できます。
順序: この番号は、デシジョン・センターのプロセス・マップに表示される一連の統合点における、このアドバイザの位置を特定します。他の統合点より順番が小さい統合点は、他の統合点より前に表示されます。小数も使用できます。たとえば、2.1は2.2.の前に表示されます。
セッションの強制クローズ: このオプションを選択すると、このアドバイザの非同期ロジックがすべて実行された後に、このアドバイザのセッションが、インライン・サービスによって自動的に停止されます。アドバイザの「ロジック」タブのサブタブ内のどこかにJava文session().close();を配置しても、同じ効果が得られます。
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。デシジョン・センターの表示ラベルを変更して、その要素をデシジョン・センターNavigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
「リクエスト」タブで「選択」をクリックして、統合点のセッション・キーを選択します。これは、運用システムから統合点に提供される値の1つです。
「リクエスト」タブでドロップダウン・リストを使用して、統合点にアクセスする外部システムを選択します。このリストは、外部システム要素を使用して外部システム識別子を作成することによって移入されます。
統合点にアクセスする順序は、「順序」に表されます。この番号と「外部システム」によって、デシジョン・センターでのエンドツーエンド・プロセスの表示が決まります。
「リクエスト」タブで「追加」をクリックして、リクエスト・データを追加します。リクエスト・データは、運用システムから統合点に提供される値です。リクエスト・データの特徴は次のとおりです。
受信パラメータ: アドバイザに送信されるリクエスト内のフィールドの名前。このフィールドの値が、リクエストからセッション属性にコピーされます。この名前は、セッション属性と同じである必要はありませんが、普通は同じ名前が付けられます。
セッション・キーが作成されると、入力されたパラメータがセッション属性に割り当てられます。
タイプ: これはセッション属性のデータ型で、入力された引数はそこにコピーされます。有効な型は、integer、string、dateまたはdoubleです。
|
注意: リクエスト・フィールドの型とセッション属性が一致しない場合、変換メソッドを使用する必要があります。 |
配列: このオプションは、型がコレクションの場合に選択します。
セッション属性: リクエストの入力パラメータのマップ先となるセッションの属性。
「レスポンス」タブで「追加」をクリックして、レスポンス・データを追加します。レスポンス・データは、リクエストを呼び出した後に、運用システムから統合点に返信される値です。レスポンス・データの特徴は次のとおりです。
レスポンス: レスポンスには、選択した選択肢オブジェクトの配列が含まれ、各選択肢には、名前付きの属性値のコレクションが含まれています。選択肢の選択プロセスは、アドバイザで参照されている2つのデシジョン・オブジェクトのいずれか一方によって制御されます。1つのデシジョンが、コール元のアプリケーションに与えられます。
使用するデシジョン: Control Groupのセッションではなく、通常のセッションに使用するデシジョン・オブジェクトの名前。このデシジョンが、アドバイザからコール元システムへのレスポンスになります。
使用する制御グループのデシジョン: 制御グループのデシジョンは、ベースラインを提供することによって他のデシジョンの効果を評価する方法として、少数のセッションのみに使用されます。制御グループのデシジョンを使用するセッションの割合は、インライン・サービスのアプリケーション要素で指定します。制御グループのデシジョンは、いつもどおりのロジックを使用して選択肢を選択するように設計する必要があります。つまり、インライン・サービスの導入前に企業で使用していたルールです。デシジョン・センター・コンソールにあるレポートで、アドバイザの通常のデシジョン・オブジェクトのビジネス効果を制御グループのデシジョンと比較できます。
パラメータ: デシジョンによって定義される入力パラメータ。「名前」列と「タイプ」列は説明のみで、デシジョン・オブジェクトからここに表示されます。
返される選択肢のデフォルト数: デシジョンによって返されるデフォルトの選択肢数。これは、デシジョンで定義されている選択肢の数です。
デフォルトのオーバーライド: アドバイザでは、参照先のデシジョンで指定されている数値を上書きまたはそのまま使用できます。ここでは、アドバイザのレスポンスに含めることのできる選択肢の最大数を指定します。
デフォルトの選択肢: コール元のクライアント・アプリケーションがアドバイザを起動しようとしたとき、サーバーの保証されているレスポンス時間内にアドバイザがレスポンスを提供できない場合に、コール元のクライアント・アプリケーションに返される選択肢のリスト。
デフォルトの選択肢は、アドバイザごとに指定する必要はありません。インライン・サービスでもデフォルトの選択肢を宣言することがありますが、これは独自の宣言を行わないアドバイザで使用されます。また、デフォルトの選択肢構成は、クライアント・アプリケーションに伝播され、Smart Clientコンポーネントによってローカルのファイル・システムに格納されます。したがって、その後は、サーバーに接続できないクライアント・アプリケーションで使用できるようになります。
アドバイザのロジックは、「ロジック」タブ「非同期ロジック」タブで操作します。
この項には次のトピックが含まれます:
このスクリプトは、「データのリクエスト」タブで宣言されたいずれかのリクエスト・データが実行されてから、クライアントにレスポンスが返信されるまでの間に実行されます。
アドバイザのロジックは、一般的には不要です。これは、リクエストとともに着信するデータを事前処理するため、またはデバッグ目的に使用します。
このスクリプトは、クライアントにレスポンスを返信するサーバー側メカニズムにレスポンスが渡された後に実行されます。クライアントで使用されているエンドポイントのタイプによっては、このスクリプトが終了する前にクライアントが結果の処理を開始し、並列性を強化することによって効果的なレスポンス時間を改善できます。
アドバイザからリクエスト・データには、様々な方法でアクセスできます。入力されたパラメータがセッション属性にマップされる場合は、そのパラメータにgetメソッドがあります。
request.get$()
この$は、先頭が大文字のパラメータ名です。
この属性がマップされない場合は、同じ結果をもたらすメソッドがいくつかあります。
String request.getStringValue(fieldName) SDStringArray request.getStringArrayValue(fieldName) boolean request.isArgPresent(fieldName)
統合点は、モデルの学習に寄与することなくサーバーでロジックを実行するリモート・プロシージャ・コールとして設計できます。設計の意図として特定のセッションにアクセスしない場合は、セッション・キーなしで統合点を定義できます。
統合点で使用できるAPIにはSession()メソッドが用意されています。このメソッドはセッション・オブジェクトを返します。セッション・キーが定義されていない統合点でSession()メソッドを呼び出すと、Oracle RTDでは一時セッションが作成されます。このセッションは、統合点によって生成および使用されるデータのコンテナとして使用できますが、一時的なセッションなので、他の統合点コールでは使用できません。
外部システムは、デシジョン・スタジオ内でのみ識別されます。外部システムは、インライン・サービスに統合する、エンタープライズ内の運用システムを表します。外部システムは、API経由ではアクセスできません。外部システムは、統合点で、どの外部システムがその統合点にアクセスするかを識別するために使用します。外部システムは、デシジョン・センターの統合マップでの表示に使用されます。
外部システムには、説明および表示ラベルがあります。表示ラベルを変更しても、オブジェクトIDには影響がありません。
カテゴリは、選択肢の整理に使用します。同じカテゴリにある選択肢はすべて、デシジョン・センターに一緒に表示されます。カテゴリには、クラスは生成されません。カテゴリは、デシジョン・センターで、選択肢のグループ分けおよび整理のみに使用します。
カテゴリの特徴は次のとおりです。
名前:デシジョン・スタジオに入力されるカテゴリの名前。
説明:デシジョン・スタジオに入力されるカテゴリの説明。
ラベルの表示: 表示ラベルを変更できます。オブジェクトIDには影響がありません。
関数は、計算など、再利用可能にする処理に使用できます。関数は、デシジョン・スタジオを使用して定義します。関数定義の特徴は次のとおりです。
説明: 関数の説明。
戻り値: 関数が値を返すかどうかを指定します。
データ型: 戻り値の型。
配列: このオプションは、戻り型が配列の場合に選択します。
コール・テンプレート: 関数のコール方法の定義。{0}や{1}などを引数として使用し、関数を説明する表現を設定して、コールのテンプレートを定義します。この表現は関数の使用時に表示されるため、わかりやすい表現を使用することが重要です。たとえば、乗算のコール・テンプレートは、「{1}を乗算した{0}」です。
パラメータ: 関数のロジックで使用される名前付きパラメータ。この数値は、コール・テンプレートにある引数の数と一致する必要があります。たとえば、multiplyには、a, type Double; b, type Doubleのようなパラメータがあります。
ルールで関数パラメータを使用する場合、パラメータの型制約を選択できます。これは必須要件ではありませんが、ルールの定式化に役立ちます。型制約の作成と使用の詳細は、第13.19項「型制約について」を参照してください。
ロジック: 関数のJavaコード。multiplyのコードは次のとおりです。
return a * b;
この項には次のトピックが含まれます:
インライン・サービスを構成する際、Oracle RTDの選択肢イベント履歴表に格納されているデータにアクセスするための事前定義済関数を使用できます。これらの関数は、選択肢適格性ルールの作成や編集でアクセスできますし、カスタムJavaロジックからもコールできます。
選択肢適格性ルール文でこれらの関数にアクセスするには、「関数コール」を選択して「関数」フォルダを開きます。使用可能な関数のリストに、次の関数が表示されます。
| 関数名 | パラメータ | 説明 |
|---|---|---|
|
最後のイベントからの日数 |
イベント名 |
特定の選択肢や指定されたイベント名に対して、最後にイベントが記録されてからの経過日数を返します。 |
|
チャネルでの最後のイベントからの日数 |
イベント名 チャネル |
特定の選択肢、指定されたイベント名および指定されたチャネル名に対して、最後にイベントが記録されてからの経過日数を返します。 |
|
最近のイベント数 |
イベント名 日数 |
特定の選択肢、指定されたイベント名および指定された日数に対して、イベント記録の合計回数を返します。 |
|
チャネルでの最近のイベント数 |
イベント名 チャネル 日数 |
特定の選択肢、指定されたイベント名、指定されたチャネルおよび指定された日数に対して、イベント記録の合計回数を返します。 |
メンテナンス操作はインライン・サービス固有のユーザー定義関数であり、管理者はEnterprise Managerで次のような特定のインライン・サービス関連作業を実行できます。
外部ルール・キャッシュのクリア
クラスタ内でのメッセージのブロードキャスト
ブロック操作の実行
インライン・サービス用に作成されたメンテナンス操作は、Oracle RTDによってMBean操作として公開されます。
メンテナンス操作は、クラスタの個々のメンバーでもクラスタ全体でも起動できます。メンテナンス操作は非ブロック型です。
|
注意: メンテナンス操作は、クラスタの個々のメンバーでブロック操作として直接起動できます。リクエストをブロードキャストしてクラスタ全体でメンテナンス操作を起動する場合、メッセージ配信中のみブロックされます。 |
各メンテナンス操作は、ロード可能なインライン・サービスごとに、MBeanツリーに2回表示されます。
ローカル・サーバーでのみメンテナンス操作を起動できるようにするため
クラスタのすべてのノードでメンテナンス操作を起動できるようにするため
特定のインライン・サービスでバージョンが異なる場合、メンテナンス操作が異なる場合があります。たとえば、あるインライン・サービスの複数のバージョンをデプロイできますが、それぞれのデプロイ状態が異なる場合があります。このときメンテナンス操作を使用できるのは、ロード可能な状態のインライン・サービスのみです。
メンテナンス操作に関して、次の内容をデザインタイムに考慮する必要があります。
メンテナンス操作は、プリミティブ型の引数(String、int、double、date、またはboolean)を0個以上受け取り、String、int、double、date、booleanまたはvoidを返すことができます。
戻り値(および例外)はログに記録されます。
メンテナンス操作は、グローバルなインライン・サービスのコンテキスト内で動作します。セッション属性はnullです。セッションにアクセスすると、IllegalStateExceptionがスローされます。
外部ルール・キャッシュのメンテナンス操作
Oracle RTDには、外部ルール・キャッシュのためのメンテナンス操作が用意されています。詳細は、第17.2.6.2項「外部ルール・キャッシュ」を参照してください。
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。デシジョン・センターの表示ラベルを変更して、その要素をデシジョン・センターNavigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
関数は、コール・テンプレートを使用して、他の要素からコールされます。たとえば、前項で説明したmultiply関数を使用する場合、関数を「値の編集」ダイアログから選択します。コール・テンプレート{0} multiplied by {1}を使用すると、引数の位置と数がエディタに与えられます。
型がInteger、Double、DateまたはStringであるセッションおよびエンティティの属性、選択肢および選択肢グループの属性、および関数およびアプリケーションのパラメータに関連付けることができる制約が、型制約によって定義されます。
型制約は、通常、ルール・エディタでユーザー入力を簡素化する目的で使用します。型が制約された要素を使用するルールをルール・エディタで定義するとき、関連付けられた型制約で定義されている制約に応じた値リストを表示し、そこから値を選択できます。型制約は、インライン・サービスの設計者を支援する機能です。実行時には評価されません。
型制約には、次の3種類があります。
値リスト
エンティティのリスト
他の制約
「値リスト」型制約は、1つ以上の値を持つリストで表示されます。
「エンティティのリスト」型制約は、関数から返されるエンティティ属性値で構成されます。「エンティティのリスト」型制約を使用して、データベースの表とビューから動的な値リストを生成できます。
「他の制約」型制約は、値(データ型がDate、DoubleまたはInteger)の範囲またはJavaScript正規表現パターンで構成されます。
JavaScript正規表現パターンは一般的に、郵便番号や電話番号のように、データの各文字が、コード内の位置に応じて現実の世界における規則に従っているデータに使用されます。たとえば、米国の電話番号(例: (650) 506 7000)や英国の郵便番号(例: KT2 6JX)があります。
型制約は、サービス・メタデータ・オブジェクトとして個々に作成と編集を行います。型制約は、次のインライン・サービス・オブジェクトに、対応オブジェクト・エディタで関連付けることができます。
セッション属性およびエンティティ属性
選択肢グループ属性
選択肢属性
関数パラメータ
アプリケーション・パラメータ
ルール・エディタでオペランドとして型制約オブジェクトをルールに追加する場合、ルールの作成や編集で次の支援機能を使用できます。
「値リスト」または「エンティティのリスト」の型制約のオブジェクトの場合、型制約に従ったドロップダウン・リストでオブジェクトの値を表示したり選択できます。
「他の制約」型制約のオブジェクトの場合、マウス(カーソル)をオブジェクトの上に移動することで、型制約の範囲の制約またはJavaScript正規表現を参照できます。
この項の以降の内容は次のとおりです。
「値リスト」型制約の場合、データ型を選択し、個々の要素に1つ以上の値を指定する必要があります。選択する値の数は、500個未満にすることをお薦めします。
「値リスト」型制約を定義できるのは、String、Integer、DoubleまたはDateのデータです。
「エンティティのリスト」型制約を定義するには、まず特定の前提条件を満たす必要があります。
特定のエンティティ・タイプのデータを返す関数が定義されている必要があります(関数が返す値の数は500個未満にすることをお薦めします)。
参照されるエンティティ・タイプには、列が2列以上存在する必要があります。これらは、型制約のラベルおよび値として使用されます。
ラベルの列と値の列は、ルール・エディタでルール文を編集したり、型制約を関連付けた属性またはパラメータを選択する際に使用します。
ラベルの列には、ドロップダウン・リストのデータが格納されます。ドロップダウン・リストから選択すると、値の列にある対応データがルールに追加されます。
たとえば、米国の州コードに対する型制約を使用すると、アラバマやカリフォルニアなどの米国の州名のドロップダウン・リストからルール作成者は州名を選択できます。ここでは州名の列がラベルの列として使用されます。
ルール作成者がドロップダウン・リストから州名を選択すると、Oracle RTDによって、ALやCAなどの対応する州コードがルールに追加されます。ここでは州コードの列が値の列として使用されます。
「エンティティのリスト」型制約は、次の特性によって定義されます。
エンティティ: 型制約の定義対象のエンティティ。
関数: 制約されたデータを返す関数。この関数の戻り値のデータ型として、型制約エンティティを指定する必要があります。
ラベル: 型制約エンティティの属性であり、この型制約を使用してオブジェクトを参照するルールを作成する際、ドロップダウン・リストの値はこの属性に保持されます。
値: 型制約エンティティの属性であり、ユーザーがルール・エディタでドロップダウン・リストからラベル値を選択した際にルールに追加される値がこの属性に保持されます。
「エンティティのリスト」型制約を定義できるのは、String、Integer、DoubleまたはDateのデータです。
|
注意: 「エンティティのリスト」型制約を作成したり編集した後で、インライン・サービスをデプロイする必要があります。これによって、型が制約された属性またはパラメータを使用するルールを作成する際に、正しい値がドロップダウン・リストに表示できるようになります。 |
「他の制約」により、範囲の制約またはJavaScript正規表現パターンを定義できます。また、両方を組み合せて定義することもできます。
範囲の制約を定義できるのは、Integer、DoubleまたはDateのデータです。下限値と上限値、および上下限値が含まれるかどうかを指定できます。たとえば、下限値は、「より大きい」条件の場合は含まれませんが、「以上」条件の場合は含まれます。
JavaScript正規表現パターンでは、{、}、[、]、$、?、\などの標準の正規表現パターン文字を使用して、データ形式やパターンを定義できます。JavaScript正規表現パターンを指定できるのは、String、Integer、DoubleまたはDateのデータです。
たとえば、カナダの郵便番号(L5J 2V4やV6Z 1M5など)を考えます。このデータ値を正しい形式に制約するJavaScript正規表現パターンは、[A-Z]\d[A-Z] \d[A-Z]\dです。
Integer、DoubleまたはDateのデータの場合、範囲の制約とJavaScript正規表現パターンをどちらも定義できます。型制約が使用されている場合、2つの条件は論理積演算子で結合されます。
作成した型制約は、次に示す1つ以上のインライン・サービス・オブジェクトに関連付けることができます(対応するオブジェクト・エディタを使用)。
セッション属性およびエンティティ属性
選択肢グループ属性
選択肢属性
関数パラメータ
アプリケーション・パラメータ
対応するオブジェクト・エディタの使用方法の詳細は、このドキュメントの対応するオブジェクトに関する項を参照してください。
型制約をオブジェクトに関連付けると、ビジネス・ユーザーがルール・エディタでそのオブジェクトのルールを定式化する際に役に立ちます。
ルールを作成または編集する際、次のオプションを選択できます。
「値リスト」または「エンティティのリスト」のどちらかの型制約が関連付けられたオブジェクトをオペランドとして選択すると、もう一方のルール・オペランドではドロップダウン・リストから値を選択できます。このドロップダウン・リストから値を選択できますが、値の選択は必須ではありません。
「他の制約」型制約のオブジェクトをオペランドとして選択してから、マウスをその上に移動すると、型制約の範囲の制約またはJavaScript正規表現がバルーン・ヘルプに表示されます。
|
注意: 型制約は、ルールの作成や編集を支援する機能であり、厳格な要件ではありません。たとえば、型制約のある要素のルールに、ドロップダウン・リストに表示されていない値を入力できます。実行時には、ルールは評価され、それに応じて動作しますが、型制約は評価されません。 |
一般的に次が成立します。
「値リスト」型制約によって定数リストが提示されます。
「エンティティのリスト」型制約によって動的な実行時リストが提示されます。
「他の制約」により、リスト・エントリに対するチェック以外の型検証を設計できます。
型制約に対する違反は、次に示すように、エラーではなく警告として処理されます。
違反しているオペランドは、赤色の波型下線で示されます。
違反しているオペランドの上にマウスを移動すると、違反の詳細を参照できます。
警告があっても、ルールをコンパイルしてデプロイすることは可能です。
この項では、様々な型制約を作成して使用する方法の例を示します。
「値リスト」型制約
Product_Sizeという名前で、Large、Medium、Smallを値とする型制約を作成します。
Product_Size型制約をsession/Product属性に関連付けます。
次に示すように、ルール・エディタでフィルタリング・ルールのLarge_Productを作成します。
session/Product = "Large"
「エンティティのリスト」型制約
New_Provinceエンティティを作成し、String型属性としてCodeおよびFullnameを追加します。
New_Provinceデータ型の値を返すFn_New_Provinces関数を次に示すロジックで作成します。
SDProvinceArray provinces = new SDProvinceArray();
Province nb = new Province();
nb.setCode("NB");
nb.setFullname("New Brunswick");
provinces.add(nb);
Province nf = new Province();
nf.setCode("NF");
nf.setFullname("Newfoundland");
provinces.add(nf);
return provinces;
String型制約のProvince_Restrictionを次に示す特性で作成します。
Entity= New_Province
Function=Fn_New_Provinces
Label=Fullname
Value=Code
インライン・サービスをデプロイします。これによって、その後に表示されるドロップダウン・リストに正しい値がルール・エディタで表示できるようになります。
Province_Restrictionをエンティティ属性のsession/Address/Provinceの型制約として関連付けます。
次に示すように、ルール・エディタでフィルタリング・ルールのNFを作成します。
session/Address/Province = "NF"
「Province」ドロップダウン・リスト値として、Fullnameの値が表示されます。選択される値はCodeであり、その値がルールに追加されます。
「エンティティのリスト」型制約による動的な値の表示
この例では、型が制約されたオブジェクトをルールで使用する際に、データベース表の値を表示したり選択できます。
Look Upエンティティを作成し、String型属性としてStatecodeおよびStatenameを追加します。
States表に基づいて、Abbr列とFullname列を持つStates DSデータ・ソースを作成します。
US States Look Upエンティティを次に示す特性で作成します。
Look Up型のlookUp配列属性
States DS/AbbrにマッピングされたlookUp/Statecode属性
The attribute lookUp/Statename mapped to States DS/AbbrFullname
Look Upデータ型の値を返すLook Up States関数を次に示すロジックで作成します。
return new UsStatesLookUp().getLookUp();
String型制約のStates Inputを次に示す特性で作成します。
Entity= Look Up
Function=Look Up States
Label=Statename
Value=Statecode
インライン・サービスをデプロイします。これによって、その後に表示されるドロップダウン・リストに正しい値がルール・エディタで表示できるようになります。
States Inputをエンティティ属性のsession/Address/Stateの型制約として関連付けます。
次に示すように、ルール・エディタでフィルタリング・ルールのNDを作成します。
session/Address/State = "ND"
「State」ドロップダウン・リスト値として、Statenameの値が表示されます。North Dakotaを選択すると、対応するStatecodeのND値がルールに追加されます。
範囲を使用するその他の型制約
Date型制約をFrom_Now_Onの名前で作成し、下限値として現在日を指定します。
From_Now_On型制約をsession/Acct/Pay_By属性に関連付けます。
次に示すように、ルール・エディタでフィルタリング・ルールのPayUpを作成します。
session/Acct/Pay_By = <current_date> + 45 days
JavaScript正規表現パターンを使用するその他の型制約
Morning Rush Hourという名前のDate型制約を作成し、次のJavaScript正規表現パターンにより、値を午前8:00から午前9:59の範囲に制約します。
^(?=\d)(?:(?:(?:(?:(?:0?[13578]|1[02])(\/|-|\.)31)\1|(?:(?:0?[1,3-9]|1[0-2])(\/|-|\.)(?:29|30)\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})|(?:0?2(\/|-|\.)29\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))|(?:(?:0?[1-9])|(?:1[0-2]))(\/|-|\.)(?:0?[1-9]|1\d|2[0-8])\4(?:(?:1[6-9]|[2-9]\d)?\d{2}))($|\ (?=\d)))?(((0?[8-9])(:[0-5]\d){0,2}(\ AM))|(0?[8-9])(:[0-5]\d){1,2})?$
Morning Rush Hour型制約をsession/Traffic/Morning Rush Hour属性に関連付けます。
次に示すように、ルール・エディタでフィルタリング・ルールのMid_MRHを作成します。
session/Traffic/Morning Rush Hour = <current_date> 9:00 AM
統計コレクタは、インライン・サービスの非定型統計の収集とライフサイクルを管理します。デフォルトでは、インライン・サービスごとに、選択肢イベントの統計コレクタが1つずつ作成されます。選択肢イベントの統計コレクタは、インライン・サービスで定義されているイベントの統計を自動的に収集します。統計コレクタのプロパティは次のとおりです。
説明: 統計コレクタの説明。
統計の収集場所: 統計は、選択肢や選択肢グループなどのオブジェクトごとに個別に収集することも、同じタイプのすべてのオブジェクトに集計して収集することもできます。
集計: 個々のイベントを記録するか、または集計されたデータを記録します。個々のイベントを記録する場合は、トランザクションの多いシステムにパフォーマンス上の問題が発生する場合があるため、注意が必要です。
集計間隔: 統計コレクタによりデータを記録する前の集計に要する時間(単位は秒)。
有効期限: 「永久に保存」または「古い統計のパージ」を選択します。「永久に保存」を選択する場合は、データのサイズが問題になる場合があるため、注意が必要です。
データベースに保持: データを消去するまでの時間(日)。
パラメータはすべて、デシジョン・スタジオ・エディタを使用して構成できます。選択肢イベントの統計は、レポートとしてデシジョン・センターに表示されます。
デシジョン・スタジオを使用して、オブジェクトまたはクラスに関する追加の統計を記録するカスタム統計コレクタを作成できます。たとえば、選択肢に関する統計を記録する統計コレクタを作成できます。パラメータは、前項の説明に従って構成します。
インライン・サービスのコードで(たとえば、インフォーマントまたは関数コール経由で)、統計コレクタのファクトリを作成し、統計コレクタ名(String)または統計タイプ(String)を渡します。
StatisticCollectorFactory factory = Application.getCollectorFactory(<stat collector name | statistic type>);
このファクトリを使用して、コレクタを作成し、統計を収集するイベント名(String)または統計名(String)を渡します。
StatCollectorInterface collector = factory.getCollector(<event name | statistic name> );
イベント名または統計名は、収集対象を表す任意の文字列です。
最後に、コレクタを使用して、object_type (String)、object_id (String)、イベント値(double)および追加データ(string)を渡してイベントを記録します。
Collector.recordEvent(<object_type>, <object_id>, event value, extra data);
object_typeには、選択肢、選択肢グループ、エンティティなど、有効なオブジェクト・タイプを指定する必要があります。object_idは、オブジェクトの内部名です。
