| Oracle® Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイド 11g リリース1 (11.1.1) B72429-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Real-Time Decisionsプラットフォーム開発者ガイド 11g リリース1 (11.1.1) B72429-01 |
|
前 |
次 |
これは、インライン・サービスを作成および構成する手順について説明するチュートリアル・セクションの序章です。この章では、インライン・サービスの主な要素(データ・ソース、エンティティ、インフォーマント、アドバイザ、 選択肢グループ、モデル、デシジョン)について説明し、これらの要素をデシジョン・スタジオで作成およびテストする方法を示します。
このチュートリアル・セクションは、特定のプロセスとその特性をリアルタイムで継続的に監視するインライン・サービスを構成する方法を説明することを目的としています。このタイプのインライン・サービスは、ビジネス・ユーザーが、様々なビジネス・イベントおよび時間の経過に伴うビジネス・イベントの誘因の変化を分析する際の指針となります。
このチュートリアルのインライン・サービスは、クレジット・カード会社のコール・センターに関するものです。このインライン・サービスでは、顧客およびコール・センターの業務系システムに関するデータを収集し、その通話内容と解決方法についての情報を分析します。
このインライン・サービスの目標は、通話のパターン、通話理由および顧客を分析することです。後述の各項では、このインライン・サービスの機能を拡張して、抱合せ販売のオファーについてCRMシステムに提案を行い、さらにその提案の結果についてサービスにフィードバックを加えます。
この章には次のトピックが含まれます:
インライン・サービスはデシジョン・スタジオ開発ツールを使用して作成されます。一般に、インライン・サービスは次のように作成されます。
デシジョン・スタジオでプロジェクトが開始されます。
要素がそのプロジェクトに追加され、目的のビジネス・ニーズをサポートするように構成されます。
操作を実行する特定の要素に、Javaスクリプトレットの形式でロジックが追加されます。
インライン・サービスが、実行されるDecision Serverにデプロイされます。
インライン・サービスの使用から生成されるレポートがデシジョン・センターに表示されます。
このチュートリアルでは、次の要素が追加および構成されます。
アプリケーション: 必要なアプリケーション・レベルの設定を行い、インライン・サービスのセキュリティを定義します。アプリケーション要素は、各インライン・サービスに対して自動的に作成されます。
パフォーマンス目標: スコアリングを使用して最適化されるメトリックで構成される組織目標を表します。たとえば、収益や通話継続時間はパフォーマンス・メトリックです。組織目標は、通話継続時間を最小化して収益を最大化すること、などになります
データ・ソース: 外部データ・ソースからのデータのプロバイダとして機能します。データ・ソースのデータの構造および形式は様々に異なります。例:
RDBMS表の行と列
ストアド・プロシージャからの出力値と結果行セット
データ・ソースは、エンティティ要素にマップできるデータのプロバイダで、エンティティ要素にデータを提供します。
たとえば、このチュートリアルでは、データベース内の表に接続するデータ・ソースを追加します。この表には顧客データが含まれます。
エンティティ: 1つ以上のデータ・ソースから構築されるデータの論理的表現です。エンティティは次の目的を果たします。
組織、分析およびモデル化のためのオブジェクトにデータを編成する。
様々なソースのデータのJavaコードから、比較的簡単でわかりやすいアクセスを可能にする。
データ取得の詳細を隠し、ロジックを変更せずにこれらの詳細を変更できるようにする。
データ取得のメカニズムを隠し、ユーザーがデータの取得に使用されるAPIを処理せずに済むようにする。
オブジェクトを共有する必要がある場合に、オブジェクトの共有をサポートする。たとえば、サービス・エージェントを表すオブジェクトは複数のセッションで使用される場合があります。
エンティティの属性はキー値にすることができます。エンティティ・キーは、エンティティのインスタンスの特定に使用されます。
たとえば、このチュートリアルでは、顧客を表すエンティティを作成します。そのエンティティの属性は、値のデータ・ソースにマップされます。顧客IDがその顧客エンティティのキーとして選択されます。
後で、通話を表すエンティティも作成します。
セッション・エンティティ: Oracle RTDにおけるセッションは、単一のインスタンスに固有のフロント・エンド・アプリケーションとのやりとりを表します。たとえば、ある顧客がコール・センターに電話をかけたとき、その単一の顧客とエージェントとのやりとりがセッションになります。同様に、顧客によるWebサイトの訪問や、その訪問時のページ間の移動もセッションの例といえます。
セッション・エンティティは、インライン・サービスの特殊なエンティティです。セッション・エンティティは、定義された特定のセッションに固有の属性のコンテナを表します。セッション・キーによって個々の各セッションが一意に識別されます。
セッション・エンティティの属性として設定することにより、定義されたエンティティをセッションに関連付けることができます。セッション属性であるエンティティのみが、そのキーをセッション・キーとしてマーク付けできます。
たとえば、このチュートリアルでは、顧客エンティティを属性としてセッション・エンティティに追加し、セッション・キーとして顧客キー値である顧客IDを選択します。
インフォーマント: インフォーマントとは、インライン・サービス内で構成する統合点です。インフォーマントは、フロント・エンド・クライアントがビジネス上のやりとりに関するデータをその発生時にOracle RTDに提供できようにするほか、Decision Serverでビジネス・ロジックをトリガーできます。インフォーマントはOracle RTDによるプロセスの「監視」を可能にする一方向のフィードを表しますが、プロセスとのやりとりは行いません。
このチュートリアルでは、まずテスト用インフォーマントを作成し、その後CRMシステムからすべてのサービス・データを収集するインフォーマントを作成します。
このチュートリアルの後半では、モデルの予測の成功または失敗について、インライン・サービスにフィードバックを行うインフォーマントを作成します。
選択肢グループ: インライン・サービスに選択肢の論理階層を作成するときに使用します。選択肢グループは、Oracle RTDモデリングおよびデシジョンに使用する、オファーなどのスタディ対象を編成する手段を提供します。
たとえば、このチュートリアルでは、まず通話理由を編成する選択肢グループを作成します。インライン・サービスを拡張してアドバイザを含める際に、選択肢グループを使用して、サービス・センター・エージェントに提案される抱合せ販売のオファーを編成します。
モデル: 組込み分析モデルによる自己学習および自動分析が可能です。モデルは、単にデータを分析する場合にも、ビジネス・プロセスへの提案を行うときに使用する確率スコアを生成する場合にも使用できます。
このチュートリアルでは、通話理由を分析するモデルを作成し、その後、顧客に最も受け入れられる可能性のある抱合せ販売のオファーの決定に役立つモデルを作成します。
デシジョン: デシジョンは、アドバイザが適切な選択肢を決定し、各選択肢のスコアを動的に計算し、母集団のセグメントと指定パフォーマンス目標に応じてスコアに重みを付け、選択肢のランク付けリストをアドバイザに返すために使用されます。
アドバイザ: コール元のビジネス・プロセスに情報を返す統合点です。アドバイザは、ランク付けされた選択肢を1つ以上返すインライン・サービスでデシジョンをコールします。
このチュートリアルでは、クレジット・カード・サービス・センターへの通話者に対して提示できるオファーの選択肢グループを作成します。アドバイザはデシジョンを呼び出し、通話および通話者に関する情報に基づいて、通話者にとって最適なオファーを決定します。アドバイザは、その抱合せ販売の提案をフロント・エンド・アプリケーションに渡します。これによって、コール・センター・エージェントが抱合せ販売を提案できるようになります。
インライン・サービスをReal-Time Decision Serverにデプロイし、インライン・サービスの結果をデシジョン・センターで表示できるためには、必要なロールが付与されていることが必要です。このロールは、ユーザー名とパスワードを介することで提供されます。
このチュートリアルでは、BIConsumerおよびBIAuthorのロールが割り当てられた有効なユーザー・ログインとパスワードが作成されていることを前提としています。
必要に応じて、Oracle RTDシステムのインストールと設定を担当する管理者に問い合せてください。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「Oracle Real-Time Decisionsのセキュリティ」を参照してください。
要素の名前および説明は、ビジネス・ユーザーのユーザー・インタフェースであるデシジョン・センターで広く使用されます。したがって、要素を作成する際は、時間をかけてわかりやすい要素名を付け、すべての要素に適切な説明を記述することが非常に重要です。
始める前に、Real-Time Decision Serverが起動されていることを確認します。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle Real-Time Decisionsの起動と停止に関する項を参照してください。
アプリケーション要素を構成する手順は次のとおりです。
RTD_HOME\eclipse\eclipse.exeを実行し、デシジョン・スタジオを起動します。デシジョン・スタジオが開いたら、「ファイル」→「新規」→「インライン・サービス・プロジェクト」を選択して、新規プロジェクトを開始します。
|
注意: このチュートリアルでは、新規インストールを元のプリファレンス設定で使用することを前提としています。すでにデシジョン・スタジオまたはEclipseを使用している場合は、新しいワークスペースに切り替えることもできます。新しいワークスペースに切り替えるには、「ファイル」→ワークスペースの切替えを選択し、新しいワークスペース・フォルダを選択します。 |
プロジェクト名としてTutorialを指定し、「基本」テンプレートを選択します。「終了」をクリックします。インライン・サービスのアップグレードについて尋ねられたら、「はい」を選択します。「インライン・サービス・エクスプローラ」にインライン・サービス・プロジェクトが作成されます。デフォルトでは、インライン・サービス・プロジェクトのファイルは、デシジョン・スタジオのワークスペースのプロジェクトと同じ名前のフォルダに保存されます(C:\Documents and Settings\Windows_user\Oracle RTD Studio\Tutorialなど)。
デシジョン・スタジオで、「チュートリアル」→「サーバー・メタデータ」フォルダを開きます。「アプリケーション」要素をダブルクリックし、要素エディタを表示します。要素エディタに、Tutorialインライン・サービスの説明を入力します。
組織データにアクセスするには、次の2つの要素を構成します。
データ・ソース: データベース内のデータ構造を表す要素です。
エンティティ: 1つ以上のデータ・ソースによって移入可能なデータ、またはインフォーマントによって取得されるコンテキスト・データの論理的表現です。
この項には次のトピックが含まれます:
データ・ソースを追加するには、新しいデータ・ソースを作成してからデータ・ソースの出力をインポートします。
この項には次のトピックが含まれます:
データ・ソースを作成する手順は次のとおりです。
デシジョン・スタジオのインライン・サービス・エクスプローラで、「データ・ソース」を選択してダブルクリックします。「新規SQLデータ・ソース」を選択します。「ラベルの表示」で「Customer Data Source」と入力し、「OK」をクリックします。データ・ソース・エディタが表示されます。
「説明」で、データ・ソースの説明に「Customer data from a database table」と入力します。
適切な説明であることが非常に重要です。これらの説明はデシジョン・センターで使用され、ビジネス・ユーザーがレポートおよび分析のコンポーネントを識別するために必要不可欠です。
|
注意: いくつかの別のデータ・ソースがすでに定義されています。これらはインライン・サービスのフレームワークの一部であり、このチュートリアルでは使用しません。 |
データ・ソースの出力は、データベースから取得された列になります。出力に表内のすべての列が含まれる必要はありません。
データ・ソースの出力をインポートする手順は次のとおりです。
「インポート」をクリックします。「データベース表のインポート」が表示されます。「サーバー」の横に各自のサーバーが表示されます。「次」をクリックし、サーバーに接続します。「表またはビューの選択」が表示されます。
「JDBCデータ・ソース」で「SDDS」を選択します。次に、「表とビュー」で「CrossSellCustomers」を選択します。この表は、CrossSellインライン・サービスに対してInitAppDBスクリプトを実行すると作成されます。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のCrossSellサンプル・データの移入に関する項を参照してください。
「終了」をクリックします。
表のすべての列が「出力」列表にインポートされます。
データ・ソースの入力列を設定します。入力は、データ・レコードを取得する際に一致させる列です。ここでは、「出力」列表でID列名を選択し、右矢印(→)をクリックして、IDを「入力」列表に移動できます。データ型は「Integer」です。
データ・ソースの出力列を設定します。「出力」列表で、表2-1に示されている列を除いてすべてを選択し、「削除」を使用して削除します。
「ファイル」→「すべて保存」を選択して、作業内容を保存します。作業にエラーがある場合は、「問題」ビューに通知が表示されます。
|
注意: 「インポート」を使用して、データ・ソースの出力に列名およびデータ型をインポートできます。使用しない列は、「削除」で削除します。 |
データ・ソースを定義したので、対応するエンティティの定義に進みます。エンティティは、構成内の他の要素によって使用されるオブジェクトです。エンティティは、データ・ソースやインフォーマントなどのデータのソースからの抽象レベルを提供します。1つのエンティティは、多くのデータ・ソースからのデータ、あるいは計算値を持つことができます。今回は、データ・ソースの構造に直接マップされる簡単なエンティティを作成します。
この項には次のトピックが含まれます:
新しいエンティティを作成する手順は次のとおりです。
「インライン・サービス・エクスプローラ」で、「エンティティ」フォルダを右クリックし、「新規エンティティ」を選択します。「ラベルの表示」で名前としてCustomerと入力し、「OK」をクリックします。エンティティ・エディタが表示されます。「説明」でCustomer entityと入力します。
エンティティ属性の適切な説明であることが非常に重要です。それぞれのエンティティに適切な説明を追加してください。
|
注意: オブジェクトIDはJava命名規約に準拠するように自動的に作成されます。変数名は大文字と小文字が混在し、最初の1文字は小文字になります。クラス名は大文字と小文字が混在し、最初の1文字は大文字になります。ラベル名に空白が含まれている場合、オブジェクトIDの作成時に空白は削除されます。 オブジェクトのラベルとそのオブジェクトIDとの間で表示を切り替えるには、「インライン・サービス・エクスプローラ」のタスク・バーにある「トグル」アイコンを使用します。  |
「インポート」をクリックして、Customer Data Sourceから属性名とデータ型をインポートします。「選択したデータ・ソースのデータ・マッピングのビルド」オプションは選択したままにします。
「定義」タブの「デフォルト値」列で、クリックして挿入ポイントを取得し、表2-2に一覧表示されている各属性のデフォルト値を追加します。Stringデータ型の値は、自動的に二重引用符で囲まれます。
エンティティの属性に関するその他の設定も変更できます。たとえば、より複雑なインライン・サービスでは、属性のカテゴリを定義できます。これを定義するには、カテゴリ要素を作成し、属性の「プロパティ」で「カテゴリ」を使用してこれを割り当てます。属性のプロパティを表示するには、「定義」タブの属性を選択し、右クリックしてメニューから「プロパティ」を選択します。
学習に属性を使用しないように指定することもできます。インライン・サービスでカスタム・ロジックに属性を使用するが、属性をモデル入力として直接使用しない場合がこれに該当します。より具体的な例として、顧客の電話番号がある場合、電話番号を分析しても意味がありません。このような場合には、「分析に使用」の選択を解除してください。
デシジョン・センターに属性を表示するかどうか制御するには、「デシジョン・センターで表示」オプションを使用します。これは、属性が技術的な意味を持つだけで、ビジネス上の直接的な意味または関心を引くような意味がない場合に便利です。
エンティティ・オブジェクトを完全にデータ・ソースにマップするには、エンティティ属性をデータ・ソースのキー値にマップして、マッピングを完了する必要があります。その手順は次のとおりです。
Customerエンティティの「定義」タブで、「キーの追加」をクリックしてキー属性を追加します。「キーの追加」が表示されます。「ラベルの表示」にcustomerIdを表示どおりに入力します(この入力は大文字と小文字が区別されます)。キー値の説明を追加し、データ型を「Integer」に変更して「OK」をクリックします。
「ファイル」→「すべて保存」を選択して、作業内容を保存します。「問題」ビューにいくつかエラーが表示される場合があります。これは、 Customerエンティティの属性とそのデータ・ソースとの間のマッピング定義が不完全であるためです。次のセクションに進んで、マッピング定義を完了してください。
セッションは、プロセスのユニットのランタイム・データの基礎になります。セッションの期間中、データはメモリーに格納されます。エンティティに関するデータを追跡するには、これをOracle RTDフレームワークの一部であるセッション・エンティティに関連付けます。エンティティをセッションに関連付けるには、これをセッション・エンティティの属性にします。セッションに対するキーが選択されます。そのキーの固有のインスタンスが検出されると、セッションが開始されます。たとえば、Oracle RTDで追跡されるコール・センター・プロセスを考えます。セッションには、通話者とエージェントを表すエンティティが含まれます。セッション(この場合は通話)の期間中、これらのエンティティで定義されたデータおよびそれらの相互作用はメモリーに格納され、分析および意思決定に使用できます。
この項には次のトピックが含まれます:
セッション・エンティティへ属性を追加する手順は次のとおりです。
「インライン・サービス・エクスプローラ」で、「エンティティ」の下の「セッション」をダブルクリックします。
「定義」タブで「属性の追加」をクリックします。「ラベルの表示」で属性名としてcustomerと入力し、「説明」を追加します。最初のデータ型はStringです。これは、次の手順で変更します。
「データ型」で「その他」を選択します。「タイプ」選択ダイアログが表示されます。「エンティティ・タイプ」で「Customer」を選択します。「OK」をクリックします。
セッション・キーを作成する手順は次のとおりです。
「依存エンティティのセッション・キー」で「選択」をクリックします。
ツリーを展開し、セッションに関連付けられたすべてのエンティティのキーを表示します。「customer」を開き、ボックスを選択することにより「customerId」をセッション・キーとして選択します。「OK」をクリックします。
|
ヒント: Oracle RTDでは、異なるシステムが同一のインライン・サービスにインフォーマントとアドバイザを送信する場合にセッションを追跡できるよう、複数のセッション・キーをサポートしています。このチュートリアルおよび実際の多くのインストールでは、必要なセッション・キーは1つのみです。 |
エンティティ・オブジェクト・エディタで定義したマッピングにより、CustomerエンティティをCustomer Data Sourceに関連付けます。Customerエンティティの属性とCustomer Data Sourceの出力列の間のマッピングは、これらの属性がCustomer Data Sourceからインポートされたときに自動的に行われました(詳細は、第2.4.2項「エンティティの追加」を参照)。ここで、CustomerエンティティのCustomer Data Sourceの入力列の値をマップする必要があります。
Customer Data Sourceの入力列値をマップする手順は次のとおりです。
Customerエンティティを開き、「マッピング」タブを選択します。エンティティ・エディタは、「E」アイコンで識別されます。
インポートを使用したので、Customer Data Source属性はすでにCustomerエンティティ属性にマップされています。属性Ageの場合、「ソース」の値はCustomer Data Source / Age(「オブジェクトIDの表示」アイコンが選択されている場合はCustomer Data Source.Age)のようになります。インポート後に属性を追加した場合、「ソース」の下の省略記号をクリックしてデータ・ソース属性を配置することで、これらがマップされます。
「属性」表で、各データ・ソース(この場合は、Customer Data Source)の入力列の値を特定する必要があります。データ・ソースの入力列は、レコードを取得する際の識別子(SQL select文のWHERE句)です。Customer Data Sourceでは入力列は「ID」のみであるため、「マッピング」タブでは、「属性」表にある「データ・ソース入力値」表にエントリが1つのみ表示されます。このエントリの「入力値」セルで省略記号をクリックし、「値の編集」ダイアログを表示します。
このインライン・サービスでは、Customerエンティティのキーを選択します。「属性または変数」を選択します。「Customer」を開き、「customerId」を選択して「OK」をクリックします。
「ファイル」→「すべて保存」を選択して、インライン・サービスを保存します。
インフォーマントは、Real-Time Decision Serverにメッセージを送信できる統合点の一種で、プロセス内の特定のユニットに関する情報を含みます。この段階でインライン・サービスをテストするために、顧客の年齢を表示するテスト・インフォーマントを作成します。実際の命令文を表示して確認するには、インライン・サービスをReal-Time Decision Serverにデプロイし、インフォーマントをコールする必要があります。数値が返されれば、エンティティ、マッピングおよびデータ・ソースがすべて正しく構成されていることがわかります。
この項には次のトピックが含まれます:
インフォーマントを作成する手順は次のとおりです。
「インライン・サービス・エクスプローラ」で、「統合点」に移動し、「インフォーマント」を選択します。右クリックし、メニューから「新規インフォーマント」を選択します。オブジェクト名としてTestingを指定し、「OK」をクリックします。
Testingインフォーマント・エディタで、「説明」に説明を追加します。
「説明」の横にある「詳細」をクリックします。「デシジョン・センターで表示」を選択解除します。これにより、このインフォーマントがデシジョン・センターのビジネス・ユーザーに対して非表示になります。「OK」をクリックします。
インフォーマントへテスト・ロジックを追加する手順は次のとおりです。
Testingインフォーマント・エディタで、「リクエスト」タブを選択します。インフォーマントは、Iアイコンで識別されます。
セッション・キーを追加するには、「セッション・キー」の下の「選択」をクリックします。「Customer」から「customerId」を選択します。「OK」をクリックします。
|
注意: デシジョン・スタジオでエンティティを構成すると、クラスが生成されます。生成されるクラスには、各属性のプロパティ、ゲッターおよびセッターがあります。 |
「ロジック」タブを選択します。「ロジック」の下に次のスクリプトレットを追加します。
logInfo("Customer age = " + session().getCustomer().getAge() );
logInfoをコールすることにより、「テスト」ビューの「ログ」サブタブと、Oracle RTDがインストールされている管理対象サーバーのログ・ファイル(Enterprise Managerで確認可能)に情報を出力できます。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のサーバー側ログ・ファイルの検索と表示に関する項を参照してください。セッションを使用してCustomerオブジェクトにアクセスし、年齢属性の内容を取得します。
これでデプロイの準備が整いました。「ファイル」→「すべて保存」を選択して、構成を保存します。
図2-3は、Testingインフォーマントがコールされてセッションが作成される際、このインフォーマントがどのように顧客データにアクセスするのかを示します。
インライン・サービスをテストするには、これをデプロイしてテスト・データを持つインフォーマントをコールし、「テスト」ビューを使用して結果を確認します。インフォーマントはコール元に値を返さないため、結果は「テスト」ビューの「ログ」タブに表示されます。
インライン・サービスをデプロイしてテストする手順は次のとおりです。
タスクバーの「デプロイ」アイコンをクリックして、インライン・サービスをデプロイします。
メニュー・アイテムの「プロジェクト」→「デプロイ」からでも、インライン・サービスをデプロイできます。
「選択」をクリックして、デプロイ先となるサーバーを選択します。Real-Time Decision Serverの場所にデプロイします。これはデフォルトで、インストールのデフォルト構成と同様、localhostになります。第2.2項「デプロイおよびデシジョン・センターのセキュリティについて」の説明に従って、自分のユーザー名とパスワードを入力します。ドロップダウン・リストを使用して、デプロイの状態に「開発」を選択します。「アクティブ・セッション(テスト用として使用)の終了」を選択します。「デプロイ」をクリックします。
デプロイには10秒から数分かかります。デプロイが完了すると、「インライン・サービス・エクスプローラ」の下に「Tutorial deployed successfully」というメッセージが表示されます。
|
注意: アクティブなセッションを終了するのは、最後にデプロイされたインライン・サービスに対してテストを実行するためです。アクティブなセッションがあり、その同じセッションID(この場合はcustomerId)を使用する場合、インフォーマントのテストは、以前にデプロイされたインライン・サービスに対して実行されます。現在アクティブなセッションを終了すると、使用されるセッションIDに関係なく、最後にデプロイされたインライン・サービスに対してテストが確実に実行されます。 |
画面下部の「テスト」ビューで、テストする統合点として「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についてに関する項を参照してください。 |
「テスト」ビューの「ログ」タブを選択し、結果を表示します。logInfoコマンドによるすべての出力がタイムスタンプ付きで表示されます。
結果は次のようになります。
Jun 18, 2010 3:59:09 PM Tutorial INFO: Customer age = 38
次に、通話に固有の情報を保持するエンティティを作成します。これは、顧客との相互作用の特性に関するコンテキスト情報です。このエンティティのデータは、インフォーマントから、あるいは計算によって取得され、データベースから取得されることはありません。最初に通話を表すエンティティを作成してから、通話からデータを収集するインフォーマントを作成します。
このエンティティを使用して、通話理由ごとの通話の長さ、これらの通話を行う顧客の特徴など、通話理由に関連するファクタを調査します。インフォーマントにより収集された通話理由を収集および分析するため、自己学習分析モデルが追加され、レポートがデシジョン・センターに表示されます。
この項には次のトピックが含まれます:
Callエンティティを作成する手順は次のとおりです。
「インライン・サービス・エクスプローラ」で、「エンティティ」フォルダを右クリックし、「新規エンティティ」を選択します。オブジェクト名としてCallを指定し、「OK」をクリックします。
表2-3に一覧表示される属性ごとに、次の操作を行います。
エンティティ・エディタの「定義」タブで、「属性の追加」をクリックします。「属性の追加」が表示されます。表の値を入力し、「OK」をクリックします。
「タイプ」をクリックします。ドロップダウン・リストを使用して、属性ごとに適切なデータ型を選択します。
「インライン・サービス・エクスプローラ」で、「エンティティ」の下の「セッション」をダブルクリックします。
「定義」タブで「属性の追加」をクリックします。オブジェクト名としてcallを指定します。デフォルトの型はStringです。デフォルトの型は次の手順で変更します。
「データ型」で「その他」を選択します。「タイプ」ダイアログ・ボックスで、「エンティティ・タイプ」を開き、型として「Call」を選択し、「OK」をクリックします。callの「説明」を追加します。「OK」をクリックします。
「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。
CRMアプリケーションによってコールされる3つのインフォーマント(Call Begin、Service CompleteおよびCall End)を作成します。1番目のCall Beginはセッションを開始します。このインフォーマントでは、後でより迅速にアクセスできるよう、オプションで特定のセッション属性値を事前にロードおよびキャッシュできます。たとえば、後で使用する顧客のプロファイル情報があり、データベースのコールまたはその他の制約によってこの情報のロードが遅くなることが予測される場合、この顧客のプロファイルを事前にロードしておくことができます。
セッションの属性値は必要に応じて自動的にロードされるため、事前にロードする必要はありません。たとえば、前述の項のTestingインフォーマントのように顧客の年齢を表示する場合、Real-Time Decision Serverでは自動的にセッションのCustomerエンティティ属性全体を移入し、Age値を返します。このTutorialインライン・サービスでは、Call Beginインフォーマントはセッションを開始するだけで、セッションの属性値を事前に移入することはありません。
Call Beginインフォーマントを作成する手順は次のとおりです。
「インライン・サービス・エクスプローラ」で、「統合点」の下の「外部システム」フォルダを右クリックし、「新規外部システム」を選択します。「オブジェクト名」が表示されます。システム名としてIVRを指定し、「OK」をクリックします。要素の説明を入力します。このオブジェクトを保存します。
「インライン・サービス・エクスプローラ」で、「統合点」の下の「インフォーマント」フォルダを右クリックし、「新規インフォーマント」を選択します。「オブジェクト名」が表示されます。インフォーマント名としてCall Beginを指定し、「OK」をクリックします。
インフォーマント・エディタを使用して、Call Beginの説明を入力します。
セッション・キーをCall Beginインフォーマントに追加するには、「リクエスト」タブの「セッション・キー」の横にある「選択」をクリックします。「customerId」を選択します。「OK」をクリックします。
さらに「リクエスト」タブで、「外部システム」ドロップダウン・リストから「IVR」を選択し、「順序」ボックスに1を入力します。「セッションの強制クローズ」は選択しないでください。「外部システム」および「順序」により、デシジョン・センターの統合マップ(詳細は、第4.8項「統合マップの表示」を参照)の表示レイアウトと順序が決定します。3つのインフォーマントの定義を終了してインライン・サービスをデプロイすると、デシジョン・センターの統合マップは図2-5のようになります。
「ロジック」タブで、次のコードを入力します。
/*
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);
「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。
2番目のインフォーマントは、通話を処理したエージェント、通話の長さ、顧客の通話理由など、通話情報についてレポートします。このインフォーマントは、コール・センター・エージェントが顧客のニーズに応えたとき、すなわちサービスが完了したときにCRMアプリケーションによってコールされます。このインフォーマントによって収集されるデータは、Callエンティティに移入されます。
Service Completeインフォーマントを作成する手順は次のとおりです。
「インライン・サービス・エクスプローラ」で、「統合点」の下の「外部システム」フォルダを右クリックし、「新規外部システム」を選択します。「オブジェクト名」が表示されます。システム名としてCRMを指定し、「OK」をクリックします。要素の説明を入力します。このオブジェクトを保存します。
「インライン・サービス・エクスプローラ」で、「統合点」の下の「インフォーマント」フォルダを右クリックし、「新規インフォーマント」を選択します。「オブジェクト名」が表示されます。インフォーマント名としてService Completeを指定し、「OK」をクリックします。
インフォーマント・エディタを使用して、Service Completeの説明を入力します。
セッション・キーをService Completeインフォーマントに追加するには、「リクエスト」タブの「セッション・キー」の横にある「選択」をクリックします。「customerId」を選択し、「OK」をクリックします。
さらに「リクエスト」タブで、「外部システム」ドロップダウン・リストから「CRM」を選択し、「順序」ボックスに2を入力します。「セッションの強制クローズ」は選択しないでください。
インフォーマントにデータを追加するには、表2-4に一覧表示された入力パラメータごとに、次の操作を行います。
インフォーマント・エディタの「リクエスト」タブで、「追加」をクリックします。名前を入力し、ドロップダウン・リストを使用してデータ型を選択します。「OK」をクリックします。
「セッション属性」の下で省略記号をクリックし、「割当て」を使用します。「セッション」フォルダを開いてから「call」を開き、入力項目に一致する通話属性を選択します。
「ロジック」タブで、次のコードを入力します。
logInfo("Integration Point - Service Complete");
logInfo(" Reason Code: " + session().getCall().getReasonCode());
logInfo(" Agent: " + session().getCall().getAgent());
logInfo(" Call Length: " + session().getCall().getLength());
「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。
3番目のインフォーマントではセッションを閉じます。これは、CRMアプリケーションからコールされる最後のインフォーマントとなります。このTutorialインライン・サービスでは、このインフォーマントをセッションを閉じるためだけに使用しますが、実際のシステムでは、さらに処理を実行したり、モデルの学習をトリガーしたりできます。
Call Endインフォーマントを作成する手順は次のとおりです。
「インライン・サービス・エクスプローラ」で、「統合点」の下の「インフォーマント」フォルダを右クリックし、「新規インフォーマント」を選択します。「オブジェクト名」が表示されます。インフォーマント名としてCall Endを指定し、「OK」をクリックします。
インフォーマント・エディタを使用して、Call Endの説明を入力します。
セッション・キーをCall Endインフォーマントに追加するには、「リクエスト」タブの「セッション・キー」の横にある「選択」をクリックします。「customerId」を選択し、「OK」をクリックします。
さらに「リクエスト」タブで、「外部システム」ドロップダウン・リストから「CRM」を選択し、「順序」ボックスに5を入力します。「順序」を5に設定するのは、このチュートリアルの後半で、さらに2つの統合点(アドバイザともう1つのインフォーマント)を追加するためです。
オプションの「セッションの強制クローズ」が選択されていることを確認します。このオプションを選択している場合は、インフォーマントがコールされ、そのロジックが処理されると、明示的にそのセッションが閉じられます。明示的にセッションを閉じない場合は、一定の期間が経過した後、自動的に閉じられます。この期間はデフォルトでは30分ですが、Oracle RTD用のシステムMBeanブラウザを使用して変更できます。
「ロジック」タブで、次のコードを入力します。
logInfo("Integration Point - CallEnd");
logInfo("***************************");
「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。
図2-6は、3つのインフォーマントが同じセッションにアクセスして更新する方法を示しています。
ここで、作成した3つのインフォーマントをコールする簡単なシナリオをテストします。それぞれ、1) コールの開始、2) サービスの完了、3) コールの終了に対応します。「テスト」ビューを使用してインフォーマントをコールし、インフォーマントのロジック部分に配置したログ・メッセージを表示します。
インフォーマントをテストする手順は次のとおりです。
サーバーにデプロイします。タスクバーの「デプロイ」アイコンをクリックして、Tutorialインライン・サービスをデプロイします。
「アクティブ・セッション(テスト用として使用)の終了」を必ず選択してください。
デシジョン・スタジオの下部にある「テスト」ビューの「統合点」で「Call Begin」を選択します。リクエスト入力の「customerId」に、たとえば「7」などの整数値を入力します。「送信」アイコンをクリックし、リクエストをサーバーに送信します。
「テスト」ビュー内の「ログ」タブに、Call Begin統合点がコールされたことを示すメッセージが表示されます。
他の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に対してコールを実行できる、コール・センター・プロセスの異なる場所を示しています。
|
ヒント: コンパイルでエラーが生じた場合は、デシジョン・スタジオのダイアログにより、「問題」ビューにこれらのエラーが表示されます。エラーをダブルクリックすると、エラーのある要素のエディタが開きます。 通信しているサーバーが |
前述の項では3つのインフォーマントを作成しました。その2番目のインフォーマントService Completeでは、通話情報をCRMアプリケーションからReal-Time Decision Serverに送信します。通話情報の1つは通話理由、つまり顧客がなぜ通話したのかということです。この項では、選択肢およびモデルを使用して、登録された通話理由を分析します。通話理由に関する基本的なレポート(記録された理由の数、それぞれの通話理由とセッション属性の間に相関関係があるのか、それはどのような相関関係か)を表示できるようにすることが目的です。
この項には次のトピックが含まれます:
選択肢は、分析の対象の作成に使用されます。ここでは最初に通話理由の分析に焦点を当てます。まず、通話理由の選択肢グループを作成します。次に、この選択肢グループcodeの属性を定義します。このグループ内で作成される個々の選択肢は、値はそれぞれ異なりますが、この属性定義を継承します。
選択肢グループを追加する手順は次のとおりです。
「インライン・サービス・エクスプローラ」で、「サーバー・メタデータ」の下の「選択肢」フォルダを右クリックし、「新規選択肢グループ」を選択します。グループ名としてCall Reasonを指定し、「OK」をクリックします。説明を追加します。
Call Reason選択肢グループ・エディタの「選択肢属性」タブで、「属性」表の横にある「追加」をクリックします。「ラベルの表示」に、codeと入力します。データ型に「Integer」を選択してから、「オーバーライド可能」を選択します。Choice codesという説明を追加し、「OK」をクリックします。
|
注意: グループ属性に対して、これを選択肢属性としました。この2つの違いは、選択肢属性では階層の各選択肢に対して値が与えられるのに対し、グループ属性は現在のグループに対してのみ与えられるという点です。 |
グループの下に選択肢を作成するには、「インライン・サービス・エクスプローラ」で選択肢グループ「Call Reason」」を右クリックし、「新規選択肢」を選択します。Check Balanceという選択肢を追加します。
Make Payment、Rate Inquiry、Otherの各選択肢について、この手順を繰り返します。それぞれの説明を追加します。
「インライン・サービス・エクスプローラ」で、「選択肢」の下の「Call Reason」グループを開き、各選択肢を表示します。
4つの選択肢のそれぞれについて、「インライン・サービス・エクスプローラ」で「選択肢」を選択します。その選択肢のエディタの「属性値」タブで、code属性に対して、表2-6に示すとおりに「属性値」を設定します。
「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。
自己学習分析モデルが作成され、通話理由の自動分析が行われます。このモデルは各通話理由を追跡し、すべてのセッション属性をこれらの結果と関連付けます。デシジョン・センターでは、このモデルを使用してレポートを作成します。
分析モデルを追加する手順は次のとおりです。
「インライン・サービス・エクスプローラ」で、「サーバー・メタデータ」の下の「モデル」フォルダを右クリックし、「新規選択肢モデル」を選択します。モデル名としてReason Analysisを指定し、「OK」をクリックします。選択肢イベント・モデルではなく選択肢モデルを作成してください。
「予測に使用」を選択解除します。
分析の対象がchoiceモデル属性であることを示すには、「選択肢」タブを選択し、「選択肢グループ」ドロップダウン・リストから「Call Reason」を選択します。
「場所の学習」タブを選択してから、「統合点」を選択します。
「選択」をクリックしてからサービス完了を選択し、「OK」をクリックします。
「ファイル」→「すべて保存」を選択して、インライン・サービスの変更を保存します。
Service Completeインフォーマントを受け取ったら、該当する通話理由を示す選択肢を選択する必要があります。これを行うには、選択肢モデルのメソッドaddToChoiceを使用して、モデルの選択肢配列に理由を追加します。
モデルの選択肢配列に理由を追加する手順は次のとおりです。
「インライン・サービス・エクスプローラ」で、「統合点」を展開します。「インフォーマント」の下のサービス完了をダブルクリックします。
「ロジック」タブを選択し、次のロジックを入力します。これにより、通話理由を示す選択肢のオブジェクト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;
}
「ファイル」→「すべて保存」を選択して、構成を保存します。
図2-9は、Service Completeインフォーマントがコールされると、Reason Analysisモデルがどのように更新されるかを示しています。
構成のすべての部分をテストする手順は次のとおりです。
構成をサーバーにデプロイします。デプロイまたはコンパイルにエラーがないことを確認します。
「テスト」ビューを使用して統合点をテストします。「Service Complete」を選択し、各引数の値をcustomerId=7、agent=John、length=21、reasonCode=18と設定します。
「送信」をクリックします。次のような結果が表示されます。
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増加します。カウントとともに、モデルはすべてのセッション属性および選択肢との相関関係も追跡します。
値を変更し、数回テストして、その他の理由コードの場合でも正しいオブジェクトIDがモデルに追加されることを確認します。
