| Oracle Real-Time Decisionsプラットフォーム開発者ガイド リリース3.0 B54059-01 |
|
 戻る |
 次へ |
Decision Studioの要素はDecision Studio内で構成され、ロジックがJavaスクリプトレットの形式で追加されます。この章では、各要素のプロパティおよび要素に含まれるJavaスクリプトレット（存在する場合）について、例とともに説明します。
この章の内容は次のとおりです。
Oracle RTDの意思決定プロセスは、組織に関連する全体的パフォーマンス目標、その目標を測定するパフォーマンス・メトリック、各選択肢のスコアリングに必要なアクション、および母集団のセグメントに基づくそのスコアの重み付けをそれぞれ考慮したフレームワークをベースとしています。
このフレームワークには、次のような要素があります。
パフォーマンス目標
意思決定
選択肢グループおよび選択肢
フィルタリング・ルール
スコアリング・ルール
予測モデル
これらの要素が通常のOracle RTD意思決定プロセスに取り込まれ、インライン・サービスの基礎を形成する様子を次の図に示します。
各入力の拡張機能により外部アプリケーションとOracle RTDで複合的なデシジョン・サービスをエンド・ユーザーに提供できる仕組みの詳細は、第16章「外部化されたオブジェクト管理」を参照してください。
要素を作成する際、その要素の表示ラベルを入力します。表示ラベルを入力すると、オブジェクトIDが自動的に生成されます。
オブジェクトIDはJava命名規約に準拠するように自動的に作成されます。変数名は大文字と小文字が混在し、最初の文字は小文字になります。クラス名は大文字と小文字が混在し、最初の文字は大文字になります。ラベル名に空白が含まれる場合は、オブジェクトIDの生成時に空白が削除されます。オブジェクトIDを手動で入力すると、自動的に作成されたオブジェクトIDを上書きできます。
「Inline Service Explorer」のタスク・バーにある「Toggle」アイコンを使用すると、オブジェクトの表示ラベルとそのオブジェクトIDとの間で表示の切替えができます。
|
注意: 新しいオブジェクトを作成する際、オブジェクト名が既存のオブジェクトで使用されていると、競合を防止するためにDecision Studioによって自動的にオブジェクトIDに番号が割り当てられます（1、2など）。 |
Decision Studioで新しいプロジェクトを開始すると、「Service Metadata」フォルダにアプリケーション・オブジェクトが作成されます。アプリケーション・オブジェクトのプロパティでは、次の特性が定義されます。
アプリケーション・パラメータ
制御グループ
モデルのデフォルト値
ロジック
権限
これらすべての値は、Decision Studioインタフェースを使用して定義されます。
この項の内容は次のとおりです。
この項では、アプリケーション・パラメータについて説明します。この項の内容は次のとおりです。
本番データベースに対してデプロイされているインライン・サービスをテストする場合、モデル・データを混在させないようにするには、デバッグ・オプションを使用してデータが書き込まれないようにします。デバッグ・オプションは次のとおりです。
Disable learning: モデルの現在の状態を維持して、テストにより追加的な学習が導入されないようにします。
Disable database writes: データがデータベースに書き込まれないようにします。
パラメータには、名前、データ型、デフォルト値があり、配列にすることもできます。
アプリケーション・パラメータは、すべてのセッションについて定義および保存できるグローバルレベルのパラメータです。
「Application Parameter」タブで「Add」をクリックしてパラメータを追加します。パラメータを追加する際、「Name」、「Type」、「Array」および「Default Value」を入力します。
ルールでアプリケーション・パラメータを使用する場合、パラメータの型制約を選択できます。これは必須要件ではありませんが、ルールの定式化に役立ちます。型制約の作成と使用の詳細は、第12.18項「型制約について」を参照してください。
「Remove」をクリックすると、パラメータは削除されます。
次のコードはそれぞれ、オブジェクトのラベルと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の導入前に抱合せ販売がランダムに行われていた場合、制御グループのデシジョンではランダムなデシジョンが反映されるようにする必要もあります。
表12-1 制御グループのオプション
| オプション名 | 説明 |
|---|---|
|
No Control Group |
これを選択すると、制御グループは使用されず、「Selection Value」が0に設定され、「Use value literally」が選択されて無効になります。制御グループを有効にして設定を変更するには、「No Control Group」を選択解除します。 |
|
Selection Value |
属性値への参照。この値を使用して、リクエストのランダムな選択を制御グループに生成します。 |
|
Use value literally |
「Use value literally」を選択解除する場合、制御グループの選択値は、セッション・キーまたは顧客を一意に識別する属性を参照する必要があります。制御グループの参加は、選択値の疑似乱数ハッシュを使用して決定されます。計算の結果は決定論的であり、制御グループの選択値と指定されたサイズにのみ依存します。制御グループの実際のサイズは、指定されたサイズと微妙に異なります。 「Use value literally」を選択すると、選択値により制御グループの参加が直接決定されます。この場合の選択値には、ブール（制御グループの参加をtrue値で示す）または整数（制御グループの参加を0以外の値で示す）を指定できます。 たとえば、顧客の制御グループへの割当てをOracle RTD以外で行う場合に「Use value literally」を選択します。制御グループの選択値として使用する属性は、この割当てを示す必要があります。 |
|
Percent of Population |
「Use value literally」がFalseに設定されている場合にのみ、このオプションはアクティブになります。その場合、制御グループに割り当てる必要があるセッションの総数に対するパーセンテージをユーザーは決定します。 |
|
Use for analysis |
制御グループの参加を解析モデルにより追跡するかどうかを制御します。 |
|
Name for Analysis |
解析モデルが制御グループの参加の追跡に使用する名前。 |
モデルのデフォルト値は、使用するモデルおよびモデルの設定方法を制御します。ほとんどのモデルのデフォルト値は、Oracleサポート・サービスによる指示のないかぎり変更しないでください。
表12-2 モデルのデフォルト値
| オプション名 | 説明 |
|---|---|
|
Study name |
インライン・サービスで使用するスタディの名前。通常は、インライン・サービスごとに個別のスタディを持ちます。これは、スタディ名をインライン・サービス名と同じにすると実現できます。ただし、既存のスタディはインライン・サービスのテスト時に使用されることがあります。そのような場合は、学習を無効にして本番データが失われないようにする必要があります。 |
|
Persistence Interval |
モデル・データをデータベースに保存する時間間隔。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。 |
|
Time Window Duration |
デフォルト値は「Quarter」です。 |
|
First Day of Week |
デフォルト値はロケールにより異なります。米国では、デフォルト値は「Sunday」です。 |
|
First Month of Year |
デフォルト値は「January」です。 |
|
Build when data changes by |
新しい予測モデルを構築する新規レコードのパーセンテージ。デフォルト値は「20%」です。 たとえば10%に設定した場合、前回予測モデルが構築されたのが13400レコードに達した時点であったと仮定すると、次回予測モデルが構築されるのは1340レコードに達した時点になります。 |
|
Significance threshold |
デフォルト値は「25」です。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。 |
|
Correlation threshold |
デフォルト値は「0」です。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。 |
|
Max Input Cardinality |
個々の属性で追跡される値の最大数。デフォルト値は「500」です。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。 |
|
Max Input Buckets |
数値属性の入力バケットの最大数。デフォルト値は「200」です。値が「100」でも十分有効な場合があります。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。 |
アプリケーション要素の「Logic」タブにある「Initialization Logic」および「Cleanup Logic」パネルを使用して、インライン・サービスを初期化およびクリーンアップするスクリプトレットがDecision Studioを介して追加されます。
これらのスクリプトレットは、ApplicationクラスのinitおよびcleanUpメソッドに挿入されます。initメソッドは、インライン・サービスがロードされるときにコールされます。cleanUpメソッドは、インライン・サービスがアンロードされるときにコールされます。アプリケーションが再デプロイされると、initが再度コールされます。
ライフサイクル中のインライン・サービスの操作をユーザーに許可するロールに対して、インライン・サービス権限を設定します。各インライン・サービスでは表12-3に示す権限を使用できます。これらの権限は、インライン・サービスの開発者およびDecision Centerのビジネス・ユーザーに適しています。
表12-3 インライン・サービス権限
| 権限名 | 説明 |
|---|---|
|
Open Service for Reading |
Decision Centerでインライン・サービスを読取り専用モードで開くことを許可します。このモードは、Decision Centerを使用してレポートを表示するビジネス・ユーザーに適しています。 |
|
Open Service |
Decision Centerユーザーがインライン・サービスを編集してReal-Time Decision Serverに再デプロイすることを許可します。 |
|
Deploy Service from Studio |
Decision Studioユーザーがインライン・サービスをデプロイすることを許可します。既存のインライン・サービスを再デプロイするには、既存のサービスおよび新しいサービスの両方に対するデプロイ権限を持つロールがユーザーに割り当てられている必要があります。このモードは、Decision Studioを使用してインライン・サービスをデプロイするインライン・サービスの開発者に適しています。 |
|
Download Service |
Decision Studioユーザーが、サーバーから既存のデプロイ済インライン・サービスをダウンロードすることを許可します。このモードは、Decision Studioを使用してインライン・サービスをデプロイするインライン・サービスの開発者に適しています。 |
インライン・サービス権限は、サーバー側のクラスタ権限と連携して、権限のないユーザーによってインライン・サービスが変更または再デプロイされないように保護します。クラスタ権限の設定の詳細は、『Oracle Real-Time Decisionsインストレーションおよび管理ガイド』を参照してください。さらに、Decision Centerのパースペクティブでも権限を設定できます。詳細は、第12.20項「Decision Centerのパースペクティブについて」を参照してください。
アプリケーション要素の「Permissions」タブを使用して、インライン・サービス権限を設定します。「Add」を使用して、ロールをインライン・サービスに追加します。サーバーからロールを取得するには、「Get Names」をクリックします。
ロールはリストから選択することも、「Role」フィールドに名前を入力することもできます。ロールを追加したら、「Permissions」リストの「Granted」フィールドで適用対象権限を選択します。
インライン・サービスからロールを削除するには、ロールを選択して「Remove」をクリックします。
|
注意: Windows認証が有効な場合、「Get Names」をクリックしてもロールのリストを取得できません。かわりに、権限の割当て先となるロールの名前を「Role」フィールドに入力する必要があります。 |
インライン・サービス内のデータにアクセスするには、エンティティ、データソース、およびセッション要素を使用します。
エンティティは、複数のソースからのデータをまとめて、インライン・サービス全体で使用されるオブジェクトを形成する抽象的な方法を提供します。エンティティは、そのコンテンツを記述する多数の属性で構成されます。また、エンティティは属性にアクセスするメソッドも備えています。
Customerなどのエンティティは、様々なソースから着信するデータを組み合せます（IVRを介して入力されたアカウント番号や企業データベースから取得した顧客履歴など）。エンティティの属性にはキー（一意の識別子）もあります。着信したデータは、エンティティの適切な属性にマップされます。セッションの存続期間中に、インライン・サービスにコーディングされている追加ロジックによってエンティティ属性を移入できます。
データソースは、データのサプライヤとして機能します。これは、リレーショナル・データベース・テーブルおよびストアド・プロシージャへの接続を管理する方法を提供します。データソースは、データベース・テーブルの列、またはストアド・プロシージャからの結果セットを属性として識別します。これらの属性は、エンティティ属性にマップされます。
セッション・オブジェクトは、インライン・サービスに対してメモリー内の使用可能な属性を識別する特別なエンティティです。これらの属性は、前述のCustomerなどのエンティティと、計算などの他のソースで設定された属性で構成できます。セッション・オブジェクトを使用して、ユーザー・セッションの情報を保存します。セッションに保存された属性はインライン・サービス全体で使用でき、セッションを閉じたときに破棄されます。セッションに関連付けられている属性は、特定のモデルで明示的に除外されている場合や、解析対象から完全に除外されている場合を除いて、デフォルトでOracle RTD学習モデルの入力として使用されます。
データにアクセスするには、通常、次の手順を実行します。
SQLテーブルまたはストアド・プロシージャに基づいてデータソースを作成します。
1つ以上のデータソースからの属性を持つエンティティを作成します。
キー値をエンティティに追加します。
エンティティを属性としてセッションに追加し、セッション・キーを割り当てます。
エンティティ属性をデータソース列または出力値にマップします。
エンティティ・キーをセッション・キーまたは関数にマップします。
この項の内容は次のとおりです。
データはインライン・サービス内でデータソース要素およびエンティティ要素を使用してアクセスします。データソースはデータの抽象プロバイダです。データソースは、インライン・サービスに対するデータのサプライヤとして機能します。
データソースは、Decision Studio内ですべて構成されます。データソースには、SQLデータソースとストアド・プロシージャ・データソースの2種類があります。
この項では、SQLデータソースを作成する方法について説明します。この項の内容は次のとおりです。
表12-4はSQLデータソースのプロパティを示します。
表12-4 SQLデータソースのプロパティ
| データソースのプロパティ名 | 説明 |
|---|---|
|
Description |
データソースの説明。 |
|
JDBC Data Source |
JDBCデータソースのJNDI名。新しいデータソースの作成方法の詳細は、『Oracle Real-Time Decisionsインストレーションおよび管理ガイド』を参照してください。 |
|
Table Name |
テーブルの名前。データベースで大文字と小文字が区別される場合であっても、この名前の大文字と小文字は常に区別されません。 |
|
Output Column Name |
データソースから選択する列。 |
|
Output Type |
出力列のデータ型。 |
|
Input Column Name |
データソースに対するクエリーのWHERE句に使用する列。これは、データソースからデータを選択する際に一致させる列です。 |
|
Input Type |
入力列のデータ型。 |
|
Allow multiple rows |
複数行が返されることを許可します。このオプションを選択しない場合に複数行が返されると、最初の1行のみが使用されます。 |
|
Advanced |
「Advanced」ボタンを使用すると、Decision Centerに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。 |
「Add」または「Remove」をクリックすると、データソースに列を追加または削除できます。複数の行が想定される場合、「Allow Multiple Rows」を選択します。このオプションを選択しない場合に複数行が返されると、最初の1行のみが使用されます。
「Import」をクリックして、データソースに直接接続します。指定されたデータソースのすべてのデータベース・テーブルが表示されます。データソースが指定されない場合は、デフォルトのデータソースSDDSが使用されます。
「Include objects from all schemas」を選択すると、データソース・スキーマに定義されていないテーブルが表示されます。すべてのアクセス可能なスキーマからのテーブルが表示されます。表スキーマは個別の列に表示されます。
インポートするテーブルを選択すると、それらの列の列名とデータ型がインポートされます。不要な列がある場合、「Remove」をクリックしてそれらを削除します。
「Input column」は、セッションに必要な行を取得するために、データベース・テーブルに対して一致させる列です。ほとんどの場合、これは単一レコードを返すための主キーまたは一意の索引列の値になります。大きな結果セットが必要な場合は、一意でない索引列にすることもできます。「Add」をクリックして、一致させる属性を選択します。
この項では、ストアド・プロシージャ・データソースを作成する方法について説明します。この項の内容は次のとおりです。
表12-5はストアド・プロシージャ・データソースのプロパティを示します。
表12-5 ストアド・プロシージャ・データソースのプロパティ
| データソースのプロパティ名 | 説明 |
|---|---|
|
Description |
データソースの説明。 |
|
JDBC Data Source |
JDBCデータソースのJNDI名。 |
|
Procedure Name |
ストアド・プロシージャの名前。データベースで大文字と小文字が区別される場合であっても、この名前の大文字と小文字は常に区別されません。 |
|
Inputs and Outputs |
ストアド・プロシージャの入出力パラメータ。各入出力パラメータには、Name、Type、およびDirectionがあります。 |
|
Result Sets |
ストアド・プロシージャからの結果セット。 |
|
Allow multiple rows |
複数行が返されることを許可します。このオプションを選択しない場合に複数行が返されると、最初の1行のみが使用されます。 |
|
Result Set Details |
列名と予想される結果の型。 |
|
Advanced |
「Advanced」ボタンを使用すると、Decision Centerに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。 |
「Import」をクリックして、データソースに直接接続します。指定されたデータソースのすべてのストアド・プロシージャが表示されます。データソースが指定されない場合は、デフォルトのデータソースSDDSが使用されます。
「Include objects from all schemas」を選択すると、すべてのデータソース・スキーマのストアド・プロシージャが表示されます。
インポートするストアド・プロシージャを選択すると、そのパラメータの名前とデータ型がインポートされ、データソースの属性になります。そして、「Finish」をクリックします。不要なパラメータがある場合、「Remove」をクリックしてそれらを削除します。
「Add」または「Remove」をクリックすると、データソースに属性を追加または削除できます。属性が「Input」、「Output」、または「Input/Output」かを選択します。
属性は順に並べる必要があります。「Up」または「Down」を使用して属性の順番を変更します。
ストアド・プロシージャに1つ以上の結果セットがある場合、各結果セットに対して次の手順を実行します。
「Result Sets」の「Add」ボタンをクリックして、結果セットをデータソースに追加します。
「Result Set Detail」の「Add」ボタンを使用すると、結果セットの列名および型を追加できます。
列名とデータ型を手動で入力して、次に示すようにストアド・プロシージャの結果セットの列に一致させる必要があります。
データソースの列名は、結果セットの列名と正確に一致している必要があります。
データソースのデータ型は、結果セットの対応データ型で有効である必要があります。
たとえば、結果セットの列がVARCHARまたはVARCHAR2の場合、データソースの対応する列のデータ型としてStringを入力します。SQL ServerまたはOracleのストアド・プロシージャの列がFLOATの場合や、DB2のストアド・プロシージャの列がREALの場合、データソースの対応する列のデータ型としてDoubleを入力します。
付録B「ストアド・プロシージャからのデータ・ソースの例」では、Oracle、SQL ServerおよびDB2の各データベースからデータソースを設定し、データソースから属性を導出するエンティティを作成する例について説明しています。
Oracle Siebel Analytics Serverでは、OLTPおよびOLAPデータベースに格納されたデータにアクセスするために、ODBCクライアント・インタフェースを公開しています。RTD Decision Serviceは、Java Runtime Environment（JRE）に含まれるJDBC-ODBCブリッジを使用して、Siebel Analytics Serverで提供されるODBCドライバに接続します。
RTD Decision Serviceから見ると、Siebel Analytics Serverは通常のデータベースと同様のSQLデータソースです。Siebel Analytics Serverのサブジェクト領域は、インライン・サービスによってデータベース・テーブルとして処理されます。列名は、プレゼンテーション・オブジェクト階層の2つのレベルを組み合せたものです。
Decision Studioデータソースでアクセス可能なJDBCデータソースの追加方法の詳細は、『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オブジェクトにアクセスします。
統合点の処理により、後で呼び出される統合点で使用できるように、セッションの情報が明示的または暗示的に保存されます。
エンティティは、Decision Studioを使用して定義します。エンティティ名は、大文字で開始する必要があります。エンティティでは、次の特性が定義されます。
Description: Decision Studioに入力されたエンティティの説明。
Key: エンティティの一意のID。「Add Key」をクリックすると、キーがエンティティに追加されます。
エンティティ属性にはプロパティもあります。属性のプロパティを表12-6に示します。
表12-6 エンティティ属性のプロパティ
| エンティティ属性のプロパティ名 | 説明 |
|---|---|
|
Description |
Decision Studioに入力された属性の説明。 |
|
Type |
属性タイプは、基本型、Javaクラス、エンティティ・タイプ、選択肢または選択肢グループのいずれかです。 |
|
Array |
単一値かコレクションかどうか。 |
|
Type Restriction |
ルールでエンティティ属性を使用する場合、属性の型制約を選択できます。これは必須要件ではありませんが、ルールの定式化に役立ちます。型制約の作成と使用の詳細は、第12.18項「型制約について」を参照してください。 |
|
デフォルト値 |
デフォルト値。定数、関数、または属性への参照を指定できます。 |
|
Use for analysis |
このオプションを選択して、予測モデル内の解析にこの属性を使用します。 |
|
Category |
属性のカテゴリ。カテゴリは、Decision Centerでの属性の表示の編成に役立ちます。 |
|
Analysis options |
Date属性の追加の解析オプションが使用できます。解析にDateを使用するには、解析に使用するパターンを指定します。月、日、曜日、時刻の影響を個別に、または任意の組合せで解析できます。 |
「Add Attribute」または「Add Key」をクリックして、属性をエンティティに追加します。属性がコレクションの場合は、「Array」列を選択します。
|
警告: Key属性を追加する場合、データ型は自動的にStringになります。データソース列または出力パラメータのデータ型がString以外の場合は、データソースの入力の設定時に変換関数を使用します。 |
データソースのすべての出力列を自動的にエンティティ属性として追加するには、「Import」をクリックしてインポート元のデータソースを選択します。複数のデータソースからインポートする場合は、この手順を繰り返します。「Remove」をクリックすると、不要な属性を削除できます。
「Import」を使用する際、「Build data mappings for selected data source」を選択すると、属性がデータソースに自動的にマップされます。エンティティがネストされ（たとえば、1対多関係）、属性が間接的にマップされる場合は、このオプションを選択しません。
|
注意: 「Build data mappings for selected data source」によりエンティティ属性がデータ列にマップされますが、ユーザーがエンティティ・エディタの「Data Source input values」セクションで入力値を割り当てることもできます。 |
「Use for Analysis」を選択して、解析モデルに属性を追加します。
各エンティティ属性の「Use for Analysis」オプションはデフォルトでtrueに設定されており、Oracle RTDのモデルの入力として使用されます。その必要がない場合は、ユーザーがこのオプションの選択を明示的に解除できます。適切な属性を右クリックして「Properties」を選択することで、この設定にアクセスします。
「Show in Decision Center」オプションは、デフォルトで選択されます。Decision Centerユーザーに対して属性を表示しないようにする場合は、このオプションを選択解除します。必要に応じて、「Category」を選択すると、Decision Centerの属性の表示を制御できます。適切な属性を右クリックして「Properties」を選択することで、この設定にアクセスします。
使用するセッション・キー値がエンティティの属性である場合、最初にエンティティをセッションに追加します。そのためには、セッション・エンティティで「Add attribute」をクリックして、このエンティティをそのエンティティ・タイプの新しい属性としてそのセッションに追加します。
たとえば、セッション・キーをCustomerエンティティのcustomerId属性にするとします。「Add Attribute」をクリックして、属性をcustomerというセッションに追加します。この属性の型は、エンティティ・タイプ（つまり、Customer）です。
エンティティ・タイプにアクセスするには、「Type」列のドロップダウン・リストを使用して「Others」を選択します。「Type」ウィンドウが表示されます。この属性の「Entity Type」を選択します。
セッション・キーを追加するには、「Session Keys from Dependent Entities」から「Select」をクリックします。セッションの属性であるエンティティからのキー値はすべて、セッションのキー値として選択できます。ベースとなるセッションのキーを選択します。この例では、customerIdです。
|
注意: キャッシュされたエンティティのキーはセッション・キーとして使用できません。 |
「Add Attribute」をクリックして、セッション全体で使用可能にする属性を追加します。セッション属性には、他のエンティティ属性と同様にゲッターおよびセッターが生成されます。
Decision Studioを使用してエンティティを作成したら、エンティティの属性を定数、計算済、データソースの属性への参照、またはセッション・キーのいずれかの値にマップします。
構成されているデータソースへのマッピングは、エンティティ・オブジェクトの「Mapping」タブで実行します。エンティティの属性をデータソースにマップするには、「Source」列を使用して、データソース列のパスまたはデータの属性を提供する出力パラメータを選択します。
キー値をマップするには、「Data Source Input Values」から「Input Value」をクリックします。ここで、属性をデータソース値にマップすると、キー値が表示されます。キーは、セッション・キー属性、別のエンティティ・キー値、または関数にマップできます。入力タイプは、String型にする必要があります。String型でない場合は、非文字列値を変換する関数を使用します。
1対多の外部キー関係のエンティティのデータにアクセスするには、関係するエンティティを最初のエンティティの属性にします。たとえば、CustomersテーブルにキーCustomerIDがあると仮定します。Customersには多数のOrdersがあり、OrderIDと外部キーCustomerIDで識別されます。
1対多の外部キー関係のエンティティのデータにアクセスする手順を、CustomersとOrdersを例に使用して、次に示します。
|
注意: この例は、OrdersテーブルにCustomerIDが外部キーとして存在していることを前提としています。このCustomerIDはOrdersデータソースの入力列として使用されます。また、Ordersデータソースの「Allow Multiple Rows」設定がtrueに設定されています。 |
Decision Studioで、各テーブルのデータソースを定義します。
CustomersおよびOrdersのエンティティを作成します。
Customerをセッションに追加します。これは、次のデータ・レベルを取得する際のキーとなります。
セッション・キーとしてCustomerIDを選択します。
OrdersとCustomersの間の1対多関係を関連付けるには、Ordersエンティティ・タイプのOrdersという属性をCustomerに追加します。1つのCustomerに対して多数のOrdersがあるので、これを配列にします。
Customerエンティティのマッピング・タブを使用してすべての属性値をマップできます。
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「Advanced」をクリックします。
セッション要素は、セッションの初期化および終了で実行されるスクリプトレットを受け入れます。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は、キャッシュされたエンティティに対してはコールしないでください。
エンティティは、アクセスしやすいようにサーバー上にキャッシュできます。エンティティをキャッシュするには、エンティティの「Cache」タブをクリックします。
エンティティには次のキャッシュ関連オプションを持たせることができます。
Enable caching for this entity type: このオプションを選択してキャッシュを有効にします。キャッシュされたエンティティはキャッシュされていないエンティティと同様に処理され、同じAPIを持ちますが、キャッシュされたエンティティのキーをセッション・キーとして使用することはできません。
Max number of items to cache: キャッシュするアイテムの最大数。アイテムは先入れ先出し方式でフラッシュされます。
さらに、エンティティには次の「Caching strategy」関連オプションを持たせることができます。
Use fixed lifetime: リフレッシュされるまで各オブジェクトをキャッシュに維持する秒数。
Use fixed period: キャッシュ全体がリフレッシュされるまでの秒数。
Never refresh cache: キャッシュされたアイテムは、最大数に達するまでキャッシュに維持されます。
エンティティがキャッシュにマークされている場合、次のコードを使用して属性を設定します。エンティティを作成したら、キー値を設定して、キャッシュから属性値を取得します。キャッシュされたエンティティ属性（キー以外）には、セッターがありません。そのため、エンティティはキャッシュされたバージョンと常に同期します。
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());
前述の行から次のような出力がインライン・サービスの「Test」→「Log」タブに表示されます。
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デシジョンの導入によって改善対象となる具体的メトリックを検討します。一般的なパフォーマンス・メトリックには、次のようなものがあります。
Webサイトを訪問した顧客当たりの売上
コンタクト・センターにおける顧客通話当たりの処理コスト
パフォーマンス・メトリックは、最適化の方向（最大化または最小化）と正規化ファクタで構成されます。
パフォーマンス目標の特徴は次のとおりです。
Performance metric: 組織がデシジョンの成功の度合いを測定するように選択したメトリック。
Optimization: パフォーマンス・メトリックを最適化する方向を示す値。「Minimize」または「Maximize」。
Required: パフォーマンス・メトリックのスコアリングが必要な場合は選択します。メトリックが必要であるとマークされていない場合、データ不足によってスコアが使用できないと、Oracle RTDは別のスコアを調査してスコアを提供します。メトリックが必要であるとマークされている場合、全体的なスコアは提供されません。メトリックは使用不可とマークされ、スコアリング・プロセスから削除されます。
Normalization factor: このパフォーマンス・メトリックの組織の相対値。
この項の内容は次のとおりです。
「Add」をクリックして、パフォーマンス・メトリックを追加します。メトリック（例: 収益）、最適化の方向（最大化）、メトリックで意思決定を行うためのスコアを使用可能にする必要があるかどうかを追加します。
メトリックをすべて追加したら、正規化ファクタを決定する必要があります。
インライン・サービス開発者やビジネス・ユーザーが本来の測定スケールが異なるパフォーマンス目標に対するスコアリング関数を表現するには、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の範囲のときは、正規化ファクタではなくカスタム・スコアリング関数を定義することが適切である場合があります。
パフォーマンス目標の「Required」フラグは、デシジョンを処理するために実際の値が必要かどうかを示します。
このフラグが「True」に設定されていると、適格な各選択肢でこのパフォーマンス目標のスコアが必要です。
選択肢にそのような値が見つからない場合、すなわちスコアがNaNの場合、ランダム・スコアが生成されます。
このフラグが「False」に設定されていると、適格な各選択肢でこのパフォーマンス目標のスコアは必要ありません。
選択肢スコアにそのような値が見つからない場合、すなわちスコアがNaNの場合、このパフォーマンス目標はその選択肢では無視され、デシジョンで使用される他のパフォーマンス目標の重み付けにおいて、不要とマークされたパフォーマンス目標の重み付けが均等に分配され調整されます。
|
注意: 外部化されたパフォーマンス目標とその重み付けのコンテキストでは、インライン・サービス開発者が重み付けを正規化する必要があります。 |
選択肢は、デシジョン・プロセス中に評価されるオブジェクトです。デシジョン・プロセスでは、候補となる選択肢のリストから最適な選択肢が選択されます。選択肢の例は次のとおりです。
マーケティング・オファーの選択元リスト
推奨製品リスト
タスクのリソース・リスト
選択肢は、選択肢グループにまとめることができます。選択肢グループと選択肢は階層ツリーに似た構造として編成され、1つの親選択肢グループの下に複数の子選択肢グループが存在できます。候補となる選択肢のリストから選択肢を選択すること、すなわちデシジョン・プロセスは、次のロジックに従って段階的に行う操作です。
適格性: デシジョンに対して選択肢を検討する必要があるかどうかを決定するルールのセットです。適格性ルールは、選択肢グループと選択肢の階層の各レベルで定義できます。
スコアリング: デシジョンに対して定義されている各パフォーマンス目標に沿ったスコアの計算です。
正規化: 様々なパフォーマンス・メトリックに沿ってスコアを一般のスケールに移行して、スコアを比較できるようにします。
総計化: 選択肢ごとに1つの数値を生成します。この数値は、デシジョンの適用先セグメントの各パフォーマンス目標の正規化済スコアを重み付けして合計した値です。
選択: 選択肢の合計スコアに基づいて最適な選択肢の設定数を選択します。
選択肢には、静的選択肢と動的選択肢があります。
静的選択肢の場合、リクエスト元アプリケーションまたは自己学習モデルに提示される選択肢は、Oracle RTD内で完全に定義されます。静的選択肢は、選択肢が既知の場合と、一定期間にわたって一定の場合に役に立ちます。
動的選択肢は、実行時に動的に構築される選択肢です。この選択肢は通常、外部データソースに保持されます。これにより、オファー管理システムで定義したオファーに基づく選択肢など、ソース・システムで選択肢を管理できます。
|
注意: 選択肢グループは常に静的であり、Oracle RTDインライン・サービスで定義されます。 |
この項では、選択肢グループおよび静的選択肢と動的選択肢の両方に該当する一般的な特徴とプロセスについて説明します。動的選択肢固有の詳細は、第16.1項「動的選択肢」を参照してください。
この項の内容は次のとおりです。
選択肢グループと選択肢には次の特徴があります。
Attribute values: 選択肢を構成する属性。これらは、親の選択肢グループから継承されるか、選択肢レベルで割り当てられます。
Scores: 各選択肢は、「Scores」タブの定義に従ってスコアリングされます。選択肢は、デシジョンで定義されているすべてのパフォーマンス・メトリックに対してスコアリングされます。
Choice Events: 選択肢イベントは、グループ・レベルでのみ記述されます。これらのイベントによって、選択肢のライフサイクルで重要なイベントが識別されます。たとえば、実行されるCross Selling Offerには、Offered、Accepted、Product First Usedなどのイベントがあります。
Rules: 選択肢に適用可能なルールには2つのタイプがあり、Decision Centerユーザーはどちらのルールも作成や変更ができます。
適格性ルールにより、デシジョンで選択肢を検討する条件を制御します。適格性ルールは、選択肢グループ階層のどのレベルでも定義できます。選択肢は、その上位階層で定義されている適格性条件を継承します。
スコアリング・ルールを使用して、選択肢に数値スコアを関連付けることができます。これらのスコアは、パフォーマンス目標スコアリング・ロジックの一部として使用したり、選択肢の属性として使用できます。
Advanced: 「Advanced」ボタンを使用すると、Decision Centerに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。
選択肢グループ属性を使用して、グループ・レベルで属性を定義します。グループ属性は選択肢グループ・レベルにのみ適用され、個々の選択肢には割り当てられません。
選択肢属性は、グループの各選択肢が同じ属性のセットを持つように選択肢グループ・レベルで定義されます。選択肢属性の値は、選択肢レベルで個別に定義します。選択肢属性にはデフォルト値を設定できます。これは、低位レベルで設定して上書きできます。
選択肢グループおよび選択肢は階層的に定義されます。階層は、選択肢の論理分類に準拠します。最上位レベルでは、サブツリー全体で一貫性のある選択肢属性の定義を考慮する必要があります。低位レベルでは、階層の形は通常、組織の事情を考慮して決定されます。
選択肢属性は、通常、階層の高位レベルで定義します。属性の中には上書き不可とマークされているデフォルト値を持つものもあります。これは、デフォルトで設定された値が使用される値になることを示します。これは一般的に計算が含まれる場合に設定されます。これはデプロイ後、ビジネス・ユーザーに属性を更新させないようにする場合に有用です。
選択肢属性の値は次のいずれかにできます。
定数
属性または変数
関数またはルール・コール
モデル予測
図12-2に、選択肢グループの例を示します。
この例の「Offers」レベルで設定されている選択肢属性を表12-7に示します。
表12-7 「Offers」選択肢グループの例の「Offers」レベルで設定されている選択肢属性
| 属性 | 型 | 値 |
|---|---|---|
|
Message |
String |
デフォルト値なし。各選択肢の値は選択肢レベルで割り当てられます。 |
|
ShouldRespondPositively |
Boolean |
特定の選択肢に対して顧客が肯定的に反応するかどうかを示すブール値を返す |
|
likelihood |
Predictive/Double |
この選択肢グループが登録されている選択肢モデルまたは選択肢イベント・モデルによって割り当てられるプレースホルダ属性。選択肢が受け入れられる確率に使用します。実行時に計算されるため、デフォルト値はありません。 |
|
Profit Margin |
Double |
オファーの収益性のインジケータ（パーセンテージ単位）。デフォルト値は 0.5。各選択肢の値は選択肢レベルで割り当てられます。 |
各選択肢は、Profit MarginおよびMessageの値を、その選択肢を示す値で上書きします。ただし、有効な期間にサーバーが応答できない場合は、実行時にデフォルト値が使用されます。
選択肢は、ShouldRespondPositively属性を上書きしません。これは、すべてで同じ関数を使用してその値を決定するためです。likelihoodは、実行時に選択肢ごとにモデルで計算されます。
グループ・レベルには、もう1つの属性があります。それは名前がaverageLikelihood、型がPredictive/Doubleのグループ属性です。この属性は、選択肢全体のlikelihoodの平均としてモデルで使用されます。特定の選択肢のlikelihoodが使用できない場合のlikelihoodとして使用します。実行時に計算されるため、デフォルト値はありません。
選択肢属性の特徴は次のとおりです。
Name: 属性の名前。
Category: 属性が属するカテゴリ。カテゴリは、Category要素で定義されます。
Type: 属性のデータ型。
Array: 属性がコレクションであるかどうか。
Type Restriction: ルールで選択肢属性または選択肢グループ属性を使用する場合、属性の型制約を選択できます。これは必須要件ではありませんが、ルールの定式化に役立ちます。型制約の作成と使用の詳細は、第12.18項「型制約について」を参照してください。
Inherited Value: 存在する場合は、選択肢グループまたは選択肢の属性が親から継承した値。
Value: 属性の値。この値は、常に継承した値を上書きします。
Show in Decision Center: このオプションを選択すると、ビジネス・ユーザーに対して属性がDecision Centerで表示されるようになります。属性を内部的に使用する場合は、選択解除します。
Use for indexing: 指定した属性で選択肢を検索できるようにする場合、このオプションを選択します。たとえば、nameという選択肢属性があるとします。選択肢グループに、getChoiceWithName(String name)という名前の静的メソッドが生成されます。このメソッドは選択肢を1つ返します。
Send to client: この選択肢を返すインライン・サービスをコールする外側のクライアントに属性を送信する場合は、このオプションを選択します。
選択肢属性を追加または削除するには、「Add」または「Remove」をクリックします。選択肢属性を編集するには、属性を右クリックして、「Properties」を選択します。選択肢属性は、定義されている最上位レベルでのみ編集できます。
選択肢は、その親からスコアリング関数を継承します。選択肢のスコアリングで、その選択肢に適用するパフォーマンス・メトリックを特定して、スコアリング・メソッドをそれに適用します。スコアリング・メソッドには、スコアリング・ルール、関数、定数、選択肢イベント・モデルでのイベントの発生率などを指定できます。
たとえば、図12-2に示す選択肢グループ構造を仮定すると、一部の選択肢は次のようなスコアリングを持つ場合があります。
Mileage Plus Card
パフォーマンス・メトリック: 売上の増加
スコア: 顧客がオファーを受け入れる可能性と、オファーの潜在的売上を計算するためにカードの期待利益を使用する関数。可能性はモデルで計算されます。
Gold Card
パフォーマンス・メトリック: 売上の増加
スコア: 選択肢グループ・レベルから継承された定数
Credit Analysis
パフォーマンス・メトリック: 顧客維持の増加
スコア: 顧客データを使用してスコアを割り当てるスコアリング・ルール
適格性ルールは、選択肢グループ・レベルおよび選択肢レベルで次のように使用できます。
選択肢グループには選択肢適格性ルールとグループ適格性ルールを設定でき、それぞれ選択肢グループ・エディタの「Choice Eligibility」タブと「Group Eligibility」タブにあります。
選択肢グループのグループ適格性ルールは、選択肢グループ・レベルで定義される属性に適用されます。
選択肢グループの選択肢適格性ルールは、一般的にその選択肢グループに定義されている選択肢の属性に適用されます。
選択肢には選択肢適格性ルールを設定でき、選択肢エディタの「Eligibility Rule」タブにあります。
選択肢および選択肢グループに対するこれらのルールによって、意思決定の参加の適格性が判断されます。適格性ルールにより、目的の選択肢が、選択関数やデシジョンのルールまたは選択肢を選択するロジックへの参加に適格かどうかを判断します。
適格性ルールにより、選択肢グループまたは選択肢の先頭となるサブツリーが意思決定に適格かどうかを判断します。選択肢自身が適格であっても、そのすべての子孫が適格でないと、それらは適格となりません。
これらのルールのエディタを使用する方法の詳細は、第12.10項「ルール・エディタの使用」を参照してください。
選択肢グループおよび選択肢のルールは、継承され、追加されるようになっています。つまり、選択肢グループ（GroupおよびChoiceルール）および選択肢レベルでルールがある場合、それは論理積が適用されるようにルールが拡張されます。継承されたルールは、「Inherited eligibility conditions」というラベルの付いたルールの最上位の展開可能なセクションに表示されます。「Move Rule」アイコンを使用して、セクションを開いたり閉じたりします。
次に、選択肢グループ・ルールと選択肢ルールとの間における相互作用の例を示します。
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);
フィルタリング・ルールは、スタンドアロン・ルールとして、母集団のセグメント化に使用したり、他のルールのコンポーネントとして使用できます。スタンドアロン・ルールは、様々な要素で再利用可能です。
母集団のセグメントの識別に通常使用されるルールを図12-3に示します。
図12-3のルールは、年齢が18歳以上で信用限度額が$8000以上の顧客をターゲットとしています。
ルールの編集の詳細は、第12.10項「ルール・エディタの使用」を参照してください。
ブール値を返す適格性ルールと異なり、スコアリング・ルールでは数値を返します。返された値は、Oracle RTDのデシジョン・ロジック全体で使用できます。通常は次のような場合に使用されます。
特定のパフォーマンス目標の選択肢のスコアを設定する場合
選択肢属性の値を設定する場合
スコアリング・ルールには、どのルール・セグメントもtrueに評価されない場合のデフォルト値があります。
値を追加するには、「Value」列の「Then」または「The value is」の下をクリックします。ここで、他のルール値と同様に、省略記号をクリックして値を編集します。
たとえば、図12-4に示すスコアリング・ルールでは、顧客の信用限度額に基づいてスコアが割り当てられます。いずれの信用限度額の範囲のカテゴリにも該当しないと、スコアはデフォルトの3.25になります。
また、スコアリング・ルールには次のオプションがあります。
Description: スコアリング・ルールはDecision Centerユーザーが調整できるため、スコアリング・ルールを適切に記述することが重要です。十分に調査したスコア範囲を指定することをお薦めします。
Advanced: 「Advanced」ボタンを使用すると、Decision Centerに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。
ルールの編集の詳細は、第12.10項「ルール・エディタの使用」を参照してください。
ルールは、Decision Studio内およびDecision Center内で、様々な目的に使用します。具体的には次のような目的があります。
選択肢グループや選択肢をデシジョンに含めるかどうかの適格性を判断するため
スタンドアロンとして、意思決定のために母集団セグメントの作成に使用するフィルタリング・ルールを作成するため
スタンドアロンとして、選択肢のスコアリングに使用するスコアリング・ルールを作成するため
ルール・エディタのツールバーを使用すると、ルールの編集に使用する機能にアクセスできます。エディタのツールバーには、各ルール・エディタでルールを作成する際に必要な機能が用意されています。これらの機能は、ユーザーが実行するルール作成やルール編集のコンテキストに応じてアクティブになります。
ツールバーには、左から順に次の機能があります。
Edit rule properties
Add conditional value
Add Rule
Add Rule Set
Delete
Invert
Move up
Move down
Copy
Cut
Paste
ルールの作成に使用するエディタは、それぞれよく似ています。次の各項では、これらのエディタを使用してルールを作成する方法について説明します。
この項の内容は次のとおりです。
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"
表12-8に、Oracle RTDのルール文で使用される項目を記述するBNF（Backus-Naur Form）タイプの規約を使用して、Oracle RTDのルール文法をより正式な表現で示します。
表12-8 Oracle RTDのルール文法
| 項目 | 項目のコンポーネント | 注意 |
|---|---|---|
|
|
|
なし |
|
|
|
ルールに名前を割り当てます。 ルールが作成された後は、ヘッダー行の編集はできません。 |
|
|
All of the following | Any of the following | None of the following | Not all of the following |
論理演算子により、直後に続く |
|
|
|
ルール・エントリには必ず番号が付与されます。ルール・エントリには、ブール文などのルール・エントリを記述できます。 |
|
|
|
2番目の |
|
|
|
|
|
|
|
配列処理ルール・セットでのみ使用されます。詳細は、「数量詞および配列処理ルール」を参照してください。 |
|
|
For all | There exists |
なし |
前述の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>の部分
ルール・セットおよびブール文
ルール・セット（表12-8で<rule set>と表記）は複合文であり、1つ以上の番号付きルール・エントリで構成されます。各ルール・エントリはブール文などの別のルール・セットです。
ブール文（表12-8で<boolean statement>と表記）には、ルールが処理される際にtrueまたはfalseに評価される条件が含まれます。ブール文は、ルール・セットの最小レベルの要素であり、さらに分解することはできません。
オプションで、上位レベルのルール・セット内で定義されているルール・セットに名前を付与できます。
|
注意: Oracle RTDの各ルールには、暗黙で無名の最上位レベル・ルール・セットがあります。 |
各ルール・セットは、ルール・セット文の処理を制御する論理演算子によって修飾されます。詳細は、「論理演算子」を参照してください。
次のExclusion Rule例は、ルール・セット内にルール・セットが存在します。
この例は、次のことを表しています。
上位レベルの無名ルール・セットには、論理演算子のAll of the followingおよび2つのルール・エントリがあります。1番目のルール・エントリはブール文、2番目のルール・エントリはルール・セットです。
上位レベルのルール・セット内にあるルール・セットには、論理演算子のNone of the followingおよび3つのルール・エントリがあります。これらのルール・エントリはそれぞれがブール文です。
論理演算子
Oracle RTDの論理演算子を次に示します。
All of the following（論理積、and）。ルール・セットでは、ブール文または下位レベルのルール・セットがすべてtrueになる場合にtrueと評価されます。
Any of the following（論理和、or）。ルール・セットでは、ブール文または下位レベルのルール・セットのいずれか1つがtrueになる場合にtrueと評価されます。
None of the following（否定論理積、nand）。ルール・セットでは、ブール文または下位レベルのルール・セットがすべてfalseになる場合にtrueと評価されます。
Not all of the following（否定論理和、nor）。ルール・セットでは、ブール文または下位レベルのルール・セットのいずれか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はユーザー定義項目であり、ルール・セット内で個々の配列要素を識別するために使用されています。
配列処理ルールの修飾
配列処理ルールの修飾処理の一般的な計算式を次に示します。
<quantifier> <array_variable> in <array_name>, <logical_operator>
前述の計算式に関する説明を次に示します。
quantifierは、For allまたはThere existsのどちらかです。
For all: この数量詞をルール・セットの論理演算子と併用することで、配列要素をそれぞれ調べる必要があること、および各配列要素について、修飾されるルール・セットにあるすべてのブール文と下位レベルのルール・セットが満たされる必要があることが指定されます。
修飾されるルール・セットにあるすべてのブール文と下位レベルのルール・セットが満たされない配列要素が1つ見つかった時点で、ルールの評価は中止されます。配列の残りの要素はスキップされます。
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"
Add Rule Set
ルール・セットを追加するには、「Add Rule Set」アイコンをクリックします。
ルールに最初に作成する要素の場合、ルールに次の文が表示されます。
デフォルト論理演算子のAll of the following
ルールの番号付きの先頭行として表示されるルール・セット・エントリ: デフォルト論理演算子のAll of the followingが含まれます
オペランドが2つで空のブール文: 新たに定義されるルール・セット内にあります
これ以外の場合、現在のルール・セットで次のエントリとして、オペランドが2つで空のブール文を含む新規ルール・セット・エントリが追加されます。たとえば、ブール文が1つ含まれている既存ルール・セットにルール・セットを追加すると、追加されたルール・セット・エントリは、次に示すように、行番号2の横に表示されます。
ルール・セットの右上隅をクリックすると、名前を付与できます。ルール・セットに名前を付与する際、ルール・セット・ボックスの右上隅にある山形記号アイコンをクリックすると、ルール・セットを開いたり閉じることができます。
ルールへの（ブール文の）追加
ブール文を追加するには、「Add Rule」アイコンをクリックします。
ルールに最初に作成する要素の場合、次に示すように、デフォルト論理演算子のAll of the followingが表示され、その後にオペランドが2つで空のブール文が表示されます。
これ以外の場合、オペランドが2つで空のブール文が現在のルール・セットに追加されます。ブール文が1つ存在する場合の例を次に示します。
デフォルトでは、ブール文には2つのオペランドとそれらの間に演算子があります。
ブール文を1オペランドと2オペランドで切り替えるには、次の例に示すように、ブール文の行番号をクリックし、ブール文ボックスの右下隅の矢印アイコンをクリックします。
1オペランドは、常にブールとして評価されます。
演算子を選択するには、演算子をクリックしてから、右下隅をクリックします。
表12-9に、使用可能な演算子の一覧を示します。
表12-9 ルールの演算子
| 演算子 | 説明 |
|---|---|
|
なし |
オペランドが1個しかない単純な式 |
|
= |
左が右と等しい |
|
≠ |
左が右と等しくない |
|
< |
左が右より小さい |
|
<= |
左が右以下 |
|
> |
左が右より大きい |
|
>= |
左が右以上 |
|
in |
左側の値が右側のリストに含まれる |
|
not in |
左側の値が右側のリストに含まれない |
|
includes all of |
左側のリストに、右側のリストの値がすべて含まれる |
|
excludes all of |
左側のリストに、右側のリストの値が何も含まれない |
|
includes any of |
左側のリストに、右側のリストの値のいずれかが含まれる |
|
does not include all of |
左側のリストに、右側のリストの値の一部が含まれない |
ルールのブール文を編集するには、左側をクリックしてから、省略記号をクリックします。定数、属性、関数コールのいずれかを選択できます。配列の値を指定するには、ページの最上部で「Array」を選択します。
「Constant」を選択した場合、項目の「Data type」および「Value」を指定します。「Array」を選択した場合、必要な数の項目を配列に追加します。次に、各項目について「Data Type」を選択し、「Value」を指定します。
「Attribute」を選択した場合は、次のいずれかを指定します。
Group attribute: ルールのプロパティで選択されている選択肢グループまたはその選択肢の一部である属性。
Session attribute: セッション・エンティティの一部である属性。
Application attribute: アプリケーション要素のメンバーである属性。
Array variable: 数量化された論理演算子式内にあるルール・セットの個々の配列要素を識別するための名前。詳細は、「数量詞および配列処理ルール」を参照してください。
「Apply filter type」を選択し、「Data type」を選択して、型別に属性をフィルタリングします（必須ではない）。「Array」を選択した場合は、必要な数の項目を配列に追加してから、それぞれに属性値を割り当てます。
「Function call」を選択した場合は、次のいずれかを指定します。
Filtering rules: インライン・サービス用に定義されているスタンドアロンのフィルタリング・ルール。
Scoring rules: インライン・サービス用に定義されているスタンドアロンのスコアリング・ルール。
Function calls: インライン・サービス用に定義されているスタンドアロンの関数。
「Apply filter type」を選択し、「Data type」を選択して、型別に属性をフィルタリングします（必須ではない）。「Array」を選択した場合は、必要な数の項目を配列に追加してから、それぞれに関数またはルールを割り当てます。
オペランドまたはオペランドの一部として型が制約されたオブジェクトを選択すると、他のオペランドの値が含まれるドロップダウン・リストから値を表示できます。このドロップダウン・リストから値を選択できますが、値の選択は必須ではありません。
型制約と型制約オブジェクトの詳細は、第12.18項「型制約について」を参照してください。
フィルタリング・ルールにもスコアリング・ルールにもルールのプロパティがあり、そのプロパティは設定可能です。ルールのプロパティを編集するには、「Rule properties」アイコンをクリックします。
「Edit rule properties」が表示されます。
ルールのプロパティには、コール・テンプレートとネガティブ・コール・テンプレートがあります。コール・テンプレートを使用すると、別のルールからルールをコールする方法がわかりやすくなります。
コール・テンプレートを定義するには、「Parameters」の下の「Add」ボタンをクリックして、ルールのパラメータの数を増やします。{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
ルールのプロパティを使用すると、ルールで使用する選択肢グループを割り当てることもできます。「Use with choice group」を選択することにより、パラメータで使用する選択肢属性を提供する選択肢グループまたはその中の選択肢を指定できます。これらの属性は、オペランドの値を編集するときに使用できます。
「Invert」アイコンは、ルールで複数の要素を逆にします。ブール文の番号を選択することで、ブール文の演算子を逆にできます。たとえば、演算子が=であった場合は、逆に<>となります。
ルール・セットの論理演算子も逆にできます。それには、論理演算子を選択して「Invert」をクリックします。たとえば、「All of the following」は「Not all of the following」になります。
「Invert」の最後の使用方法は、ブール、つまり1オペランドのルールを逆にすることです。このタイプのルールを逆にすると、ルールを定義する関数のネガティブ・コール・テンプレートに変換されます。
デシジョンは、適格な選択肢のグループから1つ以上の選択肢を選択するために使用します。デシジョンは、アドバイザ内で使用するのが最も一般的です。アドバイザでは、2つのデシジョンをコールできます。1つは、通常の処理に使用するデシジョンで、もう1つはインライン・サービスでコントロール・グループ機能を使用する場合のデシジョンです。
デシジョンの設定には、選択肢の選択元である選択肢グループを1つ以上だけでなく、選択肢に順序を付けるための数値選択基準も含まれている必要があります。
選択肢の選択は、ランダムにもできますし、カスタム選択関数によってもできます。また、関連するパフォーマンス目標ごとに選択肢グループ・レベルで構成されているユーザー定義スコアリング・ロジックに基づいても選択できます。
静的スコア、関数ドリブン値、ルールベースのスコアまたは予測スコアなど、様々なスコアリング手法を使用して、選択肢ごとに複数のスコアを定義できます。
実行時に、デシジョンでは、関連付けられた選択肢グループのサブツリーで適格な選択肢をすべて識別します。次に、適格な選択肢がすべてスコアリングされ（1つ以上のスコアを使用して）、順序付けされます。
選択肢のスコアリング手法の例を次に示します。
選択肢に関心を持つ確率（Oracle RTDの自己学習予測モデルで計算）
選択肢のビジネス価値（ユーザー定義のルールまたは関数で計算）
あるいは、カスタム選択関数を作成して選択肢を選択することもできます。
選択基準は次のとおりです。
Select Choice from: デシジョンでの検討対象となる選択肢グループ（複数可）の割当てに使用します。
Number of Choices to Select: デシジョンで選択される選択肢の最大数を示します。実行時に返される選択肢の実際の数は、適格性ルールに基づいて、この数と同等以下になる場合もあります。
複数の接点で1つのデシジョンがコールされ、そのたびに異なる数の選択肢を返す必要がある場合、この数をアドバイザ・レベルで上書きできます。
デフォルトであり、最も一般的に使用される数値は1です。
Radio buttons for Type of Selection: 選択されたラジオ・ボタンによって、ランダムな選択肢を選択するか、選択肢を選択する手順の一部として重み付けされたパフォーマンス目標を使用するかが制御されます。
「Select with Fixed Goal Weights」オプションにより、母集団セグメントを指定し、各セグメントのパフォーマンス目標の重み付けを設定できます。このオプションを選択すると、画面に次に示す領域が表示されます。
Target Segments: フィルタリング・ルールを使用してセグメント化されている母集団のセグメント。デフォルトのセグメントは全員（everyone）です。
Priorities: 特定のセグメントのパフォーマンス目標の重み付けの設定に使用します。スコアリングで使用されるパフォーマンス目標は、デシジョンで選択されます。したがって、指定された各目標は、デシジョンで選択されている各選択肢グループのスコアリング方法に適合している必要があります。
「Select with Custom Goal Weights」オプションにより、パフォーマンス目標のカスタム重み付けを設定できます。通常は実行時にパフォーマンス目標の重み付けを返す関数を実行します。
「Select with Custom Goal Weights」オプションを選択し、その横にある省略記号ボタンをクリックした場合、「Value」ウィンドウで次のいずれかを選択する必要があります。
「Function or rule call」を選択してから、データ型がcom.sigmadynamics.sdo.GoalValuesを返す関数を選択します。
「Attribute or variable」を選択してから、型がcom.sigmadynamics.sdo.GoalValuesであるアプリケーション・パラメータまたはセッション属性を選択します。
「Select at Random」オプションを選択すると、選択肢グループからランダムに選択した選択肢を割り当てます。これは主として、Control Groupデシジョンに使用します。
「Select with Fixed Goal Weights」オプションと「Select with Custom Goal Weights」オプションの詳細は、第12.11.1項「母集団のセグメント化と目標の重み付け」を参照してください。
選択肢グループを追加するには、「Select」をクリックしてから、使用する選択肢グループ（複数可）を選択します。
デシジョンのパフォーマンス目標を選択するには、「Goals」をクリックしてから、適切な目標を選択します。
この項の内容は次のとおりです。
デシジョンでは、母集団のセグメントをターゲットとし、セグメントごとにそのデシジョンにアタッチしているパフォーマンス・メトリックに重みを付けることができます。
|
注意: ビジネス・ユーザーは、デシジョンのライフサイクル全体の任意の時点で、Decision Centerでデシジョンの優先度（特定セグメントのデシジョンに適用される重み付け）を変更できます。優先度は、Decision Centerの次の図と同様のウィンドウで変更できます。次に示すのは、Oracle RTDに付属のCross Sellアプリケーションから導出したウィンドウです。 |
パフォーマンス目標に必要な重み付けの種類に応じて、デシジョンは2種類の方法で設定できます。
事前定義済の重み付け: インライン・サービスで値が指定されます。
カスタムの重み付け: 実行時に値の計算や変更ができます。
事前定義済の重み付けの場合、デシジョン設定プロセスは、デシジョンの「Selection Criteria」で「Select with Fixed Goal Weights」を選択することから始めます。
次に、1つ以上のターゲット・セグメントを追加します。これは、次に示すように、ルールまたは関数で定義します。
セグメントを追加するには「Add」、削除するには「Remove」をクリックします。
最後に、各セグメントで次の手順を実行することで、各セグメントで選択したパフォーマンス目標ごとに固定パーセンテージの重み付けを指定します。
セグメントをクリックします。
「Goals」をクリックし、このデシジョンで使用するパフォーマンス目標を選択します。
選択したパフォーマンス目標が「Priorities」領域に表示されます。
「Priorities」領域で各パフォーマンス目標の重み付けを指定します。
たとえば、インライン・サービスのSelect Best Offerというデシジョンに、「Customer Retention」と「Revenue」という2つのパフォーマンス目標が定義されていると仮定します。また、フィルタリング・ルールにより「People to retain」という母集団のセグメントが定義されています。デフォルトの残りは、抱合せ販売の対象となるセグメントです。
重み付けは、パフォーマンス目標ごと、かつセグメントごとに行います。
People to retain
Customer Retention: 90%
Revenue: 10%
Default
Customer Retention: 20%
Revenue: 80%
カスタムの重み付けの場合、デシジョン設定プロセスは、デシジョンの「Selection Criteria」で「Select with Custom Goal Weights」を選択することから始めます。主な特徴は、実行時にパフォーマンス目標の重み付けを取得したり計算するために作成する必要がある関数です。この関数は、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関数、スコアリング・ルール、関数など）が、適格な選択肢すべてに適用されます。スコアは、パフォーマンス・メトリックの正規化ファクタを使用して均一化されます。次に、デシジョンに含まれているパフォーマンス・メトリックの重み付けに従って、スコアに重みが付けられます。全体のスコアが得られ、スコアが最も高い選択肢が選択されます。
標準のスコアリング・デシジョン・プロセスではなく、カスタム選択関数を使用する場合は、「Custom Selection」タブで「Custom selection」オプションを選択します。リストから選択関数を選択し、関数に必要なパラメータを追加します。
「Pre and Post Selection」タブのスクリプトレットは、スコアリングが完了してデシジョンが作成される前または後に実行されます。
選択前ロジックは、適格な選択肢をすべて収集してから選択が行われるまでの間に実行されます。選択後ロジックは、選択後、選択した選択肢が返されるまでの間に実行されます。選択後ロジックの方が一般的です。たとえば、この部分を使用して、Oracle RTDから推奨された選択肢を記録できます。
このロジックでは、選択肢の計算用に定義されている変数を使用できます。たとえば、選択前は適格な選択肢、選択後は選択した選択肢を含む選択肢配列の名前が、「Pre/Post Selection」タブで設定されます（デフォルトは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メソッドがあります。たとえば、目標が「Customer Retention」と「Revenue」の場合、メソッドは次のようになります。
public double getValueForCustomerRetention(); public double getValueForRevenue();
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「Advanced」をクリックします。Decision Centerの表示ラベルを変更して、その要素をDecision Center Navigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
標準のスコアリング・デシジョン・プロセス以外の方法として、デシジョンでは選択関数を使用できます。選択関数はすべてユーザーが定義します。ただし、選択関数には明確な特性があります。選択肢配列を入力すると、出力として選択肢配列が返されます。
選択関数には、説明および次に示すパラメータがあります。
Input Choice Array: 選択関数に対する入力パラメータ。この変数のデータ型はSDChoiceArrayです。
Output Choice Array: 選択した選択肢を含む変数の名前を指定し、この選択関数のコール元に返す必要のある戻り変数。この戻り値は、この選択関数に渡される「Input Choice Array」、または「Logic」パネル内でローカルに定義した別の変数になります。この変数のデータ型はSDChoiceArrayです。
Number of Choices Parameter: 選択関数で返す必要のある選択肢の数を表す関数の引数の名前。このパラメータのデフォルト名はnumChoicesです。この引数のデータ型はintです。
Weights: この選択関数を使用するデシジョンに目標が定義されている場合は、その目標が、「Weights」で指定されているパラメータの下の選択関数に渡されます。この型はGoalValueです。GoalValueの詳細は、デシジョンに関する項を参照してください。
Extra Parameters: 選択関数で必要なその他すべてのパラメータ。
この項の内容は次のとおりです。
選択関数は、選択条件のカスタム関数として使用します。数多くの標準的な優先度関数が、テンプレートを使用して利用できます。優先度関数や選択関数はJavaで定義します。これらのセットはテンプレートで事前に定義され、通常の場合、必要な箇所に記入されるか、拡張プロトタイプが用意されてそれを変更します。
「Input Choices Array」として渡されるリストから選択肢を実際に選択するJavaコードは、「Logic」ペインに入力します。多くの場合、「Logic」セクションの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クラスをインライン・サービスに追加するには、説明の横にある「Advanced」をクリックします。Decision Centerの表示ラベルを変更して、その要素をDecision Center Navigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
モデルは、主に予測およびレポートの2つの目的で使用します。モデルは、次の目的を達成できるように定義する必要があります。
選択肢に関連付けられている特定イベントの発生率の予測
それらのイベントと相関関係にあるデータの分析
Oracle RTDのモデルでは、ビジネス・プロセスでデシジョンを改善するために予測モデルを設計して統合する際に対処が必要な作業の多くが自動化されます。自動化される作業は次のとおりです。
予測モデルを適用する前に入力データにデータ変換を適用する作業
モデルの品質を検証する作業
新しいターゲット属性が出現した場合にモデルの再構築と再較正を行う作業
新しいデータや新しい結果によりモデルの精度を検証する作業
調査を可能にする意思決定プロセスにおいてある程度のランダム性を導入する作業
この項の以降の部分では、Oracle RTDのモデル機能によってこれらの様々な状況に対処する方法について説明します。
|
注意: また、Oracle RTDの予測モデルに累積されたデータを外部データベースのテーブルにエクスポートして、レポートとビジネス・インテリジェンスに関して標準的な製品や手法を使用して分析できます。詳細は、『Oracle Real-Time Decisionsインストレーションおよび管理ガイド』の「モデルのスナップショットの設定および使用」を参照してください。 |
モデルは、デザイン・タイムに選択肢グループに関連付けられます。これにより、予測とレポートの適用先となる選択肢のリストが定義されます。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でモデルを定義する場合、選択肢イベント・モデル、選択肢モデルおよびモデルの3種類から選択できます。
モデルの各種類は、事前定義済の使用パターンに対応しています。ほとんどの特性は共通していますが、ビジネス・デシジョンを向上する目的で予測を使用する際の自動化の度合いが異なります。すべての種類のモデルを予測とレポートに使用できます。
選択肢モデルと選択肢イベント・モデル: これらのモデルは、選択肢グループ型のターゲット属性に関連付けられます。
選択肢イベント・モデルは、ベース・イベントに応じて、イベント発生の条件付き確率の予測と分析に使用します。選択肢イベント・モデルは、1つのベース・イベントとポジティブ・イベント一覧によって定義されます。このモデルを使用して、ベース・イベントが発生した場合にポジティブ・イベントが発生する条件付き確率を予測できます。モデルでは、ポジティブ・イベント一覧は順序として解釈されます。
複数の選択肢イベント・モデルを定義して特定の選択肢グループで発生する同一イベント・グループを追跡することは可能であり、一般的に行われます。モデルごとの違いは、時間枠、ベース・イベントまたはパーティション化属性に関するものがほとんどです。
選択肢モデルは、一般的な選択肢の発生率の予測と分析に使用します。選択肢モデルでは、選択肢に関連するイベントは定義されません。このモデルで予測するのは、選択肢が存在するかどうかです。
これは、選択肢がビジネス・プロセスに存在する可能性がある項目を表す場合に便利です。たとえば、通話理由、購入対象製品、訪問先Webページなどがあります。
モデル: このモデルは、セッション属性型のターゲット属性に関連付けられます。プレーン・モデルまたはモデルは通常は使用されませんが、選択肢、選択肢グループおよびイベントなどの抽象的概念固有の知識のない汎用予測モデルを表します。
いくつかのモデル・パラメータは、3種類のモデルに共通しています。
Algorithm
「Algorithm」ドロップダウン・リストで、モデルで使用する予測アルゴリズムのタイプを定義します。
Oracle RTDでは、次の2種類のアルゴリズムがサポートされています。
Bayesianアルゴリズム
Regressionアルゴリズム
オプションを選択すると、確率のスコアを算出するための入力属性とターゲット属性との間における相関関係の処理方法が決まります。2つのアルゴリズムの違いについて理解を深めるには、数学の文献を参考にすることをお薦めします。一般論で言えば、Bayesianアルゴリズムはポジティブ結果の比率が低い場合に適しており、Regressionアルゴリズムはポジティブ結果の比率が高い（通常は15%以上）場合に適しています。
Time Window
「Default time window」チェック・ボックスと「Time Window」ドロップダウン・リストによって、モデルで時間的なライフサイクルが定義されます。デフォルトの時間枠はアプリケーション・レベルで定義され、「Default time window」の選択を解除し、「Time Window」ドロップダウン・リストから選択した場合を除いて、モデルでデフォルトで使用されます。
モデルの時間枠は、次の値に設定できます。
「Week」、「Half-Month」、「Month」、「Two Months」、「Quarter」、「Half-Year」または「Year」
古いデータが新しいデータと同じ影響を予測に与えないように、定義されたモデル時間枠に基づいて適切なタイミングで、Oracle RTDに新しいモデル・インスタンスが作成されます。Oracle RTDで適用される時間枠戦略の目的は、時間枠ごとに重なるモデル・インスタンスを自動で作成することです。Oracle RTDでは、常時存在する次の2つのモデルを使用して、重なる時間枠の手法が実装されています。
継続的に学習し予測するプライマリ・モデル
プライマリ・モデルのライフサイクルの中間点で始まり、自身がプライマリ・モデルになるまでは学習目的でのみ使用されるセカンダリ・モデル
「Use for prediction」と「Randomize Likelihood」
すべての種類のモデルを予測とレポートに使用できます。予測目的で使用するモデルでは、「Use for prediction」オプションを選択する必要があります。このオプションを選択した場合、さらに「Randomize Likelihood」オプションを使用するかどうかを決定できます。
予測に使用するモデルは、Decision Serverの実行時に、適格な各選択肢の数学的確率の計算に使用できます。
「Randomize Likelihood」オプションにより、局所的に最小または最大になる状況を予防するために、スコアに対してランダム化式が適用されます。このような状況は発生頻度が高く、モデルのライフサイクル中に新しい選択肢が導入された場合や新しく導入された選択肢に関連付けられたモデルが既存の選択肢のモデルと競合する場合に発生します。
新しい選択肢のコンテキストでは、新しい選択肢が提示される機会が実現されるように、そして学習を積み重ねた結果として、ある程度のランダム化を導入することが役に立つ場合があります。「Randomize Likelihood」オプションを選択することで、モデルのスコアをランダム化する度合いをOracle RTDで決定できます。このオプションを使用した場合にOracle RTDによって適用されるランダム化ファクタは、対象となるモデルの予測で検出されるエラーに比例します。
Premise Noise Reduction
デシジョンのために予測モデルを使用する場合に対処が必要な1つの既知データ・パターンとして、自己達成型予測があります。この状況は一般的に、入力データ属性が常にモデルのターゲット属性に関連付けられている場合に発生します。この状況の発生が予測される場合、「Premise Noise Reduction」オプションを選択します。
このオプションによって、モデル出力と高い相関関係にある入力変数値が自動的に識別され、予測から除外されます。
次に例を示します。
ショッピング・カートに追加される製品を予測するためのモデルが構築されているものと仮定します。
ショッピング・カートに存在する製品の配列が、このモデルの入力として使用されるものとします。
「Premise Noise Reduction」オプションを選択すると、製品と製品自身の間で観察される自己達成型相関関係が無視されます。Oracle RTDではさらに、入力製品に常に関連付けられている製品（たとえばセットの一部）が無視されます。
ノイズとみなされた入力属性値は、予測では無視されますが、Decision Centerではこれまでどおり表示可能であり、グラフでは灰色の棒グラフで表示されます。
Advanced: 「Advanced」ボタンを使用すると、Decision Centerに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。
選択肢イベントと選択肢モデルの「Choice」タブ
選択肢イベントと選択肢モデルの場合、「Choice」タブには次に示す共通オプションがあります。
Choice Group
Label for Choice: Decision Centerで表示される選択肢グループのラベル
選択肢イベント・モデルの場合、「Choice」タブには次に示す固有オプションがあります。
Base Event: 選択肢イベント・モデルにより計算する条件付き確率のベースラインを表す選択肢に関連付けられているイベント。イベントは、選択肢グループ・レベルで定義されているイベントのリストから選択できます。
Base Event Label
Positive Outcome Events: モデルにより条件付き確率を計算する対象となるイベントのリスト。
たとえば、Product選択肢グループに関連付けられているモデルに、ベースライン・イベントとしてDelivered、ポジティブ・イベントとしてInterestedとPurchasedの2つが存在するものと仮定します。特定の製品を購入する確率は、次のように計算します。
このモデルにより、最初にDeliveredイベントが既知であることに基づいて、Purchasedイベントの確率を計算します。この値を計算できた場合は、それを使用します。
データが不十分でそのような予測ができない場合（つまり、モデルからNAが返された場合）、モデルの確率関数で、Deliveredイベントが既知であることに基づいて、Interestedイベントの確率を計算します。この値を計算できた場合はそれを返します。
データが不十分でそのような予測ができない場合、モデルの確率関数からNAが返されます。
このとき、ポジティブ結果のリストは、予測を試みたポジティブ・イベントの順序付きリストを表します。モデルの確率関数により、イベントの順序付きリストから最もポジティブなイベントを選択できます。
選択肢モデルの場合、「Choice」タブには次に示す固有オプションがあります。
Mutually exclusive choices: このオプションは選択肢モデルの場合に使用できます。モデルのターゲットを表す選択肢が相互に排他的であることを示します。
選択肢イベントと選択肢モデルの「Attributes」タブ
選択肢イベントと選択肢モデルの場合、「Attributes」タブには次に示す共通オプションがあります。
Partitioning Attributes
パーティション化属性を追加してモデルをパーティション化することは、パーティション化属性の値ごとに個別にモデルを作成することと同等です。
たとえば、オファーの受入れ確率を予測するモデルを構築する場合、このオファーが提供され、受け入れられた対話チャネルを示すパーティション化属性を作成することが考えられます。Webオファーの受入れとコンタクト・センター・オファーの受入れを表すモデルを作成した場合、オファーを提示するチャネルが異なると、同じ特性を持つ顧客がオファーを受け入れる確率が大きく異なることが判明し、優れた予測モデルが実現されます。
モデルをパーティション化するかどうかの決定は、次の理由から、非常に慎重に行う必要があります。
属性を作成することで選択肢と属性値の組合せごとの観察頻度が減少し、その結果としてモデル対話プロセスの速度が低下します。
モデルのサイズは、パーティション化属性のカーディナリティに大きく左右されます。
除外属性: デフォルトでは、セッション属性とエンティティ属性はすべて、モデル入力として使用されます。モデルの入力のリストから特定の属性を除外するには、除外する属性を「Excluded Attributes」リストに追加します。
選択肢モデルの場合、「Attributes」タブには次に示す固有オプションがあります。
Aggregate by: パーティション化属性の1つを選択すると、属性を学習するためのサブモデルを追加作成できます。パーティション化と同様に、ある属性に基づいて集計するデシジョンは、問題の属性の値に応じて、予測される可能性の抜本的相違に基づく必要があります。
選択肢イベントと選択肢モデルの「Learn Location」タブ
選択肢イベントと選択肢モデルの場合、「Learn Location」タブには次に示す共通オプションがあります。
（学習）「On session close」または「On Integration Point」
デフォルトでは、すべてのモデル学習操作は、セッションの終了時に行われます。あるいは、モデル学習操作のトリガー処理が必要な特定統合ポイント（インフォーマントまたはアドバイザ）も選択できます。
選択肢イベントと選択肢モデルの「Temporary Data Storage」タブ
選択肢イベントと選択肢モデルの場合、「Temporary Data Storage」タブには次に示す共通オプションがあります。
Use temporary data storage
一般的なデータ・パターンとして、選択肢に関連するイベントがすべて、Oracle RTDセッションの存続期間中に発生するわけではありません。元の予測用入力値が、ポジティブ結果が遅れて発生した場合のモデルの更新でも使用されるようにするには、「Use temporary data storage」オプションを選択します。
Days to Keep: 一時データをサーバーに格納しておく日数を指定します。
Keys: 一時データ記憶域に格納されているデータは、「Temporary Data Storage」タブで定義されているキーのいずれか1つがあれば取得できます。
次のコードはそれぞれ、オブジェクトのラベルとIDを返します。
public String getSDOLabel(); public String getSDOId();
この項の内容は次のとおりです。
モデルは、次のサンプル・コードに示すgetChoiceEventLikelihoodメソッドのいずれかでクエリーを実行できます。このクエリーでは、ある選択肢がモデルによって選択される可能性が返されます。
public static SDDoubleArray getChoiceEventLikelihoods(GENOffersChoice choice); public static SDDoubleArray getChoiceEventLikelihoods(GENOffers choiceGroup); 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");
選択肢が相互排他的とマークされていない場合は、選択肢を記録する前に、getModelData()に対するコールをこのコールに含める必要があります。
if (code == 17)
ReasonAnalysis.getModelData().addToChoice("BalanceInquiry");
else if (code == 18)
ReasonAnalysis.getModelData().addToChoice("MakePayment");
else if (code == 19)
ReasonAnalysis.getModelData().addToChoice("RateInquiry");
else
ReasonAnalysis.getModelData().addToChoice("Other");
選択肢配列を処理している場合は、まず空の文字列をモデルに送信する必要があります。
ReasonAnalysis.getModelData().addToChoice("");
次に示すAPIにより、ユーザーは文字列名を指定してモデル・オブジェクトを取得できます。選択肢モデル用APIと選択肢イベント・モデル用APIがあります。
APIの一般形式
ChoiceModel <cm_model_instance_name> = Application.getApp().getChoiceModel(<model_name>);
ChoiceEventModel <cem_model_instance_name> = Application.getApp().getChoiceEventModel(<model_name>);
前述のAPIに関する説明を次に示します。
<model_name>はString型のモデル名である必要があります。
例
getChoiceEventModel APIの使用例は、「選択肢イベント・モデルAPIの例」を参照してください。
getChoiceModel APIの使用例は、「選択肢モデルAPIの例」を参照してください。
次に示すAPIにより、ユーザーは選択肢IDとイベントを渡して関連する選択肢イベント・モデルを自動的に更新できます。開発者が作成するイベント記録ロジックは1つで済みます。作成したコードは、それ以降にインライン・サービスに追加される選択肢および選択肢グループでも再利用可能であり、さらに編集する必要はありません。
APIの一般形式
<cem_model_instance_name>.recordEvent(<choiceId>,<eventId>);
前述のAPIに関する説明を次に示します。
<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>);
前述のAPIに関する説明を次に示します。
<cm_model_instance_name>はChoiceModel型で、事前にgetChoiceModel APIで取得済である必要があります。
<choiceId>はString型の選択肢識別子である必要があります。
APIの一般形式
<cm_model_instance_name>.recordChoice(<choiceId>);
前述のAPIに関する説明を次に示します。
<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>);
前述のAPIに関する説明を次に示します。
<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の間の統合点を表します。
外部システムおよび順序番号も、統合点ごとに定義されます。これらは、Decision Centerで表示されるプロセス・マップの生成に使用します。システムによって、スイムレーンと位置の順序（左から右）が決定されます。この順序は、整数のみでなくどんな数値でも可能であり、既存の統合点を変更しないで新しい統合点を導入できます。
この項の内容は次のとおりです。
インフォーマントは、外部システムとOracle RTDとの間の非同期統合点を表します。
インフォーマントは通常、次に示すように、コンテキスト情報をOracle RTDに渡して意思決定プロセスをサポートするためにトリガーされます。
インフォーマントは、クローズ・ループ情報をOracle RTDに渡して、その予測モデルを更新します。
インフォーマントは、Oracle RTDにセッション識別子を渡して、外部データソースから関連情報をフェッチします。
インフォーマントをインライン・サービスに追加する手順は次のとおりです。
外部システムを作成して、どのシステムが統合点にアクセスするかを特定します。
分析のターゲットを表す選択肢グループを作成します。たとえば、サービス・センターへの通話理由を表す選択肢グループなどです。
セッション・キー情報を受信し、セッションに基づいてデータを収集および処理するインフォーマントを作成します。
データのリポジトリであり、データを分析する分析モデルを作成します。
インフォーマントには、説明および次に示すリクエストの特徴があります。
Session Keys: セッションを一意に特定するために使用される1つ以上のセッション・キー。メッセージ内のどのセッション・キーでも、セッションを十分に特定できるため、このメッセージに関連する情報をすでに含むセッションが存在する場合、メッセージはそのセッションにディスパッチされます。
External System: インフォーマントにリクエストを送信する外部システムを特定します。インフォーマントと外部システムを関連付けると、そのインフォーマントを、Decision Centerのプロセス・マップに、他のインフォーマントおよびアドバイザとともに表示できます。
Order: この番号は、Decision Centerのプロセス・マップに表示される一連の統合点の中での、このインフォーマントの位置を特定します。別の統合点の順序より少ない順序の統合点は、他の統合点の前に表示されます。この順序は十進数です。たとえば、2.1は2.2.の前に表示されます。
Force Session Close: これを選択すると、このインフォーマントの非同期ロジックがすべて実行された後に、このインフォーマントのセッションが、インライン・サービスによって自動的に停止されます。インフォーマントの「Logic」タブのサブタブ内のどこかにJava文session().close();を配置しても、同じ効果が得られます。
この項の内容は次のとおりです。
「Request」タブで「Select」をクリックして、統合点のセッション・キーを選択します。これは、運用システムから統合点に提供される値の1つです。
「Request」タブでドロップダウン・リストを使用して、統合点にアクセスする外部システムを選択します。このメニューは、外部システム要素を使用して外部システム識別子を作成することによって移入されます。
統合点にアクセスする順序は、「Order」に表されます。この番号と「External System」によって、Decision Centerでのエンドツーエンド・プロセスの表示が決まります。
「Request」タブで「Add」をクリックして、リクエスト・データを追加します。Assignmentは、運用システムから統合点に提供される値です。Assignmentの特徴は次のとおりです。
Incoming Parameter: インフォーマントに送信されるリクエスト内のフィールドの名前。このフィールドの値が、リクエストからセッション属性にコピーされます。この名前は、セッション属性と同じである必要はありませんが、普通は同じ名前が付けられます。
セッション・キーが作成されると、入力されたパラメータがセッション・キーの属性に割り当てられます。
Type: これはセッション属性のデータ型で、入力された引数はそこにコピーされます。有効な型は、integer、string、dateまたはdoubleです。
|
注意: リクエスト・フィールドの型とセッション・キーの属性が一致しない場合、変換メソッドを使用する必要があります。 |
Array: 型がコレクションの場合にマークされます。
Session Attribute: リクエストの入力パラメータのマップ先となるセッションの属性。
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「Advanced」をクリックします。Decision Centerの表示ラベルを変更して、その要素をDecision Center Navigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
次のコードはそれぞれ、オブジェクトのラベルとIDを返します。
public String getSDOLabel(); public String getSDOId();
インフォーマントのロジックは、「Logic」タブと「Asynchronous Logic」タブで操作します。インフォーマントのリクエスト・データは、この2つのタブのどちらかを使用するとアクセスできます。
この項の内容は次のとおりです。
このスクリプトは、Request Dataで宣言されたいずれかのリクエスト・データの実行後に実行されます。インフォーマントの主要な目的が、運用システムのリクエスト・フィールドからセッション・キーおよびリクエスト・データにデータを転送することである場合、この処理は「Request Data」タブでの宣言に従って自動的に行われるため、ロジックが不要な場合があります。
インフォーマントのロジックは通常、ログ・ファイルでメッセージ受信をトレースするため、またはインフォーマントのメッセージによってキーが提供されるエンティティを事前移入するために使用します。ロジックを使用すると、レスポンス時間がより重要なアドバイザで、後にこの処理を行う必要がなくなります。ロジックは、リクエスト・データの直後に実行されます。
インフォーマントのロジックは、選択肢を選択肢モデルとともに記録する場合にも使用できます。コールするメソッドについては、選択肢モデルのAPIを参照してください。
このスクリプトは、前項で説明した「Logic」タブで定義したスクリプトの後に実行されます。ほかに必要な処理があったら、この領域に配置できます。非同期ロジックの実行順序は保証されません。
インフォーマントからリクエスト・データには、様々な方法でアクセスできます。入力されたパラメータがセッション属性にマップされる場合は、そのパラメータに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デシジョンは、最適化されたデシジョンの比較基準となるように、既存のビジネス・プロセスにできるかぎり近いものにします。
アドバイザにデフォルトの選択肢を定義できます。これらの選択肢は、サーバーでの計算を時間内に完了できない場合や、クライアントとサーバーの通信が切断された場合に使用されます。
アドバイザには、説明および次に示すリクエストの特徴があります。
Session Keys: セッションを一意に特定するために使用される1つ以上のセッション・キー。メッセージ内のどのセッション・キーでも、セッションを十分に特定できるため、このメッセージに関連する情報をすでに含むセッションが存在する場合、メッセージはそのセッションにディスパッチされます。
アドバイザがコールされると、まずセッション・キーの作成が実行されます。
External System: アドバイザのリクエストをトリガーする外部システムを特定します。アドバイザと外部システムを関連付けると、そのアドバイザを、Decision Centerのプロセス・マップに、他のインフォーマントおよびアドバイザとともに表示できます。
Order: この番号は、Decision Centerのプロセス・マップに表示される一連の統合点の中での、このアドバイザの位置を特定します。別の統合点の順序より少ない順序の統合点は、他の統合点の前に表示されます。この順序は十進数です。たとえば、2.1は2.2.の前に表示されます。
Force Session Close: このオプションを選択すると、このアドバイザの非同期ロジックがすべて実行された後に、このアドバイザのセッションが、インライン・サービスによって自動的に停止されます。アドバイザの「Logic」タブのサブタブ内のどこかにJava文session().close();を配置しても、同じ効果が得られます。
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「Advanced」をクリックします。Decision Centerの表示ラベルを変更して、その要素をDecision Center Navigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
「Request」タブで「Select」をクリックして、統合点のセッション・キーを選択します。これは、運用システムから統合点に提供される値の1つです。
「Request」タブでドロップダウン・リストを使用して、統合点にアクセスする外部システムを選択します。このリストは、外部システム要素を使用して外部システム識別子を作成することによって移入されます。
統合点にアクセスする順序は、「Order」に表されます。この番号と「External System」によって、Decision Centerでのエンドツーエンド・プロセスの表示が決まります。
「Request」タブで「Add」をクリックして、リクエスト・データを追加します。リクエスト・データは、運用システムから統合点に提供される値です。リクエスト・データの特徴は次のとおりです。
Incoming Parameter: アドバイザに送信されるリクエスト内のフィールドの名前。このフィールドの値が、リクエストからセッション属性にコピーされます。この名前は、セッション属性と同じである必要はありませんが、普通は同じ名前が付けられます。
セッション・キーが作成されると、入力されたパラメータがセッション属性に割り当てられます。
Type: これはセッション属性のデータ型で、入力された引数はそこにコピーされます。有効な型は、integer、string、dateまたはdoubleです。
|
注意: リクエスト・フィールドの型とセッション属性が一致しない場合、変換メソッドを使用する必要があります。 |
Array: このオプションは、型がコレクションの場合に選択します。
Session Attribute: リクエストの入力パラメータのマップ先となるセッションの属性。
「Response」タブで「Add」をクリックして、レスポンス・データを追加します。レスポンス・データは、リクエストを呼び出した後に、運用システムから統合点に返信される値です。レスポンス・データの特徴は次のとおりです。
Response: レスポンスには、選択した選択肢オブジェクトの配列が含まれ、各選択肢には、名前付きの属性値のコレクションが含まれています。選択肢の選択プロセスは、アドバイザで参照されている2つのデシジョン・オブジェクトのいずれか一方によって制御されます。1つのデシジョンが、コール元のアプリケーションに与えられます。
Decision to Use: Control Groupのセッションではなく、通常のセッションに使用するデシジョン・オブジェクトの名前。このデシジョンが、アドバイザからコール元システムへのレスポンスになります。
Control Group Decision to Use: Control Groupデシジョンは、ベースラインを提供することによって他のデシジョンの効果を評価する方法として、少数のセッションのみに使用されます。Control Groupデシジョンを使用するセッションの割合は、インライン・サービスのアプリケーション要素で指定します。Control Groupデシジョンは、いつもどおりのロジックを使用して選択肢を選択するように設計する必要があります。つまり、インライン・サービスの導入前にエンタープライズで使用されていたルールです。Decision Centerコンソールで、アドバイザの通常のデシジョン・オブジェクトのビジネス効果をControl Groupデシジョンと比較するレポートを使用できます。
Parameters: デシジョンによって定義される入力パラメータ。「Name」列と「Type」列は説明のみで、デシジョン・オブジェクトからここに表示されます。
Default number of choices returned: デシジョンによって返されるデフォルトの選択肢数。これは、デシジョンで定義されている選択肢の数です。
Override default with: アドバイザでは、参照先のデシジョンで指定されている数値を上書きまたはそのまま使用できます。ここでは、アドバイザのレスポンスに含めることのできる選択肢の最大数を指定します。
Default Choices: コール元のクライアント・アプリケーションがアドバイザを起動しようとしたとき、サーバーの保証されているレスポンス時間内にアドバイザがレスポンスを提供できない場合に、コール元のクライアント・アプリケーションに返される選択肢のリスト。
デフォルトの選択肢は、アドバイザごとに指定する必要はありません。インライン・サービスでもデフォルトの選択肢を宣言することがありますが、これは独自の宣言を行わないアドバイザで使用されます。また、デフォルトの選択肢構成は、クライアント・アプリケーションに伝播され、Smart Clientコンポーネントによってローカルのファイル・システムに格納されます。したがって、その後は、サーバーに接続できないクライアント・アプリケーションで使用できるようになります。
アドバイザのロジックは、「Logic」タブと「Asynchronous Logic」タブで操作します。
この項の内容は次のとおりです。
このスクリプトは、「Request Data」タブで宣言されたいずれかのリクエスト・データが実行されてから、クライアントにレスポンスが返信されるまでの間に実行されます。
アドバイザのロジックは、一般的には不要です。これは、リクエストとともに着信するデータを事前処理するため、またはデバッグ目的に使用します。
このスクリプトは、クライアントにレスポンスを返信するサーバー側メカニズムにレスポンスが渡された後に実行されます。クライアントで使用されているエンドポイントのタイプによっては、このスクリプトが終了する前にクライアントが結果の処理を開始し、並列性を強化することによって効果的なレスポンス時間を改善できます。
アドバイザからリクエスト・データには、様々な方法でアクセスできます。入力されたパラメータがセッション属性にマップされる場合は、そのパラメータにgetメソッドがあります。
request.get$()
この$は、先頭が大文字のパラメータ名です。
この属性がマップされない場合は、同じ結果をもたらすメソッドがいくつかあります。
String request.getStringValue(fieldName) SDStringArray request.getStringArrayValue(fieldName) boolean request.isArgPresent(fieldName)
外部システムは、Decision Studio内でのみ識別されます。外部システムは、インライン・サービスに統合する、エンタープライズ内の運用システムを表します。外部システムは、API経由ではアクセスできません。外部システムは、統合点で、どの外部システムがその統合点にアクセスするかを識別するために使用します。外部システムは、Decision Centerの統合マップでの表示に使用されます。
外部システムには、説明および表示ラベルがあります。表示ラベルを変更しても、オブジェクトIDには影響がありません。
カテゴリは、選択肢の整理に使用します。同じカテゴリにある選択肢はすべて、Decision Centerに一緒に表示されます。カテゴリには、クラスは生成されません。カテゴリは、Decision Centerで、選択肢のグループ分けおよび整理のみに使用します。
カテゴリの特徴は次のとおりです。
Name: Decision Studioに入力されるカテゴリの名前。
Description: Decision Studioに入力されるカテゴリの説明。
Display Label: 表示ラベルを変更できます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
関数は、計算など、再利用可能にする処理に使用できます。関数は、Decision Studioを使用して定義します。関数定義の特徴は次のとおりです。
Description: 関数の説明。
Return value: 関数が値を返すかどうかを指定します。
Data Type: 戻り値の型。
Array: このオプションは、戻り型が配列の場合に選択します。
Call Template: 関数のコール方法の定義。{0}や{1}などを引数として使用し、関数を説明する表現を設定して、コール用のテンプレートを定義します。この表現は関数使用時に表示されるため、わかりやすい表現を使用することが重要です。たとえば、multiply（乗算）のコール・テンプレートは{0} multiplied by {1}です。
Parameters: 関数のロジックで使用される名前付きパラメータ。この数値は、コール・テンプレートにある引数の数と一致する必要があります。たとえば、multiplyには、a, type Double; b, type Doubleのようなパラメータがあります。
ルールで関数パラメータを使用する場合、パラメータの型制約を選択できます。これは必須要件ではありませんが、ルールの定式化に役立ちます。型制約の作成と使用の詳細は、第12.18項「型制約について」を参照してください。
Logic: 関数のJavaコード。multiplyのコードは次のとおりです。
return a * b;
この項の内容は次のとおりです。
インライン・サービスを構成する際、Oracle RTDの選択肢イベント履歴テーブルに格納されているデータにアクセスするための事前定義済関数を使用できます。これらの関数は、選択肢適格性ルールの作成や編集でアクセスできますし、カスタムJavaロジックからもコールできます。
選択肢適格性ルール文でこれらの関数にアクセスするには、「Function Call」を選択して「Functions」フォルダを開きます。使用可能な関数のリストに、次の関数が表示されます。
| 関数名 | パラメータ | 説明 |
|---|---|---|
| Days Since Last Event | イベント名 | 特定の選択肢や指定されたイベント名に対して、最後にイベントが記録されてからの経過日数を返します。 |
| Days Since Last Event on Channel | イベント名
チャネル |
特定の選択肢、指定されたイベント名および指定されたチャネル名に対して、最後にイベントが記録されてからの経過日数を返します。 |
| Number of Recent Events | イベント名
日数 |
特定の選択肢、指定されたイベント名および指定された日数に対して、イベント記録の合計回数を返します。 |
| Number of Recent Events on Channel | イベント名
チャネル 日数 |
特定の選択肢、指定されたイベント名、指定されたチャネルおよび指定された日数に対して、イベント記録の合計回数を返します。 |
メンテナンス操作は特殊な機能であり、管理者はJConsoleで次に示すような特定のインライン・サービス関連作業を実行できます。
クラスタ全体のエンティティ・キャッシュのクリア
外部ルール・キャッシュのクリア
クラスタ内でのメッセージのブロードキャスト
ブロック操作の実行
インライン・サービス用に作成されたメンテナンス操作は、Oracle RTDによってJMX操作として公開されます。
メンテナンス操作は、クラスタの個々のメンバーでもクラスタ全体でも起動できます。メンテナンス操作は非ブロック型です。
|
注意: メンテナンス操作は、クラスタの個々のメンバーでブロック操作として直接起動できます。リクエストをブロードキャストしてクラスタ全体でメンテナンス操作を起動する場合、メッセージ配信中のみブロックされます。 |
各メンテナンス操作は、ロード可能なインライン・サービスごとに、MBeanツリーに2回表示されます。
ローカル・サーバーでのみメンテナンス操作を起動できるようにするため
クラスタのすべてのノードでメンテナンス操作を起動できるようにするため
特定のインライン・サービスでバージョンが異なる場合、メンテナンス操作が異なる場合があります。たとえば、あるインライン・サービスの複数のバージョンをデプロイできますが、それぞれのデプロイ状態が異なる場合があります。このときメンテナンス操作を使用できるのは、ロード可能な状態のインライン・サービスのみです。
メンテナンス操作に関して、次の内容をデザインタイムに考慮する必要があります。
メンテナンス操作は、プリミティブ型の引数（String、int、double、date、またはboolean）を0個以上受け取り、String、int、double、date、booleanまたはvoidを返すことができます。
戻り値（および例外）はログに記録されます。
メンテナンス操作は、グローバルなインライン・サービスのコンテキスト内で動作します。セッション属性はnullです。セッションにアクセスすると、IllegalStateExceptionがスローされます。
外部ルール・キャッシュのメンテナンス操作
Oracle RTDには、外部ルール・キャッシュのためのメンテナンス操作が用意されています。詳細は、第16.2.3.2項「外部ルール・キャッシュ」を参照してください。
インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「Advanced」をクリックします。Decision Centerの表示ラベルを変更して、その要素をDecision Center Navigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。
関数は、コール・テンプレートを使用して、他の要素からコールされます。たとえば、前項で説明したmultiply関数を使用する場合、関数を「Edit Value」ダイアログから選択します。コール・テンプレート{0} multiplied by {1}を使用すると、引数の位置と数がエディタに与えられます。
型がInteger、Double、DateまたはStringであるセッションおよびエンティティの属性、選択肢および選択肢グループの属性、および関数およびアプリケーションのパラメータに関連付けることができる制約が、型制約によって定義されます。
型制約は、通常はルール・エディタでユーザー入力を簡素化するために使用します。型が制約された要素を1つ以上使用するルールをルール・エディタで定義する場合、関連付けられている型制約で定義されている制約に従う値リストを表示して、そこから値を選択できます。型制約は、インライン・サービス・デザイナの支援機能として動作します。実行時には評価されません。
型制約には、次の3種類があります。
List of Values
List of Entities
Other Restrictions
「List of Values」型制約は、1つ以上の値を持つリストで表示されます。
「List of Entities」型制約は、関数から返されるエンティティ属性値で構成されます。「List of Entities」型制約を使用して、データベースのテーブルとビューから動的な値リストを生成できます。
「Other Restrictions」型制約は、値（データ型がDate、DoubleまたはInteger）の範囲またはJavaScript正規表現パターンで構成されます。
JavaScript正規表現パターンは一般的に、郵便番号や電話番号のように、データの各文字が、コード内の位置に応じて現実の世界における規則に従っているデータに使用されます。たとえば、米国の電話番号（例: (650) 506 7000）や英国の郵便番号（例: KT2 6JX）があります。
型制約は、サービス・メタデータ・オブジェクトとして個々に作成と編集を行います。型制約は、次のインライン・サービス・オブジェクトに、対応オブジェクト・エディタで関連付けることができます。
セッション属性およびエンティティ属性
選択肢グループ属性
選択肢属性
関数パラメータ
アプリケーション・パラメータ
ルール・エディタでオペランドとして型制約オブジェクトをルールに追加する場合、ルールの作成や編集で次の支援機能を使用できます。
「List of Values」または「List of Entities」の型制約のオブジェクトの場合、型制約に従ったドロップダウン・リストでオブジェクトの値を表示したり選択できます。
「Other Restrictions」型制約のオブジェクトの場合、マウス（カーソル）をオブジェクトの上に移動することで、型制約の範囲の制約またはJavaScript正規表現を参照できます。
この項の以降の内容は次のとおりです。
「List of Values」型制約の場合、データ型を選択し、個々の要素に1つ以上の値を指定する必要があります。
「List of Values」型制約を定義できるのは、String、Integer、DoubleまたはDateのデータです。
「List of Entities」型制約を定義するには、まず特定の前提条件を満たす必要があります。
特定のエンティティ・タイプのデータを返す関数が定義されている必要があります。
参照されるエンティティ・タイプには、列が2列以上存在する必要があります。これらは、型制約のラベルおよび値として使用されます。
ラベルの列と値の列は、ルール・エディタでルール文を編集したり、型制約を関連付けた属性またはパラメータを選択する際に使用します。
ラベルの列には、ドロップダウン・リストのデータが格納されます。ドロップダウン・リストから選択すると、値の列にある対応データがルールに追加されます。
たとえば、米国の州コードに対する型制約を使用すると、アラバマやカリフォルニアなどの米国の州名のドロップダウン・リストからルール作成者は州名を選択できます。ここでは州名の列がラベルの列として使用されます。
ルール作成者がドロップダウン・リストから州名を選択すると、Oracle RTDによって、ALやCAなどの対応する州コードがルールに追加されます。ここでは州コードの列が値の列として使用されます。
「List of Entities」型制約は、次の特性によって定義されます。
Entity: 型制約の定義対象のエンティティ。
Function: 制約されたデータを返す関数。この関数の戻り値のデータ型として、型制約エンティティを指定する必要があります。
Label: 型制約エンティティの属性であり、この型制約を使用してオブジェクトを参照するルールを作成する際、ドロップダウン・リストの値はこの属性に保持されます。
Value: 型制約エンティティの属性であり、ユーザーがルール・エディタでドロップダウン・リストからラベル値を選択した際にルールに追加される値がこの属性に保持されます。
「List of Entities」型制約を定義できるのは、String、Integer、DoubleまたはDateのデータです。
|
注意: 「List of Entities」型制約を作成したり編集した後で、インライン・サービスをデプロイする必要があります。これによって、型が制約された属性またはパラメータを使用するルールを作成する際に、正しい値がドロップダウン・リストに表示できるようになります。 |
「Other Restrictions」により、範囲の制約または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つ以上のインライン・サービス・オブジェクトに関連付けることができます（対応するオブジェクト・エディタを使用）。
セッション属性およびエンティティ属性
選択肢グループ属性
選択肢属性
関数パラメータ
アプリケーション・パラメータ
対応するオブジェクト・エディタの使用方法の詳細は、このドキュメントの対応するオブジェクトに関する項を参照してください。
型制約をオブジェクトに関連付けると、ビジネス・ユーザーがルール・エディタでそのオブジェクトのルールを定式化する際に役に立ちます。
ルールを作成または編集する際、次のオプションを選択できます。
「List of Values」または「List of Entities」のどちらかの型制約が関連付けられたオブジェクトをオペランドとして選択すると、もう一方のルール・オペランドではドロップダウン・リストから値を選択できます。このドロップダウン・リストから値を選択できますが、値の選択は必須ではありません。
「Other Restrictions」型制約のオブジェクトをオペランドとして選択してから、マウスをその上に移動すると、型制約の範囲の制約またはJavaScript正規表現がバルーン・ヘルプに表示されます。
|
注意: 型制約は、ルールの作成や編集を支援する機能であり、厳格な要件ではありません。たとえば、型制約のある要素のルールに、ドロップダウン・リストに表示されていない値を入力できます。実行時には、ルールは評価され、それに応じて動作しますが、型制約は評価されません。 |
一般的に次が成立します。
「List of Values」型制約によって定数リストが提示されます。
「List of Entities」型制約によって動的な実行時リストが提示されます。
「Other Restrictions」により、リスト・エントリに対するチェック以外の型検証を設計できます。
型制約に対する違反は、次に示すように、エラーではなく警告として処理されます。
違反しているオペランドは、赤色の波型下線で示されます。
違反しているオペランドの上にマウスを移動すると、違反の詳細を参照できます。
警告があっても、ルールをコンパイルしてデプロイすることは可能です。
この項では、様々な型制約を作成して使用する方法の例を示します。
「List of Values」型制約
Product_Sizeという名前で、Large、Medium、Smallを値とする型制約を作成します。
Product_Size型制約をsession/Product属性に関連付けます。
次に示すように、ルール・エディタでフィルタリング・ルールのLarge_Productを作成します。
session/Product = "Large"
「List of Entities」型制約
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であり、その値がルールに追加されます。
「List of Entities」型制約による動的な値の表示
この例では、型が制約されたオブジェクトをルールで使用する際に、データベース・テーブルの値を表示したり選択できます。
Look Upエンティティを作成し、String型属性としてStatecodeおよびStatenameを追加します。
Statesテーブルに基づいて、Abbr列とFullname列を持つStates DSデータソースを作成します。
US States Look Upエンティティを次に示す特性で作成します。
Look Up型のlookUp配列属性
States DS/AbbrにマッピングされたlookUp/Statecode属性
States DS/FullnameにマッピングされたlookUp/Statename属性
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正規表現パターンを使用するその他の型制約
Date型制約をMorning Rush Hourの名前で作成し、次の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つずつ作成されます。選択肢イベントの統計コレクタは、インライン・サービスで定義されているイベントの統計を自動的に収集します。統計コレクタのプロパティは次のとおりです。
Description: 統計コレクタの説明。
Collect Statistics On: 統計は、選択肢や選択肢グループなどのオブジェクトごとに個別に収集することも、同じタイプのすべてのオブジェクトに集計して収集することもできます。
Aggregation: 個々のイベントを記録するか、または集計されたデータを記録します。個々のイベントを記録する場合は、トランザクションの多いシステムにパフォーマンス上の問題が発生する場合があるため、注意が必要です。
Aggregation Interval: 統計コレクタによりデータを記録する前の集計に要する時間（単位は秒）。
Expiration: 「Keep forever」または「Purge old statistics」を選択します。「Keep forever」を選択する場合は、データのサイズが問題になる場合があるため、注意が必要です。
Keep in database for: データを消去するまでの時間（日）。
パラメータはすべて、Decision Studioエディタを使用して構成できます。選択肢イベントの統計は、レポートとしてDecision Centerに表示されます。
Decision Studioを使用して、オブジェクトまたはクラスに関する追加の統計を記録するカスタム統計コレクタを作成できます。たとえば、選択肢に関する統計を記録する統計コレクタを作成できます。パラメータは、前項の説明に従って構成します。
インライン・サービスのコードで（たとえば、インフォーマントまたは関数コール経由で）、統計コレクタのファクトリを作成し、統計コレクタ名（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は、オブジェクトの内部名です。
Decision Studioと同様に、Decision Centerを使用すると、インライン・サービスを様々なパースペクティブから操作できます。パースペクティブは、Decision Centerでの初期レイアウトを定義します。パースペクティブごとに、特定のタイプのタスク達成を目的とした一連の機能があり、特定のタイプのリソースに対応します。パースペクティブは、特定のメニューおよびツールバーの表示を制御します。
Decision Centerには、デフォルトのパースペクティブとして、「Explore」、「Design」、「At a Glance」の3つがあります。インライン・サービス・ナビゲータは、使用しているパースペクティブに従って変わります。システム管理者がパースペクティブを追加している場合もあります。
Decision Centerのパースペクティブへのアクセスは、ロールに権限を割り当てることで制御できます。ロール管理の詳細は、『Oracle Real-Time Decisionsインストレーションおよび管理ガイド』を参照してください。
パースペクティブの権限を割り当てるには、Decision Studioのインライン・サービス・ナビゲータに進み、アクセスを設定するパースペクティブを右クリックします。「Properties」を選択して「Add」をクリックします。権限の割当て先となるロールを選択して、「Permissions」の下の「Use perspective」を選択します。「OK」をクリックして終了します。
