| 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 |
|
前 |
次 |
この章では、Oracle RTDを企業の業務系システムと統合するためのコンポーネント(スマート・クライアント、PHPクライアントおよびWebサービス)について説明します。また、コンポーネント別の各章で様々な統合方法について説明するときに使用するCrossSellインライン・サービスの要素についても解説します。
Oracle RTDには、企業の業務系システムとの統合方法として、次に示すように強力で簡単に使用できる方法が用意されています。
スマート・クライアント: Java環境および.NET環境では、スマート・クライアントのコンポーネントにより、Real-Time Decision Serverにおける統合点との通信を管理します。
PHPクライアント統合クラスを介してWebアプリケーションをデプロイ済インライン・サービスと統合します。
ゼロ・クライアント: ゼロ・クライアントの手法としてWebサービスを介して統合点にアクセスします。
この章と第II部の各章では、Oracle RTD上で実行するデプロイ済インライン・サービスとの統合に、これらの方法を使用する方法について概略を説明します。
デシジョン・スタジオを使用してインライン・サービスをデプロイする方法の詳細は、第I部「概要」を参照してください。統合APIの詳細は、デシジョン・スタジオのオンライン・ヘルプを参照してください。
|
注意: Oracle RTDドキュメント全体にわたって次の用語が参照されます。
詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』の「Oracle RTDラインタイム環境について」を参照してください。 |
この章には次のトピックが含まれます:
Oracle Real-Time Decisionsには、複数の統合方法が用意されています。ご使用の環境に最適な方法を選択するには、使用するプラットフォームやパフォーマンス要件だけでなく、RTDスマート・クライアントが用意している統合方法固有の追加機能についても考慮する必要があります。
この項には次のトピックが含まれます:
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リクエストに挿入されます。これによって、外部のロード・バランサがそのインライン・サービス・キーを処理しているサーバー・インスタンスにリクエストをルーティングできるようになります。
他の統合方法を使用してクラスタリングを実現する場合は、アプリケーション自体がインライン・サービス・キーを追跡管理する必要があります。
.NET環境では、.NETスマート・クライアントのコンポーネントを使用できます。このコンポーネントには、Javaスマート・クライアントと同じインタフェースをコールする機能が用意されています。ただし、セッション・アフィニティの維持とデフォルト値関連の追加機能はありません。
開発者がWebアプリケーションをデプロイ済インライン・サービスと統合するための手段としてJSPクライアント統合タグが用意されています。これらのJSPタグによって、Javaスマート・クライアントによって用意されているAPIと同等のクライアント・インタフェースが実現します。
PHPクライアントには、Webアプリケーションをデプロイ済インライン・サービスと統合する便利な方法として、PHPクライアント統合クラスが用意されています。PHPを使用すると、対話型のWebページを作成できます。用意されているPHPクラスは、Javaスマート・クライアントと同様の機能を備えています。
クライアントは、Webサービスを介してReal-Time Decision Serverにアクセスできます。Webサービスの運用はWSDLファイルに定義され、Webサービスの定義はスキーマ・ファイルで指定します。Oracle RTDのWSDLファイルを使用してユーザー独自の標準Webクライアントを作成できます。
サンプルのインライン・サービスがデシジョン・スタジオに付属しています。その中の1つが抱合せ販売用のサンプルです。
CrossSellインライン・サービスでは、クレジット・カード会社のコンタクト・センターを想定した単純な実装がシミュレートされます。センターで電話を受けると、顧客および連絡先チャネルに関する情報が入力されます。
この顧客に関する情報に基づいて、顧客に提案する抱合せ販売のオファーが選択されます。オファーの成否が追跡されてサーバーに追跡情報が返されます。これによって、基礎となる意思決定モデルに対して精度を高めるフィードバックが返され、抱合せ販売のオファーが改善されます。
このドキュメントでは、CrossSellインライン・サービスを使用して、各種統合方法について説明します。
CrossSellインライン・サービスを使用するには、特定の表をいくつか作成して移入する必要があります。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のCrossSellサンプル・データの移入に関する項を参照してください。
ランダムではなく、モデルの学習データに基づく提案結果を取得するには、Loadgenスクリプトも実行する必要があります。詳細は、第12.3.6項「サンプル・プロジェクト」を参照してください。
複数の統合点がCrossSellサンプルに用意されています。後述する記載に従って、これらの統合点について理解を深めてください。
インフォーマントでは、適切なパラメータが渡されると、サーバー上で実行されます。そして、アドバイザが実行してデータを返します。統合点へのコールに正しいパラメータを指定するには、最初にオブジェクトIDを特定する必要があります。
この項には次のトピックが含まれます:
|
注意: 統合点のオブジェクトIDは、ラベルと同じ場合と異なる場合があります。オブジェクトIDは、統合点をメソッド・コールにおいて参照するために使用されます。 |
オブジェクトIDを特定する手順は、次のとおりです。
RTD_HOME\eclipse\eclipse.exeを実行し、デシジョン・スタジオを起動します。
「ファイル」→「インポート」を選択してCrossSellインライン・サービスを開きます。「インポート」が表示されます。
既存のプロジェクトをワークスペースへを選択し、「次」をクリックします。RTD_HOME\examples\CrossSellにあるCrossSellプロジェクトを参照します。「OK」を選択してから「終了」をクリックし、プロジェクトを開きます。
「インライン・サービス・エクスプローラ」を使用して、「統合点」を開きます。図6-1に示すように、「インフォーマント」フォルダと「アドバイザ」フォルダを開き、統合点を表示します。
オブジェクトIDの「トグル」アイコンを使用して、オブジェクトIDを「インライン・サービス・エクスプローラ」に表示します。
「トグル」アイコンが選択されていると、オブジェクトIDが「インライン・サービス・エクスプローラ」に表示されます。選択されていないと、表示ラベルが表示されます。
統合点を起動するには、統合点に対応するセッション・キーおよび引数の値を指定する必要があります。リクエストでは、デシジョン・スタジオによって定義されているオブジェクトIDを統合点のセッション・キーおよび引数に対して使用する必要があります。キー名は、デシジョン・スタジオに定義されている統合点用セッション・キー名のいずれかと一致する必要があります。
セッション・キーおよび引数を特定する手順は、次のとおりです。
「CallStart」統合点を選択します。この統合点のエディタの「リクエスト」タブにある「セッション・キー」リストに、セッション・キーへのパス(sessionで始まる)が表示されます。このパス名の最後はセッション・キーのオブジェクトIDです。
|
注意: セッション・キーがオブジェクト形式で表示されない場合、オブジェクトIDの「トグル」アイコンを使用して表示設定を変更します。
最後のオブジェクトIDのみセッション・キーで必要です。たとえば、この例では最後の文字列の |
統合点の引数を特定するには、詳細ペインを使用して、「リクエスト」タブの受信属性列を表示します。CallStartの入力引数はchannelです。
レスポンスを配信する統合点を、アドバイザと呼びます。デシジョン・スタジオでは、アドバイザの「レスポンス」タブを使用して、アドバイザによって暗黙的に起動されるパラメータ化Decisionオブジェクトを指定することでレスポンスが決まります。Decisionオブジェクトの役割は、それに割り当てられている選択肢グループから最適な選択肢を選択することです。配信される選択肢属性は、選択肢グループの定義に設定されている構成によって決まります。
この例では、OfferRequest統合点がアドバイザになります。それが起動されると、単一の抱合せ販売オファーが返されます。
アドバイザのレスポンスを決定する手順は、次のとおりです。
デシジョン・スタジオで、「OfferRequest」統合点を選択し、エディタを表示します。
「レスポンス」タブにある「デシジョン」で、OfferRequestがレスポンスの返信に使用するデシジョンを調べます。「OfferDecision」であることを確認します。
「デシジョン」にある「OfferDecision」をダブルクリックし、その詳細ペインを表示します。
「選択基準」タブにある「選択する選択肢の数」で、OfferRequestによって配信されるレスポンスの数を確認します。
「選択基準」タブにある「選択肢グループ」で、OfferRequestによって使用される選択肢グループを調べます。Offersであることを確認します。
「選択肢」にある「Offers」をダブルクリックし、この選択肢グループに関連付けられている選択肢属性を確認します。アドバイザがコールされたときに、これらの属性が返されます。
|
ヒント: デシジョン・スタジオでは、「テスト」ビューを使用して、アドバイザをコールし、返される内容を確認します。このビューには、返されるオファーと、それに付属する属性が表示されます。「テスト」ビューにアクセスするには、「問題」タブの横にある「テスト」タブをクリックします。「送信」アイコンをクリックし、リクエストをサーバーに送信します。  |
Oracle RTDの自己学習モデルを更新できるようにするには、選択肢の成否をRTD Serverに送り返すことが重要です。選択肢グループが選択肢イベント・モデルに関連付けられている場合、サーバーが必要とするフィードバックを調べるには、そのモデルに関連付けられているイベントを次のように特定する必要があります。
デシジョン・スタジオで、「Offer Acceptance」選択肢イベント・モデルをダブルクリックします。エディタが右側に表示されます。
「選択肢」タブにある「正の結果イベント」により、サーバーの自己学習に影響を及ぼすイベントを確認できます。それらは次のとおりです。
Interested
Purchased
これらの結果がインライン・サービスからサーバーに報告されることで、適切なフィードバックがモデルに返されます。
OfferResponse統合点には、この情報報告の役割があります。
Oracle RTD Webサービスの一般情報およびOracle RTD Webサービスで使用されるセキュリティ・ポリシーの一般情報は、付録B「Oracle RTD Webサービスおよびクライアント」を参照してください。
ハードウェアとソフトウェアの要件、プラットフォーム、データベースおよびその他の情報の詳細は、システム要件と動作要件のドキュメントを参照してください。いずれのドキュメントも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
