Oracle® Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイド

11g リリース1 (11.1.1)

B72429-01(原本部品番号:E16630-06)

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

第I部 概要

1 Oracle Real-Time Decisionsについて

- 1.1 用語

- 1.2デシジョン・スタジオについて

- 1.2.1 「インライン・サービス・エクスプローラ」ビュー

- 1.2.2 「問題」ビュー

- 1.2.3 「テスト」ビュー

- 1.2.4 カンニング・ペーパー・ビュー

- 1.2.5 エディタ領域

- 1.2.6 ビューの配置とエディタのサイズ変更

- 1.3デシジョン・センターについて

- 1.4 インライン・サービスのライフサイクルについて

2 インライン・サービスの作成

- 2.1 インライン・サービス・チュートリアルについて

- 2.2 デプロイおよびデシジョン・センターのセキュリティについて

- 2.3 命名および説明について

- 2.4 データのアクセス

- 2.4.1 データ・ソースの追加

- 2.4.1.1 データ・ソースの新規作成

- 2.4.1.2 データ・ソースの出力のインポート

- 2.4.2 エンティティの追加

- 2.4.2.1 エンティティの新規作成

- 2.4.2.2 その他のエンティティ・プロパティについて

- 2.4.2.3 エンティティ・キーの追加

- 2.5 セッション・エンティティについて

- 2.5.1 セッション・エンティティへの属性の追加

- 2.5.2 セッション・キーの作成

- 2.5.3 データ・ソースへのエンティティのマッピング

- 2.6 インフォーマントの追加

- 2.6.1 インフォーマントの作成

- 2.6.2 インフォーマントへのテスト・ロジックの追加

- 2.7 インライン・サービスのテスト

- 2.8 機能の追加

- 2.8.1 Callエンティティの作成

- 2.8.2 Call Beginインフォーマントの作成

- 2.8.3 Service Completeインフォーマントの作成

- 2.8.4 Call Endインフォーマントの作成

- 2.8.5 インフォーマントのテスト

- 2.9 通話理由の分析

- 2.9.1 分析のための選択肢の使用について

- 2.9.2 選択肢グループの追加

- 2.9.3 分析モデルの追加

- 2.9.4 選択肢の選択のためのロジックの追加

- 2.9.5 全体のテスト

3 インライン・サービスに対する負荷のシミュレート

- 3.1 負荷下のパフォーマンス

- 3.1.1ロード・ジェネレータ・スクリプトの作成

- 3.1.2デシジョン・センターにおける分析結果の表示

- 3.1.3 属性の除外

- 3.2 モデルの学習内容のリセット

- 3.2.1 インライン・サービスの要約

4 コール・センターのインライン・サービスの機能拡張

- 4.1 選択肢グループの使用と抱合せ販売へのスコアリングについて

- 4.2 選択肢グループによるオファー(抱合せ販売)インベントリの作成

- 4.3 パフォーマンス目標の構成

- 4.4 選択肢のスコアリング

- 4.5 アドバイザについて

- 4.6 デシジョンの作成

- 4.7 アドバイザの作成

- 4.8 統合マップの表示

- 4.9 アドバイザのテスト

5 フィードバック・ループのクローズ

- 5.1 成功を追跡するイベントの使用

- 5.1.1 選択肢グループにおけるイベントの定義

- 5.1.2 選択肢イベント・モデルの定義

- 5.1.3 その他のモデル設定

- 5.1.3.1 パーティション化属性

- 5.1.3.2 除外属性

- 5.1.3.3 学習の実行場所

- 5.1.4 提案されたオファーの記憶

- 5.1.5 フィードバック・インフォーマントの作成

- 5.1.6 フィードバック・インフォーマントのテスト

- 5.1.7ロード・ジェネレータ・スクリプトの更新

- 5.2 モデルの予測機能の使用

- 5.2.1 売上単価選択肢属性の追加

- 5.2.2 2番目のパフォーマンス目標(売上の最大化)の追加

- 5.2.3 パフォーマンス目標であるMaximize Revenueのスコア値の計算

- 5.2.4 2番目のパフォーマンス目標の挿入によるSelect Offerデシジョンの更新

- 5.2.5 受入れ確率を表示するための選択肢属性の追加

- 5.2.6 受入れ確率値のチェック

- 5.2.7 特定の顧客に対するオファー受入れバイアスの導入

- 5.2.8ロード・ジェネレータ・スクリプトの実行

- 5.2.9 結果の検証

第II部 統合ガイド

6 Oracle RTDとの統合について

- 6.1 最適な統合方法の選択

- 6.1.1 Javaスマート・クライアントについて

- 6.1.2 .NETスマート・クライアントについて

- 6.1.3 JSPスマート・クライアントについて

- 6.1.4 PHPクライアントについて

- 6.1.5 Webサービスについて

- 6.2 CrossSellインライン・サービスについて

- 6.2.1デシジョン・スタジオによるオブジェクトIDの特定

- 6.2.2 セッション・キーおよび引数の特定

- 6.2.3 アドバイザのレスポンスの決定

- 6.2.4 Oracle RTDへのイベント・レスポンスの特定

- 6.3 Oracle RTD WebサービスとWebサービス・セキュリティ

- 6.4 システム要件と動作保証情報

7 Javaスマート・クライアントの使用

- 7.1 作業前の準備

- 7.2 Javaスマート・クライアントによるインライン・サービスとの統合

- 7.2.1 Javaスマート・クライアントのサンプルの準備

- 7.2.2 Javaスマート・クライアントのプロパティ・ファイルの作成

- 7.2.3 Javaスマート・クライアントの作成

- 7.2.4 リクエストの作成

- 7.2.5 レスポンスの確認

- 7.2.6 ループのクローズ

- 7.2.7 クライアントのクローズ

8 Javaスマート・クライアントのJSPタグの使用

- 8.1 作業前の準備

- 8.2 Javaスマート・クライアントのJSPタグによるインライン・サービスとの統合

- 8.3 JSPスマート・クライアント・サンプルのデプロイ

- 8.3.1 WebLogicへのJSPスマート・クライアント・サンプルのデプロイ

9 PHPクライアント

- 9.1 作業前の準備

- 9.2 Oracle RTD PHPクライアントによるインライン・サービスとの統合

- 9.2.1 PHPクライアント・サンプルのデプロイ

- 9.2.2 Oracle RTD PHPクライアントの.iniファイルの設定

- 9.2.3 Nusoapパス・ライブラリの場所の編集

- 9.2.4 Oracle RTD PHPクライアントの作成

- 9.2.5 リクエストの作成

- 9.2.6 レスポンスの確認

- 9.2.7 ループのクローズ

10 .NETスマート・クライアントの使用

- 10.1 作業前の準備

- 10.2 .NETスマート・クライアントによるインライン・サービスとの統合

- 10.3 .NET統合のサンプル

11 Webサービス・クライアントのサンプル

- 11.1 作業前の準備

- 11.2 新しいNetBeans Javaアプリケーション・プロジェクトの作成

- 11.3 用意されているJavaコードの追加およびクライアントのテスト

第III部デシジョン・スタジオ・リファレンス

12デシジョン・スタジオについて

- 12.1 インライン・サービスについて

- 12.1.1 インライン・サービスの構成

- 12.1.2 インライン・サービスの一般的なタイプ

- 12.1.2.1 オブザーバ・インライン・サービス

- 12.1.2.2 アドバイザ・インライン・サービス

- 12.2デシジョン・スタジオとEclipse

- 12.2.1デシジョン・スタジオのワークスペースの選択

- 12.2.2 Javaコンパイラ準拠レベルの設定

- 12.2.3 インライン・サービス・エクスプローラについて

- 12.2.4 コード生成

- 12.2.5デシジョン・スタジオのパースペクティブおよびビューについて

- 12.2.6 ビューの配置とエディタのサイズ変更

- 12.2.7 要素へのカスタム・ロジックの追加

- 12.2.8 生成済コードの上書き

- 12.2.9 インライン・サービス検索の実行

- 12.3デシジョン・スタジオのプロジェクトの概要

- 12.3.1 新規プロジェクトの開始

- 12.3.2 プロジェクトのインポート

- 12.3.3 ユーザー定義テンプレートの作成

- 12.3.4 デプロイされているインライン・サービスのダウンロード

- 12.3.5 デプロイの状態について

- 12.3.6 サンプル・プロジェクト

- 12.4 インライン・サービスのディレクトリ構造

- 12.5 インライン・サービスのセキュリティ

13デシジョン・スタジオの要素とAPIについて

- 13.1 Oracle RTDの意思決定プロセスの概要

- 13.2 Oracle RTDの意思決定プロセス

- 13.3 要素の表示ラベルとオブジェクトIDについて

- 13.4 アプリケーション要素について

- 13.4.1 アプリケーション・パラメータ

- 13.4.1.1 デバッグ・オプションの使用

- 13.4.1.2 アプリケーション・パラメータの追加

- 13.4.2 アプリケーションAPI

- 13.4.3 制御グループの構成

- 13.4.4 モデルのデフォルト値の設定

- 13.4.5 アプリケーションの書込みロジック

- 13.4.5.1 インポートされたJavaクラスの追加

- 13.5 データのアクセス

- 13.5.1 データ・ソースについて

- 13.5.2 SQLデータ・ソースの作成

- 13.5.2.1 SQLデータ・ソースの特性

- 13.5.2.2 データ・ソースへの列の追加

- 13.5.2.3 データベース列名のインポート

- 13.5.2.4 入力列の設定

- 13.5.3 ストアド・プロシージャ・データ・ソースの作成

- 13.5.3.1 ストアド・プロシージャ・データ・ソースの特性

- 13.5.3.2 ストアド・プロシージャ・パラメータのインポート

- 13.5.3.3 データ・ソースへの属性の追加

- 13.5.3.4 データ・ソースへの結果セットの追加

- 13.5.3.5 ストアド・プロシージャからのデータ・ソースの設定例

- 13.5.4 Oracle Business Intelligence Enterprise Editionデータへのアクセス

- 13.6 エンティティの形成

- 13.6.1 Sessionエンティティについて

- 13.6.1.1 セッション・キーについて

- 13.6.2 エンティティの作成

- 13.6.3 属性およびキーのエンティティへの追加

- 13.6.4 データ・ソースからの属性のインポート

- 13.6.5 解析の属性の使用

- 13.6.6デシジョン・センターの表示

- 13.6.7 セッション・キーの追加

- 13.6.8 セッションへの属性の追加

- 13.6.9 属性のデータ・ソースへのマップ

- 13.6.10 1対多関係

- 13.6.11 インポートされたJavaクラスの追加

- 13.6.12 セッション・ロジック

- 13.6.13 セッションAPI

- 13.6.14 エンティティAPI

- 13.6.15 エンティティ・クラスについて

- 13.6.16 Oracle RTDロジックでのエンティティの参照

- 13.6.17 エンティティ・キーの追加

- 13.6.18 エンティティ属性へのアクセス

- 13.6.19 エンティティのリセットと入力

- 13.6.20 キャッシュされたエンティティについて

- 13.6.21 エンティティ属性のロギングの拡張

- 13.7 パフォーマンス目標

- 13.7.1 パフォーマンス・メトリックの追加

- 13.7.2 正規化ファクタの計算

- 13.8 選択肢グループおよび選択肢

- 13.8.1 選択肢グループおよび選択肢について

- 13.8.2 選択肢グループと選択肢属性について

- 13.8.3 選択肢属性の特徴

- 13.8.4 選択肢のスコアリングについて

- 13.8.5 適格性ルールについて

- 13.8.6 選択肢グループのルールおよび選択肢の適格性ルールの評価

- 13.8.7 適格性の判定

- 13.8.8 選択肢グループのAPI

- 13.8.9 選択肢のAPI

- 13.9 フィルタリング・ルール

- 13.10 スコアリング・ルール

- 13.11 ルール・エディタの使用

- 13.11.1 Oracle RTDのルールの項目と文

- 13.11.2 ルールへの文の追加

- 13.11.3 演算子の選択

- 13.11.4 ブール文の編集

- 13.11.4.1 ルールにおける型制約オブジェクトの使用

- 13.11.5 ルール・プロパティの編集

- 13.11.6 ルール要素の反転

- 13.12 Decisionsについて

- 13.12.1 母集団のセグメント化と目標の重み付け

- 13.12.2 カスタム選択関数の使用

- 13.12.3 選択前と選択後のロジック

- 13.12.4 目標のカスタム重み付けの選択関数API

- 13.12.5 インポートされたJavaクラスの追加とデシジョン・センターの表示の変更

- 13.13 選択関数について

- 13.13.1 選択関数のスクリプトレット

- 13.13.2 インポートされたJavaクラスの追加とデシジョン・センターの表示の変更

- 13.14 モデルについて

- 13.14.1 モデルの種類

- 13.14.2 共通のモデル・パラメータ

- 13.14.3 モデルの属性

- 13.14.4 モデルのAPI

- 13.14.4.1 モデルの問合せ

- 13.14.4.2 選択肢をモデルとともに記録

- 13.14.4.3 文字列名によるモデル・オブジェクトの取得

- 13.14.4.4 選択肢イベント・モデルの選択肢イベントの記録

- 13.14.4.5 選択肢モデルの選択肢の記録

- 13.14.4.6 モデル選択肢の確率の取得

- 13.15 統合点について

- 13.15.1 インフォーマントについて

- 13.15.1.1 セッション・キーの追加

- 13.15.1.2 外部システムおよび順序の特定

- 13.15.1.3 リクエスト・データの追加

- 13.15.2 インポートされたJavaクラスの追加とデシジョン・センターの表示の変更

- 13.15.3 インフォーマントのAPI

- 13.15.4 インフォーマントのロジック

- 13.15.4.1 ロジック

- 13.15.4.2 非同期ロジック

- 13.15.4.3 インフォーマントからのリクエスト・データへのアクセス

- 13.15.5 アドバイザについて

- 13.15.6 アドバイザの意思決定プロセスについて

- 13.15.7 インポートされたJavaクラスの追加とデシジョン・センターの表示の変更

- 13.15.8 セッション・キーの追加

- 13.15.9 外部システムおよび順序の特定

- 13.15.10 リクエスト・データの追加

- 13.15.11 レスポンス・データの追加

- 13.15.12 アドバイザのロジック

- 13.15.12.1 ロジック

- 13.15.12.2 非同期ロジック

- 13.15.13 アドバイザからのリクエスト・データへのアクセス

- 13.15.14 セッション・キーのない統合点の一時セッション

- 13.16 外部システムについて

- 13.17 カテゴリ・オブジェクトについて

- 13.18 関数について

- 13.18.1 選択肢イベント履歴表とともに使用する関数

- 13.18.2 メンテナンス操作について

- 13.18.3 インポートされたJavaクラスの追加とデシジョン・センターの表示の変更

- 13.19 型制約について

- 13.19.1 型制約の管理

- 13.19.1.1 「値リスト」型制約の作成および編集

- 13.19.1.2 「エンティティのリスト」型制約の作成および編集

- 13.19.1.3 「他の制約」の作成および編集

- 13.19.1.4 インライン・サービス・オブジェクトと型制約の関連付け

- 13.19.1.5 ルールでの型制約の使用

- 13.19.1.6 型制約の例

- 13.20 統計コレクタについて

- 13.20.1 カスタム統計コレクタの作成

14 インライン・サービスのデプロイ、テストおよびデバッグ

- 14.1 インライン・サービスのデプロイ

- 14.2 Real-Time Decision Serverへの接続

- 14.3 インライン・サービスの再デプロイ

- 14.4 インライン・サービスのテストおよびデバッグ

- 14.4.1 「問題」ビューについて

- 14.4.2 「テスト」ビューの使用

- 14.4.2.1 logInfo()の使用

- 14.4.2.2 着信リクエスト・データのテスト

- 14.4.3 システム・ログを使用してインライン・サービスのテストとデバッグを行う方法

15ロード・ジェネレータについて

- 15.1ロード・ジェネレータによるテスト

- 15.2ロード・ジェネレータによるパフォーマンスの特徴付け

- 15.3ロード・ジェネレータのセッションの実行

- 15.3.1 サーバーの負荷の測定

- 15.4 パフォーマンス・グラフの表示

- 15.5 「一般」タブについて

- 15.5.1 「ロード・ジェネレータ」セクション

- 15.5.2 「詳細」セクション

- 15.5.3 「思考時間」セクション

- 15.5.4 「スクリプト」セクション

- 15.5.5 「ロギング」セクション

- 15.6 変数について

- 15.6.1 変数の使用

- 15.6.2 変数型

- 15.7 アクションについて

- 15.7.1 アクションの種類

- 15.8ロード・ジェネレータのCSVログ・ファイルの内容

- 15.9 XLSファイルのコンテンツ

第IV部 その他のアプリケーション開発

16 Oracle RTDバッチ・フレームワーク

- 16.1 バッチ・フレームワーク・アーキテクチャ

- 16.1.1 バッチ・フレームワークのコンポーネント

- 16.1.2 クラスタ環境内でのバッチ・フレームワークの使用

- 16.2 バッチ・ジョブの実装

- 16.2.1 BatchJobインタフェースの実装

- 16.2.2 バッチ・フレームワークへのバッチ・ジョブの登録

- 16.2.2.1 BatchAgent

- 16.2.2.2 インポートされたJavaクラスのインライン・サービスへの登録

- 16.2.2.3 バッチ・ジョブのインライン・サービスへの登録

- 16.3 バッチ・ジョブの管理

- 16.3.1 BatchClientAdminインタフェースの使用

- 16.3.2 バッチ・コンソールの使用

- 16.3.2.1 バッチ・コンソール・コマンドに関する注意

- 16.3.2.2 ジョブの順次実行

- 16.3.2.3 ジョブの並行処理

17 外部化されたオブジェクト管理

- 17.1 動的選択肢

- 17.1.1 動的選択肢の簡単な例

- 17.1.2 動的選択肢の基本設計の概要

- 17.1.3 単一データ・ソースからの複数カテゴリの動的選択肢

- 17.1.3.1 同一データ・ソース内に異なる動的選択肢カテゴリがある場合

- 17.1.4 動的選択肢の外部データ・ソースの前提条件

- 17.1.5デシジョン・スタジオにおける動的選択肢の設定の概要

- 17.1.6 動的選択肢のデータ・ソースの作成

- 17.1.7 動的選択肢の単一エンティティの作成

- 17.1.8 動的選択肢のセット・エンティティの作成

- 17.1.9 動的選択肢のデータ取得関数の作成

- 17.1.10 選択肢グループの設計に関する考慮事項

- 17.1.11 単一カテゴリの選択肢グループの作成

- 17.1.11.1 「グループ属性」タブ

- 17.1.11.2 「選択肢属性」タブ

- 17.1.11.3 「動的選択肢」タブ

- 17.1.12 複数カテゴリの選択肢グループの作成

- 17.1.12.1 親選択肢グループの「グループ属性」タブ

- 17.1.12.2 子選択肢グループの「グループ属性」タブ

- 17.1.12.3 子選択肢グループの「動的選択肢」タブ

- 17.1.13 動的選択肢のレポートの概要

- 17.1.13.1 静的選択肢のみのアプリケーション

- 17.1.13.2 動的選択肢の表示

- 17.1.13.3 システム生成の範囲フォルダ

- 17.1.13.4デシジョン・センター・フォルダ間での選択肢の分散

- 17.1.13.5 動的選択肢のデシジョン・センター・レポートの例

- 17.2 外部ルール

- 17.2.1 外部ルールの概要

- 17.2.2 外部ルール・エディタの構成要素

- 17.2.2.1 外部ルール・エディタと外部ルール・エディタ・クライアント

- 17.2.2.2 Oracle Web Service Manager (OWSM)

- 17.2.2.3 セキュリティ

- 17.2.2.4 ワークベンチWebサービス

- 17.2.3 外部ルール・エディタのデプロイメント・トポロジ

- 17.2.4 外部ルール・エディタの作成およびデプロイ手順

- 17.2.4.1 構築

- 17.2.4.2 統合

- 17.2.4.3 パッケージ化

- 17.2.4.4 デプロイ

- 17.2.4.5 セキュリティ

- 17.2.5 外部ルール・エディタ・インタフェースの要件

- 17.2.6 外部ルール・フレームワーク

- 17.2.6.1 外部ルール評価関数

- 17.2.6.2 外部ルール・キャッシュ

- 17.2.6.3 外部ルールAPI

- 17.2.6.4 外部ルール・エラーの処理およびロギング

- 17.2.7デシジョン・スタジオにおける外部ルールの設定

- 17.2.7.1 前提条件 - 外部コンテンツ・リポジトリ内のオブジェクトの設定

- 17.2.7.2 ルールのインライン・サービス・オブジェクトの定義

- 17.2.7.3 インライン・サービス・オブジェクトの外部ルールの定義

- 17.2.8 外部インタフェースおよび埋込みルール・エディタの設定

- 17.2.8.1 ルール・エディタ・ウィジェットの定義

- 17.2.8.2 ルール・エディタのコンテキストと範囲の変更

- 17.2.8.3 コールバック関数の定義

- 17.3 動的選択肢および外部ルールを使用したエンドツーエンド開発の例

- 17.3.1 データベース・ドリブン型動的選択肢

- 17.3.2 外部ルールの評価

- 17.3.3 サード・パーティ製インタフェースへの外部ルール・エディタの埋込み

- 17.3.4 DC_Demo外部ルール・デプロイメント・ヘルパー

- 17.3.5 本番環境への外部ルールの送信

- 17.3.6 動的選択肢のレポートの表示

- 17.4 外部化されたパフォーマンス目標の重み付け

A Oracle RTDモデルの機能と戦略

- A.1 モデルの概念

- A.2 モデルからデシジョンへ

- A.3 モデルの成熟

- A.3.1 重要度しきい値

- A.4 モデルのランダム化された確率計算

- A.5 複数イベントに対するモデル確率計算

- A.5.1 個別のモデル確率のリクエスト

- A.6 デシジョンのための選択肢のスコアリング

- A.6.1 新しい選択肢の導入

- A.7 モデル品質

- A.7.1 モデル品質のしきい値とモデルの使用

- A.8 よくある質問

B Oracle RTD Webサービスおよびクライアント

- B.1 Oracle RTD Webサービス

- B.1.1 Oracle RTD Webサービスの概要

- B.1.2 管理Webサービス

- B.2 Oracle RTDクライアント

- B.3 Webサービスのセキュリティ

- B.3.1 Oracle RTD Decision Server認証の無効化

- B.3.2 グローバルにアタッチされたポリシーから直接アタッチされたポリシーへの置換

C ストアド・プロシージャからのデータ・ソースの例

- C.1 単一結果のストアド・プロシージャからのデータ・ソースの作成

- C.2 結果セットが1つのストアド・プロシージャからのデータ・ソースの作成

- C.3 結果セットが2つのストアド・プロシージャからのデータ・ソースの作成

D インライン・サービス・メタデータのローカライズ

- D.1 ローカライズの概要

- D.2 ローカライズのソース・テキスト文字列とターゲット・テキスト文字列

- D.3 インライン・サービス・ローカライズの設定

- D.3.1 ローカライズ・データをテキスト・ファイルに格納する場合の設定例

- D.3.2 ローカライズ・データをデータベースに格納する場合の設定例

Oracle® Fusion Middleware

Oracle Real-Time Decisionsプラットフォーム開発者ガイド

11g リリース1 (11.1.1)

B72429-01(原本部品番号:E16630-06)

2013年2月

Oracle Real-Time Decisions (Oracle RTD)を使用して適応性のあるソリューションを開発する方法について説明します。チュートリアル、Oracle RTDとの統合に関する情報およびインライン・サービスの詳細が含まれます。

Oracle Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイド 11g リリース1 (11.1.1)

B72429-01

Copyright © 2011, 2013, Oracle and/or its affiliates.All rights reserved.

原本著者: Oracle Corporation

原本協力者: Oracle Real-Time Decisionsの開発、製品管理および品質保証チーム

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

はじめに

Oracle Real-Time Decisions (Oracle RTD)は、適応性の高いエンタープライズ・ソフトウェア・ソリューションの開発を可能にします。こうした適応性のあるソリューションは、ビジネス・プロセス・トランザクションが実行される際に継続的に学習し、ルールと予測モデルに従って、各トランザクションをリアルタイムで最適化します。

このドキュメントは、次の4つの部で構成されています。

- 第I部「概要」は、Oracle RTDの使用を開始する際に役立つ情報および例を提供するチュートリアルです。

- 第II部「統合ガイド」では、Oracle RTDスマート・クライアント、Webサービスおよび直接メッセージングを行ううリアルタイム・デシジョン・サーバーを含むOracle RTDとの統合に関する情報を提供します。

- 第III部「デシジョン・スタジオ・リファレンス」では、インライン・サービスの構成に使用する各要素を特定します。各インライン・サービスのプロパティおよび使用可能なAPIについても説明します。

- 第IV部「その他のアプリケーション開発」では、Oracle RTDアプリケーション・オブジェクトの変更が可能な外部エディタやバッチ・フレームワークなど、特別な処理を必要とするOracle RTDアプリケーション開発に関連する概念、コンポーネントおよびプロセスについて詳しく説明します。

対象読者

このドキュメントの第I部は、Oracle RTDのテクニカル・ユーザーがインライン・サービスの構成に使用する機能、用語、ツールおよび手法についてよく理解できるようにすることを目的としています。

このドキュメントの第II部は、JavaベースのAPI、.NETコンポーネントまたはWebサービスを使用して、エンタープライズ・アプリケーションをOracle RTDインライン・サービスと統合する開発者を対象としています。

このドキュメントの第III部は、デシジョン・スタジオを使用してインライン・サービスを構成するテクニカル・ユーザーを対象としてます。

このドキュメントの第IV部は、Oracle RTDアプリケーション・オブジェクトとインタフェースするバッチ・ジョブまたは外部エディタを開発するテクニカル・ユーザーを対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

関連するOracle Business Intelligenceのドキュメントのリストは、Oracle Business Intelligenceのドキュメント・ライブラリを参照してください。

次の関連ドキュメントも参照してください。

- 使用しているプラットフォーム用のOracle Fusion Middlewareリリース・ノート

- 『Oracle Fusion Middleware Webサービスの紹介』

- 『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』

また、Oracle Business Intelligenceに関連するオンライン・トレーニングのリソースについては、Oracle Learning Libraryを参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

第I部

概要

第I部の各章は、Oracle RTDの使用方法を紹介するチュートリアルになっています。各章の例は、WindowsシステムにOracle RTDがインストールされていることが前提になります。

第I部の内容は次のとおりです。

- 第1章「Oracle Real-Time Decisionsについて」

- 第2章「インライン・サービスの作成」

- 第3章「インライン・サービスに対する負荷のシミュレート」

- 第4章「コール・センターのインライン・サービスの機能拡張」

- 第5章「フィードバック・ループのクローズ」

1 Oracle Real-Time Decisionsについて

この章では、Oracle Real-Time Decisions (Oracle RTD)の各コンポーネントについて説明します。特に、開発ツールDであるecision StudioとWebベースのアプリケーションであるデシジョン・センターに重点を置いて説明します。また、インライン・サービスについても概説します。インライン・サービスを作成すると、ビジネス・プロセスをモデル化し、統計を収集して提案を行うことができます。さらに、開発サイクルにおけるインライン・サービスの使用方法についても説明します。デシジョン・スタジオを使用すると、インライン・サービスを構成できます。デシジョン・センターでは、デプロイされたインライン・サービスをビジネス・アナリストが監視および最適化できます。

Oracle Real-Time Decisions (Oracle RTD)により、新世代のエンタープライズ分析ソフトウェア・ソリューションを実現します。これによって、ビジネス運用プロセスにおける重要な局面でより適切な意思決定を企業がリアルタイムにできるようになります。

Oracle RTDは、フロント・エンド(WebサイトやCRMアプリケーションなど)およびバック・エンド(エンタープライズ・データストアなど)のどちらでも、エンタープライズ・アプリケーションと容易に統合できます。またOracle RTDには、負荷テストやデバッグに役立つその他のツールも用意されています。

この章には次のトピックが含まれます:

- 第1.1項「用語」

- 第1.2項「デシジョン・スタジオについて」

- 第1.3項「デシジョン・センターについて」

- 第1.4項「インライン・サービスのライフサイクルについて」

1.1 用語

Oracle RTDは、次の5つのコンポーネントで構成されています。

- デシジョン・スタジオ

- Real-Time Decision Server

- デシジョン・センター

- Administration

- ロード・ジェネレータ

インライン・サービスとは、デプロイされる構成済のアプリケーションです。

インライン・サービスは、デシジョン・スタジオを使用して構成およびデプロイされ、デシジョン・センターを使用して分析および更新されます。インライン・サービスの実行はReal-Time Decision Serverで行われます。

インライン・サービスは、Real-Time Decision Serverでどのようにリアルタイムかつ継続的にデータを収集して企業のビジネス・プロセスの特性を分析するかを記述したメタデータで構成されています。

要素は、次のいずれかのタイプのオブジェクトです。

- アプリケーション: デフォルトのモデル・パラメータなどのアプリケーション・レベル設定や、インライン・サービスでグローバルに必要なパラメータを指定します。

- パフォーマンス目標: Oracle RTDでの選択肢のスコアリングにおいて、デシジョン基準の設定で使用されるキー・パフォーマンス・インディケータ(KPI)を指定します。

- 選択肢: インライン・サービスで提示されるオファー、またはOracle RTDの自己学習モデルで追跡される学習対象を表します。

- ルール: ルールはグラフィカルに構成され、母集団のセグメントを定めたり、適切な選択肢を決定したり、特定の選択肢のスコアリングを行ったりするために使用されます。

- デシジョン: 関連する各パフォーマンス目標に対して重み付けされたスコアに基づいて、適格な選択肢のスコアリングとランキングを行います。

- 選択関数: Oracle RTDアドバイザを介して送信する選択肢を選択するためのカスタムな方法として、デシジョンで使用できます。
アドバイザは統合点です。詳細は、この一覧で後述する「統合点」を参照してください。

- エンティティ: システム内のアクターを表します。エンティティは、Oracle RTDのモデリングとデシジョンで使用されるデータの論理的表現です。エンティティの属性は、統合点からの入力パラメータとしてデータ・ソース経由で移入したり、カスタム・ロジックを介してリアルタイムで導出できます。

- データ・ソース: 表またはストアド・プロシージャからデータを取得します。

- 統合点: 統合点は、Oracle RTDと連携動作する外部システムとの接点の役割を果たします。統合点には、インフォーマントとアドバイザという2種類があります。インフォーマントは外部システムからデータを受信するのに対して、アドバイザはデータを受信して外部システムに推奨情報を送信します。

- モデル: 自己学習型の予測モデルであり、デシジョンの最適化や適切な学習対象のリアルタイム分析で使用できます。

- 統計コレクタ: エンティティに関する統計を追跡する特殊なモデルです。

- カテゴリ:デシジョン・センターに表示するデータの分割に使用されます。

注意:

Oracle RTDドキュメント全体にわたって次の用語が参照されます。

- RTD_HOME: Oracle RTDクライアント側ツールがインストールされているディレクトリです。

- RTD_RUNTIME_HOME: アプリケーション・サーバーによってOracle RTDが実行されるアプリケーション・サーバー固有ディレクトリです。

詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「Oracle RTDラインタイム環境について」を参照してください。

1.2 デシジョン・スタジオについて

デシジョン・スタジオは、インライン・サービスを構成するための開発ツールです。インライン・サービスとは、ビジネス・プロセスをモデル化し、統計を収集して提案を行うために作成するサービスです。デシジョン・スタジオは、Eclipse Foundation社により開発されたオープン・ソースのJava IDEであるEclipseと完全に統合されています。デシジョン・スタジオはEclipse環境に対する標準プラグインとして存在します。Eclipseを使用している場合は、この環境を利用して、追加の開発機能や高度な機能を使用できます。Eclipseに精通していない場合でも、デシジョン・スタジオを完全に透過的に使用できます。Eclipseおよびデシジョン・スタジオでは、ともにヘルプ・メニューからオンライン・ヘルプを使用できます。デシジョン・スタジオでは、複数のパースペクティブでインライン・サービスを操作できます。パースペクティブは、そのパースペクティブのビューやエディタの初期設定およびレイアウトを定義します。パースペクティブはそれぞれ、特定のタイプのタスクを実行するための一連の機能を提供し、特定のタイプのリソースを操作します。パースペクティブは、特定のメニューおよびツールバーの表示を制御します。

パースペクティブ(インライン・サービス、Java、リソースなど)を選択したり、別のパースペクティブに変更したりするには、デシジョン・スタジオで「ウィンドウ」メニューをクリックし、パースペクティブを開くを選択して、使用可能なパースペクティブのリストから選択します。最初にデシジョン・スタジオを起動したときのデフォルトのパースペクティブは「インライン・サービス」です。このチュートリアルでは、このパースペクティブを使用します。通常、インライン・サービスの開発にはこのパースペクティブを使用します。

図1-1に示すように、デフォルトの「インライン・サービス」パースペクティブには、4つのビューおよびエディタ領域があります。

図1-1デシジョン・スタジオの「インライン・サービス」パースペクティブ

「図1-1デシジョン・スタジオの「インライン・サービス」パースペクティブ」の説明

この項には次のトピックが含まれます:

- 第1.2.1項「「インライン・サービス・エクスプローラ」ビュー」

- 第1.2.2項「「問題」ビュー」

- 第1.2.3項「「テスト」ビュー」

- 第1.2.4項「カンニング・ペーパー・ビュー」

- 第1.2.5項「エディタ領域」

- 第1.2.6項「ビューの配置とエディタのサイズ変更」

1.2.1 「インライン・サービス・エクスプローラ」ビュー

「インライン・サービス・エクスプローラ」ビューでは、ユーザーが構成するインライン・サービスのすべての要素が編成されます。

1.2.2 「問題」ビュー

「問題」ビューには、インライン・サービスを構築してコンパイルする際の検証エラー(.sdaファイル)およびコンパイル・エラー(.javaファイル)が表示されます。検証エラーをダブルクリックすると、「問題」ビューに、メタデータ/要素エディタがエラー・ポイントで開きます。コンパイル・エラーをダブルクリックすると、「問題」ビューに、生成されたソース・コード(.javaファイル)がエラー・ポイントで開きます。生成されたソース・コード・ファイルを直接編集しないでください。関連するメタデータ/要素の問題を解消すると、ソース・コードが再生成され再コンパイルされます。

1.2.3 「テスト」ビュー

「テスト」ビューでは、インライン・サービスをサーバーにデプロイした後、Studioからインライン・サービスを直接テストできます。

1.2.4 カンニング・ペーパー・ビュー

カンニング・ペーパー・ビューには、一般的なタスクの手順が表示されます。インストール後、このビューはウィンドウの右側に配置されます。

ヒント:

カンニング・ペーパー・ビューを閉じてエディタ領域を拡大することもできます。このチュートリアルではカンニング・ペーパーは使用しません。

1.2.5 エディタ領域

インライン・サービス・パースペクティブの中央の領域はエディタ領域です。選択したプロジェクト・ツリーのノードに固有のエディタが表示されます。新しいエディタに変更するには、「インライン・サービス・エクスプローラ」ビューで編集する要素をダブルクリックします。

1.2.6 ビューの配置とエディタのサイズ変更

エディタのタブには、現在編集のために開かれているリソース名が表示されます。アスタリスク(*)は、変更がまだ保存されていないことを示します。

パースペクティブのビューおよびエディタは、画面上の任意の領域にドラッグできます。ビューおよびエディタのサイズは、配置される領域に合せて自動的に変更されます。(主な作業場所である)エディタまたはビューの一部が、他のビューに覆われたり、使用するには不便な領域にサイズ変更される場合があります。エディタまたはビューのサイズを変更するには、開いている別のビューを閉じて残りが自動的にサイズ変更されるようにするか、エディタ・タブをダブルクリックすることによりエディタまたはビューを最大化します。

エディタとビューはどちらも、タブをダブルクリックするか、右クリックして表示されるメニュー・アイテムを使用して、最大化と最小化を切り替えることができます。

さらにビューを表示するか、閉じたビューを開くには、デシジョン・スタジオの「ウィンドウ」メニューをクリックし、「ビューの表示」を選択して使用可能なビューのリストから選択します。

1.3 デシジョン・センターについて

デシジョン・センターは、デプロイされたインライン・サービスをビジネス・アナリストが監視および最適化できるWebベースのアプリケーションです。デシジョン・センターでは、意思決定方法の調整だけでなく、モデルから収集された統計の表示や、抱合せ販売などのキャンペーンの微調整を実行できます。デシジョン・センターのユーザー・インタフェースでは、インライン・サービスを2つのペインで表示します。左側のペインにはインライン・サービスの要素のリストが表示され、右側のペインには選択された要素に関連する詳細情報が表示されます。

図1-2デシジョン・センター

「図1-2デシジョン・センター」の説明

1.4 インライン・サービスのライフサイクルについて

インライン・サービスはデシジョン・スタジオを使用して作成されます。図1-3は、インライン・サービスのライフサイクルを示しています。

図1-3 インライン・サービスのライフサイクル

「図1-3 インライン・サービスのライフサイクル」の説明

次の手順では、インライン・サービスを作成、デプロイおよびダウンロードするプロセス全体の概要を示します。

1. 作成:デシジョン・スタジオを使用して、Oracle RTDの統合先となるビジネス・プロセスに合せて要素を構成します。要素の例には、選択肢グループ、パフォーマンス目標、デシジョン、インフォーマント、アドバイザ、エンティティおよびデータ・ソースなどがあります。
一部の要素では、「ロジック」属性および「非同期ロジック」属性にJavaスクリプトレットを使用できます。例として、図1-4にインフォーマント要素を示します。この要素の名前は「Call Begin」です。「説明」および「詳細」ボタンのほかに3つのタブがあり、それぞれにインフォーマントの属性のセットがあります。

図1-4 Call Beginインフォーマント

「図1-4 Call Beginインフォーマント」の説明

図1-5に示すように、このCall Beginインフォーマントの「ロジック」タブで、特定のタスクを実行するオプションJavaコードを記述できます。

図1-5 Call Beginインフォーマントの「ロジック」タブ

「図1-5 Call Beginインフォーマントの「ロジック」タブ」の説明

要素が作成され保存されると、オブジェクトを記述するXMLメタデータがメモリーに作成されます。

2. 保存:デシジョン・スタジオでインライン・サービスを保存すると、ローカル・ファイル・システム上のインライン・サービス・ディレクトリで、拡張子*.sdaのXMLファイルにメタデータが記述されます。Call BeginインフォーマントのメタデータはCallBegin.sdaというファイルに保存され、その内容の例は次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<sda:RTAPType xmlns:sda="http://www.sigmadynamics.com/schema/sda"
internalName="CallBegin" lastModifiedTime="1133228616435" name="Call Begin"
schemaVersion="20050818" forcesSessionClose="false" order="1.0">
<sda:description>The Call Begin Informant starts the session after the
customer's call enters the IVR system. Logic could be added here to pre-
populate certain values (example: customer profile) that may be used later   on.</sda:description>
<sda:system ref="Ivr"/>
<sda:sessionKey path="customer.customerId" relativeTo="session"/>
<sda:requestMapper internalName="RequestMapper">
<sda:entity type="ApplicationSession" var="session"/>
<sda:dataSource type="RequestDataSource" var="result">
<sda:arg>
<sda:path localVarName="session" path="request" relativeTo="local"/>
</sda:arg>
</sda:dataSource>
</sda:requestMapper>
<sda:requestData internalName="RequestDataSource">
<sda:param internalName="message" dataType="object"
objectType="com.sigmadynamics.client.wp.SDRequest"/>
<sda:request>
<sda:resultSet/>
</sda:request>
</sda:requestData>
<sda:body>
<sda:java order="0">/* Trigger data retrieval
*/&#xD;&#xA;session().getCustomer().fill(); </sda:java>
</sda:body>
<sda:postOutputBody/>
</sda:RTAPType>

デシジョン・スタジオで要素に割り当てられたセッション・キーおよび外部システムなどの属性がここに示されます。JavaスクリプトレットもXMLファイルのボディに挿入されていることに注意してください。

インライン・サービスの要素が追加、構成、保存されると、デシジョン・スタジオは必要なJavaコードを自動的に生成してコンパイルし、Javaクラス・ファイルを作成します。2つのクラスのJavaコードが生成されます。最初のセットは、インライン・サービスで使用される基本Javaファイルです。これらのファイル名は、要素IDの前にGENを付けた名前となります。たとえば、CallBegin要素はGENCallBegin.javaというファイルを生成します。

2番目のJavaファイルのセットは、生成されたコードを上書きできるように作成されます。これらのファイル名は要素IDと同じ名前になります。たとえば、CallBegin要素はCallBegin.javaというファイルを生成します。デフォルトでは、JavaクラスCallBeginは、クラスGENCallBeginを単純に拡張します。

インライン・サービスのコンパイル時には、上書きコードを使用する特別な指示がないかぎり、生成されたコードが使用されます。上書きコードを使用するには、上書きJavaファイル(CallBegin.javaなど)を更新し、次の生成されたソース・ファイルのフォルダ

Inline_Service_project_root_folder\gensrc\com\sigmadynamics\sdo

から、次の上書きソース・ファイルのフォルダに移動します。

Inline_Service_project_root_folder\src\com\sigmadynamics\sdo

これにより、デシジョン・スタジオでは、生成されたJavaファイルではなく、上書きJavaファイルを使用してコンパイルが実行されます。

ヒント:

インライン・サービス・オブジェクトのXMLは、デシジョン・スタジオの組込みテキスト・エディタで表示できます。「インライン・サービス・エクスプローラ」ビューでインライン・サービス・オブジェクトを右クリックし、「次で開く」メニューから「テキスト・エディタ」を選択します。通常のエディタ形式に戻すには、「インライン・サービス・エディタ」オプションを選択します。

インライン・サービス・オブジェクトを変更する場合は、XML(*.sda)ファイルを直接編集しないでください。変更するには、対応するインライン・サービス・エディタを使用してください。

3. デプロイ: インライン・サービスは、デシジョン・スタジオを使用してReal-Time Decision Serverにデプロイされます。このサーバーの管理サービスでは、メタデータおよびコンパイルされたインライン・サービス・ファイルの受信、インライン・サービスのデータベースへの格納、およびインライン・サービスのメモリーへのロードが行われます。これにより、インライン・サービスを利用して、リクエストの処理やレポートの表示などを実行できます。

4. 表示および更新: レポートおよび学習は、ブラウザベースのデシジョン・センター・インタフェースを介して表示されます。インライン・サービスの選択された要素およびパラメータは、デシジョン・センターから更新できます。更新されたインライン・サービスは、再デプロイされるまでランタイムで使用できません。

5. 再デプロイ:デシジョン・センターでインライン・サービスを更新した場合、デシジョン・センターでインライン・サービスを再デプロイすることで、この変更を使用できるようになります。管理サービスでは、必要なすべてのメタデータとJavaファイルの再生成、インライン・サービスの再コンパイル、インライン・サービスのデータベースへの格納、およびメモリーへのロードが行われます。

6. ダウンロード:デシジョン・スタジオを使用して、デプロイされたインライン・サービスをサーバーからダウンロードできます。ダウンロードでは、データベースにあるインライン・サービスをコピーして、メタデータ、Javaおよびクラス・ファイルをハード・ドライブ上のデシジョン・スタジオ・プロジェクトに配置します。これは、インライン・サービスの元の開発者ではないためにメタデータ・ファイルがない場合に便利です。ビジネス・プロセスで他のユーザーにデシジョン・センターを介したインライン・サービスの変更および再デプロイを許可している場合は、インライン・サービスを最初にデシジョン・スタジオで開発およびデプロイしたユーザーであっても、デシジョン・スタジオでそのインライン・サービスをさらに変更するには、まずサーバーから最新バージョンをダウンロードする必要があります。

2 インライン・サービスの作成

これは、インライン・サービスを作成および構成する手順について説明するチュートリアル・セクションの序章です。この章では、インライン・サービスの主な要素(データ・ソース、エンティティ、インフォーマント、アドバイザ、 選択肢グループ、モデル、デシジョン)について説明し、これらの要素をデシジョン・スタジオで作成およびテストする方法を示します。

このチュートリアル・セクションは、特定のプロセスとその特性をリアルタイムで継続的に監視するインライン・サービスを構成する方法を説明することを目的としています。このタイプのインライン・サービスは、ビジネス・ユーザーが、様々なビジネス・イベントおよび時間の経過に伴うビジネス・イベントの誘因の変化を分析する際の指針となります。

このチュートリアルのインライン・サービスは、クレジット・カード会社のコール・センターに関するものです。このインライン・サービスでは、顧客およびコール・センターの業務系システムに関するデータを収集し、その通話内容と解決方法についての情報を分析します。

このインライン・サービスの目標は、通話のパターン、通話理由および顧客を分析することです。後述の各項では、このインライン・サービスの機能を拡張して、抱合せ販売のオファーについてCRMシステムに提案を行い、さらにその提案の結果についてサービスにフィードバックを加えます。

この章には次のトピックが含まれます:

- 第2.1項「インライン・サービス・チュートリアルについて」

- 第2.2項「デプロイおよびデシジョン・センターのセキュリティについて」

- 第2.3項「命名および説明について」

- 第2.4項「データのアクセス」

- 第2.5項「セッション・エンティティについて」

- 第2.6項「インフォーマントの追加」

- 第2.7項「インライン・サービスのテスト」

- 第2.8項「機能の追加」

- 第2.9項「通話理由の分析」

2.1 インライン・サービス・チュートリアルについて

インライン・サービスはデシジョン・スタジオ開発ツールを使用して作成されます。一般に、インライン・サービスは次のように作成されます。

- デシジョン・スタジオでプロジェクトが開始されます。

- 要素がそのプロジェクトに追加され、目的のビジネス・ニーズをサポートするように構成されます。

- 操作を実行する特定の要素に、Javaスクリプトレットの形式でロジックが追加されます。

- インライン・サービスが、実行されるDecision Serverにデプロイされます。

- インライン・サービスの使用から生成されるレポートがデシジョン・センターに表示されます。

このチュートリアルでは、次の要素が追加および構成されます。

1. アプリケーション: 必要なアプリケーション・レベルの設定を行い、インライン・サービスのセキュリティを定義します。アプリケーション要素は、各インライン・サービスに対して自動的に作成されます。

2. パフォーマンス目標: スコアリングを使用して最適化されるメトリックで構成される組織目標を表します。たとえば、収益や通話継続時間はパフォーマンス・メトリックです。組織目標は、通話継続時間を最小化して収益を最大化すること、などになります

3. データ・ソース: 外部データ・ソースからのデータのプロバイダとして機能します。データ・ソースのデータの構造および形式は様々に異なります。例:

- RDBMS表の行と列

- ストアド・プロシージャからの出力値と結果行セット

データ・ソースは、エンティティ要素にマップできるデータのプロバイダで、エンティティ要素にデータを提供します。

たとえば、このチュートリアルでは、データベース内の表に接続するデータ・ソースを追加します。この表には顧客データが含まれます。

4. エンティティ: 1つ以上のデータ・ソースから構築されるデータの論理的表現です。エンティティは次の目的を果たします。

- 組織、分析およびモデル化のためのオブジェクトにデータを編成する。

- 様々なソースのデータのJavaコードから、比較的簡単でわかりやすいアクセスを可能にする。

- データ取得の詳細を隠し、ロジックを変更せずにこれらの詳細を変更できるようにする。

- データ取得のメカニズムを隠し、ユーザーがデータの取得に使用されるAPIを処理せずに済むようにする。

- オブジェクトを共有する必要がある場合に、オブジェクトの共有をサポートする。たとえば、サービス・エージェントを表すオブジェクトは複数のセッションで使用される場合があります。

エンティティの属性はキー値にすることができます。エンティティ・キーは、エンティティのインスタンスの特定に使用されます。

たとえば、このチュートリアルでは、顧客を表すエンティティを作成します。そのエンティティの属性は、値のデータ・ソースにマップされます。顧客IDがその顧客エンティティのキーとして選択されます。

後で、通話を表すエンティティも作成します。

5. セッション・エンティティ: Oracle RTDにおけるセッションは、単一のインスタンスに固有のフロント・エンド・アプリケーションとのやりとりを表します。たとえば、ある顧客がコール・センターに電話をかけたとき、その単一の顧客とエージェントとのやりとりがセッションになります。同様に、顧客によるWebサイトの訪問や、その訪問時のページ間の移動もセッションの例といえます。
セッション・エンティティは、インライン・サービスの特殊なエンティティです。セッション・エンティティは、定義された特定のセッションに固有の属性のコンテナを表します。セッション・キーによって個々の各セッションが一意に識別されます。

セッション・エンティティの属性として設定することにより、定義されたエンティティをセッションに関連付けることができます。セッション属性であるエンティティのみが、そのキーをセッション・キーとしてマーク付けできます。

たとえば、このチュートリアルでは、顧客エンティティを属性としてセッション・エンティティに追加し、セッション・キーとして顧客キー値である顧客IDを選択します。

6. インフォーマント: インフォーマントとは、インライン・サービス内で構成する統合点です。インフォーマントは、フロント・エンド・クライアントがビジネス上のやりとりに関するデータをその発生時にOracle RTDに提供できようにするほか、Decision Serverでビジネス・ロジックをトリガーできます。インフォーマントはOracle RTDによるプロセスの「監視」を可能にする一方向のフィードを表しますが、プロセスとのやりとりは行いません。
このチュートリアルでは、まずテスト用インフォーマントを作成し、その後CRMシステムからすべてのサービス・データを収集するインフォーマントを作成します。

このチュートリアルの後半では、モデルの予測の成功または失敗について、インライン・サービスにフィードバックを行うインフォーマントを作成します。

7. 選択肢グループ: インライン・サービスに選択肢の論理階層を作成するときに使用します。選択肢グループは、Oracle RTDモデリングおよびデシジョンに使用する、オファーなどのスタディ対象を編成する手段を提供します。
たとえば、このチュートリアルでは、まず通話理由を編成する選択肢グループを作成します。インライン・サービスを拡張してアドバイザを含める際に、選択肢グループを使用して、サービス・センター・エージェントに提案される抱合せ販売のオファーを編成します。

8. モデル: 組込み分析モデルによる自己学習および自動分析が可能です。モデルは、単にデータを分析する場合にも、ビジネス・プロセスへの提案を行うときに使用する確率スコアを生成する場合にも使用できます。
このチュートリアルでは、通話理由を分析するモデルを作成し、その後、顧客に最も受け入れられる可能性のある抱合せ販売のオファーの決定に役立つモデルを作成します。

9. デシジョン: デシジョンは、アドバイザが適切な選択肢を決定し、各選択肢のスコアを動的に計算し、母集団のセグメントと指定パフォーマンス目標に応じてスコアに重みを付け、選択肢のランク付けリストをアドバイザに返すために使用されます。

10. アドバイザ: コール元のビジネス・プロセスに情報を返す統合点です。アドバイザは、ランク付けされた選択肢を1つ以上返すインライン・サービスでデシジョンをコールします。
このチュートリアルでは、クレジット・カード・サービス・センターへの通話者に対して提示できるオファーの選択肢グループを作成します。アドバイザはデシジョンを呼び出し、通話および通話者に関する情報に基づいて、通話者にとって最適なオファーを決定します。アドバイザは、その抱合せ販売の提案をフロント・エンド・アプリケーションに渡します。これによって、コール・センター・エージェントが抱合せ販売を提案できるようになります。

2.2 デプロイおよびデシジョン・センターのセキュリティについて

インライン・サービスをReal-Time Decision Serverにデプロイし、インライン・サービスの結果をデシジョン・センターで表示できるためには、必要なロールが付与されていることが必要です。このロールは、ユーザー名とパスワードを介することで提供されます。

このチュートリアルでは、BIConsumerおよびBIAuthorのロールが割り当てられた有効なユーザー・ログインとパスワードが作成されていることを前提としています。

必要に応じて、Oracle RTDシステムのインストールと設定を担当する管理者に問い合せてください。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「Oracle Real-Time Decisionsのセキュリティ」を参照してください。

2.3 命名および説明について

要素の名前および説明は、ビジネス・ユーザーのユーザー・インタフェースであるデシジョン・センターで広く使用されます。したがって、要素を作成する際は、時間をかけてわかりやすい要素名を付け、すべての要素に適切な説明を記述することが非常に重要です。

始める前に、Real-Time Decision Serverが起動されていることを確認します。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsの起動と停止に関する項を参照してください。

アプリケーション要素を構成する手順は次のとおりです。

1. RTD_HOME\eclipse\eclipse.exeを実行し、デシジョン・スタジオを起動します。デシジョン・スタジオが開いたら、「ファイル」→「新規」→「インライン・サービス・プロジェクト」を選択して、新規プロジェクトを開始します。

注意:

このチュートリアルでは、新規インストールを元のプリファレンス設定で使用することを前提としています。すでにデシジョン・スタジオまたはEclipseを使用している場合は、新しいワークスペースに切り替えることもできます。新しいワークスペースに切り替えるには、「ファイル」→ワークスペースの切替えを選択し、新しいワークスペース・フォルダを選択します。

2. プロジェクト名としてTutorialを指定し、「基本」テンプレートを選択します。「終了」をクリックします。インライン・サービスのアップグレードについて尋ねられたら、「はい」を選択します。「インライン・サービス・エクスプローラ」にインライン・サービス・プロジェクトが作成されます。デフォルトでは、インライン・サービス・プロジェクトのファイルは、デシジョン・スタジオのワークスペースのプロジェクトと同じ名前のフォルダに保存されます(C:\Documents and Settings\Windows_user\Oracle RTD Studio\Tutorialなど)。

3. デシジョン・スタジオで、「チュートリアル」→「サーバー・メタデータ」フォルダを開きます。「アプリケーション」要素をダブルクリックし、要素エディタを表示します。要素エディタに、Tutorialインライン・サービスの説明を入力します。

2.4 データのアクセス

組織データにアクセスするには、次の2つの要素を構成します。

- データ・ソース: データベース内のデータ構造を表す要素です。

- エンティティ: 1つ以上のデータ・ソースによって移入可能なデータ、またはインフォーマントによって取得されるコンテキスト・データの論理的表現です。

図2-1 データ・ソースとエンティティとのマッピング

「図2-1 データ・ソースとエンティティとのマッピング」の説明

この項には次のトピックが含まれます:

- 第2.4.1項「データ・ソースの追加」

- 第2.4.2項「エンティティの追加」

2.4.1 データ・ソースの追加

データ・ソースを追加するには、新しいデータ・ソースを作成してからデータ・ソースの出力をインポートします。

この項には次のトピックが含まれます:

- 第2.4.1.1項「データ・ソースの新規作成」

- 第2.4.1.2項「データ・ソースの出力のインポート」

2.4.1.1 データ・ソースの新規作成

データ・ソースを作成する手順は次のとおりです。

1. デシジョン・スタジオのインライン・サービス・エクスプローラで、「データ・ソース」を選択してダブルクリックします。「新規SQLデータ・ソース」を選択します。「ラベルの表示」で「Customer Data Source」と入力し、「OK」をクリックします。データ・ソース・エディタが表示されます。

2. 「説明」で、データ・ソースの説明に「Customer data from a database table」と入力します。
適切な説明であることが非常に重要です。これらの説明はデシジョン・センターで使用され、ビジネス・ユーザーがレポートおよび分析のコンポーネントを識別するために必要不可欠です。

注意:

いくつかの別のデータ・ソースがすでに定義されています。これらはインライン・サービスのフレームワークの一部であり、このチュートリアルでは使用しません。

2.4.1.2 データ・ソースの出力のインポート

データ・ソースの出力は、データベースから取得された列になります。出力に表内のすべての列が含まれる必要はありません。

データ・ソースの出力をインポートする手順は次のとおりです。

1. 「インポート」をクリックします。「データベース表のインポート」が表示されます。「サーバー」の横に各自のサーバーが表示されます。「次」をクリックし、サーバーに接続します。「表またはビューの選択」が表示されます。

2. 「JDBCデータ・ソース」で「SDDS」を選択します。次に、「表とビュー」で「CrossSellCustomers」を選択します。この表は、CrossSellインライン・サービスに対してInitAppDBスクリプトを実行すると作成されます。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のCrossSellサンプル・データの移入に関する項を参照してください。

3. 「終了」をクリックします。

4. 表のすべての列が「出力」列表にインポートされます。

5. データ・ソースの入力列を設定します。入力は、データ・レコードを取得する際に一致させる列です。ここでは、「出力」列表でID列名を選択し、右矢印(→)をクリックして、IDを「入力」列表に移動できます。データ型は「Integer」です。

6. データ・ソースの出力列を設定します。「出力」列表で、表2-1に示されている列を除いてすべてを選択し、「削除」を使用して削除します。

表2-1 CrossSellCustomers表に保持する「出力」列

名前

型

Age

Integer

HasCreditProtection

String

Language

String

LastStatementBalance

Double

MaritalStatus

String

NumberOfChildren

Integer

Occupation

String

7. 「ファイル」→「すべて保存」を選択して、作業内容を保存します。作業にエラーがある場合は、「問題」ビューに通知が表示されます。

注意:

「インポート」を使用して、データ・ソースの出力に列名およびデータ型をインポートできます。使用しない列は、「削除」で削除します。

2.4.2 エンティティの追加

データ・ソースを定義したので、対応するエンティティの定義に進みます。エンティティは、構成内の他の要素によって使用されるオブジェクトです。エンティティは、データ・ソースやインフォーマントなどのデータのソースからの抽象レベルを提供します。1つのエンティティは、多くのデータ・ソースからのデータ、あるいは計算値を持つことができます。今回は、データ・ソースの構造に直接マップされる簡単なエンティティを作成します。

この項には次のトピックが含まれます:

- 第2.4.2.1項「エンティティの新規作成」

- 第2.4.2.2項「その他のエンティティ・プロパティについて」

- 第2.4.2.3項「エンティティ・キーの追加」

2.4.2.1 エンティティの新規作成

新しいエンティティを作成する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「エンティティ」フォルダを右クリックし、「新規エンティティ」を選択します。「ラベルの表示」で名前としてCustomerと入力し、「OK」をクリックします。エンティティ・エディタが表示されます。「説明」でCustomer entityと入力します。
エンティティ属性の適切な説明であることが非常に重要です。それぞれのエンティティに適切な説明を追加してください。

注意:

オブジェクトIDはJava命名規約に準拠するように自動的に作成されます。変数名は大文字と小文字が混在し、最初の1文字は小文字になります。クラス名は大文字と小文字が混在し、最初の1文字は大文字になります。ラベル名に空白が含まれている場合、オブジェクトIDの作成時に空白は削除されます。

オブジェクトのラベルとそのオブジェクトIDとの間で表示を切り替えるには、「インライン・サービス・エクスプローラ」のタスク・バーにある「トグル」アイコンを使用します。

2. 「インポート」をクリックして、Customer Data Sourceから属性名とデータ型をインポートします。「選択したデータ・ソースのデータ・マッピングのビルド」オプションは選択したままにします。

3. 「定義」タブの「デフォルト値」列で、クリックして挿入ポイントを取得し、表2-2に一覧表示されている各属性のデフォルト値を追加します。Stringデータ型の値は、自動的に二重引用符で囲まれます。

表2-2 「定義」タブの「デフォルト値」列の属性

名前

型

デフォルト値

Age

Integer

35

HasCreditProtection

String

No

Language

String

English

LastStatementBalance

Double

1000

MaritalStatus

String

Single

NumberOfChildren

Integer

0

Occupation

String

Student

2.4.2.2 その他のエンティティ・プロパティについて

エンティティの属性に関するその他の設定も変更できます。たとえば、より複雑なインライン・サービスでは、属性のカテゴリを定義できます。これを定義するには、カテゴリ要素を作成し、属性の「プロパティ」で「カテゴリ」を使用してこれを割り当てます。属性のプロパティを表示するには、「定義」タブの属性を選択し、右クリックしてメニューから「プロパティ」を選択します。

学習に属性を使用しないように指定することもできます。インライン・サービスでカスタム・ロジックに属性を使用するが、属性をモデル入力として直接使用しない場合がこれに該当します。より具体的な例として、顧客の電話番号がある場合、電話番号を分析しても意味がありません。このような場合には、「分析に使用」の選択を解除してください。

デシジョン・センターに属性を表示するかどうか制御するには、「デシジョン・センターで表示」オプションを使用します。これは、属性が技術的な意味を持つだけで、ビジネス上の直接的な意味または関心を引くような意味がない場合に便利です。

2.4.2.3 エンティティ・キーの追加

エンティティ・オブジェクトを完全にデータ・ソースにマップするには、エンティティ属性をデータ・ソースのキー値にマップして、マッピングを完了する必要があります。その手順は次のとおりです。

1. Customerエンティティの「定義」タブで、「キーの追加」をクリックしてキー属性を追加します。「キーの追加」が表示されます。「ラベルの表示」にcustomerIdを表示どおりに入力します(この入力は大文字と小文字が区別されます)。キー値の説明を追加し、データ型を「Integer」に変更して「OK」をクリックします。

2. 「ファイル」→「すべて保存」を選択して、作業内容を保存します。「問題」ビューにいくつかエラーが表示される場合があります。これは、 Customerエンティティの属性とそのデータ・ソースとの間のマッピング定義が不完全であるためです。次のセクションに進んで、マッピング定義を完了してください。

2.5 セッション・エンティティについて

セッションは、プロセスのユニットのランタイム・データの基礎になります。セッションの期間中、データはメモリーに格納されます。エンティティに関するデータを追跡するには、これをOracle RTDフレームワークの一部であるセッション・エンティティに関連付けます。エンティティをセッションに関連付けるには、これをセッション・エンティティの属性にします。セッションに対するキーが選択されます。そのキーの固有のインスタンスが検出されると、セッションが開始されます。たとえば、Oracle RTDで追跡されるコール・センター・プロセスを考えます。セッションには、通話者とエージェントを表すエンティティが含まれます。セッション(この場合は通話)の期間中、これらのエンティティで定義されたデータおよびそれらの相互作用はメモリーに格納され、分析および意思決定に使用できます。

この項には次のトピックが含まれます:

- 第2.5.1項「セッション・エンティティへの属性の追加」

- 第2.5.2項「セッション・キーの作成」

- 第2.5.3項「データ・ソースへのエンティティのマッピング」

2.5.1 セッション・エンティティへの属性の追加

セッション・エンティティへ属性を追加する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「エンティティ」の下の「セッション」をダブルクリックします。

2. 「定義」タブで「属性の追加」をクリックします。「ラベルの表示」で属性名としてcustomerと入力し、「説明」を追加します。最初のデータ型はStringです。これは、次の手順で変更します。

3. 「データ型」で「その他」を選択します。「タイプ」選択ダイアログが表示されます。「エンティティ・タイプ」で「Customer」を選択します。「OK」をクリックします。

2.5.2 セッション・キーの作成

セッション・キーを作成する手順は次のとおりです。

1. 「依存エンティティのセッション・キー」で「選択」をクリックします。

2. ツリーを展開し、セッションに関連付けられたすべてのエンティティのキーを表示します。「customer」を開き、ボックスを選択することにより「customerId」をセッション・キーとして選択します。「OK」をクリックします。

ヒント:

Oracle RTDでは、異なるシステムが同一のインライン・サービスにインフォーマントとアドバイザを送信する場合にセッションを追跡できるよう、複数のセッション・キーをサポートしています。このチュートリアルおよび実際の多くのインストールでは、必要なセッション・キーは1つのみです。

2.5.3 データ・ソースへのエンティティのマッピング

エンティティ・オブジェクト・エディタで定義したマッピングにより、CustomerエンティティをCustomer Data Sourceに関連付けます。Customerエンティティの属性とCustomer Data Sourceの出力列の間のマッピングは、これらの属性がCustomer Data Sourceからインポートされたときに自動的に行われました(詳細は、第2.4.2項「エンティティの追加」を参照)。ここで、CustomerエンティティのCustomer Data Sourceの入力列の値をマップする必要があります。

Customer Data Sourceの入力列値をマップする手順は次のとおりです。

1. Customerエンティティを開き、「マッピング」タブを選択します。エンティティ・エディタは、「E」アイコンで識別されます。

2. インポートを使用したので、Customer Data Source属性はすでにCustomerエンティティ属性にマップされています。属性Ageの場合、「ソース」の値はCustomer Data Source / Age(「オブジェクトIDの表示」アイコンが選択されている場合はCustomer Data Source.Age)のようになります。インポート後に属性を追加した場合、「ソース」の下の省略記号をクリックしてデータ・ソース属性を配置することで、これらがマップされます。

3. 「属性」表で、各データ・ソース(この場合は、Customer Data Source)の入力列の値を特定する必要があります。データ・ソースの入力列は、レコードを取得する際の識別子(SQL select文のWHERE句)です。Customer Data Sourceでは入力列は「ID」のみであるため、「マッピング」タブでは、「属性」表にある「データ・ソース入力値」表にエントリが1つのみ表示されます。このエントリの「入力値」セルで省略記号をクリックし、「値の編集」ダイアログを表示します。

4. このインライン・サービスでは、Customerエンティティのキーを選択します。「属性または変数」を選択します。「Customer」を開き、「customerId」を選択して「OK」をクリックします。

図2-2 ID列の「値の編集」ダイアログ

「図2-2 ID列の「値の編集」ダイアログ」の説明

5. 「ファイル」→「すべて保存」を選択して、インライン・サービスを保存します。

2.6 インフォーマントの追加

インフォーマントは、Real-Time Decision Serverにメッセージを送信できる統合点の一種で、プロセス内の特定のユニットに関する情報を含みます。この段階でインライン・サービスをテストするために、顧客の年齢を表示するテスト・インフォーマントを作成します。実際の命令文を表示して確認するには、インライン・サービスをReal-Time Decision Serverにデプロイし、インフォーマントをコールする必要があります。数値が返されれば、エンティティ、マッピングおよびデータ・ソースがすべて正しく構成されていることがわかります。

この項には次のトピックが含まれます:

- 第2.6.1項「インフォーマントの作成」

- 第2.6.2項「インフォーマントへのテスト・ロジックの追加」

2.6.1 インフォーマントの作成

インフォーマントを作成する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「統合点」に移動し、「インフォーマント」を選択します。右クリックし、メニューから「新規インフォーマント」を選択します。オブジェクト名としてTestingを指定し、「OK」をクリックします。

2. Testingインフォーマント・エディタで、「説明」に説明を追加します。

3. 「説明」の横にある「詳細」をクリックします。「デシジョン・センターで表示」を選択解除します。これにより、このインフォーマントがデシジョン・センターのビジネス・ユーザーに対して非表示になります。「OK」をクリックします。

2.6.2 インフォーマントへのテスト・ロジックの追加

インフォーマントへテスト・ロジックを追加する手順は次のとおりです。

1. Testingインフォーマント・エディタで、「リクエスト」タブを選択します。インフォーマントは、Iアイコンで識別されます。

2. セッション・キーを追加するには、「セッション・キー」の下の「選択」をクリックします。「Customer」から「customerId」を選択します。「OK」をクリックします。

注意:

デシジョン・スタジオでエンティティを構成すると、クラスが生成されます。生成されるクラスには、各属性のプロパティ、ゲッターおよびセッターがあります。

3. 「ロジック」タブを選択します。「ロジック」の下に次のスクリプトレットを追加します。

logInfo("Customer age = " + session().getCustomer().getAge() );

logInfoをコールすることにより、「テスト」ビューの「ログ」サブタブと、Oracle RTDがインストールされている管理対象サーバーのログ・ファイル(Enterprise Managerで確認可能)に情報を出力できます。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のサーバー側ログ・ファイルの検索と表示に関する項を参照してください。セッションを使用してCustomerオブジェクトにアクセスし、年齢属性の内容を取得します。

4. これでデプロイの準備が整いました。「ファイル」→「すべて保存」を選択して、構成を保存します。
図2-3は、Testingインフォーマントがコールされてセッションが作成される際、このインフォーマントがどのように顧客データにアクセスするのかを示します。

図2-3 Tutorialインライン・サービスのオブジェクト

「図2-3 Tutorialインライン・サービスのオブジェクト」の説明

2.7 インライン・サービスのテスト

インライン・サービスをテストするには、これをデプロイしてテスト・データを持つインフォーマントをコールし、「テスト」ビューを使用して結果を確認します。インフォーマントはコール元に値を返さないため、結果は「テスト」ビューの「ログ」タブに表示されます。

インライン・サービスをデプロイしてテストする手順は次のとおりです。

1. タスクバーの「デプロイ」アイコンをクリックして、インライン・サービスをデプロイします。

メニュー・アイテムの「プロジェクト」→「デプロイ」からでも、インライン・サービスをデプロイできます。

2. 「選択」をクリックして、デプロイ先となるサーバーを選択します。Real-Time Decision Serverの場所にデプロイします。これはデフォルトで、インストールのデフォルト構成と同様、localhostになります。第2.2項「デプロイおよびデシジョン・センターのセキュリティについて」の説明に従って、自分のユーザー名とパスワードを入力します。ドロップダウン・リストを使用して、デプロイの状態に「開発」を選択します。「アクティブ・セッション(テスト用として使用)の終了」を選択します。「デプロイ」をクリックします。
デプロイには10秒から数分かかります。デプロイが完了すると、「インライン・サービス・エクスプローラ」の下に「Tutorial deployed successfully」というメッセージが表示されます。

注意:

アクティブなセッションを終了するのは、最後にデプロイされたインライン・サービスに対してテストを実行するためです。アクティブなセッションがあり、その同じセッションID(この場合はcustomerId)を使用する場合、インフォーマントのテストは、以前にデプロイされたインライン・サービスに対して実行されます。現在アクティブなセッションを終了すると、使用されるセッションIDに関係なく、最後にデプロイされたインライン・サービスに対してテストが確実に実行されます。

3. 画面下部の「テスト」ビューで、テストする統合点として「Testing」を選択します。「customerId」フィールドに「7」と入力します。「送信」アイコンをクリックします。

注意:

デシジョン・スタジオを実行するホストとRTD Decision Serverがデプロイされているホストが異なる場合などに、RTD Decision Serverは、デフォルトでは、RTD Decision Serverのデプロイ先のホスト以外のホストからの統合点リクエストを防止します。この場合、インフォーマントを実行すると、「アントラステッド・ホスト」というエラーが発生する可能性があります。

これを解消するには、Oracle RTD MBeansを使用して、トラステッド・ホストのオプションを無効にするか、デシジョン・スタジオを実行するホストをトラステッド・クライアントとして指定します。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracleRTD→SDClusterPropertyManager→Clusterについてに関する項を参照してください。

4. 「テスト」ビューの「ログ」タブを選択し、結果を表示します。logInfoコマンドによるすべての出力がタイムスタンプ付きで表示されます。
結果は次のようになります。

Jun 18, 2010 3:59:09 PM Tutorial INFO: Customer age = 38

2.8 機能の追加

次に、通話に固有の情報を保持するエンティティを作成します。これは、顧客との相互作用の特性に関するコンテキスト情報です。このエンティティのデータは、インフォーマントから、あるいは計算によって取得され、データベースから取得されることはありません。最初に通話を表すエンティティを作成してから、通話からデータを収集するインフォーマントを作成します。

図2-4 セッション・エンティティ

「図2-4 セッション・エンティティ」の説明

このエンティティを使用して、通話理由ごとの通話の長さ、これらの通話を行う顧客の特徴など、通話理由に関連するファクタを調査します。インフォーマントにより収集された通話理由を収集および分析するため、自己学習分析モデルが追加され、レポートがデシジョン・センターに表示されます。

この項には次のトピックが含まれます:

- 第2.8.1項「Callエンティティの作成」

- 第2.8.2項「Call Beginインフォーマントの作成」

- 第2.8.3項「Service Completeインフォーマントの作成」

- 第2.8.4項「Call Endインフォーマントの作成」

- 第2.8.5項「インフォーマントのテスト」

2.8.1 Callエンティティの作成

Callエンティティを作成する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「エンティティ」フォルダを右クリックし、「新規エンティティ」を選択します。オブジェクト名としてCallを指定し、「OK」をクリックします。

2. 表2-3に一覧表示される属性ごとに、次の操作を行います。

- エンティティ・エディタの「定義」タブで、「属性の追加」をクリックします。「属性の追加」が表示されます。表の値を入力し、「OK」をクリックします。

- 「タイプ」をクリックします。ドロップダウン・リストを使用して、属性ごとに適切なデータ型を選択します。

表2-3 Callエンティティの属性

名前

型

agent

String

length

Integer

reason code

Integer

3. 「インライン・サービス・エクスプローラ」で、「エンティティ」の下の「セッション」をダブルクリックします。

4. 「定義」タブで「属性の追加」をクリックします。オブジェクト名としてcallを指定します。デフォルトの型はStringです。デフォルトの型は次の手順で変更します。

5. 「データ型」で「その他」を選択します。「タイプ」ダイアログ・ボックスで、「エンティティ・タイプ」を開き、型として「Call」を選択し、「OK」をクリックします。callの「説明」を追加します。「OK」をクリックします。

6. 「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。

2.8.2 Call Beginインフォーマントの作成

CRMアプリケーションによってコールされる3つのインフォーマント(Call Begin、Service CompleteおよびCall End)を作成します。1番目のCall Beginはセッションを開始します。このインフォーマントでは、後でより迅速にアクセスできるよう、オプションで特定のセッション属性値を事前にロードおよびキャッシュできます。たとえば、後で使用する顧客のプロファイル情報があり、データベースのコールまたはその他の制約によってこの情報のロードが遅くなることが予測される場合、この顧客のプロファイルを事前にロードしておくことができます。

セッションの属性値は必要に応じて自動的にロードされるため、事前にロードする必要はありません。たとえば、前述の項のTestingインフォーマントのように顧客の年齢を表示する場合、Real-Time Decision Serverでは自動的にセッションのCustomerエンティティ属性全体を移入し、Age値を返します。このTutorialインライン・サービスでは、Call Beginインフォーマントはセッションを開始するだけで、セッションの属性値を事前に移入することはありません。

Call Beginインフォーマントを作成する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「統合点」の下の「外部システム」フォルダを右クリックし、「新規外部システム」を選択します。「オブジェクト名」が表示されます。システム名としてIVRを指定し、「OK」をクリックします。要素の説明を入力します。このオブジェクトを保存します。

2. 「インライン・サービス・エクスプローラ」で、「統合点」の下の「インフォーマント」フォルダを右クリックし、「新規インフォーマント」を選択します。「オブジェクト名」が表示されます。インフォーマント名としてCall Beginを指定し、「OK」をクリックします。

3. インフォーマント・エディタを使用して、Call Beginの説明を入力します。

4. セッション・キーをCall Beginインフォーマントに追加するには、「リクエスト」タブの「セッション・キー」の横にある「選択」をクリックします。「customerId」を選択します。「OK」をクリックします。

5. さらに「リクエスト」タブで、「外部システム」ドロップダウン・リストから「IVR」を選択し、「順序」ボックスに1を入力します。「セッションの強制クローズ」は選択しないでください。「外部システム」および「順序」により、デシジョン・センターの統合マップ(詳細は、第4.8項「統合マップの表示」を参照)の表示レイアウトと順序が決定します。3つのインフォーマントの定義を終了してインライン・サービスをデプロイすると、デシジョン・センターの統合マップは図2-5のようになります。

図2-5デシジョン・センターの統合マップ

「図2-5デシジョン・センターの統合マップ」の説明

6. 「ロジック」タブで、次のコードを入力します。

/*
Prepopulate customer data during start of call even though the information may
not be used until much later. This is not explicitly necessary since the
server will automatically retrieve the information whenever logic in the
Inline Service needs it.
*/
//session().getCustomer().fill();
int CustomerID = session().getCustomer().getCustomerId();
logInfo("Integration Point - CallBegin: Start Session for customerID = " +
CustomerID);

7. 「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。

2.8.3 Service Completeインフォーマントの作成

2番目のインフォーマントは、通話を処理したエージェント、通話の長さ、顧客の通話理由など、通話情報についてレポートします。このインフォーマントは、コール・センター・エージェントが顧客のニーズに応えたとき、すなわちサービスが完了したときにCRMアプリケーションによってコールされます。このインフォーマントによって収集されるデータは、Callエンティティに移入されます。

Service Completeインフォーマントを作成する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「統合点」の下の「外部システム」フォルダを右クリックし、「新規外部システム」を選択します。「オブジェクト名」が表示されます。システム名としてCRMを指定し、「OK」をクリックします。要素の説明を入力します。このオブジェクトを保存します。

2. 「インライン・サービス・エクスプローラ」で、「統合点」の下の「インフォーマント」フォルダを右クリックし、「新規インフォーマント」を選択します。「オブジェクト名」が表示されます。インフォーマント名としてService Completeを指定し、「OK」をクリックします。

3. インフォーマント・エディタを使用して、Service Completeの説明を入力します。

4. セッション・キーをService Completeインフォーマントに追加するには、「リクエスト」タブの「セッション・キー」の横にある「選択」をクリックします。「customerId」を選択し、「OK」をクリックします。

5. さらに「リクエスト」タブで、「外部システム」ドロップダウン・リストから「CRM」を選択し、「順序」ボックスに2を入力します。「セッションの強制クローズ」は選択しないでください。

6. インフォーマントにデータを追加するには、表2-4に一覧表示された入力パラメータごとに、次の操作を行います。

- インフォーマント・エディタの「リクエスト」タブで、「追加」をクリックします。名前を入力し、ドロップダウン・リストを使用してデータ型を選択します。「OK」をクリックします。

- 「セッション属性」の下で省略記号をクリックし、「割当て」を使用します。「セッション」フォルダを開いてから「call」を開き、入力項目に一致する通話属性を選択します。

表2-4 入力パラメータのデータ型とセッション属性

入力パラメータ名

型

セッション属性

agent

String

call / agent(「オブジェクトIDの表示」アイコンが選択されている場合はcall.agent)

length

Integer

call / length(「オブジェクトIDの表示」アイコンが選択されている場合はcall.length)

reason code

Integer

call / reason code(オブジェクトIDの表示が選択されている場合はcall.reason code)

7. 「ロジック」タブで、次のコードを入力します。

logInfo("Integration Point - Service Complete");
logInfo("  Reason Code: " + session().getCall().getReasonCode());
logInfo("  Agent: " + session().getCall().getAgent());
logInfo("  Call Length: " + session().getCall().getLength());

8. 「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。

2.8.4 Call Endインフォーマントの作成

3番目のインフォーマントではセッションを閉じます。これは、CRMアプリケーションからコールされる最後のインフォーマントとなります。このTutorialインライン・サービスでは、このインフォーマントをセッションを閉じるためだけに使用しますが、実際のシステムでは、さらに処理を実行したり、モデルの学習をトリガーしたりできます。

Call Endインフォーマントを作成する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「統合点」の下の「インフォーマント」フォルダを右クリックし、「新規インフォーマント」を選択します。「オブジェクト名」が表示されます。インフォーマント名としてCall Endを指定し、「OK」をクリックします。

2. インフォーマント・エディタを使用して、Call Endの説明を入力します。

3. セッション・キーをCall Endインフォーマントに追加するには、「リクエスト」タブの「セッション・キー」の横にある「選択」をクリックします。「customerId」を選択し、「OK」をクリックします。

4. さらに「リクエスト」タブで、「外部システム」ドロップダウン・リストから「CRM」を選択し、「順序」ボックスに5を入力します。「順序」を5に設定するのは、このチュートリアルの後半で、さらに2つの統合点(アドバイザともう1つのインフォーマント)を追加するためです。

5. オプションの「セッションの強制クローズ」が選択されていることを確認します。このオプションを選択している場合は、インフォーマントがコールされ、そのロジックが処理されると、明示的にそのセッションが閉じられます。明示的にセッションを閉じない場合は、一定の期間が経過した後、自動的に閉じられます。この期間はデフォルトでは30分ですが、Oracle RTD用のシステムMBeanブラウザを使用して変更できます。

6. 「ロジック」タブで、次のコードを入力します。

logInfo("Integration Point - CallEnd");
logInfo("***************************");

7. 「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。

図2-6は、3つのインフォーマントが同じセッションにアクセスして更新する方法を示しています。

図2-6 Tutorialインライン・サービスのオブジェクト: 統合点

「図2-6 Tutorialインライン・サービスのオブジェクト: 統合点」の説明

2.8.5 インフォーマントのテスト

ここで、作成した3つのインフォーマントをコールする簡単なシナリオをテストします。それぞれ、1) コールの開始、2) サービスの完了、3) コールの終了に対応します。「テスト」ビューを使用してインフォーマントをコールし、インフォーマントのロジック部分に配置したログ・メッセージを表示します。

インフォーマントをテストする手順は次のとおりです。

1. サーバーにデプロイします。タスクバーの「デプロイ」アイコンをクリックして、Tutorialインライン・サービスをデプロイします。

「アクティブ・セッション(テスト用として使用)の終了」を必ず選択してください。

2. デシジョン・スタジオの下部にある「テスト」ビューの「統合点」で「Call Begin」を選択します。リクエスト入力の「customerId」に、たとえば「7」などの整数値を入力します。「送信」アイコンをクリックし、リクエストをサーバーに送信します。

「テスト」ビュー内の「ログ」タブに、Call Begin統合点がコールされたことを示すメッセージが表示されます。

3. 他の2つの統合点(Service CompleteおよびCall End)についても、表2-5に示す入力値でこの処理を順番に繰り返します。表2-5には、「ログ」タブの表示例も示されています。

表2-5 統合点の入力値およびログ結果

統合点

リクエスト入力

「ログ」タブ

Call Begin

customerId: 7

09:15:41,753 Integration Point - CallBegin:
Start Session for customerID = 7

Service Complete

customerId: 7

agent: John

length: 21

reason code: 18

09:17:51,845 Integration Point - Service
Complete
09:17:51,845 Reason Code: 18
09:17:51,845 Agent: John
09:17:51,845 Call Length: 21

Call End

customerId: 7

09:20:17,342 Integration Point - CallEnd
09:20:17,342 ***************************

インフォーマントは任意の順序でコールできます。セッションの開始にCall Beginインフォーマントは必要なく、セッションの終了にCall Endは必要ありません。Service Completeインフォーマントのみをコールした場合、セッションは正常に開始され、応答も同様に返されますが、セッションは開いたままとなります。このチュートリアルで操作する3つのインフォーマントは、Real-Time Decision Serverに対してコールを実行できる、コール・センター・プロセスの異なる場所を示しています。

ヒント:

コンパイルでエラーが生じた場合は、デシジョン・スタジオのダイアログにより、「問題」ビューにこれらのエラーが表示されます。エラーをダブルクリックすると、エラーのある要素のエディタが開きます。

通信しているサーバーがlocalhostであることを確認してください。デシジョン・スタジオでは、以前入力した値がドロップダウンに保持されるため、デフォルトがlocalhostではない場合があります。

2.9 通話理由の分析

前述の項では3つのインフォーマントを作成しました。その2番目のインフォーマントService Completeでは、通話情報をCRMアプリケーションからReal-Time Decision Serverに送信します。通話情報の1つは通話理由、つまり顧客がなぜ通話したのかということです。この項では、選択肢およびモデルを使用して、登録された通話理由を分析します。通話理由に関する基本的なレポート(記録された理由の数、それぞれの通話理由とセッション属性の間に相関関係があるのか、それはどのような相関関係か)を表示できるようにすることが目的です。

この項には次のトピックが含まれます:

- 第2.9.1項「分析のための選択肢の使用について」

- 第2.9.2項「選択肢グループの追加」

- 第2.9.3項「分析モデルの追加」

- 第2.9.4項「選択肢の選択のためのロジックの追加」

- 第2.9.5項「全体のテスト」

2.9.1 分析のための選択肢の使用について

選択肢は、分析の対象の作成に使用されます。ここでは最初に通話理由の分析に焦点を当てます。まず、通話理由の選択肢グループを作成します。次に、この選択肢グループcodeの属性を定義します。このグループ内で作成される個々の選択肢は、値はそれぞれ異なりますが、この属性定義を継承します。

図2-7 通話データの分析

「図2-7 通話データの分析」の説明

2.9.2 選択肢グループの追加

選択肢グループを追加する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「サーバー・メタデータ」の下の「選択肢」フォルダを右クリックし、「新規選択肢グループ」を選択します。グループ名としてCall Reasonを指定し、「OK」をクリックします。説明を追加します。

2. Call Reason選択肢グループ・エディタの「選択肢属性」タブで、「属性」表の横にある「追加」をクリックします。「ラベルの表示」に、codeと入力します。データ型に「Integer」を選択してから、「オーバーライド可能」を選択します。Choice codesという説明を追加し、「OK」をクリックします。

注意:

グループ属性に対して、これを選択肢属性としました。この2つの違いは、選択肢属性では階層の各選択肢に対して値が与えられるのに対し、グループ属性は現在のグループに対してのみ与えられるという点です。

3. グループの下に選択肢を作成するには、「インライン・サービス・エクスプローラ」で選択肢グループ「Call Reason」」を右クリックし、「新規選択肢」を選択します。Check Balanceという選択肢を追加します。
Make Payment、Rate Inquiry、Otherの各選択肢について、この手順を繰り返します。それぞれの説明を追加します。

4. 「インライン・サービス・エクスプローラ」で、「選択肢」の下の「Call Reason」グループを開き、各選択肢を表示します。

図2-8 「インライン・サービス・エクスプローラ」内の通話理由

「図2-8 「インライン・サービス・エクスプローラ」内の通話理由」の説明

5. 4つの選択肢のそれぞれについて、「インライン・サービス・エクスプローラ」で「選択肢」を選択します。その選択肢のエディタの「属性値」タブで、code属性に対して、表2-6に示すとおりに「属性値」を設定します。

表2-6 Call Reasonの選択肢のコード属性値

選択肢

属性値

Check Balance

17

Make Payment

18

Other

20

Rate Inquiry

19

6. 「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。

2.9.3 分析モデルの追加

自己学習分析モデルが作成され、通話理由の自動分析が行われます。このモデルは各通話理由を追跡し、すべてのセッション属性をこれらの結果と関連付けます。デシジョン・センターでは、このモデルを使用してレポートを作成します。

分析モデルを追加する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「サーバー・メタデータ」の下の「モデル」フォルダを右クリックし、「新規選択肢モデル」を選択します。モデル名としてReason Analysisを指定し、「OK」をクリックします。選択肢イベント・モデルではなく選択肢モデルを作成してください。

2. 「予測に使用」を選択解除します。

3. 分析の対象がchoiceモデル属性であることを示すには、「選択肢」タブを選択し、「選択肢グループ」ドロップダウン・リストから「Call Reason」を選択します。

4. 「場所の学習」タブを選択してから、「統合点」を選択します。

5. 「選択」をクリックしてからサービス完了を選択し、「OK」をクリックします。

6. 「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。

2.9.4 選択肢の選択のためのロジックの追加

Service Completeインフォーマントを受け取ったら、該当する通話理由を示す選択肢を選択する必要があります。これを行うには、選択肢モデルのメソッドaddToChoiceを使用して、モデルの選択肢配列に理由を追加します。

モデルの選択肢配列に理由を追加する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「統合点」を展開します。「インフォーマント」の下のサービス完了をダブルクリックします。

2. 「ロジック」タブを選択し、次のロジックを入力します。これにより、通話理由を示す選択肢のオブジェクトIDがモデルに追加されます。

logInfo ("Integration Point - Service Complete. ");
logInfo ("  Reason Code: " + session().getCall().getReasonCode());
logInfo ("  Agent: " + session().getCall().getAgent());
logInfo ("  Length: " + session().getCall().getLength());

int code=session().getCall().getReasonCode();
switch (code) {
case 17:
ReasonAnalysis.addToChoice("CheckBalance");
logInfo ("  CheckBalance was added to the model");
break;
case 18:
ReasonAnalysis.addToChoice("MakePayment");
logInfo ("  MakePayment was added to the model");
break;
case 19:
ReasonAnalysis.addToChoice("RateInquiry");
logInfo ("  RateInquiry was added to the model");
break;
default:
ReasonAnalysis.addToChoice("Other");
logInfo ("  Other was added to the model");
break;
}

3. 「ファイル」→「すべて保存」を選択して、構成を保存します。

図2-9は、Service Completeインフォーマントがコールされると、Reason Analysisモデルがどのように更新されるかを示しています。

図2-9 Tutorialインライン・サービスのオブジェクト

「図2-9 Tutorialインライン・サービスのオブジェクト」の説明

2.9.5 全体のテスト

構成のすべての部分をテストする手順は次のとおりです。

1. 構成をサーバーにデプロイします。デプロイまたはコンパイルにエラーがないことを確認します。

2. 「テスト」ビューを使用して統合点をテストします。「Service Complete」を選択し、各引数の値をcustomerId=7、agent=John、length=21、reasonCode=18と設定します。

3. 「送信」をクリックします。次のような結果が表示されます。

13:57:29,794 Integration Point - Service Complete.
13:57:29,794   Reason Code: 18
13:57:29,794   Agent: John
13:57:29,794   Length: 21
13:57:29,794   MakePayment was added to the model

表示された入力値でインフォーマントがコールされると、そのセッションの属性であるCallエンティティに、エージェント、通話長および理由コードについての情報が移入されます。次にインフォーマント・ロジックは、理由コードが18なので、選択肢Make PaymentがReason Analysisモデルに追加されると判断します。つまり、選択肢Make Paymentのカウントが1増加します。カウントとともに、モデルはすべてのセッション属性および選択肢との相関関係も追跡します。

4. 値を変更し、数回テストして、その他の理由コードの場合でも正しいオブジェクトIDがモデルに追加されることを確認します。

3 インライン・サービスに対する負荷のシミュレート

この章のチュートリアルでは、ロード・ジェネレータを使用してシステムのランタイム操作をシミュレートする手順について説明します。

一般的にロード・ジェネレータは、次の3つの目的で使用されます。

- パフォーマンスのチェック: 負荷がかかったときのシステムのパフォーマンスを検証します。レスポンス時間を測定したり、バックエンド・データの入力時などにおいてシステム全体が想定負荷に対応できることを確認します。

- 初期化: 重要なデータを使用して、デモ目的で学習機能および統計機能を初期化します。

- データ処理: オフラインのバッチ・ソースを処理します。たとえば、プロジェクトの初期段階に、以前に収集したデータの分析を行います。

この章には次のトピックが含まれます:

- 第3.1項「負荷下のパフォーマンス」

- 第3.2項「モデルの学習内容のリセット」

3.1 負荷下のパフォーマンス

負荷がかかったときのパフォーマンスを評価するために、インライン・サービスに定義されている統合点(Begin Call、Service CompleteおよびCall End)をコールする負荷シミュレーション・スクリプトを作成します。スクリプトでは、顧客ID、通話理由コード、エージェント名および通話の長さを毎回変えて、これら3つの連続する統合点を複数回コールします。この反復実行ごとにReason Analysisモデルで学習が行われ、その分析結果をデシジョン・センター・レポートにおいて参照できます。

このチュートリアルでは、ロード・ジェネレータをCRMアプリケーションのシミュレーション・プログラムとして扱い、Real-Time Decision Serverに対して統合点のコールを反復実行します。作成するロード・ジェネレータ・スクリプト(xmlファイルとして保存)には、このシミュレーションの定義が記述されます。

注意:

ロード・ジェネレータ・スクリプトを定義するときは、インライン・サービス・オブジェクトへのすべての参照を、ラベルではなく、オブジェクトIDの形式で記述する必要があります。StudioでオブジェクトIDを表示するには、「インライン・サービス・エクスプローラ」タスクバーにあるオブジェクトID用「トグル」アイコンを使用します。

たとえば、Service CompleteインフォーマントのIDはServiceCompleteで、reason codeインフォーマント・パラメータのIDはreasonCodeです。他も同様です。

この項には次のトピックが含まれます:

- 第3.1.1項「ロード・ジェネレータ・スクリプトの作成」

- 第3.1.2項「デシジョン・センターにおける分析結果の表示」

- 第3.1.3項「属性の除外」

3.1.1 ロード・ジェネレータ・スクリプトの作成

注意:

ロード・ジェネレータなどのクライアント側ツールを実行するには、JAVA_HOMEを設定する必要があります。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle RTDクライアント・ツールに必要なJava Development Kitのインストールに関する項を参照してください。

ロード・ジェネレータ・スクリプトを作成する手順は次のとおりです。

1. RTD_HOME\scripts\loadgen.cmdを実行することで、ロード・ジェネレータを開きます。次に、「新規ロード・ジェネレータ・スクリプトを作成します」をクリックします。
[F1]キーを押すと、ロード・ジェネレータのオンライン・ヘルプを参照できます。オンライン・ヘルプでは、このチュートリアルに説明されていないパラメータが説明されています。

2. 「一般」タブを選択し、表3-1に示されているパラメータの値を入力します。

表3-1 「一般」タブのパラメータ

パラメータ名

説明

値

クライアント構成ファイル

サーバーとの通信に使用するプロトコル、接続先サーバーおよび使用するポートを指定するプロパティ・ファイル。デフォルトでは、HTTPを使用して、ローカル・サーバーとポート8080で通信します。ファイル内のHTTP1.urlパラメータを、使用するRTDサーバーとポートの値に更新してください。たとえば、http://wlsserver1.company.com:9704など。

RTD_HOME\client\clientHttp
EndPoints.properties

グラフ・リフレッシュ間隔(秒)

このパラメータはユーザー・インタフェースにのみ影響します。このパラメータにより、UI上のグラフおよびカウンタのリフレッシュ間隔を指定します。デフォルトは2秒間隔のリフレッシュです。

2

インライン・サービス

前の項で作成したインライン・サービスに割り当てた名前。

Tutorial

ランダム数値ジェネレータ・シード

ランダムな数値の生成に使用するシード。デフォルトは-1です。

-1

思考時間

複数のトランザクション間における時間。セッション指向の負荷シミュレーションでは、必要に応じて異なる値を指定します。このチュートリアルでは、可能なかぎり多くのセッションを送信し、最大スループットを調べます。思考時間のタイプは、「固定グローバル思考時間」または「範囲指定されたグローバル思考時間」のいずれかです。

グローバルな思考時間を指定する固定値

定数

思考時間のタイプを「固定グローバル思考時間」に設定した場合、パラメータ「定数」が表示されます。これはトランザクション間の待機時間(秒数)です。「0」の場合、RTD Decision Serverが統合点リクエストを処理可能になり次第、ロード・ジェネレータはただちにリクエストをDecision Serverに送信する必要があることを意味します。

0

実行する同時スクリプトの数

並行して実行することで、同時にアクティブになるセッションの数。このシミュレーションでは、一度に1セッションのみを実行します。

1

実行するスクリプトの最大数

作成されるセッションの合計数。この数値に達した時点で、イベントの送信が停止します。

2000

ロギングの有効化

loadgenカウンタ・ログを有効化/無効化するオプション。このログには、loadgenのパフォーマンス・データ(ロード・ジェネレータによって送信されたリクエストの数、エラーの数、リクエストの平均レスポンス時間およびピーク時のレスポンス時間など)の履歴が記録されます。このチェック・ボックスの選択が解除されている場合は、残りの3つのログ関連パラメータ(「既存のファイルへ追加」、「ログ・ファイル」および「ロギング間隔」)は無視されます。

選択解除

既存のファイルへ追加

loadgenスクリプトを実行するたびに既存のログ・ファイルを上書きするか追加するかを指定するオプション。

選択解除

ログ・ファイル

asciiファイルへのファイル・パス。ロード・ジェネレータのログが、タブ区切りの書式で書き込まれる場所です。

RTD_HOME\log\loadgen.csv

ロギング間隔

このパラメータはロード・ジェネレータのログにのみ影響します。このパラメータにより、ログへの書込み間隔を指定します。デフォルトは10秒です。

10

パス名内のRTD_HOMEは、Oracle RTDクライアント側ツールがインストールされている場所に置き換えてください。

セッションに関連するパラメータは、実行中に変更できないことに注意してください。正確に言うと変更は可能ですが、ロード・ジェネレータ・スクリプトが停止して再起動されるまで、変更は実行に影響しません。

3. 構成を保存します。ファイルをインライン・サービスのプロジェクト・フォルダ内にあるetcフォルダに保存することにより、インライン・サービスに対して作成したLoadgenスクリプトを同じプロジェクトにバンドルできます。Tutorialインライン・サービスをデフォルトのワークスペースに作成した場合、このパスはC:\Documents and Settings\Win_User\Oracle RTD Studio\Tutorial\etcのようになります。スクリプト(xmlファイル)に任意の名前を付けます(たとえば、TutorialLoadgen.xmlなど)。

4. 統合点に対するパラメータの値を定義するには、「変数」タブをクリックします。「変数」タブにより、統合点の各パラメータ値を、それぞれ異なるソースから取得できます。

注意:

すべてのツリーが左側に表示されていない場合があります。すべてのツリーを表示するには、バーをドラッグして、2つの領域に分割します。

5. 「スクリプト」フォルダを右クリックし、「変数の追加」を選択します。名前をvar_customerIdにします。「コンテンツ」で、「整数範囲」を選択し、1から2000までの順次実行を指定します。この定義によって、各セッションで一度処理され、1から2000まで順次実行される変数が作成されます。したがって、最初のセッションではvar_customerId = 1となり、最後のセッションでは2000となります。「スクリプト」を右クリックし、「変数の追加」をさらに3回選択して、表3-2に示すように4つの変数を定義します。

表3-2ロード・ジェネレータ・スクリプトの変数の名前と値

パラメータ名

コンテンツ・タイプ

値

var_customerId

整数値の範囲

最小 = 1、最大 = 2000、アクセス・タイプ = 順次

var_reasonCode

整数値の範囲

最小 = 17、最大 = 20、アクセス・タイプ = ランダム

var_agent

文字列配列

文字列を配列に追加するには、表領域を右クリックし、「項目の追加」を選択します。次に、新しく作成された行を選択(ダブルクリック)してカーソルを取得し、使用する名前を入力します。[Enter]キーを押して、新しい行の値を登録します。エージェント名として、いくつかのサンプル値(John、Peter、Mary、Saraなど)を追加します。

var_length

整数値の範囲

最小 = 75、最大 = 567、アクセス・タイプ = 順次

この値は秒単位で、通話の長さとして使用されます。

6. 「スクリプトの編集」タブを選択し、左側の領域を右クリックして「アクションの追加」を選択します。それぞれが1つの統合点に対応する3つのアクションを追加します。アクションは適切な順序(つまりCallBegin、ServiceComplete、CallEndの順)にする必要があります。

7. 最初のアクションに対して、タイプを「メッセージ」に、統合点の名前をCallBeginにそれぞれ設定します。「入力フィールド」で右クリックして「項目の追加」を選択し、入力フィールドを追加します。「名前」の下のスペースをダブルクリックして値customerIdを入力し、[Enter]を押して新しい値を登録します。customerIdに対応する「変数」列で、ドロップダウン・リストから「var_customerId」を選択します。「セッション・キー」を選択し、このフィールドをセッション・キーとして指定します。

8. ServiceCompleteアクションに対して、表3-3に示されているように、3つのフィールドを追加します。

表3-3 ServiceComplete用の追加入力フィールド

名前

変数

reasonCode

var_reasonCode

agent

var_agent

length

var_length

フィールド名は、デシジョン・スタジオに表示されるServiceCompleteインフォーマントの入力パラメータIDと完全に一致する必要があります。オブジェクトのラベルとそのオブジェクトIDとの間における表示を切り替えるには、デシジョン・スタジオの「インライン・サービス・エクスプローラ」タスク・バーにある「トグル」アイコンを使用します。

図3-1は、ServiceComplete用に設定が完了した「入力フィールド」セクションを示しています。

図3-1 ServiceComplete用の入力フィールド

「図3-1 ServiceComplete用の入力フィールド」の説明

9. 「スクリプトの編集」タブで、左側の領域を右クリックして「アクションの追加」を選択します。タイプを「メッセージ」に、統合点の名前をCallEndにそれぞれ設定します。「入力フィールド」で右クリックして「項目の追加」を選択し、入力フィールドを追加します。「名前」をcustomerIdに、「変数」をvar_customerIdにそれぞれ設定し、「セッション・キー」を選択します。

10. 「セキュリティ」タブで、「ユーザー名」と「パスワード」を入力します。

11. 再びロード・ジェネレータ構成スクリプトを保存します。この時点で、ロード・ジェネレータ・スクリプトに、3つの統合点へのコールが定義されます。「スクリプトの編集」タブにおけるアクションの順序が正しいこと(つまり、CallBegin、ServiceComplete、CallEndの順になっていること)を確認します。この順序でない場合は、各アクションを右クリックして、上下に移動します。スクリプトを再び保存します。

12. 「実行」タブに移動し、「再生」ボタンを押します。ロード・ジェネレータにおいてスクリプトの実行が完了するまで待ちます。

「一時停止」ボタンと「停止」ボタンがあることに注意してください。両者の違いは、「一時停止」では順次実行が記憶され一時停止した箇所から再開するのに対して、「停止」では完全にリセットされる点にあります。

ヒント:

問題が発生した場合、「実行」タブの「エラー合計」を調べます。この値が0よりも大きい場合は、クライアント側とサーバー側のログ・ファイルを調べます。ログ・ファイルに問題の内容が記録されている場合があります。

クライアント側のログは、ディレクトリRTD_HOME\logにあります。例: RTD_HOME\log\client.log.0

サーバー側のメッセージへのアクセス方法は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のサーバー側ログ・ファイルの検索と表示に関する項を参照してください。

サーバー側のメッセージは、WebLogic Serverの診断ファイルに記録されています。例: <mw_home>\user_projects\domains\bifoundation_domain\servers\bi_server1\logs\bi_server1-diagnostic.log

一般的な間違いは次のとおりです。

- インライン・サービスがデプロイされていない。

- インライン・サービスや統合点の名前に、スペルの間違いや大文字と小文字の間違いがある。

- サーバーが実行していない。

「リクエスト合計」の値が1から増えていない場合、loadgenスクリプトの定義に間違いがある可能性があります。次の点を調べてください。

- 「整数範囲」の変数で、最小値が最大値よりも小さいこと。

- メッセージで送信される変数への値のマッピングが正しいこと。たとえば、変数名を変更した場合は、そのマッピングをやりなおす必要があります。

- クライアント構成ファイルが正しいこと。

3.1.2 デシジョン・センターにおける分析結果の表示

ロード・ジェネレータの実行後に、デシジョン・センターを使用すると、モデルの学習結果を参照できます。その手順は次のとおりです。

1. Webブラウザを起動してURLにhttp://server_name:9704/uiを指定して、デシジョン・センターを起動します。第2.2項「デプロイおよびデシジョン・センターのセキュリティについて」に説明されているように、提供されているユーザー名とパスワードを使用してログインします。

2. 「インライン・サービスを開く」をクリックします。「インライン・サービスの選択」ウィンドウが表示されます。「Tutorial」を選択し、「Call Reason」を展開して「Make Payment」などの選択肢を1つ選択します。右側のペインで、「分析」タブ→「最適」サブタブにナビゲートします。このレポートには、この通話理由が該当した回数と、このコール理由と各属性値間の相関関係に関する要約がそれぞれ記載されます。
興味深いデータが表示されます。図3-2に示されているように、call reason codeとMake Paymentとの間に、予想外に強い相関関係があります。

図3-2 Make Paymentと相関関係がある属性の値

「図3-2 Make Paymentと相関関係がある属性の値」の説明

通話データはロード・ジェネレータ変数によってランダムに生成されているため、強い相関関係は想定範囲にありません。ただし、ここでは、通話理由コード(ServiceCompleteインフォーマントによって送信される)が、この通話理由に大きく関係しています(ロジックの詳細は、第2.9.5項「全体のテスト」を参照)。

この誘発的な相関関係を解消するには、この属性がモデルへの入力として使用されないように除外します。モデルから除外する属性の別のタイプとして、顧客の電話番号があります。個々の電話番号と通話理由との間には、特定の相関関係が存在する可能性は低いです。一方、顧客の地域コードと通話理由との間には相関関係が存在する場合があるため、この属性はモデルから除外しません。次の項では、通話理由コードの属性をモデルから除外し、ロード・ジェネレータ・スクリプトを再び実行します。

3.1.3 属性の除外

reason code属性を除外する手順は次のとおりです。

1. デシジョン・スタジオで、Tutorialプロジェクトを開きます。

2. 「インライン・サービス・エクスプローラ」から「サーバー・メタデータ」→「モデル」 を開き、「Reason Analysis」をダブルクリックします。

3. 「属性」タブに移動します。下側にある表(表のタイトルは「除外された属性」)で、「選択」をクリックし除外する属性を選択します。「セッション」ノード→「call」エンティティを開き、「reason code」を選択します。「OK」をクリックします。

4. すべてを保存し、localhostサーバーに再デプロイします。

5. ロード・ジェネレータ・スクリプトを再び実行できます。

再実行後にデシジョン・センターを使用してカウントの値を調べると、ロード・ジェネレータを2回実行したときのイベントが含まれています。これは、ロード・ジェネレータ・スクリプトを属性除外前に実行してから属性除外後に実行する前にモデルをリセットしていないためです。

3.2 モデルの学習内容のリセット

次に示すように、モデルの学習内容をリセットするには、Enterprise Managerを使用します。

1. 自分のユーザー名とパスワードを使用してEnterprise Managerにログインします。

2. 左側のナビゲーション・ペインで、「アプリケーションのデプロイ」エントリを開いて、「OracleRTD」を表示します。

3. 「OracleRTD」エントリを右クリックして「システムMBeanブラウザ」を選択します。

4. 表示される「システムMBeanブラウザ」ナビゲーション・ペインで、「アプリケーション定義のMBean」まで下にスクロールします。

5. 「アプリケーション定義のMBean」の下の「OracleRTD」を開き、Oracle RTDがデプロイされているサーバーを開きます。

6. 「InlineServiceManager」を開き、「Tutorial.Development」エントリを選択します。

7. 「操作」タブをクリックし、deleteAllOperationalData操作を使用して、このインライン・サービスのすべての操作データを、スタディも含めて削除します。

8. 新しい分析結果をデシジョン・センターで参照するために、ロード・ジェネレータ・スクリプトを再び実行します。

3.2.1 インライン・サービスの要約

これまで、単純ですが完全な機能を持つインライン・サービスを作成しました。それには、データ環境、データ・ソースおよび顧客エンティティの定義から始めて、現在の通話データのエンティティを定義しました。基本的な機能をテストした後、分析実行用の統合点とモデルを作成しました。顧客の通話理由を調べて通話理由の発生回数を記録するロジックを、モデルに分析目的で追加しました。次に、ロード・ジェネレータを使用して、Real-Time Decision ServerおよびTutorialインライン・サービスに対するリクエストをシミュレートしました。最後に、結果をデシジョン・センターに表示しました。

4 コール・センターのインライン・サービスの機能拡張

チュートリアルのこの章では、インライン・サービスの各要素(特に、パフォーマンス目標、スコアリング・ルール、アドバイザおよびデシジョン)を作成および構成する手順について説明します。これらの要素を組み合せることにより、顧客に対する最適なオファーをOracle RTDが提案できるようになります。

第2章では、クレジット・カード会社のコール・センターにおける通話理由に関連する入力データを追跡して分析するインライン・サービスを作成しました。第3章では、ロード・ジェネレータを使用して、インライン・サービスへのクライアント・リクエスト(インフォーマントのコールを介したリクエスト)をシミュレートしました。

この章では、Tutorialインライン・サービスを拡張して、抱合せ販売のアドバイスをCRMアプリケーションに提供します。ここでは、エージェントが顧客からの通話を通常の方法(Service Completeインフォーマントのコール)で処理した後で、その機会を利用して顧客にオファーを提示するように、プロセスを拡張します。第5章では、オファーに対する顧客のレスポンスを追跡し、レスポンスから学習した内容を別の顧客へのオファー提示に活用します。

この章には次のトピックが含まれます:

- 第4.1項「選択肢グループの使用と抱合せ販売へのスコアリングについて」

- 第4.2項「選択肢グループによるオファー(抱合せ販売)インベントリの作成」

- 第4.3項「パフォーマンス目標の構成」

- 第4.4項「選択肢のスコアリング」

- 第4.5項「アドバイザについて」

- 第4.6項「デシジョンの作成」

- 第4.7項「アドバイザの作成」

- 第4.8項「統合マップの表示」

- 第4.9項「アドバイザのテスト」

4.1 選択肢グループの使用と抱合せ販売へのスコアリングについて

このチュートリアルでは、クレジット・カード・サービス・センターへの通話者に対して提示できるオファーの選択肢グループを作成します。コストを最小化するパフォーマンス・メトリックをサポートできるように、選択肢のスコアはコスト・ベースにします。次に、アドバイザを作成して抱合せ販売提案をCRMアプリケーションに渡します。これによって、コール・センター・エージェントがオファーを提示できるようになります。

図4-1 抱合せ販売のオファー

「図4-1 抱合せ販売のオファー」の説明

4.2 選択肢グループによるオファー(抱合せ販売)インベントリの作成

選択肢グループを使用してオファー(抱合せ販売)インベントリを作成する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「選択肢」フォルダを右クリックし、「新規選択肢グループ」を選択します。グループ名にCross Selling Offerを指定し、「OK」をクリックします。

2. 「選択肢」を開き、新しく作成したグループを選択して開きます。説明を追加します。

3. 「選択肢属性」タブで、「属性」表の横にある「追加」をクリックします。表4-1に示されている属性を追加し、「クライアントへ送信」と「オーバーライド可能」を選択します。

表4-1 「選択肢属性」タブの属性

属性名

データ型

クライアントへ送信

オーバーライド可能

Offer Description

String

選択済

選択済

URL

String

選択済

選択済

Agent Script

String

選択済

選択済

注意:

これらの属性はクライアント(コール・センター・エージェント)でのオファーの提案に必要なため、クライアントに送信されます。

属性の値は実際のオファーごとに異なるため、これらの属性は上書き可能である必要があります。抱合せ販売のオファー内容は、この選択肢グループ内の選択肢によって表されます。

実際のインライン・サービスでは、具体的なオファーが提示される前に、レベル分けされた選択肢グループが表示される場合があります。各選択肢グループはオファーの論理グループを表し、グループ内のオファーに一様に適用される属性やビジネス・ルールが存在する場合があります。

4. 「インライン・サービス・エクスプローラ」で、「選択肢」の下の「Cross Selling Offer」選択肢グループを選択し、表4-2に示すように、属性を持つ選択肢を5つ追加します。各選択肢を追加する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で「Cross Selling Offer」を右クリックし、「新規選択肢」を選択します。Credit Card、Savings Account、Life Insurance、Roth IRAおよびBrokerage Accountの5つの選択肢を追加します。

2. 「インライン・サービス・エクスプローラ」で、「選択肢」にある「Cross Selling Offer」グループを開き、各選択肢を表示します。各選択肢に対して、次の手順を実行して属性を追加します。

- 「インライン・サービス・エクスプローラ」で、「選択肢」を選択します。選択肢用のエディタで、説明を追加します。

- 「属性値」タブに、3つの属性「Agent Script」、「Offer Description」および「URL」が表示されます。「属性値」を使用して、表4-2に示す属性値を追加します。

表4-2 選択肢の属性値

選択肢名

Agent Script

Offer Description

URL

Brokerage Account

Would you like to try our new brokerage account?

Brokerage Account offer

http://www.offer.com/offer1.html

Credit Card

Would you like to try our new credit card?

Credit Card offer

http://www.offer.com/offer2.html

Life Insurance

Would you like to try our new life insurance?

Life Insurance offer

http://www.offer.com/offer3.html

Roth IRA

Would you like to try our new Roth IRA?

Roth IRA offer

http://www.offer.com/offer4.html

Savings Account

Would you like to try our new savings account?

Savings Account offer

http://www.offer.com/offer5.html

5. 「ファイル」→「すべて保存」を選択して、構成を保存します。

4.3 パフォーマンス目標の構成

パフォーマンス目標を構成する手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「パフォーマンス目標」要素をダブルクリックし、エディタを起動します。「追加」をクリックして、パフォーマンス・メトリックを追加します。メトリック名をCostにします。「OK」をクリックします。

2. 「最適化」で、「最小化」を選択し、メトリックを「必須」にします。

注意:

複数のパフォーマンス・メトリックがある場合、「正規化係数」を使用して値を正規化する必要があります。たとえば、あるメトリック(Minimize hold timeという名前)が秒単位で測定される場合、この正規化ファクタでは、1ドルの売上を実現するのに要する最小時間が秒単位で測定されます。

3. 「ファイル」→「すべて保存」を選択して、構成を保存します。

4.4 選択肢のスコアリング

各製品には、その維持に必要な平均コスト(年ベース)があります。ドル単位のコストは、構成したCostパフォーマンス目標に関連付ける製品のスコアを表します。

選択肢をスコアリングする手順は次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「選択肢」にある「Cross Selling Offer」選択肢グループを選択し開きます。「スコア」タブで、「メトリックの選択」をクリックし、パフォーマンス・メトリックの「Cost」を選択し、「OK」をクリックします。これによって、選択肢グループにコスト・スコアが設定されます。実際のスコア値は、選択肢ごとに設定されます。
スコア値は定数である必要はありません。多くの場合、顧客のタイプが異なるとスコア値が大きく異なります。こうした相違は、式(つまり、スコアリング・ルール)を使用して表現できます。たとえば、クレジット・カード・アカウントの維持に必要なコストは、40歳以下の顧客では低くなる場合があります。このロジックをスコアリング・ルールに定義してから、このルールをCredit Cardオファーのコスト・スコアに割り当てます。

2. 「インライン・サービス・エクスプローラ」で、「スコアリング・ルール」フォルダを右クリックし、「新規スコアリング・ルール」を選択します。スコアリング・ルールの名前をCredit Card Scoreにします。この新しいスコアリング・ルール用のエディタが起動します。

3. 「条件値の追加」アイコンをクリックし、デフォルト以外のルール条件を設定します。

新しい行が表示されます。その左側のセルに比較式によるルールを指定し、右側のセルにスコア値を指定します。このロジックは次のようになります。左側のセルが真の場合は、右側のセルの値が返されます。それ以外の場合は、ルールの2行目の値が使用されます。

ルールの左側をクリックし、省略記号をクリックします。「値の編集」ダイアログが表示されます。「属性」を選択し、「セッション属性」→「customer」を開き、「Age」を選択したら、「OK」をクリックします。条件演算子アイコンをクリックし、その右下にある三角形をクリックします。

以下を表す記号(<=)を選択します。ルールの右側をクリックし、数値の40を入力します。「その場合」セルに数値の130を入力します。2行目を選択し、値として数値の147を入力します。入力したルールは図4-2のようになります。

図4-2 完成したルール条件

「図4-2 完成したルール条件」の説明

作成したCredit Card Scoreスコアリング・ルールを保存します。他のオファーについては、定数値をコスト・スコアに設定します。

4. 「Cross Selling Offer」選択肢グループの選択肢ごとに、「スコア」タブを開きます。Costメトリックの「スコア」列に、表4-3に示す値を入力します。クレジット・カード選択肢にコスト・スコアを設定するには、「スコア」列の省略記号をクリックし、値ソースとして「関数またはルール・コール」を選択します。「コールする関数」ドロップダウン・リストで、「Credit Card Score」を選択します。

表4-3 選択肢のコスト・スコア

選択肢

コスト・スコア

Brokerage Account

150

Credit Card

Credit Card Scoreスコアリング・ルール: 年齢<=40の場合は130、それ以外は147

Life Insurance

140

Roth IRA

145

Savings Account

135

今回のパフォーマンス目標はコストの最小化にあるため、顧客の年齢が40歳以下の場合はCredit Cardオファー(スコアは130)が選択され、それ以外の場合はSavings Accountオファー(スコアは135)が選択されます。このチュートリアルの後述の項では、別のパフォーマンス目標(売上最大化メトリック)を追加し、これらの競合する2つのパフォーマンス・メトリックがプラットフォームによって最適化される方法について説明します。

5. 「ファイル」→「すべて保存」を選択して、構成を保存します。

4.5 アドバイザについて

外部システムで意思決定を行う必要があるとき、アドバイザがコールされます。この項では、特定の顧客用に選択されたオファーをCRMアプリケーションに返すアドバイザを作成します。

アドバイザの内部構造には、1つ以上の選択肢グループに関連付けるデシジョンが含まれます。これらの選択肢グループには、作成されるオファーが含まれます。デシジョンの結果は、アドバイザに送信される結果です。

アドバイザには2種類のデシジョンがあり、1つは通常の処理用で、もう1つは制御グループ用です。使用した場合、制御グループはOracle RTDによって実現されたパフォーマンス結果を示すベースラインとして機能します。

図4-3 Get Cross Sell Offerアドバイザの構造

「図4-3 Get Cross Sell Offerアドバイザの構造」の説明

4.6 デシジョンの作成

デシジョンを作成する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「デシジョン」フォルダを右クリックし、「新規デシジョン」を選択します。デシジョン名としてSelect Offerを指定し、「OK」をクリックします。

2. Select Offerデシジョンの説明を追加します。「デシジョン」エディタの「選択基準」タブで、「次から選択肢を選択」を探します。「選択」をクリックし、リストから「Cross Selling Offer」を選択し、「OK」をクリックします。

3. 制御グループには、オファーをランダムに選択するデシジョンを作成します。新しいデシジョンを作成し、その名前をRandom Choiceにします。

4. Random Choiceデシジョンの説明を追加します。「デシジョン」エディタの「選択基準」タブで、「次から選択肢を選択」を探します。「選択」をクリックし、リストから「Cross Selling Offer」を選択し、「OK」をクリックします。

5. 「ランダムに選択」チェック・ボックスを選択します。

注意:

制御グループは、ビジネス・ユーザー予測モデルの結果を既存のビジネス・プロセスと比較できるようにするベースラインとして機能します。制御グループのデシジョンは、Oracle RTDがインストールされていないときのデシジョンを正しく反映するように、正確に定義することが重要です。たとえば、コール・センター用の抱合せ販売アプリケーションで、Oracle RTDの導入前にはエージェントがランダムにオファーを選択していた場合は、制御グループのデシジョンがランダムな選択を返す必要があります。

6. 「ファイル」→「すべて保存」を選択して、構成を保存します。

4.7 アドバイザの作成

アドバイザを作成する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「統合点」の下の「アドバイザ」フォルダを右クリックし、「新規アドバイザ」を選択します。アドバイザ名にGet Cross Sell Offerを指定し、「OK」をクリックします。

2. セッション・キーをGet Cross Sell Offerアドバイザに追加するには、エディタで「セッション・キー」の「選択」をクリックして、「customerId」を選択します。「OK」をクリックします。

3. 「外部システム」で「CRM」を選択します。「順序」に「3」を入力します。
Service Completeインフォーマントの「順序」を2に設定したことを思い出してください。このインフォーマントの後にGet Cross Sell Offerアドバイザをコールしようとしているので、順序は3になります。この「順序」は、デシジョン・センターの統合マップでアプリケーション・プロセスを図示する目的にのみ使用され、統合点を特定の順序で実行するものでないことに注意してください。

4. 「レスポンス」タブで、通常処理と制御グループの両方に対してデシジョンを選択します。「デシジョン」には「Select Offer」デシジョンを選択し、「制御グループのデシジョン」にはRandom Choiceデシジョンを選択します。

5. 「デフォルトの選択肢」セクションで、「選択」をクリックし、リストから「Life Insurance」を選択し、「OK」をクリックします。これによって、選択されたオファーがこのアドバイザのデフォルト・レスポンスになります。このデフォルトは、処理に問題(タイムアウトなど)が発生したときに使用されます。

6. 「非同期ロジック」タブで、次のコードを入力します。

logInfo("Integration Point - Get Cross Sell Offer");
logInfo("  Customer age = " + session().getCustomer().getAge() );
// 'choices' is array returned by the 'Select Offer' decision
if (choices.size() > 0) {
//Get the first offer from array
Choice offer = choices.get(0);
logInfo("  Offer presented: '" + offer.getSDOLabel() + "'");
}

コードを「ロジック」タブに入力すると、返されるオファーがデシジョンによって決定される前にコードが実行されるため、返されるオファー名を出力できなくなります。前述のコードでは、顧客の年齢と提示されたオファー名が出力されます。コストの最小化を目標としているため、顧客の年齢に基づいて、Savings AccountオファーおよびCredit Cardオファーのみが提示されることを思い出してください。

7. インライン・サービスを保存します。ツールバーの「デプロイ」ボタンをクリックします。「アクティブ・セッション(テスト用として使用)の終了」 を選択して、その時点でまだアクティブなセッションをすべて削除します。デプロイします。
図4-4に、パフォーマンス目標のCostに基づいてGet Cross Sell OfferアドバイザがCross Selling Offer選択肢グループからオファーを取得するフローを示します。

図4-4 Cross Selling Offer選択肢グループからオファーを取得するGet Cross Sell Offerアドバイザ

「図4-4 Cross Selling Offer選択肢グループからオファーを取得するGet Cross Sell Offerアドバイザ」の説明

4.8 統合マップの表示

デシジョン・センターで統合マップを表示する手順は、次のとおりです。

1. Webブラウザを起動してURLにhttp://server_name:9704/uiを指定して、デシジョン・センターを起動します。インストール時に作成したデフォルト管理者資格証明を使用してログインします。デシジョン・センターを実行するには、Real-Time Decision Serverが起動されている必要があります。

2. インライン・サービスを開くをクリックします。

3. Tutorialインライン・サービスを選択します。

4. 左側のツリーで、ルート・ノードの「チュートリアル」をクリックします。右側のペインで、「定義」タブの「統合マップ」サブタブをクリックして表示します。図4-5のようなマップが表示されます。

図4-5 Tutorial統合マップ

「図4-5 Tutorial統合マップ」の説明

統合マップでは表4-4の記号を使用して、統合点、データ処理、エンティティおよび情報フローが示されます。

表4-4 統合マップの記号

記号

意味

Real-Time Decision Serverでのデータ処理

アドバイザ・コール

Real-Time Decision Serverに渡す情報(データ)

インフォーマント・コール

4.9 アドバイザのテスト

アドバイザをテストする手順は、次のとおりです。

1. デシジョン・スタジオで、「テスト」ビューを使用して、統合点リクエストを送信します。Service Completeインフォーマントを選択し、パラメータ値を入力します。たとえば、顧客IDに7、エージェント名にJohn、長さに21、理由コードに18(または17、19、20)をそれぞれ入力します。

2. 「送信」アイコンをクリックします。

「ログ」サブタブでメッセージが送信されたことを確認します。このインフォーマント・コールによって、新しいセッションが顧客IDに基づいて作成され、顧客の通話理由、エージェント名およびコールの長さが登録されます。

3. Get Cross Sell Offerアドバイザを選択します。同一セッションで作業を続行するため、customerIdはそのままにします。「送信」をクリックします。

選択されたオファーとその属性が返され、「テスト」ビューの「レスポンス」ペインに表示されます。

「テスト」ビューの「ログ」サブタブで、customerId = 7のエントリには、次のようなレスポンスが表示されます。

00:24:40,764 Integration Point - Get Cross Sell Offer
00:24:40,764   Customer age = 38
00:24:40,764   Offer presented: 'Credit Card'

4. 「customerId」と他のパラメータで値をそれぞれ異なる値に変えて、手順1から3までを繰り返します。顧客の年齢が40歳以下のときはCredit Cardオファーが返され、40歳を超えるときはSavings Accountオファーが返されることを確認してください。このような結果となる理由は、アドバイザがCostパフォーマンス・メトリックに対してのみ最適化されており、最小コストのオファーが顧客の年齢に応じてSavings AccountまたはCredit Cardのどちらかになるためです(「選択肢のスコアリング」のCredit Card Scoreスコアリング・ルールを参照)。

5. 「テスト」ビューの「トレース」サブタブには、オファーが選択されるまでの一連のプロセス(つまり、各オファーのスコアが計算され最適なオファーが決定されるプロセスから、最終的にパフォーマンス目標(コストの最小化)を満足したオファーが選択されるまでのプロセス)の説明が記録されます。

5 フィードバック・ループのクローズ

この章では、Oracle RTDが提案する選択肢の有効性に関するフィードバック情報を提供するために選択肢グループ・イベントと選択肢イベント・モデルを構成する方法について説明し、このチュートリアル・セクションを終了します。また、フィードバック情報が様々なデシジョン・センター・レポートでどのように表示されるかも説明します。

前の章では、コール・センター・エージェントが顧客にオファーを提示できるように、オファーをCRMアプリケーションに返すアドバイザを追加しました。顧客へのオファー提示後、顧客がそのオファーを受け入れたかどうかを追跡してから、オファーの提示と受入れのプロセスに関するループをクローズする必要があります。フィードバックのループは、様々な方法によって様々なタイミングでクローズされる場合があります。デシジョンやオファーが実行されてから数日から数週間後にようやく結果が判明することもあります。また、それだけの時間が経過しても、肯定的な結果のみが判明し、否定的な結果は不明な場合が多くあります。フィードバックは、顧客から直接取得される場合もあれば、電話に対応したエージェントから取得される場合、サービス、契約および請求を処理する業務システム、さらにはバッチ・プロセスから取得される場合もあります。

インライン・サービスに対するフィードバック・ループは、インフォーマントの使用を介してReal-Time Decision Serverに通知することでクローズされます。

この章には次のトピックが含まれます:

- 第5.1項「成功を追跡するイベントの使用」

- 第5.2項「モデルの予測機能の使用」

5.1 成功を追跡するイベントの使用

ほとんどの場合、オファーの存続期間中には、成功を追跡する観点から見て有意義なイベントが複数あります。たとえば、Credit Cardオファーの存続期間では、次のようなイベントが存在する場合があります。

- オファーの提示

- 顧客による興味関心

- カード発行の申込み

- カードの受領

- カードの使用

顧客がクレジット・カードを使用したときが本当の成功と考えることができます。最終的な目標は、顧客がカードに興味を持ち、カードの発行を申込み、カードを受領するだけではなく、より多くの顧客がカードを使用することにあります。カードの使用によって企業に収益がもたらされるからです。

一般的に、オファーの提示直後のイベントは追跡が容易です。たとえば、コール・センターにおいてエージェントがオファーを提示した時点で、顧客が示す興味関心の程度を測定できます。オファーがWebサイトに提示されている場合は、クリック・イベントが興味関心のインジケータになります。

オファーの存続期間の後半にあるイベントほど、オファーを追跡して妥当性を評価することが難しくなる場合があります。そのため、プロジェクトを開始して即座に結果の出るフィードバック・ループのみをクローズし、システムが熟成するにつれて下流のイベントを追加するのが一般的です。Oracle RTDでは、開始直後のフィードバックのみでも、マーケティングの意思決定に大きく貢献できます。

この項には次のトピックが含まれます:

- 第5.1.1項「選択肢グループにおけるイベントの定義」

- 第5.1.2項「選択肢イベント・モデルの定義」

- 第5.1.3項「その他のモデル設定」

- 第5.1.4項「提案されたオファーの記憶」

- 第5.1.5項「フィードバック・インフォーマントの作成」

- 第5.1.6項「フィードバック・インフォーマントのテスト」

- 第5.1.7項「ロード・ジェネレータ・スクリプトの更新」

5.1.1 選択肢グループにおけるイベントの定義

イベントは、選択肢グループのレベルで定義します。イベントはグループ階層の任意のレベルで定義できますが、ルートに近い最上位レベルで定義するのが一般的です。

ここではイベントを2つ作成します。1つはオファーが顧客に提示された事実を示すイベントで、もう1つはオファーが受け入れられた事実を示すイベントです。このチュートリアルでは、アドバイザの結果として選択されたすべてのオファーが提示され、オファーの受入れがただちに判明することを前提にしています。

選択肢グループにイベントを定義する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」の「選択肢」で、「Cross Selling Offer」選択肢グループをダブルクリックします。

2. 「選択肢イベント」タブを選択します。「追加」をクリックして、イベントを2つ追加します。最初のイベント名は「presented」(提示)、2番目のイベント名は「accepted」(受入れ)にします。これらのイベント名は単なるラベルで、オファーの内部状態には対応しないことに注意してください。これらのイベントは選択肢イベント・モデル(次の項で説明)で使用され、これらのイベント名はそこで意味を持ちます。

3. イベントごとに、ドロップダウン・リストを使用して、「統計コレクタ」を「選択肢イベント統計コレクタ」に設定します。これはデフォルトの統計コレクタです。このコレクタによって、各イベントに関する統計が収集されます。

4. 「イベント履歴(日数)」が「セッション継続時間」に設定されていることを確認します。

5. 「値属性」は空欄のままにします。
これは、イベントの自動処理に使用されます。このチュートリアルでは、フィードバック・インフォーマントのロジックによりイベントを記録します。

6. 「ファイル」→「すべて保存」を選択します。

5.1.2 選択肢イベント・モデルの定義

ここまでで、イベントの定義が完了し、統計を追跡する準備が整いました。イベントでは、統計の追跡に加えて、様々な要因(顧客の特性、通話とエージェント、およびオファーの成功や失敗)間における相関関係に関する学習が自己学習モデルにおいて行われます。この知識は次の2つの目的で役立ちます。

- マーケティング担当者や営業担当者の洞察力と把握力の向上

- 様々な状況で最適なオファーを提示する自動予測

このチュートリアルでは、これらの両方に対する使用方法について説明します。

選択肢イベント・モデルを定義する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「モデル」を右クリックしてから、「新規選択肢イベント・モデル」を選択します。新しいモデルの名前をOffer Acceptance Predictorに設定し、「OK」をクリックします。

2. モデルのエディタで、「新規選択肢イベント・モデル」の選択を解除し、「時間ウィンドウ」を1週間に設定します。

3. 「選択肢グループ」で「Cross Selling Offer」を選択します。
このグループは選択肢階層の最上位グループで、このモデルを使用してオファーの受入れを追跡します。

4. 「ベース・イベント」で「presented」を選択します。前項で、選択肢グループのこれらのイベント名を定義したことを思い出してください。
このイベントが、成功を測定する対象イベントになります。オファーが受け入れられたかどうかは、オファーの提示後に追跡します。

5. 「正の結果イベント」で、「選択」をクリックして「accepted」を選択し、「OK」をクリックします。このチュートリアルでは、これが唯一の肯定的な結果です。複数のイベントを追跡する場合は、ここで追加します。

6. 必要に応じて、イベントのラベルをオファー指向の名前に変更できます。

5.1.3 その他のモデル設定

選択肢イベント・モデルには、他にも役に立つ設定があります。「属性」タブには重要な設定が2つあります。パーティション化属性と除外属性です。次の各項で、これらの属性などの設定について説明します。

この項には次のトピックが含まれます:

- パーティション化属性

- 除外属性

- 学習の実行場所

5.1.3.1 パーティション化属性

パーティション化属性は、大きく異なる結果をもたらす区分によってモデルを分割する目的で使用されます。たとえば、同じオファーでも、Webでの提示とコール・センターでの提示では、その受入れ特性が大きく異なる可能性があります。このような場合、提示チャネルをパーティション化属性として設定できます。

パーティション化属性は複数設定できますが、メモリー使用量に影響する場合があることに注意してください。各パーティション化属性では、属性値の数だけモデル数が倍増します。たとえば、モデルに3つの値を持つパーティション化属性と4つの値を持つパーティション化属性がある場合、メモリーの使用量はパーティション化でないモデルの12倍になります。それでもそうする意味がある場合は、それによってモデルの予測性能と説明性能が大きく向上するため、必ずパーティション化属性を使用してください。

5.1.3.2 除外属性

モデルへの入力として意味がない属性もあります。たとえば、Reason Analysisモデル(第3.1.2項「デシジョン・センターにおける分析結果の表示」を参照)では、入力として理由コードを持つことで、理由コードと通話理由の選択肢との間に相関関係が検出されました。この関係は、第2.9.4項「選択肢の選択のためのロジックの追加」で作成したロジックの当然の結果です。この相関関係は人為的なものであり、有意義な洞察でないため、理由コードをモデルから除外しました。

他のモデルでは理由コードが重要な要素となる場合があるため、除外が適切でない場合があることに注意してください。エンティティ属性レベルではなく、モデル・レベルで理由コード属性を除外(「分析に使用」プロパティの選択を解除)するのはこのためです。エンティティ属性レベルで除外すると、インライン・サービスのすべてのモデルで理由コード属性が除外されます。たとえば、Offer Acceptance Predictorモデルでは、オファーの受入れと理由コードとの間における相関関係に注目する必然性があります。

5.1.3.3 学習の実行場所

「場所の学習」タブで、モデルの学習をプロセス内のどのタイミングで実行するかを設定します。ほとんどの場合は、デフォルトの「セッションのクローズ」が適しています。セッションにおいて複数の状態から学習を行う必要があるときは、特定の統合点において学習を設定すると有効な場合があります。

5.1.4 提案されたオファーの記憶

選択肢イベント・モデルの定義が完了し、使用する準備が整いました。モデルに適切な情報を入力するには、ループをクローズするロジックを完成する必要があります。

提案されたオファーをモデルで使用可能にするには、オファーIDをセッションで記憶する必要があります。フロントエンド・クライアントがそれを記憶する場合もあるため、この手順は必須ではありませんが、ここではフロントエンドの機能を前提にしません。オファーの記憶には単純な文字列属性を使用するだけですが、複雑な場合は配列を使用して複数の選択肢を記憶します。

提案されたオファーを記憶する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「エンティティ」の下の「セッション」をダブルクリックします。

2. 「属性の追加」をクリックして属性を追加し、Offer Extendedと命名します。

3. 属性の説明を入力します。「デシジョン・センターで表示」および「分析に使用」の選択を解除します。「OK」をクリックします。
この操作を行う理由は、現時点でこの属性を内部変数として扱い、ビジネス・ユーザーには表示しないためです。

4. 「インライン・サービス・エクスプローラ」で、「統合点」→「アドバイザ」の下にある「Get Cross Sell Offer」をダブルクリックします。

5. 「非同期ロジック」タブで、既存のコードを更新します。presentedイベントを記録してOfferExtendedセッション属性に選択肢IDの値を設定する行を既存のコードに追加します。更新後のコードは次のようになります。

logInfo("Integration Point - Get Cross Sell Offer");
logInfo("  Customer age = " + session().getCustomer().getAge() );
// 'choices' is array returned by the 'Select Offer' decision
if (choices.size() > 0) {
//Get the first offer from array
Choice offer = choices.get(0);
//For the selected offer, record that it has been 'presented'
offer.recordEvent("Presented");
//Set the session attribute 'OfferExtended' with the offer's ID.
session().setOfferExtended(offer.getSDOId());
logInfo("  Offer presented: '" + offer.getSDOLabel() + "'");
}

これにより、選択された選択肢のSDOIdがセッション・エンティティのOfferExtended属性に割り当てられます。SDOIdは一意の識別子です。Oracle RTD構成のすべてのオブジェクトには一意なSDOIdがあります。選択されたオファーのPresentedイベントも記録されます。イベント名は小文字表記で、Presentedの選択肢イベントIDに対応することに注意してください。このIDを表示するには、「インライン・サービス・エクスプローラ」で「選択肢」を開き、「Cross Selling Offer」をダブルクリックします。次に、「選択肢イベント」タブをクリックし、ラベル/IDの切替アイコンをクリックします。

デシジョンの時点で、どのオファーが選択されコール・センター・エージェントによって(Get Cross Sell Offerアドバイザを介して)顧客に提示されたかがセッションにおいて記憶されます。顧客からのレスポンスは判明していません。レスポンスは、次の項で説明するフィードバック・インフォーマントを介して送信されます。

5.1.5 フィードバック・インフォーマントの作成

このインフォーマントによりOracle RTDに対して、オファー選択デシジョンの結果評価に必要な情報が提供されます。

フィードバック・インフォーマントを作成する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「統合点」を開いて「インフォーマント」フォルダを右クリックし、「新規インフォーマント」を選択します。インフォーマント名をOffer Feedbackにします。

2. エディタで、インフォーマントの説明を入力します。「外部システム」で「CRM」を選択します。「順序」に4を入力します。

3. セッション・キーをOffer Feedbackインフォーマントに追加するには、「セッション・キー」の横にある「選択」をクリックします。「customerId」を選択し、「OK」をクリックします。

4. 「追加」をクリックして入力パラメータを追加します。パラメータ名をPositiveにします。

5. データ型が「String」でない場合は選択し、「OK」をクリックします。
パラメータはマップされないままにします。このパラメータにセッション属性へのマッピングが不要なのは、この引数がオファーの受入れの成否を即時に判定する目的で使用されるためです。オファーの受入れは、yes値によって示されます。

6. 「ロジック」タブの「ロジック」に次のコードを入力し、受入れイベントの発生時に記録されるようにします。

logInfo("Integration Point - Offer Feedback");
//"yes" or "no" to accept offer.
String     positive = request.getPositive();
positive = positive.toLowerCase();

//Get the offer id from session attribute 'OfferExtended'
String extendedOfferID = session().getOfferExtended();
if (extendedOfferID != null) {
//Get the offer from choice group 'Cross Selling Offer'
Choice offer = CrossSellingOffer.getChoice(extendedOfferID);
if (offer != null){
String offerId = offer.getSDOId();
//If response is "yes", then record the offer as accepted.
if (positive.equals("yes")) {
offer.recordEvent ("Accepted");
logInfo("  Offer '" + offer.getSDOLabel() + "' accepted");
}
}
}

7. すべてを保存し、インライン・サービスを再デプロイします。「デプロイ」ダイアログで、「アクティブ・セッション(テスト用として使用)の終了」を選択します。
次の図に、Get Cross Sell Offerアドバイザがオファーを取得および提示してから、Offer Feedbackインフォーマントがオファーを受け入れるか拒否するまでのフローを示します。Call Endインフォーマントによってセッションがクローズされると、Offer Acceptance PredictorモデルがオファーのPresentedイベントまたはAcceptedイベントによって更新されます。

図5-1 Tutorialインライン・サービスのオブジェクト: アドバイザおよびインフォーマントのフロー

「図5-1 Tutorialインライン・サービスのオブジェクト: アドバイザおよびインフォーマントのフロー」の説明

5.1.6 フィードバック・インフォーマントのテスト

Offer Feedbackインフォーマントをテストするには、最初にGet Cross Sell Offerをコールしてオファーを取得して提示する必要があります。

フィードバック・インフォーマントをテストする手順は、次のとおりです。

1. 「テスト」ビューで、Get Cross Sell Offer統合点を選択します。「customerId」に10などの値を入力します。

2. 「送信」アイコンをクリックします。

「レスポンス」サブタブでオファーが取得されたことを確認します。「ログ」サブタブには、次のような結果が表示されます。

00:45:28,466 Integration Point - Get Cross Sell Offer
00:45:28,466   Customer age = 38
00:45:28,466   Offer presented: 'Credit Card'

他の値を「customerId」に入力しても、提示されるオファーは必ずSavings AccountかCredit Cardのどちらかになります。これは、この段階ではパフォーマンス目標をコストの最小化に対してのみ構成しており、顧客の年齢に応じてSavings AccountまたはCredit Cardが最小コストとなるためです。

3. 「統合点」ドロップダウン・リストから、「Offer Feedback」インフォーマントを選択します。同一セッションで手順を続行するため、「customerId」の値はそのままにします。入力の「Positive」に、yesなどの値を入力します。

4. 「送信」をクリックし、Get Cross Sell Offerアドバイザによって取得されたオファーが受け入れられたことを「ログ」サブタブで確認します。次のようなマップが表示されます。

00:46:01,418 Integration Point - Offer Feedback
00:46:01,418   Offer 'Credit Card' accepted

5. 入力の「Positive」値をnoに変更し、Offer Feedbackインフォーマントを再送信します。「ログ」サブタブの内容は次のようになります。

00:47:31,494 Integration Point - Offer Feedback

5.1.7 ロード・ジェネレータ・スクリプトの更新

ロード・ジェネレータ・スクリプトを更新して、Get Cross Sell OfferアドバイザおよびOffer Feedbackインフォーマントに対するコールを追加します。これらの統合点コールは、ServiceCompleteインフォーマントの後からCallEndインフォーマント(セッションをクローズするインフォーマント)の前までに実行される必要があることに注意してください。ロジックは次のとおりです。1) コールが開始します。2) 標準サービスが完了します。ReasonAnalysisモデルを使用して通話理由を記録および分析します。3) エージェントがコスト最小化目標に基づいて抱合せ販売オファーを顧客に提示します。4) オファーを顧客が受け入れたかどうかを記録します。5) コール/セッションが終了し、OfferAcceptancePredictorモデルがオファーの提示や受入れについて学習します。

Get Cross Sell Offerアドバイザをロード・ジェネレータ・スクリプトに追加する手順は、次のとおりです。

1. RTD_HOME\scripts\loadgen.cmdを実行することで、ロード・ジェネレータを開きます。そして、以前のスクリプトを開きます。

2. 「スクリプトの編集」タブを選択し、左側のツリー・ビューを右クリックして「アクションの追加」を選択します。アクションのタイプを「メッセージ」に、統合点の名前をGetCrossSellOfferにそれぞれ設定します。

3. 「入力フィールド」で右クリックして「項目の追加」を選択し、入力フィールドを追加します。「名前」の下のスペースをクリックしてcustomerIdを入力してから、[Enter]を押します。

4. 入力フィールドの「変数」をクリックし、ドロップダウン・リストを使用して、対応する変数のvar_customerId(詳細は第3.1.1項「ロード・ジェネレータ・スクリプトの作成」を参照)を選択します。「セッション・キー」を選択して、customerIdをセッション・キーとしてマークします。

5. このアクションをスクリプトに追加すると、アクション・リストの下部に追加されます。GetCrossSellOfferがServiceCompleteの後にコールされるように、順序を調整する必要があります。「スクリプトの編集」タブの左側で「GetCrossSellOffer」を右クリックしてから、「上に移動」または「下に移動」を使用して、順序がCallBegin、ServiceComplete、GetCrossSellOffer、CallEndになるようにします。

6. ロード・ジェネレータ・スクリプトを保存します。

Offer Feedbackインフォーマントをロード・ジェネレータ・スクリプトに追加する手順は、次のとおりです。

1. OfferFeedbackのコールを「スクリプトの編集」タブで追加する前に、 新しい変数を「変数」タブで作成する必要があります。OfferFeedbackインフォーマントの定義で、パラメータpositiveを使用してオファーの受入れを示していることを思い出してください。ロード・ジェネレータでは、このパラメータの値がランダムにyes(30%の割合)、no(70%の割合)になるように設定します。これには、加重された文字列配列を使用します。

2. 「変数」タブの左側で「スクリプト」フォルダをクリックし、「変数の追加」を選択します。「変数名」に「var_positive」を入力し、「コンテンツ」のタイプを「加重された文字列配列」に設定します。2つのアイテムを配列に追加します(コンテンツ・タイプの下のスペースを右クリックし、「項目の追加」を選択)。最初のアイテムでは、「加重」セルをダブルクリックして編集可能にし、値として30を入力し、対応する「文字列」セルに値としてyesを入力します。2番目のアイテムでは、加重値を70にし、文字列値をnoにします。加重値は合計を100にする必要はありません。自動的に正規化されます。加重値を6と14にしても、同じ結果となります。

図5-2 「加重された文字列配列」変数

「図5-2 「加重された文字列配列」変数」の説明

3. 「スクリプトの編集」タブを選択し、左側のツリー・ビューを右クリックして「アクションの追加」を選択します。アクションのタイプを「メッセージ」に、統合点の名前をOfferFeedbackにします。

4. 「入力フィールド」で右クリックして「項目の追加」を選択し、入力フィールドを追加します。「名前」の下のスペースをクリックし、customerIdを追加します。「変数」列で、対応する変数のvar_customerId(詳細は第3.1.1項「ロード・ジェネレータ・スクリプトの作成」を参照)を選択します。「セッション・キー」を選択して、customerIdをセッション・キーとしてマークします。

5. 再び「入力フィールド」で右クリックして「項目の追加」を選択し、入力フィールドを追加します。「名前」の下のスペースをクリックし、positiveを追加します。「変数」列で、対応する変数のvar_positiveを選択します。

6. このアクションをスクリプトに追加すると、アクション・リストの下部に追加されます。OfferFeedbackがGetCrossSellOfferの後にコールされるように、順序を調整する必要があります。「スクリプトの編集」タブの左側で「OfferFeedback」を右クリックし、「上に移動」または「下に移動」を選択して、順序がCallBegin、ServiceComplete、GetCrossSellOffer、OfferFeedback、CallEndになるようにします。

図5-3ロード・ジェネレータ・スクリプトへのOfferFeedbackインフォーマントの追加

「図5-3ロード・ジェネレータ・スクリプトへのOfferFeedbackインフォーマントの追加」の説明

7. 「セキュリティ」タブで、「ユーザー名」と「パスワード」を入力します。

8. ロード・ジェネレータ・スクリプトを保存します。

この時点でロード・ジェネレータ・スクリプトを実行できます。実行結果に古いデータが混在しないように、スクリプトを実行する前に既存データを再び削除することをお薦めします。削除方法の詳細は、第3.2項「モデルの学習内容のリセット」を参照してください。

ロード・ジェネレータ・スクリプトを実行した場合は、その結果をデシジョン・センターで参照できます。デシジョン・センターにログインし、「Cross Selling Offer」選択肢グループをクリックし、Offer Acceptance Predictorモデルの結果を表示します。「パフォーマンス」タブ→「カウント」サブタブをクリックします。オファーの分布とパレート図が、図5-4のように表示されます。

図5-4デシジョン・センター→「Cross Selling Offer」→「パフォーマンス」→「カウント」

「図5-4デシジョン・センター→「Cross Selling Offer」→「パフォーマンス」→「カウント」」の説明

Credit CardとSavings Accountの2つのオファーのみが提示され、それぞれの受入れ率が約30%になっていることに注意してください。これは、これまでに設定したロジックの当然の結果です。 コスト最小化というパフォーマンス目標のみが満たされ、顧客の年齢に応じてSavings AccountまたはCredit Cardのコストが最小になっています(第4.4項「選択肢のスコアリング」を参照)。ロード・ジェネレータ・スクリプトで、OfferFeedbackインフォーマントによって、オファーへの肯定的なレスポンスが30%の確率で記録されるように指定しました。個々のオファーの分析レポートにドリルダウンすると、オファーの受入れとセッション属性の間には相関関係があまりないことがわかります。これは、ランダムな顧客プロファイル・データを使用し、顧客やその他の属性(通話の長さ、コール・エージェント名、通話理由など)に関係なく、受入れ率が30%になるように強制しているためです。

これまで、パフォーマンス目標を使用して提示オファーを決定する方法と、選択肢イベント・モデルを使用して提示オファーの受入れ率を追跡する方法についてそれぞれ説明しました。これまでに使用したのは、分析に関するモデルのみです。次の項では、2番目のパフォーマンス目標(売上の最大化)を追加し、そのモデルの学習内容を使用して、提示するオファーに影響を与える方法について説明します。また、2人以上の子供を持つ顧客にLife Insuranceオファーが提示された場合に、その受入れ確率を高める人為的なバイアスを導入します。これによって、このバイアスがモデルの結果にどのように影響するかを調べます。

5.2 モデルの予測機能の使用

これまでに作成したモデルは、顧客の特性、通話の特性、抱合せ販売の結果の間にある相関関係を学習します。このモデルは、オファー受入れの確率を予測する予測計算にも使用できます。この確率情報を使用することで、提示するオファーを決定する際にオファーの値を調整できます。たとえば、オファーAの受入れ確率がオファーBの2倍と予測される場合は、提示するオファーの選択時に、オファーAを優先するのが妥当です。この項では、2番目のパフォーマンス目標としてMaximize Revenue(売上の最大化)を導入します。その値/スコアは、受入れ確率と売上単価の積として計算します。

たとえば、Brokerage Accountオファーの売上単価が$300で受入れ確率が30% (0.3)と仮定した場合、その売上最大化スコアは$300 x 0.3 = $90になります。Life Insuranceオファーの売上単価は$185で受入れ確率が60% (0.6)と仮定した場合、売上最大化スコアは$185 x 0.6 = $111になります。Brokerage Accountのほうが売上単価の値が高くても、売上最大化スコアが高くなるLife Insuranceオファーを優先して選択するほうが有利になります。

ここでは、コストと売上最大化の両方に基づいて、提示するオファーを選択することに注意してください。前述の例で、コストと売上最大化の重み付けされた合計においてBrokerage AccountがLife Insuranceよりも高い場合は、Brokerage Accountが選択されます。

この項では、最初に売上単価を追加し、その後で2番目のパフォーマンス目標である売上最大化を追加します。次に、売上最大化の目標のスコアとして、売上単価と受入れ確率との積の値を設定します。設定が完了したら、提示するオファーの選択時にコストと売上最大化の両方の目標が適用されるように、Select Offerデシジョンを更新します。最後に、Offer Feedbackに、Life Insuranceオファーの提示先であり特定のプロファイルを持つ顧客に対して、オファー受入れバイアスを導入するロジックを追加します。

この項には次のトピックが含まれます:

- 第5.2.1項「売上単価選択肢属性の追加」

- 第5.2.2項「2番目のパフォーマンス目標(売上の最大化)の追加」

- 第5.2.3項「パフォーマンス目標であるMaximize Revenueのスコア値の計算」

- 第5.2.4項「2番目のパフォーマンス目標の挿入によるSelect Offerデシジョンの更新」

- 第5.2.5項「受入れ確率を表示するための選択肢属性の追加」

- 第5.2.6項「受入れ確率値のチェック」

- 第5.2.7項「特定の顧客に対するオファー受入れバイアスの導入」

- 第5.2.8項「ロード・ジェネレータ・スクリプトの実行」

- 第5.2.9項「結果の検証」

5.2.1 売上単価選択肢属性の追加

売上単価選択肢属性を追加する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」の「選択肢」で、「Cross Selling Offer」選択肢グループをダブルクリックします。「選択肢属性」タブで、「追加」をクリックします。

2. この属性の名前をRevenueに、データ型をIntegerにそれぞれ設定します。オファーごとに異なる値を割り当てるため、「オーバーライド可能」オプションが選択されていることを確認し、「OK」をクリックします。

3. 「Cross Selling Offer」選択肢グループの各選択肢に、表5-1に示すように、Revenue属性の値を設定します。

表5-1 各選択肢のRevenue値

選択肢名

売上単価の値

Brokerage Account

300

Credit Card

205

Life Insurance

185

Roth IRA

190

Savings Account

175

5.2.2 2番目のパフォーマンス目標(売上の最大化)の追加

このチュートリアルにおける前述の項で、Costパフォーマンス目標を定義しました。ここでは、2番目のパフォーマンス目標としてMaximize Revenueを追加します。この新しいパフォーマンス・メトリックのスコアの計算では、選択肢の受入れ確率と売上単価を使用します。その計算式は、売上単価×受入れ確率＝潜在売上スコアとなります。

2番目のパフォーマンス目標を追加する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「パフォーマンス目標」をダブルクリックし、エディタを起動します。「追加」をクリックして、パフォーマンス・メトリックを追加します。メトリック名をMaximize Revenueとし、「OK」をクリックします。

2. 「最適化」で、「最大化」を選択し、メトリックを「必須」にします。コストの$1と売上の$1は等しいため、正規化ファクタは調整不要です。

3. 次に、このメトリックを「Cross Selling Offer」選択肢グループに追加する必要があります。「インライン・サービス・エクスプローラ」で、「Cross Selling Offer」をダブルクリックします。「スコア」タブで「メトリックの選択」をクリックします。「選択」ダイアログで「Maximize Revenue」を選択し、「OK」をクリックします。

5.2.3 パフォーマンス目標であるMaximize Revenueのスコア値の計算

Maximize Revenue目標のスコア値を計算するには、Offer Acceptance Predictor選択肢イベント・モデルによって決定される受入れ確率値と売上単価が必要です。この値は、「値の編集」ダイアログで値スコアを「モデル予測」に変更することで取得できます。

パフォーマンス目標であるMaximize Revenueのスコア値を計算する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」の「選択肢」で、「Cross Selling Offer」選択肢グループをダブルクリックします。「スコア」タブで、Maximize Revenueメトリックの「スコア」列→省略記号をクリックし、「値の編集」ダイアログを起動します。

2. 「値ソース」で、「関数またはルール・コール」を選択します。「コールする関数」で、「乗算」関数を選択します。「パラメータ」の表で、aパラメータの「値」セルをクリックします。省略記号をクリックして「属性または変数」を選択します。「選択肢」フォルダを開き、「収益」を選択して「OK」をクリックします。「パラメータ」の表で、bパラメータの「値」セルをクリックします。省略記号をクリックして「モデル予測」を選択します。Offer Acceptance PredictorモデルとAcceptedイベントによって予測される確率を選択し、「OK」をクリックします。「値の編集」ダイアログでもう一度「OK」をクリックします。

図5-5 Maximize Revenueのスコアの「値の編集」ダイアログ

「図5-5 Maximize Revenueのスコアの「値の編集」ダイアログ」の説明

実際の確率の値は0から1までの間であり、1は100%の受入れ確率を意味します。この値はNaN (Not a number)になる場合もあり、これは確率値の計算に十分なデータがモデルになかったことを意味します。この場合、Maximize Revenueのスコアは計算不能で、Select Offerデシジョンによるオファー選択は、組込みのスコア計算ロジックに基づきます(スコアが必須かどうかに応じて処理される)。

3. Maximize Revenueのスコアを選択肢グループ・レベルで定義することで、グループ内のすべての選択肢においてその定義が継承され、選択肢固有の売上単価値と受入れ確率値が実行時に適用されます。

5.2.4 2番目のパフォーマンス目標の挿入によるSelect Offerデシジョンの更新

これまで、新しいパフォーマンス・メトリックとその値の計算方法を定義しました。次に、提示するオファーの選択時に両方のパフォーマンス・メトリックが適用されるように、Select Offerデシジョンを更新します。

Select Offerデシジョンを更新する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「デシジョン」フォルダを開き、「Select Offer」をダブルクリックします。

2. 「選択基準」タブの「"Default"セグメントの優先度」表には、パフォーマンス目標のCostのみが100%の重み付け値で表示されます。「目標」をクリックしてパフォーマンス目標の「Maximize Revenue」を選択し、「OK」をクリックします。
優先度の表に、2つのパフォーマンス目標が、それぞれ重み付け値50%で表示されます。デフォルトでは、重み付けは、選択されたすべてのメトリック間で均等に分配されます。Maximize Revenueパフォーマンス目標をCostよりも優先する場合は、このパーセント値を調整して重み付けを高くします。このチュートリアルでは、デフォルトの重み付けの50%を使用します。

表5-2に、Select Offerデシジョンにより特定のオファーに対する合計スコアを計算する例を示します。この例では、オファーのCostスコアを150、Maximize Revenueスコアを215とします。

表5-2 オファーの合計スコアの計算

パフォーマンス目標

スコア

重み付け

最大/最小

正規化

重み付けされたスコア

Cost

150

50%

最小

1

-75

Maximize Revenue

215

50%

最大

1

107.5

表5-2の値に基づいて計算されたスコアの合計は32.5になります。Costの重み付けされたスコアは、「最適化」が「最小化」のため負の値になります。オファーの合計スコアは、2つの重み付けされたスコアの加算値です。合計スコアはオファーごとに計算され、最高値を持つオファーが選択されます。

5.2.5 受入れ確率を表示するための選択肢属性の追加

受入れ確率の値を表示するには、対応する選択肢属性を追加し、logInfoを介して表示するか、「テスト」ビューの「レスポンス」タブに表示します。

選択肢属性を追加する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」の「選択肢」で、「Cross Selling Offer」選択肢グループをダブルクリックします。「選択肢属性」タブで、「追加」をクリックして属性を追加します。プロパティ・ダイアログで、「ラベルの表示」をLikelihood Of Acceptanceに設定します。「ラベルの表示」をDoubleに設定します。

2. この選択肢グループ内のすべての選択肢によってこの属性に同じ定義が使用されるため、「オーバーライド可能」オプションの選択を解除します。「クライアントへ送信」オプションを選択し、「OK」をクリックします。

3. Likelihood Of Acceptance属性の「値」列で、省略記号をクリックし、その値を設定します。「値の編集」ダイアログで、「値ソース」を「モデル予測」に設定します。Offer Acceptance PredictorモデルとAcceptedイベントを選択し、「OK」をクリックします。

4. インライン・サービスに対するすべての変更を保存します。

5.2.6 受入れ確率値のチェック

受入れ確率値を表示するには、次に示すように、logInfo文をGet Cross Sell Offerアドバイザに追加します。

1. 「インライン・サービス・エクスプローラ」で、「統合点」→「アドバイザ」の下にある「Get Cross Sell Offer」フォルダをダブルクリックします。

2. 「非同期ロジック」タブで、受入れ確率の値を出力する行を追加して、既存コードを更新します。更新後のコードは次のようになります。

logInfo("Integration Point - Get Cross Sell Offer");
logInfo("  Customer age = " + session().getCustomer().getAge() );
// 'choices' is array returned by the 'Select Offer' decision. The
// name 'choices' was set (and can be changed) in the 'Choice Array'
// text box in the 'Select Offer' decision's 'Pre/Post Selection
// Logic' tab.
if (choices.size() > 0) {
//Get the first offer from array
Choice offer = choices.get(0);
//For the selected offer, record that it has been 'presented'
offer.recordEvent("Presented");
//Set the session attribute 'OfferExtended' with the offer's ID.
session().setOfferExtended(offer.getSDOId());
logInfo("  Offer presented: '" + offer.getSDOLabel() + "'");
//Cast selected offer to type CrossSellingOfficeChoice -
//the base Choice type of choice group 'Cross Selling Offer'
CrossSellingOfferChoice cso = (CrossSellingOfferChoice) offer;
logInfo("  Likelihood of Acceptance = " + cso.getLikelihoodOfAcceptance());
}

3. アドバイザの変更結果を確認するには、すべてを保存し、インライン・サービスをデプロイします。

4. 「テスト」ビューで、Get Cross Sell Offer統合点を選択し、「customerId」に8などの値を入力します。「送信」をクリックします。「テスト」ビューの「レスポンス」サブタブに、図5-6に示すような結果が表示されます。

図5-6 「テスト」ビューの「レスポンス」サブタブ

「図5-6 「テスト」ビューの「レスポンス」サブタブ」の説明

「ログ」サブタブには、次のような結果が表示されます。

14:07:37,908 Integration Point - Get Cross Sell Offer
14:07:37,908   Customer age = 57
14:07:37,908   Offer presented: 'Savings Account'
14:07:37,908   Likelihood of Acceptance = 0.30354643094453865

Likelihood Of AcceptanceでNaN (Not A Number)値を取得した場合は、受入れ確率値の計算に十分なデータがモデルにないことを意味します。モデルの収束(受入れ確率値がNaNでなくなる)に必要な反復実行回数は、アプリケーションとデータの質によって異なります。

このケースでは、オファーの受入れ確率を30%にして(第5.1.7項「ロード・ジェネレータ・スクリプトの更新」を参照)、ランダムな顧客プロファイル・データを使用するため、Offer Acceptance Predictorモデルは短時間で収束し、数百回の反復実行で受入れ確率を計算できます。モデルが収束する前に、オファー選択プロセスは、組込みのスコア計算ロジックに基づいて決定します(スコアが必須かどうかに応じて処理される)。

次の図に、各オファーの合計スコアをCostとMaximize Revenueの2つのスコアの重み付けされた合計として、Get Cross Sell OfferアドバイザがCross Selling Offer選択肢グループからオファーを取得するフローを示します。

図5-7 Tutorialインライン・サービスのオブジェクト: 重み付けされた合計

「図5-7 Tutorialインライン・サービスのオブジェクト: 重み付けされた合計」の説明

5.2.7 特定の顧客に対するオファー受入れバイアスの導入

これまで、Offer Feedbackインフォーマントにおいて、提示されたオファーが受け入れられたかどうかを示すPositiveインフォーマント・パラメータを指定しました。次に、このインフォーマントがコールされたときに、Positiveパラメータにyesの値が30%の割合で渡されるように、ロード・ジェネレータ・スクリプトを更新しました(第5.1.7項「ロード・ジェネレータ・スクリプトの更新」を参照)。このパーセント値は顧客のプロファイル・データによって変わらないため、どのような顧客に対しても、提示されたすべてのオファーの受入れ確率が30%程度になります。

この段階でロード・ジェネレータ・スクリプトを実行しても、モデルによって、顧客属性とオファー受入れとの間において密接な相関関係が示されることはありません。ここでは、2人以上の子供を持つ顧客にLife Insuranceオファーが提示された場合に、肯定的なオファー受入れをOffer Feedbackインフォーマントのロジックに必ず記録する人為的なバイアスを導入します。このロジックでは、デフォルトの受入れ確率(ロード・ジェネレータ・スクリプトに定義済)に加えて、Life Insuranceオファーの受入れ確率を30%よりも高い値に偏向させます。デシジョン・センターでは、子供の数とこのオファーの受入れ確率との間に明確な相関関係が見られるようになります。

オファー受入れバイアスを導入する手順は、次のとおりです。

1. 「インライン・サービス・エクスプローラ」で、「統合点」→「インフォーマント」の下にある「Offer Feedback」をダブルクリックします。

2. 「ロジック」タブで、2人以上の子供を持つ顧客にLife Insuranceオファーが提示された場合にオファー受入れバイアスを追加する行を追加して、既存コードを更新します。更新後のコードは次のようになります。

logInfo("Integration Point - Offer Feedback");
//"yes" or "no" to accept offer.
String    positive = request.getPositive();
positive = positive.toLowerCase();

//Get the offer id from session attribute 'OfferExtended'
String extendedOfferID = session().getOfferExtended();
if (extendedOfferID != null) {
//Get the offer from choice group 'Cross Selling Offer'
Choice offer = CrossSellingOffer.getChoice(extendedOfferID);
if (offer != null){
String offerId = offer.getSDOId();
//Introduce artificial bias for customers with 2 or more
//children to always accept "LifeInsurance" if it was
//selected after scoring.
//If data source is Oracle, change the following method from
//getNumberOfChildren() to getNumberofchildren()
int numOfChildren = session().getCustomer().getNumberOfChildren();
if ( numOfChildren >= 2 && offerId.equals("LifeInsurance")) {
positive="yes";
}
//If response is "yes", then record the offer as accepted.
if (positive.equals("yes")) {
offer.recordEvent ("Accepted");
logInfo("  Offer '" + offer.getSDOLabel() + "' accepted");
}
}
}

3. すべての変更を保存し、インライン・サービスをデプロイします。

5.2.8 ロード・ジェネレータ・スクリプトの実行

第5.1.7項「ロード・ジェネレータ・スクリプトの更新」で、Get Cross Sell OfferアドバイザとOfferFeedbackインフォーマントが含まれるようにロード・ジェネレータ・スクリプトを更新しました。この時点では、オファー選択プロセスは、コストの最小化というパフォーマンス目標にのみ基づいていました。次に、2番目のパフォーマンス目標として売上の最大化を追加し、それにOffer Acceptance Predictorモデルによって計算される受入れ確率の予測値を使用しました。これによってオファー選択プロセスは、両方のパフォーマンス目標に基づくことになります。さらに、特定のプロファイルに合致する顧客にLife Insuranceオファーが提示された場合の受入れバイアスを導入しました。ここで、ロード・ジェネレータ・スクリプトを再度実行して、結果を確認します。

ロード・ジェネレータ・スクリプトを実行する手順は、次のとおりです。

1. 第3.2項「モデルの学習内容のリセット」の手順1から7の説明に従って、Enterprise ManagerのOracle RTD用のシステムMBeanブラウザを使用して、このインライン・サービスの操作データをすべて削除します。

2. ロード・ジェネレータを起動し、前の項で定義したロード・ジェネレータ・スクリプトを開きます。変更は不要です。

3. 「セキュリティ」タブで、「ユーザー名」と「パスワード」を入力し、ロード・ジェネレータ・スクリプトを開始します。約200回スクリプト実行後、「一時停止」アイコンをクリックし、サーバーへのリクエストの送信を一時的に停止します。

RTD_RUNTIME_HOME\logディレクトリにあるサーバー・ログ・ファイルでサーバーの出力を確認します。サーバー・ログ・ファイルの一般的な名前は、server_name-diagnostic[-<n>].logです。

すべてのセッションでは、出力された受入れ確率値がNaNになります。これは、受入れ確率値を計算できるだけ十分なデータの学習がモデルにおいて行われていないことを意味します。確率値がなくても、オファーは提示されることに注意してください。オファーは、組込みのスコア計算ロジックを使用して選択されます。

4. ロード・ジェネレータ・スクリプトの一時停止を解除し、実行回数が2000回になるまでスクリプトを実行します。今回は、サーバー出力に受入れ確率の実際値が出力されます。Life Insurance以外のすべてのオファーでは0.3前後になりますが、Life Insuranceオファーでは導入したバイアスの結果として値が高くなります。

5. 特定のオファーで、モデルが予測する受入れ確率値が顧客のプロファイルに応じて異なることに注目することが重要です。たとえば、顧客が2人(JohnとTom)いて、子供の数のみが異なると仮定します。2人の顧客のLife Insuranceオファーに対する受入れ確率値を調べると(ある時点でのスナップショットとして)、表5-3に示すように、Tomの値のほうが高いことが判明します。これは、Tomには3人の子供がいて、Life Insuranceオファーが提示された場合の受入れ確率が高くなることによります。

表5-3 Life Insuranceオファーの受入れ確率値

顧客名

子供の数

Life Insuranceオファーの受入れ確率値

John Doe

0

.32

Tom Smith

3

.89

顧客に提示されるオファーはCostスコアとMaximize Revenueスコアの組合せに基づいて決定され、オファーごとにモデルによって予測される受入れ確率値にMaximize Revenueが基づくため、2人以上の子供を持つ顧客ではLife InsuranceオファーのMaximize Revenue値が高くなり、結果として、こうした顧客に対しては、他のオファーよりもLife Insuranceの提示率(さらには受入れ率)が高くなります。

5.2.9 結果の検証

ロード・ジェネレータの実行結果を参照するには、デシジョン・センターにログインします。「Cross Selling Offer」選択肢グループを左側のナビゲーション・ボックスでクリックします。ここにOffer Acceptance Predictorモデルの結果が表示されます。「パフォーマンス」タブ→「カウント」サブタブをクリックします。図5-8に示すような結果が表示されます。

図5-8 「Cross Selling Offer」選択肢グループの「パフォーマンス」→「カウント」

「図5-8 「Cross Selling Offer」選択肢グループの「パフォーマンス」→「カウント」」の説明

デシジョン・センターの表はオファーの分布(つまり、オファーごとの提示数と受入れ数)を示しています。Life Insurance以外のすべてのオファーでは、図5-8に示すように、受入れ率が30%前後になっています。これは、ロード・ジェネレータ・スクリプトの設定の当然の結果です(第5.1.7項「ロード・ジェネレータ・スクリプトの更新」を参照)。Life Insuranceの受入れ率は30%よりも高くなっています。これは、 第5.2.7項「特定の顧客に対するオファー受入れバイアスの導入」で人為的なバイアスを導入したためです。このバイアスによって、30%の顧客がすべてのオファーを受入れることに加えて、2人以上の子供を持つ顧客がLife Insuranceをオファーされた場合は必ずそのオファーを受け入れるようにしています。

人為的なバイアスを加えたことで、Life InsuranceオファーではNumberOfChildren属性がオファー受入れの重要な指標となることが、モデル結果に反映されます。デシジョン・センター・レポートで、このことを確認できます。Cross Selling Offer選択肢グループ→「分析」タブ→「ドライバ」サブタブをクリックします。「レポート設定」セクションで、「最小予測」の値を0に変更し、「実行」をクリックします。属性の一覧が、予測値の高い順に表示されます。「最大予測」の最高値は、NumberOfChildren属性になります。この属性が、追加した唯一の人為的なバイアスのためです。対応するオファーは、図5-9の画像のようにLife Insuranceになります。

図5-9 「Cross Selling Offer」→「分析」→「ドライバ」

「図5-9 「Cross Selling Offer」→「分析」→「ドライバ」」の説明

Life Insuranceオファー固有のレポートを表示することで、このオファーに対してNumberOfChildren属性が持つ重要性をさらに分析できます。デシジョン・センターのナビゲーション・ボックスで、「Cross Selling Offer」選択肢グループを開き、選択肢の「Life Insurance」→「分析」タブ→「ドライバ」タブをクリックします。このレポートには、この特定のオファー(Life Insurance)の受入れに対する重要な誘因が示されます。

「レポート設定」セクションで、「最小予測」の値を0に変更し、「実行」をクリックします。属性の一覧が、「予測」値の順に表示されます。NumberOfChildren属性の予測値が最も高くなっています。属性名をクリックして詳細レポートを表示します。その中の1つに、図5-10に示すようなグラフが表示されます。

図5-10 Life Insuranceオファーの「分析」→「ドライバ」

「図5-10 Life Insuranceオファーの「分析」→「ドライバ」」の説明

図5-10に示すグラフは、NumberOfChildrenの値が2以上の場合、オファー受入れと密接な正の相関関係があることを示しています。これは、この属性値(2以上)の場合、このオファーの受入れ数が期待値よりも大きくなることを意味します。同様に、値が0または1の場合も相関関係が非常に密接になりますが、この相関関係は負で、子供がいないか子供が1人の顧客には期待するほどLife Insuranceオファーが受け入れられないことを意味します。

第II部

統合ガイド

第II部の各章では、Javaスマート・クライアント、Javaスマート・クライアントのJSPタグおよび.NETスマート・クライアントを使用してOracle RTDと統合する方法について説明します。また、Oracle RTDのWebサービスを使用する方法についても説明します。

第II部の内容は次のとおりです。

- 第6章「Oracle RTDとの統合について」

- 第7章「Javaスマート・クライアントの使用」

- 第8章「Javaスマート・クライアントのJSPタグの使用」

- 第10章「.NETスマート・クライアントの使用」

- 第11章「Webサービス・クライアントのサンプル」

6 Oracle RTDとの統合について

この章では、Oracle RTDを企業の業務系システムと統合するためのコンポーネント(スマート・クライアント、PHPクライアントおよびWebサービス)について説明します。また、コンポーネント別の各章で様々な統合方法について説明するときに使用するCrossSellインライン・サービスの要素についても解説します。

Oracle RTDには、企業の業務系システムとの統合方法として、次に示すように強力で簡単に使用できる方法が用意されています。

- スマート・クライアント: Java環境および.NET環境では、スマート・クライアントのコンポーネントにより、Real-Time Decision Serverにおける統合点との通信を管理します。

- PHPクライアント統合クラスを介してWebアプリケーションをデプロイ済インライン・サービスと統合します。

- ゼロ・クライアント: ゼロ・クライアントの手法としてWebサービスを介して統合点にアクセスします。

この章と第II部の各章では、Oracle RTD上で実行するデプロイ済インライン・サービスとの統合に、これらの方法を使用する方法について概略を説明します。

デシジョン・スタジオを使用してインライン・サービスをデプロイする方法の詳細は、第I部「概要」を参照してください。統合APIの詳細は、デシジョン・スタジオのオンライン・ヘルプを参照してください。

注意:

Oracle RTDドキュメント全体にわたって次の用語が参照されます。

- RTD_HOME: Oracle RTDクライアント側ツールがインストールされているディレクトリです。

- RTD_RUNTIME_HOME: アプリケーション・サーバーによってOracle RTDが実行されるアプリケーション・サーバー固有ディレクトリです。

詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「Oracle RTDラインタイム環境について」を参照してください。

この章には次のトピックが含まれます:

- 第6.1項「最適な統合方法の選択」

- 第6.2項「CrossSellインライン・サービスについて」

- 第6.3項「Oracle RTD WebサービスとWebサービス・セキュリティ」

- 第6.4項「システム要件と動作保証情報」

6.1 最適な統合方法の選択

Oracle Real-Time Decisionsには、複数の統合方法が用意されています。ご使用の環境に最適な方法を選択するには、使用するプラットフォームやパフォーマンス要件だけでなく、RTDスマート・クライアントが用意している統合方法固有の追加機能についても考慮する必要があります。

この項には次のトピックが含まれます:

- 第6.1.1項「Javaスマート・クライアントについて」

- 第6.1.2項「.NETスマート・クライアントについて」

- 第6.1.3項「JSPスマート・クライアントについて」

- 第6.1.5項「Webサービスについて」

6.1.1 Javaスマート・クライアントについて

Oracle RTDのJavaスマート・クライアントは、デプロイ済インライン・サービスと業務系システムを簡単に統合でき、統合を管理できるコンポーネントです。Java環境を使用する場合は、Javaスマート・クライアントが最適な統合方法です。Javaスマート・クライアントにはその他の統合方法にはない重要な機能が2つ用意されています。1つは、セッション・キーのマッピング(外部のロード・バランサによるHTTPセッション・アフィニティ管理が容易になる機能)で、もう1つはデフォルトのレスポンス処理です。リリース11gのOracle RTDクライアントでは、ユーザー定義のセッション・キーと値のペアをHTTPヘッダーに挿入できる機能もサポートされています(setHttpHeaderメソッドを使用)。デフォルトでは、RTDSESSIONKEYという名前のセッション・キーとrtdセッションIDの値がHTTPヘッダーに追加されます。これより、ハードウェア・ロード・バランサを使用したセッション・アフィニティの管理が可能になります。

Javaスマート・クライアント・インタフェースのファクトリ・メソッドには、単独のサーバーまたはクラスタのメンバーとの通信の確立に必要な最低限の情報を表すパラメータがあります。コンポーネントのフル構成は、接続の確立後に、サーバーからダウンロードされます。この方法では、少数のパラメータ・セットのみがクライアント・アプリケーションで管理され、コンポーネントの大半の構成はサーバーの管理コンソールによって一元管理されます。

サーバーからクライアントに返される構成情報は、同じJava仮想マシン上に作成されているすべてのスマート・クライアント・インスタンスによって共有されます。クライアント側には、この共有構成を管理するクラス(クライアント・サイド・ディスパッチャと呼ばれる)があります。また、セッションのアフィニティ情報もこのクラスによって管理され、リクエストのセッション・キーに基づいて適切なサーバーへリクエストをディスパッチするために使用されます。

Javaスマート・クライアントはスレッドセーフですが、最適なパフォーマンスを実現するには、各スレッドに個別にJavaスマート・クライアントを1つ作成します。Javaスマート・クライアントの各インスタンスは情報と接続を共有するため、複数のインスタンスを持つことによるデメリットは実質的にありません。

Javaスマート・クライアントの作成に使用できるファクトリ・メソッドは複数あります。大半のメソッドは、直接的または間接的に、ファイル・システムまたはWebサーバー上のプロパティ・ファイルを参照します。このプロパティ・ファイルには、単一クラスタ内の1台以上のサーバーに接続するためのアドレスに加えて、サーバーへの接続を構成するその他のプロパティがあります。また、ファクトリ・メソッドに、HTTP URLとポートを直接指定することも、デフォルト・アドレスを使用することも可能です。

クライアントの初期化時に、クライアント構成キャッシュと呼ばれるローカル・ファイルに詳細構成情報が保存されます。これによって、サーバーが使用できない状態のときにクライアントを再起動した場合でも、詳細構成情報にアクセスできます。クライアント構成キャッシュには、すべてのインライン・サービスのすべての統合点に対する、クライアントの一連のデフォルト・レスポンスなどの情報が格納されます。サーバーで構成情報が変更された場合、クライアント構成キャッシュは、クライアントによって自動的に更新されます。

サーバーからクライアントにダウンロードされる構成情報には、クライアントにおいてサーバーとの通信が切断された場合やサーバーが統合点リクエストに適時にレスポンスできない場合に使用されるデフォルト・レスポンスのセットがあります。これによって、個々のトランザクションの可用性とは関係なく、Real-Time Decision Serverとクライアント・アプリケーションとの間におけるサービス・レベル合意(SLA)が維持されます。

これらのデフォルト・レスポンスは個々の統合点の粒度で構成され、各統合点は独自に特化したデフォルト・レスポンスに依存します。特定のデフォルト・レスポンスがサーバー上で再構成された場合は、その変更が通常の統合点レスポンスとともに、自動的にクライアントに伝播されます。

Javaスマート・クライアントでは、Real-Time Decision ServerのWebコンテナから返されたすべてのHTTP Cookieが自動的に追跡管理されます。次回、同じインライン・サービス・キーをリクエストで使用すると、対応するCookieがHTTPリクエストに挿入されます。これによって、外部のロード・バランサがそのインライン・サービス・キーを処理しているサーバー・インスタンスにリクエストをルーティングできるようになります。

他の統合方法を使用してクラスタリングを実現する場合は、アプリケーション自体がインライン・サービス・キーを追跡管理する必要があります。

6.1.2 .NETスマート・クライアントについて

.NET環境では、.NETスマート・クライアントのコンポーネントを使用できます。このコンポーネントには、Javaスマート・クライアントと同じインタフェースをコールする機能が用意されています。ただし、セッション・アフィニティの維持とデフォルト値関連の追加機能はありません。

6.1.3 JSPスマート・クライアントについて

開発者がWebアプリケーションをデプロイ済インライン・サービスと統合するための手段としてJSPクライアント統合タグが用意されています。これらのJSPタグによって、Javaスマート・クライアントによって用意されているAPIと同等のクライアント・インタフェースが実現します。

6.1.4 PHPクライアントについて

PHPクライアントには、Webアプリケーションをデプロイ済インライン・サービスと統合する便利な方法として、PHPクライアント統合クラスが用意されています。PHPを使用すると、対話型のWebページを作成できます。用意されているPHPクラスは、Javaスマート・クライアントと同様の機能を備えています。

6.1.5 Webサービスについて

クライアントは、Webサービスを介してReal-Time Decision Serverにアクセスできます。Webサービスの運用はWSDLファイルに定義され、Webサービスの定義はスキーマ・ファイルで指定します。Oracle RTDのWSDLファイルを使用してユーザー独自の標準Webクライアントを作成できます。

6.2 CrossSellインライン・サービスについて

サンプルのインライン・サービスがデシジョン・スタジオに付属しています。その中の1つが抱合せ販売用のサンプルです。

CrossSellインライン・サービスでは、クレジット・カード会社のコンタクト・センターを想定した単純な実装がシミュレートされます。センターで電話を受けると、顧客および連絡先チャネルに関する情報が入力されます。

この顧客に関する情報に基づいて、顧客に提案する抱合せ販売のオファーが選択されます。オファーの成否が追跡されてサーバーに追跡情報が返されます。これによって、基礎となる意思決定モデルに対して精度を高めるフィードバックが返され、抱合せ販売のオファーが改善されます。

このドキュメントでは、CrossSellインライン・サービスを使用して、各種統合方法について説明します。

CrossSellインライン・サービスを使用するには、特定の表をいくつか作成して移入する必要があります。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のCrossSellサンプル・データの移入に関する項を参照してください。

ランダムではなく、モデルの学習データに基づく提案結果を取得するには、Loadgenスクリプトも実行する必要があります。詳細は、第12.3.6項「サンプル・プロジェクト」を参照してください。

複数の統合点がCrossSellサンプルに用意されています。後述する記載に従って、これらの統合点について理解を深めてください。

インフォーマントでは、適切なパラメータが渡されると、サーバー上で実行されます。そして、アドバイザが実行してデータを返します。統合点へのコールに正しいパラメータを指定するには、最初にオブジェクトIDを特定する必要があります。

この項には次のトピックが含まれます:

- 第6.2.1項「デシジョン・スタジオによるオブジェクトIDの特定」

- 第6.2.2項「セッション・キーおよび引数の特定」

- 第6.2.3項「アドバイザのレスポンスの決定」

- 第6.2.4項「Oracle RTDへのイベント・レスポンスの特定」

6.2.1 デシジョン・スタジオによるオブジェクトIDの特定

注意:

統合点のオブジェクトIDは、ラベルと同じ場合と異なる場合があります。オブジェクトIDは、統合点をメソッド・コールにおいて参照するために使用されます。

オブジェクトIDを特定する手順は、次のとおりです。

1. RTD_HOME\eclipse\eclipse.exeを実行し、デシジョン・スタジオを起動します。

2. 「ファイル」→「インポート」を選択してCrossSellインライン・サービスを開きます。「インポート」が表示されます。

3. 既存のプロジェクトをワークスペースへを選択し、「次」をクリックします。RTD_HOME\examples\CrossSellにあるCrossSellプロジェクトを参照します。「OK」を選択してから「終了」をクリックし、プロジェクトを開きます。

4. 「インライン・サービス・エクスプローラ」を使用して、「統合点」を開きます。図6-1に示すように、「インフォーマント」フォルダと「アドバイザ」フォルダを開き、統合点を表示します。

図6-1 「インライン・サービス・エクスプローラ」の「インフォーマント」と「アドバイザ」

「図6-1 「インライン・サービス・エクスプローラ」の「インフォーマント」と「アドバイザ」」の説明

5. オブジェクトIDの「トグル」アイコンを使用して、オブジェクトIDを「インライン・サービス・エクスプローラ」に表示します。

「トグル」アイコンが選択されていると、オブジェクトIDが「インライン・サービス・エクスプローラ」に表示されます。選択されていないと、表示ラベルが表示されます。

6.2.2 セッション・キーおよび引数の特定

統合点を起動するには、統合点に対応するセッション・キーおよび引数の値を指定する必要があります。リクエストでは、デシジョン・スタジオによって定義されているオブジェクトIDを統合点のセッション・キーおよび引数に対して使用する必要があります。キー名は、デシジョン・スタジオに定義されている統合点用セッション・キー名のいずれかと一致する必要があります。

セッション・キーおよび引数を特定する手順は、次のとおりです。

1. 「CallStart」統合点を選択します。この統合点のエディタの「リクエスト」タブにある「セッション・キー」リストに、セッション・キーへのパス(sessionで始まる)が表示されます。このパス名の最後はセッション・キーのオブジェクトIDです。

注意:

セッション・キーがオブジェクト形式で表示されない場合、オブジェクトIDの「トグル」アイコンを使用して表示設定を変更します。

最後のオブジェクトIDのみセッション・キーで必要です。たとえば、この例では最後の文字列のcustomerIdが使用されます。

2. 統合点の引数を特定するには、詳細ペインを使用して、「リクエスト」タブの受信属性列を表示します。CallStartの入力引数はchannelです。

6.2.3 アドバイザのレスポンスの決定

レスポンスを配信する統合点を、アドバイザと呼びます。デシジョン・スタジオでは、アドバイザの「レスポンス」タブを使用して、アドバイザによって暗黙的に起動されるパラメータ化Decisionオブジェクトを指定することでレスポンスが決まります。Decisionオブジェクトの役割は、それに割り当てられている選択肢グループから最適な選択肢を選択することです。配信される選択肢属性は、選択肢グループの定義に設定されている構成によって決まります。

この例では、OfferRequest統合点がアドバイザになります。それが起動されると、単一の抱合せ販売オファーが返されます。

アドバイザのレスポンスを決定する手順は、次のとおりです。

1. デシジョン・スタジオで、「OfferRequest」統合点を選択し、エディタを表示します。

2. 「レスポンス」タブにある「デシジョン」で、OfferRequestがレスポンスの返信に使用するデシジョンを調べます。「OfferDecision」であることを確認します。

3. 「デシジョン」にある「OfferDecision」をダブルクリックし、その詳細ペインを表示します。

4. 「選択基準」タブにある「選択する選択肢の数」で、OfferRequestによって配信されるレスポンスの数を確認します。

5. 「選択基準」タブにある「選択肢グループ」で、OfferRequestによって使用される選択肢グループを調べます。Offersであることを確認します。

6. 「選択肢」にある「Offers」をダブルクリックし、この選択肢グループに関連付けられている選択肢属性を確認します。アドバイザがコールされたときに、これらの属性が返されます。

ヒント:

デシジョン・スタジオでは、「テスト」ビューを使用して、アドバイザをコールし、返される内容を確認します。このビューには、返されるオファーと、それに付属する属性が表示されます。「テスト」ビューにアクセスするには、「問題」タブの横にある「テスト」タブをクリックします。「送信」アイコンをクリックし、リクエストをサーバーに送信します。

6.2.4 Oracle RTDへのイベント・レスポンスの特定

Oracle RTDの自己学習モデルを更新できるようにするには、選択肢の成否をRTD Serverに送り返すことが重要です。選択肢グループが選択肢イベント・モデルに関連付けられている場合、サーバーが必要とするフィードバックを調べるには、そのモデルに関連付けられているイベントを次のように特定する必要があります。

1. デシジョン・スタジオで、「Offer Acceptance」選択肢イベント・モデルをダブルクリックします。エディタが右側に表示されます。

2. 「選択肢」タブにある「正の結果イベント」により、サーバーの自己学習に影響を及ぼすイベントを確認できます。それらは次のとおりです。

- Interested

- Purchased

これらの結果がインライン・サービスからサーバーに報告されることで、適切なフィードバックがモデルに返されます。

3. OfferResponse統合点には、この情報報告の役割があります。

6.3 Oracle RTD WebサービスとWebサービス・セキュリティ

Oracle RTD Webサービスの一般情報およびOracle RTD Webサービスで使用されるセキュリティ・ポリシーの一般情報は、付録B「Oracle RTD Webサービスおよびクライアント」を参照してください。

6.4 システム要件と動作保証情報

ハードウェアとソフトウェアの要件、プラットフォーム、データベースおよびその他の情報の詳細は、システム要件と動作要件のドキュメントを参照してください。いずれのドキュメントもOracle Technology Network (OTN)から入手できます。

システム要件に関するドキュメントには、ハードウェア要件およびソフトウェア要件、ディスク領域とメモリーの最小要件、必要なシステム・ライブラリ、パッケージ、パッチなどの情報が記載されています。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-requirements-100147.html

動作保証のドキュメントには、サポートされているインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサードパーティ製品が記載されています。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

7 Javaスマート・クライアントの使用

この章では、インライン・サービスをJavaスマート・クライアントと統合する方法について、CrossSellインライン・サービスを例に説明します。

Javaスマート・クライアントAPIの詳細は、デシジョン・スタジオのオンライン・ヘルプを参照してください。

この章には次のトピックが含まれます:

- 第7.1項「前提作業」

- 第7.2項「Javaスマート・クライアントによるインライン・サービスとの統合」

7.1 作業前の準備

Javaスマート・クライアントのサンプルで作業を行う前に、次の作業を実行する必要があります。

1. Java Development Kit (JDK)をインストールし、JAVA_HOME環境変数にそのインストール場所を設定します。JDKは次のサイトから取得できます。
http://developers.sun.com/downloads

サポートされるバージョンの詳細は、第6.4項「システム要件と動作保証情報」に掲載されているドキュメントを参照してください。

2. Oracle RTDファイルをインストールし、Oracle RTDをアプリケーション・サーバーにデプロイします。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。

3. Javaスマート・クライアントのサンプルは、サンプルのCrossSellインライン・サービスと連携して動作します。そのため、最初にOracle RTD DatabaseにCrossSellのサンプル・データを移入してから、デシジョン・スタジオを使用してCrossSellインライン・サービスをデプロイする必要があります。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のCrossSellサンプル・データの移入に関する項を参照してください。インライン・サービスのデプロイについては、第III部「デシジョン・スタジオ・リファレンス」を参照してください。

4. Real-Time Decision Serverを起動します。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』を参照してください。

7.2 Javaスマート・クライアントによるインライン・サービスとの統合

一般的に、Javaスマート・クライアントを使用した統合は、次の手順に従って実行します。

1. プロパティ・ファイルを準備します。

2. インライン・サービスへの接続を作成します。

3. 統合点による出力の決定に必要な様々な情報(接続先統合点やセッション識別用パラメータなど)を識別するリクエストを作成します。

4. リクエストを起動します。

5. レスポンス情報をアドバイザから収集して分析します。

6. 接続を切断します。

この項には次のトピックが含まれます:

- 第7.2.1項「Javaスマート・クライアントのサンプルの準備」

- 第7.2.2項「Javaスマート・クライアントのプロパティ・ファイルの作成」

- 第7.2.3項「Javaスマート・クライアントの作成」

- 第7.2.4項「リクエストの作成」

- 第7.2.5項「レスポンスの確認」

- 第7.2.6項「ループのクローズ」

- 第7.2.7項「クライアントのクローズ」

7.2.1 Javaスマート・クライアントのサンプルの準備

注意:

リリース11gでは、クライアント・クエストを認証する必要があります。つまり、少なくとも、コール時に資格証明のセットを提供する必要があります。デフォルトのポリシーは、ユーザー名パスワードとメッセージ・レベルの暗号化です。ユーザーはユーザー名とパスワードを入力するだけでよく、メッセージ・レベルの暗号化を明示的にリクエストする必要はありません。

この項では、簡単なコマンドライン・アプリケーションに統合されたCrossSellインライン・サービスを使用して、統合にJavaスマート・クライアントを使用する方法について説明します。

このサンプルのソース・コードは、次のファイルにあります。

RTD_HOME\client\Client Examples\Java Client Example\src\com\sigmadynamics\
client\example\Example.java

作業を始める前に、Example.javaを編集して、実際のユーザー名とパスワードを、2つのプロパティ設定文の第2パラメータに追加してください。

props.put("username", "your name");
props.put("password", "your password");

スマート・クライアントのサンプルを準備する手順は、次のとおりです。

1. デシジョン・スタジオを起動し、「ファイル」→「インポート」を選択し、既存のプロジェクトをワークスペースへを選択して「次」をクリックします。

2. 「ルート・ディレクトリの選択」で、RTD_HOME\client\Client Examples\Java Client Exampleを参照し、「OK」をクリックします。「終了」をクリックします。

3. メニュー・バーから「ウィンドウ」→パースペクティブを開く→「Java」を選択します。「コンソール」ビューが表示されない場合は、「ウィンドウ」→「ビューの表示」→「コンソール」を選択します。

4. メニュー・バーから「実行」→「実行」を選択します。

5. 「構成の作成、管理および実行」画面で、「Javaアプリケーション」を選択し、「新規」をクリックします。

6. 「プロジェクト」フィールドの横にある「参照」をクリックし、「JavaSmartClientExample」を選択して「OK」をクリックします。

7. 「メイン・クラス」フィールドの横にある「検索」をクリックし、「例」を選択して「OK」をクリックします。

8. 「適用」→「実行」をクリックします。コンソール・ビューに、次のテキストが表示されます。

Ring! Ring! New telephone call!
Enter a customer ID between 1 and 1000:

9. カーソルをコロンの後に移動し、顧客ID(たとえば、5)を入力し、[Enter]を押します。次のようなレスポンスが表示されます。

Here are the deals we've got for you:
1: ElectronicPayments
Electronic payments eliminate the complications of handling checks.
Enter the line number of the offer that catches your interest, or zero if none do:

10. カーソルを最後のコロンの後に移動し、「1」を入力してオファーを選択します。サーバーによって、最後のメッセージがレスポンスされます。

11. プロセスが繰り返されます。プログラムを終了する場合は、1000よりも大きな顧客IDを入力します。

7.2.2 Javaスマート・クライアントのプロパティ・ファイルの作成

クライアント・アプリケーションでJavaスマート・クライアントが作成されると、コンポーネントのエンドポイント構成となるJavaスマート・クライアント・ファクトリに、プロパティのセットが渡されます。このファイルには、クライアントがサーバー・エンドポイントに接続するために必要な情報が記載されています。デフォルトの構成値を使用するファクトリ・メソッドが別に用意されていますが、明示的にプロパティを指定することをお薦めします。デフォルトのプロパティ・ファイルについては、次の手順で説明します。

ファクトリ・メソッドでは、これらのプロパティを使用してサーバーに接続します。ファクトリがサーバーに接続すると、詳細な構成情報がクライアントにダウンロードされます。これには、サーバーが使用できない状態でクライアントの実行が必要な場合にクライアントで使用する一連のデフォルト・レスポンスなどが含まれます。詳細なクライアント構成は、Javaスマート・クライアント構成キャッシュと呼ばれるローカル・ファイルに保存され、サーバーの構成が変更されると自動的に更新されます。

編集可能なサンプルのプロパティ・ファイルとして、sdclient.propertiesとsdjrfclient.propertiesの2つが用意されています。後者は、JRF Webサービス・クライアント・スタックを使用するユーザー向けです。

プロパティ・ファイルを作成する手順は、次のとおりです。

1. 目的のファイル(sdclient.propertiesまたはsdjrfclient.properties)をRTD_HOME\client\Client Examples\Java Client Example\lib\で探して、編集用に開きます。
リリース時のsdclient.propertiesの内容は次のとおりです。

UseEndpointsInOrder = HTTP1
appsCacheDirectory = ${rootDir}/etc
timeout = 0
HTTP1.type = http
HTTP1.url = http://localhost:8080/

リリース時のsdjrfclient.propertiesの内容は次のとおりです。

clientEndPointClass=com.sigmadynamics.client.jws.JwsClientEndPoint
UseEndpointsInOrder = HTTP1
appsCacheDirectory = ${rootDir}/etc
timeout = 0
HTTP1.type = http
HTTP1.url = http://localhost:8081/

2. 使用するサーバー構成に一致するように、ファイルの内容を変更します。表7-1に、このファイルの各要素に関する説明を示します。特に、有効なキャッシュ・ディレクトリが存在することと、エンドポイントのURLがローカルのReal-Time Decision ServerのURLとポートになっていることを確認してください。

表7-1 sdclient.propertiesおよびsdjrfclient.propertiesファイルの要素

要素

説明

UseEndpointsInOrder

エンドポイント名のカンマ区切りのリスト。スマート・クライアントの初期化時に、このリストに指定された順番でサーバー・クラスタとの初期接続の確立が試行されます。初期化後は、更新されたエンドポイントのリストがサーバーによって提供されます。

このリストにあるエンドポイント名はこのプロパティ・ファイル内の定義にのみ関連し、この名前が他で使用されることはありません。

appsCacheDirectory

クライアント・コンポーネントがサーバーから取得した構成情報を保存する書込み可能ディレクトリを指定するファイルURL。このキャッシュによって、アプリケーションによるクライアント・コンポーネントの初期化時に、Real-Time Decision Serverが使用できない状態になった場合に使用する情報が用意されます。sdclient.propertiesまたはsdjrfclient.propertiesでキャッシュ・ディレクトリを指定する場合は、既存のディレクトリを指定する必要があります。存在しない場合、クライアントはJava仮想マシンの一時ディレクトリを使用します。

timeout

クライアント・コンポーネントの初期化時に、サーバーへの初期接続の試行に適用されるタイムアウト時間(ミリ秒単位)。サーバーに接続すると、サーバーのタイムアウト時間であるIntegrationPointGuaranteedRequestTimeout(JMX MBeanプロパティによって構成)が使用されます。

endpoint_name.type

指定されたエンドポイントのタイプ。現時点では、HTTPのみがサポートされています。

endpointName.url

サーバーのHTTPエンドポイントのHTTPホストとポートを指定するURL。

username

サーバーとの接続に使用するユーザー名。

password

サーバーとの接続に使用するパスワード。

7.2.3 Javaスマート・クライアントの作成

Javaスマート・クライアントを作成するには、次の場所にあるサンプル・アプリケーションのソース・ファイルを開きます。

RTD_HOME\client\Client Examples\Java Client Example\src\com\sigmadynamics\
client\example\Example.java

ヒント:

このサンプルのソース・コードを、各自のJavaスマート・クライアント実装のテンプレートとして使用できます。

Oracle RTD統合をサポートするために、次のインポートが使用されます。

import com.sigmadynamics.client.IntegrationPointRequestInterface;
import com.sigmadynamics.client.IntegrationPointResponseInterface;
import com.sigmadynamics.client.SDClientException;
import com.sigmadynamics.client.SDClientFactory;
import com.sigmadynamics.client.SDClientInterface;

サンプル・アプリケーションのメイン・メソッドには、サンプル・アプリケーションに指定された引数に基づいて、SDClientFactoryを使用してSDClientInterface実装を作成するコードが記述されています。

これらの引数はgetClientに渡され、そこで適切なファクトリ・メソッドが識別されます。

SDClientInterface client = getClient(args);

Javaスマート・クライアントの作成に使用されるファクトリ・メソッドは複数あります。次のように、getClientのコードを調べることで、様々なメソッドを確認できます。

private static SDClientInterface getClient(String[] args) {
try {
Properties props = null;
if (args.length == 0) {
//The default properties file is referenced.
props = getDefaultHttpAddressProperties();
}

if ("-h".equals(args[0])) {
if (args.length < 2)
//This prepares property with the default HTTP address of http://localhost:8080.   //This is the default installation URL and port of Real-Time Decision Server.   //Uses createHttp(java.lang.String, int, boolean).
props = getDefaultHttpAddressProperties();
else
//This prepares property with a supplied HTTP address.
//This is the address and port of your Real-Time Decision Server,
// if it is not at the default address. Uses createHttp(String).
props = getHttpAddressProperties(args[1]);
}

if ("-u".equals(args[0])) {
if (args.length < 2) {
System.out.println("Missing properties file URL argument");
System.exit(-1);
}
//This prepares property with the information supplied in the properties file at   //the address specified. Uses createFromProperties.
props = getPropertiesFromURL(args[1]);
}

if ("-f".equals(args[0])) {
if (args.length < 2) {
System.out.println("Missing properties filename argument");
System.exit(-1);
}
//This prepares property with the information supplied in the properties file.   //Uses createFromPropertiesURL.
props = getPropertiesFromFileName(args[1]);
}

//This sets username and password for RTD Decision service security.
props.put("username", "your name");
props.put("password", "your password");

// This creates RTD Client based on configuration properties.
return SDClientFactory.createFromProperties(props);

} catch (SDClientException e) {
e.printStackTrace();
}
System.out.println("Unrecognized argument");
System.exit(-1);
return null;
}

これらのメソッドの概要は、デシジョン・スタジオのオンライン・ヘルプのJavaスマート・クライアントAPIに関する項を参照してください。

7.2.4 リクエストの作成

リクエストが移入されると、クライアント・アプリケーションでは、SDClientInterfaceのinvokeメソッドをコールしてリクエストをサーバーに送信し、サーバーによって計算処理された選択肢の配列を表すIntegrationPointResponseInterfaceを受信します。

IntegrationPointResponseInterface invoke(IntegrationPointRequestInterface request);

サンプル・アプリケーションでは、次のようにコールされます。

client.invoke(request);

注意:

レスポンスが不要なリクエストやメッセージ配信順序が重要でないリクエストをクライアント・アプリケーションで送信する場合、invokeメソッドではなくinvokeAsyncメソッドを使用できます。

invokeAsyncをコールして送信されるリクエストは、それ以降invokeAsyncやinvokeをコールして送信されるリクエストよりも前に、サーバーに到着するとはかぎりません。メッセージ配信順序が重要な場合は、レスポンスが不要でも、invokeAsyncメソッドではなくinvokeメソッドを使用してください。

CallStart統合点へのリクエストが起動されると、新しいリクエストが準備され、CallInfoに対して起動されます。

// Supply some additional information about the telephone call.
// Apparently the CrossSell service expects very little here --
// just the channel again, which it already knows. Hence this message
// could be left out with no consequences.
request = client.createRequest(INLINE_SERVICE_NAME, "CallInfo");
request.setSessionKey( SESSION_KEY, sCustID );
request.setArg( "channel", "Call");
client.invoke(request);

7.2.5 レスポンスの確認

アドバイザが起動されると、特定数のレスポンス・アイテム(選択肢とも呼ばれる)が返されます。使用するアプリケーションには、返される数だけのレスポンス・アイテムを処理するコードが必要です。詳細は、第6.2.3項「アドバイザのレスポンスの決定」を参照してください。

クライアント・アプリケーションでは、invokeメソッドによって返されたIntegrationPointResponseInterfaceを介して、それらの選択肢にアクセスできます。IntegrationPointResponseInterfaceにより、レスポンス・アイテム・オブジェクトの配列であるResponseItemInterfaceにアクセスできます。ResponseItemInterfaceの各レスポンス・アイテムは、アドバイザのデシジョンによって選択された選択肢オブジェクトに対応します。

com.sigmadynamics.clientパッケージは、各選択肢を値文字列のコレクションとして抽出し、名前文字列によって区別します。

このサンプルでは、リクエストをアドバイザの統合点に対して起動するとき、レスポンスの受信を準備します。

// Based on what the server knows about this customer, ask for some
// product recommendations.
request = client.createRequest(INLINE_SERVICE_NAME, "OfferRequest");
IntegrationPointResponseInterface response = client.invoke(request);
request.setSessionKey( SESSION_KEY, sCustID );

返されるレスポンスの数が判明している場合は、処理を正確に記述できます。レスポンスは配列から読み取られ、顧客に表示されます。

if ( response.size() > 0 ){
// Since I know that CrossSell's OfferDecision returns only
// one Choice, I could get that choice from the response with
// response.get(0); Instead, I'll pretend that
// multiple offers could be returned instead of just one.
System.out.println();
System.out.println("Here are the deals we've got for you:");
ResponseItemInterface[] items = response.getResponseItems();
for ( int i = 0; i < items.length; i++ ){
System.out.println(" " + (i+1) + ": " + items[i].getId());
String message = items[i].getValue("message");
if ( message != null )
System.out.println("   " + message );
}
System.out.println();
System.out.println("Enter the line number of the offer that catches your
interest, or zero if none do: " );

7.2.6 ループのクローズ

多くのインライン・サービスは自己学習が行われるように設計されています。CrossSellインライン・サービスでは、OfferResponseインフォーマントにより、抱合せ販売オファーに対する関心度が選択肢イベント・モデルにフィードバックされます。

// Tell the server the good news.
request = client.createRequest(INLINE_SERVICE_NAME, "OfferResponse");
request.setSessionKey( SESSION_KEY, sCustID );
request.setArg( "choiceName", prodName );

// "Interested" is one of the Choice Events defined for the choice group, Offers.

選択肢イベント・モデルと選択肢を特定するには、第6.2.4項「Oracle RTDへのイベント・レスポンスの特定」を参照してください。

request.setArg( "choiceOutcome", "Interested" );
client.invoke(request);

最後に、CallResolutionインフォーマント(サンプルのCrossSellでセッションの終了用に設計されている)をサーバーにおいて起動することでセッションがクローズします。

// Close the server's session.
request = client.createRequest(INLINE_SERVICE_NAME, "CallResolution");
request.setSessionKey( SESSION_KEY, sCustID );
client.invoke(request);

7.2.7 クライアントのクローズ

クライアント・アプリケーションでSDClientInterfaceの使用を終了して再利用しない場合は、コンポーネントのcloseメソッドをコールし、インスタンス固有の情報を解放します。

client.close();

8 Javaスマート・クライアントのJSPタグの使用

この章では、インライン・サービスをJavaスマート・クライアントのJSPタグと統合する方法について、CrossSellインライン・サービスを例に説明します。

Webアプリケーションをデプロイ済インライン・サービスと統合する便利な方法として、JSPクライアント統合タグを使用する方法があります。JSPを使用すると、埋込みのJavaを使用する対話型Webページを作成できます。用意されているJSPタグは、前の章で説明したJavaスマート・クライアントがベースになっています。

JSPタグを使用するときのオーバーヘッドは無視できます。また、このタグには、スマート・クライアントを同一セッションで自動的に再利用する機能があるためパフォーマンスが向上します。JSPタグを使用してJavaスマート・クライアントが作成されると、同じ名前とプロパティを持つクライアントが存在してクローズされていないかどうかがチェックされます。存在する場合は、そのクライアントが自動的に再利用されます。存在しない場合は、新しいクライアントが作成されます。

スマート・クライアントのJSPタグの詳細は、デシジョン・スタジオのオンライン・ヘルプを参照してください。

この章には次のトピックが含まれます:

- 第8.1項「作業前の準備」

- 第8.2項「Javaスマート・クライアントのJSPタグによるインライン・サービスとの統合」

- 第8.3項「JSPスマート・クライアント・サンプルのデプロイ」

8.1 作業前の準備

JSPクライアント統合タグで作業を行う前に、次の作業を実行する必要があります。

1. Java Development Kit (JDK)をインストールし、JAVA_HOME環境変数にそのインストール場所を設定します。JDKは次のサイトから取得できます。
http://developers.sun.com/downloads

サポートされるバージョンの詳細は、第6.4項「システム要件と動作保証情報」に掲載されているドキュメントを参照してください。

2. Oracle RTDファイルをインストールし、Oracle RTDをアプリケーション・サーバーにデプロイします。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。

3. Javaスマート・クライアントのサンプルは、サンプルのCrossSellインライン・サービスと連携して動作します。そのため、最初にOracle RTD DatabaseにCrossSellのサンプル・データを移入してから、デシジョン・スタジオを使用してCrossSellインライン・サービスをデプロイする必要があります。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のCrossSellサンプル・データの移入に関する項を参照してください。インライン・サービスのデプロイについては、第III部「デシジョン・スタジオ・リファレンス」を参照してください。

4. Real-Time Decision Serverを起動します。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』を参照してください。

8.2 Javaスマート・クライアントのJSPタグによるインライン・サービスとの統合

一般的に、Javaスマート・クライアントを使用した統合は、次の手順に従って実行します。

1. プロパティ・ファイルを準備します。

2. InvokeタグまたはAsyncInvokeタグを使用して、サーバーへのリクエストを作成します。

3. レスポンス情報をアドバイザから収集して分析します。

4. 接続を切断します。

スマート・クライアントのJSPタグを使用した統合サンプル・コードが、RTD_HOME\client\Client Examples\JSP Client Example\example.jspに用意されています。

8.3 JSPスマート・クライアント・サンプルのデプロイ

注意:

Real-Time Decision Serverのポートが8080ではない場合、JSPスマート・クライアント・サンプルをデプロイする前に、次に示すように、クライアント・プロパティ情報を編集する必要があります。

1. WinZipまたはWinRARを使用して、RTD_HOME\client\Client Examples\JSP Client Example\sdclient-test.warを開きます。

2. sdclient-test.warでclient\sdclient.propertiesを開きます。

3. 次のエントリを検索します。

HTTP1.url = http://localhost:8080

4. 使用しているReal-Time Decision Serverのホストとポートに一致するようにURLのlocalhost:8080を変更します。

5. ファイルをsdclient-test.warに保存します。

この項では、簡単なコマンドライン・アプリケーションに統合されたCrossSellインライン・サービスを使用して、統合にスマート・クライアントを使用する方法について説明します。JSPスマート・クライアント・サンプルをアプリケーション・サーバーにデプロイするには、次の各項の手順に従う必要があります。

この項には次のトピックが含まれます:

- 第8.3.1項「WebLogicへのJSPスマート・クライアント・サンプルのデプロイ」

8.3.1 WebLogicへのJSPスマート・クライアント・サンプルのデプロイ

WebLogicにJSPスマート・クライアント・サンプルをデプロイする手順は、次のとおりです。

1. http://weblogic_host:port/consoleのURLから、Oracle RTDドメインのWebLogic Server管理コンソールにアクセスします。ログイン・プロンプトで、管理者のユーザー名とパスワードを入力します。

2. 左側のツリーで、「デプロイ」をクリックします。

3. 「インストール」をクリックします。「インストール」ボタンを有効にするには、最初に「ロックして編集」のクリックが必要になる場合があります。

4. RTD_HOME/client/Client Examplesに移動して「JSP Client Example」を選択し、「次へ」をクリックします。

5. 「このデプロイメントをアプリケーションとしてインストールする」を選択して、「次へ」をクリックします。

6. 「オプション設定」ページで、「名前」に「JSPClientExample」と入力します。「次へ」をクリックします。

7. 設定を確認して「終了」をクリックします。

8. 「保存」→「変更のアクティブ化」をクリックします。

9. 「デプロイメント」の表でJSPClientExampleアプリケーションを選択し、「起動」→ 「すべてのリクエストを処理」をクリックして、アプリケーションを起動します。メッセージが表示されたら、「はい」をクリックします。アプリケーションが実行中になります。

10. アプリケーションにアクセスするには、Webブラウザを起動して、次の場所に移動します:
http://weblogic_host:port/sdclient-test/example.jsp

表示される最初のWebページで、ユーザー名とパスワードの入力を求められます。ユーザー名とパスワードを入力すると、図8-1のような、サービスのコールをシミュレートするWebページが表示されます。

図8-1 JSPスマート・クライアント・サンプル: 顧客IDの入力

「図8-1 JSPスマート・クライアント・サンプル: 顧客IDの入力」の説明

11. 顧客ID(たとえば、5)を入力し、「OK」をクリックします。図8-2に示すように、レスポンス・ページが表示され、コールを終了するオプションとオファーが表示されます。

図8-2 JSPスマート・クライアント・サンプル: オファーの表示

「図8-2 JSPスマート・クライアント・サンプル: オファーの表示」の説明

12. オファーのリンクをクリックするか、「End this call」をクリックします。

9 PHPクライアント

この章では、インライン・サービスをOracle RTD PHPクライアントと統合する方法について、CrossSellインライン・サービスを例に説明します。

Webアプリケーションをデプロイ済インライン・サービスと統合する便利な方法として、PHPクライアント統合クラスを使用する方法があります。PHPを使用すると、対話型のWebページを作成できます。用意されているPHPクラスは、前の章で説明したJavaスマート・クライアントと同様の機能を備えています。

この章には次のトピックが含まれます:

- 第9.1項「作業前の準備」

- 第9.2項「Oracle RTD PHPクライアントによるインライン・サービスとの統合」

9.1 作業前の準備

PHPクライアントのサンプルで作業を行う前に、次の作業を実行する必要があります。

1. Java Development Kit (JDK)をインストールし、JAVA_HOME環境変数にそのインストール場所を設定します。JDKは次のサイトから取得できます。
http://developers.sun.com/downloads

サポートされるバージョンの詳細は、第6.4項「システム要件と動作保証情報」に掲載されているドキュメントを参照してください。

2. Oracle RTDファイルをインストールし、Oracle RTDをアプリケーション・サーバーにデプロイします。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。

3. PHPクライアントのサンプルは、サンプルのCrossSellインライン・サービスと連携して動作します。そのため、最初にOracle RTD DatabaseにCrossSellのサンプル・データを移入してから、デシジョン・スタジオを使用してCrossSellインライン・サービスをデプロイする必要があります。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のCrossSellサンプル・データの移入に関する項を参照してください。インライン・サービスのデプロイについては、第III部「デシジョン・スタジオ・リファレンス」を参照してください。

4. Real-Time Decision Serverを起動します。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』を参照してください。

5. Apacheとmod_phpなど、PHP 5.2スクリプトの評価に適した環境をインストールして構成します。サポートされるバージョンとオペレーティング・システムについては、第6.4項「システム要件と動作保証情報」に掲載されているドキュメントを参照してください。

6. PHP SoapまたはNuSoap (リリース0.7.3)のどちらかをSourceForgeからインストールします。

9.2 Oracle RTD PHPクライアントによるインライン・サービスとの統合

一般に、Oracle RTD PHPクライアントを使用した統合は、次の手順で実行します。

1. Oracle RTD PHPクライアントの.iniファイルを準備します。

2. クライアント・オブジェクトを準備します。

3. 次の情報を識別するリクエストを作成します。

- 接続先の統合点

- セッションを識別するパラメータ

- 統合点による出力の決定に必要なその他の任意情報

4. Oracle RTD PHPメソッドの構文を使用してインフォーマントのリクエストを作成します。

5. Oracle RTD PHPメソッドの構文を使用してアドバイザからのレスポンスを解析します。

6. 接続を切断します。

PHPクライアントの実践的な使用例がRTD_HOME\client\Client Examples\PHP Client Exampleに2つ用意されています。

- example_nusoap.phpは、Oracle RTD PHPクライアントをNuSoapと併用する方法を示しています。

- example.phpは、同じ機能を、PHP Soapを使用して実装しています。

この項の残り部分は、次のような内容となっています。

- 第9.2.1項「PHPクライアント・サンプルのデプロイ」

- 第9.2.2項「Oracle RTD PHPクライアントの.iniファイルの設定」

- 第9.2.3項「Nusoapパス・ライブラリの場所の編集」

- 第9.2.4項「Oracle RTD PHPクライアントの作成」

- 第9.2.5項「リクエストの作成」

- 第9.2.6項「レスポンスの確認」

- 第9.2.7項「ループのクローズ」

9.2.1 PHPクライアント・サンプルのデプロイ

この例では、簡単なPHPページよってCrossSellインライン・サービスを実行して、PHPクライアントの使用方法を説明します。次のセクションの説明に従って、PHPクライアントのサンプルをアプリケーション・サーバーにデプロイする必要があります。

PHPクライアントのサンプルをApacheにデプロイする手順は次のとおりです。

1. 次のOracle RTD PHPクライアント・ライブラリを

- RTD_HOME\client\Client Examples\PHP Client Example\rtd

PHPインクルード・パス上の場所またはApache HTTPサーバーのWebサイト・ページ・フォルダ(htdocsなど)に置きます。

このrtdフォルダには、次のファイルが格納されています。

- DecisionService.wsdl

- rtd.client.base.php

- rtd.client.nusoap.php

- rtd.client.phpsoap.php

- rtd_client_conf.ini

- rtd_client_nusoap_conf.ini

注意:

セットアップの一環として、使用する.iniファイルが使用環境に適切であることを確認してください。詳細は、第9.2.2項「Oracle RTD PHPクライアントの.iniファイルの設定」を参照してください。

2. 該当するOracle RTD PHPクライアント・サンプル(PHP Soapの場合はexample.php 、NuSoapの場合はexample_nusoap.php)を、ApacheサーバーでPHPスクリプトを供給するパスとして構成されているパスに置きます(/home/www/example.phpなど)。

3. アプリケーションにアクセスするには、Webブラウザを起動して、次の場所に移動します:
http://apache_host:port/example.php (PHPの場合)

または

http://apache_host:port/example_nusoap.php (NuSoapの場合)

4. 顧客ID(たとえば、5)を入力し、「OK」をクリックします。

このサンプルについては、後続の各項で説明します。

9.2.2 Oracle RTD PHPクライアントの.iniファイルの設定

Oracle RTDで用意されている.iniファイルは次のとおりです。

- rtd_client_conf.ini (PHP Soap用)

- rtd_client_nusoap_conf.ini (NuSoap用)

これらのファイルにあるPHPクライアントのプロパティは次のとおりです。

- wsdl: wsdlファイルの場所。PHP Soapで使用します。

注意:

PHPクライアント・ライブラリがPHPインクルード・パス上の場所にある場合は、次のいずれかの方法でwsdlの場所を指定できます。

- フル・パス名を指定する。例: c:\php\includes\rtd\DecisionService.wsdl

- DecisionService.wsdlファイルをApache HTTPサーバーのWebサイト・ページ・フォルダ(htdocsなど)にコピーしてある場合は、 wsdlプロパティに相対パス名を指定する。例: rtd\DecisionService.wsdl

- clientClass: クライアント・クラス名

- appsCacheClass: キャッシュ・クラス名

- appsCacheFile: デフォルト・レスポンスの一時ファイル

- clientTimeout: Oracle RTD統合点の起動タイムアウト(秒)。これはオプションです。

- endpointUrl: デシジョン・サービスのURL

- username: サーバーとの接続に使用するユーザー名

- password: サーバーとの接続に使用するパスワード

rtd_client_conf.iniの例

rtd_client_conf.iniの例を次に示します。

# RTD integration service wsdl file path
wsdl=rtd/DecisionService.wsdl

clientClass=Oracle_Rtd_Client_Impl
appsCacheClass=Oracle_Rtd_Client_File_Cache

# temp file for default response
appsCacheFile=c:/temp/rtd_default.dat

# RTD integration point invoke timeout in seconds
clientTimeout=2

# RTD service url
endpointUrl=http://localhost:8080/

rtd_client_nusoap_conf.iniの例

rtd_client_nusoap_conf.iniの例を次に示します。

# client class name
clientClass=Oracle_Rtd_Client_Nu

# cache class name
appsCacheClass=Oracle_Rtd_Client_File_Cache

# temp file for default response
appsCacheFile=c:/temp/rtd_default_nusoap.dat

# RTD integration point invoke timeout in seconds
clientTimeout=2

# RTD service url
endpointUrl=http://localhost:8080/

.iniファイルの編集

Oracle RTDには、構成用の基礎としてクライアントのサンプルが用意されています。ファイルの設定が使用するシステムと一致していることを確認する必要があります。必要な場合は、ファイルを編集し、構成に応じて正しく設定してください。

たとえば、Real-Time Decision Serverがlocalhost上で実行されており、そのリスニング・ポートが8080でない場合は、Oracle PHPクライアントのサンプルをデプロイする前に、該当する.iniをファイルを次のように編集する必要があります。

1. RTD_HOME\client\Client Examples\PHP Client Example\rtdにある該当するファイル(rtd_client_conf.iniまたはrtd_client_nusoap_conf.ini)をテキスト・エディタで開きます。

2. 次のエントリを検索します。

endPointUrl = http://localhost:8080

3. 使用しているReal-Time Decision Serverのホストとポートに一致するようにURLのlocalhost:8080を変更します。

4. ファイルを保存します。

クライアントのプロパティの使用方法

クライアント・アプリケーションは、Oracle RTD PHPクライアントを作成すると、コンポーネントのエンドポイント構成を表す一連のプロパティをOracle RTD PHPクライアント・ファクトリに渡します。

引数が指定されていない場合、クライアント・ファクトリはparse_ini_fileをrtd_client_conf.iniに適用して、その設定を導出します。

ファクトリ・メソッドは、これらの設定を使用してサーバーに接続します。Oracle RTD PHPクライアントは、サーバーに接続すると、詳細な構成情報をダウンロードします。これには、サーバーが使用できない状態でクライアントの実行が必要な場合にクライアントで使用する一連のデフォルト・レスポンスなどが含まれます。

詳細なクライアント構成は、Oracle RTD PHPクライアント構成キャッシュと呼ばれるローカル・ファイルに保存され、サーバーの構成が変更されるたびに自動的に更新されます。

9.2.3 Nusoapパス・ライブラリの場所の編集

Oracle RTDクライアント・ライブラリでは、nusoap.phpが<php_includes>/nusoap/nusoap.phpという形式のディレクトリ構造に配置されていることを前提としています。<php_includes>は、PHPインストールのインクルード・ディレクトリです。

しかし、nusoapファイルは、libおよびsampleディレクトリにダウンロードされています。

次の作業を実行してください。

1. libディレクトリの中身を<php_includes>/nusoapにコピーします。

2. rtd.client.nusoap.phpの次のエントリを編集し、

- include_once "nusoap/nusoap.php"

実際のnusoapライブラリの場所を反映させます。

NuSoapとのOracle RTD統合をサポートするには、 次のincludeを使用します。

- include_once "rtd/rtd.client.nusoap.php"

9.2.4 Oracle RTD PHPクライアントの作成

Oracle RTD PHPクライアントを作成するには、使用環境に応じたサンプルPHPスクリプトのソース・ファイル(PHP Soapを使用する場合はexample.php、NuSoapを使用する場合はexample_nusoap.php)を開きます。

NuSoapとのOracle RTD統合をサポートするには、 次のincludeを使用します。

include_once "rtd/rtd.client.nusoap.php";

PHP SoapとのOracle RTD統合をサポートするには、 次のincludeを使用します。

include_once "rtd/rtd.client.phpsoap.php";

example.phpとexample_nusoap.phpは、Oracle RTD PHPクライアントのインスタンスを取得する別々の方法を示しています。

example.phpが示すように、インラインで明示的に設定を指定してクライアントを取得できます。

$client = Oracle_Rtd_Client_Factory::createClient(array(
"wsdl"=>"C:/OracleBI/RTD/client/Client Examples/PHP Client Example/rtd/DecisionService.wsdl",
"clientClass"=>"Oracle_Rtd_Client_Impl",
"appsCacheClass"=>"Oracle_Rtd_Client_File_Cache",
"appsCacheFile"=>"C:/temp/rtd_default.dat",
"clientTimeout"=>2,
"username"=>"your name",
"password"=>"your password",
"endpointUrl"=>"http://localhost:9704/"
));

example_nusoap.phpでは、これらの設定が、サンプルPHPスクリプトと同じディレクトリにある.iniファイル(RTD_HOME\client\Client Examples\PHP Client Example\rtd\rtd_client_nusoap_conf.ini)から解析されます。

$config = parse_ini_file("rtd_client_nusoap_conf.ini");
$client = Oracle_Rtd_Client_Factory::createClient($config);

9.2.5 リクエストの作成

次のコード行でRequestオブジェクトを作成します。

$request = $client->createRequest();

リクエストは、宛先のインライン・サービスを指定して構成する必要があります。

$request->setServiceName("CrossSell");

デプロイメント状態を使用して、インライン・サービスの選択をさらに限定できます。省略すると、最も高い状態でデプロイされたインライン・サービスがリクエストを受信します(本番はQAより高く、QAは開発より高い)。

$request->setDeploymentState("Development");

リクエストの詳細は、インライン・サービスごとに異なります。次の例では、CallStartインフォーマントがcustomerIdという名前のセッション・キーとchannelという名前の追加パラメータを要求します。

$request->setIntegrationPointName("CallStart");
$request->setSessionKey("customerId", 3);
$request->setArg("channel", "Call");

リクエストを移入したら、クライアント・アプリケーションはクライアントのinvokeメソッドを呼び出して、リクエストをRTD Serverに送信します。

$client->invoke($request);

9.2.6 レスポンスの確認

アドバイザが起動されると、複数のレスポンス・アイテム(選択肢とも呼ばれる)が返されます。アプリケーションには、これらのレスポンス・アイテムを処理するコードが必要です。詳細は、第6.2.3項「アドバイザのレスポンスの決定」を参照してください。

クライアントPHPスクリプトでは、クライアントのinvokeメソッドによって返されたレスポンス・インタフェースを介して、それらの選択肢にアクセスできます。このオブジェクトによってResponseItemオブジェクトの配列にアクセスできます。各ResponseItemオブジェクトは、アドバイザのデシジョンによって選択された選択肢オブジェクトに対応しています。

選択肢の名前にはgetId()メソッドでアクセスできます。選択肢の属性にはgetAttributes()によってアクセスできます。

$request->setIntegrationPointName("OfferRequest");
$response = $client->invoke($request);

PHPサンプル・スクリプトでは、各レスポンス・アイテムが、RTDサーバーによって指定された順序でWebページに出力されます。

$items = $response->getResponseItems();
foreach ($items as $item) {
echo "<h1>" . $item->getId() . "</h1>";
foreach ($item->getAttributes() as $key => $value) {
echo $key . ': '.$value."<br>";
}
}

9.2.7 ループのクローズ

多くのインライン・サービスは自己学習が行われるように設計されています。CrossSellインライン・サービスでは、OfferResponseインフォーマントにより、抱合せ販売オファーに対する関心度が選択肢イベント・モデルにフィードバックされます。単純化するため、次の例では、レスポンス・アイテムの中で最上位にランク付けされた選択肢に対して「Interested」選択肢イベントを登録します。

if ($response->size() > 0) {
$request->setIntegrationPointName("OfferResponse");
$request->setArg("choiceName", $response->get(0)->getId());
$request->setArg("choiceOutcome", "Interested");
$client->invoke($request);
}

選択肢イベント・モデルと選択肢の詳細は、第6.2.4項「Oracle RTDへのイベント・レスポンスの特定」を参照してください。

最後に、CallResolutionインフォーマントを起動してセッションをクローズします。CrossSellサンプルでは、このインフォーマントがセッションを終了し、リソースを解放して、セッションの終了を待機しているタスクの実行をトリガーするように設計されています。

$request->setIntegrationPointName("CallResolution");
$client->invoke($request);

10 .NETスマート・クライアントの使用

この章では、インライン・サービスを.NETスマート・クライアントと統合する方法について、CrossSellインライン・サービスを例に説明します。

.NETスマート・クライアントにより、Java APIとほぼ同等のクライアントを実現し、アプリケーションからコールします。.NETスマート・クライアントの現行の実装では、Javaスマート・クライアントが持つ高度な機能の一部(セッション・アフィニティ管理やデフォルトのレスポンス処理など)がサポートされていません。

.NETスマート・クライアントAPIの詳細は、デシジョン・スタジオのオンライン・ヘルプを参照してください。

この章には次のトピックが含まれます:

- 第10.1項「作業前の準備」

- 第10.2項「.NETスマート・クライアントによるインライン・サービスとの統合」

- 第10.3項「.NET統合のサンプル」

10.1 作業前の準備

.Netスマート・クライアントで作業を行う前に、次の作業を実行する必要があります。

1. Java Development Kit (JDK)をインストールし、JAVA_HOME環境変数にそのインストール場所を設定します。JDKは次のサイトから取得できます。
http://developers.sun.com/downloads

サポートされるバージョンの詳細は、第6.4項「システム要件と動作保証情報」に掲載されているドキュメントを参照してください。

2. Oracle RTDファイルをインストールし、Oracle RTDをアプリケーション・サーバーにデプロイします。詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。

3. .NETスマート・クライアントのサンプルは、サンプルのCrossSellインライン・サービスと連携して動作します。そのため、最初にOracle RTD DatabaseにCrossSellのサンプル・データを移入してから、デシジョン・スタジオを使用してCrossSellインライン・サービスをデプロイする必要があります。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のCrossSellサンプル・データの移入に関する項を参照してください。インライン・サービスのデプロイについては、第III部「デシジョン・スタジオ・リファレンス」を参照してください。

4. Real-Time Decision Serverを起動します。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』を参照してください。

10.2 .NETスマート・クライアントによるインライン・サービスとの統合

一般的な統合手順は次のとおりです。

1. Oracle RTDスマート・クライアントをアプリケーション・コード内に作成します。

2. インライン・サービスと統合点に対して送信するリクエストを作成します。

3. リクエストにおいて引数とセッション・キーを移入します。

4. スマート・クライアントを使用してリクエストを起動します。

5. リクエストがアドバイザに対して起動された場合、レスポンスを確認します。

6. 終了したらスマート・クライアントをクローズします。

.NETスマート・クライアントは、RTD_HOME\client\Client Examples\Dot Net Client Example\sdclient.dllにあります。このファイルをアクセス可能にするには、アプリケーションと同じ場所に配置する必要があります。

10.3 .NET統合のサンプル

.NET統合クライアントのサンプルは、RTD_HOME\client\Client Examples\Dot Net Client Example\DotNetSmartClientExample.slnにあります。このサンプルは、Microsoft Visual C# 2010 Expressなどの.NET開発ツールで開いて、実行やデバッグができます。

このサンプルでは、インフォーマントとアドバイザの統合点がCrossSellインライン・サービスに対して起動されます。このインライン・サービスの理解を深めるには、第6.2項「CrossSellインライン・サービスについて」を参照してください。サンプルでは、統合点が起動され、アドバイザからの戻り値がコンソールに出力されます。

Microsoft Visual Studioの起動後、サンプルをこの開発ツールで実行する手順は次のとおりです。

1. メニュー・バーから「File」→「Open」→「Project」を選択します。

2. 「File Name」に「RTD_HOME\client\Client Examples\Dot NET Client Example\DotNetSmartClientExample.sln」を選択し、「Open」をクリックします。

3. Real-Time Decision Serverが実行しているホストまたはポートがデフォルトのlocalhost:9704と異なる場合、次の手順を実行します。

- 右側の「Solution Explorer」ウィンドウで、DotNetSmartClientExample.csをダブルクリックします。

- 次の行を探します。

SDClient client = new SDClient("http://localhost:9704","your name", "password");

- Real-Time Decision Serverが実行しているホストとポートに一致するようにlocalhost:9704を変更します。

- このファイルを保存して閉じます。

4. メニュー・バーから「Debug」→「Start」を選択します。コンソール・ウィンドウに、次のテキストが表示されます。

Ring! Ring! New telephone call!
Enter a customer ID between 1 and 1000:

5. カーソルをコロンの後に移動し、顧客ID(たとえば、5)を入力し、[Enter]を押します。次のようなレスポンスが表示されます。

Here are the deals we've got for you:
1: ElectronicPayments
Electronic payments eliminate the complications of handling checks.
Enter the line number of the offer that catches your interest, or zero if none do:

6. カーソルを最後のコロンの後に移動し、「1」を入力してオファーを選択します。サーバーによって、最後のメッセージがレスポンスされます。

7. プロセスが繰り返されます。プログラムを終了するには、数字を入力せずに、顧客IDプロンプトで[Enter]を押します。

11 Webサービス・クライアントのサンプル

この章では、Oracle RTD Webサービスを企業の業務系システムと統合する方法について、NetBeans IDEとOracle RTD DecisionService.wsdlを例に説明します。

Real-Time Decision Serverの統合点は、ゼロ・クライアントの手法でも使用できます。デプロイ済のインライン・サービスの統合点は、Webサービスの定義によって公開されます。

デプロイ済の統合点を同期して起動したり非同期で起動する機能は、Real-Time Decision ServerによってWebサービスとして公開されます。これらの操作の定義は、次の場所からWSDLファイルとして入手できます。

RTD_HOME\deploy\DecisionService\DecisionService.wsdl

WSDLファイルには、使用可能なすべての複合型と操作が定義されています。

Oracle Real-Time Decisionsリリース2.2では構造がわずかに変更されて、デシジョン・サービスがWS-I Basicレベルに準拠するように改良されています。以前のバージョンのWSDLファイルの名前は次のとおりです。

RTD_HOME\deploy\DecisionService\DecisionServiceLegacy.wsdl

新しいWSDLを使用して新しいクライアントを開発することをお薦めしますが、DecisionServiceLegacy.wsdlに定義されているプロトコルにもサーバーはこれまでと同様に対応でき、既存クライアント機能が実現されます。

この章では、NetBeans IDEを使用して、RTD DecisionService WSDLファイルからJava WSDL Webサービス・クライアントを作成する方法について詳細に説明します。また、Webサービス・プロジェクトのMainクラスのコードも示します。

この章には次のトピックが含まれます:

- 第11.1項「前提作業」

- 第11.2項「新しいNetBeans Javaアプリケーション・プロジェクトの作成」

- 第11.3項「用意されているJavaコードの追加およびクライアントのテスト」

11.1 作業前の準備

Webサービス・クライアントで作業を行う前に、次の作業を実行する必要があります。

1. http://www.netbeans.org/downloads/index.htmlからNetBeans IDE (Javaバンドル)をダウンロードします。

2. NetBeans IDEをインストールして起動します。

11.2 新しいNetBeans Javaアプリケーション・プロジェクトの作成

Netbeans IDEで、新しいNetBeans Javaアプリケーション・プロジェクトを作成するには、次の手順を実行します:

1. 上部のメニューで「File」→「New Project」を選択します。

2. 「New Project」ダイアログで次のようにします。

- 「Categories」で「Java」を選択します。

- 「Projects」で「Java Application」を選択し、「Next」をクリックします。

3. 「Project」に名前を入力し、「Finish」をクリックします。
JAX-RPC Webサービス・プラグインのインストール

4. 上部のメニューで「Tools」→「Plugins」→「Available Plugins」を選択します。

5. 「Plugins｜Plugins」ダイアログで「Available Plugins｜Available Plugins」タブをクリックします。

6. 「Web Services plug-in」チェック・ボックスを選択し、「Install」をクリックします。プラグインをインストールします。
Oracle RTD Webサービス・クライアントの作成

7. 「Projects」エクスプローラで、使用するプロジェクトを右クリックし、 「New」→「Web Service Client...」を選択します。

8. 「New Web Service Client」ダイアログで「Local File」ラジオ・ボタンを選択します。

9. 「Local File:」の横にある「Browse...」ボタンをクリックします。

10. Oracle Real-Time Decisionsインストール内にあるDecisionService.wsdlファイルを探します。
例:

C:\OracleBI\RTD\client\Client Examples\Web Service Client Example\DecisionService.wsdl

C:\OracleBI\RTD\deploy\DecisionService\DecisionService.wsdl

11. 「Client Style」で「JAX-WS Style」を選択します。

12. 「Package」でプロジェクト・パッケージを選択します。

13. 「Finish」をクリックします。

11.3 用意されているJavaコードの追加およびクライアントのテスト

用意されているJavaコードを追加してクライアントをテストするには、次の手順を実行します:

1. 「Projects」エクスプローラで「oracle.rtd.test」パッケージを作成します。

2. このパッケージの下にMainクラスとSecurityHandlerクラスを作成します。RTD_HOME\client\Client Examples\Web Service Client ExampleにあるファイルMain.javaとSecurityHandler.javaと同様に、このサンプルのクラス・コンテンツを使用してください。
システムによって生成されたMainクラスは削除してかまいません。

3. 「Web Service References」の下にある「DecisionService」を右クリックし、「Configure Handlers...」をクリックします。

4. 「Configure Message Handlers」ウィンドウで「Add」をクリックして、oracle.rtd.test.SecurityHandlerクラスをハンドラとして追加し、「OK」をクリックします。

5. 上部のメニューから「Run」→「Run Main Project」を選択します。

6. IDEの下部にある「Output」タブで出力を確認します。

第III部

デシジョン・スタジオ・リファレンス

第III部の各章では、デシジョン・スタジオを使用してインライン・サービスを開発するために必要な概念、コンポーネントおよびAPIについて詳細に説明します。

第III部の内容は次のとおりです。

- 第12章「デシジョン・スタジオについて」

- 第13章「デシジョン・スタジオの要素とAPIについて」

- 第14章「インライン・サービスのデプロイ、テストおよびデバッグ」

12 デシジョン・スタジオについて

デシジョン・スタジオはインライン・サービスを定義および管理するためのツールです。デシジョン・スタジオにはインライン・サービスのすべての機能が公開されます。デシジョン・スタジオは、Javaの基本的な知識があり、アプリケーション開発およびライフサイクルの問題を総合的に理解するITプロフェッショナルを対象ユーザーとしています。この章では、インライン・サービスの2つの大きなカテゴリであるオブザーバとアドバイザについて概説するとともに、デシジョン・スタジオおよび関連する外部ファイル・ディレクトリにおけるインライン・サービスの様々な側面やコンポーネントの表示について説明します。

デシジョン・スタジオは、統合開発環境(IDE)パラダイムに準拠したリッチ・クライアント・アプリケーションです。デシジョン・スタジオの左側は「インライン・サービス・エクスプローラ」ビュー、右側はエディタ・ビューになっています。このナビゲータ・ビューには、事前定義されたインライン・サービス・フォルダ構造が表示されます。各フォルダ内のアイテムはインライン・サービスのメタデータ要素です。デシジョン・スタジオを使用して、メタデータ要素の追加、編集および削除ができます。メタデータ要素をダブルクリックすると、その要素の詳細がオブジェクト・エディタに表示されます。メタデータ要素のタイプごとに固有のエディタが用意されています。要素はXMLメタデータ(.sda)ファイルとして保存されます。メタデータからJavaクラス(.java)が自動生成され、.classファイルにコンパイルされます。これらの.classファイルがランタイム・インライン・サービスを構成します。デシジョン・スタジオはEclipse IDEに基づいています。それは、インライン・サービスの管理用機能と、汎用のJava開発ツールやソフトウェア構成管理(SCM)システムとの統合をはじめとするEclipse IDEの機能を兼ね備えています。

注意:

Oracle RTDドキュメント全体にわたって次の用語が参照されます。

- RTD_HOME: Oracle RTDクライアント側ツールがインストールされているディレクトリです。

- RTD_RUNTIME_HOME: アプリケーション・サーバーによってOracle RTDが実行されるアプリケーション・サーバー固有ディレクトリです。

詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「Oracle RTDラインタイム環境について」を参照してください。

この章には次のトピックが含まれます:

- 第12.1項「インライン・サービスについて」

- 第12.2項「デシジョン・スタジオとEclipse」

- 第12.3項「デシジョン・スタジオのプロジェクトの概要」

- 第12.4項「インライン・サービスのディレクトリ構造」

- 第12.5項「インライン・サービスのセキュリティ」

12.1 インライン・サービスについて

インライン・サービスは、企業全体のビジネス・プロセスにおける重要な局面での、リアルタイムかつ継続的な監視およびアドバイスを実行するデプロイ可能なアプリケーションです。インライン・サービスはビジネス・プロセス全体を追従するのではなく、プロセス内の特定の識別ポイントに焦点を当てます。インライン・サービスは、デシジョン・スタジオを使用して構成およびデプロイされ、デシジョン・センターを使用して分析および調整されます。インライン・サービスの実行はReal-Time Decision Serverで行われます。

12.1.1 インライン・サービスの構成

インライン・サービスは、デシジョン・スタジオを使用して構成およびデプロイされます。要素がプロジェクトに追加され、機能ロジックを含むJavaスクリプトレットが特定の要素に追加されます。インライン・サービスを保存すると、XMLメタデータが作成されてJavaコードが生成され、Real-Time Decision Serverにデプロイされて、ここでインライン・サービスが実行されます。

12.1.2 インライン・サービスの一般的なタイプ

インライン・サービスは、次に示す実行可能な2つの主要機能のうち、1つのみに特化して設計できます。

- ビジネス・プロセスの監視

- ビジネス上の重要な意思決定の方法に関するビジネス・プロセスへのアドバイス

注意:

特化したインライン・サービスを持つと便利ですが、一般に、インライン・サービスは監視と意思決定という2つの主要機能を兼備します。

この項では、特化したインライン・サービスの2つの大きなカテゴリについて説明します。

- 第12.1.2.1項「オブザーバ・インライン・サービス」

- 第12.1.2.2項「アドバイザ・インライン・サービス」

12.1.2.1 オブザーバ・インライン・サービス

監視では、インライン・サービスはビジネスに関するデータが収集される収集ポイントに焦点を当てます。このデータにおける傾向と相関関係の洞察および検出は、自己学習モデルによって行われます。このタイプのインライン・サービスをオブザーバといいます。

これらの検出は、シン・クライアント・ツールであるデシジョン・センターによって確認できます。デシジョン・センターでは、ビジネス・ユーザーがこれらの洞察を利用して意思決定を行います。またビジネス・ユーザーは、デシジョン・センターを使用してインライン・サービスの管理および最適化も行います。

12.1.2.2 アドバイザ・インライン・サービス

ビジネス・プロセスのアドバイスの実行では、主要な意思決定ポイントおよび収集ポイントでインライン・サービス間が接続されます。意思決定ポイントとは、全体的なビジネス・プロセスにおいて、製品の推奨や顧客維持オファーの提示など、主要なビジネス上の意思決定が行われる場所です。最初に収集ポイントでデータが集められ、自己学習モデルを使用して検出され、組織の実現目標としているパフォーマンス・メトリックに従って選択肢がスコアリングされます。インライン・サービスにより、ビジネス・プロセスの意思決定ポイントで、最高スコアの選択肢が提示されます。フィードバックを介してこれらの選択肢の成功レベルがインライン・サービスに返されると、より適切な選択肢を提示するようにモデルの機能が向上します。このタイプのインライン・サービスをアドバイザといいます。

12.2 デシジョン・スタジオとEclipse

デシジョン・スタジオは、Eclipse Foundation社により開発されたオープン・ソースJava IDEであるEclipseに基づいています。デシジョン・スタジオはEclipse環境に対する標準プラグインとして存在します。Eclipseを使用している場合は、この環境を利用して、追加の開発機能や高度な機能を使用できます。Eclipseに精通していない場合でも、デシジョン・スタジオを完全に透過的に使用できます。

注意:

64ビット・マシンでデシジョン・スタジオを実行するには、コマンドラインで32ビットJDKを指定する必要があります。例:

RTD_HOME\eclipse\eclipse.exe -vm "C:\jdk160_32bit\jre\bin\javaw"

この項には次のトピックが含まれます:

- 第12.2.1項「デシジョン・スタジオのワークスペースの選択」

- 第12.2.2項「Javaコンパイラ準拠レベルの設定」

- 第12.2.3項「インライン・サービス・エクスプローラについて」

- 第12.2.4項「コード生成」

- 第12.2.5項「デシジョン・スタジオのパースペクティブおよびビューについて」

- 第12.2.6項「ビューの配置とエディタのサイズ変更」

- 第12.2.7項「要素へのカスタム・ロジックの追加」

- 第12.2.8項「生成済コードの上書き」

12.2.1 デシジョン・スタジオのワークスペースの選択

デシジョン・スタジオの起動時にセッションのワークスペースを選択できます。デフォルトのワークスペースは、C:\Documents and Settings\username\Oracle RTD Studioです。必要に応じて、ワークスペースの場所をそれ以降のデフォルトとして設定できます。

また、セッション中にメニューから「ファイル」→ワークスペースの切替えを選択することでも、ワークスペースを変更できます。

12.2.2 Javaコンパイラ準拠レベルの設定

インライン・サービスは、Javaコンパイラ準拠レベルとして5を指定してコンパイルする必要があります。

この値がすべてのインライン・サービスで優先的に使用されるように設定するには、次の手順を実行します:

1. デシジョン・スタジオにログインします。

2. メニューで「ウィンドウ」→「プリファレンス」にナビゲートします。

3. 「プリファレンス」ウィンドウの左側のパネルで、「Java」→「コンパイラ」を選択します。

4. JDKコンプライアンス領域のコンパイラ・コンプライアンス・レベルで「5.0」を選択します。

5. 「OK」をクリックし、完全なリビルドを実行することを確認します。

以前のリリースのOracle RTDで作成されたインライン・サービスでは、Javaコンパイラ準拠レベルを手動で5.0に変更する必要が発生する場合があります。

インライン・サービスのレベルごとに個別にJavaコンパイラ準拠レベルを変更するには、インライン・サービス名を右クリックして「プロパティ」→「Javaコンパイラ」を選択してから、コンパイラ・コンプライアンス・レベルで「5.0」を選択します。

12.2.3 インライン・サービス・エクスプローラについて

インライン・サービス・エクスプローラを使用すると、インライン・サービス・プロジェクトのすべての側面にアクセスできます。一般的なインライン・サービス・プロジェクトを図12-1に示します。

図12-1 インライン・サービス・エクスプローラ

「図12-1 インライン・サービス・エクスプローラ」の説明

表12-1に、インライン・サービス・フォルダの内容を示します。

表12-1 インライン・サービス・フォルダの内容

フォルダ名

説明

Service Metadata

インライン・サービスを形成するメタデータ。このファイル・タイプのデフォルトのエディタは各要素に固有です。メタデータはテキスト・エディタで編集することもできますが、この方法はお薦めしません。

.settings

このインライン・サービスに固有のEclipseエディタ設定が格納されています。

classes

コンパイル処理で生成されたクラス。

etc

このディレクトリには、システム管理に使用する様々なスクリプトおよびファイルが含まれます。ロード・ジェネレータ・スクリプトが構築されると、規定によりこのフォルダに保存されます。

gensrc

インライン・サービス用に生成されたソース・コード・ファイル。

src

カスタムJavaコード。ユーザーが用意した任意のJavaクラスが含まれる場合があります。これらのクラスの一部を使用して、生成済インライン・サービスJavaクラスのデフォルト動作をオーバーライドできます。

lib

libフォルダは、外側クラスを使用する場合にユーザーによってオプションで作成されます。

たとえば、ある関数、ロジックまたは初期化ブロック内でTHashMapというクラスにアクセスするとします。このクラスはtcollections.jarファイル内にあります。このクラスを使用するには、次の手順を実行します:

1. プロジェクト・ワークスペース内のプロジェクト・ディレクトリの下にlibフォルダを作成します。

2. tcollections.jarファイルをこのフォルダに置きます。

3. インライン・サービス・プロパティ(「インライン・サービス」を右クリックし、「プロパティ」→「プロジェクト」→「プロパティ」を選択)で、Javaビルド・パスを選択します。

4. 「ライブラリ」タブを選択し、外部Jarsの追加...をクリックします。

5. 手順2でtcollections.jarファイルを置いたフォルダでこのファイルを選択します。

このjarのクラスを使用するには、編集するインライン・サービス・オブジェクトの「説明」ボックスの横にある「詳細」ボタンを使用してインポートし、そのクラスをコード内で使用します。

.classpath

プロジェクトのJavaクラスパスを含むファイル。このファイルを編集する必要はありません。

.project

Eclipseプロジェクト・ファイル。

12.2.4 コード生成

通常、インライン・サービスの要素を構成すると、次の4つのファイルが生成されます。

- 構成をメタデータとして格納する.sdaファイル。

- メタデータから生成され、クラス・ファイルにコンパイルされる.javaファイル。

- 元の生成済ファイルを拡張して、特殊な環境で生成済ファイルの動作を上書きするために使用される.javaファイル。

- 最初は生成済ファイルからコンパイルされ、その後、任意の上書きファイルからコンパイルされるクラス・ファイル。

それぞれのファイルの名前は次のようになります。

- メタデータ・ファイル: Object_ID.sda

- 生成済ファイル: GENObject_ID.java

- 上書きファイル: Object_ID.java

- クラス・ファイル: Object_ID.class

- 生成済クラス・ファイル: GENObject_ID.class

ヒント:

オブジェクトIDは、オブジェクトに付けられた名前と同様に作成されます。オブジェクトIDは、作成されたオブジェクト名の下にあるテキスト・ボックスに表示されます。オブジェクトIDはJava標準に準拠するため、ラベルと異なる場合があります。オブジェクトIDを調べるには、「トグル」アイコンを使用して、ラベルの表示とオブジェクトIDの表示を切り替えます。

たとえば、Customer accountという名前の要素があるとします。このオブジェクトIDは、Java命名規約に準拠してCustomerAccountという形式になります。

作成されるファイルは次のとおりです。

- メタデータ・ファイル: CustomerAccount.sda

- 生成済ファイル: GENCustomerAccount.java

- 上書きファイル: CustomerAccount.java

- クラス・ファイル: CustomerAccount.class

- 生成済クラス・ファイル: GENCustomerAccount.class

12.2.5 デシジョン・スタジオのパースペクティブおよびビューについて

デシジョン・スタジオでは、複数のパースペクティブでインライン・サービスを操作できます。パースペクティブは、そのパースペクティブのビューやエディタの初期設定およびレイアウトを定義します。パースペクティブごとに、特定のタイプのタスク達成を目的とした一連の機能があり、特定のタイプのリソースに対応します。パースペクティブは、特定のメニューおよびツールバーの表示を制御します。

デフォルトのインライン・サービス・パースペクティブには、次の4つのビューがあります。

- 「インライン・サービス・エクスプローラ」ビュー: ツリー形式でプロジェクトおよび要素が表示されます。デフォルトでは、画面の左側に配置されます。

- 「問題」ビュー: プロジェクトに関するエラーおよび例外が表示されます。デフォルトでは画面の底部に配置され、このビューと「テスト」ビューのいずれかがタブで選択されます。
「問題」ビューでは、インライン・サービスの構築時にコンパイル・エラーや検証エラーを特定できます。コンパイル・エラーをダブルクリックすると、Javaパースペクティブが表示され、エラーが強調表示されます。

検証エラーをダブルクリックすると、インライン・サービス・パースペクティブが表示され、検証エラーのある要素に対する要素エディタも表示されます。

- 「テスト」ビュー: インライン・サービスのテスト用の領域が提供されます。デフォルトでは画面の底部に配置され、このビューと「問題」ビューのいずれかがタブで選択されます。

- カンニング・ペーパー・ビュー: 一般的なタスクの手順が表示されます。デフォルトでは、画面の右側に配置されます。

インライン・サービス・パースペクティブの中央の領域はエディタ領域です。選択したプロジェクト・ツリーのノードに固有のエディタが表示されます。新しいエディタに変更するには、編集する要素をダブルクリックします。

Javaファイルを編集するには、Javaパースペクティブに変更して、編集するJavaファイルをダブルクリックします。

インライン・サービス・パースペクティブはデフォルトのパースペクティブであり、インライン・サービスを構成およびデプロイするためのメインの作業領域となります。Oracle RTDには、インライン・サービス・メタデータを操作するための多くの機能があります。これらについては、後述の各項で説明します。ここに記載のない機能は、コアのEclipseプラットフォームの一部になります。これらの機能の詳細は、Eclipseのオンライン・ヘルプ・ドキュメント『Workbench User Guide』を参照してください。

インライン・サービス・パースペクティブには、表12-2に示すメニューおよびツールバー・アイテムがあります。

表12-2 インライン・サービス・パースペクティブのメニューおよびツールバー・アイテム

メニューまたはツールバー・アイテムの名前

説明

「ファイル」→「新規インライン・サービス・プロジェクト」

選択したワークスペースに新しいインライン・サービス・プロジェクトを作成します。

「プロジェクト」→「ダウンロード」

変更するために、デプロイ済のインライン・サービスをReal-Time Decision Serverからダウンロードします。

「プロジェクト」→「デプロイ」

インライン・サービスをReal-Time Decision Serverにデプロイします。

「ウィンドウ」→パースペクティブを開く→インライン・サービス・パースペクティブ

インライン・サービス・パースペクティブを開きます。

「ウィンドウ」→「ビューの表示」→「インライン・サービス・エクスプローラ」ビュー

現在のインライン・サービスのビューを表示します。

「ウィンドウ」→「オブジェクトIDの表示」

ラベルとオブジェクトIDの表示を切り替えます。

「ヘルプ」→「バージョン情報」

デシジョン・スタジオのバージョン情報を表示します。

「デプロイ」アイコン

インライン・サービスをReal-Time Decision Serverにデプロイします。

「ダウンロード」アイコン

変更するために、デプロイ済のインライン・サービスをReal-Time Decision Serverからダウンロードします。

「トグル」アイコン

ラベルとオブジェクトIDの表示を切り替えます。

「インライン・サービス・エクスプローラ」ビューにもツールバー・アイテムがあります。これらのアイテムを表12-3に示します。

表12-3 「インライン・サービス・エクスプローラ」ビューのツールバー・アイテム

ツールバー・アイテム名

説明

「メタデータ」アイコン

プロジェクト・ツリー全体とインライン・サービス・メタデータのみの表示を切り替えます。

「すべて閉じる」アイコン

プロジェクト・ツリーを閉じます。

エディタとリンク・アイコン

要素の選択に応じてエディタが調整されるよう、選択した要素タイプとリンクに適切なエディタを探します。

「メニュー」アイコン

エディタとリンク、「メタデータのみ表示」および「常にオブジェクトIDを表示」にアクセスできます。最後のオプションは、「インライン・サービス・エクスプローラ」とエディタで要素のオブジェクトIDとラベルの両方を表示します。

Javaパースペクティブでは、Javaソース・ファイルの編集時に通常使用するビューを組み合せます。一方、デバッグ・パースペクティブには、Javaプログラムのデバッグ時に使用するビューが含まれます。

生成済Javaコードを直接操作するには、Javaパースペクティブを使用します。Javaコード・レベルでインライン・サービスをデバッグするには、デバッグ・パースペクティブを使用します。

12.2.6 ビューの配置とエディタのサイズ変更

エディタ領域のタブには、現在編集のために開かれているリソース名が表示されます。アスタリスク(*)は、変更がまだ保存されていないことを示します。ビューのタブにはビューの名前が表示され、ビューに固有の機能を提供するツールバーがあります。

パースペクティブのビューおよびエディタは、画面上の任意の領域にドラッグ・アンド・ドロップできます。ビューおよびエディタのサイズは、配置される領域に合せて自動的に変更されます。(主な作業場所である)エディタまたはビューの一部が、他のビューに覆われたり、使用するには不便な領域にサイズ変更される場合があります。エディタまたはビューのサイズを変更するには、開いている別のビューを閉じて残りが自動的にサイズ変更されるようにするか、エディタまたはビューを最大化します。

エディタとビューはどちらも、タブをダブルクリックするか、右クリックして表示されるメニュー・アイテムを使用して、最大化と最小化を切り替えることができます。パースペクティブ、エディタおよびビューの詳細は、Eclipseのオンライン・ヘルプに含まれている、『Workbench User Guide』内のオンライン・ドキュメントを参照してください。

12.2.7 要素へのカスタム・ロジックの追加

Javaコードは、デシジョン・スタジオ内の要素のロジック・パネルに追加されます。このコードは、GENObject_ID.javaファイルの適切なメソッドに挿入されます。ロジックを要素に追加したり更新したりする場合は、要素を選択し、エディタを使用してロジック・パネルのコードを変更します。

生成済コード内に直接、大きなコードの断片を挿入する方が便利な場合もあります。デシジョン・スタジオのJavaパースペクティブを使用して、これらのファイルを直接編集できます。生成済コードは、特定の場所でしか手動で編集できないので注意してください。また、「プロジェクト」→クリーンを選択すると、デシジョン・スタジオで生成済コードが再生成され、生成済Javaコードに直接加えたコード変更が上書きされます。

デシジョン・スタジオのJavaパースペクティブを使用して編集可能な任意のメソッドは、StartおよびEndマーカーで明示的に示されています。たとえば、Applicationオブジェクトにはインライン・サービスを初期化するinit()というメソッドがあります。

このメソッドのコードは、デシジョン・スタジオ・インタフェースで、アプリケーション要素の「ロジック」タブの「初期化ロジック」を使用して追加できます。

かわりにEclipseを使用して初期化コードを直接Applicationクラスに追加する場合は、次のようにマークされたメソッドにのみ追加します。

public void init() {
// SDCUSTOMCODESTART.Application.InitBody.java.0
// SDCUSTOMCODEEND.Application.InitBody.java.0
}

コードは、メソッドの開始コメントと終了コメントの間に記述する必要があります。コメント化された領域外にコードを記述すると、上書きされるおそれがあります。生成済Javaファイルに直接追加されたコードは、ファイルの再生成時に失われます。コードを保持するには、対応するメタデータ要素にそれをコピーする必要があります。

12.2.8 生成済コードの上書き

生成済クラスObject_ID.javaは、クラスGENObject_ID.javaを拡張します。なんらかの理由でGENObject_ID.javaに含まれるコードを上書きする必要がある場合は、上書きするコードをObject_ID.javaファイルに追加します。このファイルは、gensrcディレクトリからsrcディレクトリに移動する必要があります。

12.2.9 インライン・サービス検索の実行

インライン・サービスでオブジェクトおよび文字列を検索する手順は、次のとおりです。

1. メニューで「検索」→「検索」を選択して手順を開始します。

2. 「インライン・サービス検索」タブをクリックします。

3. 検索文字列を入力し、必要に応じて検索条件を絞り込みます。

- オブジェクトIDと任意の文字列を組み合せて検索できます。

- インライン・サービス検索では、デフォルトでは大文字と小文字は区別されません。必要に応じて、次に示す検索オプションを1つ以上選択できます。

- 大/小文字の区別 - 入力された式を検索する際に、大文字と小文字が区別されます。

- 完全一致のみ - 長い語の一部ではなく独立した語として式が存在する場合のみ検索されます。

- 正規表現 - 検索文字列としてJava正規表現を使用します。

4. 「検索」をクリックします。
結果は「検索」ビューに表示されます。

12.3 デシジョン・スタジオのプロジェクトの概要

インライン・サービスは、デシジョン・スタジオ内のプロジェクトとして構築されます。

この項には次のトピックが含まれます:

- 第12.3.1項「新規プロジェクトの開始」

- 第12.3.2項「プロジェクトのインポート」

- 第12.3.3項「ユーザー定義テンプレートの作成」

- 第12.3.4項「デプロイされているインライン・サービスのダウンロード」

- 第12.3.5項「デプロイの状態について」

- 第12.3.6項「サンプル・プロジェクト」

12.3.1 新規プロジェクトの開始

新しいインライン・サービスを開始するには、「ファイル」→「新規インライン・サービス・プロジェクト」を選択してプロジェクトを開始します。リストからテンプレートを選択してプロジェクトの名前を指定し、「終了」をクリックしてプロジェクトを作成します。

テンプレートのリストには、Oracle RTDインストールで提供されるテンプレートと任意のユーザー定義テンプレートが含まれます。

12.3.2 プロジェクトのインポート

既存のプロジェクトを開くには、「ファイル」→「インポート」を選択してプロジェクトをインポートします。メタデータを以前のバージョンから更新する必要がある場合は、アップグレードするよう求められます。

12.3.3 ユーザー定義テンプレートの作成

インライン・サービスからテンプレートを作成するには、「ファイル」→「エクスポート」を選択してプロジェクトをテンプレートにエクスポートします。エクスポート・タイプは「インライン・サービス・テンプレート」を選択します。テンプレートは、インライン・サービスのプリファレンスで定義された場所に保存されます。プリファレンスにアクセスするには、「ウィンドウ」→「プリファレンス」を選択し、「インライン・サービス」を選択します。入力されたディレクトリは、ファイル・システム上でテンプレートが保存される場所になります。

12.3.4 デプロイされているインライン・サービスのダウンロード

デプロイ済インライン・サービスをダウンロードするには、「プロジェクト」→「ダウンロード」を選択します。また、ツールバーの「ダウンロード」アイコンを使用してもReal-Time Decision Serverからダウンロードできます。

デプロイされているインライン・サービスを変更する場合は、その変更と、ビジネス・ユーザーにより行われている可能性のある変更の両方が失われないよう、次の手順に従うことが重要です。次の方法を使用します。

1. デプロイされている目的のインライン・サービスを編集しているビジネス・ユーザーがいないことを確認します。

2. ダウンロードする場合は必ずインライン・サービスをロックして、編集中にビジネス・ユーザーが変更できないようにします。

3. デシジョン・スタジオで変更作業を行います。

4. インライン・サービスを再デプロイしてロックを解除します。

インライン・サービスがロックされている間、ビジネス・ユーザーはそのデプロイされているインライン・サービスを表示できますが、編集はできません。

12.3.5 デプロイの状態について

インライン・サービスをデシジョン・スタジオからデプロイする場合は、デプロイ・ダイアログでデプロイの状態を選択します。開発、QAおよび本番の3つデプロイメント状態が使用できます。デプロイメント状態のサポートは将来のリリースで削減されるため、QAおよび本番の状態にはデプロイしないでください。

「テスト」ビューでインライン・サービスをテストする場合、最後のデプロイ状態がテストされます。

12.3.6 サンプル・プロジェクト

インポートして使用できるサンプル・プロジェクトがRTD_HOME\examplesディレクトリにあります。サンプル・プロジェクトの1つがCrossSellインライン・サービスです。

CrossSellインライン・サービスでは、クレジット・カード会社のコンタクト・センターを想定した単純な実装がシミュレートされます。センターで電話を受けると、顧客および連絡先チャネルに関する情報が入力されます。

既知の顧客情報に基づき、この顧客に対する抱合せ販売のオファーが提供されます。オファーの成否が追跡され、サーバーに返されます。これにより、基になる意思決定モデルに対して精度を高めるフィードバックが返され、抱合せ販売のオファーが改善されます。

CrossSellインライン・サービスでは、次を含めてOracle RTDの多くの機能が使用されています。

- キー・パフォーマンス・インディケータ(KPI)による意思決定プロセスの推進

- 顧客維持率の最大化や収益増加などの競合するKPIの最適化

- 正しい意思決定を行うためにグラフィカルなルールベース型スコアリングの使用

- 最良の意思決定を予測するために分析的な自己学習モデルの使用

ただし、CrossSellプロジェクトに表示されるいくつかの機能は、シミュレーション専用であるので注意してください。これらはサンプルの中で明示的に示しているので、本番のインライン・サービスでは使用しないでください。

デシジョン・スタジオを使用してCrossSellインライン・サービスをデプロイする前に、Oracle RTD DatabaseにCrossSellのサンプル・データを移入する必要があります。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のCrossSellサンプル・データの移入に関する項を参照してください。

デシジョン・スタジオでは、CrossSellサンプルはプロジェクトをインポートすることで表示できます。このプロジェクトは、RTD_HOME\examples\CrossSellにあります。プロジェクトをインポートしたら、各要素をダブルクリックしてその要素のエディタを表示することで、表12-4に示す機能を表示できます。

表12-4 CrossSellサンプル・インライン・サービスの機能

機能

要素名

説明

複数のKPI

パフォーマンス目標

Cross Sellインライン・サービスは、収益の最大化と顧客維持率の最大化の両方を最適化するように設計されています。

動的な顧客データ

データ・ソース/CustomerDataSource

エンティティ/カスタマ

データ・ソースとエンティティを組み合せると、顧客に提示するオファー・タイプの意思決定を支援する顧客データにアクセスできます。

エンティティは、1つまたは複数のデータ・ソースを、インライン・サービスの重要な単位を表すオブジェクトにマップする手段を提供するオブジェクトです。

エンティティを介してアクセスされるデータはセッション固有です。

抱合せ販売および顧客維持のためのオファー

選択肢

拡張可能なオファーは「選択肢」の下にまとめられています。これらのオファーには、抱合せ販売のオファーを意図したものも、顧客維持率の向上を意図したものもあります。各オファーの「スコア」タブを開くと、オファーに割り当てられている評価のスコアが表示されます。スコアは、パフォーマンス目標(RevenueやRetention)ごとに用意されています。一部のオファー(たとえば、all Credit Cards)は、親の選択肢グループからスコアリングを引き継ぎます。これは、このグループ内のすべてのオファーが同様にスコアリングされることを示します。この場合、スコアはProfit Marginを受入れ確率で乗算して計算されます。

その他のオファー(Reduced Interest Rateなど)は、ルールを使用して計算します。Reduced Interest Rateの収益目標には、組織の収益が赤字を示す場合、実際に負の値がスコアリングされます。

スコアリング・ルール

スコアリング・ルール/興味の低下率

スコアリング・ルールは、顧客に関する情報など、セッション・データを使用してオファーを動的にスコアリングする方法です。

母集団のセグメント

フィルタリング・ルール/保持するセグメント

フィルタリング・ルールを使用して母集団をセグメント化できます。このルールにより、顧客維持オファーに適するグループと、抱合せ販売の対象となるグループの2つのグループが出力されます。顧客が6回以上の放棄呼を受け、かつ2年を超えて顧客であり続けた場合、その顧客は維持オファーのグループにフィルタリングされます。

母集団のセグメントによる意思決定の重み付け

デシジョン/OfferDecision

「デシジョン」要素を使用して、競合するパフォーマンス・メトリック全体で意思決定プロセスの重み付けを行うことができます。このサンプルでは、顧客維持プロファイルに一致する母集団のセグメントに対して、Customer Retentionのスコアが高いオファーを重みの高い優先度に設定します。

編成プロセスへの統合

統合点

統合点は、情報を収集したり(IVRから顧客に関する情報を収集するCallStartなど)、外部システムに情報を提供したりすることによって(顧客に対する最高スコアのオファーをCRMシステムに提供するOfferRequestなど)、外部のシステムおよびプロセスと接するサイトです。

OfferResponse統合点にはelse分岐にコードがありますが、これはシミュレーション用なので注意してください。本番環境では、オファーが受け入れられたかどうかはサービス・センターのオペレータからのフィードバックとなります。

警告:

インライン・サービスの負荷生成スクリプトが実行されているときの時間の経過をシミュレートするために、Application.javaでcurrentTimeMillisメソッドがオーバーライドされています。CrossSellを本番のインライン・サービスのベースとして使用する場合、次のオーバーライド・ファイルを削除する必要があります。

RTD_HOME\examples\CrossSell\src\com\sigmadynamics\sdo\
Application.java

詳細は、第12.2.8項「生成済コードの上書き」を参照してください。

Cross Sellインライン・サービスをデプロイしてデータをロードする準備ができました。インライン・サービスをデプロイしたら、RTD_HOME\scripts\loadgen.cmdを実行してロード・ジェネレータを開きます。そこで「既存のロード・ジェネレータ・スクリプトを開きます」を選択して、RTD_HOME\examples\CrossSell\etc\LoadGen.xmlにブラウズします。「セキュリティ」タブで有効なユーザー名とパスワード入力し、スクリプトを実行します。

このスクリプトでは、シミュレーション上の顧客データを取得してインライン・サービスを実行します。データおよび検出された相関関係は、デシジョン・センターで表示できます。

12.4 インライン・サービスのディレクトリ構造

インライン・サービスを作成するとき、ファイル・システム上の任意の場所にプロジェクトを作成できます。使用しやすいように、すべてのプロジェクトを1つのディレクトリに保存することをお薦めします。デフォルトのワークスペースは、C:\Documents and Settings\user_name\Oracle RTD Studioです。

インライン・サービスを保存すると、そのディレクトリ名はインライン・サービス名と同じになります。インライン・サービスには、次のディレクトリ構造が作成されます。

表12-5 インライン・サービスのディレクトリ構造

ディレクトリ名

説明

Inline_Service_name\classes

インライン・サービスのコンパイル済クラス

Inline_Service_name\dc

デシジョン・センターのカスタムJSP用フォルダ

カスタムJSPは、http://<host_name_or_ip>:<port>/ui/custom/<ILS-name>/<custom page file name>という形式のURLを使用してアクセスできます。

例:

http://localhost:8081/ui/custom/CrossSell/mypage.jsp.

Inline_Service_name\etc

インライン・サービス関連の様々なファイルが配置されオプションのディレクトリ。例:

- loadgenスクリプト

- Readmeファイル

- インライン・サービス説明ファイル

- インライン・サービス設定手順ファイル

インライン・サービスがデプロイされる際に、このディレクトリはReal-Time Decision Serverに送信されません。

Inline_Service_name\gensrc

インライン・サービスの生成済ソース・コードの場所

Inline_Service_name\meta

インライン・サービスのメタデータ

Inline_Service_name\src

インライン・サービスの生成済コードを上書きするソース・コード

インライン・サービスのディレクトリ構造にオプションのlibディレクトリも追加して、外部Javaクラスを格納することもできます。詳細は、表12-1を参照してください。

12.5 インライン・サービスのセキュリティ

インライン・サービス・セキュリティは、Oracle Fusion MiddlewareおよびOracle WebLogic Serverで定義されているセキュリティ・フレームワークおよび要素によってのみ提供されます。このワークフレームを使用して、インライン・サービスに関連する特殊な権限(インライン・サービスをデシジョン・スタジオからデプロイする権限など)をユーザーに付与できます。

セキュリティに関する一般情報は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「Oracle Real-Time Decisionsのセキュリティ」を参照してください。インライン・サービスの権限の詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsのリソース・タイプとアクションに関する項を参照してください。

13 デシジョン・スタジオの要素とAPIについて

デシジョン・スタジオの要素はデシジョン・スタジオ内で構成され、ロジックがJavaスクリプトレットの形式で追加されます。この章では、各要素のプロパティおよび要素に含まれるJavaスクリプトレット(存在する場合)について、例とともに説明します。

この章には次のトピックが含まれます:

- 第13.1項「Oracle RTDの意思決定プロセスの概要」

- 第13.2項「Oracle RTDの意思決定プロセス」

- 第13.3項「要素の表示ラベルとオブジェクトIDについて」

- 第13.4項「アプリケーション要素について」

- 第13.5項「データへのアクセス」

- 第13.6項「エンティティの形成」

- 第13.7項「パフォーマンス目標」

- 第13.8項「選択肢グループおよび選択肢」

- 第13.9項「フィルタリング・ルール」

- 第13.10項「スコアリング・ルール」

- 第13.11項「ルール・エディタの使用」

- 第13.12項「Decisionsについて」

- 第13.13項「選択関数について」

- 第13.14項「モデルについて」

- 第13.15項「統合点について」

- 第13.16項「外部システムについて」

- 第13.17項「カテゴリ・オブジェクトについて」

- 第13.18項「関数について」

- 第13.19項「型制約について」

- 第13.20項「統計コレクタについて」

13.1 Oracle RTDの意思決定プロセスの概要

Oracle RTDの意思決定プロセスは、組織に関連する全体的パフォーマンス目標、その目標を測定するパフォーマンス・メトリック、各選択肢のスコアリングに必要なアクション、および母集団のセグメントに基づくそのスコアの重み付けをそれぞれ考慮したフレームワークをベースとしています。

このフレームワークには、次のような要素があります。

- パフォーマンス目標

- 意思決定

- 選択肢グループおよび選択肢

- フィルタリング・ルール

- スコアリング・ルール

- 予測モデル

これらの要素が通常のOracle RTD意思決定プロセスに取り込まれ、インライン・サービスの基礎を形成する様子を次の図に示します。

各入力の拡張機能により外部アプリケーションとOracle RTDで複合的なデシジョン・サービスをエンド・ユーザーに提供できる仕組みの詳細は、第17章「外部化されたオブジェクト管理」を参照してください。

13.2 Oracle RTDの意思決定プロセス

この項では、Oracle RTDの一般的な意思決定プロセス・フローについて説明します。

Oracle RTDの意思決定プロセスは、次の要素を考慮したフレームワークに基づいています。

- 組織の全体的なパフォーマンス目標

- パフォーマンス目標に応じた各選択肢のスコアリング方法

- 母集団のセグメントに基づくパフォーマンス目標の重み付け

デシジョンは、アドバイザによって選択肢をスコアリングするために呼び出され、選択肢グループの中から1つまたは複数の選択肢を返します。デシジョンの設定には、選択肢の選択元である選択肢グループが少なくとも1つと、選択肢をスコアリングするための関数またはルールが必須です。実行時にデシジョンは、それぞれの選択肢グループにある適格な選択肢をすべて収集します。その後、アドバイザによって各選択肢がスコアリングされ、最終的にランク付けられた順序が決定されて送り返されます。

図13-1は、Oracle RTDの基本的なプロセスを示したもので、セッションの開始と終了、およびOracle RTD意思決定プロセスの各手順で構成されています。

図13-1 Oracle RTDの意思決定プロセス・フロー

注意:

この項の例では、Oracle RTDに付属のCrossSellインライン・サービスの要素に言及します。

次の手順では、必要なデータを取得してデシジョンを処理するプロセス全体の様々なステージを示します。

1. システムがセッションを開始します。
ユーザーがログオンし、外部アプリケーションがOracle RTDに接続し、Oracle RTDがセッションを確立します。

通常、外部アプリケーションがユーザーに関する情報をできるだけ多くの収集し、 1つまたは複数のインフォーマントを使用してその情報をOracle RTDに渡します。

Oracle RTDが、外部アプリケーションに関連付けられたインライン・サービスで定義されているデータ・ソースとエンティティからさらに情報を抽出する場合もあります。

2. アドバイザがデシジョンを呼び出します。
アドバイザ・コールによるリクエストによって意思決定プロセスが開始されます。関連する選択肢グループごとに、意思決定の評価対象となる一連の選択肢が決定されます。

Oracle RTDの意思決定プロセスの主な目的は、最適な選択肢を評価してアプリケーションに提案することです。

「最適な選択肢」とは

アプリケーションの目的に最も適った、最も妥当な選択肢です。

アプリケーションの「目的」とは

次のようなパフォーマンス目標です。

- Revenue

- Customer Retention

パフォーマンス目標は、それぞれ相反する目標という可能性があります。そのため、相反する可能性のある目標同士の折り合いをつける手段が必要になります。

3. 各選択肢の適格性が決定されます。
選択肢によっては、現実の世界においては不合理な場合もあります。このため、選択肢を除外する仕組みが意思決定プロセスの早い段階で必要になります。それが適格性ステージです。

選択肢の適格性ルールが起動され、潜在的な多くの選択肢の中から、意思決定プロセスの次のステージに進む選択肢が決定されます。

4. 必要に応じて、ユーザー・セグメントが決定されます。

選択肢の妥当性は、最終的に選択肢の提案を受けるユーザーのグループによって異なる可能性があります。そのため、様々なユーザー・セグメントを定義します。その特性は、フィルタリング・ルールで明示的に定義するか、またはデータをフィルタリングするカスタム関数によって暗黙的に定義します。

たとえば、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%

5. 各選択肢がスコアリングされます。
要約すると、関連付けられた各パフォーマンス目標に適格なすべての選択肢がスコアリングされます。

詳細説明:

デシジョンの最終目的は、最適な選択肢を見つけることです。選択肢を比較するとき、各選択肢の数値スコアが生成され、スコアによって選択肢がランク付けされ、最高スコアの選択肢が選択されます。

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モデルの予測からスコアが導出されます。

6. 選択肢のスコアに重みが付けられます。
ユーザーのセグメントに明示的または暗黙的に適用される適格な各選択肢のスコアが計算されます。

スコアリング・ステージに到達した選択肢ごとに、セグメントとパフォーマンス目標の組合せに対して指定した必要な重み付けを適用して、各パフォーマンス目標のスコアが評価されます。詳細は、「セグメントと重み付けされたパフォーマンス目標」を参照してください。

各選択肢の合計スコアは、重み付けされたすべてのパフォーマンス目標のスコアの合計です。

合計スコアが最も高い選択肢が最適な選択肢となります。

7. 1つまたは複数の選択肢が外部アプリケーションに返されます。
選択肢の名前と外部アプリケーションが必要とする指定の選択肢属性を渡すことで、Oracle RTDは外部アプリケーションに1つまたは複数の選択肢を返します。外部アプリケーションは返された選択肢を表示するか、適宜に情報を処理します。

8. セッション情報が更新されます。
この手順は、意思決定プロセスのどのステージでも実行できます。その主な結果として、特定のセクションに関する新しい情報でOracle RTDサーバーが更新されます。

また、指定の統合点またはセッション終了時に、セッション情報に基づいてモデルを更新できます。

9. セッションがクローズします。
アクティブなOracle RTDセッションがクローズし、終了時のロジックが実行されます。これには、セッションのクローズ時に学習するように定義されているモデルの学習などが含まれます。

13.3 要素の表示ラベルとオブジェクトIDについて

要素を作成する際、その要素の表示ラベルを入力します。表示ラベルを入力すると、オブジェクトIDが自動的に生成されます。

オブジェクトIDはJava命名規約に準拠するように自動的に作成されます。変数名は大文字と小文字が混在し、最初の1文字は小文字になります。クラス名は大文字と小文字が混在し、最初の1文字は大文字になります。ラベル名に空白が含まれている場合、オブジェクトIDの作成時に空白は削除されます。オブジェクトIDを手動で入力すると、自動的に作成されたオブジェクトIDを上書きできます。

「インライン・サービス・エクスプローラ」のタスク・バーにある「トグル」アイコンを使用すると、オブジェクトの表示ラベルとそのオブジェクトIDとの間で表示の切替えができます。

注意:

新しいオブジェクトを作成する際、オブジェクト名が既存のオブジェクトで使用されていると、競合を防止するためにデシジョン・スタジオによって自動的にオブジェクトIDに番号が割り当てられます(1、2など)。

13.4 アプリケーション要素について

デシジョン・スタジオで新しいプロジェクトを開始すると、「サーバー・メタデータ」フォルダにアプリケーション・オブジェクトが作成されます。アプリケーション・オブジェクトのプロパティでは、次の特性が定義されます。

- アプリケーション・パラメータ

- 制御グループ

- モデルのデフォルト値

- ロジック

これらすべての値は、デシジョン・スタジオ・インタフェースを使用して定義されます。

この項には次のトピックが含まれます:

- 第13.4.1項「アプリケーション・パラメータ」

- 第13.4.2項「アプリケーションAPI」

- 第13.4.3項「制御グループの構成」

- 第13.4.4項「モデルのデフォルト値の設定」

- 第13.4.5項「アプリケーションの書込みロジック」

13.4.1 アプリケーション・パラメータ

この項では、アプリケーション・パラメータについて説明します。この項には次のトピックが含まれます:

- 第13.4.1.1項「デバッグ・オプションの使用」

- 第13.4.1.2項「アプリケーション・パラメータの追加」

13.4.1.1 デバッグ・オプションの使用

本番データベースに対してデプロイされているインライン・サービスをテストする場合、モデル・データを混在させないようにするには、デバッグ・オプションを使用してデータが書き込まれないようにします。デバッグ・オプションは次のとおりです。

- 学習の無効化: モデルの現在の状態を維持して、テストにより追加的な学習が導入されないようにします。

- データベース書込みの無効化: データがデータベースに書き込まれないようにします。

- 親が最初のクラスロード: Javaクラスのロードを制御します。
デフォルトでは、このオプションが選択されており、親(RTDサーバー)レベルですでに定義されているクラスが先にロードされます。

このオプションの選択を解除すると、インライン・サービス・レベルで定義されているJavaクラスが先にロードされます。これは、既存の機能をオーバーライドするときに便利です。

注意:

WebSphere上でOracle RTDシステムを実行している場合は、このオプション(「親が最初のクラスロード」)の選択を必ず解除してください。

また、WebSphereシステム構成の一環として、これに対応するクラス・ローディングのオプションをWebSphereの管理コンソールで設定する必要があります。詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドの親クラスのロードの無効化に関する項を参照してください。

13.4.1.2 アプリケーション・パラメータの追加

アプリケーション・パラメータは、すべてのセッションについて定義および保存できるグローバルレベルのパラメータです。

「アプリケーション・パラメータ」タブで「追加」をクリックしてパラメータを追加します。パラメータを追加する際、「名前」、「タイプ」、「配列」および「デフォルト値」を入力します。

オプションとして、パラメータに型制約を追加できます。これは、ルールでパラメータを使用する際のパラメータ値の設定に役立ちます。型制約の作成と使用の詳細は、第13.19項「型制約について」を参照してください。

「削除」をクリックすると、パラメータは削除されます。

13.4.2 アプリケーションAPI

次のコードはそれぞれ、オブジェクトのラベルとIDを返します。

public String getSDOLabel();
public String getSDOId();

グローバル・パラメータが設定されると、コード内にゲッターとセッターが生成されます。アプリケーション・パラメータ(たとえば、string型のmyApplicationParameter)にアクセスするには、次を使用します。

String param = Application.getApp().getMyApplicationParameter();

逆に、アプリケーション・パラメータを設定するには、次のように指定します。

Application.getApp().setMyApplicationParameter("my parameter");

13.4.3 制御グループの構成

制御グループは、ビジネス・ユーザーがOracle RTDの意思決定プロセスと既存のランキング・プロセスまたはランダムな選択とを比較できるようにするベースラインとして機能します。制御グループのデシジョンは、Oracle RTDがインストールされていないときのデシジョンを正しく反映するように、正確に定義することが重要です。

たとえば、コール・センター用の抱合せ販売インライン・サービスでは、Oracle RTDの導入前に抱合せ販売がランダムに行われていた場合、制御グループのデシジョンではランダムなデシジョンが反映されるようにする必要もあります。

表13-3 制御グループのオプション

オプション名

説明

制御グループなし

これを選択すると、制御グループは使用されず、「選択値」が0に設定され、「値の逐語的使用」が選択されて無効になります。制御グループを有効にして設定を変更するには、「制御グループなし」を選択解除します。

選択値

属性値への参照。この値を使用して、リクエストのランダムな選択を制御グループに生成します。

値の逐語的使用

「値の逐語的使用」を選択解除する場合、制御グループの選択値は、セッション・キーまたは顧客を一意に識別する属性を参照する必要があります。制御グループの参加は、選択値の疑似乱数ハッシュを使用して決定されます。計算の結果は決定論的であり、制御グループの選択値と指定されたサイズにのみ依存します。制御グループの実際のサイズは、指定されたサイズと微妙に異なります。

「値の逐語的使用」を選択すると、選択値により制御グループの参加が直接決定されます。この場合の選択値には、ブール(制御グループの参加をtrue値で示す)または整数(制御グループの参加を0以外の値で示す)を指定できます。

たとえば、顧客の制御グループへの割当てをOracle RTD以外で行う場合に「値の逐語的使用」を選択します。制御グループの選択値として使用する属性は、この割当てを示す必要があります。

母集団のパーセント

「値の逐語的使用」がFalseに設定されている場合にのみ、このオプションはアクティブになります。その場合、制御グループに割り当てる必要があるセッションの総数に対するパーセンテージをユーザーは決定します。

分析に使用

制御グループの参加を解析モデルにより追跡するかどうかを制御します。

分析の名前

解析モデルが制御グループの参加の追跡に使用する名前。

13.4.4 モデルのデフォルト値の設定

モデルのデフォルト値は、使用するモデルおよびモデルの設定方法を制御します。ほとんどのモデルのデフォルト値は、Oracleサポート・サービスによる指示のないかぎり変更しないでください。

表13-4 モデルのデフォルト値

オプション名

説明

スタディ名

インライン・サービスで使用するスタディの名前。通常は、インライン・サービスごとに個別のスタディを持ちます。これは、スタディ名をインライン・サービス名と同じにすると実現できます。ただし、既存のスタディはインライン・サービスのテスト時に使用されることがあります。そのような場合は、学習を無効にして本番データが失われないようにする必要があります。

連続性間隔

モデル・データをデータベースに保存する時間間隔。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。

時間ウィンドウ期間

デフォルト値は「四半期」です。この値はモデルごとにオーバーライドできます。

週の最初の曜日

デフォルト値はロケールにより異なります。米国では、デフォルト値は「日曜日」です。

年の最初の月

デフォルト値は「1月」です。

データの変更時にビルド

新しい予測モデルを構築する新規レコードのパーセンテージ。デフォルト値は「20%」です。

たとえば10%に設定した場合、前回予測モデルが構築されたのが13400レコードに達した時点であったと仮定すると、次回予測モデルが構築されるのは1340レコードに達した時点になります。

重要度しきい値

デフォルト値は「25」です。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。

相関しきい値

デフォルト値は「0」です。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。

最大入力カーディナリティ

個々の属性で追跡される値の最大数。デフォルト値は「500」です。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。

最大入力バケット

数値属性の入力バケットの最大数。デフォルト値は「200」です。値が「100」でも十分有効な場合があります。この機能は、Oracleサポート・サービスによる指示のないかぎり調整しないでください。

13.4.5 アプリケーションの書込みロジック

アプリケーション要素の「ロジック」タブにある「初期化ロジック」および「クリーンアップ・ロジック」パネルを使用して、インライン・サービスを初期化およびクリーンアップするスクリプトレットがデシジョン・スタジオを介して追加されます。

これらのスクリプトレットは、ApplicationクラスのinitおよびcleanUpメソッドに挿入されます。initメソッドは、インライン・サービスがロードされるときにコールされます。cleanUpメソッドは、インライン・サービスがアンロードされるときにコールされます。アプリケーションが再デプロイされると、initが再度コールされます。

13.4.5.1 インポートされたJavaクラスの追加

ユーザーの設定したJavaクラスをinitまたはcleanUpメソッドで参照する場合、それらのクラスがインポートされている必要がある可能性があります。import文を追加するには、説明の横にある「詳細」をクリックします。詳細は、表12-1のフォルダ名libの説明を参照してください。

13.5 データへのアクセス

インライン・サービス内のデータにアクセスするには、エンティティ、データ・ソースおよびセッションの各要素を使用します。

エンティティは、複数のソースからのデータをまとめて、インライン・サービス全体で使用されるオブジェクトを形成する論理的な方法を提供します。エンティティは、その内容を記述するいくつかの属性で構成されます。また、エンティティは属性にアクセスするメソッドも備えています。

Customerなどのエンティティは、様々なソースから着信するデータを組み合せます(IVRを介して入力されたアカウント番号や企業データベースから取得した顧客履歴など)。エンティティの属性の1つがキー(一意の識別子)の場合もあります。着信したデータは、エンティティの適切な属性にマップされます。セッションの存続期間中に、インライン・サービスにコーディングされている追加ロジックによってエンティティ属性を移入できます。

データ・ソースは、データのサプライヤとして機能します。これは、リレーショナル・データベース表およびストアド・プロシージャへの接続を管理する方法を提供します。データ・ソースは、データベース表の列、またはストアド・プロシージャからの結果セットを属性として識別します。これらの属性は、エンティティ属性にマップされます。

セッション・オブジェクトは、インライン・サービスに対してメモリー内の使用可能な属性を識別する特別なエンティティです。これらの属性は、前述のCustomerなどのエンティティと、計算などの他のソースで設定された属性で構成できます。セッション・オブジェクトを使用して、ユーザー・セッションの情報を保存します。セッションに保存された属性はインライン・サービス全体で使用でき、セッションを閉じたときに破棄されます。セッションに関連付けられている属性は、特定のモデルで明示的に除外されている場合や、解析対象から完全に除外されている場合を除いて、デフォルトでOracle RTD学習モデルの入力として使用されます。

データにアクセスするには、通常、次の手順を実行します。

1. SQL表またはストアド・プロシージャに基づいてデータ・ソースを作成します。

2. ゼロ以上のデータ・ソースにマッピングされた属性を持つエンティティを作成します。

3. キー値をエンティティに追加します。

4. エンティティを属性としてセッションに追加し、セッション・キーを割り当てます。

5. エンティティ属性をデータ・ソース列または出力値にマップします。

6. エンティティ・キーをセッション・キーまたは関数にマップします。

この項には次のトピックが含まれます:

- 第13.5.1項「データ・ソースについて」

- 第13.5.2項「SQLデータ・ソースの作成」

- 第13.5.3項「ストアド・プロシージャ・データ・ソースの作成」

- 第13.5.4項「Oracle Business Intelligence Enterprise Editionデータへのアクセス」

13.5.1 データ・ソースについて

データはインライン・サービス内でデータ・ソース要素およびエンティティ要素を使用してアクセスします。データ・ソースはデータの抽象プロバイダです。データ・ソースは、インライン・サービスに対するデータのサプライヤとして機能します。

データ・ソースには、SQLデータ・ソースとストアド・プロシージャ・データ・ソースの2種類があります。

13.5.2 SQLデータ・ソースの作成

この項では、SQLデータ・ソースを作成する方法について説明します。この項には次のトピックが含まれます:

- 第13.5.2.1項「SQLデータ・ソースの特性」

- 第13.5.2.2項「データ・ソースへの列の追加」

- 第13.5.2.3項「データベース列名のインポート」

- 第13.5.2.4項「入力列の設定」

13.5.2.1 SQLデータ・ソースの特性

表13-5はSQLデータ・ソースのプロパティを示します。

表13-5 SQLデータ・ソースのプロパティ

データ・ソースのプロパティ名

説明

説明

データ・ソースの説明。

JDBCデータ・ソース

JDBCデータ・ソースのJNDI名。新しいデータ・ソースの作成方法は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsのデータ・アクセスの構成に関する項を参照してください。

表名

表の名前。大文字と小文字が区別されるデータベースを使用している場合は、この名前の大文字と小文字が区別されます。

出力列名

データ・ソースから選択する列。

出力タイプ

出力列のデータ型。

入力列名

データ・ソースに対する問合せのWHERE句に使用する列。これは、データ・ソースからデータを選択する際に一致させる列です。

入力タイプ

入力列のデータ型。

複数の行を許可

複数行が返されることを許可します。このオプションを選択しない場合に複数行が返されると、最初の1行のみが使用されます。

詳細

「詳細」ボタンを使用すると、デシジョン・センターに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。

13.5.2.2 データ・ソースへの列の追加

「追加」または「削除」をクリックすると、データ・ソースに列を追加または削除できます。複数の行が想定される場合、「複数の行を許可」を選択します。このオプションを選択しない場合に複数行が返されると、最初の1行のみが使用されます。

13.5.2.3 データベース列名のインポート

「インポート」をクリックすると、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.5.2.4 入力列の設定

「入力列」は、セッションに必要な行を取得するために、データベース表に対して一致させる列です。ほとんどの場合、これは単一レコードを返すための主キーまたは一意の索引列の値になります。大きな結果セットが必要な場合は、一意でない索引列にすることもできます。「追加」をクリックして、一致させる属性を選択します。

13.5.3 ストアド・プロシージャ・データ・ソースの作成

この項では、ストアド・プロシージャ・データ・ソースを作成する方法について説明します。この項には次のトピックが含まれます:

- 第13.5.3.1項「ストアド・プロシージャ・データ・ソースの特性」

- 第13.5.3.2項「ストアド・プロシージャ・パラメータのインポート」

- 第13.5.3.3項「データ・ソースへの属性の追加」

- 第13.5.3.4項「データ・ソースへの結果セットの追加」

13.5.3.1 ストアド・プロシージャ・データ・ソースの特性

表13-6はストアド・プロシージャ・データ・ソースのプロパティを示します。

表13-6 ストアド・プロシージャ・データ・ソースのプロパティ

データ・ソースのプロパティ名

説明

説明

データ・ソースの説明。

JDBCデータ・ソース

JDBCデータ・ソースのJNDI名。

プロシージャ名

ストアド・プロシージャの名前。データベースで大文字と小文字が区別される場合であっても、この名前の大文字と小文字は常に区別されません。

入力と出力

ストアド・プロシージャの入出力パラメータ。各入出力パラメータには、Name、Type、およびDirectionがあります。

結果セット

ストアド・プロシージャからの結果セット。

複数の行を許可

複数行が返されることを許可します。このオプションを選択しない場合に複数行が返されると、最初の1行のみが使用されます。

結果セットの詳細

列名と予想される結果の型。

詳細

「詳細」ボタンを使用すると、デシジョン・センターに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。

13.5.3.2 ストアド・プロシージャ・パラメータのインポート

「インポート」をクリックして、データ・ソースに直接接続します。指定されたデータ・ソースのすべてのストアド・プロシージャが表示されます。データ・ソースが指定されない場合は、デフォルトのデータ・ソースSDDSが使用されます。

「すべてのスキーマのオブジェクトを含む」を選択すると、すべてのデータ・ソース・スキーマのストアド・プロシージャが表示されます。

インポートするストアド・プロシージャを選択すると、そのパラメータの名前とデータ型がインポートされ、データ・ソースの属性になります。その後、「終了」をクリックします。不要なパラメータがある場合は、「削除」をクリックすると削除できます。

13.5.3.3 データ・ソースへの属性の追加

「追加」または「削除」をクリックすると、データ・ソースに属性を追加または削除できます。属性が「入力」、「出力」、または「入力/出力」かを選択します。

属性は順に並べる必要があります。「上へ」または「下へ」を使用して属性の順番を変更します。

13.5.3.4 データ・ソースへの結果セットの追加

ストアド・プロシージャに1つ以上の結果セットがある場合、各結果セットに対して次の手順を実行します:

1. 「結果セット」の「追加」ボタンをクリックして、結果セットをデータ・ソースに追加します。

2. 「結果セットの詳細」の「追加」ボタンを使用すると、結果セットの列名および型を追加できます。
列名とデータ型を手動で入力して、次に示すようにストアド・プロシージャの結果セットの列に一致させる必要があります。

- データ・ソースの列名は、結果セットの列名と正確に一致している必要があります。

- データ・ソースのデータ型は、結果セットの対応データ型で有効である必要があります。
たとえば、結果セットの列がVARCHARまたはVARCHAR2の場合、データ・ソースの対応する列のデータ型としてStringを入力します。SQL ServerまたはOracleのストアド・プロシージャの列がFLOATの場合や、DB2のストアド・プロシージャの列がREALの場合、データ・ソースの対応する列のデータ型としてDoubleを入力します。

13.5.3.5 ストアド・プロシージャからのデータ・ソースの設定例

付録C「ストアド・プロシージャからのデータ・ソースの例」では、Oracle、SQL ServerおよびDB2の各データベースからデータ・ソースを設定し、データ・ソースから属性を導出するエンティティを作成する例について説明しています。

13.5.4 Oracle Business Intelligence Enterprise Editionデータへのアクセス

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のデータ・アクセスの構成に関する項を参照してください。

13.6 エンティティの形成

エンティティは、名前付き属性とその属性にアクセスするためのメソッドのセットです。通常、1つの属性がエンティティのキーとして指定されます。たとえば、単純な顧客エンティティは次のようになります。

Customer

customerId: string, key
name: string
age: integer
accounts: collection of Account entities

このエンティティでは、customerIdがエンティティのキーで、nameとageは単純な属性です。accountsは、Customerヘッダーに関連付けられているAccountエンティティのコレクションです。

この項には次のトピックが含まれます:

- 第13.6.1項「Sessionエンティティについて」

- 第13.6.2項「エンティティの作成」

- 第13.6.3項「属性およびキーのエンティティへの追加」

- 第13.6.4項「データ・ソースからの属性のインポート」

- 第13.6.5項「解析の属性の使用」

- 第13.6.6項「デシジョン・センターの表示」

- 第13.6.7項「セッション・キーの追加」

- 第13.6.8項「セッションへの属性の追加」

- 第13.6.9項「属性のデータ・ソースへのマップ」

- 第13.6.10項「1対多関係」

- 第13.6.11項「インポートされたJavaクラスの追加」

- 第13.6.12項「セッション・ロジック」

- 第13.6.13項「セッションAPI」

- 第13.6.14項「エンティティAPI」

- 第13.6.15項「エンティティ・クラスについて」

- 第13.6.16項「Oracle RTDロジックでのエンティティの参照」

- 第13.6.17項「エンティティ・キーの追加」

- 第13.6.18項「エンティティ属性へのアクセス」

- 第13.6.19項「エンティティのリセットと入力」

- 第13.6.20項「キャッシュされたエンティティについて」

- 第13.6.21項「エンティティ属性のロギングの拡張」

13.6.1 Sessionエンティティについて

Sessionエンティティは、インライン・サービスごとに自動的に作成される特別なエンティティです。

特定のフロント・エンド・セッションの存続期間中、Sessionエンティティによって、インライン・サービスで使用可能なメモリー内の属性が識別されます。これらの属性は、Customerなどのエンティティと、計算などの他のソースで設定された属性で構成できます。Sessionオブジェクトを使用して、ユーザー・セッションの情報を保存します。セッションに保存された属性はインライン・サービス全体で使用でき、セッションを閉じたときに破棄されます。

セッションは統合点によって明示的にクローズされるか、またはタイムアウトによってクローズされます。

13.6.1.1 セッション・キーについて

セッション・キーはリクエストに渡すフィールドの1つで、統合点で使用可能な、Real-Time Decision Serverサーバーに存在するSessionオブジェクトのインスタンスを識別します。

セッションの使用例として、クライアントWebアプリケーションについて考えます。ここでは、各リクエストがセッション・キーとしてWebアプリケーションのCustomerIdを渡します。新しいCustomerIdを持つ最初のリクエストが到着すると、Real-Time Decision Serverではそのセッション・キーが新しいことを認識し、新しいSessionオブジェクトを作成して、リクエストの実行時に統合点で使用できるようにします。これと同じCustomerIdを使用する後続のリクエストは、同じSessionオブジェクトにアクセスします。

統合点の処理により、後で呼び出される統合点で使用できるように、セッションの情報が明示的または暗示的に保存されます。

13.6.2 エンティティの作成

エンティティは、デシジョン・スタジオを使用して定義します。エンティティ名は、大文字で開始する必要があります。エンティティでは、次の特性が定義されます。

- 説明:デシジョン・スタジオに入力されたエンティティの説明。

- キー: エンティティの一意のID。「キーの追加」をクリックすると、キーがエンティティに追加されます。

エンティティ属性にはプロパティもあります。属性のプロパティを表13-7に示します。

表13-7 エンティティ属性のプロパティ

エンティティ属性のプロパティ名

説明

説明

デシジョン・スタジオに入力された属性の説明。

タイプ

属性タイプは、基本型、Javaクラス、エンティティ・タイプ、選択肢または選択肢グループのいずれかです。

配列

単一値かコレクションかどうか。

タイプ制約

ルールでエンティティ属性を使用する場合、属性の型制約を選択できます。これは必須要件ではありませんが、ルールの定式化に役立ちます。型制約の作成と使用の詳細は、第13.19項「型制約について」を参照してください。

デフォルト値

デフォルト値。定数、関数、または属性への参照を指定できます。

分析に使用

このオプションを選択して、予測モデル内の解析にこの属性を使用します。デフォルトでは、これはtrueに設定されています。

カテゴリ

属性のカテゴリ。カテゴリは、デシジョン・センターでの属性の表示の編成に役立ちます。

分析オプション

Date属性の追加の解析オプションが使用できます。解析にDateを使用するには、解析に使用するパターンを指定します。月、日、曜日、時刻の影響を個別に、または任意の組合せで解析できます。

13.6.3 属性およびキーのエンティティへの追加

「属性の追加」または「キーの追加」をクリックして、属性をエンティティに追加します。属性がコレクションの場合は、「配列」列を選択します。

警告:

Key属性を追加する場合、データ型は自動的にStringになります。データ・ソース列または出力パラメータのデータ型がString以外の場合は、データ・ソースの入力の設定時に変換関数を使用します。

13.6.4 データ・ソースからの属性のインポート

データ・ソースのすべての出力列を自動的にエンティティ属性として追加するには、「インポート」をクリックしてインポート元のデータ・ソースを選択します。複数のデータ・ソースからインポートする場合は、この手順を繰り返します。「削除」をクリックすると、不要な属性を削除できます。

「インポート」を使用する際、「選択したデータ・ソースのデータ・マッピングのビルド」を選択すると、属性がデータ・ソースに自動的にマップされます。エンティティがネストされ(たとえば、1対多関係)、属性が間接的にマップされる場合は、このオプションを選択しません。

注意:

「選択したデータ・ソースのデータ・マッピングのビルド」によりエンティティ属性がデータ列にマップされますが、ユーザーがエンティティ・エディタの「データ・ソース入力値」セクションで入力値を割り当てることもできます。

13.6.5 解析の属性の使用

「分析に使用」を選択して、解析モデルに属性を追加します。

各エンティティ属性の「分析に使用」オプションはデフォルトでtrueに設定されており、Oracle RTDのモデルの入力として使用されます。その必要がない場合は、ユーザーがこのオプションの選択を明示的に解除できます。適切な属性を右クリックして「プロパティ」を選択することで、この設定にアクセスします。

このオプションの選択を解除する場合の一般的な例として、属性自体はモデリングに有効でないが、別の属性の値を計算する関数で使用されている場合があげられます。

注意:

値がNULLや空文字列になる可能性がある属性には注意してください。

NULLは学習モデルに渡されず、予測の計算にも使用されません。また、標準のパーティション化されていない属性の場合、デシジョン・センター・レポートに表示されません。

NULLは、データ値が不明な場合にのみ使用してください。特殊なケースの疑似値としては使用しません。たとえば、Number_of_children属性の値がNULLの場合は子供の数が不明であることを示し、値が0の場合は子供の数が0人であることを示します。

空文字列は学習モデルに渡されますが、意味のある予測を生成しません。デシジョン・センター・レポートには「NOT KNOWN」と表示されます。 Oracle RTDモデルでは空文字列を使用しないことをお薦めします。

13.6.6 デシジョン・センターの表示

「デシジョン・センターで表示」オプションは、デフォルトで選択されます。デシジョン・センター・ユーザーに対して属性を表示しないようにする場合は、このオプションを選択解除します。必要に応じて、「カテゴリ」を選択すると、デシジョン・センターの属性の表示を制御できます。適切な属性を右クリックして「プロパティ」を選択することで、この設定にアクセスします。

第13.6.5項「解析の属性の使用」のNULLと空文字列に関する注意も参照してください。

13.6.7 セッション・キーの追加

使用するセッション・キー値がエンティティの属性である場合、最初にエンティティをセッションに追加します。そのためには、セッション・エンティティで「属性の追加」をクリックして、このエンティティをそのエンティティ・タイプの新しい属性としてそのセッションに追加します。

たとえば、セッション・キーをCustomerエンティティのcustomerId属性にするとします。「属性の追加」をクリックして、属性をcustomerというセッションに追加します。この属性の型は、エンティティ・タイプ(つまり、Customer)です。

エンティティ・タイプにアクセスするには、「タイプ」列のドロップダウン・リストを使用して「その他」を選択します。「タイプ」ウィンドウが表示されます。この属性の「エンティティ・タイプ」を選択します。

セッション・キーを追加するには、「依存エンティティのセッション・キー」から「選択」をクリックします。セッションの属性であるエンティティからのキー値はすべて、セッションのキー値として選択できます。そのセッションのベースにするキーを選択します。この例では、customerIdです。

注意:

キャッシュされたエンティティのキーはセッション・キーとして使用できません。エンティティのキャッシュの詳細は、第13.6.20項「キャッシュされたエンティティについて」を参照してください。

13.6.8 セッションへの属性の追加

「属性の追加」をクリックして、セッション全体で使用可能にする属性を追加します。セッション属性も他のエンティティ属性もゲッターおよびセッターが生成されます。これにより、作成するカスタム・ロジックでこれらの属性を使用できるようになります。

13.6.9 属性のデータ・ソースへのマップ

デシジョン・スタジオを使用してエンティティを作成したら、エンティティの属性を定数、計算済、データ・ソースの属性への参照、またはセッション・キーのいずれかの値にマップします。

構成されているデータ・ソースへのマッピングは、エンティティ・オブジェクトの「マッピング」タブで実行します。エンティティの属性をデータ・ソースにマップするには、「ソース」列を使用して、データ・ソース列のパスまたはデータの属性を提供する出力パラメータを選択します。

キー値をマップするには、「データ・ソース入力値」から「入力値」をクリックします。ここで、属性をデータ・ソース値にマップすると、キー値が表示されます。キーは、セッション・キー属性、別のエンティティ・キー値、または関数にマップできます。入力タイプは、String型にする必要があります。String型でない場合は、非文字列値を変換する関数を使用します。

13.6.10 1対多関係

1対多の外部キー関係のエンティティのデータにアクセスするには、関係するエンティティを最初のエンティティの属性にします。たとえば、Customers表にキーCustomerIDがあると仮定します。Customersには多数のOrdersがあり、OrderIDと外部キーCustomerIDで識別されます。

図13-2 エンティティのマッピング例

「図13-2 エンティティのマッピング例」の説明

1対多の外部キー関係のエンティティのデータにアクセスする手順を、CustomersとOrdersを例に使用して、次に示します:

注意:

この例は、Orders表にCustomerIDが外部キーとして存在していることを前提としています。このCustomerIDはOrdersデータ・ソースの入力列として使用されます。また、Ordersデータ・ソースの「複数の行を許可」設定がtrueに設定されています。

1. デシジョン・スタジオで、各表のデータ・ソースを定義します。

2. CustomersおよびOrdersのエンティティを作成します。

3. Customerをセッションに追加します。これは、次のデータ・レベルを取得する際のキーとなります。

4. セッション・キーとしてCustomerIDを選択します。

5. OrdersとCustomersの間の1対多関係を関連付けるには、Ordersエンティティ・タイプのOrdersという属性をCustomerに追加します。1つのCustomerに対して多数のOrdersがあるので、これを配列にします。

6. Customerエンティティのマッピング・タブを使用して、CustomerエンティティとOrdersエンティティ両方のすべての属性値をマップできます。

13.6.11 インポートされたJavaクラスの追加

インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。

13.6.12 セッション・ロジック

セッション要素は、セッションの初期化および終了で実行されるスクリプトレットを受け入れます。cleanUpスクリプトレットは、セッションがクローズされるときにコールされます。

13.6.13 セッションAPI

次のコードはそれぞれ、オブジェクトのラベルと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();

13.6.14 エンティティAPI

次のコードはそれぞれ、オブジェクトのラベルとIDを返します。

public String getSDOLabel();
public String getSDOId();

13.6.15 エンティティ・クラスについて

生成される通常のクラスに加え、各エンティティには配列クラスも生成されます。生成されるクラスには、各属性のプロパティ、ゲッターおよびセッターがあります。したがって、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) {
}
}

13.6.16 Oracle RTDロジックでのエンティティの参照

クラスはエンティティ・タイプごとに生成されるため、他のJavaオブジェクトと同様に、new演算子でエンティティを作成します。例:

Customer cust = new Customer();

エンティティが別のエンティティの子である場合は、オプションで親エンティティの名前を渡します。セッションは、別のエンティティの親エンティティになることもあります。

Customer cust = new Customer(entityParent);

13.6.17 エンティティ・キーの追加

ほとんどのエンティティは、キー属性の値がなければ有用ではありません。キー属性は、他の属性と同様に、生成されたセッターを使用して設定されます。

Customer cust = new Customer();
String newKey = '12345';
cust.setCustomerId(newKey);

13.6.18 エンティティ属性へのアクセス

前述のように、ゲッターは属性ごとに生成されます。ゲッターの形式は、属性が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);

13.6.19 エンティティのリセットと入力

エンティティをリセットおよび入力するために、3つの特別なメソッドが用意されています。

cust.reset();

セッション・キー以外のすべてのキーとすべての属性をリセットします。

cust.resetAttributes();

すべての属性をリセットしますが、キーはリセットしません。

cust.fill();

fillにより、エンティティ・マッピングに従って属性の値が再帰的に入力されます。データ・ソース、計算済の値または定数値によってデータが強制的にリフレッシュされます。また、エンティティ・タイプの任意の属性も入力されます。

resetおよびfillは、キャッシュされたエンティティに対してはコールしないでください。

13.6.20 キャッシュされたエンティティについて

エンティティは、アクセスしやすいようにサーバー上にキャッシュできます。エンティティをキャッシュするには、エンティティの「キャッシュ」タブをクリックします。

エンティティには次のキャッシュ関連オプションを持たせることができます。

- このエンティティ・タイプのキャッシングの有効化: このオプションを選択してキャッシュを有効にします。キャッシュされたエンティティはキャッシュされていないエンティティと同様に処理され、同じAPIを持ちますが、キャッシュされたエンティティのキーをセッション・キーとして使用することはできません。

- キャッシュする項目の最大数: キャッシュするアイテムの最大数。アイテムは先入れ先出し方式でフラッシュされます。

さらに、エンティティには次の「キャッシング方針」関連オプションを持たせることができます。

- 固定存続期間の使用: リフレッシュされるまで各オブジェクトをキャッシュに維持する秒数。

- 固定期間の使用: キャッシュ全体がリフレッシュされるまでの秒数。

- キャッシュをリフレッシュしない: キャッシュされたアイテムは、最大数に達するまでキャッシュに維持されます。

エンティティがキャッシュにマークされている場合、次のコードを使用して属性を設定します。エンティティを作成したら、キー値を設定して、キャッシュから属性値を取得します。キャッシュされたエンティティ属性(キー以外)には、セッターがありません。そのため、エンティティはキャッシュされたバージョンと常に同期します。

Customer cust = new Customer();
String newKey = '12345';
cust.setCustomerId(newKey);
cust.getCustomerId();
cust.getName();
cust.getAge();
cust.getAccounts();

13.6.21 エンティティ属性のロギングの拡張

問題

デバッグやロギングを行うには、設定しているOracle RTDエンティティの現在値を調べるために、logDebugやlogInfoなどのログ記録文を開発者は記述する必要があります。通常は、Oracle RTDログに値を出力する必要がある各エンティティ属性に対して1行以上のコードが必要です。これによって、出力をログに記録することのみを目的とするコードが大量に追加されます。

解決策

Oracle RTDプラットフォームには、すべてのセッション・エンティティ属性の値または指定したエンティティとその属性の値をOracle RTDログに出力できるAPIが用意されています。出力は、情報、デバッグ、エラー、警告およびトレースのすべてのログ・レベルで行われます。

APIの一般形式

注意:

1. この項では、logInfoコマンドについてのみ説明します。logDebug、logError、LogWarningおよびlogTraceの各コマンドにも、すべての拡張ロギング・オプションが適用されます。

2. 説明を単純にするために、各ロギング・オプションには基本となるactiveパラメータのみが示されています。各パラメータにテキスト情報を連結することで、ロギング・メッセージの情報量を増やすことができます。

セッションのすべての属性をログに記録するには、次のように記述します。

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

13.7 パフォーマンス目標

組織の意思決定プロセスの設計では、まず、Oracle RTDデシジョンの導入によって改善する必要のある具体的なメトリックを検討します。一般的なパフォーマンス・メトリックとして、次の2つがあります。

- Webサイトを訪問した顧客当たりの売上

- コンタクト・センターにおける顧客通話当たりの処理コスト

パフォーマンス・メトリックは、最適化の方向(最大化または最小化)と正規化ファクタで構成されます。

パフォーマンス目標の特徴は次のとおりです。

- パフォーマンス・メトリック: 組織がデシジョンの成功の度合いを測定するように選択したメトリック。

- 最適化: パフォーマンス・メトリックを最適化する方向を示す値、「最小化」または「最大化」。

- 必須:パフォーマンス・メトリックのスコアリングが必要な場合は選択します。メトリックが必須としてマークされていない場合、データ不足によってスコアが使用できないと、Oracle RTDは別のスコアを調べてスコアを提供します。メトリックが必須としてマークされている場合、全体的なスコアは提供されません。そのメトリックは使用不可とマークされ、スコアリング・プロセスから削除されます。

- 正規化係数: このパフォーマンス・メトリックの組織の相対値。

この項には次のトピックが含まれます:

- 第13.7.1項「パフォーマンス・メトリックの追加」

- 第13.7.2項「正規化ファクタの計算」

13.7.1 パフォーマンス・メトリックの追加

パフォーマンス目標要素を選択してから、「追加」をクリックしてパフォーマンス・メトリックを追加します。メトリック(例: 収益)、最適化の方向(最大化)、メトリックで意思決定を行うためのスコアを使用可能にする必要があるかどうかを追加します。

メトリックをすべて追加したら、正規化ファクタを決定する必要があります。

13.7.2 正規化ファクタの計算

インライン・サービス開発者やビジネス・ユーザーが本来の測定スケールが異なるパフォーマンス目標に対するスコアリング関数を表現するには、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の場合、このパフォーマンス目標はその選択肢では無視され、デシジョンで使用される他のパフォーマンス目標の重み付けにおいて、不要とマークされたパフォーマンス目標の重み付けが均等に分配され調整されます。

注意:

外部化されたパフォーマンス目標とその重み付けのコンテキストでは、インライン・サービス開発者が重み付けを正規化する必要があります。

13.8 選択肢グループおよび選択肢

選択肢は、意思決定プロセスで評価されるオブジェクトです。また、ビジネス・プロセスをモデル化するためのスタディ対象になる場合もあります。意思決定プロセスで使用された場合、候補となる選択肢のリストから最適な選択肢がアドバイザ・コールを介して返されます。意思決定プロセスにおける選択肢の例を次に示します。

- マーケティング・オファーの選択元リスト

- 推奨製品リスト

- タスクのリソース・リスト

選択肢は、選択肢グループにまとめることができます。選択肢グループと選択肢は階層ツリーに似た構造として編成され、1つの親選択肢グループの下に複数の子選択肢グループが存在できます。候補となる選択肢のリストから選択肢を選択すること、すなわちデシジョン・プロセスは、次のロジックに従って段階的に行う操作です。

1. 適格性: デシジョンに対して選択肢を検討する必要があるかどうかを決定するルールのセットです。適格性ルールは、選択肢グループと選択肢の階層の各レベルで定義できます。

2. スコアリング: デシジョンに対して定義されている各パフォーマンス目標に沿ったスコアの計算です。

3. 正規化: 様々なパフォーマンス・メトリックに沿ってスコアを一般のスケールに移行して、スコアを比較できるようにします。

4. 総計化: 選択肢ごとに1つの数値を生成します。この数値は、デシジョンの適用先セグメントの各パフォーマンス目標の正規化済スコアを重み付けして合計した値です。

5. 選択: 選択肢の合計スコアに基づいて最適な選択肢の設定数を選択します。

選択肢には、静的選択肢と動的選択肢があります。

静的選択肢の場合、リクエスト元アプリケーションまたは自己学習モデルに提示される選択肢は、Oracle RTD内で完全に定義されます。静的選択肢は、選択肢が既知の場合と、一定期間にわたって一定の場合に役に立ちます。

動的選択肢は、実行時に動的に構築される選択肢です。この選択肢は通常、外部データ・ソースに保持されます。これにより、オファー管理システムで定義したオファーに基づく選択肢など、ソース・システムで選択肢を管理できます。

注意:

選択肢グループは常に静的であり、Oracle RTDインライン・サービスで定義されます。

この項では、選択肢グループおよび静的選択肢と動的選択肢の両方に該当する一般的な特徴とプロセスについて説明します。動的選択肢の詳細は、第17章「外部化されたオブジェクト管理」を参照してください。

この項には次のトピックが含まれます:

- 第13.8.1項「選択肢グループおよび選択肢について」

- 第13.8.2項「選択肢グループと選択肢属性について」

- 第13.8.3項「選択肢属性の特徴」

- 第13.8.4項「選択肢のスコアリングについて」

- 第13.8.5項「適格性ルールについて」

- 第13.8.6項「選択肢グループのルールおよび選択肢の適格性ルールの評価」

- 第13.8.7項「適格性の判定」

- 第13.8.8項「選択肢グループのAPI」

- 第13.8.9項「選択肢のAPI」

13.8.1 選択肢グループおよび選択肢について

選択肢グループと選択肢には次の特徴があります。

- 属性: 選択肢を構成する属性。これらは、親の選択肢グループから継承されるか、選択肢レベルで割り当てられます。

- スコア: 各選択肢は、「スコア」タブの定義に従ってスコアリングされます。選択肢は、デシジョンで定義されているすべてのパフォーマンス・メトリックに対してスコアリングされます。

- 選択肢イベント: 選択肢イベントは、グループ・レベルでのみ記述されます。これらのイベントによって、選択肢のライフサイクルで重要なイベントが識別されます。たとえば、実行されるCross Selling Offerには、Offered、Accepted、Product First Usedなどのイベントがあります。

- ルール: 選択肢に適用可能なルールには2つのタイプがあり、デシジョン・センター・ユーザーはどちらのルールも作成や変更ができます。

- 適格性ルールにより、デシジョンで選択肢を検討する条件を制御します。適格性ルールは、選択肢グループ階層のどのレベルでも定義できます。選択肢は、その上位階層で定義されている適格性条件を継承します。

- スコアリング・ルールを使用して、選択肢に数値スコアを関連付けることができます。これらのスコアは、パフォーマンス目標スコアリング・ロジックの一部として使用したり、選択肢の属性として使用できます。

スコアリング・ルールは別個の要素として定義され、該当する選択肢に適用されるのに対し、適格性ルールは選択肢グループ・レベルまたは選択肢レベルで直接定義されます。

- 詳細: 「詳細」ボタンを使用すると、デシジョン・センターに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。

13.8.2 選択肢グループと選択肢属性について

選択肢グループ属性を使用して、グループ・レベルで属性を定義します。グループ属性は選択肢グループ・レベルにのみ適用され、個々の選択肢には割り当てられません。

選択肢属性は、グループ内の各選択肢が同じ属性のセットを持つように選択肢グループ・レベルで定義されます。選択肢属性の値は、選択肢レベルで個別に定義します。選択肢属性にはデフォルト値を設定できます。これは、低位レベルでオーバーライドできます。

選択肢グループおよび選択肢は階層的に定義されます。階層は、選択肢の論理分類に準拠します。最上位レベルでは、サブツリー全体で一貫性のある選択肢属性の定義を考慮する必要があります。低位レベルでは、階層の形は通常、組織の事情を考慮して決定されます。

選択肢属性は、通常、階層の高位レベルで定義します。属性の中にはオーバーライド不可とマークされているデフォルト値を持つものもあります。これは、デフォルトで設定された値が使用される値になることを示します。これは一般に計算が含まれる場合に設定されます。これはデプロイ後、ビジネス・ユーザーに属性を更新させないようにする場合に有用です。

選択肢属性の値は次のいずれかにできます。

- 定数

- 属性または変数

- 関数またはルール・コール

- モデル予測

図13-3に、CrossSellインライン・サービスで構成されている選択肢グループの例を示します。

図13-3 選択肢グループの例

この例のOffersレベルで設定されている選択肢属性を表13-8に示します。

表13-8 Offers選択肢グループの例のOffersレベルで設定されている選択肢属性

属性

型

値

Message

String

デフォルト値なし。各選択肢の値は選択肢レベルで割り当てられます。

shouldRespondPositively

Boolean

特定の選択肢に対して顧客が肯定的に反応するかどうかを示すブール値を返すShouldRespondPositively()関数。この関数は、loadgenシミュレータのコンテキストで使用されます。

Likelihood of Purchase

Double

この選択肢グループが登録されている選択肢モデルまたは選択肢イベント・モデルによって割り当てられるプレースホルダ属性。選択肢が購入される確率に使用します。実行時に計算されるため、デフォルト値はありません。

Profit Margin

Double

提示するオファーの収益性の指標(%)。デフォルト値は0.5です。各選択肢の値は選択肢レベルで割り当てられます。

各選択肢は、Profit MarginおよびMessageの値を、その選択肢を示す値で上書きします。ただし、有効な期間にサーバーが応答できない場合は、実行時にデフォルト値が使用されます。

どの選択肢もshouldRespondPositively属性をオーバーライドしません。これは、すべての選択肢が同じ関数を使用してその値を決定するためです。Likelihood of Purchaseは、実行時に選択肢ごとにモデルで計算されます。

13.8.3 選択肢属性の特徴

選択肢属性の特徴は次のとおりです。

- 名前: 属性の名前。

- カテゴリ: 属性が属するカテゴリ。カテゴリは、Category要素で定義されます。

- タイプ: 属性のデータ型。

- 配列: 属性がコレクションであるかどうか。

- タイプ制約: ルールで選択肢属性または選択肢グループ属性を使用する場合、属性の型制約を選択できます。これは必須要件ではありませんが、ルールの定式化に役立ちます。型制約の作成と使用の詳細は、第13.19項「型制約について」を参照してください。

- 継承した値: 存在する場合は、選択肢グループまたは選択肢の属性が親から継承した値。

- 値: 属性の値。この値は、常に継承した値を上書きします。

- デシジョン・センターで表示: このオプションを選択すると、ビジネス・ユーザーに対して属性がデシジョン・センターで表示されるようになります。属性を内部的に使用する場合は、選択解除します。
第13.6.5項「解析の属性の使用」のNULLと空文字列に関する注意も参照してください。

- 索引付けに使用: 指定した属性で選択肢を検索できるようにする場合、このオプションを選択します。たとえば、nameという選択肢属性があるとします。選択肢グループに、getChoiceWithName(String name)という名前の静的メソッドが生成されます。このメソッドは選択肢を1つ返します。
このオプションを選択する場合、この属性の値がすべての選択肢の中で一意であることが必要です。

- クライアントへ送信: この選択肢を返すインライン・サービスをコールする外側のクライアントに属性を送信する場合は、このオプションを選択します。

選択肢属性を追加または削除するには、「追加」または「削除」をクリックします。

選択肢属性を編集するには、属性を右クリックして、「プロパティ」を選択します。選択肢属性は、定義されている最上位レベルでのみ編集できます。

13.8.4 選択肢のスコアリングについて

選択肢は、その親からスコアリング関数を継承します。選択肢のスコアリングで、その選択肢に適用するパフォーマンス・メトリックを特定して、スコアリング・メソッドをそれに適用します。スコアリング・メソッドには、スコアリング・ルール、関数、定数、選択肢イベント・モデルでのイベントの発生率などを指定できます。

たとえば、図13-3に示す選択肢グループ構造を仮定すると、一部の選択肢は次のようなスコアリングを持つ場合があります。

- Mileage Plus Card

- パフォーマンス・メトリック: 売上の増加

- スコア: 顧客がオファーを受け入れる可能性と、オファーの潜在的売上を計算するためにカードの期待利益を使用する関数。可能性はモデルで計算されます。

- Gold Card

- パフォーマンス・メトリック: 売上の増加

- スコア: 選択肢グループ・レベルから継承された定数

- Credit Analysis

- パフォーマンス・メトリック: 顧客維持の増加

- スコア: 顧客データを使用してスコアを割り当てるスコアリング・ルール

注意:

選択肢または選択肢グループの「スコア」タブの「スコア」列で定義されるスコアの値は、任意の実数(つまり、正の値、負の値またはゼロ)にできます。

13.8.5 適格性ルールについて

適格性ルールは、選択肢グループ・レベルおよび選択肢レベルで次のように使用できます。

- 選択肢グループには選択肢適格性ルールとグループ適格性ルールを設定でき、それぞれ選択肢グループ・エディタの「選択肢の適格性」タブと「グループの適格性」タブにあります。
選択肢グループのグループ適格性ルールは、選択肢グループ・レベルで定義される属性に適用されます。

選択肢グループの選択肢適格性ルールは、一般的にその選択肢グループに定義されている選択肢の属性に適用されます。

- 選択肢には選択肢適格性ルールを設定でき、選択肢エディタの「適格性ルール」タブにあります。

選択肢および選択肢グループに対するこれらのルールによって、意思決定の参加の適格性が判断されます。適格性ルールにより、目的の選択肢が、選択関数やデシジョンのルールまたは選択肢を選択するロジックへの参加に適格かどうかを判断します。

適格性ルールにより、選択肢グループまたは選択肢の先頭となるサブツリーが意思決定に適格かどうかを判断します。選択肢自身が適格であっても、そのすべての子孫が適格でないと、それらは適格となりません。

これらのルールのエディタを使用する方法の詳細は、第13.11項「ルール・エディタの使用」を参照してください。

13.8.6 選択肢グループのルールおよび選択肢の適格性ルールの評価

選択肢グループおよび選択肢のルールは、継承され、追加されるようになっています。つまり、選択肢グループ(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

13.8.7 適格性の判定

選択肢の適格性を判断する場合、選択肢に対して不必要に適格性ルールが評価されないように、最初に親の適格性がテストされます。

13.8.8 選択肢グループのAPI

次のコードはそれぞれ、オブジェクトのラベルとIDを返します。

public String getSDOLabel();
public String getSDOId();

次のコードは、選択肢グループから選択肢オブジェクトを返します。

public Choice getChoice(String internalNameOfChoice);

選択肢属性が索引にマークされていると、次のメソッドを使用して、索引付き属性で参照される選択肢を返します。

public Choice getChoiceWithAttributeID(AttributeType val);

13.8.9 選択肢のAPI

次のコードはそれぞれ、オブジェクトのラベルと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.9 フィルタリング・ルール

フィルタリング・ルールは、スタンドアロン・ルールとして、母集団のセグメント化に使用したり、他のルールのコンポーネントとして使用できます。スタンドアロン・ルールは、様々な要素で再利用可能です。

母集団のセグメントの識別に通常使用されるルールを図13-4に示します。

図13-4 フィルタリング・ルール

「図13-4 フィルタリング・ルール」の説明

図13-4のルールは、年齢が18歳以上で信用限度額が$8000以上の顧客をターゲットとしています。

ルールの編集の詳細は、第13.11項「ルール・エディタの使用」を参照してください。

13.10 スコアリング・ルール

ブール値を返す適格性ルールと異なり、スコアリング・ルールでは数値を返します。返された値は、Oracle RTDのデシジョン・ロジック全体で使用できます。通常は次のような場合に使用されます。

- 特定のパフォーマンス目標の選択肢のスコアを設定する場合

- 選択肢属性の値を設定する場合

スコアリング・ルールには、どのルール・セグメントもtrueに評価されない場合のデフォルト値があります。

値を追加するには、「値」列の「その場合」または「値は次のとおりです」の下をクリックします。ここで、他のルール値と同様に、省略記号をクリックして値を編集します。

たとえば、図13-5に示すスコアリング・ルールでは、顧客の信用限度額に基づいてスコアが割り当てられます。いずれの信用限度額の範囲のカテゴリにも該当しないと、スコアはデフォルトの3.25になります。

図13-5 スコアリング・ルールの例

「図13-5 スコアリング・ルールの例」の説明

また、スコアリング・ルールには次のオプションがあります。

- 説明: スコアリング・ルールはデシジョン・センター・ユーザーが調整できるため、スコアリング・ルールを適切に記述することが重要です。スコアの範囲を記入することをお薦めします。

- 詳細: 「詳細」ボタンを使用すると、デシジョン・センターに要素を表示し、その要素のラベルを変更することもできます。要素のラベルを変更しても、オブジェクトIDは変更されません。

ルールの編集の詳細は、第13.11項「ルール・エディタの使用」を参照してください。

13.11 ルール・エディタの使用

ルールは、デシジョン・スタジオ内およびデシジョン・センター内で、様々な目的に使用します。具体的には次のような目的があります。

- 選択肢グループや選択肢をデシジョンに含めるかどうかの適格性を判断するため

- スタンドアロンとして、意思決定のために母集団セグメントの作成に使用するフィルタリング・ルールを作成するため

- スタンドアロンとして、選択肢のスコアリングに使用するスコアリング・ルールを作成するため

ルール・エディタのツールバーを使用すると、ルールの編集に使用する機能にアクセスできます。エディタのツールバーには、各ルール・エディタでルールを作成する際に必要な機能が用意されています。これらの機能は、ユーザーが実行するルール作成やルール編集のコンテキストに応じてアクティブになります。

図13-6 ルール・エディタのツールバー

「図13-6 ルール・エディタのツールバー」の説明

ツールバーには、左から順に次の機能があります。

- ルール・プロパティを編集

- 条件値の追加

- ルールの追加

- ルール・セットの追加

- 削除

- 反転

- 上に移動

- 下に移動

- コピー

- 切取り

- 貼付け

ルールの作成に使用するエディタは、それぞれよく似ています。次の各項では、これらのエディタを使用してルールを作成する方法について説明します。

この項には次のトピックが含まれます:

- 第13.11.1項「Oracle RTDのルールの項目と文」

- 第13.11.2項「ルールへの文の追加」

- 第13.11.3項「演算子の選択」

- 第13.11.4項「ブール文の編集」

- 第13.11.5項「ルールのプロパティの編集」

- 第13.11.6項「ルール要素の逆転」

13.11.1 Oracle RTDのルールの項目と文

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のルール文法

項目

項目のコンポーネント

注意

<RTDルール>

<ヘッダー行> <論理演算子> <ルール・エントリ>+ |

<ヘッダー行> <配列演算子> <論理演算子> <ルール・エントリ>+

なし

<ヘッダー行>

<ルール名> is true when

ルールに名前を割り当てます。

ルールが作成された後は、ヘッダー行の編集はできません。

<論理演算子>

次のすべて | 次のいずれか |

次のいずれでもない | 次の一部

論理演算子により、直後に続く<rule entry>を制御します。ルールを最初に作成すると、デフォルト論理演算子のAll of the followingが使用されます。

<ルール・エントリ>

<ブール文> | <ルール・セット>

ルール・エントリには必ず番号が付与されます。ルール・エントリには、ブール文などのルール・エントリを記述できます。

<ルール・セット>

<論理演算子> <ルール・エントリ>+ |

<配列演算子> <論理演算子> <ルール・エントリ>+

2番目の<ルール・セット>構成要素オプションを「配列処理ルール・セット」と呼びます。

<ブール文>

<ブール値> |

<ブール関数> |

<左辺オペランド> <関係演算子> <右辺オペランド>

<boolean statement>は、ルール・セットの最小レベルであり、さらに分解することはできません。

<配列演算子>

<数量子> <配列変数> in <配列名> ,

配列処理ルール・セットでのみ使用されます。詳細は、「数量詞および配列処理ルール」を参照してください。

<数量子>

すべて | 次が存在

なし

前述の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では、配列内の値に依存するルール・セットがサポートされています。詳細は、「数量詞および配列処理ルール」を参照してください。

論理演算子

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にある個々の配列要素を識別するための任意の名前です。

注意:

1. array_variableは、独自の配列変数を持つ下位レベルのルール・セットのブール文からでも参照できます。

2. array_variableはルールの範囲内で一意である必要があります。つまり、下位レベルの配列処理ルールの配列変数と同じarray_variableの名前は使用できません。

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"

13.11.2 ルールへの文の追加

ルール・セットの追加
ルール・セットを追加するには、「ルール・セットの追加」アイコンをクリックします。

ルールに最初に作成する要素の場合、ルールに次の文が表示されます。

- デフォルト論理演算子のAll of the following

- ルールの番号付きの先頭行として表示されるルール・セット・エントリ: デフォルト論理演算子のAll of the followingが含まれます

- オペランドが2つで空のブール文: 新たに定義されるルール・セット内にあります

これ以外の場合、現在のルール・セットで次のエントリとして、オペランドが2つで空のブール文を含む新規ルール・セット・エントリが追加されます。たとえば、ブール文が1つ含まれている既存ルール・セットにルール・セットを追加すると、追加されたルール・セット・エントリは、次に示すように、行番号2の横に表示されます。

ルール・セットの右上隅をクリックすると、名前を付与できます。ルール・セットに名前を付与する際、ルール・セット・ボックスの右上隅にある山形記号アイコンをクリックすると、ルール・セットを開いたり閉じることができます。

ルールへの(ブール文の)追加

ブール文を追加するには、「ルールの追加」アイコンをクリックします。

ルールに最初に作成する要素の場合、次に示すように、デフォルト論理演算子のAll of the followingが表示され、その後にオペランドが2つで空のブール文が表示されます。

これ以外の場合、オペランドが2つで空のブール文が現在のルール・セットに追加されます。ブール文が1つ存在する場合の例を次に示します。

デフォルトでは、ブール文には2つのオペランドとそれらの間に演算子があります。

ブール文を1オペランドと2オペランドで切り替えるには、次の例に示すように、ブール文の行番号をクリックし、ブール文ボックスの右下隅の矢印アイコンをクリックします。

1オペランドは、常にブールとして評価されます。

13.11.3 演算子の選択

演算子を選択するには、演算子をクリックしてから、右下隅をクリックします。

表13-10に、使用可能な演算子の一覧を示します。

表13-10 ルール演算子

演算子

説明

なし

オペランドが1個しかない単純な式

=

左が右と等しい

<>

左が右と等しくない

<

左が右より小さい

<=

左が右以下

>

左が右より大きい

>=

左が右以上

次に含まれる

左側の値が右側のリストに含まれる

次に含まれない

左側の値が右側のリストに含まれない

次のすべてを含む

左側のリストに、右側のリストの値がすべて含まれる

次のすべてを除外

左側のリストに、右側のリストの値が何も含まれない

次のいずれかを含む

左側のリストに、右側のリストの値のいずれかが含まれる

次のすべてを含まない

左側のリストに、右側のリストの値の一部が含まれない

13.11.4 ブール文の編集

ルールのブール文を編集するには、左側をクリックしてから、省略記号をクリックします。定数、属性、関数コールのいずれかを選択できます。配列の値を指定するには、ページの最上部で「配列」を選択します。

注意:

演算子ダイアログは、[Esc]キーを使用していつでも閉じることができます。

- 「定数」を選択した場合、項目の「データ型」および「値」を指定します。「配列」を選択した場合、必要な数の項目を配列に追加します。次に、各項目について「データ型」を選択し、「値」を指定します。

- 「属性」を選択した場合は、次のいずれかを指定します。

- グループ属性: ルールのプロパティで選択されている選択肢グループまたはその選択肢の一部である属性。

- セッション属性: セッション・エンティティの一部である属性。

- アプリケーション属性: アプリケーション要素のメンバーである属性。

- 配列変数: 数量化された論理演算子式内にあるルール・セットの個々の配列要素を識別するための名前。詳細は、「数量詞および配列処理ルール」を参照してください。

フィルタ・タイプの適用を選択し、「データ型」を選択して、型別に属性をフィルタリングします(必須ではない)。「配列」を選択した場合は、必要な数の項目を配列に追加してから、それぞれに属性値を割り当てます。

- 「関数コール」を選択した場合は、次のいずれかを指定します。

- フィルタリング・ルール: インライン・サービス用に定義されているスタンドアロンのフィルタリング・ルール。

- スコアリング・ルール: インライン・サービス用に定義されているスタンドアロンのスコアリング・ルール。

- 関数コール: インライン・サービス用に定義されているスタンドアロンの関数。

フィルタ・タイプの適用を選択し、「データ型」を選択して、型別に属性をフィルタリングします(必須ではない)。「配列」を選択した場合は、必要な数の項目を配列に追加してから、それぞれに関数またはルールを割り当てます。

13.11.4.1 ルールにおける型制約オブジェクトの使用

オペランドまたはオペランドの一部として型が制約されたオブジェクトを選択すると、他のオペランドの値が含まれるドロップダウン・リストから値を表示できます。このドロップダウン・リストから値を選択できますが、値の選択は必須ではありません。

型制約と型制約オブジェクトの詳細は、第13.19項「型制約について」を参照してください。

13.11.5 ルール・プロパティの編集

フィルタリング・ルールにもスコアリング・ルールにもルールのプロパティがあり、そのプロパティは設定可能です。ルールのプロパティを編集するには、「ルール・プロパティ」アイコンをクリックします。

「ルール・プロパティを編集」が表示されます。

ルールのプロパティには、コール・テンプレートとネガティブ・コール・テンプレートがあります。コール・テンプレートを使用すると、別のルールからルールをコールする方法がわかりやすくなります。

コール・テンプレートを定義するには、「パラメータ」の下の「追加」ボタンをクリックして、ルールのパラメータの数を増やします。{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

ルールのプロパティを使用すると、ルールで使用する選択肢グループを割り当てることもできます。「選択肢グループで使用」を選択することにより、パラメータで使用する選択肢属性を提供する選択肢グループまたはその中の選択肢を指定できます。これらの属性は、オペランドの値を編集するときに使用できます。

13.11.6 ルール要素の反転

「反転」アイコンは、ルールで複数の要素を逆にします。ブール文の番号を選択することで、ブール文の演算子を逆にできます。たとえば、演算子が=であった場合は、反転して<>になります。

ルール・セットの論理演算子も逆にできます。それには、論理演算子を選択して「反転」をクリックします。たとえば、「次のすべて」は「次の一部」になります。

「反転」の最後の使用方法は、ブール、つまり1オペランドのルールを逆にすることです。このタイプのルールを逆にすると、ルールを定義する関数のネガティブ・コール・テンプレートに変換されます。

13.12 デシジョンについて

デシジョンは、適格な選択肢のグループから1つ以上の選択肢を選択するために使用します。デシジョンは、アドバイザ内で使用するのが最も一般的です。アドバイザでは、2つのデシジョンをコールできます。1つは、通常の処理に使用するデシジョンで、もう1つはインライン・サービスでコントロール・グループ機能を使用する場合のデシジョンです。

デシジョンの設定には、選択肢の選択元である選択肢グループを1つ以上だけでなく、選択肢に順序を付けるための数値選択基準も含まれている必要があります。

選択肢の選択は、ランダムにもできますし、カスタム選択関数によってもできます。また、関連するパフォーマンス目標ごとに選択肢グループ・レベルで構成されているユーザー定義スコアリング・ロジックに基づいても選択できます。

静的スコア、関数ドリブン値、ルールベースのスコアまたは予測スコアなど、様々なスコアリング手法を使用して、選択肢ごとに複数のスコアを定義できます。

実行時に、デシジョンでは、関連付けられた選択肢グループのサブツリーで適格な選択肢をすべて識別します。次に、適格な選択肢がすべてスコアリングされ(1つ以上のスコアを使用して)、順序付けされます。

選択肢のスコアリング手法の例を次に示します。

- 選択肢に関心を持つ確率(Oracle RTDの自己学習予測モデルで計算)

- 選択肢のビジネス価値(ユーザー定義のルールまたは関数で計算)

あるいは、カスタム選択関数を作成して選択肢を選択することもできます。

選択基準は次のとおりです。

- 選択肢を次から選択: デシジョンでの検討対象となる選択肢グループ(複数可)の割当てに使用します。

- 選択する選択肢の数: デシジョンで選択される選択肢の最大数を示します。実行時に返される選択肢の実際の数は、適格性ルールに基づいて、この数と同等以下になる場合もあります。
複数の接点で1つのデシジョンがコールされ、そのたびに異なる数の選択肢を返す必要がある場合、この数をアドバイザ・レベルで上書きできます。

デフォルトであり、最も一般的に使用される数値は1です。

- 選択のタイプ用ラジオ・ボタン: 選択されたラジオ・ボタンによって、ランダムな選択肢を選択するか、選択肢を選択する手順の一部として重み付けされたパフォーマンス目標を使用するかが制御されます。

1. 「固定目標加重で選択」オプションにより、母集団セグメントを指定し、各セグメントのパフォーマンス目標の重み付けを設定できます。このオプションを選択すると、画面に次に示す領域が表示されます。

- ターゲット・セグメント: フィルタリング・ルールを使用してセグメント化されている母集団のセグメント。デフォルトのセグメントは全員(everyone)です。

- 優先度: 特定のセグメントのパフォーマンス目標の重み付けの設定に使用します。スコアリングで使用されるパフォーマンス目標は、デシジョンで選択されます。したがって、指定された各目標は、デシジョンで選択されている各選択肢グループのスコアリング方法に適合している必要があります。

2. 「カスタム目標加重で選択」オプションにより、パフォーマンス目標のカスタム重み付けを設定できます。通常は実行時にパフォーマンス目標の重み付けを返す関数を実行します。
「カスタム目標加重で選択」オプションを選択し、その横にある省略記号ボタンをクリックした場合、「値」ウィンドウで次のいずれかを選択する必要があります。

- 「関数またはルール・コール」を選択してから、データ型がcom.sigmadynamics.sdo.GoalValuesを返す関数を選択します。

- 「属性または変数」を選択してから、型がcom.sigmadynamics.sdo.GoalValuesであるアプリケーション・パラメータまたはセッション属性を選択します。

3. 「ランダムに選択」オプションを選択すると、選択肢グループからランダムに選択した選択肢を割り当てます。これは主として、Control Groupデシジョンに使用します。

「固定目標加重で選択」オプションと「カスタム目標加重で選択」オプションの詳細は、第13.12.1項「母集団のセグメント化と目標の重み付け」を参照してください。

選択肢グループを追加するには、「選択」をクリックしてから、使用する選択肢グループ(複数可)を選択します。

デシジョンのパフォーマンス目標を選択するには、「目標」をクリックしてから、適切な目標を選択します。

この項には次のトピックが含まれます:

- 第13.12.1項「母集団のセグメント化と目標の重み付け」

- 第13.12.2項「カスタム選択関数の使用」

- 第13.12.3項「選択前と選択後のロジック」

- 第13.12.4項「目標のカスタム重み付けの選択関数API」

- 第13.12.5項「インポートされたJavaクラスの追加とデシジョン・センターの表示の変更」

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関数、スコアリング・ルール、関数など)が、適格な選択肢すべてに適用されます。スコアは、パフォーマンス・メトリックの正規化ファクタを使用して均一化されます。次に、デシジョンに含まれているパフォーマンス・メトリックの重み付けに従って、スコアに重みが付けられます。全体のスコアが得られ、スコアが最も高い選択肢が選択されます。

13.12.2 カスタム選択関数の使用

標準のスコアリング・デシジョン・プロセスではなく、カスタム選択関数を使用する場合は、「カスタム選択」タブで「カスタム選択」オプションを選択します。リストから選択関数を選択し、関数に必要なパラメータを追加します。

13.12.3 選択前と選択後のロジック

「選択前/後」タブのスクリプトレットは、スコアリングが完了してデシジョンが作成される前または後に実行されます。

選択前ロジックは、適格な選択肢をすべて収集してから選択が行われるまでの間に実行されます。選択後ロジックは、選択後、選択した選択肢が返されるまでの間に実行されます。選択後ロジックの方が一般的です。たとえば、この部分を使用して、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 */

13.12.4 目標のカスタム重み付けの選択関数API

重み付けパラメータの型はGoalValuesです。GoalValuesクラスには、デシジョンで定義されている目標ごとに、getValueメソッドがあります。たとえば、目標がCustomerRetentionとRevenueの場合、メソッドは次のようになります。

public double getValueForCustomerRetention();
public double getValueForRevenue();

13.12.5 インポートされたJavaクラスの追加とデシジョン・センターの表示の変更

インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。デシジョン・センターの表示ラベルを変更して、その要素をデシジョン・センターNavigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。

13.13 選択関数について

標準のスコアリング・デシジョン・プロセス以外の方法として、デシジョンでは選択関数を使用できます。選択関数はすべてユーザーが定義します。ただし、選択関数には明確な特性があります。選択肢配列を入力すると、出力として選択肢配列が返されます。

選択関数には、説明および次に示すパラメータがあります。

- 入力選択肢配列: 選択関数に対する入力パラメータ。この変数のデータ型はSDChoiceArrayです。

- 出力選択肢配列: 選択した選択肢を含む変数の名前を指定し、この選択関数のコール元に返す必要のある戻り変数。この戻り値は、この選択関数に渡される「入力選択肢配列」、または「ロジック」パネル内でローカルに定義した別の変数になります。この変数のデータ型はSDChoiceArrayです。

- 選択肢パラメータの数: 選択関数で返す必要のある選択肢の数を表す関数の引数の名前。このパラメータのデフォルト名はnumChoicesです。この引数のデータ型はintです。

- 加重: この選択関数を使用するデシジョンに目標が定義されている場合は、その目標が、「加重」で指定されているパラメータの下の選択関数に渡されます。この型はGoalValueです。GoalValueの詳細は、デシジョンに関する項を参照してください。

- 追加のパラメータ: 選択関数で必要なその他すべてのパラメータ。

この項には次のトピックが含まれます:

- 第13.13.1項「選択関数のスクリプトレット」

- 第13.13.2項「インポートされたJavaクラスの追加とデシジョン・センターの表示の変更」

13.13.1 選択関数のスクリプトレット

選択関数は、選択条件のカスタム関数として使用します。数多くの標準的な優先度関数が、テンプレートを使用して利用できます。優先度関数や選択関数は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);

13.13.2 インポートされたJavaクラスの追加とデシジョン・センターの表示の変更

インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。デシジョン・センターの表示ラベルを変更して、その要素をデシジョン・センターNavigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。

13.14 モデルについて

モデルは、主に予測およびレポートの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モデルの機能と戦略」を参照してください。

この項の以降の内容は次のとおりです。

- 第13.14.1項「モデルの種類」

- 第13.14.2項「共通のモデル・パラメータ」

- 第13.14.3項「モデルの属性」

- 第13.14.4項「モデルのAPI」

13.14.1 モデルの種類

Oracle RTDでモデルを定義する場合、選択肢イベント・モデル、選択肢モデルおよびモデルの3種類から選択できます。

モデルの各種類は、事前定義済の使用パターンに対応しています。ほとんどの特性は共通していますが、ビジネス・デシジョンを向上する目的で予測を使用する際の自動化の度合いが異なります。すべての種類のモデルを予測とレポートに使用できます。

- 選択肢モデルと選択肢イベント・モデル: これらのモデルは、選択肢グループ型のターゲット属性に関連付けられます。
選択肢イベント・モデルは、ベース・イベントに応じて、イベント発生の条件付き確率の予測と分析に使用します。選択肢イベント・モデルは、1つのベース・イベントとポジティブ・イベント一覧によって定義されます。このモデルを使用して、ベース・イベントが発生した場合にポジティブ・イベントが発生する条件付き確率を予測できます。モデルでは、ポジティブ・イベント一覧は順序として解釈されます。

複数の選択肢イベント・モデルを定義して特定の選択肢グループで発生する同一イベント・グループを追跡することは可能であり、一般的に行われます。モデルごとの違いは、時間枠、ベース・イベントまたはパーティション化属性に関するものがほとんどです。

選択肢モデルは、一般的な選択肢の発生率の予測と分析に使用します。選択肢モデルでは、選択肢に関連するイベントは定義されません。このモデルで予測するのは、選択肢が存在するかどうかです。

これは、選択肢がビジネス・プロセスに存在する可能性がある項目を表す場合に便利です。たとえば、通話理由、購入対象製品、訪問先Webページなどがあります。

- モデル: このモデルは、セッション属性型のターゲット属性に関連付けられます。プレーン・モデルまたはモデルは通常は使用されませんが、選択肢、選択肢グループおよびイベントなどの抽象的概念固有の知識のない汎用予測モデルを表します。

選択肢モデルと選択肢イベント・モデルのどちらの場合も、そのモデルに存在しない数値属性値に基づく予測は、次のように最も近い数値属性値から生成されます。

- 最高値より大きい属性値については、最高値が取得されます。

- 最低値より小さい属性値については、最低値が取得されます。

- 既存の属性値の間にあたる属性値については、予測の実行に十分なデータがあれば、最も近い値が取得されます。

13.14.2 共通のモデル・パラメータ

いくつかのモデル・パラメータは、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は変更されません。

13.14.3 モデルの属性

選択肢イベントと選択肢モデルの「選択肢」タブ

選択肢イベントと選択肢モデルの場合、「選択肢」タブには次に示す共通オプションがあります。

- 選択肢グループ

- 選択肢のラベル:デシジョン・センターで表示される選択肢グループのラベル

選択肢イベント・モデルの場合、「選択肢」タブには次に示す固有オプションがあります。

- ベース・イベント: 選択肢イベント・モデルにより計算する条件付き確率のベースラインを表す選択肢に関連付けられているイベント。イベントは、選択肢グループ・レベルで定義されているイベントのリストから選択できます。

- ベース・イベント・ラベル

- 正の結果イベント: モデルにより条件付き確率を計算する対象となるイベントのリスト。
たとえば、Product選択肢グループに関連付けられているモデルに、ベースライン・イベントとしてDelivered、ポジティブ・イベントとしてInterestedとPurchasedの2つが存在するものと仮定します。特定の製品を購入する確率は、次のように計算します。

- このモデルにより、最初にDeliveredイベントが既知であることに基づいて、Purchasedイベントの確率を計算します。この値を計算できた場合は、それを使用します。

- データが不十分でそのような予測ができない場合(つまり、モデルからNaNが返された場合)、モデルの確率関数で、Deliveredイベントが既知であることに基づいて、Interestedイベントの確率を計算します。この値を計算できた場合はそれを返します。

- データが不十分でそのような予測ができない場合、モデルの確率関数からNaNが返されます。

このとき、ポジティブ結果のリストは、予測を試みたポジティブ・イベントの順序付きリストを表します。モデルの確率関数により、イベントの順序付きリストから最もポジティブなイベントを選択できます。

選択肢モデルの場合、「選択肢」タブには次に示す固有オプションがあります。

- 相互に排他的な選択肢: このオプションは選択肢モデルの場合に使用できます。モデルのターゲットを表す選択肢が相互に排他的であることを示します。

選択肢イベントと選択肢モデルの「属性」タブ

選択肢イベントと選択肢モデルの場合、「属性」タブには次に示す共通オプションがあります。

- パーティション属性
パーティション化属性を追加してモデルをパーティション化することは、パーティション化属性の値ごとに個別にモデルを作成することと同等です。

たとえば、オファーの受入れ確率を予測するモデルを構築する場合、このオファーが提供され、受け入れられた対話チャネルを示すパーティション化属性を作成することが考えられます。Webオファーの受入れとコンタクト・センター・オファーの受入れを表すモデルを作成した場合、オファーを提示するチャネルが異なると、同じ特性を持つ顧客がオファーを受け入れる確率が大きく異なることが判明し、優れた予測モデルが実現されます。

パーティション化属性を選択した場合のデフォルト動作は、実行時に新しい各パーティション化属性値が学習プロセスに渡されると、モデルに新しいパーティションが自動的に作成されるというものです。パーティションの数を、指定した値のセットに制限できます。この入力は、選択したパーティション化属性の「値ドメイン」フィールドで行います。実行時に、指定した各値が初めて学習サーバーに渡された時点で、別個のパーティションが作成されます。指定していないすべての値に関する学習データを保持するために、Oracle RTDでは、指定していない値が初めて学習サーバーに渡された時点で、「その他」パーティションが作成されます。

多くのデシジョン・センター・レポートでは、レポート・ヘッダーでパーティション属性値を選択することで、結果をフィルタリングできます。これらのレポートで、パーティション化属性のフィルタリング値リストに「(なし)」という値がある場合は、その属性に対するNULL値が少なくとも一度は渡されたことを示します。

注意:

1. 一般に、パーティション化属性の値は実世界において有意味な値であることが必須です。NULLや空文字列にすることはできません。

2. モデル内のパーティション化属性は、「分析に使用」プロパティが選択されたセッション・エンティティ内の属性であることが必要です。

モデルをパーティション化するかどうかの決定は、次の理由から、非常に慎重に行う必要があります。

- 属性を作成することで選択肢と属性値の組合せごとの観察頻度が減少し、その結果としてモデル対話プロセスの速度が低下します。

- モデルのサイズは、パーティション化属性のカーディナリティに大きく左右されます。

- 属性の除外:デフォルトでは、セッション属性とエンティティ属性はすべて、モデル入力として使用されます。モデル入力のリストから特定の属性を除外するには、除外する属性を「除外された属性」リストに追加します。

注意:

パーティション属性を既存のモデルに追加したり、既存のモデルから削除したりすると、レポート、スナップショット、予測およびデプロイメントとの互換性が損なわれます。エラーを防止するために、Enterprise Managerを使用して古い学習データを削除してください。既存のデータを保持するには、既存のモデルをクローニングした新しいモデルを作成し、デシジョン・ロジックを更新して学習内容をこの新しいモデルに記録します。

選択肢モデルの場合、「属性」タブには次に示す固有オプションがあります。

- 集計方法: パーティション化属性の1つを選択すると、属性を学習するためのサブモデルを追加作成できます。パーティション化と同様に、ある属性に基づいて集計するデシジョンは、問題の属性の値に応じて、予測される可能性の抜本的相違に基づく必要があります。

選択肢イベントと選択肢モデルの「場所の学習」タブ

選択肢イベントと選択肢モデルの場合、「場所の学習」タブには次に示す共通オプションがあります。

- (学習)「セッションのクローズ」または「統合点」
デフォルトでは、すべてのモデル学習操作は、セッションの終了時に行われます。あるいは、モデル学習操作のトリガー処理が必要な特定統合ポイント(インフォーマントまたはアドバイザ)も選択できます。

選択肢イベント・モデルの「一時データ記憶域」タブ

選択肢イベント・モデルの場合、あるセッションでベース・イベントが発生し、対応する肯定的イベントがそれより後のセッションで発生する場合に遅延学習を有効にするためのフィールドが「一時データ記憶域」タブに用意されています。

「一時データ記憶域」タブには次に示す共通オプションがあります。

- 一時データ記憶域の使用
一般的なデータ・パターンとして、選択肢に関連するイベントがすべて、Oracle RTDセッションの存続期間中に発生するわけではありません。予測に使用された元の入力値が、肯定的結果が遅れて発生した場合のモデルの更新にも使用されるようにするには、「一時データ記憶域の使用」オプションを選択します。

- 保存日数: 一時データをサーバーに格納しておく日数を指定します。

- キー: 一時データ記憶域に格納されているデータは、「一時データ記憶域」タブで定義されているセッション・キーのいずれか1つがあれば取得できます。

「一時データ記憶域の使用」を選択すると、あるセッションで発生したベース・イベントの選択肢および選択肢属性が(「保存日数」で指定した期間だけ)保存されます。それぞれの選択肢および選択肢属性は、「キー」で指定した各セッション・キーIDによって識別されます。

以降のセッション(先行セッションで保存されたいずれかのキーと同じセッション・キー値を持つセッション)で、肯定的イベントが発生しましたが、対応するベース・イベントがそのセッション内にないとします。すると、Oracle RTDは先行セッションで保存したデータを検索し、現セッションのセッション・キー値と先行セッションのセッション・キー値を照合して、先行セッション内の対応するベース・イベントを探します。

先行セッションのベース・イベントの選択肢および選択肢属性と、現セッションの肯定的イベント・データが、次の学習時(セッション・クローズまたは指定の統合点)に学習モデルへ送られます。

13.14.4 モデルのAPI

次のコードはそれぞれ、オブジェクトのラベルとIDを返します。

public String getSDOLabel();
public String getSDOId();

この項には次のトピックが含まれます:

- 第13.14.4.1項「モデルの問合せ」

- 第13.14.4.2項「選択肢をモデルとともに記録」

- 第13.14.4.3項「文字列名によるモデル・オブジェクトの取得」

- 第13.14.4.4項「選択肢イベント・モデルの選択肢イベントの記録」

- 第13.14.4.5項「選択肢モデルの選択肢の記録」

- 第13.14.4.6項「モデル選択肢の確率の取得」

13.14.4.1 モデルの問合せ

モデルは、次のサンプル・コードに示すgetChoiceEventLikelihoodメソッドのいずれかで問合せを実行できます。この問合せは、ある選択肢がモデルによって選択される確率と任意の選択肢が特定のイベントを持つ確率を返します。

public static double getChoiceEventLikelihoods(GENOffersChoice choice, String eventName);
public static double getChoiceEventLikelihoods(GENOffers choiceGroup, String eventName);

13.14.4.2 選択肢をモデルとともに記録

選択肢イベント・モデルの場合、選択肢のメソッド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");

13.14.4.3 文字列名によるモデル・オブジェクトの取得

次に示す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の例」を参照してください。

13.14.4.4 選択肢イベント・モデルの選択肢イベントの記録

次に示す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);
}
}

13.14.4.5 選択肢モデルの選択肢の記録

次に示す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;
}
}

13.14.4.6 モデル選択肢の確率の取得

次に示す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);

13.15 統合点について

Oracle RTDには、インフォーマントとアドバイザの2種類の統合点があります。これらは、外部システムとOracle RTDの間の統合点を表します。

外部システムと順序番号も統合点ごとに定義されます。これらは、デシジョン・センターで表示されるプロセス・マップの生成に使用します。システムによって、スイムレーンと位置の順序(左から右)が決定されます。この順序は、整数のみでなくどんな数値でも可能であり、既存の統合点を変更しないで新しい統合点を導入できます。

この項には次のトピックが含まれます:

- 第13.15.1項「インフォーマントについて」

- 第13.15.2項「インポートされたJavaクラスの追加とデシジョン・センターの表示の変更」

- 第13.15.3項「インフォーマントのAPI」

- 第13.15.4項「インフォーマントのロジック」

- 第13.15.5項「アドバイザについて」

- 第13.15.6項「アドバイザの意思決定プロセスについて」

- 第13.15.7項「インポートされたJavaクラスの追加とデシジョン・センターの表示の変更」

- 第13.15.8項「セッション・キーの追加」

- 第13.15.9項「外部システムおよび順序の特定」

- 第13.15.10項「リクエスト・データの追加」

- 第13.15.11項「レスポンス・データの追加」

- 第13.15.12項「アドバイザのロジック」

- 第13.15.13項「アドバイザからのリクエスト・データへのアクセス」

13.15.1 インフォーマントについて

インフォーマントは、外部システムとOracle RTDとの間の非同期統合点を表します。

インフォーマントは通常、次に示すように、コンテキスト情報をOracle RTDに渡して意思決定プロセスをサポートするためにトリガーされます。

- インフォーマントは、クローズ・ループ情報をOracle RTDに渡して、その予測モデルを更新します。

- インフォーマントは、Oracle RTDにセッション識別子を渡して、外部データ・ソースから関連情報をフェッチします。

インフォーマントをインライン・サービスに追加する手順は次のとおりです。

1. 外部システムを作成して、どのシステムが統合点にアクセスするかを特定します。

2. 分析のターゲットを表す選択肢グループを作成します。たとえば、サービス・センターへの通話理由を表す選択肢グループなどです。

3. セッション・キー情報を受信し、セッションに基づいてデータを収集および処理するインフォーマントを作成します。

4. データのリポジトリであり、データを分析する分析モデルを作成します。

インフォーマントには、説明および次に示すリクエストの特徴があります。

- セッション・キー: セッションを一意に特定するために使用される1つ以上のセッション・キー。メッセージ内のどのセッション・キーでも、セッションを十分に特定できるため、このメッセージに関連する情報をすでに含むセッションが存在する場合、メッセージはそのセッションにディスパッチされます。

- 外部システム: インフォーマントにリクエストを送信する外部システムを特定します。インフォーマントと外部システムを関連付けると、そのインフォーマントを、デシジョン・センターのプロセス・マップに、他のインフォーマントおよびアドバイザとともに表示できます。

- 順序: この番号は、デシジョン・センターのプロセス・マップに表示される一連の統合点における、このインフォーマントの位置を特定します。他の統合点より順番が小さい統合点は、他の統合点より前に表示されます。小数も使用できます。たとえば、2.1は2.2.の前に表示されます。

- セッションの強制クローズ: これを選択すると、このインフォーマントの非同期ロジックがすべて実行された後に、このインフォーマントのセッションが、インライン・サービスによって自動的に停止されます。インフォーマントの「ロジック」タブのサブタブ内のどこかにJava文session().close();を配置しても、同じ効果が得られます。

この項には次のトピックが含まれます:

- 第13.15.1.1項「セッション・キーの追加」

- 第13.15.1.2項「外部システムおよび順序の特定」

- 第13.15.1.3項「リクエスト・データの追加」

13.15.1.1 セッション・キーの追加

「リクエスト」タブで「選択」をクリックして、統合点のセッション・キーを選択します。これは、運用システムから統合点に提供される値の1つです。

13.15.1.2 外部システムおよび順序の特定

「リクエスト」タブでドロップダウン・リストを使用して、統合点にアクセスする外部システムを選択します。このメニューは、外部システム要素を使用して外部システム識別子を作成することによって移入されます。

統合点にアクセスする順序は、「順序」に表されます。この番号と「外部システム」によって、デシジョン・センターでのエンドツーエンド・プロセスの表示が決まります。

13.15.1.3 リクエスト・データの追加

「リクエスト」タブで「追加」をクリックして、リクエスト・データを追加します。Assignmentは、運用システムから統合点に提供される値です。Assignmentの特徴は次のとおりです。

- 受信パラメータ: インフォーマントに送信されるリクエスト内のフィールドの名前。このフィールドの値が、リクエストからセッション属性にコピーされます。この名前は、セッション属性と同じである必要はありませんが、普通は同じ名前が付けられます。
セッション・キーが作成されると、入力されたパラメータがセッション・キーの属性に割り当てられます。

- タイプ: これはセッション属性のデータ型で、入力された引数はそこにコピーされます。有効な型は、integer、string、dateまたはdoubleです。

注意:

リクエスト・フィールドの型とセッション・キーの属性が一致しない場合、変換メソッドを使用する必要があります。

- 配列: 型がコレクションの場合にマークされます。

- セッション属性: リクエストの入力パラメータのマップ先となるセッションの属性。

13.15.2 インポートされたJavaクラスの追加とデシジョン・センターの表示の変更

インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。デシジョン・センターの表示ラベルを変更して、その要素をデシジョン・センターNavigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。

13.15.3 インフォーマントのAPI

次のコードはそれぞれ、オブジェクトのラベルとIDを返します。

public String getSDOLabel();
public String getSDOId();

13.15.4 インフォーマントのロジック

インフォーマントのロジックは、「ロジック」タブと「非同期ロジック」タブで操作します。インフォーマントのリクエスト・データは、この2つのタブのどちらかを使用するとアクセスできます。

この項には次のトピックが含まれます:

- 第13.15.4.1項「ロジック」

- 第13.15.4.2項「非同期ロジック」

- 第13.15.4.3項「インフォーマントからのリクエスト・データへのアクセス」

13.15.4.1 ロジック

このスクリプトは、Request Dataで宣言されたいずれかのリクエスト・データの実行後に実行されます。インフォーマントの主要な目的が、運用システムのリクエスト・フィールドからセッション・キーおよびリクエスト・データにデータを転送することである場合、この処理は「データのリクエスト」タブでの宣言に従って自動的に行われるため、ロジックが不要な場合があります。

インフォーマントのロジックは通常、ログ・ファイルでメッセージ受信をトレースするため、またはインフォーマントのメッセージによってキーが提供されるエンティティを事前移入するために使用します。ロジックを使用すると、レスポンス時間がより重要なアドバイザで、後にこの処理を行う必要がなくなります。ロジックは、リクエスト・データの直後に実行されます。

インフォーマントのロジックは、選択肢を選択肢モデルとともに記録する場合にも使用できます。コールするメソッドについては、選択肢モデルのAPIを参照してください。

13.15.4.2 非同期ロジック

このスクリプトは、前項で説明した「ロジック」タブで定義したスクリプトの後に実行されます。ほかに必要な処理があったら、この領域に配置できます。非同期ロジックの実行順序は保証されません。

13.15.4.3 インフォーマントからのリクエスト・データへのアクセス

インフォーマントからリクエスト・データには、様々な方法でアクセスできます。入力されたパラメータがセッション属性にマップされる場合は、そのパラメータにgetメソッドがあります。

request.get$()

この$は、先頭が大文字のパラメータ名です。

この属性がマップされない場合は、パラメータのフィールド名を使用して、同じ結果をもたらすメソッドがあります。

String request.getStringValue(fieldName)
SDStringArray request.getStringArrayValue(fieldName)
boolean request.isArgPresent(fieldName)

13.15.5 アドバイザについて

アドバイザは、外部システムとOracle RTDとの間の同期統合点を表します。アドバイザは通常、Oracle RTDデシジョンを起動するためにトリガーされます。

アドバイザごとに、最適化されたデシジョンとControl Groupデシジョンの2つのデシジョンを使用できます。したがって、ユーザーは2つのオプションのパフォーマンスをそれぞれ比較できます。

一般的に、2つのデシジョンは次のように設定されます。

- 最適化されたデシジョンでは、Oracle RTDのデシジョン・フレームワークの拡張機能を利用したデシジョン・ロジックが実装されます。

- Control Groupデシジョンは、最適化されたデシジョンの比較基準となるように、既存のビジネス・プロセスにできるかぎり近いものにします。

アドバイザにデフォルトの選択肢を定義できます。これらの選択肢は、サーバーでの計算を時間内に完了できない場合や、クライアントとサーバーの通信が切断された場合に使用されます。

13.15.6 アドバイザの意思決定プロセスについて

アドバイザには、説明および次に示すリクエストの特徴があります。

- セッション・キー: セッションを一意に特定するために使用される1つ以上のセッション・キー。メッセージ内のどのセッション・キーでも、セッションを十分に特定できるため、このメッセージに関連する情報をすでに含むセッションが存在する場合、メッセージはそのセッションにディスパッチされます。
アドバイザがコールされると、まずセッション・キーの作成が実行されます。

- 外部システム: アドバイザのリクエストをトリガーする外部システムを特定します。アドバイザと外部システムを関連付けると、そのアドバイザを、デシジョン・センターのプロセス・マップに、他のインフォーマントおよびアドバイザとともに表示できます。

- 順序: この番号は、デシジョン・センターのプロセス・マップに表示される一連の統合点における、このアドバイザの位置を特定します。他の統合点より順番が小さい統合点は、他の統合点より前に表示されます。小数も使用できます。たとえば、2.1は2.2.の前に表示されます。

- セッションの強制クローズ: このオプションを選択すると、このアドバイザの非同期ロジックがすべて実行された後に、このアドバイザのセッションが、インライン・サービスによって自動的に停止されます。アドバイザの「ロジック」タブのサブタブ内のどこかにJava文session().close();を配置しても、同じ効果が得られます。

13.15.7 インポートされたJavaクラスの追加とデシジョン・センターの表示の変更

インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。デシジョン・センターの表示ラベルを変更して、その要素をデシジョン・センターNavigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。

13.15.8 セッション・キーの追加

「リクエスト」タブで「選択」をクリックして、統合点のセッション・キーを選択します。これは、運用システムから統合点に提供される値の1つです。

13.15.9 外部システムおよび順序の特定

「リクエスト」タブでドロップダウン・リストを使用して、統合点にアクセスする外部システムを選択します。このリストは、外部システム要素を使用して外部システム識別子を作成することによって移入されます。

統合点にアクセスする順序は、「順序」に表されます。この番号と「外部システム」によって、デシジョン・センターでのエンドツーエンド・プロセスの表示が決まります。

13.15.10 リクエスト・データの追加

「リクエスト」タブで「追加」をクリックして、リクエスト・データを追加します。リクエスト・データは、運用システムから統合点に提供される値です。リクエスト・データの特徴は次のとおりです。

- 受信パラメータ: アドバイザに送信されるリクエスト内のフィールドの名前。このフィールドの値が、リクエストからセッション属性にコピーされます。この名前は、セッション属性と同じである必要はありませんが、普通は同じ名前が付けられます。
セッション・キーが作成されると、入力されたパラメータがセッション属性に割り当てられます。

- タイプ: これはセッション属性のデータ型で、入力された引数はそこにコピーされます。有効な型は、integer、string、dateまたはdoubleです。

注意:

リクエスト・フィールドの型とセッション属性が一致しない場合、変換メソッドを使用する必要があります。

- 配列: このオプションは、型がコレクションの場合に選択します。

- セッション属性: リクエストの入力パラメータのマップ先となるセッションの属性。

13.15.11 レスポンス・データの追加

「レスポンス」タブで「追加」をクリックして、レスポンス・データを追加します。レスポンス・データは、リクエストを呼び出した後に、運用システムから統合点に返信される値です。レスポンス・データの特徴は次のとおりです。

- レスポンス: レスポンスには、選択した選択肢オブジェクトの配列が含まれ、各選択肢には、名前付きの属性値のコレクションが含まれています。選択肢の選択プロセスは、アドバイザで参照されている2つのデシジョン・オブジェクトのいずれか一方によって制御されます。1つのデシジョンが、コール元のアプリケーションに与えられます。

- 使用するデシジョン: Control Groupのセッションではなく、通常のセッションに使用するデシジョン・オブジェクトの名前。このデシジョンが、アドバイザからコール元システムへのレスポンスになります。

- 使用する制御グループのデシジョン: 制御グループのデシジョンは、ベースラインを提供することによって他のデシジョンの効果を評価する方法として、少数のセッションのみに使用されます。制御グループのデシジョンを使用するセッションの割合は、インライン・サービスのアプリケーション要素で指定します。制御グループのデシジョンは、いつもどおりのロジックを使用して選択肢を選択するように設計する必要があります。つまり、インライン・サービスの導入前に企業で使用していたルールです。デシジョン・センター・コンソールにあるレポートで、アドバイザの通常のデシジョン・オブジェクトのビジネス効果を制御グループのデシジョンと比較できます。

- パラメータ: デシジョンによって定義される入力パラメータ。「名前」列と「タイプ」列は説明のみで、デシジョン・オブジェクトからここに表示されます。

- 返される選択肢のデフォルト数: デシジョンによって返されるデフォルトの選択肢数。これは、デシジョンで定義されている選択肢の数です。

- デフォルトのオーバーライド: アドバイザでは、参照先のデシジョンで指定されている数値を上書きまたはそのまま使用できます。ここでは、アドバイザのレスポンスに含めることのできる選択肢の最大数を指定します。

- デフォルトの選択肢: コール元のクライアント・アプリケーションがアドバイザを起動しようとしたとき、サーバーの保証されているレスポンス時間内にアドバイザがレスポンスを提供できない場合に、コール元のクライアント・アプリケーションに返される選択肢のリスト。
デフォルトの選択肢は、アドバイザごとに指定する必要はありません。インライン・サービスでもデフォルトの選択肢を宣言することがありますが、これは独自の宣言を行わないアドバイザで使用されます。また、デフォルトの選択肢構成は、クライアント・アプリケーションに伝播され、Smart Clientコンポーネントによってローカルのファイル・システムに格納されます。したがって、その後は、サーバーに接続できないクライアント・アプリケーションで使用できるようになります。

13.15.12 アドバイザのロジック

アドバイザのロジックは、「ロジック」タブ「非同期ロジック」タブで操作します。

この項には次のトピックが含まれます:

- 第13.15.12.1項「ロジック」

- 第13.15.12.2項「非同期ロジック」

13.15.12.1 ロジック

このスクリプトは、「データのリクエスト」タブで宣言されたいずれかのリクエスト・データが実行されてから、クライアントにレスポンスが返信されるまでの間に実行されます。

アドバイザのロジックは、一般的には不要です。これは、リクエストとともに着信するデータを事前処理するため、またはデバッグ目的に使用します。

13.15.12.2 非同期ロジック

このスクリプトは、クライアントにレスポンスを返信するサーバー側メカニズムにレスポンスが渡された後に実行されます。クライアントで使用されているエンドポイントのタイプによっては、このスクリプトが終了する前にクライアントが結果の処理を開始し、並列性を強化することによって効果的なレスポンス時間を改善できます。

13.15.13 アドバイザからのリクエスト・データへのアクセス

アドバイザからリクエスト・データには、様々な方法でアクセスできます。入力されたパラメータがセッション属性にマップされる場合は、そのパラメータにgetメソッドがあります。

request.get$()

この$は、先頭が大文字のパラメータ名です。

この属性がマップされない場合は、同じ結果をもたらすメソッドがいくつかあります。

String request.getStringValue(fieldName)
SDStringArray request.getStringArrayValue(fieldName)
boolean request.isArgPresent(fieldName)

13.15.14 セッション・キーのない統合点の一時セッション

統合点は、モデルの学習に寄与することなくサーバーでロジックを実行するリモート・プロシージャ・コールとして設計できます。設計の意図として特定のセッションにアクセスしない場合は、セッション・キーなしで統合点を定義できます。

統合点で使用できるAPIにはSession()メソッドが用意されています。このメソッドはセッション・オブジェクトを返します。セッション・キーが定義されていない統合点でSession()メソッドを呼び出すと、Oracle RTDでは一時セッションが作成されます。このセッションは、統合点によって生成および使用されるデータのコンテナとして使用できますが、一時的なセッションなので、他の統合点コールでは使用できません。

13.16 外部システムについて

外部システムは、デシジョン・スタジオ内でのみ識別されます。外部システムは、インライン・サービスに統合する、エンタープライズ内の運用システムを表します。外部システムは、API経由ではアクセスできません。外部システムは、統合点で、どの外部システムがその統合点にアクセスするかを識別するために使用します。外部システムは、デシジョン・センターの統合マップでの表示に使用されます。

外部システムには、説明および表示ラベルがあります。表示ラベルを変更しても、オブジェクトIDには影響がありません。

13.17 カテゴリ・オブジェクトについて

カテゴリは、選択肢の整理に使用します。同じカテゴリにある選択肢はすべて、デシジョン・センターに一緒に表示されます。カテゴリには、クラスは生成されません。カテゴリは、デシジョン・センターで、選択肢のグループ分けおよび整理のみに使用します。

カテゴリの特徴は次のとおりです。

- 名前:デシジョン・スタジオに入力されるカテゴリの名前。

- 説明:デシジョン・スタジオに入力されるカテゴリの説明。

- ラベルの表示: 表示ラベルを変更できます。オブジェクトIDには影響がありません。

13.18 関数について

関数は、計算など、再利用可能にする処理に使用できます。関数は、デシジョン・スタジオを使用して定義します。関数定義の特徴は次のとおりです。

- 説明: 関数の説明。

- 戻り値: 関数が値を返すかどうかを指定します。

- データ型: 戻り値の型。

- 配列: このオプションは、戻り型が配列の場合に選択します。

- コール・テンプレート: 関数のコール方法の定義。{0}や{1}などを引数として使用し、関数を説明する表現を設定して、コールのテンプレートを定義します。この表現は関数の使用時に表示されるため、わかりやすい表現を使用することが重要です。たとえば、乗算のコール・テンプレートは、「{1}を乗算した{0}」です。

- パラメータ: 関数のロジックで使用される名前付きパラメータ。この数値は、コール・テンプレートにある引数の数と一致する必要があります。たとえば、multiplyには、a, type Double; b, type Doubleのようなパラメータがあります。
ルールで関数パラメータを使用する場合、パラメータの型制約を選択できます。これは必須要件ではありませんが、ルールの定式化に役立ちます。型制約の作成と使用の詳細は、第13.19項「型制約について」を参照してください。

- ロジック: 関数のJavaコード。multiplyのコードは次のとおりです。

return a * b;

この項には次のトピックが含まれます:

- 第13.18.1項「選択肢イベント履歴表とともに使用する関数」

- 第13.18.2項「メンテナンス操作について」

- 第13.18.3項「インポートされたJavaクラスの追加とデシジョン・センターの表示の変更」

13.18.1 選択肢イベント履歴表とともに使用する関数

インライン・サービスを構成する際、Oracle RTDの選択肢イベント履歴表に格納されているデータにアクセスするための事前定義済関数を使用できます。これらの関数は、選択肢適格性ルールの作成や編集でアクセスできますし、カスタムJavaロジックからもコールできます。

選択肢適格性ルール文でこれらの関数にアクセスするには、「関数コール」を選択して「関数」フォルダを開きます。使用可能な関数のリストに、次の関数が表示されます。

関数名

パラメータ

説明

最後のイベントからの日数

イベント名

特定の選択肢や指定されたイベント名に対して、最後にイベントが記録されてからの経過日数を返します。

チャネルでの最後のイベントからの日数

イベント名

チャネル

特定の選択肢、指定されたイベント名および指定されたチャネル名に対して、最後にイベントが記録されてからの経過日数を返します。

最近のイベント数

イベント名

日数

特定の選択肢、指定されたイベント名および指定された日数に対して、イベント記録の合計回数を返します。

チャネルでの最近のイベント数

イベント名

チャネル

日数

特定の選択肢、指定されたイベント名、指定されたチャネルおよび指定された日数に対して、イベント記録の合計回数を返します。

13.18.2 メンテナンス操作について

メンテナンス操作はインライン・サービス固有のユーザー定義関数であり、管理者はEnterprise Managerで次のような特定のインライン・サービス関連作業を実行できます。

- 外部ルール・キャッシュのクリア

- クラスタ内でのメッセージのブロードキャスト

- ブロック操作の実行

インライン・サービス用に作成されたメンテナンス操作は、Oracle RTDによってMBean操作として公開されます。

メンテナンス操作は、クラスタの個々のメンバーでもクラスタ全体でも起動できます。メンテナンス操作は非ブロック型です。

注意:

メンテナンス操作は、クラスタの個々のメンバーでブロック操作として直接起動できます。リクエストをブロードキャストしてクラスタ全体でメンテナンス操作を起動する場合、メッセージ配信中のみブロックされます。

各メンテナンス操作は、ロード可能なインライン・サービスごとに、MBeanツリーに2回表示されます。

1. ローカル・サーバーでのみメンテナンス操作を起動できるようにするため

2. クラスタのすべてのノードでメンテナンス操作を起動できるようにするため

特定のインライン・サービスでバージョンが異なる場合、メンテナンス操作が異なる場合があります。たとえば、あるインライン・サービスの複数のバージョンをデプロイできますが、それぞれのデプロイ状態が異なる場合があります。このときメンテナンス操作を使用できるのは、ロード可能な状態のインライン・サービスのみです。

メンテナンス操作に関して、次の内容をデザインタイムに考慮する必要があります。

- メンテナンス操作は、プリミティブ型の引数(String、int、double、date、またはboolean)を0個以上受け取り、String、int、double、date、booleanまたはvoidを返すことができます。
戻り値(および例外)はログに記録されます。

- メンテナンス操作は、グローバルなインライン・サービスのコンテキスト内で動作します。セッション属性はnullです。セッションにアクセスすると、IllegalStateExceptionがスローされます。

外部ルール・キャッシュのメンテナンス操作

Oracle RTDには、外部ルール・キャッシュのためのメンテナンス操作が用意されています。詳細は、第17.2.6.2項「外部ルール・キャッシュ」を参照してください。

13.18.3 インポートされたJavaクラスの追加とデシジョン・センターの表示の変更

インポートされたJavaクラスをインライン・サービスに追加するには、説明の横にある「詳細」をクリックします。デシジョン・センターの表示ラベルを変更して、その要素をデシジョン・センターNavigatorに表示するかどうかを選択することもできます。表示ラベルを変更しても、オブジェクトIDには影響がありません。

関数は、コール・テンプレートを使用して、他の要素からコールされます。たとえば、前項で説明したmultiply関数を使用する場合、関数を「値の編集」ダイアログから選択します。コール・テンプレート{0} multiplied by {1}を使用すると、引数の位置と数がエディタに与えられます。

13.19 型制約について

型がInteger、Double、DateまたはStringであるセッションおよびエンティティの属性、選択肢および選択肢グループの属性、および関数およびアプリケーションのパラメータに関連付けることができる制約が、型制約によって定義されます。

型制約は、通常、ルール・エディタでユーザー入力を簡素化する目的で使用します。型が制約された要素を使用するルールをルール・エディタで定義するとき、関連付けられた型制約で定義されている制約に応じた値リストを表示し、そこから値を選択できます。型制約は、インライン・サービスの設計者を支援する機能です。実行時には評価されません。

型制約には、次の3種類があります。

- 値リスト

- エンティティのリスト

- 他の制約

「値リスト」型制約は、1つ以上の値を持つリストで表示されます。

「エンティティのリスト」型制約は、関数から返されるエンティティ属性値で構成されます。「エンティティのリスト」型制約を使用して、データベースの表とビューから動的な値リストを生成できます。

「他の制約」型制約は、値(データ型がDate、DoubleまたはInteger)の範囲またはJavaScript正規表現パターンで構成されます。

JavaScript正規表現パターンは一般的に、郵便番号や電話番号のように、データの各文字が、コード内の位置に応じて現実の世界における規則に従っているデータに使用されます。たとえば、米国の電話番号(例: (650) 506 7000)や英国の郵便番号(例: KT2 6JX)があります。

13.19.1 型制約の管理

型制約は、サービス・メタデータ・オブジェクトとして個々に作成と編集を行います。型制約は、次のインライン・サービス・オブジェクトに、対応オブジェクト・エディタで関連付けることができます。

- セッション属性およびエンティティ属性

- 選択肢グループ属性

- 選択肢属性

- 関数パラメータ

- アプリケーション・パラメータ

ルール・エディタでオペランドとして型制約オブジェクトをルールに追加する場合、ルールの作成や編集で次の支援機能を使用できます。

- 「値リスト」または「エンティティのリスト」の型制約のオブジェクトの場合、型制約に従ったドロップダウン・リストでオブジェクトの値を表示したり選択できます。

- 「他の制約」型制約のオブジェクトの場合、マウス(カーソル)をオブジェクトの上に移動することで、型制約の範囲の制約またはJavaScript正規表現を参照できます。

この項の以降の内容は次のとおりです。

- 第13.19.1.1項「「値リスト」型制約の作成および編集」

- 第13.19.1.2項「「エンティティのリスト」型制約の作成および編集」

- 第13.19.1.3項「「他の制約」の作成および編集」

- 第13.19.1.4項「インライン・サービス・オブジェクトと型制約の関連付け」

- 第13.19.1.5項「ルールでの型制約の使用」

- 第13.19.1.6項「型制約の例」

13.19.1.1 「値リスト」型制約の作成および編集

「値リスト」型制約の場合、データ型を選択し、個々の要素に1つ以上の値を指定する必要があります。選択する値の数は、500個未満にすることをお薦めします。

「値リスト」型制約を定義できるのは、String、Integer、DoubleまたはDateのデータです。

13.19.1.2 「エンティティのリスト」型制約の作成および編集

「エンティティのリスト」型制約を定義するには、まず特定の前提条件を満たす必要があります。

- 特定のエンティティ・タイプのデータを返す関数が定義されている必要があります(関数が返す値の数は500個未満にすることをお薦めします)。

- 参照されるエンティティ・タイプには、列が2列以上存在する必要があります。これらは、型制約のラベルおよび値として使用されます。
ラベルの列と値の列は、ルール・エディタでルール文を編集したり、型制約を関連付けた属性またはパラメータを選択する際に使用します。

ラベルの列には、ドロップダウン・リストのデータが格納されます。ドロップダウン・リストから選択すると、値の列にある対応データがルールに追加されます。

たとえば、米国の州コードに対する型制約を使用すると、アラバマやカリフォルニアなどの米国の州名のドロップダウン・リストからルール作成者は州名を選択できます。ここでは州名の列がラベルの列として使用されます。

ルール作成者がドロップダウン・リストから州名を選択すると、Oracle RTDによって、ALやCAなどの対応する州コードがルールに追加されます。ここでは州コードの列が値の列として使用されます。

「エンティティのリスト」型制約は、次の特性によって定義されます。

- エンティティ: 型制約の定義対象のエンティティ。

- 関数: 制約されたデータを返す関数。この関数の戻り値のデータ型として、型制約エンティティを指定する必要があります。

- ラベル: 型制約エンティティの属性であり、この型制約を使用してオブジェクトを参照するルールを作成する際、ドロップダウン・リストの値はこの属性に保持されます。

- 値: 型制約エンティティの属性であり、ユーザーがルール・エディタでドロップダウン・リストからラベル値を選択した際にルールに追加される値がこの属性に保持されます。

「エンティティのリスト」型制約を定義できるのは、String、Integer、DoubleまたはDateのデータです。

注意:

「エンティティのリスト」型制約を作成したり編集した後で、インライン・サービスをデプロイする必要があります。これによって、型が制約された属性またはパラメータを使用するルールを作成する際に、正しい値がドロップダウン・リストに表示できるようになります。

13.19.1.3 「他の制約」の作成および編集

「他の制約」により、範囲の制約または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つの条件は論理積演算子で結合されます。

13.19.1.4 インライン・サービス・オブジェクトと型制約の関連付け

作成した型制約は、次に示す1つ以上のインライン・サービス・オブジェクトに関連付けることができます(対応するオブジェクト・エディタを使用)。

- セッション属性およびエンティティ属性

- 選択肢グループ属性

- 選択肢属性

- 関数パラメータ

- アプリケーション・パラメータ

対応するオブジェクト・エディタの使用方法の詳細は、このドキュメントの対応するオブジェクトに関する項を参照してください。

13.19.1.5 ルールでの型制約の使用

型制約をオブジェクトに関連付けると、ビジネス・ユーザーがルール・エディタでそのオブジェクトのルールを定式化する際に役に立ちます。

ルールを作成または編集する際、次のオプションを選択できます。

- 「値リスト」または「エンティティのリスト」のどちらかの型制約が関連付けられたオブジェクトをオペランドとして選択すると、もう一方のルール・オペランドではドロップダウン・リストから値を選択できます。このドロップダウン・リストから値を選択できますが、値の選択は必須ではありません。

- 「他の制約」型制約のオブジェクトをオペランドとして選択してから、マウスをその上に移動すると、型制約の範囲の制約またはJavaScript正規表現がバルーン・ヘルプに表示されます。

注意:

型制約は、ルールの作成や編集を支援する機能であり、厳格な要件ではありません。たとえば、型制約のある要素のルールに、ドロップダウン・リストに表示されていない値を入力できます。実行時には、ルールは評価され、それに応じて動作しますが、型制約は評価されません。

一般的に次が成立します。

- 「値リスト」型制約によって定数リストが提示されます。

- 「エンティティのリスト」型制約によって動的な実行時リストが提示されます。

- 「他の制約」により、リスト・エントリに対するチェック以外の型検証を設計できます。

型制約に対する違反は、次に示すように、エラーではなく警告として処理されます。

- 違反しているオペランドは、赤色の波型下線で示されます。

- 違反しているオペランドの上にマウスを移動すると、違反の詳細を参照できます。

警告があっても、ルールをコンパイルしてデプロイすることは可能です。

13.19.1.6 型制約の例

この項では、様々な型制約を作成して使用する方法の例を示します。

1. 「値リスト」型制約
Product_Sizeという名前で、Large、Medium、Smallを値とする型制約を作成します。

Product_Size型制約をsession/Product属性に関連付けます。

次に示すように、ルール・エディタでフィルタリング・ルールのLarge_Productを作成します。

- session/Product = "Large"

2. 「エンティティのリスト」型制約
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であり、その値がルールに追加されます。

3. 「エンティティのリスト」型制約による動的な値の表示
この例では、型が制約されたオブジェクトをルールで使用する際に、データベース表の値を表示したり選択できます。

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値がルールに追加されます。

4. 範囲を使用するその他の型制約
Date型制約をFrom_Now_Onの名前で作成し、下限値として現在日を指定します。

From_Now_On型制約をsession/Acct/Pay_By属性に関連付けます。

次に示すように、ルール・エディタでフィルタリング・ルールのPayUpを作成します。

- session/Acct/Pay_By = <current_date> + 45 days

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

13.20 統計コレクタについて

統計コレクタは、インライン・サービスの非定型統計の収集とライフサイクルを管理します。デフォルトでは、インライン・サービスごとに、選択肢イベントの統計コレクタが1つずつ作成されます。選択肢イベントの統計コレクタは、インライン・サービスで定義されているイベントの統計を自動的に収集します。統計コレクタのプロパティは次のとおりです。

- 説明: 統計コレクタの説明。

- 統計の収集場所: 統計は、選択肢や選択肢グループなどのオブジェクトごとに個別に収集することも、同じタイプのすべてのオブジェクトに集計して収集することもできます。

- 集計: 個々のイベントを記録するか、または集計されたデータを記録します。個々のイベントを記録する場合は、トランザクションの多いシステムにパフォーマンス上の問題が発生する場合があるため、注意が必要です。

- 集計間隔: 統計コレクタによりデータを記録する前の集計に要する時間(単位は秒)。

- 有効期限: 「永久に保存」または「古い統計のパージ」を選択します。「永久に保存」を選択する場合は、データのサイズが問題になる場合があるため、注意が必要です。

- データベースに保持: データを消去するまでの時間(日)。

パラメータはすべて、デシジョン・スタジオ・エディタを使用して構成できます。選択肢イベントの統計は、レポートとしてデシジョン・センターに表示されます。

13.20.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は、オブジェクトの内部名です。

14 インライン・サービスのデプロイ、テストおよびデバッグ

この章では、インライン・サービスのデプロイ、テストおよびデバッグを行う方法について説明します。

この章には次のトピックが含まれます:

- 第14.1項「インライン・サービスのデプロイ」

- 第14.2項「Real-Time Decision Serverへの接続」

- 第14.3項「インライン・サービスの再デプロイ」

- 第14.4項「インライン・サービスのテストおよびデバッグ」

14.1 インライン・サービスのデプロイ

構成の済んだインライン・サービスは、ローカルにデプロイするか、テストのためにテスト環境にデプロイします。

注意:

WebSphere上で稼働するOracle RTDシステムにインライン・サービスをデプロイする場合は、インライン・サービスとWebSphereの管理レベルの両方で親クラスのロードを無効化しておく必要があります。

インライン・サービスでは、アプリケーション・パラメータ「親が最初のクラスロード」を選択しないでください。詳細は、第13.4.1.1項「デバッグ・オプションの使用」を参照してください。

WebSphereの管理レベルで必要な設定については、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドの親クラスのロードの無効化に関する項を参照してください。

インライン・サービスは、開発、QAおよび本番の3つの状態にデプロイできます。

テスト段階ではQA状態にデプロイしてから、テスト後に本番状態にデプロイできます。本番状態にデプロイする際は、「インライン・サービスのロックの開放」を選択します。インライン・サービスをビジネス・ユーザー向けにデプロイすると、ビジネス・ユーザーもインライン・サービスを更新および再デプロイできるようになります。

注意:

デシジョン・スタジオを使用する方法およびコマンドラインのデプロイ・ツールを使用する方法によりインライン・サービスをデプロイできます。

この項では、デシジョン・スタジオによるデプロイについて説明します。コマンドラインによるデプロイの詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「インライン・サービスのコマンドライン・デプロイ」を参照してください。

インライン・サービスをデプロイするには、「プロジェクト」→「デプロイ」メニュー項目を使用するか、タスク・バーの「デプロイ」アイコンをクリックします。

「デプロイ」ダイアログ・ボックスが表示されます。「デプロイ」ダイアログ・ボックスには、図14-1に示すオプションがあります。

図14-1 「デプロイ」ダイアログ・ボックス

「図14-1 「デプロイ」ダイアログ・ボックス」の説明

注意:

インライン・サービスのデプロイには、サーバー・クラスタに対する適切な権限が必要です。クラスタ権限の詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』を参照してください。

表14-1は、「デプロイ」ダイアログ・ボックスに表示される各オプションについて説明したものです。

表14-1 「デプロイ」ダイアログ・ボックスのオプション

オプション名

説明

プロジェクト

Real-Time Decision Serverにデプロイするプロジェクトを選択します。

インライン・サービス

このプロジェクトに含まれているインライン・サービス。

スタディ名

このインライン・サービスのスタディ名を入力します。各インライン・サービスの学習は、スタディ名に関連付けられています。インライン・サービスを再デプロイして学習を再開するには、新しいスタディ名を付けてデプロイします。開発、QAおよび本番で別々のスタディ名を使用できます。

デプロイメント状態

デフォルトでは、インライン・サービスのデプロイの状態には、開発、QA、本番の3つがあります。他のユーザーにわかるように、「デプロイメント状態」には、インライン・サービスの状態(開発、テストまたは本番)が示されています。

システム管理者が、カスタムのデプロイ状態を作成している場合があります。

サーバー

デプロイ先のサーバーおよびポートを入力するには、このオプションをクリックします。「サーバー」ダイアログ・ボックスで、デプロイ先のサーバー・クラスタに対してデプロイ権限を持つ有効なユーザー名およびパスワードを入力します。クラスタに対する認可は、管理者がJConsoleを使用して付与します。

インライン・サービスのロックの開放

デプロイされたインライン・サービスは自動的にロックされ、再デプロイは、デプロイを行ったユーザーしかできません。開発とテストが完了したインライン・サービスを本番環境にデプロイする際、「インライン・サービスのロックの開放」を選択すると、デシジョン・センターのユーザーがインライン・サービスを変更して再デプロイできるようになります。

アクティブ・セッションの終了

デプロイしているインライン・サービスが本番環境にある場合は、アクティブなセッションが存在している場合があります。アクティブなセッションが存在している状態で新しいバージョンのインライン・サービスをデプロイすると、古いバージョンが維持され、アクティブなセッションにサービスを提供し続けます。テスト中の場合は、アクティブ・セッションの終了を選択してアクティブなセッションを終了します。本番のインライン・サービスでは、このオプションを選択解除したままにして、アクティブなセッションが存在するとき、本番バージョンのインライン・サービスで実行され続けるようにします。新規のセッションは新しいバージョンにルーティングされ、古いバージョンはアクティブなセッションがすべて完了すると終了します。

デプロイ後にアクティブ化しない

このオプションは、インライン・サービスをサーバーにデプロイしてもプロセスを開始しないときに使用します。後日インライン・サービスをアクティブにする場合は、Fusion Middleware Controlを使用します。Fusion Middleware Controlの詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』を参照してください。

注意:

カスタム・ページのあるインライン・サービスが特定のデプロイ状態(開発など)にデプロイされると、その状態のカスタム・ページのリストは、それ以前に任意のデプロイ状態にデプロイされていた同じインライン・サービスのカスタム・ページのリストよりも優先されます。

デプロイ済のインライン・サービスを削除する方法など、インライン・サービスの管理の概要は、 『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のインライン・サービスのデプロイ後の管理に関する項を参照してください。

14.2 Real-Time Decision Serverへの接続

インライン・サービスをデプロイまたはダウンロードする際、またはデータ・ソースをインポートする際には、Real-Time Decision Serverに接続する必要があります。接続には、インストール時に作成したユーザー名およびパスワードを使用するか、管理者にユーザー名およびパスワードを問い合せてください。httpsを使用したセキュアな方法で接続するには、「セキュアな接続」を選択します。

図14-2に「サーバーへの接続」ダイアログ・ボックスを示します。

図14-2 「サーバーへの接続」ダイアログ・ボックス

「図14-2 「サーバーへの接続」ダイアログ・ボックス」の説明

14.3 インライン・サービスの再デプロイ

デプロイされているインライン・サービスを変更する場合は、その変更と、ビジネス・ユーザーにより行われている可能性のある変更の両方が失われないよう、次の手順に従うことが重要です。デプロイされているインライン・サービスを変更する場合、ツールバーの「ダウンロード」アイコンを使用してReal-Time Decision Serverからダウンロードできます。次の方法を使用します。

1. デプロイされている目的のインライン・サービスを編集しているビジネス・ユーザーがいないことを確認します。

2. ダウンロードする場合は必ずインライン・サービスをロックして、編集中にビジネス・ユーザーが変更できないようにします。

3. デシジョン・スタジオで変更作業を行います。

4. インライン・サービスを再デプロイしてロックを解除します。

インライン・サービスがロックされている間、ビジネス・ユーザーはそのデプロイされているインライン・サービスを表示できますが、編集はできません。

注意:

インライン・サービスの機能を強化するにはデシジョン・スタジオを使用する必要がありますが、インライン・サービスを再デプロイする場合はデシジョン・スタジオまたはコマンドライン・デプロイ・ツールのどちらでも使用できます。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「インライン・サービスのコマンドライン・デプロイ」を参照してください。

14.4 インライン・サービスのテストおよびデバッグ

Oracle RTDには、インライン・サービスのテストやデバッグを行うために次の機能が用意されています。

- デシジョン・スタジオの「問題」ビューおよび「テスト」ビュー

- システム・ログ

- ロード・ジェネレータ

この項には次のトピックが含まれます:

- 第14.4.1項「「問題」ビューについて」

- 第14.4.2項「「テスト」ビューの使用」

- 第14.4.3項「システム・ログを使用してインライン・サービスのテストとデバッグを行う方法」

ロード・ジェネレータは、ユーザーをシミュレートしてインライン・サービスのデバッグおよびベンチマークを行うためのツールです。ロード・ジェネレータは、インライン・サービスのテストとパフォーマンスの特徴付けの両方に使用します。

ロード・ジェネレータの詳細は、第15章「ロード・ジェネレータについて」を参照してください。

14.4.1 「問題」ビューについて

「問題」ビューでは、インライン・サービスの構築時にコンパイル・エラーや検証エラーを特定できます。コンパイル・エラーをダブルクリックすると、Javaパースペクティブが表示され、エラーが強調表示されます。

検証エラーをダブルクリックすると、インライン・サービス・パースペクティブが表示され、検証エラーのある要素に対する要素エディタも表示されます。

14.4.2 「テスト」ビューの使用

デシジョン・スタジオには、個々の統合点をテストできる「テスト」ビューがあります。「テスト」ビューでは、統合点をコールする運用システムをシミュレートできます。「テスト」ビューには、インライン・サービス内の統合点がすべて含まれるドロップダウン・リストがあります。統合点をテストするには、セッション・キーおよびリクエスト・データに値を挿入し、「実行」アイコンをクリックして実行します。統合点についての情報は、「結果」、「トレース」、「ログ」の3つのサブタブに表示されます。

「結果」タブには、アドバイザの統合点をコールした結果が示されます。結果を返すのはアドバイザのみです。インフォーマントのテスト、およびアドバイザとインフォーマント両方の統合点のデバッグには、logInfo()を使用します。

logInfo()文は、デバッグ手段として、コード内の様々な箇所で使用できます。この文は、アドバイザ、インフォーマント、デシジョン、関数などを、要素内で使用する際に役立ちます。この文は、要素の論理ペインに挿入し、様々な段階でログ・データに表示する手段として使用できます。

この項には次のトピックが含まれます:

- 第14.4.2.1項「logInfo()の使用」

- 第14.4.2.2項「着信リクエスト・データのテスト」

14.4.2.1 logInfo()の使用

「ログ」タブには、すべてのlogInfo()文が表示されます。

logInfoメソッドは、デシジョン・スタジオのオンライン・ヘルプで説明されているロギングAPIの一部です。com.sigmadynamics.supportClass SDOBaseクラスには、情報、デバッグ、警告、エラーの各レベルでメッセージをログに記録するためのメソッドが含まれています。一般的に、これらのロギング・メソッドは、文字列などの引数をパラメータとして受け入れます。

logInfoの使用例を2つ、次に示します。

logInfo("Installation date = " + DateUtil.toString(session().getCustomer().
getInstallationDate());

logInfo("Customer age = " + session().getCustomer().getAge() );

注意:

すべてのセッション・エンティティ属性の値または指定されたエンティティとその属性の値をOracle RTDのログに出力する方法の詳細は、第13.6.21項「エンティティ属性のロギングの拡張」を参照してください。

14.4.2.2 着信リクエスト・データのテスト

統合点のテスト時に、次のメソッドを使用して着信リクエスト・データを確認できます。入力されたパラメータがセッション属性にマップされる場合は、そのパラメータにgetメソッドがあります。

request.get$()

この$は、先頭が大文字のパラメータ名です。

この属性がマップされない場合は、パラメータのフィールド名を使用して、同じ結果をもたらすメソッドがあります。

String request.getStringValue(fieldName)
SDStringArray request.getStringArrayValue(fieldName)
boolean request.isArgPresent(fieldName)

送信レスポンス・データは常に、SDChoiceArrayに格納されます。

SDChoiceArray choices = null;

デシジョンは統合点によって実行され、選択肢が格納されます。

if (session().isControlGroup()) {
choices = RandomChoice.execute();
} else {
choices = SelectOffer.execute();
}

選択肢を調べるには、配列から取得し、getSDOIdまたはgetSDOLabelを使用します。

if (choices.size() > 0) {
Choice ch = choices.get(0);
ch.getSDOId();
}

これを行うために最適な場所が、デシジョンの選択後ロジック論理です。デシジョンの実行後に選択後ロジックが実行されます。

14.4.3 システム・ログを使用してインライン・サービスのテストとデバッグを行う方法

システム・ログは、インライン・サービスのテストとデバッグおよびパフォーマンスの監視とチューニングに役立ちます。

Oracle RTDの実行時ログ・ファイルの名前は、一般に次のとおりです。

- RTD_RUNTIME_HOME\log\server_name-diagnostic[-<n>].log

server_nameは、Oracle RTDが実行されているWebLogic Serverです。

詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のシステム・ログ・ファイルと構成ファイルに関する項を参照してください。

15 ロード・ジェネレータについて

この章では、ロード・ジェネレータについて説明します。ロード・ジェネレータは、デシジョン・リクエストをシミュレートしてインライン・サービスのデバッグおよびベンチマークを行うためのツールです。ロード・ジェネレータは、インライン・サービスのテストとパフォーマンスの特徴付けの両方に使用します。

ロード・ジェネレータは、RTD_HOME\scripts\loadgen.cmdを実行するとアクセスできます。ロード・ジェネレータ・スクリプトのサンプルの詳細は、Cross Sellサンプルのetcディレクトリを参照してください。

ロード・ジェネレータには、次の5つのタブがあります。

- セキュリティ:ロード・ジェネレータのセッションを実行するには、有効なユーザー名とパスワードをこのタブで入力する必要があります。

- 実行:ロード・ジェネレータのセッションを実行し、測定とグラフを使用してパフォーマンスのフィードバックを提供します。

- 一般: サーバーへのデータの送信速度やクライアントの構成ファイルの場所など、ロード・ジェネレータの操作の一般的な設定を行います。

- 変数: スクリプト、メッセージおよびアクセス変数の作成に使用します。

- スクリプトの編集: サーバーに送信する統合点リクエストを指定するスクリプトの設定に使用します。

この項には次のトピックが含まれます:

- 第15.1項「ロード・ジェネレータによるテスト」

- 第15.2項「ロード・ジェネレータによるパフォーマンスの特徴付け」

- 第15.3項「ロード・ジェネレータのセッションの実行」

- 第15.4項「パフォーマンス・グラフの表示」

- 第15.5項「「一般」タブについて」

- 第15.6項「変数について」

- 第15.7項「アクションについて」

- 第15.8項「ロード・ジェネレータのCSVログ・ファイルの内容」

- 第15.9項「XLSファイルの内容」

15.1 ロード・ジェネレータによるテスト

ロード・ジェネレータは、サーバーに対して負荷を生成し、パフォーマンスおよびスケーラビリティをテストするために使用します。理にかなったランダムなメッセージがインライン・サービスに送信され、モデルが学習できます。ロード・ジェネレータを十分な時間実行することによって、モデルの性能を測定できます。

15.2 ロード・ジェネレータによるパフォーマンスの特徴付け

インライン・サービスを構成したら、ロード・ジェネレータを使用し、特定の負荷がある状態で必要なサーバー数を判断するために、サービスの実行状況を評価します。ロード・ジェネレータは多数のスレッドの実行を扱い、複数のスクリプトを並行して実行できるので、サーバーに負荷をかけるとき、通常は1台のクライアント・マシンでロード・ジェネレータを1インスタンス実行するのみで十分です。さらに負荷をかける必要があり、Microsoftのタスク マネージャに、ロード・ジェネレータがすでにクライアントの処理能力の大部分を使用していると表示された場合、ロード・ジェネレータのインスタンスのいくつかを何台かのクライアント・コンピュータで起動し、1台のサーバーをポイントすることができます。理にかなったランダムなメッセージが生成され、セッションのコンテキストで送信されます。サーバーとともに、クライアントがパフォーマンス統計を測定します。

15.3 ロード・ジェネレータのセッションの実行

セッションを開始するには、まずスクリプトを新規に作成するか、既存のスクリプトをロードします。「セキュリティ」タブで、有効なユーザー名とパスワードを入力します。次に、「実行」メニューから「実行」オプションを選択するか、ツールバーの「実行」アイコンをクリックします。「一般」タブでは、データ・サンプル間の遅延を変更できます。

15.3.1 サーバーの負荷の測定

「実行」タブには、実行中のセッションのリアルタイム情報が表示されます。表15-1で、「実行」タブのオプションについて説明します。

表15-1ロード・ジェネレータの「実行」タブのオプション

オプション名

説明

新規リクエスト

前のデータ・サンプルが取得された後にクローズされたリクエストの数。

新規エラー

前のデータ・サンプルが記録された後に、クライアント側とサーバー側いずれかで発生したエラーの数。

新規デフォルト・レスポンス

最後のデータ・サンプル以後、そしてアドバイザのインライン・サービスでデフォルトのレスポンスが定義されて以後、(インフォーマントの統合点リクエストと相対する)アドバイザの統合点リクエストに発生したエラーの数。

アクティブ・スクリプト

このロード・ジェネレータからサーバーに同時に接続しているシミュレートされたユーザーの数。

ピーク・レスポンス時間

現在のデータ・サンプル中、最も古いリクエストをクローズするまでにかかった時間。

リクエスト合計

クローズされたリクエストの合計数。

エラー合計

エラーの合計数。

デフォルト・レスポンス合計

デフォルトのレスポンスの合計数。

終了したスクリプトの合計

シミュレートされたユーザーの合計数。

平均スクリプト期間

開始から終了までの、平均的なスクリプトの実行時間(ミリ秒)。

15.4 パフォーマンス・グラフの表示

デフォルトでは「リクエスト/秒」グラフが表示されます。「表示」→「グラフ」を選択すると、グラフの表示と非表示を切り替えることができます。グラフのデータをクリアするには、「表示」→「グラフのクリア」を選択するか、ツールバーの「グラフのクリア」アイコンをクリックします。

スクリプトを停止して再開した場合、記録されたデータはすべてクリアされます。ただし、セッションを一時停止して再開した場合は、データはクリアされません。使用可能なグラフは次のとおりです。

- 平均レスポンス時間: 直近40件の平均レスポンス時間を示すヒストグラム。

- エラー: 直近12,000件のデータ・サンプル内で発生したエラーの数を示す折れ線グラフ。

- ピーク・レスポンス時間: 直近12,000件の各データ・サンプル内で発生したピーク・レスポンス時間(ミリ秒)を示す折れ線グラフ。

- リクエスト/秒: 直近12,000件の各データ・サンプル内で発生した1秒当たりの平均リクエスト数を示す折れ線グラフ。

- リクエスト/秒の分布: 直近40件の1秒当たりのリクエスト読取り数を示すヒストグラム。

15.5 「一般」タブについて

「一般」タブには、ロード・ジェネレータの構成、タイミング、および、どのインライン・サービスが指定されているかに関する変数が含まれています。「一般」タブには、「ロード・ジェネレータ」、「詳細」、「思考時間」、「スクリプト」および「ロギング」の5つのセクションがあります。

この項には次のトピックが含まれます:

- 第15.5.1項「「ロード・ジェネレータ」セクション」

- 第15.5.2項「「詳細」セクション」

- 第15.5.3項「「思考時間」セクション」

- 第15.5.4項「「スクリプト」セクション」

- 第15.5.5項「「ロギング」セクション」

15.5.1 「ロード・ジェネレータ」セクション

「一般」タブの「ロード・ジェネレータ」セクションには次のオプションがあります。

- クライアント構成: サーバーとの通信にロード・ジェネレータが使用するエンドポイントを記述します。

- グラフ・リフレッシュ間隔(秒): グラフおよびカウンタの更新間の遅延を設定します。スクリプトがすでに実行中のときに設定を有効にするには、「適用」をクリックします。

15.5.2 「詳細」セクション

「一般」タブの「詳細」セクションには次のオプションがあります。

- インライン・サービス: このスクリプトからリクエストが送信されるインライン・サービスの名前。

- ランダム数値ジェネレータ・シード: スクリプトにランダムな要素がある場合、これによってランダムな動作をある程度まで再現できます。複数の並行処理スクリプトを実行している場合、ランダムな状態を繰り返すことはできません(第15.5.4項「「スクリプト」セクション」の「実行する同時スクリプトの数」を参照)。

15.5.3 「思考時間」セクション

「一般」タブの「思考時間」セクションには次のオプションがあります。

- 固定グローバル思考時間: シミュレートされたすべてのユーザーがリクエスト間で待機する秒数。

- 範囲指定されたグローバル思考時間: シミュレートされたユーザーがリクエスト間で待機する可変時間。この思考時間は、ランダムな数字、または設定された数字範囲から順次増分される数字によって変化します。

- 最小: ゼロ以外の最小待機秒数。

- 最大: ゼロ以外の最大待機秒数(最小待機秒数より大きい数値であることが必要)。

- アクセス・タイプ順次: アクセスのたびに1ずつ増分される思考時間で、最大待機秒数に達すると最小待機秒数にリセットされます。

- アクセス・タイプ・ランダム: アクセスのたびに、最小待機秒数と最大待機秒数の間の値を選択します(最小待機秒数と最大待機秒数も選択可)。

15.5.4 「スクリプト」セクション

「一般」タブの「スクリプト」セクションには次のオプションがあります。

- 実行する同時スクリプトの数: シミュレート対象となる同時ユーザーの数。

- 実行するスクリプトの最大数: このフィールドの値が正の場合、その数のセッションの完了後、ロード・ジェネレータの実行は停止します。ゼロは無制限を意味します。

15.5.5 「ロギング」セクション

「一般」タブの「ロギング」セクションには次のオプションがあります。

- ロギングの有効化: このオプションを選択すると、ロード・ジェネレータの統計データが、定期的にファイルに書き込まれます。

- 既存のファイルへ追加: ロギングが有効になっているとき、このオプションを選択すると、ログ・ファイルがすでに存在している場合はその最後に新しい統計データが追加され、存在していない場合はファイルが新規に作成されます。

- ログ・ファイル: タブ区切りのログ・ファイルへのフルパス。その内容の詳細は、第15.8項「ロード・ジェネレータのCSVログ・ファイルの内容」を参照してください。

- ロギング間隔: ログ・ファイルに値が書き込まれてから、次の値セットが書き込まれるまでに待機する秒数。

15.6 変数について

変数を使用すると、負荷をシミュレートする際に、様々なソースから情報を得ることができます。セッション変数は、セッションごとに1回生成されます。セッション変数は、その後アクセスした際にも同じ値が使用されます。メッセージ変数は、1つのリクエスト内では変わりません。アクセス変数は、読込みのたびに変わる場合があります。変数はメッセージ・アクションで使用されます。

この項には次のトピックが含まれます:

- 第15.6.1項「変数の使用」

- 第15.6.2項「変数の種類」

15.6.1 変数の使用

メッセージで変数をメッセージ・パラメータの値に使用する場合(「スクリプトの編集」タブ内)、「変数」列のドロップダウン・リストから選択します。ただし、「値」列で連結文字列値の一部として使用する場合、変数名を中カッコで囲みます(たとえばC001-{customerNum})。

注意:

単純に「値」列に{customerNum}を入力することは、「値」列でcustomerNumを選択することに相当します。

15.6.2 変数型

変数には次の5種類があります。

- 定数値: 定数の値。

- 整数範囲: 範囲から整数を選択します。例:

Minimum: 0, Maximum: 50000, Access Type: Random
Minimum: 0, Maximum: 1, Access Type: Sequential

- 文字配列: 指定した配列から文字列を選択します。例:

List: [A, B, C], Access Type: Random
List: [Male, Female], Access Type: Sequential

- 加重された文字列配列: 指定した配列から、[0,1]のような可能性とともに文字列を選択します。例:

List: [[0.3, Interested], [0.3, Accepted], [0.4, Rejected]]
List: [[0.999, Interested], [0.001, Accepted]]

- テキスト・ファイル: ファイルからテキストの行を選択します。例:

c:/data.txt, Access Type: Sequential

この例は、C:ドライブ上のファイルへの絶対参照を示しています。

inbox/data.txt, Access Type: Random

この例は、スクリプト・ファイルのあるディレクトリ下のinboxディレクトリにあるファイルへの相対参照を示しています。

15.7 アクションについて

現実性のある負荷をサーバーに課す複数のクライアントを簡単にシミュレートできるように、メタデータに指定された、ロード・ジェネレータが実行時に解釈するパターンからメッセージを生成できます。このようなアクション・パターンは、「スクリプトの編集」タブで定義します。

このパターンは、メッセージ間の遅延(思考時間)が固定またはランダムになっているメッセージ順序を指定します。また、メッセージ・フィールドの値を生成するパターンもあります。メッセージ・フィールドの値には、オプションでランダムな文字を埋め込んだリテラル文字列を使用することも、フィールドに関連付けられた値セットからランダムに選択した値を使用することもできます。

セッションをサポートしているため、セッション内のメッセージ全体で特定のフィールドを一定にできます。これは、(顧客ID、コールID、口座番号など)セッション・キーの表現に適しています。

このパターンによって、メッセージの順序付けを柔軟なものにできます。たとえば、典型的なセッションで、特定のメッセージが他のメッセージより前にくるようにしたり、ある種類について事前に決定した数のメッセージが生じるようにすることができます。

15.7.1 アクションの種類

アクションには、メッセージとループの2種類があります。

メッセージの属性は次のとおりです。

- 統合点名: メッセージの送信先となる統合点の名前。

- セッション・キーと値: 統合点リクエストに送信される値。セッション・キーは、サーバーがルーティングに使用するので、他のメッセージ・フィールドと区別する必要があります。

ループには実行回数の属性があります。この属性には、定数値または範囲値を指定できます。範囲値は、範囲内で順次またはランダムに実行されます。

15.8 ロード・ジェネレータのCSVログ・ファイルの内容

表15-2は、ロード・ジェネレータの統計を含むカンマ区切り値(CSV)ファイルのフィールドを示しています。

表15-2ロード・ジェネレータのCSVファイルのフィールド

フィールド名

説明

日付/時間

カウンタの現在行がファイルに追加された時刻。サーバーのログ・ファイルに格納されているメッセージとの相関関係を高めるため、ミリ秒単位の精度が用意されています。

スレッド・プール・サイズ

スクリプトの実行のために使用中または使用可能なスレッド数。これはほとんどのユーザーには無関係な、実装に関する詳細です。

新規リクエスト

前のデータ・サンプルが取得された後にクローズされたリクエストの数。

リクエスト合計

クローズされたリクエストの合計数。

新規エラー

前のデータ・サンプルが記録された後に、クライアント側とサーバー側いずれかで発生したエラーの数。

エラー合計

エラーの合計数。

新規デフォルト・レスポンス

最後のデータ・サンプル以後、そしてアドバイザのインライン・サービスでデフォルトのレスポンスが定義されて以後、(インフォーマントの統合点リクエストと相対する)アドバイザの統合点リクエストに発生したエラーの数。

デフォルト・レスポンス合計

デフォルトのレスポンスの合計数。

アクティブ・スクリプト

このロード・ジェネレータからサーバーに同時に接続しているシミュレートされたユーザーの数。

スクリプト合計

シミュレートされたユーザーの合計数。

平均レスポンス時間(ms)

現在のデータ・サンプル中、最も古いリクエストをクローズするまでにかかった平均時間。

最大レスポンス時間(ms)

現在のデータ・サンプル中、最も古いリクエストをクローズするまでにかかった最長時間。

平均スクリプト実行時間(ms)

開始から終了までの、平均的なスクリプトの実行時間(ミリ秒)。

スナップショット期間(ms)

現在のカウンタ値が累積された期間のミリ秒数。

15.9 XLSファイルのコンテンツ

この項では、log/loadgen.csvに書き込まれるロード・ジェネレータのカウンタをレンダリングするための、インストールのetcディレクトリに含まれるMicrosoft Excelのファイルlg_perf.xlsの内容について説明します。

最上部のセルA1には、データソースとしてlg_perf.xlsをタブ区切りのカウンタ・ファイルにリンクする方法を記述したコメントがあります。次にその内容を示します。

- ロード・ジェネレータのパフォーマンス・ログのパスを指定するには、セルA2にカーソルを置き、「データ」メニューから「外部データの取り込み」→「テキスト ファイルのインポートの編集」を選択し、loadgen構成で指定したパス(通常は{$install_directory}\log\loadgen.csv)に移動します。要求されたらデフォルトの解析設定を使用します。データは、3 分おきに自動的にリフレッシュされます。間隔などの設定を変更するには、「データ」メニューから「外部データの取り込み」→「データ範囲プロパティ」を選択します。

行2には、各カウンタの名前が含まれるヘッダーが表示されます。前述のCSVファイルのすべてのヘッダーがここに表示され、ヘッダーの下に値が表示されます。

第IV部

その他のアプリケーション開発

第IV部の各章では、Oracle RTDアプリケーション・オブジェクトの変更が可能な外部エディタやバッチ・フレームワークなど、特別な処理を必要とするOracle RTDアプリケーション開発に関連する概念、コンポーネントおよびプロセスについて詳しく説明します。

第IV部の内容は次のとおりです。

- 第16章「Oracle RTDバッチ・フレームワーク」

- 第17章「外部化されたオブジェクト管理」

16 Oracle RTDバッチ・フレームワーク

Oracle RTDバッチ・フレームワークは、インライン・サービスでバッチ機能を実現できるコンポーネントのセットです。これにより、インライン・サービスで対話型統合点リクエストの処理に使用できるだけでなく、あらゆる種類のバッチ操作も実行できます。この章では、バッチ・フレームワークのアーキテクチャと、バッチ・ジョブを実装および管理する方法について説明します。

一般的に、バッチでは、データベース表、フラット・ファイルまたはスプレッドシートから一連の入力行を読み取り、各入力行を順番に処理し、必要に応じて入力行ごとに1行以上の行を出力表に書き込みます。

非対話型の設定でOracle RTDのバッチ処理機能を使用する例を、次に簡単に示します。

- 顧客に以前に提示したオファーの効果に関する履歴データから学習してモデルを最適化するために、学習バッチを作成する例

- 顧客のセットから開始して、各顧客へのオファーに最適な製品を選択するように、オファー選択バッチを作成する例

- 単一の製品から開始して、その製品のオファー対象として最適な顧客を選択するように、顧客選択バッチを作成する例

- Oracle RTDで電子メール用に適切な内容を選択するように、電子メールのバッチ・セットを作成する例

インライン・サービスでは、インライン・サービスの開発者が、BatchJobインタフェースを実装するJavaクラスを1つ以上定義します。BatchJobは、インライン・サービスでサポートする名前付きバッチごとに1つ使用します。インライン・サービスで、BatchJobの各実装をOracle RTDバッチ・フレームワークに登録することで、使用可能なジョブ・タイプが外部のバッチ管理アプリケーションで開始できるようになります。外部アプリケーションは、バッチ・フレームワークで用意されているBatchAdminClientクラスを介して、登録されているバッチ・ジョブの開始、停止およびステータスの問合せができます。Oracle RTDに付属のバッチ・コンソールは、このようなバッチ関連管理作業を実行できるコマンドライン・ユーティリティです。

注意:

Oracle RTDドキュメント全体にわたって次の用語が参照されます。

- RTD_HOME: Oracle RTDクライアント側ツールがインストールされているディレクトリです。

- RTD_RUNTIME_HOME: アプリケーション・サーバーによってOracle RTDが実行されるアプリケーション・サーバー固有ディレクトリです。

詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「Oracle RTDラインタイム環境について」を参照してください。

この章の内容は次のとおりです。

- 第16.1項「バッチ・フレームワーク・アーキテクチャ」

- 第16.2項「バッチ・ジョブの実装」

- 第16.3項「バッチ・ジョブの管理」

16.1 バッチ・フレームワーク・アーキテクチャ

この項では、バッチ・フレームワーク・アーキテクチャのコンポーネントの概要を示し、複数のクラスタ・サーバー全体でバッチ機能を使用する方法について説明します。

16.1.1 バッチ・フレームワークのコンポーネント

次の図は、単一のOracle RTDインスタンスにおけるバッチ・フレームワーク・アーキテクチャのコンポーネントを示しています。

バッチ・フレームワークの主要コンポーネントとその機能は、次のとおりです。

- Batch Admin Client
Batch Admin ClientはJava APIのセットを備えており、Javaクライアント・アプリケーションはこれを使用することで、リモートのReal-Time Decision Serverに登録されているバッチを管理できます。これには、バッチの開始と停止およびバッチ・ステータス情報の取得が含まれます。

顧客は、Batch Admin Clientで用意されているAPIを使用して、独自のバッチ・クライアント・アプリケーションを作成できます。

バッチ・コンソールは、リモートのReal-Time Decision Serverに登録されているバッチを管理するためのクライアント側コマンドライン・ユーティリティです。内部的には、バッチ・コンソールはBatch Admin Clientで用意されているAPIを使用しています。

- Batch Manager
これはクラスタ全体のシングルトン・サービスで、Batch Admin Clientからクライアント・コードのクライアント・バッチ・コマンドを実行します。Batch Managerは、クラスタの各Batch Agentを管理します。

Batch Managerは、バッチ・コンソールのコマンドも実行します。

- Batch Agent
Batch Agentは、バッチ・ジョブとバッチ・フレームワークとの間のインタフェースです。バッチ対応のインライン・サービスがデプロイされるとバッチをBatch Managerに登録し、Batch Managerのかわりにバッチ・コマンドを実行するサービスです。

クラスタ環境では、バッチ・フレームワークのコンポーネントのすべてが各Oracle RTDインスタンスに表示されます。ただし、Batch Managerはいずれかのインスタンスでのみアクティブであり、そのアクティブなBatch Managerが、クラスタ内のすべてのBatch Admin ClientリクエストおよびBatch Agentリクエストを制御します。

16.1.2 クラスタ環境内でのバッチ・フレームワークの使用

次の図は、クラスタ環境内でのバッチ・フレームワークの使用例を示しています。

バッチ・コンソールなどのバッチ・クライアント・アプリケーションは、ジョブの開始、停止、一時停止などのバッチ管理コマンドを起動することでBatch Managerと通信します。

デシジョン・スタジオを使用している開発者は、インライン・サービスを作成し、Oracle RTDがインストールされているインスタンス(クラスタ・サーバー2のインスタンスなど)に、バッチでインライン・サービスをデプロイできます。

注意:

クラスタ環境では、Decision Serviceを実行しているすべてのサーバーにインライン・サービスがデプロイされます。

この図では、クラスタ・サーバー2インスタンス上のBatch Agentが、Batch Managerにバッチを登録しています。

Batch Managerは、登録済のバッチ・ジョブを、クラスタ・サーバー3など、任意のインスタンスで実行できます。

16.2 バッチ・ジョブの実装

この項では、バッチを実装するために必要なランタイム・オブジェクト・モデルの概要を説明します。

インライン・サービスがバッチ対応であるためには、BatchJobインタフェースを実装するバッチ・ジョブ用Javaクラスが1つ以上必要であり、これをバッチ・フレームワークに登録する必要があります。

注意:

この項の例は、Oracle RTDとともにリリースされるCrossSellインライン・サービスを参照しています。これには、CrossSellSelectOffersバッチ・ジョブが含まれています。

この項には、次の項目が含まれます。

- 第16.2.1項「BatchJobインタフェースの実装」

- 第16.2.2項「バッチ・フレームワークへのバッチ・ジョブの登録」

16.2.1 BatchJobインタフェースの実装

デシジョン・スタジオでのバッチ・ジョブの実装は、BatchJobインタフェースを実装するJavaクラスを作成することで開始します。

最初に、インライン・サービスのsrcブランチの下に、Javaパッケージおよびクラスを作成します。

次の図は、バッチ処理用JavaクラスのOfferSelectJob.javaを示しています。これはcrosssell.batchパッケージで宣言されています。

Javaクラスを作成する最も簡単な方法は、バッチ・フレームワークで用意されているBatchJobBaseからサブクラス化する方法です。

ジョブが開始すると、バッチ・ジョブの主要メソッドが次の順序でコールされます。

1. init()
バッチの処理ループを開始する前に、フレームワークによって1回コールされます。

2. getNextInput()
バッチで処理される次の入力行を返します。

3. executeRow()
BatchJobではこのメソッドを実装することで、getNextInputによって返された入力行を処理します。通常は、getNextInputとは異なるスレッドでコールされます。

4. flushOutputs()
フレームワークによってコールされ、BatchJobではその出力表バッファをフラッシュできます。

5. cleanup()
バッチの終了後や停止後に、フレームワークによってコールされます。init()メソッドによって作成された結果セットなど、バッチ・ジョブによって割り当てられたリソースをクリーンアップします。

BatchJobインタフェースのメソッドの詳細は、次のJavadocエントリを参照してください。

RTD_HOME\client\Batch\javadocs\com\sigmadynamics\batch\BatchJob.html

サンプルのバッチ・ジョブ

サンプルのバッチ・ジョブであるOfferSelectJob.javaは、Oracle RTDとともにリリースされるCrossSellインライン・サービスにあります。このバッチ・ジョブは、顧客のセットに対して最適なオファーを選択し、そのオファーを表に保存します。

16.2.2 バッチ・フレームワークへのバッチ・ジョブの登録

この項では、Oracle RTDバッチ・フレームワークにバッチ・ジョブを登録する方法について説明します。バッチ・ジョブを含むJavaクラスを、インポートされたJavaクラスとして登録してから、batchAgent.registerBatchメソッドを使用してバッチ・ジョブをバッチ・フレームワークに明示的に登録する必要があります。

この項には、次の項目が含まれます。

- 第16.2.2.1項「BatchAgent」

- 第16.2.2.2項「インポートされたJavaクラスのインライン・サービスへの登録」

- 第16.2.2.3項「バッチ・ジョブのインライン・サービスへの登録」

16.2.2.1 BatchAgent

バッチ・ジョブにおいて、Batch Agentは、バッチ・ジョブとバッチ・フレームワークとの間のインタフェースです。バッチ・ジョブはバッチ・フレームワークに登録する必要があります。

インライン・サービスは、そのアプリケーション・オブジェクトの「ロジック」にあるゲッターを介して、Batch Agentを指定できます。たとえば、インライン・サービスがセッションにアクセスできるコンテキストでは、次のコマンドを使用してBatchAgentにアクセスできます。

- BatchAgent batchAgent = session().getApp().getBatchAgent();

16.2.2.2 インポートされたJavaクラスのインライン・サービスへの登録

次に示すように、Javaクラスをインライン・サービスに登録する必要があります。

1. アプリケーション・オブジェクトの「詳細」ボタンをクリックします。

2. 「インポートしたJavaクラス」ペインで、インライン・サービスのバッチ・ジョブ・クラスごとに次の形式で行を入力します。

<package>.<class>

例:

crosssell.batch.OfferSelectJob

16.2.2.3 バッチ・ジョブのインライン・サービスへの登録

インライン・サービスは、アプリケーションの「ロジック」タブの「初期化ロジック」ペインで、batchAgent.registerBatch APIを使用してそのBatchJob実装を登録する必要があります。

インライン・サービスは、そのアプリケーション・オブジェクトのゲッターを介して、バッチ・フレームワークへのインタフェースであるBatch Agentを指定できます。次のような行を入力します。

BatchAgent batchAgent = getBatchAgent();

続けて、インライン・サービスのバッチ・ジョブごとに、batchAgent.registerBatchの起動を指定します。

batchAgent.registerBatchのパラメータの詳細は、次のJavadocエントリを参照してください。

RTD_HOME\client\Batch\javadocs\com\sigmadynamics\batch\BatchAgent.html

batchAgent.registerBatchのパラメータの要約は、次のとおりです。

- batchName: バッチ・クラスをクラスタに登録するときに使用される短縮名。クラス全体で一意である必要があります。

- batchJobClass: バッチのBatchJob実装クラスの完全修飾名。

- description: nullでない場合は、バッチの目的を説明する文字列。

- parameterDescriptions: バッチでサポートされるパラメータを説明するプロパティのセット(オプション)。

- parameterDefaults: バッチでサポートされるパラメータのデフォルト値を用意するプロパティのセット(オプション)。

たとえば、次のものを登録すると仮定します。

- crosssell.batch.OfferSelectJobクラスを使用するCrossSellSelectOffersバッチ

アプリケーションの「初期化ロジック」で、次を入力します。

BatchAgent batchAgent = getBatchAgent();
batchAgent.registerBatch("CrossSellSelectOffers",
"crosssell.batch.OfferSelectJob",
OfferSelectJob.description,
OfferSelectJob.paramDescriptions,
OfferSelectJob.paramDefaults);

16.3 バッチ・ジョブの管理

バッチの開始と停止、ステータスの問合せなど、バッチ・ジョブを管理する場合の中心となる方法は、コマンドライン・ユーティリティのバッチ・コンソールを使用する方法です。

このユーティリティでは、BatchAdminClient Javaインタフェースを使用しています。BatchAdminClient Javaインタフェースには、バッチの開始や管理を行うためのメソッドも含まれており、これらのメソッドは外部プログラムで使用します。

この項には次のトピックが含まれます:

- 第16.3.1項「BatchClientAdminインタフェースの使用」

- 第16.3.2項「バッチ・コンソールの使用」

16.3.1 BatchClientAdminインタフェースの使用

BatchAdminClient Javaインタフェースには、バッチの開始や管理を行うためのメソッドが含まれており、これらのメソッドは外部プログラムで使用します。

表16-1に、BatchAdminClientインタフェースのメソッドを示します。

表16-1 BatchAdminClientのメソッド

戻り型

説明

int

clearBatchStatuses()

すべての完了済バッチのステータス情報を削除します。

int

clearBatchStatuses(int numToKeep)

完了済ジョブにおいて最も古いバッチのステータス情報を削除します。

int

clearBatchStatuses(java.lang.String batchName)

完了済ジョブにおいて指定バッチ名を持つすべてバッチのステータス情報を削除します。

int

clearBatchStatuses(java.lang.String batchName, int numToKeep)

完了済ジョブにおいて指定バッチ名を持つすべてバッチのステータス情報を削除します。

BatchStatusBrief[]

getActiveBatches()

現在実行中、一時停止または実行待ちのバッチ・ジョブのすべてについて、簡単なステータス情報の順序付きリスト(場合によっては空)を返します。

java.lang.String

getBatchDescription(java.lang.String batchName)

バッチの目的を説明する文字列(場合によっては空)を返します。

java.lang.String[]

getBatchNames()

バッチ・フレームワークに登録されているバッチのリストを取得します。

java.util.Properties

getBatchParameterDefaults(java.lang.String batchName)

バッチがサポートする起動パラメータのデフォルト値を格納しているプロパティを取得します。

java.util.Properties

getBatchParameterDescriptions(java.lang.String batchName)

バッチがサポートするパラメータを説明するプロパティを取得します。

BatchStatusBrief[]

getJobHistory()

バッチ・マネージャがそのステータス情報を保持しているバッチ・ジョブ(clearBatchStatusesによって説明が破棄されていないバッチ・ジョブ)のすべてについて、簡単なステータス情報の順序付きリスト(場合によっては空)を返します。

BatchStatusBrief[]

getJobHistory(int maxToShow)

Batch Managerがそのステータス情報を保持しているバッチ・ジョブ(clearBatchStatusesによって説明が破棄されていないバッチ・ジョブ)のすべてについて、簡単なステータス情報の順序付きリスト(場合によっては空)を返します。

BatchStatus

getStatus(java.lang.String batchID)

startBatch()へのコールによって発行された際に返されたバッチIDによって識別されるバッチのステータスを返します。

void

pauseBatch(java.lang.String batchID)

バッチを停止しますが、再開できるように、リソースはクリーンアップされません。

void

restartBatch(java.lang.String batchID)

停止しているバッチを再起動します。

void

resumeBatch(java.lang.String batchID)

一時停止しているバッチを続行します。

java.lang.String

startBatch(java.lang.String batchName)

デフォルトの起動パラメータによりデフォルトの並行処理グループでバッチを開始します。

java.lang.String

startBatch(java.lang.String batchName, BatchRequest startParameters)

渡された起動パラメータによりデフォルトの並行処理グループでバッチを開始します。

java.lang.String

startBatch(java.lang.String batchName, java.lang.String concurrencyGroup)

デフォルトの起動パラメータを使用して、指定された並行処理グループでバッチを開始します。

java.lang.String

startBatch(java.lang.String batchName, java.lang.String concurrencyGroup, BatchRequest startParameters)

渡された起動パラメータを使用して、指定された並行処理グループでバッチを開始します。

void

stopBatch(java.lang.String batchID)

バッチを停止し、BatchJob.cleanup()をコールしてそのリソースをクリーンアップします。

void

stopBatch(java.lang.String batchID, boolean discardSandboxes)

バッチを停止し、BatchJob.cleanup()をコールすることでそのリソースをクリーンアップします。また必要に応じて、最後のチェックポイント以降、バッチによって生成された学習データと出力表レコードを破棄します。

BatchAdminClientインタフェースの詳細は、次のJavadocエントリを参照してください。

RTD_HOME\client\Batch\javadocs\com\sigmadynamics\batch\client\BatchAdminClient.html

16.3.2 バッチ・コンソールの使用

バッチ・コンソールは、batch-console.jarというコマンドライン・ユーティリティです。バッチの開始、停止およびステータスの問合せを行うには、バッチ・コンソールを使用します。

バッチ・コンソールを起動するには、次のコマンドを実行します。

1. cd BATCH_HOME
通常、BATCH_HOMEはC:\OracleBI\RTD\client\Batchです。

2. java [-Djavax.net.ssl.trustStore="<trust_store_location>"] -jar batch-console.jar -user <batch_user_name> -pw <batch_user_password> [-url <RTD_server_URL>] [-help]

注意:

1. バッチ・ユーザー名とパスワード情報を入力する必要があります。-userパラメータや-pwパラメータの値を指定しないと、その入力が求められます。

2. <RTD_server_URL>(デフォルト値はhttp://localhost:8080)は、Decision Serviceのアドレスです。クラスタの場合、一般的にロード・バランサの仮想アドレスで、Decision ServiceのJ2EEクラスタを指すアドレスになります。

3. -Djavax.net.ssl.trustStore="<trust_store_location>"パラメータは、SSLを使用してReal-Time Decision Serverに接続する場合にのみ使用します。ここで、<trust_store_location>は、トラストストア・ファイルのフルパスです。たとえば、-Djavax.net.ssl.trustStore="C:\OracleBI\RTD\etc\ssl\sdtrust.store"と指定します。この場合、<RTD_server_URL>は、https://localhost:9804のようになります。

4. 他のコマンドライン・パラメータの有無にかかわらず「-help」と入力すると、-helpを含めて、バッチ・コンソールのすべてのコマンドライン・パラメータの使用方法が一覧表示されます。

バッチ・コンソールで対話型コマンドを一覧表示するには、コマンド・プロンプトで「?」を入力します。

command <requiredParam>  -- [alias] Description

?                        -- Show this usage text
help                     -- Show this usage text
exit                     -- Terminate this program
quit                     -- Terminate this program
batchNames               -- [bn]      Show all registered Batch
batchDesc <batchName>    -- [bd]      Show Batch Description
paramDesc <batchName>    -- [pd]      Show a batch's Parameter Descriptions
paramDef <batchName>     -- [pdef]    Show a batch's Parameter Default values
addProp <key> <value>    -- [ap]      Add one Property for next job start
removeProp <key>         -- [rp]      Remove one startup Property
showAddedProps           -- [sap]     Show all Added startup Properties
removeAddedProps         -- [rap]     Remove all Added startup Properties
startJob <batchName>     -- [start]   Start a batch job, returning a jobID
startInGroup <batchName> <groupName>
-- [startg]  Start a batch job in a Concurrency Group
status <jobID>           -- [sts]     Show a job's detailed runtime Status
activeJobs               -- [jobs]    Show brief status of all running,
paused, waiting jobs
jobHistory               -- [hist]    Show brief status of all submitted jobs
stopJob <jobID>          -- [stop]    Stop a job, without abililty to resume
stopJobDiscardSandbox <jobID>
-- [stopds]  Stop a job, without abililty
to resume, discard learning sandboxes
restartJob <jobID>       -- [restart] Restart a batch job
pauseJob <jobID>         -- [pause]   Pause a job
resumeJob <jobID>        -- [resume]  Resume a paused job
discardStatusAll         -- [dsa]     Discard status information
for all non-active jobs
discardStatusOld <numToKeep>
-- [dso]     Discard Status for oldest non-active jobs
discardStatusName <batchName>
-- [dsn]     Discard Status for non-active
jobs of named batch
discardStatusNameOld <batchName> <numToKeep>
-- [dsno]    Discard Status for oldest
non-active jobs of named batch

この項の以降の内容は次のとおりです。

- 第16.3.2.1項「バッチ・コンソール・コマンドに関する注意」

- 第16.3.2.2項「ジョブの順次実行」

- 第16.3.2.3項「ジョブの並行処理」

16.3.2.1 バッチ・コンソール・コマンドに関する注意

1. 登録されているバッチの一覧を取得するには、「bn」または「batchNames」を入力します。

2. バッチのデフォルト・パラメータ値を取得するには、「paramDef <batchName>」または「pdef <batchName>」を入力します。
たとえば、バッチに次のパラメータ値が含まれているものと仮定します。

- sqlCustomers - 処理対象となる顧客を選択するためのパラメータ値

- rowsBetweenStatusUpdates - バッチ・ステータスの更新頻度を制御するためのパラメータ値

これらのパラメータのデフォルト値は、次のように指定できます。

- sqlCustomers = SELECT Id FROM Customers WHERE Id < 300

- rowsBetweenStatusUpdates = 1000

3. 次回バッチを起動するときに使用するパラメータ値を指定するには、addPropコマンドまたはその別名のapを使用します。
たとえば、次のコマンドで、すべての顧客を含むようにsqlCustomersパラメータよりも優先することができます。

- ap sqlCustomers SELECT Id FROM Customers

また、顧客を1500人処理するたびにバッチ・ステータスを更新するには、次のコマンドを入力します。

- ap rowsBetweenStatusUpdates 1500

このように明示的に追加されたすべてのパラメータは、showAddedPropsコマンドまたはその別名のsapで表示できます。

たとえば、前述のapコマンドを使用した場合、sap出力は次のようになります。

Property                       Value
--------                       -----
rowsBetweenStatusUpdates       1500
sqlCustomers                   SELECT Id FROM Customers

4. バッチを開始するには、startJobコマンドまたはその別名のstartを使用します。
次のような出力が表示されます。

- batchID=batch-2

返されるbatchIDはjob-IDとも呼ばれ、このジョブ・インスタンスが識別されます。これを使用して、ジョブのステータスに対して問合せができます。

5. ジョブのランタイム・ステータスを表示するには、そのbatchID値をstatusコマンドまたはその別名のstsに渡します。

- sts batch-2

次のような出力が表示されます。

ID         Name                   State         Rows Errors Restarts
--         ----                   -----         ---- ------ --------
batch-2    MyBatchJob1            Running      4,500      0        0

SubmitDateTime     WaitTime     RunTime      Group    Server
--------------     --------     ------       -----    ------
06/24/08-10:25:37  0m, 0s       0m, 0s       Default  RTDServer

しばらくしてからstatusコマンドを実行すると、ジョブが50,000人分の顧客を9分44秒で処理し、エラーを発生することなく終了したことが表示されます。

ID         Name                   State         Rows Errors Restarts
--         ----                   -----         ---- ------ --------
batch-2    MyBatchJob1            Finished    50,000      0        0

SubmitDateTime     WaitTime     RunTime      Group    Server
--------------     --------     ------       -----    ------
06/24/08-10:25:37  0m, 0s       9m, 44s      Default  RTDServer

16.3.2.2 ジョブの順次実行

ジョブが発行されて開始すると、並行処理グループに割り当てられます。特に指定がない場合は、Defaultという名前のデフォルト並行処理グループが割り当てられます。同じ並行処理グループ内のジョブは、発行された順に一度に1つずつ順番に実行されます。したがって、1番目のジョブが終了する前に2番目のジョブを開始した場合、2番目のジョブは1番目のジョブが終了するまで待機します。ここでは、MyBatchJob1バッチを開始してから、MyBatchJob2とMyBatchJob3のジョブを開始します。MyBatchJob1を開始する前に、sapコマンドを使用して、rowsBetweenStatusUpdatesとsqlCustomersのパラメータにパラメータ値が設定されていることを確認します。

MyBatchJob1を開始した後、removeAddedPropsコマンド(rap)を使用してこれらのパラメータをクリアします。これによって、次の2つのジョブは、すべてのパラメータでデフォルト値が使用されます。jobsコマンドで、実行中および待機中のジョブのすべてについて簡単なステータスを表示します。1番目のジョブが実行中で、他の2つのジョブが待機中であることが表示されます。

command: batchNames
MyBatchJob1
MyBatchJob2
MyBatchJob3
MyBatchJob4
MyBatchJob5
command: showAddedProps
Property                       Value
--------                       -----
rowsBetweenStatusUpdates       1500
sqlCustomers                   SELECT Id FROM Customers
command: start MyBatchJob1
batchID=batch-3
command: removeAddedProps
command: start MyBatchJob2
batchID=batch-4
command: start MyBatchJob3
batchID=batch-5
command: jobs
ID         Name          State    Group    Server
--         ----          -----    -----    ------
batch-3    MyBatchJob1   Running  Default  RTDServer
batch-4    MyBatchJob2   Waiting  Default  none
batch-5    MyBatchJob3   Waiting  Default  none

16.3.2.3 ジョブの並行処理

startInGroupコマンドまたはその別名のstartgを使用すると、ジョブを特定の並行処理グループに割り当てることができます。2つのジョブを別々のグループで開始すると、これらを同時に実行できます。

例:

command: startg MyBatchJob4 myGroup1
batchID=batch-6
command: startg MyBatchJob5 myGroup2
batchID=batch-7
command: jobs
ID         Name           State    Group     Server
--         ----           -----    -----     ------
batch-6    MyBatchJob4    Running  myGroup1  RTDServer
batch-7    MyBatchJob5    Running  myGroup2  RTDServer

注意:

同じ並行処理グループに割り当てられるジョブは異なるサーバー上で実行する場合がありますが、並行して実行できません。異なるグループ内のジョブのみが、並行して実行できます。

17 外部化されたオブジェクト管理

この章では、Oracle RTDの基本要素で使用できる拡張機能について説明するとともに、拡張機能を定義して複合的な意思決定プロセスにおいて使用する方法と、対応する外部アプリケーションに拡張機能を統合する方法について説明します。

Oracle RTDは、ビジネス・プロセス・トランザクションの実行時にそのトランザクションからリアルタイムで継続的に学習するプロセスにより、適応型のエンタープライズ・ソフトウェア・ソリューションを実現します。リアルタイムで継続的に学習することで、適応型のソリューションは、各トランザクションと関連ビジネス・プロセスの結果を最適化できます。Oracle RTDのデシジョン・プロセスの基本フレームワークは、次のとおりです。

- Oracle RTDでは各相互作用に対して分析的なデシジョンを作成します。

- ルールと予測モデルに基づき、Oracle RTDデシジョンでリアルタイムのデータと履歴データを使用して、様々な選択肢から最適な提案を作成します。

- 最適な提案の作成に際して、潜在的に競合するビジネス目標における最適化をOracle RTDで行います。

第13章「デシジョン・スタジオの要素とAPIについて」の説明のとおり、Oracle RTDインライン・サービスの構成要素はすべて、デシジョン・スタジオを使用して構成されます。本番環境で変更を加える場合は、作業内容によってデシジョン・スタジオまたはデシジョン・センターのいずれかを使用できます。また、Oracle RTDプラットフォームでは、いくつかの主要構成要素が、外部アプリケーションと統合可能な外部オブジェクトとして公開されています。このため、Oracle RTDの作業とオブジェクトを既存のアプリケーションによって管理できます。Oracle RTDは引き続き意思決定エンジンとして機能しますが、管理は他の既存のビジネス・ツールによって行われます。

次の図では、Oracle RTDの意思決定プロセスのフレームワークを形成する標準要素が示されています。また、外部アプリケーションとOracle RTDが連携して、エンド・ユーザーに対して複合的なデシジョン・サービスを実現するうえで重要な一連の入力も示されています。

Oracle RTDの意思決定プロセスの標準要素(デシジョン、エンティティ、選択肢、ルール、モデルおよびパフォーマンス目標)は、デシジョン・スタジオで定義されます。これらの要素の概要は、第12章「デシジョン・スタジオについて」と第13章「デシジョン・スタジオの要素とAPIについて」を参照してください。

Oracle RTDは、外部のコンテンツ管理システムで保持される選択肢など、外部データ・システムのオブジェクトにリアルタイムで変更を適用できます。

Oracle RTDを使用するアプリケーションにより、ルールの作成や変更を行ったり、デシジョン・プロセス全体の導出と制御を行うパフォーマンス目標を変更することで、ユーザーが重要な変更を即座に意思決定プロセスに加えることができます。

この章では、Oracle RTDの基本要素に対してこのような拡張機能を定義し、複合的な意思決定プロセスにおいて使用する方法と、対応する外部アプリケーションにこれらを統合する方法について説明します。

この章には次のトピックが含まれます:

- 第17.1項「動的選択肢」

- 第17.2項「外部ルール」

- 第17.3項「動的選択肢および外部ルールを使用したエンドツーエンド開発の例」

- 第17.4項「外部化されたパフォーマンス目標の重み付け」

17.1 動的選択肢

Oracle RTDにおいて、選択肢は代替案の母集団を表します。これらから、抱合せ販売アプリケーションにおける最適なオファーなどの提案を選択できます。

選択肢には、静的選択肢と動的選択肢があります。

静的選択肢の場合、リクエスト元アプリケーションまたは自己学習モデルに提示される選択肢は、Oracle RTD内で完全に定義されます。静的選択肢は、選択肢が既知の場合と、一定期間にわたって一定の場合に役に立ちます。

動的選択肢は、実行時に動的に構築される選択肢です。この選択肢は通常、外部データ・ソースに保持されます。これにより、オファー管理システムで定義したオファーに基づく選択肢など、ソース・システムで選択肢を管理できます。

注意:

動的選択肢の主要ソースが外部データ・ソースの場合でも、カスタマイズされたJavaコードで動的選択肢を作成できます。

アプリケーションに提示される動的選択肢は時間の経過に応じて変化する場合がありますが、常にアプリケーション・データの最新状態が反映されます。動的選択肢の内容が更新されたときにOracle RTDインライン・サービスを再デプロイする必要はありません。

注意:

この項では動的選択肢に焦点を絞りますが、選択肢グループは静的選択肢と動的選択肢を組み合せて構成できます。

デシジョンは、選択肢グループにどの種類の選択肢が含まれているかに関係なく、1つ以上の選択肢グループに関連付けることができます。

この項には次のトピックが含まれます:

- 第17.1.1項「動的選択肢の簡単な例」

- 第17.1.2項「動的選択肢の基本設計の概要」

- 第17.1.3項「単一データ・ソースからの複数カテゴリの動的選択肢」

- 第17.1.4項「動的選択肢の外部データ・ソースの前提条件」

- 第17.1.5項「デシジョン・スタジオにおける動的選択肢の設定の概要」

- 第17.1.6項「動的選択肢のデータ・ソースの作成」

- 第17.1.7項「動的選択肢の単一エンティティの作成」

- 第17.1.8項「動的選択肢のセット・エンティティの作成」

- 第17.1.9項「動的選択肢のデータ取得関数の作成」

- 第17.1.10項「選択肢グループの設計に関する考慮事項」

- 第17.1.11項「単一カテゴリの選択肢グループの作成」

- 第17.1.12項「複数カテゴリの選択肢グループの作成」

- 第17.1.13項「動的選択肢のレポートの概要」

17.1.1 動的選択肢の簡単な例

簡単な例として、図17-1のInsurance_Proposals表で説明します。この表はOracle RTD環境の外部で定義され、Oracle RTDが評価して優先度を設定する選択肢に関する情報を保持しています。

Insurance_Proposals表には、様々な保険商品を示す行があり、ChoiceGroupId列のInsuranceProducts共通値で識別されます。動的選択肢をカテゴリ化したりグループ化する列は、動的選択肢を設定する際に重要な必須キー識別子です。

グループにある各行は、AutoInsuranceやDisabilityInsuranceなど、様々な種類の提供対象保険商品を示しています。この各行が動的選択肢に相当します。

1つの列を使用して、グループ内で特定の動的選択肢を識別します。この例では、ChoiceID列が動的選択肢の識別列です。

表の他の列(ProfitMarginなど)は、Oracle RTDによって評価プロセスで使用できます。これらの列も、定義された選択肢属性の値として、提案される動的選択肢の一部としてアプリケーションに送信できます。

図17-1 Insurance_Proposals表の保険商品

要約すると、Oracle RTDにおける設定プロセスとは、動的選択肢に対して選択肢グループを設定し、その選択肢グループを必要な外部データ・ソースまたは外部ソースに関連付けることです。これにより、動的選択肢はOracle RTDによって提案可能になります。

対応する選択肢グループで十分な数の提案を作成してモデルを更新した後は、図17-2に示すように、デシジョン・センターにより様々な動的選択肢のパフォーマンスを分析できます。

図17-2デシジョン・センターによる動的選択肢の保険商品の分析

17.1.2 動的選択肢の基本設計の概要

動的選択肢の基本的な設計プロセスは、静的選択肢の場合と同様です。最初に選択肢グループを設定してから、選択肢グループの動的選択肢で必要な要素とパラメータを定義する必要があります。設定方法の詳細は、第17.1.5項「デシジョン・スタジオにおける動的選択肢の設定の概要」を参照してください。

この項では、Insurance_Proposalsの例を使用して、設計プロセスの概要を説明します。また、設計プロセスで使用される主な用語についても次に示します。

- すべての動的選択肢のセットは、グループ化列またはカテゴリ化列に共通値を持つすべての行と識別されます。Insurance_Proposalsの例では、カテゴリ化列(またはセット識別子)はChoiceGroupId列です。

- データベース・セットの各行は、1つの動的選択肢を表します。Insurance_Proposalsの例では、動的選択肢自体がChoiceId列の一意の値によって識別されます。

- Oracle RTDで動的選択肢の選択肢グループを定義する場合、動的選択肢が格納されている行のセットにグループをリンクする必要があります。

- Oracle RTDで選択肢グループ内の動的選択肢を定義する場合、グループ内の各動的選択肢を、データ・ソース内の対応する動的選択肢の単一行にリンクする必要があります。

17.1.3 単一データ・ソースからの複数カテゴリの動的選択肢

最も単純な動的選択肢では、データベース表のすべての行が同じカテゴリに属します。つまり、カテゴリ化列の値がすべて同じです。

同じデータベース表や各種データ・ソースから、異なる動的選択肢を渡すことができます。図17-3に示されている次の例では、Insurance_Proposals表が拡張され、保険商品と保険サービスの両方について選択肢が用意されています。

図17-3 Insurance_Proposals表の保険商品と保険サービス

この場合、Oracle RTDで2つの選択肢グループを設定し、どちらのデータセットもアプリケーションで提案できるようにします。

対応する選択肢グループで十分な数の提案を作成してモデルを更新した後は、保険商品または保険サービス(あるいはその両方)の動的選択肢のパフォーマンスを分析できます。

たとえば、図17-4に示すように、デシジョン・センターにおいて選択肢グループをグループ階層で2つのグループとして設定すると、分析に使用できます。

図17-4デシジョン・センターの選択肢グループ

保険商品の分析結果は、図17-2の結果と同じです。図17-5は、保険サービスに関して同等の分析レポートを示しています。

図17-5デシジョン・センターによる動的選択肢の保険サービスの分析

17.1.3.1 同一データ・ソース内に異なる動的選択肢カテゴリがある場合

選択肢グループは選択肢とは異なり、事前に定義する必要があります。つまり、選択肢グループは静的です。レポートやデシジョンの要件をサポートするために必要な場合、動的選択肢を個々の選択肢グループにグループ化できます。

各選択肢グループの設計に関する考慮事項と対象コンポーネントは、第17.1.2項「動的選択肢の基本設計の概要」に説明されているとおりです。

選択肢グループの設定方法の概要は、第17.1.5項「デシジョン・スタジオにおける動的選択肢の設定の概要」を参照してください。

同じデータ・ソースから異なる選択肢グループを設定する方法の詳細は、第17.1.12項「複数カテゴリの選択肢グループの作成」を参照してください。

17.1.4 動的選択肢の外部データ・ソースの前提条件

動的選択肢に必要なデータは、外部のデータ・ソースにあります。

説明を単純にするために、次の説明では、外部データ・ソースがコール元アプリケーションのデータベース表またはビューであると仮定します。

動的選択肢にとって有用にするには、データに次の列が含まれている必要があります。

- データのカテゴリ化と抽出で使用する列が1列
動的選択肢が1つの場合は、カテゴリ化列に同じ値を持つ行がすべて抽出され、この列を使用して抽出を制御します。

例:

- データベース表のSpecial_EventsにEvent_Type列があります。

- Event_Typeの値は、すべての行でPromotion、Product_Launch、Mailshotのいずれかです。

この例では、Event_Typeがカテゴリ化列で、動的選択肢が1つの場合、1つのイベント・タイプの行がすべて(すべてのPromotion行など)、Oracle RTDで抽出されます。

- 特定の動的選択肢用に抽出される行を一意に識別する列が1列
この列の値はすべての行で一意にする必要はありません。抽出されたデータセット内でのみ一意となります。

抽出されたデータ内で一意な識別子を提供する列であれば、どの列でもかまいません。この列の値には、なんらかのテキスト文字列を含めることをお薦めします。この値は、デシジョン・センター・レポートでヘッダーとして表示されるため、現実の世界で意味を持つ識別子のほうが、数値だけの識別子より有用です。

注意:

識別子の列に格納できるのは、英数字の値と空白文字のみです。特殊文字は格納できません。

図17-6は、動的選択肢のデータ・ソースとして使用可能な、Web Offersデータベース表の例です。

図17-6 外部データベース表の例

この表には、次の特徴があります。

- カテゴリ化列はCategoryで、すべてのCategory列の共通値はDynamicOffersCGです。

- Name列またはID列を、DynamicOffersCGカテゴリの動的選択肢の識別子列として選択できます。

17.1.5 デシジョン・スタジオにおける動的選択肢の設定の概要

注意:

設定プロセスを示す図およびデシジョン・スタジオの画面ショットが、動的選択肢に関連して後述する各項に記載されていますが、それらはOracle RTDとともにリリースされるDC_Demoインライン・サービスに基づいています。

デシジョン・スタジオで動的選択肢を設定するプロセスの内容は、次のとおりです。

- 第17.1.6項「動的選択肢のデータ・ソースの作成」

- 第17.1.7項「動的選択肢の単一エンティティの作成」

- 第17.1.8項「動的選択肢のセット・エンティティの作成」

- 第17.1.9項「動的選択肢のデータ取得関数の作成」

- 第17.1.10項「選択肢グループの設計に関する考慮事項」

- 第17.1.11項「単一カテゴリの選択肢グループの作成」

- 第17.1.12項「複数カテゴリの選択肢グループの作成」

図17-7は、動的選択肢に対して単純な単一カテゴリの選択肢グループを設定する方法の概要を示しています。図の中の要素については、この章の以降の詳細なプロセス説明の中で説明します。

図17-7 単一カテゴリの動的選択肢を設定するプロセスの概要

17.1.6 動的選択肢のデータ・ソースの作成

動的選択肢のデータ・ソースを作成する手順は次のとおりです。

1. 「インポート」ボタンを使用して外部データ・ソースをポイントします。第17.1.4項「動的選択肢の外部データ・ソースの前提条件」で説明した表にマップする新しいデータ・ソースが作成されます。

2. 「出力」列領域で、「複数の行を許可」チェック・ボックスを選択し、動的選択肢に必要なすべての列を選択します。
「入力」列領域で、動的選択肢行をカテゴリ化しグループ化する共通値を含む列を選択します。

注意:

この段階で、「出力」列から動的選択肢の識別子列を選択する必要はありません。

図17-8は、データ・ソースのWeb Offers DSを表のSDDS.WEBOFFERSから設定する方法を示しています。ここでは、Categoryが入力識別子で、他のいくつかの列は動的選択肢自体の属性となります。

図17-8 Web Offers DSデータ・ソースの定義

17.1.7 動的選択肢の単一エンティティの作成

動的選択肢のデータは、データ・ソース内にあります。Oracle RTDでは、カテゴリ自体の情報ではなく、特定のカテゴリに関連するすべての情報で構成されるように動的選択肢の単一エンティティを作成する必要があります。

作成したデータ・ソースでは、そのデータ・ソースの出力属性が動的選択肢の単一エンティティのエンティティ属性になります。

動的選択肢の単一エンティティを作成する手順は次のとおりです。

1. 「インポート」機能を使用して、動的選択肢データのエンティティを作成します。これによって、第17.1.4項「動的選択肢の外部データ・ソースの前提条件」で説明したデータ・ソースのすべての「出力」列が取り込まれます。

2. データ・ソースを選択する場合、インポート時に表示される「選択」ウィンドウの「選択したデータ・ソースのデータ・マッピングのビルド」オプションの選択が解除されていることを確認します。

図17-9は、動的選択肢の単一エンティティであるWeb Offersを設定する「定義」タブを示しています。属性は、データ・ソースであるWeb Offers DSの「出力」列です。

図17-9 Web Offersエンティティの定義

17.1.8 動的選択肢のセット・エンティティの作成

動的選択肢の単一エンティティに加えて、動的選択肢のセット・エンティティを作成する必要があります。このセット・エンティティには、次の属性を含めます。

- Key属性: データ・ソースの入力でありカテゴリ化列になります。これには、動的選択肢のデータが含まれます。

- 配列属性: 動的選択肢の単一エンティティのデータが格納されます。
この配列属性は、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティと同じエンティティ・タイプである必要があります。この配列は、動的選択肢で必要なデータ・ソースから抽出されるデータの、カテゴリ化属性を除くすべての属性のコンテナです。

動的選択肢のセット・エンティティを作成する手順は次のとおりです。

1. Oracle RTDでエンティティを作成します。

2. Key属性の場合は、「キーの追加」をクリックし、データ・ソースから動的選択肢のカテゴリ化属性を選択します。

3. 属性を作成し、そのタイプを第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前にします。

4. このエンティティ・タイプ属性を、「配列」として選択します。
図17-10は、動的選択肢のセット・エンティティであるWeb Offers Listを設定する「定義」タブを示しています。Key属性はデータ・ソースであるWeb Offers DSの「入力」列のCategoryで、2番目の属性はWeb Offersタイプの配列属性です。

図17-10 動的選択肢のセット・エンティティであるWeb Offers Listの定義

5. 「マッピング」タブをクリックし、エンティティ・タイプ属性内の各属性を、元のデータ・ソースで適切な列にマップします。

6. 「データ・ソース入力値」領域で、データ・ソースの入力値として、手順2で作成した動的選択肢カテゴリ化属性を選択します。
図17-11は、動的選択肢のセット・エンティティであるWeb Offers Listを設定する「マッピング」タブを示しています。配列属性内の各属性は、Web Offers DSデータ・ソース内の対応する列にマップされます。「データ・ソース入力値」領域で、入力値に対して選択された属性は、Key属性のCategoryです。

図17-11 Web Offers ListエンティティでのWeb Offers属性のマッピング

7. 「キャッシュ」タブをクリックします。

8. 「このエンティティ・タイプのキャッシングの有効化」チェック・ボックスを選択します。

注意:

動的選択肢のセット・エンティティでは、キャッシュを有効にすることが重要です。キャッシュを有効にすると、新しいセッションのたびにデータ・ソースから動的選択肢を繰り返し取得する状態がReal-Time Decision Serverで回避されます。

17.1.9 動的選択肢のデータ取得関数の作成

データベースから動的選択肢データを抽出するには、データ取得を行う関数を作成する必要があります。この関数は、この後の手順で作成する選択肢グループによってコールされます。関数の特徴は次のとおりです。

- 関数では値を返します。

- 戻り値は配列型です。

- 配列要素のデータ型は、前に作成した動的選択肢の単一エンティティです。

- 前に作成した動的選択肢のセット・エンティティのデータ・ソース入力値と同じパラメータを関数では持ちます。

- 関数のロジックによって動的選択肢のセット・エンティティの新しいインスタンスが作成され、パラメータを使用して、動的選択肢データを配列に取得します。

動的選択肢のデータ取得関数を作成する手順は次のとおりです。

1. 関数を作成し、「戻り値」チェック・ボックスを選択します。

2. 「配列」オプションを選択して、戻り値が配列型であることを指定します。

3. 「データ型」で、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前を選択します。

4. 「パラメータ」領域で、第17.1.8項「動的選択肢のセット・エンティティの作成」の手順2で作成したKey属性の「名前」と「タイプ」を追加します。

5. 「ロジック」フィールドで、次のようなコードを入力します。エンティティと属性の名前は、必要に応じて変更します。

WebOffersList list = new WebOffersList();
list.setCategory(category);
return list.getWebOffers();

ここで:

- WebOffersListは、第17.1.8項「動的選択肢のセット・エンティティの作成」で作成したエンティティのオブジェクト名で、単語と単語との間の空白が削除されています。

- list.setCategoryでは、第17.1.8項「動的選択肢のセット・エンティティの作成」の手順2で作成したエンティティ・キーを参照します。

- getWebOffers()では、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティを参照します。これは、動的選択肢のセット・エンティティ内でマップされているエンティティです。
図17-12は、GetWebOffers関数の定義を示しています。

図17-12 GetWebOffers関数の定義

17.1.10 選択肢グループの設計に関する考慮事項

アプリケーション・データの管理者は、動的選択肢によって、Oracle RTDがアプリケーションに提案する選択肢を制御できます。静的選択肢とは異なり、動的選択肢は、Oracle RTDインライン・サービスとのインタフェースを変更することなく、アプリケーション表において追加、編集および削除ができます。

1つのインライン・サービスで両方の種類の選択肢を使用する必要がある場合、選択肢グループを設計する際に、静的選択肢と動的選択肢を明確に分けることをお薦めします。この項では、動的選択肢の選択肢グループの設計についてのみ説明します。

動的選択肢は次の場所に設計できます。

- 単一の選択肢グループ内

- 完全に別個の選択肢グループ内 - つまり、独立した単一選択肢グループの集まり

- 選択肢グループ階層内

設計に影響を及ぼす要因は数多く存在します。例:

- 動的選択肢の明示的なセットに関して、顧客が選択肢グループのレポートを必要とするレポート要件がある場合

- 他のセットとは異なり動的選択肢の1つのセットに、共有される適格性ルールを適用する必要があるデシジョン要件がある場合

この項では、単一の選択肢グループおよび選択肢グループ階層で必要で高レベルな設計手順を示します。

単一の選択肢グループ

すべての動的選択肢を1つの選択肢グループにまとめる必要がある場合、次の方法で設計することをお薦めします。

1. 1つの選択肢グループを設計します。

2. 選択肢グループの「グループ属性」タブ、「選択肢属性」タブおよび「動的選択肢」タブで、必要なパラメータを入力して選択します。

デシジョン・スタジオでは、この選択肢グループにはサブグループがありません。

選択肢グループ階層

設計要件によっては、動的選択肢を選択肢グループ階層にグループ化する場合があります。次の手順は、2レベル階層の設定の概要を示しています。

1. 最上位レベルの選択肢グループの場合、「選択肢属性」タブで、必要なパラメータを入力して選択します。「グループ属性」タブと「動的選択肢」タブでは設定しません。

2. 個々の動的選択肢カテゴリについて、1つ下のレベルの選択肢グループを指定します。下位レベルの各選択肢グループの場合、「グループ属性」タブと「動的選択肢」タブで、必要なパラメータを入力して選択します。「選択肢属性」タブは設定しません。

注意:

複数レベルの選択肢グループ階層の最下位レベルの選択肢グループでは、「動的選択肢」タブのパラメータのみ入力する必要があります。

デシジョン・スタジオでは、下位レベルの選択肢グループにはサブグループがありません。

17.1.11 単一カテゴリの選択肢グループの作成

動的選択肢を使用するには、1つ以上の選択肢グループを作成する必要があります。動的選択肢が参照するデータが1つのタイプまたはカテゴリに属している場合、単一カテゴリの選択肢グループを作成します。

注意:

デシジョン・スタジオで動的選択肢の選択肢グループを作成する場合、デシジョン・スタジオのどのウィンドウにも個々の動的選択肢は表示されません。

デシジョン・センターのレポートでは、次の条件を満たす動的選択肢をすべて表示できます。

- フロントエンド・アプリケーションがコールしたデシジョンから返されている。

- その選択肢に対してRTDモデルが更新されている。

デシジョン・スタジオでは、次のタブで設定するオプションを介して、選択肢が実行時に動的に抽出できるように選択肢グループを構成します。

- 「グループ属性」タブ

- 「選択肢属性」タブ

- 「動的選択肢」タブ

動的選択肢を構成するタブは、主にこれらのタブです。

注意:

「選択肢の適格性」タブを使用して、データ・ソースから抽出する際に動的選択肢データのフィルタリングもできます。

動的選択肢に対して作成される適格性ルールは、同じ動的選択肢グループで取得されるすべての選択肢で共有されます。

図17-13は、単一カテゴリの選択肢グループであるDynamic Offersを設定するのに必要な主要要素の例を示しています。

グループ属性の設定は、動的選択肢として取得されるすべてのデータが1つのカテゴリにのみ属していることを表します。ここでは、正確なカテゴリを指定する必要があります。

選択肢属性の設定は、取得される個々の属性を指定します。

グループ属性と選択肢属性は、この単一カテゴリ選択肢グループの「動的選択肢」タブで参照されます。

図17-13 選択肢グループのDynamic Offersの定義

17.1.11.1 「グループ属性」タブ

「グループ属性」タブでは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティ・タイプの配列属性を指定します。単一カテゴリの動的選択肢の設定プロセスに関する概要を示す 図17-7では、この属性は動的選択肢の配列エンティティに対応します。

このレベルでは、動的選択肢データを取得する関数も指定します。関数のパラメータ値を選択する必要があります。これにより、現実世界に対応し1つの具体的なタイプやカテゴリに関連する動的選択肢データのみを関数で取得できます。

選択肢グループを作成しグループ属性を指定する手順は次のとおりです。

1. 選択肢グループを作成します。

2. 「グループ属性」タブをクリックします。

3. 新しいエンティティ・タイプのグループ属性(動的選択肢の配列エンティティ)を作成し、そのタイプを、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前にします。

4. この属性を「配列」として指定します。

5. 「値」ボックスの右端をクリックして省略記号(...)ボタンを表示します。次に、その省略記号ボタンをクリックして「値」ウィンドウを開きます。

6. 「値」ウィンドウで、「全体的な配列の値」オプションを選択します。

7. 「値ソース」で、「関数またはルール・コール」を選択し、第17.1.9項「動的選択肢のデータ取得関数の作成」で作成した関数を選択します。

8. 「パラメータ」領域の「値」でパラメータ値を選択し、入力属性にこの値が含まれるデータ・ソースの対応行が取得されるようにします。

注意:

「値」のこの文字列は、選択肢グループのすべての動的選択肢行をカテゴリ化する、データベース内の値と同じです。

たとえば、第17.1.1項「動的選択肢の簡単な例」で説明したようにInsurance_Proposals表の選択肢グループの設定では、この値はInsuranceProductsです。

図17-14は、選択肢グループであるDynamic Offersの「グループ属性」タブを示しています。コールする関数はGetWebOffersです。「パラメータ」領域の「値」には、文字列のDynamicOffersCGが指定されています。

図17-14 選択肢グループであるDynamic Offersのグループ属性の定義

17.1.11.2 「選択肢属性」タブ

「選択肢属性」タブでは、次を行う必要があります。

- 第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティと同じタイプのエンティティ・タイプ属性を指定します。
この属性は、単一カテゴリの動的選択肢の設定プロセスに関する概要を示す図17-7では、動的選択肢の行エンティティに対応します。

- この動的選択肢の行エンティティ内のコンポーネント属性ごとに、個々の選択肢属性を作成します。作成したばかりの動的選択肢の行エンティティ内の対応属性にこれをマップする必要があります。

選択肢グループの選択肢属性を指定する手順は次のとおりです。

1. 「選択肢属性」タブをクリックします。

2. 新しいエンティティ・タイプの属性(動的選択肢の行エンティティ)を作成します。そのタイプは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前です。

3. 「配列」チェック・ボックスの選択が解除されていることを確認します。

4. 新しい動的選択肢の行エンティティの各属性に対して、対応する選択肢属性を作成します。

5. 前の手順で作成した各選択肢属性について、手順2で作成した動的選択肢の行エンティティ内の対応する属性にその値をマップします。
図17-15は、選択肢グループであるDynamic Offersの「選択肢属性」タブを示しています。選択肢属性は次のとおりです。

- 1つの動的選択肢行エンティティであるWeb Offer Entity

- 複数の他の属性: それらの各値は、動的選択肢行エンティティであるWeb Offer Entityの対応属性から導出されます。

図17-15 選択肢グループであるDynamic Offersの選択肢属性の定義

17.1.11.3 「動的選択肢」タブ

「動的選択肢」タブでは、次の情報を指定します。

- 動的選択肢の選択肢グループとして、この選択肢グループを明示的に選択します。

- 対応する「グループ属性」タブと「選択肢属性」タブで設定したグループ属性と選択肢属性を指定します。

- 各動的選択肢を識別する属性を選択します。

- デシジョン・センターのレポートで動的選択肢をどのように表示するかを指定します。動的選択肢の数が多い場合、動的選択肢の長いリストをより小さな単位(つまり、フォルダ)に分割できます。その際、フォルダにおいてデータをグループ化する方法を指定します。

動的選択肢のパラメータを指定する手順は次のとおりです。

1. 「動的選択肢」タブをクリックします。

2. 「この選択肢グループの動的選択肢の使用」チェック・ボックスを選択します。

3. 「選択肢のエンティティのリストが含まれるグループ属性」で、第17.1.11.1項「「グループ属性」タブ」で作成した動的選択肢の配列属性を選択します。

4. 「エンティティ・データを割り当てる選択肢属性」で、第17.1.11.2項「「選択肢属性」タブ」で作成した動的選択肢の行属性を選択します。

5. 「選択肢のIDが含まれるエンティティ属性」で、抽出される動的選択肢行ごとに一意な識別子である属性を選択します。

注意:

識別子の列に格納できるのは、英数字の値と空白文字のみです。特殊文字は格納できません。

6. 「選択肢グループ・フォルダに対する選択肢の分布モード」で、「オーバーフロー」または「偶数」を選択します。

注意:

このパラメータと次の手順のパラメータの詳細は、第17.1.13.4項「デシジョン・センター・フォルダ間での選択肢の分散」を参照してください。

7. 「デシジョン・センター上の1つの選択肢グループ・フォルダ内の選択肢の最大数」を選択します。

図17-16 選択肢グループの動的選択肢パラメータの定義

17.1.12 複数カテゴリの選択肢グループの作成

動的選択肢を使用するには、1つ以上の選択肢グループを作成する必要があります。同じデータ・ソースから異なるグループのデータを選択できる必要がある場合、複数カテゴリの選択肢グループを作成します。この項では、複数カテゴリの選択肢グループを設定する一般的方法について説明します。

注意:

デシジョン・スタジオで動的選択肢の選択肢グループを作成する場合、個々の動的選択肢は表示されません。

デシジョン・センターのレポートでは、次の条件を満たす動的選択肢をすべて表示できます。

- フロントエンド・アプリケーションがコールしたデシジョンから返されている。

- その選択肢に対してOracle RTDモデルが更新されている。

デシジョン・スタジオでは、次のタブで設定するオプションを介して、選択肢が実行時に動的に抽出できるように選択肢グループを構成します。

- 「グループ属性」タブ

- 「選択肢属性」タブ

- 「動的選択肢」タブ

動的選択肢を構成するタブは、主にこれらのタブです。

注意:

「選択肢の適格性」タブを使用して、データ・ソースから抽出する際に動的選択肢データのフィルタリングもできます。

動的選択肢に対して作成される適格性ルールは、同じ動的選択肢グループで取得されるすべての選択肢で共有されます。

複数の動的選択肢カテゴリを使用するには、選択肢グループの階層を作成し、異なるレベルで選択肢グループの要素を設定する必要があります。

図17-17は、2つのカテゴリを持つ選択肢グループであるIncentive Choicesを設定するのに必要な主要要素の例を示しています。

図17-17 選択肢グループ階層の定義例

選択肢グループのIncentive Choicesは親選択肢グループで、DiscountsおよびGiftsという2つの子選択肢グループを持ちます。

最上位レベルの選択肢属性は親選択肢グループで指定します。この選択肢属性は、2つの子選択肢グループに継承されます。

注意:

親選択肢グループの場合、または複数レベルの選択肢グループ階層の上位レベル・グループの場合、「動的選択肢」タブで値の入力や選択は行いません。動的選択肢パラメータは、選択肢グループ階層の最下位レベルのグループに対してのみ指定します。

それぞれの子選択肢グループにグループ属性を設定すると、異なるカテゴリのデータセットを取得できます。どちらの子選択肢グループの「動的選択肢」タブでも、グループ属性と選択肢属性が参照されます。

このプロセスと、同等な単一カテゴリの選択肢グループの設定を比較するには、図17-7を参照してください。

17.1.12.1 親選択肢グループの「選択肢属性」タブ

「選択肢属性」タブでは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したものと同じタイプのエンティティ・タイプの選択肢属性を指定します。

この選択肢属性は、図17-7に示されている同等な単一カテゴリの動的選択肢の設定プロセスと同様、動的選択肢の行エンティティとも呼ばれています。

この動的選択肢行エンティティ内の属性ごとに、個々の選択肢属性を作成します。これを、作成した動的選択肢行エンティティ内の対応属性にマップする必要があります。

親選択肢グループおよび選択肢属性を作成する手順は次のとおりです。

1. 親選択肢グループを作成します。

2. 「選択肢属性」タブをクリックします。

3. 新しいエンティティ・タイプの選択肢属性を作成します。そのタイプは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前です。

4. 「配列」の選択が解除されていることを確認します。

5. 新しいエンティティ・タイプの選択肢属性の各属性について、対応する選択肢属性を作成します。

6. 前の手順で作成した各選択肢属性について、手順2で作成した選択肢属性内の対応属性にその値をマップします。

17.1.12.2 子選択肢グループの「グループ属性」タブ

「グループ属性」タブでは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したものと同じタイプのエンティティ・タイプの配列属性を指定します。

このグループ属性は、図17-7に示されている同等な単一カテゴリの動的選択肢の設定プロセスと同様、動的選択肢の配列エンティティとも呼ばれています。

このレベルでは、動的選択肢データを取得する関数も指定します。関数のパラメータ値を選択する必要があります。これにより、現実世界に対応し1つの具体的なタイプやカテゴリに関連する動的選択肢データのみを関数で取得できます。

前に作成した親選択肢グループの下に子選択肢グループを最初に作成してから、必要な要素を「グループ属性」タブで入力する必要があります。

子選択肢グループおよびグループ属性を作成する手順は次のとおりです。

1. 第1の子選択肢グループを作成します。

2. 動的選択肢カテゴリごとに1つの子選択肢グループを、必要に応じて追加作成します。
それぞれの子選択肢グループでは、必要な要素とパラメータを「グループ属性」タブと「動的選択肢」タブで設定する必要があります。

この項の以降の手順では、それぞれの子選択肢グループの「グループ属性」タブで必要な操作について説明します。それぞれの子選択肢グループの「動的選択肢」タブで必要な操作の詳細は、第17.1.12.3項を参照してください。

3. 子選択肢グループの「グループ属性」タブをクリックします。

4. 新しいエンティティ・タイプのグループ属性を作成します。そのタイプは、第17.1.7項「動的選択肢の単一エンティティの作成」で作成したエンティティの名前です。

5. この属性を「配列」として指定します。

6. 「値」ボックスの右端をクリックして省略記号(...)ボタンを表示します。次に、その省略記号ボタンをクリックして「値」ウィンドウを開きます。

7. 「値」ウィンドウで、「全体的な配列の値」オプションを選択します。

8. 「値ソース」で、「関数またはルール・コール」を選択し、第17.1.9項「動的選択肢のデータ取得関数の作成」で作成した関数を選択します。

9. 「パラメータ」領域の「値」でパラメータ値を選択し、入力属性にこの値が含まれるデータ・ソースの対応行が取得されるようにします。

17.1.12.3 子選択肢グループの「動的選択肢」タブ

それぞれの子選択肢グループの「動的選択肢」タブでは、次の情報を指定する必要があります。

- 動的選択肢の選択肢グループとして、この選択肢グループを明示的に選択します。

- 対応する「グループ属性」タブと「選択肢属性」タブで設定したグループ属性と選択肢属性を指定します。

- 各動的選択肢を識別する属性を選択します。

- デシジョン・センターのレポートで動的選択肢をどのように表示するかを指定します。動的選択肢の数が多い場合、動的選択肢の長いリストをより小さな単位(つまり、フォルダ)に分割できます。その際、フォルダにおいてデータをグループ化する方法を指定します。

動的選択肢のパラメータを指定する手順は次のとおりです。

1. 「動的選択肢」タブをクリックします。

2. 「この選択肢グループの動的選択肢の使用」チェック・ボックスを選択します。

3. 「選択肢のエンティティのリストが含まれるグループ属性」で、第17.1.12.2項「子選択肢グループの「グループ属性」タブ」で作成した属性を選択します。

4. 「エンティティ・データを割り当てる選択肢属性」で、第17.1.12.1項「親選択肢グループの「選択肢属性」タブ」で作成した属性を選択します。

5. 「選択肢のIDが含まれるエンティティ属性」で、抽出される動的選択肢行ごとに一意な識別子である属性を選択します。

注意:

識別子の列に格納できるのは、英数字の値と空白文字のみです。特殊文字は格納できません。

6. 「選択肢グループ・フォルダに対する選択肢の分布モード」で、「オーバーフロー」または「偶数」を選択します。

注意:

このパラメータと次の手順のパラメータの詳細は、第17.1.13.4項「デシジョン・センター・フォルダ間での選択肢の分散」を参照してください。

7. 「デシジョン・センター上の1つの選択肢グループ・フォルダ内の選択肢の最大数」を選択します。

17.1.13 動的選択肢のレポートの概要

この項には、次の項目が含まれます。

- 第17.1.13.1項「静的選択肢のみのアプリケーション」

- 第17.1.13.2項「動的選択肢の表示」

- 第17.1.13.3項「システム生成の範囲フォルダ」

- 第17.1.13.4項「デシジョン・センター・フォルダ間での選択肢の分散」

- 第17.1.13.5項「動的選択肢のデシジョン・センター・レポートの例」

17.1.13.1 静的選択肢のみのアプリケーション

静的選択肢のみを使用するようにアプリケーションが構成されている場合、デシジョン・センターのレポートへの影響はありません。図17-18の例に示すように、デシジョン・センター・ナビゲータには、デシジョン・スタジオで定義した選択肢グループ、サブグループおよび静的選択肢が同じ階層レイアウトで表示されます。

図17-18 静的選択肢のみによる定義とレポートの例

17.1.13.2 動的選択肢の表示

動的選択肢はその性質上、デシジョン・スタジオで事前に定義できません。動的に抽出された外部データを保持するように選択肢グループを構成し、そこから動的選択肢を提案できます。図17-19は、保険サービスの動的選択肢を表示するように設定された選択肢グループの例を示しています。

図17-19 動的選択肢グループの定義例

デシジョン・センターでは、実際に提案されモデルの学習データに追加された動的選択肢のみがデシジョン・センター・ナビゲータに表示され、パフォーマンス・レポートと分析レポートが生成されます。

デシジョン・センターでの動的選択肢の表示に影響する別の要因は、動的選択肢グループを定義する際に指定する「デシジョン・センター上の1つの選択肢グループ・フォルダ内の選択肢の最大数」パラメータです。選択肢の数がこの最大値を超えた場合、選択肢はシステム生成の範囲フォルダの下に表示されます。最大値を超えない場合、選択肢グループ名の直下に表示されます。

範囲フォルダの詳細は、第17.1.13.3項「システム生成の範囲フォルダ」を参照してください。

図17-20のDecision Supportナビゲータ・メニューの例では、次のように表示されています。

- モデルの学習データに5つの動的選択肢が提案され追加されています。

- 選択肢グループ当たりの選択肢の最大数は3です。

- それぞれの動的選択肢は、2つのシステム生成フォルダ名のいずれかに表示されます。

図17-20デシジョン・センターにおける動的選択肢のレイアウト例

17.1.13.3 システム生成の範囲フォルダ

各システム生成フォルダの名前は、そのフォルダ内の最初と最後の選択肢の名前を文字列(...)で区切った名前になります。システム生成フォルダは、範囲フォルダとも呼ばれています。

注意:

範囲フォルダには、静的選択肢と動的選択肢を混在できます。したがって、範囲フォルダ名を構成する2つの要素は、静的選択肢と動的選択肢のどちらでもかまいません。

通常、静的選択肢と動的選択肢は、個別の選択肢グループまたは個別の選択肢グループ階層に保存することをお薦めします。

選択肢の総数(静的選択肢およびモデル学習データに提案および追加された動的選択肢)が、選択肢グループ・フォルダに定義した最大値を超えた場合、選択肢はシステム生成のグループまたはサブフォルダに表示されます。最大値を超えない場合は、選択肢グループ名の直下に表示されます。

17.1.13.4 デシジョン・センター・フォルダ間での選択肢の分散

デシジョン・スタジオで動的選択肢の選択肢グループを構成する場合、デシジョン・センターでの選択肢の表示方法に影響するパラメータは2つあります。

どちらのパラメータも「動的選択肢」タブにあり、動的選択肢での選択肢グループの使用を選択した場合のみ有効化されます。パラメータは次のとおりです。

- 選択肢グループ・フォルダに対する選択肢の分布モード

- デシジョン・センター上の1つの選択肢グループ・フォルダ内の選択肢の最大数

説明を簡略化するために、この項ではこれらのパラメータをそれぞれDistribution modeとMaximum number of choicesで表します。

Maximum number of choicesパラメータは、デシジョン・センターにおいて、選択肢グループ名の直下またはシステム生成の範囲フォルダの下で、選択肢がどのように表示されるかを決定します。範囲フォルダの詳細は、第17.1.13.3項「システム生成の範囲フォルダ」を参照してください。

注意:

デシジョン・センターのレポートでは、範囲フォルダは静的選択肢専用または動的選択肢専用ではありません。つまり、同じ範囲フォルダに静的選択肢と動的選択肢の両方が混在して表示される場合があります。

Maximum number of choicesパラメータにより、静的選択肢または動的選択肢に関係なく、各範囲フォルダ内の選択肢の数を制限します。

Distribution modeパラメータにより、範囲フォルダへの移入方法を指定します。

- 「オーバーフロー」モードでは、各範囲フォルダに最大数の選択肢が配分されます。最後の範囲フォルダには、通常、最大数より少ない選択肢が配分されます。

- 「偶数」モードでは、範囲フォルダ全体に選択肢が均等に配分されます。

たとえば、デシジョン・センターに表示される静的選択肢と動的選択肢の総数が106個で、範囲フォルダ当たりの最大数が25個であると仮定します。

- 「オーバーフロー」モードの場合、各範囲フォルダの配分数は25、25、25、25、6になります。

- 「偶数」モードの場合、各範囲フォルダの配分数は22、21、21、21、21になります。

17.1.13.5 動的選択肢のデシジョン・センター・レポートの例

デシジョン・センターを使用して、コンテンツ・データベースに定義されている各動的選択肢のレポートを表示できます。これらの動的選択肢は、モデル学習データに実際に提案され追加されたものです。これを行うには、デシジョン・センターのインライン・サービスにログインし、デシジョン・センター・ナビゲータ内で「デシジョン・プロセス」セクションを開きます。

ここには、定義されている動的選択肢グループが一覧表示され、各動的選択肢グループに対してデータベース表内で定義されているすべての動的オファーが含まれます。それらは、モデル学習データに提案され追加されたものです。データベース表内の選択肢でモデル学習データに追加されなかったものは、デシジョン・センター・レポートに表示されません。

次の図はデシジョン・センター・レポートの例で、ナビゲータ・ツリーにはDC_Demoの動的選択肢が表示されています。

17.2 外部ルール

Oracle RTDに統合されたアプリケーションを実行しているエンド・ユーザーは、外部ルールにより、実行時にインライン・サービスを再コンパイルすることなく、ルール・ロジックを変更できます。これにより、ユーザーのコンテンツが存在する既存のシステムでOracle RTDのルールを管理できます。また、ルール管理プロセスでのみOracle RTDに有効な属性が公開されます。

一般的に、選択肢の適格性ルールや選択肢グループの適格性ルールなど、特定のルールを動的選択肢にアタッチし、インライン・サービスを再コンパイルせずに実行時に変更する必要がある場合に使用されます。

外部ルールは、静的選択肢にもアタッチできます。

この項には次のトピックが含まれます:

- 第17.2.1項「外部ルールの概要」

- 第17.2.2項「外部ルール・エディタの構成要素」

- 第17.2.3項「外部ルール・エディタのデプロイメント・トポロジ」

- 第17.2.4項「外部ルール・エディタの作成およびデプロイ手順」

- 第17.2.5項「外部ルール・エディタ・インタフェースの要件」

- 第17.2.6項「外部ルール・フレームワーク」

- 第17.2.7項「デシジョン・スタジオにおける外部ルールの設定」

- 第17.2.8項「外部インタフェースおよび埋込みルール・エディタの設定」

17.2.1 外部ルールの概要

外部ルール機能の主要コンポーネントは次のとおりです。

- 外部ルール・エディタ
Oracle RTDは、たとえばADFウィジェットまたはHTMLとJavaScriptコードを使用して、顧客のフロントエンド型Webベース・アプリケーションにプラグインできる埋込み可能なルール・エディタ・ウィジェットを備えています。

- 外部ルール・フレームワーク
外部ルール・フレームワークは、次のもので構成されています。

- 外部ルール関数
コールして外部ルールを評価できるルール評価関数をデシジョン・スタジオでユーザーが指定します。関数には、選択肢ルールを評価する関数、選択肢グループ・ルールを評価する関数、フィルタリング・ルールを評価する関数およびスコアリング・ルールを評価する関数の4種類があります。

- 外部ルール・キャッシュ
外部ルール・キャッシュは、外部ルール評価のパフォーマンスを向上するために用意されています。

キャッシュされているルールの新バージョンが評価を目的として発行された場合、失効バージョンは実行されません。ルールのキャッシュ・ミスによりリクエスト全体がタイムアウトになることを防止するために、Oracle RTDには、インライン・サービスの開発者に対して、即時に返すデフォルト・レスポンスを指定するためのメカニズムがあります。

- 外部ルールAPI
Oracle RTDには、外部ルールに関するJava APIのセットが用意されています。これらは、デシジョン・スタジオのJava関数およびロジック・セクションで使用できます。

外部ルールのプロセスの概要

図17-21は、ルールの編集と評価における外部ルールのプロセス・フローを示しています。

図17-21 外部ルールのプロセス・フロー

外部ルールは、外部コンテンツ・リポジトリにメタデータ形式で格納されます。これはどのような外部データ・システムでもかまいませんが、通常はデータベースです。コンテンツ管理サーバーにより、外部コンテンツ・リポジトリに格納されているルールへの読取りアクセスと書込みアクセスを制御します。

ビジネス・ユーザーは、コンテンツ管理製品によって用意されているサード・パーティ製外部インタフェースに埋め込まれたOracle RTDルール・エディタによりルールを編集します。

外部インタフェースが動的に設定するコンテキストの中で、埋込みルール・エディタでルールを編集する必要があります。たとえば、特定のグループの選択肢、選択肢グループまたはフィルタリング・ルールにルールをアタッチできます。

ルール・エディタで、ビジネス・ユーザーはルールの作成と編集を行います。これらのルールは、動的選択肢、関数、セッション属性など、インライン・サービスで定義されるすべてのオブジェクトを参照できます。

ユーザーがルール・エディタでのルール編集を終了した後、ルールのメタデータは外部インタフェースに渡され、そこから外部コンテンツ・リポジトリに保存されます。

実行時に、インライン・サービスは、外部コンテンツ・リポジトリから編集済の外部ルールにアクセスします。

DC_Demoインライン・サービス・ヘルパー・ファイルの外部インタフェースの例

サード・パーティ製外部インタフェースの出発点として、DC_Demoインライン・サービスには外部ルールのデプロイ・ヘルパーJSPファイルがOracle RTDに付属しています。

このヘルパーの設定方法および使用方法の詳細は、第17.3項「動的選択肢および外部ルールを使用したエンドツーエンド開発の例」を参照してください。

17.2.2 外部ルール・エディタの構成要素

この項では、外部ルール・エディタの主な構成要素と、そのデプロイメントに必要な外部(Oracle RTD以外)の構成要素を図17-22に示します。

図17-22 外部ルール・エディタの主な構成要素

次の各項で、各構成要素とその主な機能について説明します。

- 第17.2.2.1項「外部ルール・エディタと外部ルール・エディタ・クライアント」

- 第17.2.2.2項「Oracle Web Service Manager (OWSM)」

- 第17.2.2.3項「セキュリティ」

- 第17.2.2.4項「ワークベンチWebサービス」

17.2.2.1 外部ルール・エディタと外部ルール・エディタ・クライアント

外部ルール・エディタと外部ルール・エディタ・クライアントの主な機能は次のとおりです。

- 外部ルール・エディタはADFコンポーネントとしてラップされており、構築用アプリケーションでOracle Application Development Frameworkと一緒に使用できます。JDeveloper拡張として使用できるので、簡単に外部ルール・エディタをADFアプリケーションに統合できます。

- 外部ルール・エディタ・クライアントは外部ルールをレンダリングします。

- ユーザーは、外部ルール・エディタ・クライアントでルールを更新できます。

- ルールは更新時に検証されます。
無効なルールをユーザーが保存できないようにするのは、コンテナ・アプリケーションの責任です。

つまり、ユーザーは無効なルールを保存できます。RTD Serverは、外部ルールのロード時にその有効性を確認する必要があります。

外部ルール・エディタ・クライアントでは、無効なルールをユーザーがデータベースの表行に保存できます。RTD Serverはそのルールを初めてロードするときに、ルールを検証します。検証に失敗すると、そのルールを無効としてマークします。そのルールを参照するインライン・サービスは、無効なルールの例外の処理方法に従ってその無効なルールを処理します。

- 外部ルール・エディタ・クライアントは、旧リリースのOracle RTDにおける静的なルール・エディタと同じ機能をサポートしています。

- ユーザーは、リソース・ファイルを手動で更新してラベルをカスタマイズできます。アプリケーション開発者は、リソース・バンドルのベース名を属性値として提供する必要があります。

17.2.2.2 Oracle Web Service Manager (OWSM)

Oracle Web Services Manager (OWSM)は、セキュリティ・ポリシーの設定と資格証明またはSAMLトークンの検証を担当します。

詳細は、『Oracle Fusion Middleware Webサービスの紹介』と『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

17.2.2.3 セキュリティ

セキュリティの主な2つの要素は認証と認可です。

認証は、コンテナUIが担当します。コンテナ・ベースの認証またはアプリケーション・レベルの認証を使用できます。

認可は、ロールと権限によって実装されます。JDeveloperで、アプリケーション開発者は外部ルール・エディタへのアクセス権を持つアプリケーション・ロールを定義できます。外部ルール・エディタへのアクセス権が持つロールは、デプロイ時やデプロイ後にも定義できます。

実行時に、ユーザーがコンテナ・アプリケーションのUIにログオンすると、そのユーザーが外部ルール・エディタへのアクセス権を持っている場合にかぎり、外部ルール・エディタがレンダリングされます。

17.2.2.4 ワークベンチWebサービス

ワークベンチは、外部ルールから参照できるインライン・サービスのすべての要素(エンティティ、セッション・オブジェクト、選択肢、選択肢グループ、関数など)をフェッチする役割を果たします。

外部ルール・エディタ・クライアントとRTD Serverの間のやり取りは、Webサービスを介して行われます。クライアント・アプリケーションのテクノロジ・スタックに応じて、Webサービスの呼出しはJRFテクノロジ・スタックをベースにすることも、SAAJを使用することもできます。

Oracle Web Services Managerによってエンドポイントを保護できます。これは、ワークベンチ・サービスでは必須です。

サーバー側のエンドポイントでは、2種類のセキュリティ・ポリシーを定義できます。ユーザー名トークンとSAMLです。セキュリティ管理者は、Oracle Web Services Managerを使用して、Oracle RTD Workbench Webサービスにセキュリティ・ポリシーを適用できます。

クライアント側のセキュリティは、クライアント・コードで定義されます。このポリシーは、ワークベンチのエンドポイントでサポートされているポリシーと一致する必要があります。アプリケーション開発者は、デプロイ時にこのポリシーを指定します。

サポートされている2種類のポリシーについて:

- ユーザー名トークンは、ユーザーに対してユーザー名とパスワードの入力を要求します。外部ルール・エディタの呼出しで資格証明を提供する必要があります(資格証明はValueBinding言語で提供できます)。

注意:

プロパティ・ファイルは外部ルール・エディタの範囲外です。プロパティ・ファイルを使用するアプリケーション開発者は、プロパティ・ファイルの管理およびアクセスについて責任を負います。

- SAMLの場合、FusionクライアントとFusion Webサービスのエンドポイント間でSAMLトークンを自動的に伝播する役割をコンテナが果たします。

Fusion以外のOracle RTDクライアントでサポートできるのは、ユーザー名トークンによる認証のみです。SAMLはサポートできません。

ワークベンチWebサービスを保護するセキュリティ・ポリシーは無効にしないことをお薦めします。

Webサービスの呼出しでは、SOAP over HTTPまたはSOAP over HTTPSを使用します。

17.2.3 外部ルール・エディタのデプロイメント・トポロジ

通常、Oracle RTDの外部ルール・エディタは、Oracle Fusion Middlewareの内側と外側を問わず、複数のアプリケーション・サーバーにデプロイできます。

注意:

この項では、Oracle Fusion MiddlewareでサポートされているWebLogicアプリケーション・サーバーについて重点的に説明します。

この項では、Oracle RTDの外部ルール・エディタでサポートされる一連のトポロジの例を示します。

WebLogicドメインとは、管理サーバーで管理されるリソースおよびサービスの論理的な集まりです。こうしたリソースは管理対象サーバー上で実行でき、クラスタ化トポロジで構成可能です。

特に指定のないかぎり、この項で示すドメインはすべて、Oracle Fusion MiddlewareにデプロイされたWebLogicドメインです。

ADFコンポーネント - 単純な単一ドメイン・デプロイメント

最も単純なデプロイメント・トポロジでは、図17-23に示すように、Oracle RTDの外部ルール・エディタをRTD ServerとともにBIドメイン内にデプロイします。

図17-23 ADFコンポーネント - 単純な単一ドメイン・デプロイメント

外部ルール・エディタをADFコンポーネントとして使用できるようにします。これにより、外部ルール・エディタを任意のADF UIに埋め込むことが可能になります。ワークベンチ・サービスのエンドポイントは、OWSMを使用したセキュリティ・ポリシー・セットによって保護されます。詳細は、付録B「Oracle RTD Webサービスおよびクライアント」を参照してください。

ADFコンポーネント - 複数ドメイン・シナリオ

図17-24に示すように、アプリケーションをRTD Serverドメインとは異なるドメインに配置できます。

図17-24 ADFコンポーネント - 複数ドメイン・シナリオ

ADFコンポーネント - 単一ドメイン・デプロイメント(JSPアプリケーションを使用)

図17-25では、ADFベースの外部ルール・エディタがJSPベースの使用側アプリケーションUIに組み込まれています。ADF外部ルール・エディタは、JSPアプリケーションを標準JSFコンポーネントに統合する場合と同じように統合できます。使用側UIは、ADFが正しくインストールされ構成されており、rtd-adf-rt.jarがインクルードされていることを必要とします。このトポロジで使用できるセキュリティ・ポリシーはユーザー名トークンのみです。このデプロイメント・トポロジにクロスサイト・スクリプティングは不要です。

図17-25 ADFコンポーネント - 単一ドメイン・デプロイメント(JSPアプリケーションを使用)

ADFコンポーネント - 複数ドメイン(JSPアプリケーションを使用)

図17-26に示すトポロジは、図17-25と似ていますが、使用側アプリケーションとADF外部ルール・エディタが別のドメインにデプロイされている点が異なります。このトポロジで使用できるセキュリティ・ポリシーはユーザー名トークンのみです。

図17-26 ADFコンポーネント - 複数ドメイン(JSPアプリケーションを使用)

デシジョン・センターの外部ルール・エディタ - 単一ドメイン・デプロイメント

図17-27では、使用側アプリケーションのHTML DIVタグ内にOracle RTDデシジョン・センター・バージョンの外部ルール・エディタが組み込まれています。このトポロジでサポートされているOWSMセキュリティ・ポリシーはありません。

使用側アプリケーションもOracle RTDデシジョン・センターも同じドメイン内にあるため、クロスサイト・スクリプティングは使用されません。

図17-27デシジョン・センターの外部ルール・エディタ - 単一ドメイン・デプロイメント

デシジョン・センターの外部ルール・エディタ - 複数ドメイン

図17-28に示すトポロジは図17-27のものに似ていますが、複数ドメインである点が異なります。このトポロジでは、使用側アプリケーションとOracle RTDデシジョン・センターへのリクエストがすべてプロキシ・サーバーを経由する場合を除き、クロスサイト・スクリプティングが使用されます。

図17-28デシジョン・センターの外部ルール・エディタ - 複数ドメイン

Oracle Fusion Middlewareでサポートされていないアプリケーション・サーバー下の外部ルール・エディタ

図17-29では、Oracle RTDの外部ルール・エディタはアプリケーションで使用されるか、アプリケーション・サーバーに常駐していますが、そのアプリケーションもアプリケーション・サーバーもOracle Fusion Middlewareでサポートされていません。ワークベンチWebサービスのエンドポイントは、Oracle Fusion Middleware下のWebLogicドメインにデプロイされています。図17-28のトポロジと同様に、プロキシ・サーバーを経由する場合以外は、クロスサイト・スクリプティングが使用されます。

図17-29 Oracle Fusion Middlewareでサポートされていないアプリケーション・サーバー下の外部ルール・エディタ

17.2.4 外部ルール・エディタの作成およびデプロイ手順

外部ルール・エディタを使用するための手順は、通常、次のとおりです。

1. 構築
外部ルール・エディタを組み込むUIを作成します。

2. 統合
コールバックを作成し、外部ルール・エディタとの間でパラメータ(値言語バインディング)をやり取りします。

3. パッケージ化
外部ルール・エディタを組み込んだアプリケーションを、JDeveloper環境またはJDeveloper以外の環境の必要なクラスとともにパッケージ化します。

4. デプロイ
同じWebLogicドメイン内または異なるWebLogicドメイン内の、RTD Serverと同じまたは異なるサーバーにデプロイします。

5. 保護
呼出し元の外部ルール・エディタ・クライアントとワークベンチ・サービス・エンドポイントの両方を保護します(該当する場合)。

これらの手順について、次の各項で詳しく説明します

17.2.4.1 構築

JDeveloperでは、ルール・エディタ・コンポーネントをJDeveloperプロジェクト内のJSFページにドラッグ・アンド・ドロップできます。

JDeveloperプロジェクトでルール・エディタADFコンポーネントを有効化してJSFページに追加する一般的な手順は、次のとおりです。

1. Oracle JDeveloperの「アプリケーション・ナビゲータ」プルダウン・ボックスで、「新規アプリケーション」を選択します。

2. アプリケーション名を指定し、「Fusion Webアプリケーション(ADF)」を選択して、「次へ」をクリックします。
これにより、2つのプロジェクトが作成されます。デフォルト名は「モデル」とビュー・コントローラですが、この名前をそのまま使用しても変更してもかまいません。以降の説明では、デフォルトのプロジェクト名を使用します。

3. 「次へ」を2度クリックしてビュー・コントローラ設定画面に移動します。

4. 「プロジェクト・テクノロジ」タブで、「RTD ADF」を「選択済」列へ移動し、「次へ」をクリックします。

5. 「終了」をクリックします。
これにより、空のプロジェクトが作成されます。

外部ルール・エディタADFコンポーネントをJSFページに配置する必要があります。

6. ビュー・コントローラ・プロジェクトを右クリックし、「新規作成」を選択します。

7. 「新規ギャラリ」ウィンドウの「カテゴリ」ペインで、「Web層」の下にある「JSF」を選択します。

8. 「アイテム」ペインで「JSFページ」を選択し、「OK」をクリックします。

9. JSFページのファイル名(例: ruledit.jspx)を入力し、「OK」をクリックします。
これにより、空のページが作成され、右側のペインに「コンポーネント・パレット」タブと「リソース・パレット」タブが表示されます。

10. 「コンポーネント・パレット」リストで任意のコンポーネント・エントリを右クリックし、「タグ・ライブラリの編集」を選択します。

11. RTD ADFコンポーネント11を「選択済のライブラリ」列に移動し、「OK」をクリックします。
これで、「コンポーネント・パレット」タブのプルダウン・リストにRTD ADFコンポーネントというエントリが追加されました。

12. 「コンポーネント・パレット」タブのプルダウン・リストでRTD ADFコンポーネントを選択します。
「コンポーネント・パレット」タブにルール・エディタ・コンポーネントが表示されます。これをJSFページにドラッグ・アンド・ドロップできます。

注意:

ルール・エディタをJSFページにドラッグ・アンド・ドロップしても、ページは空のままになります。ルール・エディタを他のアプリケーション・オブジェクトと完全に統合するには、JSFページの「ソース」にコードを入力します。詳細は、第17.2.4.2項「統合」を参照してください。

Oracle ADFを使用したエンタープライズ開発の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

JDeveloperを使用しない場合の手順は次のとおりです。

1. web.xmlにサーブレット・マッピングを追加します。

<servlet-mapping>
<servlet-name>resources</servlet-name>
<url-pattern>/rtd/*</url-pattern
</servlet-mapping>

2. JSPヘッダーにjstl名前空間を追加します。

xmlns:rtd="http://xmlns.oracle.com/rtd/faces/adf"

3. JSPヘッダーにルール・エディタ・タグを追加します。

<rtd:ruleEditor …

17.2.4.2 統合

表17-1に、ルール・エディタの設定パラメータを示します。JDeveloperでは、「ソース」ビューで外部ルール・エディタADFコンポーネントを選択すると、「プロパティ・インスペクタ」ウィンドウに次のパラメータがすべて表示されます。

表17-1 外部ルール・エディタの統合用パラメータ

名前

説明

inlineService

対象のインライン・サービス名。

sdoId

編集するOracle RTDオブジェクトのID。

sdoType

編集するOracle RTDオブジェクトのタイプ。

editingAspect

編集するOracle RTDオブジェクトの編集する側面。

rule

ルールxml。

inlineStyle

ルール・エディタのインラインcssスタイル。

rtdUrl

Oracle RTDサーバーのURL。

idPropagation

ID伝播を有効にするか無効にするかを指定します。

username

ワークベンチとインライン・サービスへのアクセス権を持つOracle RTDユーザーのID。ID伝播でのみ使用されます。

password

ユーザー・パスワード。ID伝播でのみ使用されます。

overrideMessages

Oracle RTDルール・エディタのデフォルト・メッセージをオーバーライドするリソース・バンドルのベース名。

partialTriggers

部分ページ・レンダリングをサポートするADF属性。

rendered

ルール・エディタのレンダリングを制御する設定条件。

workbenchClientType

JRF (デフォルト)、SAAJまたはRTD3のいずれかを指定します。

(RTD3は、サーバーがRTD 3.xサーバーの場合にのみ選択します)

また、ルール・エディタのイベントを通知するコールバックJS関数を指定する必要があります。

例

<rtd:ruleEditor id="rule1" inlineService="DC_DEMO" sdoId="AllOffersCG"
sdoType="choiceGroup" editingAspect="choiceRule"
rule="#{backbean.rule}"
inlineStyle="width:100%;height:280px;border:0;"
rtdUrl="http://localhost:8081/" idPropagation="true"
partialTriggers="clFiltering clGroup cbLoadRuleXml"
overrideMessages="override_rtd_resources">
<af:clientListener method="callbackFunction" type="callback"/>
</rtd:ruleEditor>

17.2.4.3 パッケージ化

JDeveloperプロジェクトの場合、RTD ADFコンポーネント11をjstlタグ・ライブラリにインポートする必要があります。JDeveloper以外のプロジェクトの場合、rtd-adf-rt.jarランタイム・ライブラリをWEB-INF/libフォルダにパッケージ化する必要があります。

17.2.4.4 デプロイ

プロジェクトをFusionターゲットまたはFusion以外のターゲットにデプロイできます。Fusionターゲットの場合、ADF Facesランタイム・ライブラリと構成をパッケージに含める必要があります。

17.2.4.5 セキュリティ

rendered属性を使用してルール・エディタを保護すると、許可されたユーザーのみに使用を限定できます。

Oracle RTDワークベンチ・サーバーにアクセスするSAMLトークン・ポリシーを使用する場合は。idPropagation属性を設定します。

Oracle RTDワークベンチ・サーバーに特定の資格証明でアクセスする場合は、username属性とpassword属性を使用します。

17.2.5 外部ルール・エディタ・インタフェースの要件

Oracle RTDは、外部ルールを編集するために埋込み可能なブラウザ・ユーザー・インタフェースを備えています。このルール・エディタ・ウィジェットには、デシジョン・スタジオに含まれているルール・エディタと同程度の機能が含まれています。

サード・パーティ製ユーザー・インタフェースと埋込みOracle RTDルール・エディタは、次の操作を実行できる必要があります。

- 外部ルール・メタデータを埋込みルール・エディタへロードする操作

- ロードされた外部ルール・メタデータを埋込みルール・エディタで編集する操作

- 埋込みルール・エディタにロードされたルールの新しいルール・メタデータを一意のIDとタイムスタンプでエクスポートする操作

- その中でルールを編集する必要があるコンテキストを動的に設定する操作。たとえば、特定のグループの選択肢、選択肢グループまたはフィルタリング・ルールにルールをアタッチできます。

- 埋込みルール・エディタによって発行された各アクションの後でコールされるユーザー定義型コールバックJavascript関数を設定する操作

- 編集された外部ルールが有効または変更されているかどうかを判定するJavascriptメソッドを提供する操作

17.2.6 外部ルール・フレームワーク

外部ルール・フレームワークは、3つのルール評価関数、外部ルール・キャッシュおよびJava APIのセットで構成されています。

この項には、次の項目が含まれます。

- 第17.2.6.1項「外部ルール評価関数」

- 第17.2.6.2項「外部ルール・キャッシュ」

- 第17.2.6.3項「外部ルールAPI」

- 第17.2.6.4項「外部ルール・エラーの処理およびロギング」

17.2.6.1 外部ルール評価関数

デシジョン・スタジオには、外部ルール・メタデータの評価に使用できるルール評価関数が4つあります。各関数は、渡された外部ルール・メタデータを、選択肢、選択肢グループ、フィルタリング・ルールまたはスコアリング・ルールに対して評価します。

外部ルールが正常に評価されると、対応する関数からブール値(適格性ルールおよびフィルタリング・ルール)またはdouble型の値(スコアリング・ルール)のどちらかが返されます。

4つの関数は次のとおりです。

- 外部ルール - 選択肢適格性ルールの評価

- 外部ルール - 選択肢グループ適格性ルールの評価

- 外部ルール - フィルタリング・ルールの評価

- 外部ルール - スコアリング・ルールの評価

表17-2は、これらの関数のパラメータを示しています。

注意:

適格性ルール関数では、パラメータの1つがルール評価のコンテキストを設定します。たとえば、外部ルール - 選択肢適格性ルール関数の「選択肢」パラメータでは、外部ルールの評価における特定の選択肢名を指定します。

表17-2 外部ルール関数のパラメータ

関数

パラメータ

説明

外部ルール - 選択肢適格性ルールの評価

ルール・メタデータ

外部ルールのメタデータ形式を含む属性

選択肢

外部ルールが評価される選択肢

戻り値

ルールが無効の場合のステータス

外部ルール - 選択肢グループ適格性ルールの評価

ルール・メタデータ

外部ルールのメタデータ形式を含む属性

選択肢グループ

外部ルールが評価される選択肢グループ

戻り値

ルールが無効の場合のステータス

外部ルール - フィルタリング・ルールの評価

ルール・メタデータ

外部ルールのメタデータ形式を含む属性

戻り値

ルールが無効の場合のステータス

外部ルール - スコアリング・ルールの評価

スコアリング・ルール・メタデータ

外部ルールのメタデータ形式を含む属性

デフォルト・スコア

ルールが無効の場合のデフォルト・スコア。デフォルトの戻り値は0。

外部ルール - 選択肢適格性ルールの評価および外部ルール - 選択肢グループ適格性ルールの評価のコール・テンプレートは、次のとおりです。

- Value of rule {0} evaluated in context of Choice {1}, {2} if rule is invalid

外部ルール - フィルタリング・ルールの評価のコール・テンプレートは、次のとおりです。

- Value of rule {0}, {1} if rule is invalid

外部ルール - スコアリング・ルールの評価のコール・テンプレートは、次のとおりです。

- Value of rule {0}, {1} if scoring rule is invalid

評価のブロック・オプション

各関数では、評価オプションを設定できます。

オプションの1つに、評価のブロックおよび非ブロックを制御するオプションがあります。評価のブロック・オプションを設定すると、Real-Time Decision Serverが評価結果とともに戻るのをルール評価のコール元では待機します。評価をブロックしない場合は、ルール評価のコール元にデフォルト値が返されます。

デフォルトでは、各外部ルール評価関数は、渡された外部ルール・メタデータを、非ブロック方式で評価します。デシジョン・スタジオ・ユーザーは、ブロック・オプションを設定した状態でルールを評価するように、選択した関数のJavaコードを編集することで、この動作を変更できます。

外部ルール関数の変更

外部ルール関数は、個々のインライン・サービスに合せて変更できます。考えられる変更の1つは、ルール評価のブロック動作の変更です。各関数は、渡されたルール・メタデータを、デフォルトでは非ブロック方式で評価します。ブロック動作、デフォルトの戻り値および例外をスローするかどうかを制御するAPIは、次のとおりです。

public class EvaluationOptions  {
public static EvaluationOptions getEvaluationOptions(
boolean defaultReturnValue,
boolean blockEvaluationUntilCached,
boolean propagateExceptions);
public static EvaluationOptions getEvaluationOptions(
double defaultReturnValue,
boolean blockEvaluationUntilCached,
boolean propagateExceptions);
}

外部ルール関数は、ルール定義の作成、ルール・エバリュエータとルール・キャッシュの取得、評価オプションの定義およびルールの評価を行うという点で、どの関数も似ています。これらの関数の違いは、それぞれの対象範囲と戻り値にあります。

- 対象範囲: 関数がスコアリング・ルールまたはフィルタリング・ルールとして評価するのか、選択肢または選択肢グループを対象にするのか。

- 戻り値: 適格性関数とフィルタリング関数はboolean型の値を返し、スコアリング関数はdouble型の値を返します。

注意:

旧バージョンのRuleEvaluatorインタフェースには、次のような戻り値がboolean型のevaluate()メソッドが用意されていました。

interface RuleEvaluator {
boolean evaluate( Object context,
RuleDefinition def,
RuleCache cache,
EvaluationOptions opts)
throws ValidationException, EvaluationException;
}

evaluate()から次のメソッドに置き換わりましたが、後方互換性を保つためにevaluate()はAPIに残されています。

interface RuleEvaluator {
boolean evaluateEligiblityRule(Object context,
RuleDefinition def,
RuleCache cache,
EvaluationOptions opts)
throws ValidationException, EvaluationException;}

スコアリング・ルールに対応するために、RuleEvaluatorインタフェースが拡張され、double型を返すevaluateScoringRule()メソッドが追加されました。

interface RuleEvaluator {
boolean evaluateScoringRule(Object context,
RuleDefinition def,
RuleCache cache,
EvaluationOptions opts)
throws ValidationException, EvaluationException;}

次の例は、選択肢の適格性評価関数(DC_Demoインライン・サービス)を詳細に示したものです。

//compile, cache and evaluate the eligibility rule and return a boolean
if (ruleMetadata == null || ruleMetadata.trim().equals(""))
return true;
RuleDefinition def      = new RuleDefinitionImpl(ruleMetadata);
RuleEvaluator evaluator = Application.getRuleEvaluator();
RuleCache cache         = Application.getRuleCache();

// public static EvaluationOptions getEvaluationOptions(
//                  boolean defaultReturnValue,
//                  boolean blockEvaluationUntilCached,
//                  boolean propagateExceptions)
// boolean defaultReturnValue: Return this value when rule evaluation fails
//                  with an exception or while the rule is being compiled
//                  during non-blocking evaluation
// boolean blockEvaluationUntilCached: Wait for the rule to be compiled before
//                  returning a value. (May cause integration point timeout)
// boolean propagateExceptions: Set to true if ILS developer decides to
//                  handle ValidationException and EvalutionException thrown by
//                  RuleEvaluator.evaluate() instead of returning defaultReturnVal

EvaluationOptions opts = EvaluationOptions.getEvaluationOptions(
returnValue, false, true);
/*
The evaluate method attempts to retrieve the compiled bytecode for the rule definition from the cache. If the bytecode for the rule is found in the cache, the rule is evaluated and the resulting boolean is returned. Otherwise, the rule is queued for compilation. Until the rule is compiled and cached, evaluate function behaves as specified by the EvaluationOptions.
*/
return evaluator.evaluateEligibilityRule(choice, def, cache, opts);

// parameters: ruleMetadata, choice
// return: boolean

次の例は、スコアリング評価関数(DC_Demoインライン・サービス)の対応する行(コメント行を除く)を詳細に示したものです。

if (ruleMetadata == null || ruleMetadata.trim().equals(""))
return defaultValue;
RuleDefinition def      = new RuleDefinitionImpl(ruleMetadata);
RuleEvaluator evaluator = Application.getRuleEvaluator();
RuleCache cache         = Application.getRuleCache();

EvaluationOptions opts = EvaluationOptions.getEvaluationOptions(
defaultValue, false, true);

return evaluator.evaluateScoringRule(def, cache, opts);

外部ルール関数のいずれかまたはすべてにおいて、getEvaluationOptionsコールのblockEvaluationUntilCachedパラメータとpropagateExceptionsパラメータを変更できます。

注意:

各外部ルール関数の変更は、インライン・サービス・レベルで影響します。

17.2.6.2 外部ルール・キャッシュ

Real-Time Decision Serverは、ルール評価のパフォーマンスを向上するために、外部ルール・キャッシュを備えています。各インライン・サービス・アプリケーションはそれぞれのルール・キャッシュを保持しており、各アプリケーション・ルール・キャッシュは、クラスタ内の各Real-Time Decision Serverにレプリケートされます。外部ルール・キャッシュ機能によって、次の追加機能が用意されています。

- ルール・キャッシュのメンテナンス操作
デシジョン・スタジオが用意しているメンテナンス操作関数を使用すると、ルール・キャッシュのサイズを決定したり、キャッシュをクリアできます。これらの関数は次のとおりです。

- 外部ルール - キャッシュのクリア

- 外部ルール - キャッシュ・サイズの取得

- 外部ルール - キャッシュされた非アクティブなルールの削除

これらの操作をOracle Fusion Middleware Enterprise ManagerなどのMBeanクライアントによって外部でトリガーして、Real-Time Decision Serverにデプロイされたインライン・サービスのキャッシュをクリアできます。各操作では、外部ルール・キャッシュのJava APIを使用して、インライン・サービスのルール・キャッシュをクリアしたり、ルール・キャッシュの現在のサイズ(バイト単位)を取得します。

- ルール評価の非ブロック
この機能により、キャッシュでルールが見つからないと、ルールの評価はブロックされません。1つのルールのコンパイルにかかる非常に短い時間の間、バックグラウンドでルールをコンパイルしながら、キャッシュされていない適格性ルールまたはフィルタリング・ルールに対してデフォルトのtrue/false値が返されます(または、キャッシュされていないスコアリング・ルールに対してデフォルトのスコアであるゼロが返されます)。

Enterprise Managerでのメンテナンス操作

外部ルール・キャッシュのメンテナンス操作は、Enterprise ManagerでMBean操作としてアクセスできます。これらのメンテナンス操作は、デプロイされたインライン・サービスごとに作成され、「MBean OracleRTD」→「InlineServiceManager」ツリー・パスにあります。次の図は、DC_Demo.DevelopmentのMBean操作を示しています。

17.2.6.3 外部ルールAPI

外部ルール・フレームワークは、外部ルール・キャッシュ機能とともに導入されたJava APIのセットを備えています。APIは次のJavaインタフェースで用意されており、デシジョン・スタジオのJava関数およびロジック・セクションで使用できます。

- Rule - 返されるルール・インスタンス。

- RuleDefinition - ユーザーによって作成されアプリケーションのルール・エバリュエータに渡されるルール定義。

- RuleCache - デプロイされたインライン・サービスによって保持され、インライン・サービスのアプリケーション・インタフェースを介して公開されるルール・キャッシュ。

- RuleEvaluator - デプロイされたインライン・サービスによって保持され、インライン・サービスのアプリケーション・インタフェースを介して公開されるルール・エバリュエータ。

- EvaluationOptions - ルール・エバリュエータに渡すことができるユーザー定義オプションのコレクション。これらのオプションには、ランタイム例外ポリシーのオプションとエバリュエータのオプションが含まれます。

また、これらのAPIインタフェースの使用時に、2種類の新しい外部ルール例外を検出できます。

- ValidationException - ルール・メタデータに問題があるためにルールをコンパイルできない場合にスローされます。

- EvaluationException - RuntimeExceptionでルールの実行が失敗したときにスローされます。

17.2.6.4 外部ルール・エラーの処理およびロギング

次の表は、外部ルール・エラーおよび対応するOracle RTD動作を示しています。動作は、外部ルールの評価関数を変更することで調整できます。

表17-3 外部ルール・エラーおよびOracle RTD動作

エラー・イベント

Oracle RTDアクション

ルール・コンパイル・エラー

- 解析不能なルール・メタデータ

- ルール・メタデータがスキーマに従っていない

- インライン・サービス属性参照の欠落またはスペルミス - Javaコンパイル・エラー

if (RuleCache.get(rule) == null) if (propagateExceptions && blockEvaluationUntilCached) /*これらの条件が成立する場合は原因の例外をValidationExceptionでラップしてスローし、ログには記録しない*/ else

log.ERROR /*原因のルール・メタデータおよび全体のスタック・トレース*/

else

if (propagateExceptions) /*この条件が成立する場合は一般的なValidationExceptionをスローする*/ else

log.ERROR /*1行の一般的なエラー・メッセージ*/

ルール実行エラー

- 参照されたインライン・サービス属性が実行時に初期化されない

- Rule.execute()のコール先によってスローされた他の例外

if (propagateExceptions) /*この条件が成立する場合は原因の例外をEvaluationExceptionでラップしてスローし、ログには記録しない*/

else

log.WARN /*原因の1行*/

ルールUUIDエラー

- 解析不能なUUID

- 解析不能なタイムスタンプ

- UUIDまたはタイムスタンプ(あるいはその両方)の欠落

if (propagateExceptions) /*この条件が成立する場合は原因とともにValidationExceptionをスローし、ログには記録しない*/

else

log.ERROR /*原因の1行*/

17.2.7 デシジョン・スタジオにおける外部ルールの設定

次の種類の外部ルールを設定できます。

- 選択肢グループの適格性ルール

- 選択肢の適格性ルール

- フィルタリング・ルール

- スコアリング・ルール

適格性ルールは、選択肢または選択肢グループの定義の一部として定義されます。フィルタリング・ルールとスコアリング・ルールはスタンドアロン・ルールで、他のOracle RTDオブジェクトとは独立して作成されます。作成したフィルタリング・ルールは、1つ以上のデシジョンにアタッチできます。作成したスコアリング・ルールは、選択肢属性または選択肢グループ属性にアタッチできます。

この項では、外部ルールの設定プロセスについて説明します。

この項の例は、Oracle RTDとともにリリースされているDC_Demoインライン・サービスに基づいています。

この項には次のトピックが含まれます:

- 第17.2.7.1項「前提条件 - 外部コンテンツ・リポジトリ内のオブジェクトの設定」

- 第17.2.7.2項「ルールのインライン・サービス・オブジェクトの定義」

- 第17.2.7.3項「インライン・サービス・オブジェクトの外部ルールの定義」

17.2.7.1 前提条件 - 外部コンテンツ・リポジトリ内のオブジェクトの設定

外部ルールのメタデータ・バージョンは、外部データ・ソースに格納されます。通常はデータベース表の列に格納されます。たとえば、WEBOFFERS表のEligibilityRuleMetadata列などです。

注意:

旧リリースでは、WEBOFFERS表の定義にEligibilityRuleMetadata列とScoringRuleMetadata列が含まれていませんでした。

これらの列がないWEBOFFERS表をご使用の場合は、initAppDBを実行してWEBOFFERSの定義とデータを修正してください。

詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のDC_Demoサンプル・データの移入に関する項を参照してください。

ルールが動的選択肢に関係する場合、関連する動的選択肢を、同じ外部データ・ソースの別の列に格納するのが普通です。動的選択肢関連の詳細は、第17.1.4項「動的選択肢の外部データ・ソースの前提条件」を参照してください。

たとえば、SDDS.WEBOFFERS表では、EligibilityRuleMetadata列とScoringRuleMetadata列に外部ルールのメタデータが格納され、Category列とId列は、動的選択肢の識別に使用されます。

17.2.7.2 ルールのインライン・サービス・オブジェクトの定義

インライン・サービスでは、外部オブジェクトを格納するデータ・ソースを定義してから、そのデータ・ソースに基づいてエンティティを定義します。

外部ルールを必要とする選択肢グループおよび選択肢では、適切なエンティティ属性から導出される選択肢属性を定義する必要があります。

例

ルールの設定の場合、Web Offers DSデータ・ソースはSDDS.WEBOFFERS表に基づき、Web Offers DSから導出されるWeb Offersエンティティは、Eligibility Rule MetadataとScoring Rule Metadataの2つの属性を含みます。

動的選択肢の設定の場合、Web OffersエンティティはIdを含み、Web Offers Listエンティティ(Web Offers DSから導出される)はCategory属性を含みます。

Dynamic Offers選択肢グループは、Rule MetadataやScoring Rule Metadataなどの選択肢属性のほかに、動的選択肢定義に必要な属性を含みます。

詳細は、第17.3項「動的選択肢および外部ルールを使用したエンドツーエンド開発の例」を参照してください。

17.2.7.3 インライン・サービス・オブジェクトの外部ルールの定義

デシジョン・スタジオで完全に定義され作成されるルールとは対照的に、外部ルールはその性質上、デシジョン・スタジオの外部で作成されます。ただし、次に示すように、オブジェクトに対してデシジョン・スタジオ内で適切なルール・エディタを起動することで、オブジェクトの外部ルールを定義する必要があります。

- 外部フィルタリング・ルールの場合は、フィルタリング・ルールを作成するか編集します。概要は、第13.9項「フィルタリング・ルール」を参照してください。

- 選択肢および選択肢グループの外部ルールの場合は、「選択肢の適格性」タブまたは「グループの適格性」タブを選択します。概要は、第13.8.5項「適格性ルールについて」を参照してください。

- 外部スコアリング・ルールの場合は、スコアリング・ルールを作成するか編集します。概要は、第13.10項「スコアリング・ルール」を参照してください。

どちらの場合も、ルールのブール文を編集する際、必要な外部ルール評価関数を最初に選択します。

- 外部ルール - 選択肢適格性ルールの評価

- 外部ルール - 選択肢グループ適格性ルールの評価

- 外部ルール - フィルタリング・ルールの評価

- 外部ルール - スコアリング・ルールの評価

次に、関数パラメータの値を選択するか入力します。

注意:

外部化されたフィルタリング・ルールおよびスコアリング・ルールは、外部ルール・エディタでの作成時や編集時に選択肢属性を直接参照できません。選択肢属性から値が取得されるセッション属性を参照します。

選択肢の適格性の例として、DC_Demoインライン・サービスの場合、Dynamic Offers選択肢グループの外部ルールは、次に示すように「選択肢の適格性」タブで定義しています。

DC_Demoインライン・サービスには、Dynamic Offers選択肢グループの外部スコアリング・ルールの例も含まれています。

「選択肢属性」タブでは、Dynamic Score選択肢属性の値が外部ルール - スコアリング・ルールの評価関数から導出されています。この関数のパラメータは、Scoring Rule MetadataおよびDefault Score選択肢属性です。

「スコア」タブでは、Offer Acceptanceパフォーマンス・メトリックのスコアがDynamic Score選択肢属性から導出されています。

外部ルール関数およびパラメータの詳細は、第17.2.6.1項「外部ルール評価関数」を参照してください。

17.2.8 外部インタフェースおよび埋込みルール・エディタの設定

サード・パーティ製外部インタフェース・エディタは、Oracle RTDに接続し、Oracle RTDに十分な情報を渡して、サード・パーティ製インタフェース内でルール・エディタを起動します。詳細は、第17.2.5項「外部ルール・エディタ・インタフェースの要件」を参照してください。

外部インタフェースと埋込みルール・エディタの設定を示している例は、DC_Demoインライン・サービスとともにリリースされる外部ルール開発ヘルパーに基づいています。このヘルパーを生成するファイルは、DC_Demoのdc/jspフォルダにあります。

この項には次のトピックが含まれます:

- 第17.2.8.1項「ルール・エディタ・ウィジェットの定義」

- 第17.2.8.2項「ルール・エディタのコンテキストと範囲の変更」

- 第17.2.8.3項「コールバック関数の定義」

17.2.8.1 ルール・エディタ・ウィジェットの定義

ルール・エディタは、ルール・エディタ・ウィジェット用に、サード・パーティ製エディタのHTML内にHTMLフォームを作成することで、サード・パーティ製インタフェースに埋め込むことができます。

フォームはアクションを/ui/workbenchに設定し、埋込みエディタを囲むフォームをHTML DIVタブ内に作成する必要があります。

注意:

クロスドメイン・アクションに対して、コンテンツが別のドメインに基づくフレームまたはウィジェットをJavascriptで操作することを防止するセキュリティ・メカニズムをWebブラウザは備えています。

クロスドメインの問題を解決する方法は次のとおりです。

- このクロスサイト・スクリプティング通信チャネルをバイパスするブラウザ・セキュリティを無効にする方法

- 外部エディタとウィジェットを同じサーバー上でホストする方法

- 2台のサーバーの前で、それぞれのURLを書き換えるプロキシを使用し、2台のサーバーが1台のサーバーであるかのようにブラウザに見せかける方法

表17-4は、各タイプのルールのパラメータを示しています。HTMLフォームは、表17-4に示されている各パラメータの値を使用して、フォーム入力を作成する必要があります。

表17-4 埋込みルール・エディタのパラメータ

パラメータ

説明

app

インライン・サービスの識別子。

url

sdo/editor.jsp

これは、エディタのjspファイルのURLです。

変更しないでください。

object

ルールを格納しているオブジェクトの識別子。詳細は、表17-5を参照してください。

type

ルールを格納しているオブジェクトの型。詳細は、表17-5を参照してください。

editingAspect

編集に関する側面。詳細は、表17-5を参照してください。

hideInheritedRules

継承されたルールを埋込みルール・エディタに表示しません。

callback

Javascriptコールバック関数の名前。エディタ・イベントが返されるたびに、この関数がコールされます。

表17-5は、ルール固有のパラメータのオプションを示しています。

表17-5 ルール固有のパラメータ・オプション

ルール・タイプ

object

type

editingAspect

グループの適格性ルール

グループ識別子

choiceGroup

rule

グループの選択肢の適格性ルール

グループ識別子

choiceGroup

choiceRule

選択肢の適格性ルール

選択肢識別子

choice

rule

フィルタリング・ルール

<このパラメータは省略します>

""またはeligibilityRule

whole

スコアリング・ルール

<このパラメータは省略します>

valueRule

rule

フォーム入力は、埋込みルール・エディタの初期コンテキストと範囲の作成に役立ちます。

例の詳細は、「DC_Demo外部ルール・ヘルパーでのルール・エディタの定義」を参照してください。

17.2.8.2 ルール・エディタのコンテキストと範囲の変更

埋込みルール・エディタのコンテキストと範囲も、Javascript関数で動的に変更できます。

例は、「DC_Demo外部ルール・ヘルパーでのルール・エディタのコンテキストと範囲の変更」を参照してください。

17.2.8.3 コールバック関数の定義

埋込みルール・エディタが返すイベントに応答するには、Javascriptコールバック関数を作成する必要があります。埋込みルール・エディタでは、1つのオブジェクト・パラメータでコールバック関数をコールします。このオブジェクトは、発生しているイベント・タイプを指定するtypeプロパティを常に持ちます。各イベント・タイプは、dataプロパティを使用して追加情報を渡す場合があります。

埋込みルール・エディタの現在の状態を表すイベントは、次のとおりです。

- editorReady
埋込みルール・エディタによって必要なルール処理が完了した後、editorReadyイベントが起動されます。

データ・オブジェクトのプロパティとして、以降のコールで使用できる関数が3つあります。

- ブール値を返すisValid()

- ブール値を返すisModified()

- 文字列値を返すgetXml()

- modified
modifiedイベントは、ルールの変更のたびにコールされます。dataプロパティは使用しません。

例の詳細は、「DC_Demo外部ルール・ヘルパーでのコールバック関数の定義」を参照してください。

17.3 動的選択肢および外部ルールを使用したエンドツーエンド開発の例

DC_DemoはOracle RTDとともにリリースされるインライン・サービスで、動的選択肢および外部ルールの設定方法と使用方法を示すものです。

次の各項では、Oracle RTDでDC_Demoが動的選択肢の外部ルールをどのように使用するか、そしてこれが完全なアプリケーション開発プロセスにどのように該当するかについて、その概要を説明します。

要約すると、この項で説明する主な開発手順は次のとおりです。

- 動的選択肢の適格性評価において、標準の外部ルール評価関数を使用します。

- インライン・サービスのWebページに外部ルール・エディタを埋め込みます。

- 動的選択肢のコンテンツ・データベースを統合します。

- 外部ルールを編集します。

- デシジョン・センターで動的選択肢のレポートを確認します。

この項には次のトピックが含まれます:

- 第17.3.1項「データベース・ドリブン型動的選択肢」

- 第17.3.2項「外部ルールの評価」

- 第17.3.3項「サード・パーティ製インタフェースへの外部ルール・エディタの埋込み」

- 第17.3.4項「DC_Demo外部ルール・デプロイメント・ヘルパー」

- 第17.3.5項「本番環境への外部ルールの送信」

- 第17.3.6項「動的選択肢のレポートの表示」

17.3.1 データベース・ドリブン型動的選択肢

動的選択肢は、コンテンツ管理サーバーで管理し、コンテンツ・データベースに格納できます。

DC_Demoインライン・サービスは、その動的選択肢のWebオファーを、WEBOFFERSという表から導出します。この表には次の列が表示されます。

- ELIGIBILITYRULEMETADATA: 選択肢の適格性評価で使用される外部ルール・メタデータが格納されています。

- SCORINGRULEMETADATA: スコアリング・ルールの評価で使用される外部ルール・メタデータが格納されています。

- CATEGORY: 親にあたる動的選択肢のIDを指定します。

注意:

旧リリースでは、WEBOFFERS表の定義にEligibilityRuleMetadata列とScoringRuleMetadata列が含まれていませんでした。

これらの列がないWEBOFFERS表をご使用の場合は、initAppDBを実行してWEBOFFERSの定義とデータを修正してください。

詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のDC_Demoサンプル・データの移入に関する項を参照してください。

データベースの列は、次の図に示すように、Web Offers DSデータ・ソースを介して、Oracle RTDエンティティ・オブジェクト属性にマップされます。

動的選択肢は、次のように2つのエンティティ・オブジェクトを作成することで設定されます。

- Web Offersエンティティには、1つの動的選択肢の属性情報が格納されます。

- Web Offers Listエンティティには、データベースによって取得される動的オファーのセットが格納され、動的選択肢の表情報を記述するデータソースにマップされます。

Dynamic Offers選択肢グループを作成し、その動的選択肢構成を有効にし、選択肢属性データの割当てにWeb Offersエンティティを使用することを設定します。

次の図は、Dynamic Offers選択肢グループの動的選択肢定義を示しています。

次の図は、Web Offersエンティティ属性にマップされる動的選択肢属性を示しています。Eligibility Rule MetadataとScoring Rule Metadataの2つの選択肢属性に注目してください。これらは、外部ルール・メタデータの格納に使用され、選択肢の適格性とスコアリングの評価に使用されます。

動的選択肢の設定方法の概要は、第17.1.5項「デシジョン・スタジオにおける動的選択肢の設定の概要」を参照してください。

17.3.2 外部ルールの評価

動的選択肢の適格性評価ルールは、デシジョン・スタジオで用意されている外部ルール評価関数を使用することで、動的選択肢属性にルール・メタデータとして格納されている外部ルールを参照できます。たとえば、動的選択肢グループのDynamic Offersは、次の図に示すように、外部ルール関数の外部ルール - 選択肢の適格性ルールの評価を使用します。

17.3.3 サード・パーティ製インタフェースへの外部ルール・エディタの埋込み

Oracle RTDの外部ルール・エディタは、動的選択肢の外部ルールを作成したり編集できるグラフィカル・ユーザー・インタフェースを備えています。

外部インタフェースにルール・エディタを埋め込む方法の概要は、第17.2.8.1項「ルール・エディタ・ウィジェットの定義」を参照してください。

要約すると、ルール・エディタを設定するフォームでは、次のフォーム入力を定義する必要があります。

- app - インライン・サービスの名前(DC_Demoなど)

- url - sdo/editor.jsp(エディタのjspファイルのURL)

- object - デフォルトの親インライン・サービス選択肢タイプ(AllOffersCGなど)

- type: エディタのデフォルト範囲(値: choiceGroup、choice、""はフィルタリング・ルールを表す)

- editingAspect: デフォルトの編集側面(値: choiceRule、rule、whole)

- hideInheritedRules: 継承されたルールを外部ルール・エディタに表示しません。

- callback - エディタ・イベントが返されるたびにコールされるJavascriptコールバック関数

フォーム入力は、埋込みルール・エディタの初期コンテキストと範囲の作成に役立ちます。

DC_Demo外部ルール・ヘルパーでのルール・エディタの定義

埋込みルール・エディタをDC_Demo外部ルール・エディタ・ヘルパーに統合する方法の例を次に示します。

<!--
form attributes:

name:   form name (i.e. editorViewForm)
target:   form iframe target name (i.e. editorViewIFrame)
method:   post (required)
action:   /ui/workbench (editor servlet url; required)

-->

<form name="editorViewForm" target="editorViewIFrame"
method="post" action="/ui/workbench">

<iframe frameborder="0" name="editorViewIFrame"/>

<!--
form inputs:

app:           inline service name (for example, DC_Demo)
url:           embedded editor url (a constant)
object:        parent dynamic choice group ID (for example, AllOffersCG)
type:          rule evaluation scope or context (for example, choiceGroup)
editingAspect: editor aspect view (for example, choiceRule)
callback:      javascript callback function (for example, callbackFunction)
-->

<input type=hidden name=app value=DC_Demo>
<input type=hidden name=url value=sdo/editor.jsp>
<input type=hidden name=object value=AllOffersCG>
<input type=hidden name=type value=choiceGroup>
<input type=hidden name=editingAspect value=choiceRule>
<input type=hidden name=hideInheritedRules value="true">
<input type=hidden name=callback value=callbackFunction>

</form>

DC_Demo外部ルール・ヘルパーでのルール・エディタのコンテキストと範囲の変更

埋込みルール・エディタのコンテキストと範囲も、Javascript関数で動的に変更できます。

DC_Demoにおいて、定義されているJavascript関数を使用してフォーム入力値を変更することで、ルール・エディタのコンテキストと範囲を動的に変更する方法の例を次に示します。

<!--
editorViewForm:                 name of the form containing the rule editor
editorViewForm.object:          ID of the choice or choice group context
editorViewForm.type:            scope or context type (for example, choiceGroup)
editorViewForm.editingAspect:   editor aspect view (for example, choiceRule)
-->

<script>
groupChoiceScope: function() {
editorViewForm.object.value = "DynamicOfferCG";
editorViewForm.type.value = "choiceGroup";
editorViewForn.editingAspect.value = "choiceRule";
loadRule();
}

</script>

DC_Demo外部ルール・ヘルパーでのコールバック関数の定義

Javascriptコールバック関数は、埋込みルール・エディタが返すイベントに応答します。返されるイベントには、埋込みルール・エディタの現在の状態を表すeditorReadyとmodifiedが含まれます。

DC_Demoのエディタ・ヘルパーのJavascriptコールバック関数であるcallbackFunctionの例を次に示します。この関数は、editorReadyイベントを起動した後に、isValidとisModifiedのブール値およびルール・メタデータをエディタから取得します。

<!--
event.type:               the event type name (for example, editorReady)
event.data.isValid:       the is valid rule return boolean
event.data.isModified:    the is modified rule return boolean
event.data.getXml:         returns the metadata of the rule in the editor
-->
<script>
callbackFunction: function(event) {
switch(event.type) {
case "editorReady":
isValid = event.data.isValid;
isModified = event.data.isModified;
getXml = event.data.getXml;
break;
case "modified":
log("is modified");
break;
default:
throw "unexpected callback event type: " + event.type;
}
}

</script>

17.3.4 DC_Demo外部ルール・デプロイメント・ヘルパー

Oracle RTDでは、DC_Demoインライン・サービスにおいて、external_rules_deployment_helper.jspおよびdatabase.jspという2つのファイルの形式で外部ルール・エディタ・ヘルパーが用意されています。これらは、デシジョン・スタジオ内では、dc/jspフォルダ・パスの下にあります。

このエディタ・インタフェースは、外部ルール・エディタ・ウィジェットをサード・パーティ製インタフェースに統合する方法の例として用意されています。このインタフェースを介して、ユーザーは、WEBOFFERSデータベース表に定義されている動的選択肢の外部ルールを編集できます。

DC_Demoエディタ・ヘルパーは、4つのセクションに分かれています。

- グラフィカル・ビューには、実際の外部ルール・エディタが含まれており、これを使用してルールを編集できます。

- メタデータ・ビューには、動的選択肢の表行に保存できる外部ルールのメタデータ・バージョンが格納されています。

- 表形式ビューはデータベース管理セクションで、ユーザーはこのセクションを使用して、WEBOFFERSデータベース表に格納されている動的選択肢の外部ルールを検索、編集および保存できます。

- 「ログ」セクションには、エディタ・ヘルパーで実行されるアクションが表示されます。

次の図はヘルパー・ウィンドウの例で、グラフィカル表示には編集されたルールが表示され、メタデータ・ビューには編集済のルール・メタデータが表示されています。

表形式ビューにはWEBOFFERSデータベース表の行が表示されます。重要な列は次のとおりです。

- CATEGORY: 動的選択肢グループのIDが格納されます。

- ELIGIBILITYRULEMETADATA

- SCORINGRULEMETADATA

グラフィカル・ビューのルール・エディタでルールを編集した後、ユーザーがメタデータの生成リンクをクリックすると、生成されたメタデータがメタデータ・ビューに表示されます。

17.3.5 本番環境への外部ルールの送信

外部ルール・エディタの主要な目的の1つは、更新された動的選択肢の外部ルールを本番環境に戻すことです。通常、サード・パーティのコンテンツ・データベースを使用して、動的選択肢およびその外部ルールを格納します。DC_Demoでは、WEBOFFERSという表に動的選択肢が格納されています。この表には、ELIGIBILTYRULEMETADATA列とSCORINGRULEMETADATA列があります。これらの列を使用して外部ルール・メタデータが格納されています。また、CATEGORYという別の列を使用して、親の動的選択肢グループのIDが格納されています。

動的選択肢表の行を選択し行の「保存」リンクをクリックすると、DC_Demo外部ルール・エディタ・ヘルパーでは外部ルールがデータベースに保存されます。

17.3.6 動的選択肢のレポートの表示

注意:

外部ルール・エディタでルールを編集した場合でも、デシジョン・センターにはデフォルトでは、動的選択肢のルールが表示されません。

デシジョン・センターを使用して、コンテンツ・データベースに定義されている各動的選択肢のレポートを表示できます。これらの動的選択肢は、モデル学習データに実際に提案され追加されたものです。これを行うには、デシジョン・センターのインライン・サービスにログインし、デシジョン・センター・ナビゲータ内で「デシジョン・プロセス」セクションを開きます。

ここには、定義されている動的選択肢グループが一覧表示され、各動的選択肢グループに対してデータベース表内で定義されているすべての動的オファーが含まれます。それらは、モデル学習データに提案され追加されたものです。データベース表内の選択肢でモデル学習データに追加されなかったものは、デシジョン・センター・レポートに表示されません。

次の図はデシジョン・センター・レポートの例で、ナビゲータ・ツリーにはDC_Demoの動的選択肢が表示されています。

17.4 外部化されたパフォーマンス目標の重み付け

Oracle RTDのデシジョン・プロセスでは、デシジョンは母集団のセグメントをターゲットとし、セグメントごとにそのデシジョンにアタッチされているパフォーマンス・メトリックに重み付けすることもできます。

パフォーマンス目標に必要な重み付けの種類に応じて、デシジョンは2種類の方法で設定できます。

- 事前定義済の重み付け: インライン・サービスで値が指定されます。

- カスタムの重み付け: 実行時に値の計算や変更ができます。

インライン・サービスでパフォーマンス目標に対してカスタム重み付けを選択することで、エンド・ユーザーはデシジョン・プロセスに変更を即座に反映でき、異なる母集団のセグメントが実行時に効果的にセグメント化されます。

インライン・サービスでパフォーマンス目標のカスタム重み付けを定義して使用する方法の詳細は、次の各項を参照してください。

- 第13.7項「パフォーマンス目標」

- 第13.12項「Decisionsについて」

- 第13.12.1項「母集団のセグメント化と目標の重み付け」

A Oracle RTDモデルの機能と戦略

この付録では、Oracle RTD自己学習予測モデルの一部の主要機能の概要を説明するほか、ビジネス分析の例を示します。これにより、 個別の予測モデル設定がOracle RTDのデシジョン・ロジックに及ぼす影響を理解できます。このドキュメントでは、これらの機能をどのように使用すれば、モデルの初期から成熟期までのライフサイクル全体を通して、データ利用(Oracle RTD自己学習モデルで得た既知の知識の最大限の活用)とデータ探索(さらなる知識の獲得によるデシジョンの精度向上)との間の適度なバランスを確立できるかという点を中心に説明します。

この付録では、読者がOracle RTDの予測モデルおよびデシジョン・ロジックの概念や用語をすでに理解していることを前提としています。詳細は、「Oracle RTDの意思決定プロセス」と「モデルについて」を参照してください。

この付録では、Oracle RTDの予測モデリング機能の数学的な詳細説明は省略しています。

免責事項

- この付録では、具体的な例を使用して様々なOracle RTDモデル設定の動作を説明していますが、それぞれの設定が互いに干渉する可能性があるため、特定の意思決定戦略を改善するための設定の選択は、特定時点における総合的なインライン・サービスのコンテキストの中で行う必要があります。この付録であげる例やヒューリスティックは、主にOracle RTDモデルの動作の理解を助けることを目的としています。モデル設定におけるベスト・プラクティスであったとしても、反復による統一的なモデリング戦略の開発には適しません。設定を変更する前に、熟練したデータ分析者による現行の本番データの徹底的な分析をお薦めします。

この付録には次のトピックが含まれます:

- 第A.1項「モデルの概念」

- 第A.2項「モデルからデシジョンへ」

- 第A.3項「モデルの成熟」

- 第A.4項「モデルのランダム化された確率計算」

- 第A.5項「複数イベントに対するモデル確率計算」

- 第A.6項「デシジョンのための選択肢のスコアリング」

- 第A.7項「モデル品質」

- 第A.8項「よくある質問」

A.1 モデルの概念

予測モデルとは、観測されたデータ・サンプルから作成される関数のことであり、デシジョンの時点で未知である結果を推定するために使用されます。例:

- この一週間の対話データに基づき、このバナーをこのページのこの場所に表示したときに、この訪問者がこのバナーをクリックする確率を予測する。

- 過去の電子メール・キャンペーン結果に基づき、この新しい電子メールの結果として、この顧客が当社のWebサイトを訪問する確率を予測する。

予測結果は決して完全に正確ではありません。モデル化されたプロセスはランダム性を内在しており、モデルには入手できないデータによる影響を受けるからです。

Oracle RTDでモデルを定義するときには、次の3種類のモデルから選択できます。

- 選択肢イベント・モデル

- 選択肢モデル

- モデル

この3種類のモデルは、その特性のほとんどを共有していますが、それぞれ固有の使用パターンに対応しており、各ユースケースをサポートするための自動化度がそれぞれ異なります。詳細は、第13.14.1項「モデルの種類」を参照してください。

以降では、選択肢イベント・モデルを中心に説明します。選択肢イベント・モデルは自動化度が最も高いため、インライン・サービスで最もよく使用されます。選択肢イベント・モデルは、ベース・イベントが発生したときに、ある選択肢に固有のイベントが発生する条件付き確率を予測および分析する目的で使用します。

A.2 モデルからデシジョンへ

Oracle RTDがどのように予測モデルを使用してデシジョンを行うかを理解するには、モデル確率とデシジョン・スコアという2つの概念を区別することが重要です。

モデル確率は、予測モデルが返す0から1までの数値です。選択肢イベント・モデルのコンテキストでは、モデル確率とは、特定のイベントが特定の状況(ベース・イベントの発生)、顧客データおよびコンテキストにおいて発生する予測確率を意味します。この確率は、インライン・サービスで様々な目的に使用できます。たとえば、適格性ルールのしきい値や、ランキング選択肢のスコアリング方法として使用できます。

デシジョン・スコアは、 デシジョンを行う際に使用される数値です。Oracle RTDでは、複数のスコアを選択肢に関連付け、複数のパフォーマンス目標(KPIともいいます)に基づいて最適な選択肢を選択できます。Oracle RTDデシジョン・フレームワークでは、多数のパフォーマンス目標を作成して、それらにスコアリング方法を関連付けることができます。

- 単一のパフォーマンス目標を持つ(つまり、単一のスコアに基づく)デシジョン・ロジックの例として、Oracle RTD選択肢イベント・モデルによる計算で予測クリック確率が最も高いとされた選択肢が最適な選択肢である場合があげられます。

- 複数のパフォーマンス目標を持つ(つまり、複数のスコアの組合せに基づく)デシジョン・ロジックの例として、予想収益が最大、コストが最小になる組合せの選択肢が最適な選択肢である場合があげられます。この場合、予想収益は、Oracle RTD選択肢イベント・モデルが予測した確率に、商品に関連付けられた、オファーが受入れられた場合の収益を掛けた積として計算できます。コストは、各商品に関連付けられた定数値です。

例を簡単にするために、以降では、単一パフォーマンス目標デシジョン・スキームのユースケースを使用します。このデシジョン・スキームでは、最適な選択肢の選択に使用するスコアリング方法が選択肢イベント予測モデルに直接マッピングされます。

A.3 モデルの成熟

Oracle RTDモデルは徐々に学習していきます。つまり、知識がゼロの状態から開始して、学習したケースが増えるにつれて予測精度が向上していきます。

モデルは知識の離散的段階(通常のデータ・マイニング用語では「モデルの収束」ともいいます)に達すると考えがちですが、Oracle RTDの場合、モデルの知識は継続的に発達していくため、この定義は直接には当てはまりません。

Oracle RTDモデルがいつ知識の安定レベルに達するかを厳密に定義するのは困難ですが、2つの成熟初期段階は、それ以降の段階と明らかに異なっており、「重要度しきい値」パラメータがその境界となっています。

A.3.1 重要度しきい値

重要度しきい値は、Oracle RTDインライン・サービス・レベルでグローバルに定義する数値であり、このインライン・サービスで定義したすべてのモデル、選択肢およびその関連イベントに適用されます。

モデル成熟サイクルをごく短くするために、デフォルト値は25と定義されています。短い成熟サイクルを実現するには、確率計算を信頼し始められる十分なケースがモデルによって学習されたことを早期に判断する必要があります。確率計算を検証する機会を早くモデルに与えれば、モデルが正確な予測をするまでにかかる時間が短縮されます。重要度しきい値を大きくすると、モデルが有効な予測を行うために必要なユースケースが増えるため、より保守的なアプローチになります。

モデルは、ライフサイクルの初期には、すべての予測リクエストに対してNaN (Not a Number)を返します。これは、予測の概算にさえ十分な情報がモデルにないことを示します。スコアリング・プロセスにおいてNaNがデフォルトでどのように処理されるかについては後述しますが、このデフォルトの動作が要件に合致しない場合は、ユーザー独自の処理を定義できます。ただし、この初期段階はそもそも過渡的なものであることを念頭においてください。

- たとえば、選択肢の適格性を、選択肢の確度値がNaNでないケースのみに限定できます。

- また、別の戦略として、確度がNaNであるか5%を上回る選択肢を適格にすることもできます。この戦略では、選択肢の不確実性が高いことを示せると同時に、選択肢の確度が十分に高い(> 5%)とみなされるケースのみに考慮対象を限定できます。

- デシジョンのコンテキストでは、モデルがNaNを返す期間のスコアリング・ルールも使用できます。

この成熟の第1段階は、最小限の数のベース・イベントがモデルに記録されるまで続きます。この数は、重要度しきい値の2倍と定義されています(デフォルトでは2 * 25)。

ベース・イベントの数が重要度しきい値の2倍に達すると、第2段階が開始します。この時点からモデルは確率を返し始めます。肯定的イベントの数がまだ少ない間は、平均値に基づく単純な確率計算方法をモデルは使用します。つまり、この時期のモデルは、任意の時点ですべての顧客に対して同じ確率(平均確率)を返します。この平均確率は新しい学習によって変化していきます。

発生した肯定的イベントの数が重要度しきい値の2倍を超えると、第3段階が開始します。この時点からモデルはケースごとに異なる確率を返すようになります。選択肢イベント・モデルは複数の肯定的イベントを持つ場合があります。この場合、前述の成熟段階はイベントごとに別々に適用されます。

次の表は、これまでの説明をまとめたもので、アクティブな時間枠内の各成熟段階で特定の肯定的イベントの確率計算に使用される方法の特徴を説明しています。Oracle RTDで複数の肯定的イベントの確率を組み合せて最終的な確率を求める方法については、第A.5項「複数イベントに対するモデル確率計算」で別途説明しています。 説明を単純にするために、重要度しきい値は25に固定されているものと仮定します。

期間

ケース(ベース・イベント)数

肯定的ケース(肯定的イベント)数

確率

(確率計算の対象である肯定的イベントの確率)

説明

第1段階

50未満

任意の数

NaN

基礎的な予測にさえ十分なデータがないため、モデルはNaNを返します。

第2段階

50以上

1以上50未満

平均確率 = 肯定的イベント数 / ベース・イベント数

信頼性の高い予測を行うために必要な大量のデータがないときは、平均が妥当な初期推量となります。

第3段階

50以上

50以上

ケース別の予測

モデルは予測に十分なデータを学習しており、データの増加に伴いさらに成熟していきます。

たとえば、提示されたオファーを顧客がクリックする確率を予測する選択肢イベント・モデルが定義されているとします。この場合、オファーの提示がベース・イベントに当たり、オファーのクリックが肯定的イベントに当たります。モデルが返す値の変化を次の表に示します。

オファーの提示回数

オファーのクリック回数

予測

注意

0

0

NaN

知識がありません。

23

1

NaN

知識が過少です。

60

0

NaN

肯定的イベントに関する知識が過少です。

60

2

3.3%

平均(2/60)が初期推量です。

922

35

3.8%

まだ平均(35/922)が妥当な推量です。

1442

57

顧客別の値

-

25436

2011

より精度の高い顧客別の値

-

A.4 モデルのランダム化された確率計算

Oracle RTDモデルの組込み機能の1つとして、予測計算にある程度の変動性を導入する機能があります。「可能性のランダム化」を選択すると、算出された確率に正規分布ノイズ係数が加算されます。このノイズ係数は、平均が0で、肯定的イベントの総数と重要度しきい値に基づく標準偏差の正規分布に従います。このランダム化係数は、モデルが確率を計算可能になると同時に導入されます。つまり、成熟の第2段階から開始します。

このランダム化係数(統計用語では「ノイズ」ともいいます)によってある程度の変動性をデシジョン・プロセスに導入することは、クローズド・ループ・システムにおいて重要です。これにより、すべてのオファーに公平な可能性を与えることができるようになるからです。この変動性の導入により、クローズド・ループ・システムでは既成の知識を再評価し(統計用語では「システムの局所最適からの脱出」ともいいます)、学習を発展させ、より公平な可能性を他の選択肢に与えることが可能になります。Oracle RTDでは、導入する変動性の振幅を選択肢イベントの確率計算ごとに経時的に制御することで(詳細はこの項で後述します)、反応を正確に予測する能力に悪影響を及ぼすことなく既成の知識を再評価する適度なバランスを追求します。

次の表に、特定の選択肢イベント(「クリック」)の確率計算の例をいくつか示します。

選択肢の提示回数

選択肢のクリック回数

予測クリック確率

平均クリック確率

ノイズの標準偏差

ランダム・ノイズ

(例)

使用される最終確率値

(例)

37

5

NaN

13.5%

6.04%

-

NaN

1250

17

1.4%

1.4%

0.33%

0.32%

1.72%

1250

17

1.4%

1.4%

0.33%

-0.11%

1.29%

3506

44

1.3%

1.3%

0.19%

-0.44%

0.86%

5577

71

5.8%

1.3%

0.18%

0.12%

5.92%

この表からわかるように、ランダム・ノイズのレベルは、入力値が同じ場合でも、使用される最終確率値に影響します。

この表を見ると、ランダムに抽出される変数の性質により、ノイズの標準偏差は時間とともに減少していますが、個別の計算で使用されるランダム・ノイズは大きくなる場合があります。

重要な点として、この「可能性のランダム化」オプションによって導入されるノイズの振幅は、ノイズの標準偏差が肯定的イベントの回数ごとに減少するにつれて、時間とともに急速に減少していきます。次のグラフは、特定のイベントの確率計算における、ノイズの標準偏差と肯定的イベントの回数の関係を示しています。平均応答率を5%と仮定しています。

画像image002.gifの説明

A.5 複数イベントに対するモデル確率計算

Oracle RTDの選択肢イベント・モデルは、イベントの順序付きリストを使用して定義されます。たとえば、提示→クリック→購入という一連のイベントが選択肢ごとに異なる早さ、異なるタイミングで発生する可能性がある場合、Oracle RTDでは、この一連のイベントを単一のモデルで定義できます。個々のイベントごとに別々のモデルを作成して管理する必要はありません。

Oracle RTDは最も重要度が高い結果を計算に使用しようと試みるため、イベントの順序が選択肢の確率計算に影響します(たとえば、購入とクリックとでは、購入の方が定義された一連のイベントの中で高くランク付けされます)。この戦略により、Oracle RTDは一連の肯定的イベントの中の分岐点をできるかぎり早期に特定し、クリックした顧客のうち、購入意志のない人ではなく、購入意志のある人のみをデシジョン・プロセスの対象にできます。また、この定義から、順序が遅いイベントほど順序が早いイベントよりも発生確率が低いことがわかります。

順序が遅いイベントの確率を計算できない場合(つまり、モデルの第1段階にあり、前述のロジックによる確率がNaNの場合)、Oracle RTDは次の方法で確率を概算します。その方法とは、確率を計算できる最も順序が遅いイベントを探し、その確率に、本来リクエストされたイベントに対する相対比率を掛けるという方法です。

A.5.1 個別のモデル確率のリクエスト

モデル・レベルで一連のイベントが定義されている場合でも、Oracle RTDでは、特定のイベントに対する確率スコアをリクエストするインライン・サービスを実装できます。

選択肢にAというベース・イベントとB、C、Dという3つの肯定的イベントがある場合、イベントDの確率を問い合せると、次のようになります。

- Dの確率が計算可能な場合は、その確率が返されます。

- Dの確率が計算できない場合で、BまたはCの確率が計算可能なときは、前述のとおり、順序が早いイベント(BまたはC)の確率に相対比率を掛けた値が返されます。

- BまたはCの確率が計算できない場合は、NaNが返されます。

通常、個別の選択肢についてイベントDのモデルが収束しておらず、Cのモデルが収束している場合、Dの予測を問い合せた結果は、Cを問い合せた場合とは異なります。

A.6 デシジョンのための選択肢のスコアリング

Oracle RTDのデシジョン・プロセスでは、加重と、最適化の対象であるパフォーマンス目標に基づいて、適格なすべての選択肢がソートされます。この選択肢のソートは、選択肢の「合計スコア」を基準に行われます。合計スコアを計算するとき、Oracle RTDは、選択肢のスコアをパフォーマンス目標ごとに計算し、各スコアに重みを加えて合計します。これが最終的な合計スコアになります。

この付録では、単一パフォーマンス目標デシジョン・スキームのみを取り上げます。このスキームでは、最適な選択肢の選択に使用されるスコアリング方法が選択肢イベント予測モデルに直接マッピングされます。この場合、各選択肢に関連付けられる合計スコアは、選択肢イベント・モデルで算出された確率が基になります。

また、ここでは「パフォーマンス目標」設定の「必須」オプションが選択されているものと仮定します。このオプションは、合計スコアを計算するには、各選択肢にこのパフォーマンス目標のスコア値が必須であること示します。選択肢のソートには各選択肢の合計スコアが必要なため、Oracle RTDでは、定義されたスコアリング方法が値を返さないときに使用するデフォルト戦略を定義しておく必要があります。通常、この状況が発生するのはモデル成熟度の初期段階です。選択肢のソート・アルゴリズムを詳しくみる前に、一部のスコアを計算できないときの一般的なシナリオについて、次の各項でいくつか説明します。

A.6.1 新しい選択肢の導入

予測ベースのデシジョン・スキームが持つ重要な課題の1つは、新しく導入された選択肢(モデルがまだ収束していない)を既存の選択肢(既成の予測モデルに関連付けられている)と競合させる必要がある場合の処理です。

新しい選択肢に対しては、Oracle RTDがモデルを信頼して肯定的イベントの確率を予測し始まるまでの間、自らの価値を示す公平な可能性を与える必要があります。

Oracle RTDには、新しい選択肢を公平に表現できる簡単な方法が用意されています。「公平」とは相対的に平等という意味です。たとえば、適格な選択肢が15個ある場合、ある選択肢が最初に選択される可能性として6.6%を与えれば、公平な表現になります。

新しい適格な選択肢に可能性を与えると同時に、優れたモデルがある適格な選択肢に関する知識を活用する必要があります。したがって、新しい選択肢も既成の選択肢も少数であれば、新しい選択肢にはその数に応じた公平な表現を与え、既成の選択肢には最適化された表現を与えるのが理想です。

次の例で、この要件にOracle RTDがどのように対応するかを説明します。

適格な選択肢が15個あり、うち10個は既成の選択肢で、そのための優れたモデルがあり、残りの5個は新しい選択肢であると仮定します。

この場合、33%の確率で5個ある新しい選択肢の1つがランダムに選択され、66%の確率で10個ある既成の選択肢の1つが合計スコアに基づいて選択されるのが理想的です。

Oracle RTDでは、次のようなプロセスによってこの公平性を実現します。

1. 各選択肢にランダムな数値を割り振ります。選択肢のスコアが計算可能かどうかは関係ありません。

2. 選択肢同士を比較して選択肢をソートします(適格な選択肢の全リストで繰り返し対比較を行います)。

- 比較する2つの選択肢それぞれの合計スコアを計算できるときは、合計スコアを使用して比較します。

- 比較する2つの選択肢の片方または両方の合計スコアが計算できないときは、割り振ったランダムな数値を使用して比較します。

この単純なプロセスによって、前述した公平性の目標を達成できます。言い換えると、既成の選択肢同士は合計スコアで比較され、新しい選択肢と比較する選択肢はランダムにソートされます(ソート・プロセスの最初にランダムな数値が割り振られているので、矛盾なくソートされます)。なお、デシジョン・プロセスで選択肢の比較に使用されるランダムな数値は、この付録で前述したモデルの確率計算のために行われるランダム化とはまったく異なります。注意してください。

「必須」チェック・ボックスを選択していない場合、スコアリング方法が値を返さないと、他のパフォーマンス目標に基づいて他の選択肢との1対1の比較が行われます。スコアを計算できるパフォーマンス目標がない場合は、ランダム対比較が使用されます。

原則として、ランダムな数値を使用してスコアリングされる選択肢とランダムな数値を使用しない選択肢の割合によってシステム全体のパフォーマンスが低下しないように、既成のシステムへ一度に導入する新しい選択肢の数を監視する必要があります。このランダム比較が発生するのは、学習の初期と過渡期のみです。

A.7 モデル品質

ほとんどのデータやデータ間結合が持つ性質そのものが原因で、予測モデリングによる将来の事象の予測には誤差が伴います。Oracle RTDモデルには、こうした誤差の性質を理解し、潜在的な誤差の認識に基づいて最適なデシジョン・スキームを設計するために役立つ機能がいくつか用意されています。

Oracle RTDデシジョン・センターの品質レポートには、次に示すメトリックが選択肢レベルと選択肢グループ・レベルの両方で表示されます。これらは、予測モデルの品質の特性を表します。

- モデル品質

- 累積ゲイン・チャート

- モデル誤差

モデル品質は0から100の範囲の数値です。ある結果を予測するときに、そのモデルがどれだけ信頼できるかを示します。

モデル品質は、モデルのリスト曲線の下の領域を理論上の理想モデルと比較して計算されます。

Oracle RTDでは、モデル品質の計算はレコードが増えるに従って増分的に行われます。最初のうちは、モデル内のデータが少なすぎるためにモデルを信頼できない時期もあります。この期間中は、デシジョン・センターのレポートにモデル品質のメトリックは表示されません。モデルが信頼できる状態になった後は、モデル品質がレポートに表示されます。

モデル品質のメトリックによってモデルを評価すると、最終的には1つの数値が得られますが、これは絶対値ではなく相対値として扱う必要があります。

経験則:

- モデル品質が30を下回っているときは、一般にあまり実用的ではありません。この状態が発生する原因は様々で、たとえば次のようなものがあります。

- 入力データと出力との相関性が低い。

- 入力変数の値が多すぎるため、あまりにも多くのノイズが入り込んでいる。

- 誤ったデータをモデリングしている。

- モデル品質が95を上回っている場合は検査が必要です。それは、入力の中に自己達成的なものがある可能性があるからです。つまり、その結果が存在するときはその入力が必ず存在するということです。

- モデル品質が50以上ならば良好です。

- モデル品質が70以上ならばきわめて良好です。

A.7 モデル品質のしきい値とモデルの使用

予測モデルに関連付けてその動作の特徴を示すことができるメトリクスは多数ありますが、モデル品質は複数のメトリクスを1つに集約するため、モデルのすべての側面を正確に表すことはできません。それでも、モデル品質はモデルを使用および信頼するタイミングを示す優れた指標であり、他のスコアリング戦略との比較検討に役立ちます。

例:

- スコアリングに使用できる既存のオフライン・モデルのスコアがある場合で、Oracle RTDモデルが学習中のときは、Oracle RTDモデルの品質が30から40に達するまで、既存モデルを使用することが考えられます。

- また、このような既存モデルがない場合は、最初からOracle RTDモデルを使用する必要があります。

- 別の方法として、Oracle RTDモデルが十分に学習して所期の品質に達するまでの間、不明の確率(NaN)を選択肢に割り当てておくこともできます。関連付けられたパフォーマンス目標が必須としてマークされている場合、この戦略ではオファーが比例的にランダムに提示されます。

他のスコアリング戦略と比較検討し、モデルを使用および信頼するタイミングを決定するための別の指標として、モデル・リフトがあります。Oracle RTDには、リフト・チャート内の特定のポイントにおけるモデルの相対的な強みを識別するためのランタイムAPIが用意されています。

モデル「lift at 20%」もモデル品質の優れた指標です。このAPIは、リスト曲線の20%のポイントでモデルが提供するリフトを返します。 これは、デシジョン・センターのレポートに表示されます。繰り返しますが、正確に何をしきい値とするかは、意思決定戦略によっても、代替のスコアリング戦略の有無によっても異なります。

最後に、より入念な戦略としては、様々な確率予測戦略を使用した複数の予測モデルを構築し、それらのモデルをどのように組み合せるべきかを集計モデルによってリアルタイムに判断します。

A.8 よくある質問

モデル品質は、選択肢の確率計算でどのような役割を果たしますか。

モデル品質は、確率計算では何の役割も果たしません。

重要度しきい値は、どのような役割を果たしますか。

重要度しきい値(アプリケーションの「モデルのデフォルト」で設定)は、モデルからの予測の計算時、予測モデルの構築時、および予測に最も役立つ属性や値の特定時に様々な箇所で使用されます。

このしきい値には様々な用途があるため、通常は値を変更しないことをお薦めします。

このしきい値は、統計的に有効な結果が出始めるまでに学習する必要があるケース数と解釈するのが最良です。

ボリュームが非常に少ない環境では、このしきい値をデフォルトの25未満に下げることを検討してもかまいません。

代替の確率予測方法があり、Oracle RTDモデルは精度が非常に高まってから使用するような環境では、このしきい値をおそらく50まで上げてもよいでしょう。

予測に役立たない属性の削除についてのベスト・プラクティスを教えてください。

デフォルトでは、入力属性の数はスコアリング・スループットにほとんど影響を与えないため、Oracle RTD全体のベスト・プラクティスは、選択肢の予測有効性に寄与する可能性のある属性はすべて含めておくというものです。

モデルが収束したら、個々の属性を含めるかどうかを、それぞれの予測有用性に基づいて調整できます。モデルのすべての選択肢に対して予測有用性がゼロの属性(デシジョン・センターのドライバ・レポートに示されます)については、除外を検討してもかまいません。ただし、このような属性も、後から、または新しく導入する選択肢の予測に役立つ可能性がある場合は、モデルから除外しないでください。

Oracle RTDは、ノイズと思われる属性を識別しますか。

極端に高い(90-100)予測有効性を示す属性は、予測対象の属性と共線的であると判断されれば、除外する必要があります。こうした属性をデシジョン・スタジオで排除するには、モデル構成時に「除外された属性」セクションを使用するか、属性のプロパティで「分析に使用」の選択を解除します(この場合、すべてのモデルから除外されます)。

Oracle RTDモデルは、モデルの定義にある「前提ノイズの削減」オプションを有効にすることで、属性の予測有効性が疑わしいほど高いケースを自動的に認識するように設定できます。このようなケースに該当する場合、デシジョン・センターのレポートでは、疑わしい非常に高い予測有効性の値および相関性の値が灰色の棒グラフで強調されます。詳細は、第13.14.2項「共通のモデル・パラメータ」のトピック「前提ノイズの削減」を参照してください。

選択肢の適格性ルールで使用されている属性を手動で除外する必要はありません。このような属性はベース・イベントと肯定的イベントの両方でカウントされるため、除外しなくても予測計算には影響しないからです。

モデル出力との相関関係がないとわかっている属性(たとえば、データベースの一意識別子や参照キーなど)はすべて、モデルから除外できます。除外しなかったとしても、Oracle RTDは自動化に対応して設計されており、予測に役立たない可能性がある属性を含むことで生じるノイズは無視できる程度のものです。

モデルの再構築は、いつ必要でしょうか。

従来のデータ・マイニング手法では、モデル品質の低下に伴い、定期的に予測モデルを再構築する必要があります。Oracle RTDには、モデルの再構築を自動化してモデルの利用を最適化するための機能が複数用意されています。

その1つはモデルの時間枠です。この機能は、設定されたタイミングに基づくモデルの再構築を自動化します。これにより、古いデータやその過去における作用が新しい時間枠のモデルに影響を及ぼさないようにできます。

もう1つは、モデルを定期的に再評価する機能です。インライン・サービスの「アプリケーション」の「モデルのデフォルト」タブにある「データの変更時にビルド」パラメータを使用すると、新しい予測モデルを構築する前に何件のレコードが記録される必要があるかをパーセンテージで設定できます。デフォルト値は「20%」です。

Oracle RTDでは、スコアの計算時に属性の母集団全体の中から何個の属性が選択されますか。すべて、上位20個、上位30個、または統計的計算に基づく可変数ですか。その場合、どのような計算方法ですか。

Oracle RTDでは、属性のプロパティ・ボックス内にある「分析に使用」チェック・ボックスの選択を解除している場合を除き、すべてのエンティティ属性がモデル学習の一部として組み込まれます。

モデルを圧縮すると、属性の数だけでなく数値用の事前計算バイナリの数も減り、サイズが約1/10になります。ただし、どの値が使用されるかを示すレポートは現在ありません。

インライン・サービス・アプリケーション・レベルで定義する相関しきい値によってモデルの圧縮率を制御できます。デフォルトでは0に設定されています。したがって、肯定的イベントとの相関関係がゼロの属性-値のみが削除され、情報の欠落がまったくない圧縮モデルができます。このしきい値を大きくすれば、モデルの圧縮率を上げられますが、その代償として、相関関係のレベルが定義したしきい値を下回る属性-値が削除されます。

B Oracle RTD Webサービスおよびクライアント

Java Required Files (JRF)は、アプリケーション・サーバーのインストールには含まれていないコンポーネントで構成されており、Oracleビジネス・アプリケーションおよびアプリケーション・フレームワークで使用する共通の機能を提供します。11gリリース1以降、ユーザー・アプリケーションからコールできるOracle RTD WebサービスはJRFテクノロジ・スタックに基づいています。これらのWebサービスは、Webセキュリティ・ポリシーによって保護されます。この付録では、Oracle RTD Webサービスとそれにアクセス可能なクライアントのほか、サポートされているすべてのテクノロジ・スタックおよびセキュリティ・ポリシーのオプションを示します。

この付録には次のトピックが含まれます:

- 第B.1項「Oracle RTD Webサービス」

- 第B.2項「Oracle RTDクライアント」

- 第B.3項「Webサービスのセキュリティ」

注意:

この付録では、次の略語を使用します。これらは、Oracle RTDおよびOracle RTDアプリケーションに固有のものです。

- WB = ワークベンチ

- DS = Decision Server

- LS = Learning Server

- DC =デシジョン・センター

- ILS = インライン・サービス

- Admin = 管理Webサービス

- RTD ADF ERE = ADFコンポーネントとしての外部ルール・エディタ

- RTD DC ERE =デシジョン・センター内の外部ルール・エディタ

B.1 Oracle RTD Webサービス

この項には次のトピックが含まれます:

- Oracle RTD Webサービスの概要

- 管理Webサービス

B.1.1 Oracle RTD Webサービスの概要

Oracle RTD Webサービスには、次のようなものがあります。

- RTIS (SDClientとも呼ばれます)
デシジョン・サービスとのインタフェースです。

統合点コールに対するすべてのリクエストに応えます。

- ワークベンチ
デシジョン・スタジオによるインライン・サービスのデプロイメントをサポートします。

デシジョン・センターで構造およびインライン・サービスのデシジョン履歴の表示に使用されるWebインタフェースを提供します。

インライン・サービスのルールをフェッチおよび更新するサービスを提供します。

- バッチ
バッチ・ジョブの実行リクエストに応えます。

- 管理Webサービス
Oracle RTD管理サービスをBI管理者に提供します。

- 外部選択肢
Oracle RTDの外部選択肢エンティティのリストをフェッチします。

表B-1に、使用可能なOracle RTD Webサービス、そのテクノロジ・スタック、エンドポイント・アドレスおよびサポートされるセキュリティ・ポリシーの全リストを示します。

表B-1 Oracle RTD Webサービス

Webサービス名

テクノロジ・スタック

エンドポイント・アドレス

用途/使用元

セキュリティ・ポリシー

RTIS

JRF

http://<server>:<port>/rtis/sdwp脚注 1

統合点コール

username_token

RTIS

JRF

http://<server>:<port>/ws/rtis

統合点コール

username_token

WB

JAX-WS

http://<server>:<port>/ui/workbench2

デシジョン・センター

Webコンテナ・セキュリティ

WB

JRF

http://<server>:<port>/ws/workbench

ILSデプロイメント、ADF外部ルール・エディタ

username_token

WB

JRF

http://<server>:<port>/ws/workbench2

ILSデプロイメント、ADF外部ルール・エディタ

SAMLまたはusername_token_with_message_protection

バッチ

JRF

http://<server>:<port>/ws/batch

バッチ

username_token

バッチ

JRF

http://<server>:<port>/ws/batch2

バッチ

SAMLまたはusername_token_with_message_protection

Admin

JRF

http://<server>:<port>/ws/AdministrationClient

管理サービス

username_token

Admin

JRF

http://<server>:<port>/ws/AdministrationClient2

管理サービス

SAMLまたはusername_token_with_message_protection

外部選択肢

JRF

http://<server>:<port>/ws/externalchoice

外部選択肢

username_token

外部選択肢

JRF

http://<server>:<port>/ws/externalchoice2

外部選択肢

SAMLまたはusername_token_with_message_protection

脚注 1 rtis/sdwpエンドポイントは、Oracle RTD Version 3.0との後方互換性を保つために用意されています。

注意:

この表および以降の表に記載のセキュリティ・ポリシー名は、完全名ではなく一般名です。たとえば、汎用セキュリティ・ポリシーusername_tokenの、Fusion Middleware Controlに表示される完全名はoracle/wss_username_token_service_policyです。

図B-1は、Oracle RTD Webサービスに接続するOracle RTDクライアントとともに、連携するOracle RTDサーバーおよび主要なOracle RTD要素を示しています。Oracle RTDクライアントの詳細は、第B.2項「Oracle RTDクライアント」を参照してください。

Oracle RTDで用意されているもの以外のWebサービス・クライアントを使用する開発者は、Webサービス・エンドポイントでポリシーを変更できますが、使用するWebサービス・クライアントがポリシーをサポートできるようにする責任があります。

図B-1 Oracle RTDクライアント - Webサービスの概要

B.1.2 管理Webサービス

管理Webサービスにより、BI管理者は次のインライン・サービス管理操作を実行できます。

- すべての業務系データのクリア

- 選択肢の履歴のクリア

- モデルのクリア

- 統計のクリア

- スタディのクリア

- サービスの削除

- サービスのロック解除

注意:

モデルのクリア以外の管理Webサービス操作は、対応するInlineServiceManager JMX MBeanと同じ操作を実行します。これらのMBeanは、Enterprise Managerを介して使用できます。MBeanの詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracleRTDについて→InlineServiceManager→[InlineService.DeploymentState]に関する項を参照してください。

コール元には、適切な管理アクションの権限が付与されたBI管理者アプリケーション・ロールが必要です。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle RTDのリソース・タイプとアクションに関する項を参照してください。

注意:

すべての管理操作は、Enterprise Managerと管理Webアプリケーションのどちらを使用して実行するかにかかわらず、Oracle RTDが新しいリクエストの受付けを終了し、インライン・サービスおよびバッチが処理を完了してから実行することを強くお薦めします。

管理WebサービスのWSDLを実行中のWebLogicサーバーから取得するには、次のURLをユーザー環境に合せて適切に変更したものをインターネット・ブラウザで使用します。

http://localhost:7001/ws/AdministrationClient?WSDL

次に、それぞれの管理Webサービス操作コールの詳細を示します。参考として、Enterprise Managerによって起動可能な対応するJMX MBeanも掲載します。

注意:

各APIは、WebLogicに付属のWebサービス・ツールで正常終了メッセージのみを返します。管理Webサービス自体が例外をスローするのは、エラーが発生した場合のみです。それ以外の場合は、正常に動作が完了したとみなすことができます。

- void clearAllOperationalData(String serviceName, DeploymentState deploymentState)
この操作は、指定されたインライン・サービスおよびデプロイメント状態の業務系データをすべてクリアします。

正常に終了すると、指定されたインライン・サービスの業務系データ、統計、選択肢の履歴およびスタディがすべてクリアされたことを示すメッセージが表示されます。

対応するInlineServiceManager MBean: deleteAllOperationalData

- void clearChoiceHistory(String serviceName, DeploymentState deploymentState)
この操作は、指定されたインライン・サービスおよびデプロイメント状態の選択肢の履歴をクリアします。

対応するInlineServiceManager MBean: deleteChoiceHistory

- void clearModel(String serviceName, DeploymentState deploymentState, String modelName)
この操作は、指定されたインライン・サービス、デプロイメント状態およびモデル名のモデル・データをクリアします。

正常に終了すると、指定されたインライン・サービスのモデルがクリアされたことを示すメッセージが表示されます。

対応するInlineServiceManager MBean: なし

- void clearStatistics(String serviceName, DeploymentState deploymentState)
この操作は、指定されたインライン・サービスおよびデプロイメント状態の統計をクリアします。

正常に終了すると、指定されたインライン・サービスの統計がクリアされたことを示すメッセージが表示されます。

対応するInlineServiceManager MBean: deleteStatistics

- void clearStudy(String serviceName, DeploymentState deploymentState)
この操作は、指定されたインライン・サービスおよびデプロイメント状態のスタディをクリアします。

正常に終了すると、指定されたインライン・サービスのスタディがクリアされたことを示すメッセージが表示されます。

対応するInlineServiceManager MBean: deleteStudy

- void deleteService(String serviceName, DeploymentState deploymentState)
この操作は、指定されたインライン・サービス名およびデプロイメント状態のインライン・サービスを削除します。

正常に終了すると、指定されたインライン・サービスが削除されたことを示すメッセージが表示されます。

対応するInlineServiceManager MBean: removeService

- void unlockService(String serviceName, DeploymentState deploymentState)
この操作は、指定されたインライン・サービス名およびデプロイメント状態のインライン・サービスのロックを解除します。

正常に終了すると、指定されたインライン・サービスのロックが解除されたことを示すメッセージが表示されます。

対応するInlineServiceManager MBean: unlockService

無効な資格証明が渡された場合(たとえば、コール元にBI管理者アプリケーション・ロールがない場合など)、次のようなエラー・メッセージが表示されます。

Caller is not authorized to execute action for Inline Service <ils_name>

デプロイメント状態

デプロイメント状態パラメータには、各管理操作の対象とするインライン・サービスのデプロイメント状態を指定します。デプロイメント状態は、Development、QAまたはProductionという3つの値のいずれかをとります。

管理クライアントAPIの使用例

try {
webServiceClient.clearStudy("CrossSell", DeploymentState.DEVELOPMENT);
} catch(Exception e) {
System.out.println("Clear study failed!");
}

B.2 Oracle RTDクライアント

表B-2に、Oracle RTDクライアント、その基盤となるテクノロジ・スタック、使用するWebサービスおよびサポートするセキュリティ・ポリシーを示します。

クライアントが、許可されているセキュリティ・ポリシーのいずれかを使用すると、対応するエンドポイントがコールされます。

表B-2 Oracle RTDクライアント

クライアント名

テクノロジ・スタック

Webサービス

セキュリティ・ポリシー

Javaスマート・クライアント

JRF

RTIS

username_token、username_token_with_message_protection、SAML

Javaスマート・クライアント

HTTPクライアント

RTIS

username_token

バッチ・クライアント

JRF

バッチ

username_token、username_token_with_message_protection、SAML

バッチ・クライアント

JAX-WS

バッチ

username_token

ロード・ジェネレータ

HTTPクライアント、JAX-WS WBクライアント

RTIS、WB

username_token

デシジョン・スタジオ

HTTPクライアント、JAX-WS WBクライアント

RTIS、WB

username_token

RTD ADF ERE

JRF

WB (JRF)

username_token_with_message_protection、SAML

RTD ADF ERE

SAAJ

WB (JRF)

username_token

RTD DC ERE

JavaScript

WB (JAX-WS)

なし

ユーザーが作成したWSクライアント

JRF

RTIS

username_token_with_message_protection、SAML

ユーザーが作成したWSクライアント

JAX-WS、AXIS、JAX-RPC、.NET

RTIS

username_token

RTD PHPクライアント

PHP Soap

RTIS

username_token

RTD PHPクライアント

NuSoap

RTIS

username_token

.Netクライアント

.Net

RTIS

username_token

この項で示す各シナリオでは、Oracle RTDサーバーがOracle Fusion Middleware BI Shiphome上にインストールされているものと仮定しています。

シナリオ1: Oracle Fusion Middlewareでサポートされているアプリケーション・サーバー上で実行可能なOracle RTDクライアントの全リスト

表B-3 Oracle Fusion Middlewareでサポートされているアプリケーション・サーバー上で実行するクライアント

クライアント名

クライアントが依存するテクノロジ・スタック

セキュリティ・ポリシー

Javaスマート・クライアント

JRF

username_token_with_message_protection、SAML

バッチ・クライアント

JRF

username_token_with_message_protection、SAML

ロード・ジェネレータ

HTTPクライアント、JAX-WS WBクライアント

username_token

デシジョン・スタジオ

HTTPクライアント、JAX-WS WBクライアント

username_token

RTD ADF ERE

JRF

username_token_with_message_protection、SAML

ユーザーが作成したWSクライアント

JRF

username_token_with_message_protection、SAML

シナリオ2: Fusion以外のJDK 1.6およびJDK 1.5上で実行可能なOracle RTDクライアントの全リスト

表B-4: Fusion以外のJDK 1.6およびJDK 1.5上で動作するクライアント

クライアント名

クライアントが依存するテクノロジ・スタック

セキュリティ・ポリシー

Javaスマート・クライアント

HTTPクライアント

username_token

バッチ・クライアント

JAX-WS

username_token

ロード・ジェネレータ

HTTPクライアント

username_token

デシジョン・スタジオ

JAX-WS WBクライアント

username_token

RTD ADF ERE

(ADF JSFライブラリがOracle RTDクライアント・コードとともに必要)

SAAJ

username_token

ユーザーが作成したWSクライアント

JRF (1.6のみ)

username_token_with_message_protection、SAML

(SAMLの場合:

ユーザー自身がSAMLトークンを作成してSOAPヘッダーに挿入する必要があります。

クライアントとOracle RTDの両方が同じOID/OVDをポイントする必要があります。)

ユーザーが作成したWSクライアント

JAX-WS、AXIS、JAX-RPC、.NET

username_token

シナリオ3: Oracle Fusion MiddlewareでサポートされていないJDK 1.4上で動作するクライアント

JDK 1.4でサポートされているのはRTD Javaクライアントのみです。

デシジョン・スタジオ、ロード・ジェネレータ、バッチおよびコマンドライン・デプロイヤはJDK 1.4ではサポートされません。

シナリオ4: Oracle Fusion Middlewareでサポートされていないサーバーで動作するPHPクライアント

Oracle RTDでは、デシジョン用のOracle RTD Decision Serverと統合されたPHPフロントエンド・アプリケーションのみをサポートしています。

デシジョン・スタジオ、ロード・ジェネレータおよびバッチ・クライアントはJava環境で実行する必要があります。

表B-5 Oracle Fusion Middlewareでサポートされていないサーバーで動作するPHPクライアント

クライアント・アプリケーション・スタック

クライアントのタイプ

テクノロジ・スタック

セキュリティ・ポリシー

PHP V5

PHPクライアント

PHP Soap

username_token

PHP V5

PHPクライアント

NuSoap

username_token

シナリオ5: Oracle Fusion Middlewareでサポートされていないサーバーで動作する.NETクライアント

Oracle RTDでは、デシジョン用のOracle RTD Decision Serverと統合された.NETフロントエンド・アプリケーションのみをサポートしています。

デシジョン・スタジオ、ロード・ジェネレータおよびバッチ・クライアントはJava環境で実行する必要があります。

表B-6 Oracle Fusion Middlewareでサポートされていないサーバーで動作する.NETクライアント

クライアント・アプリケーション・スタック

クライアントのタイプ

テクノロジ・スタック

セキュリティ・ポリシー

.Net

.Netクライアント

username_token

B.3 Webサービスのセキュリティ

Oracle RTD Webサービスのセキュリティは、Oracle Web Services Manager (OWSM)を介して実装されます。Oracle RTDをデプロイすると、Oracle RTD WebサービスがOWSMに登録されます。デフォルトでは、それらは、表B-1に示すエンドポイント・アドレス、ポートおよびセキュリティ・ポリシーを持ちます。serverとportの値は環境固有です。

この項には次のトピックが含まれます:

- 第B.3.1項「Oracle RTD Decision Server認証の無効化」

- 第B.3.2項「グローバルにアタッチされたポリシーから直接アタッチされたポリシーへの置換」

B.3.1 Oracle RTD Decision Server認証の無効化

デフォルトでは、Oracle RTD Webサービスはすべてのセキュリティ・オプションが有効になっています。これらのオプションは、Oracle RTDをコールするアプリケーションが動作する個々のセキュリティ・コンテキストに応じて無効にできます。どのセキュリティ・ポリシーをWebサービスに関連付けるかを選択できます。認証や認可を使用しないポリシーも選択できます。

これらのオプションは、Oracle RTDをコールするアプリケーションが動作する個々のセキュリティ・コンテキストに応じて無効にできます。どのセキュリティ・ポリシーをWebサービスに関連付けるかを選択できます。認証や認可を使用しないポリシーも選択できます。

Oracle RTD Decision Server認証をWebサービスで無効にするには、次の手順を実行します:

1. Fusion Middleware Controlにログインします。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』を参照してください。

2. 「ターゲット・ナビゲーション・ペイン」の「アプリケーション・デプロイメント」で、OracleRTDサーバーのエントリを右クリックし、「Webサービス」を選択します。

3. 「Webサービスの詳細」領域で「Webサービス・エンドポイント」タブをクリックします。

4. Webサービスで使用するエンドポイント名をクリックします。

5. 「ポリシー」タブでポリシーを選択し、「アタッチ/デタッチ」をクリックします。

6. 「アタッチされたポリシー」領域でポリシーを選択して「デタッチ」をクリックし、「OK」をクリックします。
ポリシーをデタッチする各Webサービスに対して、手順3から6を繰り返します。

7. Oracle RTDが含まれているドメインを停止して再開します。

Webサービスのセキュリティの構成および変更の詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

B.3.2 グローバルにアタッチされたポリシーから直接アタッチされたポリシーへの置換

デフォルトでは、Oracle RTD Webサービスは、グローバルにアタッチされたセキュリティ・ポリシーを使用するように構成されています。使用環境でグローバルにアタッチされたポリシーを使用しない場合は、ローカルに直接アタッチされたポリシーを使用できます。Oracle RTD Webサービスでより厳格なポリシーを必要とする場合は、ポリシーを直接アタッチする必要があります。具体的には、次のWebサービスがこれに該当します。

- WorkBenchEndPointService2 (エンドポイント名: WorkBenchEndPointPort)

- SDClient2 (エンドポイント名: SDClientPort)

- BatchManagerClientService2 (エンドポイント名: BatchManager)

- ExternalChoiceService2 (エンドポイント名: ExternalChoice)

- AdministrationClientEndPointService2 (エンドポイント名: AdministrationClientEndPointPort)

ポリシーをグローバル・アタッチから直接アタッチに置き換えるには、次の手順を実行します:

1. Fusion Middleware Controlにログインします。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』を参照してください。

2. 「ターゲット・ナビゲーション・ペイン」の「アプリケーション・デプロイメント」で、OracleRTDサーバーのエントリを右クリックし、「Webサービス」を選択します。

3. 「Webサービスの詳細」領域で「Webサービス・エンドポイント」タブをクリックします。

4. WorkBenchEndPointService2という名前のWebサービスのエンドポイント名をクリックします。

5. 「OWSMポリシー」、「グローバルにアタッチされたポリシー」でポリシーをデタッチします。

6. 「OWSMポリシー」、「直接アタッチされたポリシー」でポリシーをデタッチします。

7. 「使用可能なポリシー」のリストから「oracle/wss11_saml_or_username_token_with_message_protection_service_policy」を選択して「アタッチ」をクリックし、「OK」をクリックします。
WebサービスのSDClient2、BatchManagerClientService2、ExternalChoiceService2およびAdministrationClientEndPointService2に対して、手順3から7を繰り返します。

8. Oracle RTDが含まれているドメインを停止して再開します。

Webサービスのセキュリティの構成および変更の詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。

C ストアド・プロシージャからのデータ・ソースの例

この付録では、Oracle、SQL ServerおよびDB2からデータ・ソースを作成する方法の例だけでなく、これらのデータ・ソースからエンティティとセッションの属性を作成する方法の例も示します。

例は、CrossSellCustomers表に基づいています。この表の設定の詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のCrossSellサンプル・データの移入に関する項を参照してください。

この付録には次のトピックが含まれます:

- 第C.1項「単一結果のストアド・プロシージャからのデータ・ソースの作成」

- 第C.2項「結果セットが1つのストアド・プロシージャからのデータ・ソースの作成」

- 第C.3項「結果セットが2つのストアド・プロシージャからのデータ・ソースの作成」

C.1 単一結果のストアド・プロシージャからのデータ・ソースの作成

単一結果のストアド・プロシージャからデータ・ソースを作成する手順は次のとおりです。

1. 適切なコマンドを使用して、Oracle、SQL ServerまたはDB2のデータベースにストアド・プロシージャのGet_Single_CustomerInfoを作成します。
(A) Oracle

CREATE PROCEDURE GET_SINGLE_CUSTOMERINFO
(
P_ID IN INTEGER,
P_AGE OUT INTEGER,
P_OCCUPATION OUT VARCHAR2,
P_LASTSTATEMENTBALANCE OUT FLOAT
)
AS
BEGIN
SELECT AGE, OCCUPATION, LASTSTATEMENTBALANCE INTO P_AGE, P_OCCUPATION,
P_LASTSTATEMENTBALANCE
FROM CROSSSELLCUSTOMERS
WHERE CROSSSELLCUSTOMERS.ID = P_ID;
END;

(B) SQL Server

CREATE PROCEDURE Get_Single_CustomerInfo
@pId INTEGER,
@pAge INTEGER OUTPUT,
@pOccupation VARCHAR(20) OUTPUT,
@pLastStatementBalance FLOAT OUTPUT
AS
SELECT @pAge = Age,
@pOccupation = Occupation,
@pLastStatementBalance = LastStatementBalance
FROM CrossSellCustomers
WHERE Id = @pId;
GO

(C) DB2

CREATE PROCEDURE DB2ADMIN.GET_SINGLE_CUSTOMERINFO
(
IN P_ID INTEGER,
OUT P_AGE INTEGER,
OUT P_OCCUPATION VARCHAR(20),
OUT P_LASTSTATEMENTBALANCE REAL
)
LANGUAGE SQL
P1: BEGIN
DECLARE CURSOR_ CURSOR WITH RETURN FOR
SELECT AGE, OCCUPATION, LASTSTATEMENTBALANCE
FROM DB2ADMIN.CROSSSELLCUSTOMERS AS CROSSSELLCUSTOMERS
WHERE CROSSSELLCUSTOMERS.ID = P_ID;
OPEN CURSOR_;
FETCH CURSOR_ INTO P_AGE, P_OCCUPATION, P_LASTSTATEMENTBALANCE;
CLOSE CURSOR_;
END P1

2. 使用しているアプリケーション・サーバーにストアド・プロシージャのJDBCデータ・ソースを作成します。
アプリケーション・サーバーにデータ・ソースを作成する方法の詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsのデータ・アクセスの構成に関する項を参照してください。

3. デシジョン・スタジオで、データベースからGet_Single_CustomerInfoストアド・プロシージャをインポートすることで、ストアド・プロシージャのデータ・ソースであるDS_Single_Customerを作成します。
SQL Server用ストアド・プロシージャの場合は、パラメータのpAge、pOccupationおよびpLastStatementBalanceの方向をInput/OutputからOutputに変更します。

4. デシジョン・スタジオで、データ・ソースのDS_Single_Customerをインポートすることで、エンティティのEnt_Single_Customerを作成します。

5. Integer型のId属性を追加します。

6. 「マッピング」タブの「データ・ソース入力値」領域で、入力列の「pId」の入力値をIdに設定します。

7. 「セッション」エンティティを開き、新しい属性のcust_spを追加し、データ型をEnt_Single_Customerに設定します。

C.2 結果セットが1つのストアド・プロシージャからのデータ・ソースの作成

結果セットが1つのストアド・プロシージャからデータ・ソースを作成する手順は次のとおりです。

1. 適切なコマンドを使用して、Oracle、SQL ServerまたはDB2のデータベースにストアド・プロシージャのGet_OneSet_CustomerInfoを作成します。
(A) Oracle

CREATE PROCEDURE GET_ONESET_CUSTOMERINFO
(
P_CREDITLINEAMOUNT IN INTEGER,
CURSOR_ IN OUT TYPES.REF_CURSOR
)
AS
BEGIN
OPEN CURSOR_ FOR
SELECT * FROM CROSSSELLCUSTOMERS
WHERE CREDITLINEAMOUNT >= P_CREDITLINEAMOUNT;
END;

(B) SQL Server

CREATE PROCEDURE Get_OneSet_CustomerInfo
@pCreditLineAmount INTEGER
AS
SET NOCOUNT ON;
SELECT * FROM CrossSellCustomers
WHERE CreditLineAmount >= @pCreditLineAmount;
GO

(C) DB2

CREATE PROCEDURE DB2ADMIN.GET_ONESET_CUSTOMERINFO
(
IN P_CREDITLINEAMOUNT INTEGER
)
DYNAMIC RESULT SETS 1
LANGUAGE SQL
P1: BEGIN
DECLARE CURSOR_ CURSOR WITH RETURN FOR
SELECT * FROM DB2ADMIN.CROSSSELLCUSTOMERS AS CROSSSELLCUSTOMERS
WHERE CROSSSELLCUSTOMERS.CREDITLINEAMOUNT >= P_CREDITLINEAMOUNT;
OPEN CURSOR_;
END P1

2. 使用しているアプリケーション・サーバーにストアド・プロシージャのJDBCデータ・ソースを作成します。
アプリケーション・サーバーにデータ・ソースを作成する方法の詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsのデータ・アクセスの構成に関する項を参照してください。

3. デシジョン・スタジオで、データベースからGet_OneSet_CustomerInfoストアド・プロシージャをインポートすることで、ストアド・プロシージャのデータ・ソースであるDS_OneSet_Customerを作成します。

4. 「結果セットの詳細」セクションで、結果セットを追加します。

5. 「複数の行を許可」チェック・ボックスを選択します。

6. SQL Server用ストアド・プロシージャの場合は、所定のデータ型で示されているとおりに次の列名を追加します。

- Age [Integer]

- Occupation [String]

- LastStatementBalance [Double]

Oracle用ストアド・プロシージャとDB2用ストアド・プロシージャの場合は、所定のデータ型で示されているとおりに次の列名を追加します。

- AGE [Integer]

- OCCUPATION [String]

- LASTSTATEMENTBALANCE [Double]

7. デシジョン・スタジオで、データ・ソースのDS_OneSet_Customerをインポートすることで、エンティティのEnt_OneSet_Customerを作成します。

8. Integerデータ型のCreditLineAmount属性を追加し、そのデフォルト値を50000に設定します。
これにより、結果は約30行に制限されます。

9. 属性のAge、OccupationおよびLastStatementBalanceの「配列」列を選択します。

10. 「マッピング」タブの「データ・ソース入力値」領域で、入力列の「pCreditLineAmount」の入力値をCreditLineAmountに設定します。

11. 「セッション」エンティティを開き、新しい属性のcust_oneset_spを追加し、データ型をEnt_OneSet_Customerに設定します。

C.3 結果セットが2つのストアド・プロシージャからのデータ・ソースの作成

結果セットが2つのストアド・プロシージャからデータ・ソースを作成する手順は次のとおりです。

1. 適切なコマンドを使用して、Oracle、SQL ServerまたはDB2のデータベースにストアド・プロシージャのGet_TwoSets_CustomerInfoを作成します。
(A) Oracle

CREATE PROCEDURE GET_TWOSETS_CUSTOMERINFO
(
P_CREDITLINEAMOUNT IN INTEGER,
CURSOR1_ IN OUT TYPES.REF_CURSOR,
CURSOR2_ IN OUT TYPES.REF_CURSOR
)
AS
BEGIN
OPEN CURSOR1_ FOR
SELECT * FROM CROSSSELLCUSTOMERS
WHERE CREDITLINEAMOUNT >= P_CREDITLINEAMOUNT;

OPEN CURSOR2_ FOR
SELECT * FROM CROSSSELLCUSTOMERS
WHERE CARDTYPE = 'Platinum' AND CREDITLINEAMOUNT >= P_CREDITLINEAMOUNT;
END;

(B) SQL Server

CREATE PROCEDURE Get_TwoSets_CustomerInfo
@pCreditLineAmount INTEGER
AS
SET NOCOUNT ON;
SELECT * FROM CrossSellCustomers
WHERE CreditLineAmount >= @pCreditLineAmount;
SELECT * FROM CrossSellCustomers
WHERE CreditLineAmount >= @pCreditLineAmount AND CardType = 'Platinum';
GO

(C) DB2

CREATE PROCEDURE DB2ADMIN.GET_TWOSETS_CUSTOMERINFO
(
IN P_CREDITLINEAMOUNT INTEGER
)
DYNAMIC RESULT SETS 2
LANGUAGE SQL
P1: BEGIN
DECLARE CURSOR1_ CURSOR WITH RETURN FOR
SELECT * FROM DB2ADMIN.CROSSSELLCUSTOMERS AS CROSSSELLCUSTOMERS
WHERE CROSSSELLCUSTOMERS.CREDITLINEAMOUNT >= P_CREDITLINEAMOUNT;

DECLARE CURSOR2_ CURSOR WITH RETURN FOR
SELECT * FROM DB2ADMIN.CROSSSELLCUSTOMERS AS CROSSSELLCUSTOMERS
WHERE CROSSSELLCUSTOMERS.CREDITLINEAMOUNT >= P_CREDITLINEAMOUNT
AND CROSSSELLCUSTOMERS.CARDTYPE = 'Platinum';

OPEN CURSOR1_;
OPEN CURSOR2_;
END P1

2. 使用しているアプリケーション・サーバーにストアド・プロシージャのJDBCデータ・ソースを作成します。
アプリケーション・サーバーにデータ・ソースを作成する方法の詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsのデータ・アクセスの構成に関する項を参照してください。

3. デシジョン・スタジオで、データベースからGet_TwoSets_CustomerInfoストアド・プロシージャをインポートすることで、ストアド・プロシージャのデータ・ソースのDS_TwoSets_Customerを作成します。

4. 「結果セットの詳細」セクションで、結果セットを追加します。

5. 「複数の行を許可」チェック・ボックスを選択します。

6. SQL Server用ストアド・プロシージャの場合は、所定のデータ型で示されているとおりに次の列名を追加します。

- Age [Integer]

- Occupation [String]

- LastStatementBalance [Double]

Oracle用ストアド・プロシージャとDB2用ストアド・プロシージャの場合は、所定のデータ型で示されているとおりに次の列名を追加します。

- AGE [Integer]

- OCCUPATION [String]

- LASTSTATEMENTBALANCE [Double]

7. 2番目の結果セットに対して手順4から6を繰り返します。

8. デシジョン・スタジオで、データ・ソースのDS_TwoSets_Customerをインポートすることで、エンティティのEnt_TwoSets_Customerを作成します。

9. Integerデータ型のCreditLineAmount属性を追加し、そのデフォルト値を50000に設定します。
これにより、結果は約30行に制限されます。

10. 属性のAge、OccupationおよびLastStatementBalanceの「配列」列を選択します。

11. 「マッピング」タブの「データ・ソース入力値」領域で、入力列の「pCreditLineAmount」の入力値をCreditLineAmountに設定します。

12. 「セッション」エンティティを開き、新しい属性のcust_twosets_spを追加し、データ型をEnt_TwoSets_Customerに設定します。

D インライン・サービス・メタデータのローカライズ

インライン・サービス・メタデータのローカライズにより、ルール・エディタおよびデシジョン・センターのレポートに表示されるローカル言語名を変更できます。ローカライズできるインライン・サービスのメタデータ要素は、エンティティ、エンティティ属性、選択肢属性およびアプリケーション・パラメータです。

注意:

この付録では、ローカライズの主用途である、エンティティ名とエンティティ属性名のローカライズを中心に説明します。

この付録には次のトピックが含まれます:

- 第D.1「ローカライズの概要」

- 第D.2「ローカライズのソース・テキスト文字列とターゲット・テキスト文字列」

- 第D.3「インライン・サービス・ローカライズの設定」

D.1 ローカライズの概要

ローカライズは、1つの関数によって実現されます。この関数により、インライン・サービス・メタデータ値のソース名とターゲット名(メッセージとも呼ばれます)を検索する場所が指定されます。ソース名とターゲット名は、この関数自体の中でも記述できますが、通常はテキスト・ファイルまたはデータベース表に格納します。この関数名を「メッセージ関数」アプリケーション・パラメータの値として選択します。インライン・サービスを再デプロイすると、ローカライズされたテキストをルール・エディタの画面やデシジョン・センターのレポートに表示できるようになります。

要約すると、ローカライズの設定で必要な主な要素は次の3つです。

- ローカライズ・メッセージのソース(インライン・サービス内のテキスト・ファイルまたはデータベースに格納できます)

- ローカライズ・メッセージを検索するローカライズ関数

- ローカライズ関数はアプリケーションの「メッセージ関数」パラメータとして設定する必要がある

インライン・サービスをデシジョン・スタジオで編集して、アプリケーション・サーバーにデプロイする必要があります。ユーザーがデシジョン・センターにログインすると、ローカライズされたメッセージが検索されます。

ローカライズ・データの標準的な2つの設定方法の例と、Decision Managerのレポートにおけるローカライズの効果を図D-1に示します。

図D-1 ローカライズ設定とデシジョン・センターのレポートの例

「図D-1 ローカライズ設定とデシジョン・センターのレポートの例」の説明

注意:

この付録では、主にデシジョン・センターのレポートにおけるローカライズの効果について説明しますが、ルール・エディタの画面でも同様の効果があります。ルール・エディタの画面では、ローカライズされたエンティティ名およびエンティティ属性名も表示されます。

D.2 ローカライズのソース・テキスト文字列とターゲット・テキスト文字列

ローカライズ関数自体、テキスト・ファイルまたはデータベース表のいずれで指定するかを問わず、ローカライズ・データは、対応するソース・テキスト文字列とターゲット・テキスト文字列の組で構成されます。

ソース・テキスト文字列

ソース・テキスト文字列は、インライン・サービス要素の内部IDに由来します(通常、インライン・サービスの各画面にデフォルトで表示されるラベルではありません)。

エンティティIDは、デフォルトでは大文字で始まります(例: Address)。 属性IDおよびパラメータIDは、デフォルトでは小文字で始まります(例: houseNumber)。これらのIDはデシジョン・スタジオで変更できます。そのため、「トグル」アイコンをクリックしてID値を表示することが重要です。このアイコンをクリックすると、オブジェクト名の表示がラベルとオブジェクトIDの間で切り替わります。

エンティティのうち、別のエンティティの属性でもあるエンティティには、エンティティID(明示的なエンティティ要素として参照される場合)と属性ID(上位エンティティの属性として参照される場合)の両方があります。たとえば、AddressエンティティがCustomerの属性である場合、Addressとしてのデフォルトの明示的エンティティIDはAddressであり、Customer内のAddressとしてのデフォルト属性IDはCustomer.addressです。

この項の以降の例では、Customerエンティティの属性の1つにAddressエンティティがあり、AddressエンティティにはstreetとhouseNumberという属性があると仮定します。

インライン・サービスの一般的な要素(エンティティなど)の場合、ソース・テキスト文字列の形式は次のとおりです。

- <element_ID>
例: Customer, Address, Offers

インライン・サービスの一般的な要素(エンティティなど)の属性またはパラメータの場合、ソース・テキスト文字列の形式は次のとおりです。

- <element_ID>.<element_attribute_or_parameter_ID>
例: Customer.address, Address.street, Offers.profitMargin

Applicationのパラメータの場合、ソース・テキスト文字列の形式は次のとおりです。

- Application.<parameter_ID>
例: Application.serviceTest

Sessionの属性の場合、ソース・テキスト文字列の形式は次のとおりです。

- ApplicationSession.<attribute_ID>
例: ApplicationSession.customer

インライン・サービスの特殊要素であるApplicationとSessionは、単独のソース・テキスト文字列としてローカライズで必要になることはありません。この2つはOracle RTDで内部的に処理されます。

注意:

ソース・テキスト文字列で使用できるドット区切りの構成要素は2つまでです。

たとえば、次のソース・テキスト文字列はいずれも無効です。

- Customer.Address (2番目の値は属性IDであることが必要です)

- Customer.Address.street (2番目の属性は属性IDであることが必要です。また、使用できる値は2つのみです)

- Customer.address.houseNumber (使用できる値は2つのみです)

ターゲット・テキスト文字列

ターゲット・テキスト文字列は自由形式のテキスト文字列です。通常はローカル言語で記述しますが、必ずしもその必要はありません。ターゲット・テキスト文字列には空白文字を含めることができます。

ローカライズの設定後、ルール・エディタ(値リストと条件)およびデシジョン・センターのレポートにターゲット・テキスト文字列が表示されます。

ルール・エディタの例

ソース・テキスト文字列とターゲット・テキスト文字列は次のとおりです。

- ApplicationSession.ball=[BALL]

- Ball=[BALL]

- Ball.color=[COLOUR]

- Ball.size=[SIZE]

この場合、ルール・エディタでは、次の例のようにローカライズされたメタデータが条件に表示されます。

画像img_005.pngの説明

D.3 インライン・サービス・ローカライズの設定

ローカライズ関数は、入力パラメータjava.util.Localeをとり、java.util.Mapまたはそのサブクラス(java.util.Propertiesなど)を返すインライン・サービス関数です。

ソース・テキスト文字列とターゲット・テキスト文字列の詳細は、第D.2項「ローカライズのソース・テキスト文字列とターゲット・テキスト文字列」を参照してください。

返されたマップには、ソース・テキスト文字列とターゲット・テキスト文字列の組が含まれています。マップ・キーはソース・テキスト文字列(Customer.addressなど)で、ターゲット・テキスト文字列(indirizzoなど)の検索に使用されます。

この項には次のトピックが含まれます:

- 第D.3.1項「ローカライズ・データをテキスト・ファイルに格納する場合の設定例」

- 第D.3.2項「ローカライズ・データをデータベースに格納する場合の設定例」

D.3.1 ローカライズ・データをテキスト・ファイルに格納する場合の設定例

このシナリオでは、ユーザーのブラウザの言語をローカライズ・メッセージ・テキスト・ファイルのキーとして使用する方法について説明します。たとえば、ユーザーのブラウザの言語が英語に設定されている場合は、対応するサーバー・ロケールがen_US (米国の場合)またはen_CA (カナダの場合)に設定されている可能性があります。国固有の翻訳が不要であれば、対応するファイル名はmessages_en_US.propertiesまたはmessages_en.propertiesになります。

該当するファイルを検索するロジックは次のとおりです。

- まず、完全なロケールが使用されます。たとえば、pt-BR (ポルトガル語 - ブラジル)です。対応するファイル名はmessages_pt_BR.propertiesです。

- このファイルが見つからない場合、ロケールの言語部分のみが使用されます。ファイル名はmessages_pt.propertiesです。

- このファイルが見つからない場合、検索ロジックはサーバーのデフォルト・ロケール(en-USなど)に戻り、前述の2つのステップが繰り返されます。

- このフォールバック・ロケールに対応するファイルが見つからない場合、デフォルト・ファイルが使用されます。ファイル名はmessages.propertiesです。

- 最後の手段として、空のマップが返されます。これは、ローカライズが用意されていない場合に、Oracle RTDがローカライズされたメッセージを絶えず要求しないようにするためです。

インライン・サービス・メタデータのローカライズを実装するには、次の手順を実行します:

1. インライン・サービスはアプリケーション・サーバーにデプロイされるため、すべてのメッセージ・ファイルをアプリケーション・サーバーのファイル・システムに伝播させる必要があります。つまり、インライン・サービスと一緒にデプロイする必要があります。このため、すべてのメッセージ・ファイルをインライン・サービスのdc/jspフォルダに格納する必要があります。
このフォルダが存在しない場合は、デシジョン・スタジオで次の例のように作成します。

画像img_007.pngの説明

2. このフォルダに、図D-1のテキスト・ファイルの例にあるエントリのような、ソース・テキスト文字列とターゲット・テキスト文字列を記述したファイルを作成します。
画像loc_dcjsp.gifの説明

3. ローカライズ関数を作成します。
この例では、ローカライズ関数の名前をGet Messages From Propertiesとします。

4. ローカライズ関数に対して、次の操作を行います。

- 戻り値を指定します。

- 「データ型」で「その他」を選択し、「Javaクラス名」にPropertiesと入力します。
画像img_013.pngの説明

[インライン・サービス関数でjava.util.*パッケージがすでにインポートされているので、戻り型の完全名(java.util.Properties)を指定する必要はありません。]

5. 同様に、関数の入力パラメータをjava.util.Locale型で追加します。

6. 次のようなコードを関数ロジックに追加します。

String language = locale.getLanguage();
String country = locale.getCountry();

Properties props = new Properties();

java.io.File appDir = com.sigmadynamics.sdo.loading.AppFactory.getInstance().getAppLocation(
Application.getApp().getName(), Application.getApp().getDeploymentState());
java.io.File dcDir = new java.io.File(appDir, "dc/jsp");

Locale fallbackLocale = Locale.getDefault();
String fbLanguage = fallbackLocale.getLanguage();
String fbCountry = fallbackLocale.getCountry();

String fileName = "resources_" + language;
if (!country.isEmpty()) fileName += "_" + country;
fileName += ".properties";
java.io.File propFile = new java.io.File(dcDir, fileName);
if (!propFile.exists()) {
fileName = "resources_" + language + ".properties";
propFile = new java.io.File(dcDir, fileName);
}
if (!propFile.exists()) {
fileName = "resources_" + fbLanguage;
if (!fbCountry.isEmpty()) fileName += "_" + fbCountry;
fileName += ".properties";
propFile = new java.io.File(dcDir, fileName);
}
if (!propFile.exists()) {
fileName = "resources_" + fbLanguage + ".properties";
propFile = new java.io.File(dcDir, fileName);
}
if (!propFile.exists()) {
fileName = "resources.properties";
propFile = new java.io.File(dcDir, fileName);
}
if (propFile.exists()) {
try {
props.load(new java.io.FileInputStream(propFile));
} catch (Exception e) {
logError("Error retrieving localized messages from properties (locale ["
+locale.toString()+"], file ["+propFile.getName()+"])", e);
}
}
return props;

7. この関数をアプリケーションのメッセージ関数として割り当てます。
画像img_015.pngの説明

8. インライン・サービスを再デプロイします。

9. ブラウザ(次の例のブラウザはInternet Explorerです)を起動し、目的の言語を追加します。

画像img_017.pngの説明

10. 追加した言語をブラウザの「言語の優先順位」リストの先頭に移動します。

画像img_019.pngの説明

デシジョン・センターにログインすると、図D-1のようにローカライズされたレポートを表示できます。

D.3.2 ローカライズ・データをデータベースに格納する場合の設定例

このシナリオでは、ローカライズ・データおよびローカライズ情報をデータベース表に格納します。表と列には任意の名前を使用できます。

この例では、表名をLOCALIZATIONとします。この表にはLOCALE列、SELECTOR列(ソース・テキスト文字列)、MESSAGE列(ターゲット・テキスト文字列)があります。また、データベースはOracle RTDデータベースであり、データソースにはSDDSを使用すると仮定します。

インライン・サービス・メタデータのローカライズを実装するには、次の手順を実行します:

1. データベースで次のコマンドを実行して表を作成します。

CREATE TABLE LOCALIZATION (
LOCALE VARCHAR2(8) NOT NULL,
SELECTOR VARCHAR2(200) NOT NULL,
MESSAGE NVARCHAR2(2000)
)

ターゲット・テキストにはあらゆる文字セットが使用される可能性があるため、ターゲット・テキスト列はNVARCHAR2型にすることが重要です。

2. データベース表にデータを入力します。
[この手順は、ここで行っても後で行っても構いません。]

画像loc_db2.gifの説明

3. ローカライズ関数(Get Messages From Databaseなど)を作成します。

4. ローカライズ関数に対して、次の操作を行います。

- 戻り値を指定します。

- 「データ型」で「その他」を選択し、「Javaクラス名」にPropertiesと入力します。

- 戻り型をMapに設定します。

5. 同様に、関数の入力パラメータをjava.util.Locale型で追加します。

6. 次のようなコードを関数ロジックに追加します。

java.sql.Connection conn = null;
java.sql.PreparedStatement pst = null;
java.sql.ResultSet rs = null;
Map<String, String> strings = new HashMap<String, String>();

try {
conn =     com.sigmadynamics.server.SDDataSource.getDataSource("SDDS").getConnection();
pst = conn.prepareStatement("select * from Localization where locale=?");
pst.setString(1, locale.getLanguage() + (locale.getCountry().isEmpty() ? "" : "_" + locale.getCountry()));
rs = pst.executeQuery();
if (!rs.next()) {
rs.close();
pst.setString(1, locale.getLanguage());
rs = pst.executeQuery();
} else {
strings.put(rs.getString(2), rs.getString(3)); // selector + message
}
while (rs.next()) {
strings.put(rs.getString(2), rs.getString(3)); // selector + message
}
} catch (Exception e) {
logError("Error retrieving localized messages from database (locale ["+locale.toString()+"])", e);

} finally {
try {
rs.close();
pst.close();
conn.close();
} catch (Exception e) {}
}
return strings;

7. この関数をアプリケーションのメッセージ関数として割り当てます。

8. インライン・サービスを再デプロイします。

9. ブラウザの言語設定(第D.3.1項「ローカライズ・データをテキスト・ファイルに格納する場合の設定例」の手順9と10)を行います。

デシジョン・センターにログインすると、図D-1のようにローカライズされたレポートを表示できます。

Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved.