| Oracle Real-Time Decisionsプラットフォーム開発者ガイド リリース3.0 B54059-01 |
|
 戻る |
 次へ |
Oracle RTDには、企業の業務系システムとの統合方法として、次に示すように強力で簡単に使用できる方法が用意されています。
スマート・クライアント: Java環境および.NET環境では、スマート・クライアントのコンポーネントにより、Real-Time Decision Serverにおける統合点との通信を管理します。
ゼロ・クライアント: ゼロ・クライアントの手法としてWebサービスを介して統合点にアクセスします。
この章と第II部の各章では、Oracle RTD上で実行するデプロイ済インライン・サービスとの統合に、これらの方法を使用する方法について概略を説明します。
Decision Studioを使用してインライン・サービスをデプロイする方法の詳細は、第I部「概要」を参照してください。統合APIの詳細は、Decision Studioのオンライン・ヘルプを参照してください。
|
注意: Oracle RTDドキュメント全体にわたって次の用語が参照されます。
詳細は、『Oracle Real-Time Decisionsインストレーションおよび管理ガイド』の「Oracle RTDのランタイム環境について」を参照してください。 |
この章の内容は次のとおりです。
Oracle Real-Time Decisionsには、複数の統合方法が用意されています。ご使用の環境に最適な方法を選択するには、使用するプラットフォームやパフォーマンス要件だけでなく、RTDスマート・クライアントが用意している統合方法固有の追加機能についても考慮する必要があります。
この項の内容は次のとおりです。
Java用のOracle RTDスマート・クライアントはコンポーネントであり、これによって業務系システムとしてデプロイ済インライン・サービスとの統合が容易になり、統合に管理機能を実装できます。Java環境を使用する場合は、Javaスマート・クライアントが最適な統合方法です。Javaスマート・クライアントにはその他の統合方法にはない重要な機能が2つ用意されています。1つは、セッション・キーのマッピング（外部のロード・バランサによるHTTPセッション・アフィニティ管理が容易になる機能）で、もう1つはデフォルトのレスポンス処理です。
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リクエストに挿入されます。これによって、外部のロード・バランサがそのインライン・サービス・キーを処理しているサーバー・インスタンスにリクエストをルーティングできるようになります。
他の統合方法を使用してクラスタリングを実現する場合は、アプリケーション自体がインライン・サービス・キーを追跡管理する必要があります。
.NET環境では、.NETスマート・クライアントのコンポーネントを使用できます。このコンポーネントには、Javaスマート・クライアントと同じインタフェースをコールする機能が用意されています。ただし、セッション・アフィニティの維持とデフォルト値関連の追加機能はありません。
開発者がWebアプリケーションをデプロイ済インライン・サービスと統合するための手段としてJSPクライアント統合タグが用意されています。これらのJSPタグによって、Javaスマート・クライアントによって用意されているAPIと同等のクライアント・インタフェースが実現します。
クライアントは、Webサービスを介してReal-Time Decision Serverにアクセスできます。この統合方法の利点は、クライアント上にコードが不要なことです。Webサービスの運用はWSDLファイルに定義され、Webサービスの定義はスキーマ・ファイルで指定します。
サンプルのインライン・サービスがDecision Studioに付属しています。その中の1つが抱合せ販売用のサンプルです。
CrossSellインライン・サービスでは、クレジット・カード会社のコンタクト・センターを想定した単純な実装がシミュレートされます。センターで電話を受けると、顧客および連絡先チャネルに関する情報が入力されます。
この顧客に関する情報に基づいて、顧客に提案する抱合せ販売のオファーが選択されます。オファーの成功や失敗が追跡されてサーバーに追跡情報が返されます。これによって、基礎となる意思決定モデルに対して精度を高めるフィードバックが返され、抱合せ販売のオファーが改善されます。
このドキュメントでは、CrossSellインライン・サービスを使用して、各種統合方法について説明します。
複数の統合点がCrossSellサンプルに用意されています。後述する記載に従って、これらの統合点について理解を深めてください。
インフォーマントでは、適切なパラメータが渡されると、サーバー上で実行されます。そして、アドバイザが実行してデータを返します。統合点へのコールに正しいパラメータを指定するには、最初にオブジェクトIDを特定する必要があります。
この項の内容は次のとおりです。
オブジェクトIDを特定する手順は、次のとおりです。
RTD_HOME\eclipse\eclipse.exeを実行し、Decision Studioを起動します。
「File」→「Import」を選択し、CrossSellインライン・サービスを起動します。「Import」が表示されます。
「Existing Project into Workspace」を選択し、「Next」をクリックします。RTD_HOME\examples\CrossSellにあるCrossSellプロジェクトを参照します。「OK」を選択してから「Finish」をクリックし、CrossSellプロジェクトを起動します。
「Inline Service Explorer」を使用して、「Integration Points」を開きます。図6-1に示すように、「Informants」フォルダと「Advisors」フォルダを開き、統合点を表示します。
図6-1 「Inline Service Explorer」の「Informants」と「Advisors」
オブジェクトIDの「Toggle」アイコンを使用して、オブジェクトIDを「Inline Service Explorer」に表示します。
「Toggle」アイコンが選択されていると、オブジェクトIDが「Inline Service Explorer」に表示されます。選択されていないと、表示ラベルが表示されます。
|
注意: 統合点のオブジェクトIDは、ラベルと同じ場合と異なる場合があります。オブジェクトIDは、統合点をメソッド・コールにおいて参照するために使用されます。 |
レスポンスを配信する統合点を、アドバイザと呼びます。Decision Studioでは、アドバイザの「Response」タブを使用して、アドバイザによって暗黙的に起動されるパラメータ化Decisionオブジェクトを指定することでレスポンスが決まります。Decisionオブジェクトの役割は、それに割り当てられている選択肢グループから最適な選択肢を選択することです。配信される選択肢属性は、選択肢グループの定義に設定されている構成によって決まります。
この例では、OfferRequest統合点がアドバイザになります。OfferRequestが起動されると、単一の抱合せ販売オファーが返されます。
アドバイザのレスポンスを決定する手順は、次のとおりです。
Decision Studioで、「OfferRequest」統合点を選択し、エディタを表示します。
「Response」タブにある「Decision」で、OfferRequestがレスポンスの返信に使用するデシジョンを調べます。「OfferDecision」であることを確認します。
「Decisions」にある「OfferDecision」をダブルクリックし、その詳細ペインを表示します。
「Selection Criteria」タブにある「Number of Choices to Select」で、OfferRequestによって配信されるレスポンスの数を確認します。
「Selection Criteria」タブにある「Choice Group」で、OfferRequestによって使用される選択肢グループを調べます。「Offers」であることを確認します。
「Choices」にある「Offers」をダブルクリックし、この選択肢グループに関連付けられている選択肢属性を確認します。アドバイザがコールされたときに、これらの属性が返されます。
|
ヒント: Decision Studioでは、「Test」ビューを使用して、アドバイザをコールし、返される内容を確認します。このビューには、返されるオファーと、それに付属する属性が表示されます。「Test」ビューにアクセスするには、「Problems」タブの横にある「Test」タブをクリックします。「Send」アイコンをクリックして、リクエストをサーバーに送信します。 |
選択肢の成功や失敗が追跡され、モデルにおいてその情報に基づいて自己学習が行われるにつれて、インライン・サービスはより強力になります。サーバーの自己学習に必要なフィードバックを確認するには、次に示すように、選択肢イベント・モデルを調べる必要があります。
Decision Studioで、「Offer Acceptance」選択肢イベント・モデルをダブルクリックします。エディタが右側に表示されます。
「Choice」タブにある「Positive Outcome Events」により、サーバーの自己学習に影響を及ぼすイベントを確認できます。それらは次のとおりです。
Interested
Purchased
これらの結果がインライン・サービスからサーバーに報告されることで、適切なフィードバックがモデルに返されます。
OfferResponse統合点には、この情報報告の役割があります。
統合点を起動するには、統合点に対応するセッション・キーおよび引数の値を指定する必要があります。リクエストでは、Decision Studioによって定義されているオブジェクトIDを統合点のセッション・キーおよび引数に対して使用する必要があります。キー名は、Decision Studioに定義されている統合点用セッション・キー名のいずれかと一致する必要があります。
セッション・キーおよび引数を特定する手順は、次のとおりです。
「CallStart」統合点を選択します。対応する統合点エディタの「Request」タブにある「Session Keys」リストに、セッション・キーへのパス（sessionで始まる）が表示されます。このパス名の最後はセッション・キーのオブジェクトIDです。
|
注意: セッション・キーがオブジェクト形式で表示されない場合、オブジェクトIDの「Toggle」アイコンを使用して表示設定を変更します。
最後のオブジェクトIDのみセッション・キーで必要です。たとえば、この例では最後の文字列の |
統合点の引数を特定するには、詳細ペインを使用して、「Request」タブの「Incoming Attribute」列を表示します。「CallStart」の入力引数はchannelです。
