| Oracle Real-Time Decisionsプラットフォーム開発者ガイド リリース3.0 B54059-01 |
|
 戻る |
 次へ |
この章では、オブザーバとして機能するインライン・サービスを構築する方法について説明します。オブザーバ・インライン・サービスは、リアルタイムで継続的に対象プロセスの特性を分析することを目的としています。オブサーバ・インライン・サービスは、ビジネス・ユーザーが、様々なビジネス・イベントおよび時間の経過に伴うビジネス・イベントの変化を分析する際の指針となります。
このチュートリアルのインライン・サービスは、クレジット・カード会社のコール・センターに関するものです。このインライン・サービスでは、顧客およびコール・センターの業務系システムに関するデータを収集し、その通話内容と解決方法についての情報を分析します。
このインライン・サービスの目標は、通話のパターン、通話理由および顧客を分析することです。後述の各項では、このインライン・サービスの機能を拡張して、抱合せ販売のオファーについてCRMシステムに提案を行い、さらにその提案の結果についてサービスにフィードバックを加えます。
この章の内容は次のとおりです。
インライン・サービスはDecision Studio開発ツールを使用して作成されます。一般に、インライン・サービスは次のように作成されます。
Decision Studioでプロジェクトが開始されます。
要素がそのプロジェクトに追加され、目的のビジネス・ニーズをサポートするように構成されます。
操作を実行する特定の要素に、Javaスクリプトレットの形式でロジックが追加されます。
インライン・サービスが、実行されるReal-Time Decision Serverにデプロイされます。
インライン・サービスの使用から生成されるレポートがDecision Centerに表示されます。
このチュートリアルでは、次の要素が追加および構成されます。
アプリケーション: 必要なアプリケーション・レベルの設定を行い、インライン・サービスのセキュリティを定義します。アプリケーション要素は、各インライン・サービスに対して自動的に作成されます。
パフォーマンス目標: スコアリングを使用して最適化されるメトリックで構成される組織目標を表します。たとえば、収益や通話継続時間はパフォーマンス・メトリックです。組織目標は、通話継続時間を最小化して収益を最大化すること、などになります
データソース: 外部データソースからのデータのプロバイダとして機能します。データソースのデータの構造および形式は様々に異なります。次に例を示します。
RDBMSテーブルの行と列
ストアド・プロシージャからの出力値と結果行セット
データソースは、エンティティ要素にマップできるデータのプロバイダで、エンティティ要素にデータを提供します。
たとえば、このチュートリアルでは、データベース内のテーブルに接続するデータソースを追加します。このテーブルには顧客データが含まれます。
エンティティ: 1つ以上のデータソースから構築されるデータの論理的表現です。エンティティは次の目的を果たします。
組織、分析およびモデル化のためのオブジェクトにデータを編成する。
様々なソースのデータのJavaコードから、比較的簡単でわかりやすいアクセスを可能にする。
データ取得の詳細を隠し、ロジックを変更せずにこれらの詳細を変更できるようにする。
データ取得のメカニズムを隠し、ユーザーがデータの取得に使用されるAPIを処理せずに済むようにする。
オブジェクトを共有する必要がある場合に、オブジェクトの共有をサポートする。たとえば、サービス・エージェントを表すオブジェクトは複数のセッションで使用される場合があります。
エンティティの属性にはキー値があります。エンティティ・キーは、エンティティのインスタンスの特定に使用されます。
たとえば、このチュートリアルでは、顧客を表すエンティティを作成します。そのエンティティの属性は、値のデータソースにマップされます。顧客IDがその顧客エンティティのキーとして選択されます。
後で、通話を表すエンティティも作成します。
セッション・エンティティ: インライン・サービスの特別なエンティティです。セッション・エンティティは、定義された特定のセッションに固有の属性のコンテナを表します。セッション・キーにより、個々の各セッションが一意に識別されます。
セッション・エンティティの属性として設定することにより、定義されたエンティティをセッションに関連付けることができます。セッション属性であるエンティティのみが、そのキーをセッション・キーとしてマーク付けできます。
たとえば、このチュートリアルでは、顧客エンティティを属性としてセッション・エンティティに追加し、セッション・キーとして顧客キー値である顧客IDを選択します。
インフォーマント: 業務上の相互作用の発生を識別して、データ内の関連する統計パターンを継続的に識別するビジネス・ロジックをトリガーするインライン・サービス内の統合点です。インフォーマントはプロセスを監視しますが、プロセスとのやりとりは行いません。
このチュートリアルでは、まずテスト用インフォーマントを作成し、その後CRMシステムからすべてのサービス・データを収集するインフォーマントを作成します。
このチュートリアルの後半では、モデルの予測の成功または失敗について、インライン・サービスにフィードバックを行うインフォーマントを作成します。
選択肢グループ: 選択肢グループは選択肢の編成に便利です。選択肢グループは、収集および分析される監視結果の編成方法、またはアドバイザ統合点を経由してビジネス・プロセスに提供するフィードバックの編成方法のいずれかを提供します。
たとえば、このチュートリアルでは、まず通話理由を編成する選択肢グループを作成します。インライン・サービスを拡張してアドバイザを含める際に、選択肢グループを使用して、サービス・センター・エージェントに提案される抱合せ販売のオファーを編成します。
モデル: 組込み分析モデルによる自己学習および自動分析が可能です。モデルは、単にデータを分析する場合にも、ビジネス・プロセスへの提案を行う場合にも使用できます。
このチュートリアルでは、通話理由を分析するモデルを作成し、その後、顧客に最も受け入れられる可能性のある抱合せ販売のオファーの決定に役立つモデルを作成します。
デシジョン: アドバイザによって、適切な選択肢の決定、これらの選択肢の動的なスコアリング、母集団のセグメントと指定パフォーマンス目標によるスコアリングの重み付け、および最適な選択肢の提示に使用されます。
アドバイザ: コール元のビジネス・プロセスに情報を返す統合点です。アドバイザは、ランク付けされた選択肢を1つ以上返すインライン・サービスでデシジョンをコールします。
このチュートリアルでは、クレジット・カード・サービス・センターへの通話者に対して行うオファーの選択肢グループを作成します。アドバイザはデシジョンを呼び出し、通話および通話者に関する情報に基づいて、通話者にとって最適なオファーを決定します。アドバイザは、その抱合せ販売の提案をフロント・エンド・アプリケーションに渡します。これによって、コール・センター・エージェントが抱合せ販売を提案できるようになります。
インライン・サービスをReal-Time Decision Serverにデプロイし、インライン・サービスの結果をDecision Centerで表示できるためには、必要なロールが付与されていることが必要です。このロールは、ユーザー名とパスワードを介することで提供されます。
このチュートリアルでは、RTDUsers、RTDDecisionCenterUsersおよびRTDStudioDeployersの割当て済ロールで有効なユーザー・ログインとパスワードが作成されていることを前提としています。
必要に応じて、Oracle RTDシステムのインストールと設定を担当する管理者に問い合せてください。
要素の名前および説明は、ビジネス・ユーザーのユーザー・インタフェースであるDecision Centerで広く使用されます。したがって、要素を作成する際は、時間をかけてわかりやすい要素名を付け、すべての要素に適切な説明を記述することが非常に重要です。
始める前に、Real-Time Decision Serverが起動されていることを確認します。Real-Time Decision Serverの起動方法の詳細は、『Oracle Real-Time Decisionsインストレーションおよび管理ガイド』を参照してください。
アプリケーション要素を構成する手順は次のとおりです。
RTD_HOME\eclipse\eclipse.exeを実行し、Decision Studioを起動します。Decision Studioが起動したら、「File」→「New」→「Inline Service Project」を選択して新しいプロジェクトを開始します。
|
注意: このチュートリアルでは、新規インストールを元のプリファレンス設定で使用することを前提としています。すでにDecision StudioまたはEclipseを使用している場合は、新しいワークスペースに切り替えることもできます。新しいワークスペースに切り替えるには、「File」→「Switch Workspace」を選択し、新しいワークスペース・フォルダを選択します。 |
プロジェクト名としてTutorialを指定し、「Basic」テンプレートを選択します。「Finish」をクリックします。インライン・サービスのアップグレードについて尋ねられたら、「Yes」を選択します。「Inline Service Explorer」にインライン・サービス・プロジェクトが作成されます。デフォルトでは、インライン・サービス・プロジェクトのファイルは、Decision Studioのワークスペースのプロジェクトと同じ名前のフォルダに保存されます（C:\Documents and Settings\Windows_user\Oracle RTD Studio\Tutorialなど）。
Decision Studioで、「Tutorial」→「Service Metadata」フォルダを開きます。「Application」要素をダブルクリックし、要素エディタを表示します。要素エディタに、Tutorialインライン・サービスの説明を入力します。
組織データにアクセスするには、次の2つの要素を構成します。
データソース: データベース内のデータ構造を表す要素です。
エンティティ: 1つ以上のデータソースによって移入可能なデータ、またはインフォーマントによって取得されるコンテキスト・データの論理的表現です。
この項の内容は次のとおりです。
データソースを追加するには、新しいデータソースを作成してからデータソースの出力をインポートします。
この項の内容は次のとおりです。
データソースを作成する手順は次のとおりです。
Decision Studioの「Inline Service Explorer」で「Data Sources」を選択して右クリックします。「New SQL Data Source」を選択します。「Display Label」で「Customer Data Source」と入力し、「OK」をクリックします。データソース・エディタが表示されます。
「Description」で、データソースの説明に「Customer data from a database table」と入力します。
適切な説明であることが非常に重要です。これらの説明はDecision Centerで使用され、ビジネス・ユーザーがレポートおよび分析のコンポーネントを識別するために必要不可欠です。
|
注意: いくつかの別のデータソースがすでに定義されています。これらはインライン・サービスのフレームワークの一部であり、このチュートリアルでは使用しません。 |
データソースの出力は、データベースから取得された列になります。出力にテーブル内のすべての列が含まれる必要はありません。
データソースの出力をインポートする手順は次のとおりです。
「Import」をクリックします。「Import Database Table」が表示されます。「Server」の横に各自のサーバーが表示されます。「Next」をクリックし、サーバーに接続します。「Select Table or View」が表示されます。
「JDBC Data Source」で「SDDS」を選択します。次に、「Tables and Views」で「CrossSellCustomers」を選択します。このテーブルは、デフォルトの標準インストールにより作成および移入されています。
「Finish」をクリックします。
テーブルのすべての列が「Output」列テーブルにインポートされます。
データソースの入力列を設定します。入力は、データ・レコードを取得する際に一致させる列です。ここでは、「Output」列テーブルでID列名を選択し、右矢印（→）をクリックして、IDを「Input」列テーブルに移動できます。データ型は「Integer」です。
データソースの出力列を設定します。「Output」列テーブルで、表2-1に示されている列を除いてすべてを選択し、「Remove」を使用して削除します。
「File」→「Save All」を選択して作業を保存します。作業にエラーがある場合は、「Problems」ビューに通知が表示されます。
|
注意: 「Import」を使用して、データソースの出力に列名およびデータ型をインポートできます。使用しない列は、「Remove」で削除します。 |
データソースを定義したので、対応するエンティティの定義に進みます。エンティティは、構成内の他の要素によって使用されるオブジェクトです。エンティティは、データソースやインフォーマントなどのデータのソースからの抽象レベルを提供します。1つのエンティティは、多くのデータソースからのデータ、あるいは計算値を持つことができます。今回は、データソースの構造に直接マップされる簡単なエンティティを作成します。
この項の内容は次のとおりです。
新しいエンティティを作成する手順は次のとおりです。
「Inline Service Explorer」で、「Entities」フォルダを右クリックし、「New Entity」を選択します。「Display Label」で名前として「Customer」と入力し、「OK」をクリックします。エンティティ・エディタが表示されます。「Description」で「Customer entity」と入力します。
エンティティ属性の適切な説明であることが非常に重要です。それぞれのエンティティに適切な説明を追加してください。
|
注意: オブジェクトIDはJava命名規約に準拠するように自動的に作成されます。変数名は大文字と小文字が混在し、最初の文字は小文字になります。クラス名は大文字と小文字が混在し、最初の文字は大文字になります。ラベル名に空白が含まれている場合、オブジェクトIDを作成する際に空白は削除されます。オブジェクトのラベルとそのオブジェクトIDとの間で表示を切り替えるには、「Inline Service Explorer」のタスク・バーにある「Toggle」アイコンを使用します。  |
「Import」をクリックして、Customer Data Sourceから属性名とデータ型をインポートします。「Build data mappings for the selected data source」オプションは選択したままにします。
「Definition」タブの「Default Value」列で、クリックして挿入ポイントを取得し、表2-2に一覧表示されている各属性のデフォルト値を追加します。Stringデータ型の値は、自動的に二重引用符で囲まれます。
エンティティの属性に関するその他の設定も変更できます。たとえば、より複雑なインライン・サービスでは、属性のカテゴリを定義できます。これを定義するには、カテゴリ要素を作成し、属性の「Properties」で「Category」を使用してこれを割り当てます。属性のプロパティを表示するには、「Definition」タブの属性を選択し、右クリックしてメニューから「Properties」を選択します。
学習について属性を使用しないように指定することもできます。たとえば、顧客の電話番号がある場合、その番号の分析には意味がありません。そのような場合は、「Use for Analysis」を選択解除します。
Decision Centerに属性を表示するかどうか制御するには、「Show in Decision Center」オプションを使用します。これは、属性が技術的な意味を持つだけで、ビジネス上の直接的な意味または関心を引くような意味がない場合に便利です。
エンティティ・オブジェクトを完全にデータソースにマップするには、エンティティ属性をデータソースのキー値にマップして、マッピングを完了する必要があります。その手順は次のとおりです。
Customerエンティティの「Definition」タブで、「Add Key」をクリックしてキー属性を追加します。「Add Key」が表示されます。「Display Label」で「customerId」と入力し、キー値の説明を追加して、データ型を「Integer」に変更し、「OK」をクリックします。
「File」→「Save All」を使用して作業を保存します。「Problems」ビューにエラーが表示される場合があります。これは、データソースに対するCustomerエンティティ属性のマッピング定義が完了していないための予期されるエラーです。次の項に進んでマッピング定義を完了してください。
セッションは、プロセスのユニットのランタイム・データの基礎になります。セッションの期間中、データはメモリーに格納されます。エンティティに関するデータを追跡するには、これをOracle RTDフレームワークの一部であるセッション・エンティティに関連付けます。エンティティをセッションに関連付けるには、これをセッション・エンティティの属性にします。セッションに対するキーが選択されます。そのキーの固有のインスタンスが検出されると、セッションが開始されます。たとえば、Oracle RTDで追跡されるコール・センター・プロセスを考えます。セッションには、通話者とエージェントを表すエンティティが含まれます。セッション（この場合は通話）の期間中、これらのエンティティで定義されたデータおよびそれらの相互作用はメモリーに格納され、分析および意思決定に使用できます。
この項の内容は次のとおりです。
セッション・エンティティへ属性を追加する手順は次のとおりです。
「Inline Service Explorer」で、「Entities」の下の「Session」をダブルクリックします。
「Definition」タブで「Add Attribute」をクリックします。「Display Label」で属性名として「customer」と入力し、「Description」を追加します。最初のデータ型はStringです。これは、次の手順で変更します。
「Data type」で「Other」を選択します。「Type」選択ダイアログが表示されます。「Entity Types」で「Customer」を選択します。「OK」をクリックします。
セッション・キーを作成する手順は次のとおりです。
「Session Keys from Dependent Entities」で「Select」をクリックします。
ツリーを展開し、セッションに関連付けられたすべてのエンティティのキーを表示します。「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エンティティを開き、「Mapping」タブを選択します。エンティティ・エディタは、Eアイコンで識別されます。
インポートを使用したので、Customer Data Source属性はすでにCustomerエンティティ属性にマップされています。属性Ageの場合、「Source」の値はCustomer Data Source / Age（「Show Object ID」アイコンが選択されている場合はCustomer Data Source.Age）のようになります。インポート後に属性を追加した場合、「Source」の下の省略記号をクリックしてデータソース属性を配置することで、これらがマップされます。
「Attributes」テーブルで、各データソース（この場合は、Customer Data Source）の入力列の値を特定する必要があります。データソースの入力列は、レコードを取得する際の識別子（SQL select文のWHERE句）です。Customer Data Sourceでは入力列はIDのみであるため、「Mapping」タブでは、「Attributes」テーブルにある「Data Source Input Values」テーブルにエントリが1つのみ表示されます。このエントリの「Input Value」セルで省略記号をクリックし、「Edit Value」ダイアログを表示します。
このインライン・サービスでは、Customerエンティティのキーを選択します。「Attribute or Variable」を選択します。「Customer」を展開し、「customerId」を選択して「OK」をクリックします。
「File」→「Save All」を選択してインライン・サービスを保存します。
インフォーマントは、Real-Time Decision Serverにメッセージを送信できる統合点の一種で、プロセス内の特定のユニットに関する情報を含みます。この段階でインライン・サービスをテストするために、顧客の年齢を表示するテスト・インフォーマントを作成します。実際の命令文を表示して確認するには、インライン・サービスをReal-Time Decision Serverにデプロイし、インフォーマントをコールする必要があります。数字を戻すと、エンティティ、マッピングおよびデータソースが機能していることがわかります。
この項の内容は次のとおりです。
インフォーマントを作成する手順は次のとおりです。
「Inline Service Explorer」で、「Integration Points」に移動し、「Informants」を選択します。右クリックし、メニューから「New Informant」を選択します。オブジェクト名としてTestingを指定し、「OK」をクリックします。
Testingインフォーマント・エディタで、「Description」に説明を追加します。
「Description」の横にある「Advanced」をクリックします。「Show in Decision Center」を選択解除します。これにより、このインフォーマントがDecision Centerのビジネス・ユーザーに対して非表示になります。「OK」をクリックします。
インフォーマントへテスト・ロジックを追加する手順は次のとおりです。
Testingインフォーマント・エディタで、「Request」タブを選択します。インフォーマントは、Iアイコンで識別されます。
セッション・キーを追加するには、「Session Keys」の下の「Select」をクリックします。「Customer」から「customerId」を選択します。「OK」をクリックします。
|
注意: Decision Studioでエンティティを構成すると、クラスが生成されます。生成されるクラスには、各属性のプロパティ、ゲッターおよびセッターがあります。 |
「Logic」タブを選択します。「Logic」の下に次のスクリプトレットを追加します。
logInfo("Customer age = " + session().getCustomer().getAge() );
logInfoをコールすることにより、情報を「Test」ビューの「Log」サブタブ、およびサーバーのログ・ファイル（通常は、RTD_HOME\log）に出力できます。セッションを使用してCustomerオブジェクトにアクセスし、年齢属性の内容を取得します。
これでデプロイの準備が整いました。「File」→「Save All」を選択して構成を保存します。
図2-3は、Testingインフォーマントがコールされてセッションが作成される際、このインフォーマントがどのように顧客データにアクセスするのかを示します。
インライン・サービスをテストするには、これをデプロイしてテスト・データを持つインフォーマントをコールし、「Test」ビューを使用して結果を確認します。インフォーマントはコール元に値を返さないため、結果は「Test」ビューの「Log」タブに表示されます。
インライン・サービスをデプロイしてテストする手順は次のとおりです。
タスクバーの「Deploy」アイコンをクリックして、インライン・サービスをデプロイします。
「Project」メニュー・アイテム→「Deploy」を選択しても、インライン・サービスをデプロイできます。
「Select」をクリックして、デプロイ先となるサーバーを選択します。Real-Time Decision Serverの場所にデプロイします。これはデフォルトで、インストールのデフォルト構成と同様、localhostになります。第2.2項「デプロイおよびDecision Centerのセキュリティについて」に説明されているように、提供されているユーザー名とパスワードを入力します。ドロップダウン・リストを使用して、デプロイの状態「Development」を選択します。「Terminate Active Sessions (used for testing)」を選択します。「Deploy」をクリックします。
デプロイには10秒から数分かかります。デプロイが完了すると、「Inline Service Explorer」の下に「Tutorial deployed successfully」というメッセージが表示されます。
|
注意: アクティブなセッションを終了するのは、最後にデプロイされたインライン・サービスに対してテストを実行するためです。アクティブなセッションがあり、その同じセッションID（この場合はcustomerId）を使用する場合、インフォーマントのテストは、以前にデプロイされたインライン・サービスに対して実行されます。現在アクティブなセッションを終了すると、使用されるセッションIDに関係なく、最後にデプロイされたインライン・サービスに対してテストが確実に実行されます。 |
画面下部の「Test」ビューで、テストする統合点として「Testing」を選択します。「customerId」フィールドに「7」と入力します。「Send」アイコンをクリックします。
「Test」ビューの「Log」タブを選択し、結果を表示します。logInfoコマンドによるすべての出力がタイムスタンプ付きで表示されます。
結果は次のようになります。
11:53:54,102 Customer age = 38
次に、通話に固有の情報を保持するエンティティを作成します。これは、顧客との相互作用の特性に関するコンテキスト情報です。このエンティティのデータは、インフォーマントから、あるいは計算によって取得され、データベースから取得されることはありません。最初に通話を表すエンティティを作成し、次に通話からデータを収集するインフォーマントを作成します。通話の分析の対象として選択肢が作成されます。ここでは、通話理由の分析に焦点を当てます。
このエンティティを使用して、通話理由ごとの通話の長さ、これらの通話を行う顧客の特徴など、通話理由に関連するファクタを調査します。インフォーマントにより収集された通話理由を収集および分析するため、自己学習分析モデルが追加され、レポートがDecision Centerに表示されます。
この項の内容は次のとおりです。
Callエンティティを作成する手順は次のとおりです。
「Inline Service Explorer」で、「Entities」フォルダを右クリックし、「New Entity」を選択します。オブジェクト名としてCallを指定し、「OK」をクリックします。
表2-3に一覧表示される属性ごとに、次の操作を行います。
エンティティ・エディタの「Definition」タブで、「Add Attribute」をクリックします。「Add Attribute」が表示されます。表の値を入力し、「OK」をクリックします。
「Type」をクリックします。ドロップダウン・リストを使用して、属性ごとに適切なデータ型を選択します。
「Inline Service Explorer」で、「Entities」の下の「Session」をダブルクリックします。
「Definition」タブで「Add Attribute」をクリックします。オブジェクト名としてcallを指定します。デフォルトの型はStringです。デフォルトの型は次の手順で変更します。
「Data type」で「Other」を選択します。「Type」ダイアログ・ボックスで、「Entity types」を開き、型として「Call」を選択し、「OK」をクリックします。callの「Description」を追加します。「OK」をクリックします。
「File」→「Save All」を選択してインライン・サービスの変更を保存します。
CRMアプリケーションによってコールされる3つのインフォーマント（Call Begin、Service CompleteおよびCall End）を作成します。1番目のCall Beginはセッションを開始します。このインフォーマントでは、後でより迅速にアクセスできるよう、オプションで特定のセッション属性値を事前にロードおよびキャッシュできます。たとえば、後で使用する顧客のプロファイル情報があり、データベースのコールまたはその他の制約によってこの情報のロードが遅くなることが予測される場合、この顧客のプロファイルを事前にロードしておくことができます。
セッションの属性値は必要に応じて自動的にロードされるため、事前にロードする必要はありません。たとえば、前述の項のTestingインフォーマントのように顧客の年齢を表示する場合、Real-Time Decision Serverでは自動的にセッションのCustomerエンティティ属性全体を移入し、Age値を返します。このTutorialインライン・サービスでは、Call Beginインフォーマントはセッションを開始するだけで、セッションの属性値を事前に移入することはありません。
Call Beginインフォーマントを作成する手順は次のとおりです。
「Inline Service Explorer」で、「Integration Points」の下の「External Systems」フォルダを右クリックし、「New External System」を選択します。「Object Name」が表示されます。システム名としてIVRを指定し、「OK」をクリックします。要素の説明を入力します。このオブジェクトを保存します。
「Inline Service Explorer」で、「Integration Points」の下の「Informants」フォルダを右クリックし、「New Informant」を選択します。「Object Name」が表示されます。インフォーマント名としてCall Beginを指定し、「OK」をクリックします。
インフォーマント・エディタを使用して、Call Beginの説明を入力します。
セッション・キーをCall Beginインフォーマントに追加するには、「Request」タブの「Session Keys」の横にある「Select」をクリックします。「customerId」を選択します。「OK」をクリックします。
さらに「Request」タブで、「External System」ドロップダウン・リストから「IVR」を選択し、「Order」ボックスに「1」を入力します。「Force session close」は選択しないでください。「External System」および「Order」により、Decision Centerの統合マップ（詳細は、第4.8項「統合マップの表示」を参照）の表示レイアウトと順序が決定します。3つのインフォーマントの定義を終了してインライン・サービスをデプロイすると、Decision Centerの統合マップは図2-5のようになります。
「Logic」タブで、次のコードを入力します。
/*
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);
「File」→「Save All」を選択してインライン・サービスの変更を保存します。
2番目のインフォーマントは、通話を処理したエージェント、通話の長さ、顧客の通話理由など、通話情報についてレポートします。このインフォーマントは、コール・センター・エージェントが顧客のニーズに応えたとき、すなわちサービスが完了したときにCRMアプリケーションによってコールされます。このインフォーマントによって収集されるデータは、Callエンティティに移入されます。
Service Completeインフォーマントを作成する手順は次のとおりです。
「Inline Service Explorer」で、「Integration Points」の下の「External Systems」フォルダを右クリックし、「New External System」を選択します。「Object Name」が表示されます。システム名としてCRMを指定し、「OK」をクリックします。要素の説明を入力します。このオブジェクトを保存します。
「Inline Service Explorer」で、「Integration Points」の下の「Informants」フォルダを右クリックし、「New Informant」を選択します。「Object Name」が表示されます。インフォーマント名としてService Completeを指定し、「OK」をクリックします。
インフォーマント・エディタを使用して、Service Completeの説明を入力します。
セッション・キーをService Completeインフォーマントに追加するには、「Request」タブの「Session Keys」の横にある「Select」をクリックします。「customerId」を選択し、「OK」をクリックします。
さらに「Request」タブで、「External System」ドロップダウン・リストから「CRM」を選択し、「Order」ボックスに「2」を入力します。「Force session close」は選択しないでください。
インフォーマントにデータを追加するには、表2-4に一覧表示された入力パラメータごとに、次の操作を行います。
インフォーマント・エディタの「Request」タブで、「Add」をクリックします。名前を入力し、ドロップダウン・リストを使用してデータ型を選択します。「OK」をクリックします。
「Session Attribute」の下で省略記号をクリックし、「Assignment」を使用します。「Session」フォルダを開いてから「call」を開き、入力項目に一致する通話属性を選択します。
「Logic」タブで、次のコードを入力します。
logInfo("Integration Point - Service Complete");
logInfo(" Reason Code: " + session().getCall().getReasonCode());
logInfo(" Agent: " + session().getCall().getAgent());
logInfo(" Call Length: " + session().getCall().getLength());
「File」→「Save All」を選択してインライン・サービスの変更を保存します。
3番目のインフォーマントではセッションを閉じます。これは、CRMアプリケーションからコールされる最後のインフォーマントとなります。このTutorialインライン・サービスでは、このインフォーマントをセッションを閉じるためだけに使用しますが、実際のシステムでは、さらに処理を実行したり、モデルの学習をトリガーする場合もあります。
Call Endインフォーマントを作成する手順は次のとおりです。
「Inline Service Explorer」で、「Integration Points」の下の「Informants」フォルダを右クリックし、「New Informant」を選択します。「Object Name」が表示されます。インフォーマント名としてCall Endを指定し、「OK」をクリックします。
インフォーマント・エディタを使用して、Call Endの説明を入力します。
セッション・キーをCall Endインフォーマントに追加するには、「Request」タブの「Session Keys」の横にある「Select」をクリックします。「customerId」を選択し、「OK」をクリックします。
さらに「Request」タブで、「External System」ドロップダウン・リストから「CRM」を選択し、「Order」ボックスに「5」を入力します。「Order」を5に設定するのは、このチュートリアルの後半で、さらに2つの統合点（アドバイザともう1つのインフォーマント）を追加するためです。
オプション「Force session close」が選択されていることを確認します。このオプションを選択している場合は、インフォーマントがコールされ、そのロジックが処理されると、明示的にそのセッションが閉じられます。明示的にセッションを閉じない場合は、一定の期間が経過した後、自動的に閉じられます。この期間はデフォルトで30分で、JConsoleを使用して変更できます。
「Logic」タブで、次のコードを入力します。
logInfo("Integration Point - CallEnd");
logInfo("***************************");
「File」→「Save All」を選択してインライン・サービスの変更を保存します。
図2-6は、3つのインフォーマントが同じセッションにアクセスして更新する方法を示しています。
ここで、作成した3つのインフォーマントをコールする簡単なシナリオをテストします。それぞれ、1）コールの開始、2）サービスの完了、3）コールの終了に対応します。「Test」ビューを使用してインフォーマントをコールし、インフォーマントのロジック部分に配置したログ・メッセージを表示します。
インフォーマントをテストする手順は次のとおりです。
サーバーにデプロイします。タスクバーの「Deploy」アイコンをクリックして、Tutorialインライン・サービスをデプロイします。
「Terminate Active Sessions (used for testing)」を必ず選択してください。
Decision Studioの下部にある「Test」ビューの「Integration Point」で「Call Begin」を選択します。リクエスト入力の「customerId」に、たとえば「7」などの整数値を入力します。「Send」アイコンをクリックし、リクエストをサーバーに送信します。
「Test」ビュー内の「Log」タブに、Call Begin統合点がコールされたことを示すメッセージが表示されます。
他の2つの統合点（Service CompleteおよびCall End）についても、表2-5に示す入力値でこの処理を順番に繰り返します。表2-5には、「Log」タブの表示例も示されています。
表2-5 統合点の入力値およびログ結果
| 統合点 | リクエスト入力 | 「Log」タブ |
|---|---|---|
|
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に対してコールを実行できる、コール・センター・プロセスの異なる場所を示しています。
|
ヒント: コンパイルでエラーが生じた場合は、Decision Studioのダイアログにより、「Problems」ビューにこれらのエラーが表示されます。エラーをダブルクリックすると、エラーのある要素のエディタが開きます。通信しているサーバーが |
前述の項では3つのインフォーマントを作成しましたが、その2番目のService Completeでは、通話情報をCRMアプリケーションからReal-Time Decision Serverに送信します。通話情報の1つは通話理由、すなわち顧客がなぜ通話したのかということです。この項では、選択肢およびモデルを使用して登録された通話理由を分析します。通話理由に関する基本的なレポート（記録された理由の数、それぞれの通話理由とセッション属性の間に相関関係があるのか、それはどのような相関関係か）を表示できるようにすることが目的です。
この項の内容は次のとおりです。
選択肢は、分析の対象の作成に使用されます。ここでは最初に通話理由の分析に焦点を当てます。まず、通話理由の選択肢グループを作成します。次に、この選択肢グループcodeの属性を定義します。このグループ内で作成される個々の選択肢は、値はそれぞれ異なりますが、この属性定義を継承します。
選択肢グループを追加する手順は次のとおりです。
「Inline Service Explorer」で、「Service Metadata」の下の「Choices」フォルダを右クリックし、「New Choice Group」を選択します。グループ名としてCall Reasonを指定し、「OK」をクリックします。説明を追加します。
Call Reason選択肢グループ・エディタの「Choice Attributes」タブで、「Attributes」テーブルの横にある「Add」をクリックします。「Display Label」に、「code」と入力します。データ型に「Integer」を選択してから、「Overridable」を選択します。「Choice codes」という説明を追加し、「OK」をクリックします。
|
注意: グループ属性に対して、これを選択肢属性としました。この2つの違いは、選択肢属性では階層の各選択肢に対して値が与えられるのに対し、グループ属性は現在のグループに対してのみ与えられるという点です。 |
グループの下に選択肢を作成するには、「Inline Service Explorer」で選択肢グループ「Call Reason」を右クリックし、「New Choice」を選択します。Check Balanceという選択肢を追加します。
Make Payment、Rate Inquiry、Otherの各選択肢について、この手順を繰り返します。それぞれの説明を追加します。
「Inline Service Explorer」で、「Choices」の下の「Call Reason」グループを展開し、各選択肢を表示します。
4つの選択肢のそれぞれについて、「Inline Service Explorer」で、「Choice」を選択します。その選択肢のエディタの「Attribute Values」タブで、code属性に対して、表2-6に示すとおりに「Attribute Value」を設定します。
「File」→「Save All」を選択してインライン・サービスの変更を保存します。
自己学習分析モデルが作成され、通話理由の自動分析が行われます。このモデルは各通話理由を追跡し、すべてのセッション属性をこれらの結果と関連付けます。Decision Centerでは、このモデルを使用してレポートを作成します。
分析モデルを追加する手順は次のとおりです。
「Inline Service Explorer」で、「Service Metadata」の下の「Models」フォルダを右クリックし、「New Choice Model」を選択します。モデル名としてReason Analysisを指定し、「OK」をクリックします。選択肢イベント・モデルではなく選択肢モデルを作成してください。
「Use for prediction」を選択解除します。
分析の対象がchoiceモデル属性であることを示すには、「Choice」タブを選択し、「Choice Group」ドロップダウン・リストから「Call Reason」を選択します。
「Learn Location」タブを選択してから、「On Integration Point」を選択します。
「Select」をクリックしてから「Service Complete」を選択し、「OK」をクリックします。
「File」→「Save All」を選択してインライン・サービスの変更を保存します。
Service Completeインフォーマントを受け取ったら、該当する通話理由を示す選択肢を選択する必要があります。これを行うには、選択肢モデルのメソッドaddToChoiceを使用して、モデルの選択肢配列に理由を追加します。
モデルの選択肢配列に理由を追加する手順は次のとおりです。
「Inline Service Explorer」で、「Integration Points」を展開します。「Informants」の下の「Service Complete」をダブルクリックします。
「Logic」タブを選択し、次のロジックを入力します。これにより、通話理由を示す選択肢のオブジェクト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;
}
「File」→「Save All」を選択して構成を保存します。
図2-9は、Service Completeインフォーマントがコールされると、Reason Analysisモデルがどのように更新されるかを示しています。
構成のすべての部分をテストする手順は次のとおりです。
構成をサーバーにデプロイします。デプロイまたはコンパイルにエラーがないことを確認します。
「Test」ビューを使用して統合点をテストします。「Service Complete」を選択し、各引数の値をcustomerId=7、agent=John、length=21、reasonCode=18と設定します。
「Send」をクリックします。次のような結果が表示されます。
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がモデルに追加されることを確認します。
