3 クレジット検証システムの作成
この章の内容は次のとおりです。
3.1 ビジネス課題
会社Xは、顧客満足度を高めるためのプロジェクトを立ち上げました。改善の主要領域は、注文ライフ・サイクルの次の部分における注文追跡表示を向上させるために注文プロセスを合理化する必要性です。
-
クレジットの承認
-
履行
-
出荷
-
配送
現在のシステムの主な問題は、クレジット・カードの支払が些細な理由により拒否される場合が多いということです。これらの問題を修正するプロセスは会社Xの注文入力システムによって異なるため、顧客に対する一貫したフォローアップや解決策がありません。システムで注文が消失したり、遅れが生じると、顧客は不満を抱きます。
会社Xは、クレジット・カードの不正使用を排除するため、年度末に新しいクレジット・カード不正検出システムも設置する必要があると判断しました。一貫した不正メカニズムでは、すべての注文入力システムでクレジット検証プロセスを統合する必要があります。
最初のステップは、クレジット検証用のすべての注文入力アプリケーションに対して一貫したインタフェースを提供することです。統合されたクレジット検証サービスは、品質管理のために、最初は社内でホストされることになりました。ただし、インタフェースの安定性を確保した後、このサービスは、サード・パーティ・プロバイダに委託されます。将来、会社Xが外部プロバイダにクレジット検証を委託することを決めた場合でも、これは既存のアプリケーションへの影響なしで実行できます。
3.2 ビジネス・ソリューション
このビジネス課題に対処するために、会社Xは表3-1で説明するコンポーネントを使用するビジネス・ソリューションを設計します。
表3-1 ビジネス・ソリューションを提供するコンポーネント
| コンポーネント | このコンポーネントがビジネス課題に対処する方法 | コンポーネントの説明 |
|---|---|---|
|
SOAコンポジット・アプリケーション |
SOAコンポジット・アプリケーションは、支払を検証して、ステータスを返すように設計されます。支払が拒否されると、注文は処理されません。コンポジットは、次のコンポーネントから構成されます。それぞれについて、簡潔に後述します。
|
SOAコンポジット・アプリケーションは、次のコンポーネントで構成されます。
|
|
BPELプロセス(およびそのアクティビティ)は、クレジット・カード支払の検証をオーケストレートし、支払ステータスを返します(データベース・アダプタを起動します)。 |
BPELプロセスは、ビジネス・プロセスを作成、デプロイおよび管理するための包括的で使用しやすいインフラストラクチャを提供します。BPELは、個別のサービスをエンドツーエンドのプロセス・フローに組み立てるための標準です。BPELプロセスは、プロセス自動化のオーケストレーションおよび構築を実行します。 |
|
データベース・アダプタは、支払タイプ、カード番号、有効期限、カード名義および1日の利用限度額を含む、データベースからのクレジット・カード支払情報を格納および取得します。クレジット・カード番号がデータベースにない場合、支払は拒否されます。 |
データベース・アダプタを使用すると、Oracle SOA SuiteおよびOracle Fusion Middlewareとデータベース・エンドポイントとの通信が可能になります。これには、ANSI SQL標準に準拠し、JDBCドライバを備えたOracleデータベース・サーバーおよびリレーショナル・データベースが含まれます。 |
|
1日の利用限度額と合計注文金額に基づいた支払ステータス(認可または拒否)を決定する変換アクティビティを含む、BPELスコープ・アクティビティ・テンプレートがインポートされます。 |
SOAテンプレートは、Oracle SOA Suiteプロジェクトの再使用可能な部分で、新規プロジェクトの作成に使用されます。テンプレートには、次の3種類があります。
|
|
コンポジット・センサーは、クレジット・カード支払ステータスを追跡します。 |
コンポジット・センサーは、メッセージにトラッキング可能なフィールドを実装する手段を提供します。 |
|
Oracle Service Bus |
Oracle Service Busは、コンポジット登録とセキュリティ上の次の利点を提供します。
|
Oracle Service Busは、構成ベースでポリシー駆動のEnterprise Service Busです。スケーラビリティと信頼性の高いサービス志向の統合やサービス管理、また、異なるIT環境に対して従来のメッセージ・ブローカリングを提供します。 |
図3-1に、このビジネス・ソリューションの実装方法の概要を示します。
この章の後続の項では、表3-1のコンポーネントを使用して、クレジット検証のビジネス課題に対処する方法について、より詳細に説明します。
3.2.1 クレジット検証コンポジットの作成
ビジネス・ソリューションは、クレジット・カード支払を検証し、支払ステータスを返す、SOAコンポジット・アプリケーション内で設計されます。支払が拒否されると、注文は処理されません。このサービスの実装では、BPELプロセスを使用して、データベース・アダプタを起動し、データベースからクレジット・カード・データを取得して、検証を実行します。このサービスは、認可済または拒否済の支払ステータスを返します。
図3-2に、クレジット検証コンポジットの概要を示します。顧客のリクエストは、validatepaymentprocessサービスから発生します。SOAコンポジット・アプリケーション(validatePaymentという名前)はこれらのリクエストを取得し、getPaymentInformationという名前のデータベース・アダプタ参照を起動して、データベースからクレジット・カード情報を取得します。データベース・アダプタは、アダプタ構成ウィザードで構成されます。
次の例は、インバウンド注文メッセージのコンテンツを示しています。顧客は、クレジット・カード番号、有効期限、カード・タイプおよび請求先住所を提供します。
<soas:Billing >
<soas:CardPaymentType>1</soas:CardPaymentType>
<soas:CardNum>1234123412341234</soas:CardNum>
<soas:ExpireDate>0316</soas:ExpireDate>
<soas:CardName>AMEX</soas:CardName>
<soas:BillingAddress>
<soas:FirstName>Joe</soas:FirstName>
<soas:LastName>Smith</soas:LastName>
<soas:AddressLine>555 Beverly Lane</soas:AddressLine>
<soas:City>Hollywood</soas:City>
<soas:State>CA</soas:State>
<soas:ZipCode>12345</soas:ZipCode>
<soas:PhoneNumber>5127691108</soas:PhoneNumber>
</soas:BillingAddress>
</soas:Billing>3.2.2 データベースからのクレジット・カード支払情報の取得
支払タイプ、カード番号、有効期限、カード名義、1日の利用限度額を含む、すべての利用可能なクレジット・カードの詳細が、データベースに格納されます。データベース・アダプタは、顧客のクレジット・カード番号をキーとして使用して、データベースからクレジット・カード支払情報を取得します。
検証プロセスには、次の3つのステップがあります。
-
注文メッセージに引用されているクレジット・カード番号をキーとして使用して、支払情報が最初にデータベースから取得されます。このクレジット・カード番号での利用可能なデータがない場合、支払は拒否されます。
-
クレジット・カード番号のデータが利用できない場合、データベース・レコードの有効期限が注文メッセージの有効期限と比較されます。これらの情報が異なる場合も、支払は拒否されます。
-
最後のチェックで、注文合計額がデータベース内のクレジット・カードの1日の利用限度額を超えないかどうかが比較されます。
すべてのテストに合格すると、支払は認可されます。不合格の場合は、支払が拒否されます。
アダプタ構成ウィザードを起動するには、SOAコンポジット・エディタで、「コンポーネント」ウィンドウから「外部参照」スイムレーンにデータベース・アダプタをドラッグします。このアクションにより、データベース・アダプタを構成するためのアダプタ構成ウィザードが起動します。
3.2.2.1 アダプタ構成ウィザードを使用したデータベース・アダプタの構成
次のデータベース・アダプタ構成タスクは、アダプタ構成ウィザードの実行中に実行されます。
-
クレジット・カード情報が格納されているデータベースへの接続を作成するオプションが選択されます(図3-3を参照)。これにより、データベース・アダプタがデータベースにアクセスし、適切なクレジット・カード情報を取得できるようになります。
-
データベースの「選択」オプションが、データベース問合せを作成するために選択されます(図3-4を参照)。
-
適切なクレジット・カード情報の表がデータベースからインポートされます(図3-5を参照)。
-
データベース問合せの「選択」操作の作成に使用する、適切なクレジット・カード・フィルタリング情報が有効になります(図3-6を参照)。
-
有効期限
-
1日の利用限度額
-
現在の限度
-
-
「選択」操作のための適切なクレジット・カード条件が指定されます(図3-7を参照)。ccnbパラメータが、インバウンド・メッセージ(
CardNum)で指定される顧客のクレジット・カード番号に対して提供されます(「クレジット検証コンポジットの作成」を参照)。データベース・アダプタは、クレジット・カード番号をキーとして使用して、データベースからクレジット・カード支払情報を取得します。データベース・アダプタは、選択内容肢を処理し、指定された操作を実装する参照を生成します。これで、データベース・アダプタ参照getPaymentInformationを表すWSDLファイルがSOAコンポジット・アプリケーションに含まれるようになります。図3-2のコンポジット・ダイアグラムは、getPaymentInformation参照を示しています。
3.2.3 BPELプロセスからのデータベース・アダプタの起動
会社Xは、SOAコンポジット・アプリケーションでBPELプロセス・サービス・コンポーネントを作成します。BPELプロセスは、ビジネス・ソリューションのロジックをオーケストレートします。BPELプロセスのinvokeアクティビティは、パートナ・リンクとしてデータベース・アダプタを起動し、データベースからクレジット・カード情報を取得します。図3-8に詳細を示します。
BPELプロセス内のinvokeアクティビティは、データベース・アダプタ(getPaymentInformation)をコールします(図3-9を参照)。デザイナの下のプロパティ・インスペクタから、またはinvokeアクティビティをダブルクリックして、invokeアクティビティの詳細を作成および編集できます。
-
名前
-
起動するパートナ・リンク(この例では、データベース・アダプタ)
-
ポート・タイプ
-
実行する操作
-
「入力」タブの下の入力変数(データベース・アダプタに送信するクレジット・カード番号が含まれる)
-
「出力」タブの下の出力変数(データベース・アダプタからの結果を返す)
assignアクティビティは、invokeアクティビティの入力変数の移入に使用されます。assignアクティビティ(setCreditCardNumber)の「コピー・ルール」タブで、CardNumとしてBPELプロセスに渡されるクレジット・カード番号がgetPaymentInformationデータベース・アダプタのccnbパラメータに割り当てられます。図3-10に詳細を示します。
XSLTマップは、データベース・アダプタによって返される情報に基づいて支払が有効であるかどうかを判断します。
3.2.4 XSLT変換を使用した支払ステータスの計算
会社Xは、支払ステータスの認可または拒否を判断するためのメカニズムを必要としています。この要件に対処するために、XSLT変換アクティビティでは、データベース・アダプタによって返される次の情報に基づいて支払が有効であるかどうかが判断されます。
-
1日の利用限度額(データベースから取得)。
-
注文の合計金額(価格と注文アイテム数を乗算し、それらを加算することによってプロセス注文プロジェクトで計算される、注文メッセージの認可額)。注文の合計金額がクレジット・カードの1日の利用限度額を超えないようにする必要があります。
XSLT変換設計は、次の方法でパッケージ化できます。
-
BPELプロセスの個々のtransformアクティビティ内で。
-
テンプレートの一部として。テンプレートにより、アプリケーション、コンポジットおよびプロセス間で共通のコードを共有できます。一度テンプレートを作成し、必要に応じて、それを共有します。テンプレートは、何度も再使用できます。次の3種類のテンプレートがサポートされています。
-
すべてのコンポーネントとリソースを含む完全なプロジェクトを提供するプロジェクト・テンプレート
-
すべての参照とコンポーネントを含むBPELプロセスなどのサービス・コンポーネント・テンプレート
-
BPELプロセス・スコープ・アクティビティで構成されるカスタム・アクティビティ・テンプレート
-
会社Xは、テンプレートを使用することにしました。この例では、transformアクティビティを含んだscopeアクティビティで構成されるカスタム・アクティビティ・テンプレートが作成され、インポートされます。
Oracle JDeveloperでテンプレートを作成し、設計します。作成後のテンプレートは、選択して使用するために「コンポーネント」ウィンドウに表示されます(図3-11を参照)。カスタム・アクティビティ・テンプレートは、必要に応じてBPELプロセスにドラッグできます。
カスタムscopeアクティビティは、transformアクティビティで構成されます。この例の変換では、図3-12の「ソース」セクションで示すように、2つの入力変数が期待されています。
-
データベースに格納される支払情報を含む、データベース・アダプタの出力変数
-
注文合計金額を含む、BPELプロセスの入力変数
図3-12の「ターゲット・パート」セクションで示すように、出力は、出力メッセージの「ステータス」フィールドにあります。このフィールドは、拒否または認可のいずれかに設定されます。
XSLTマップ・エディタのマッピングは、図3-13に示します。
3.2.5 コンポジット・センサーを使用した支払ステータスの追跡
会社Xは、注文支払のステータス(認可または拒否)を追跡できる必要があります。この要件に対処するために、コンポジット・センサーが使用されます。コンポジット・センサーは、メッセージにトラッキング可能なフィールドを実装する手段を提供します。コンポジット・センサー・データは、実行時にデータベース内に保持されます。これにより、すべての認可済または拒否済の支払を検索できます。
コンポジット・センサーを使用すると、次のタスクを実行できます。
-
受信メッセージおよび送信メッセージを監視できます。
-
Oracle Enterprise Manager Fusion Middleware Controlで特定のセンサー詳細を検索することにより、特定のインスタンスを確認します。
-
受信メッセージおよび送信メッセージから計算されたJMSデータをパブリッシュします。
-
ビジネス・イベント・サブスクリプションによって開始されたコンポジット・インスタンスを追跡します。
コンポジット・センサーは、インバウンドSOAP Webサービス・バインディング・コンポーネントで定義されます(図3-14を参照)。コンポジット・センサーは、ビジネス・イベント・サブスクリプションを持つ参照バインディング・コンポーネントおよびサービス・コンポーネントで定義することもできます。
図3-15の「コンポジット・センサーの作成」ダイアログは、XPath式が支払ステータス(認可または拒否)を追跡するために定義されることを示しています。「Enterprise Manager」チェック・ボックスも選択されます。これにより、Oracle Enterprise Manager Fusion Middleware Controlの「フロー・インスタンス」ページでコンポジット・センサーの名前と値(たとえば、Status=Authorized)を表示できるようになります。
センサーは、SOAP Webサービス・バインディング・コンポーネントvalidatepaymentprocessのアイコンとして表示されます。アイコンにカーソルを置くと、コンポジット・センサーの定義が表示されます。図3-16に詳細を示します。
3.2.6 validatePaymentコンポジットのデプロイ
会社Xは、Oracle JDeveloperでvalidatePaymentコンポジットをデプロイします(図3-17を参照)。
デプロイメント・プロセス中に、「アダプタ構成ウィザードを使用したデータベース・アダプタの構成」でアプリケーション・サーバー接続を作成したサーバーに、コンポジットがデプロイされます。図3-18に詳細を示します。
コンパイル・エラーがない場合、ビルドが成功し、デプロイメントが開始されます。図3-19に詳細を示します。
図3-19 Oracle JDeveloperログ・ウィンドウでのデプロイメント成功メッセージ
「図3-19 Oracle JDeveloperログ・ウィンドウでのデプロイメント成功メッセージ」の説明
3.2.7 Oracle Service BusでのSOAコンポジット・アプリケーションの登録
会社Xは、デプロイメント場所や実装の更新などの日常的な変更からvalidatePaymentコンポジット・ユーザーを保護できる必要があります。この要件に対処するために、会社Xは、Oracle Service BusでvalidatePaymentコンポジットを登録します。Oracle Service Busは、より大量のリクエストを処理するためにサービスを拡張し、日常的なメンテナンスのためにサービスを停止する際には、障害に対するレジリエンシを高めます。
会社Xは、登録を実行するOracle Service Busアプリケーションの作成を開始します。図3-20に詳細を示します。会社Xは、右の「コンポーネント」ウィンドウからデザイナにアイコンをドラッグして、プロキシ、パイプラインおよびビジネス・サービスを作成できます。「コンポーネント」ウィンドウには、「パイプライン」アイコンと「分割-結合」アイコンが表示されます。リリース12cでは、再利用可能なコンポーネントになるように、パイプラインがプロキシから切り離されています。アダプタとトランスポートも、ビジネス・サービス(「外部参照」スイムレーン)およびプロキシ(「公開されたサービス」スイムレーン)を構築するために表示されます。
設計登録の完了後、ビジネス・ソリューションは図3-21のようになります。
次の項では、Oracle Service Busアプリケーションの登録の概要について説明します。
3.2.7.1 フォルダとリソースの共有
会社Xは、XSDやWSDLファイルなどのリソースがインポートされるフォルダを作成します。このアクションは、Oracle Service Busアプリケーションを右クリックし、「新規」→「ギャラリから」→「フォルダ」を選択して、「フォルダの作成」ウィザードを起動することにより実行されます。
Oracle Service Busフォルダでは、リソースがカテゴリ化され、SOAコンポジット・アプリケーションの「アプリケーション」ウィンドウに表示される、デフォルトの「スキーマ」および「WSDL」フォルダとともに配置されます。これらのフォルダは、Oracle Service BusとSOAコンポジット・アプリケーション間でリソースを共有する方法を提供します。
フォルダの作成後、会社Xは、「ファイル」→「インポート」→「Service Busリソース」を選択して、「Service Busリソースのインポート」ウィザードを起動し、サービスを構築するためのアーティファクトをファイル・システムからインポートします。アーティファクトの選択の完了後、ウィザードは図3-22のようになります。
ウィザードの構成が完了すると、図3-23に示す「アプリケーション」ウィンドウにアーティファクトが表示されます。
図3-23 Oracle Service BusでインポートされたWSDLおよびスキーマ・ファイル・リソース
「図3-23 Oracle Service BusでインポートされたWSDLおよびスキーマ・ファイル・リソース」の説明
3.2.7.2 SOAコンポジット・アプリケーションのコンポジットURIの登録
ビジネス・サービス(図3-21のValidateBS)は、SOAコンポジット・アプリケーションのコンポジットURIを登録し、validatePaymentコンポジットを表示します。構成を行うには、「コンポーネント」ウィンドウからOracle Service Busアプリケーションの「外部参照」スイムレーンに「HTTP」アイコンをドラッグします(図3-24を参照)。
このアクションにより、次のものを構成するための「ビジネス・サービスの作成」ウィザードが起動します。
-
トランスポート・タイプとしてのHTTP。
-
サービス・タイプとしてのWSDL
-
WSDLファイル
-
エンドポイントURI。validatePaymentコンポジットに設定されます。エンドポイントURI書式は、選択したトランスポート・プロトコルに基づきます(HTTP)。たとえば:
http://localhost:7101/soainfra/services/default/ValidatePayment/ validatepaymentprocess_client_ep
会社Xは、「ValidateBS」ビジネス・サービスをダブルクリックして、一般、トランスポート、パフォーマンス(結果キャッシュ)、セキュリティ・ポリシーの各設定を確認します。
3.2.7.3 パイプラインとプロキシの構成
パイプライン(図3-21のValidatePP)には、エラー処理レポート、データ変換、コンポジット起動前の検証など、サービス・バスで実行されるアクションが含まれます。
ユーザーは、コンポジットに直接接続するかわりに、プロキシ(図3-21のValidatePS)を介してvalidatePaymentコンポジットを起動します。これにより、変更管理において、より高い機動性と柔軟性が実現されます。プロキシは、外部コンシューマからのサービスへのインタフェースです。
パイプラインとプロキシの構成を行うには、「コンポーネント」ウィンドウからOracle Service Busアプリケーションの「コンポーネント」セクションに「パイプライン」アイコンをドラッグします。このアクションにより、パイプラインとプロキシを構成するための「パイプライン・サービスの作成」ウィザードが起動します。構成中に、会社XがWSDLファイルを選択します(図3-25を参照)。
ウィザードの後続のページで、「プロキシ・サービスとして公開」チェック・ボックスも選択されます。図3-26に詳細を示します。
図3-27は、「コンポーネント」セクションの「ValidatePP」パイプライン、および「公開されたサービス」スイムレーンの「ValidatePS」プロキシを示しています。
3.2.8 デプロイおよびテスト
アプリケーション設計の完了後、会社Xは「ValidatePS」プロキシを右クリックして、「実行」を選択することにより、アプリケーションのエンドツーエンドにデプロイしてテストします。図3-28に詳細を示します。
テスト用のペイロードを選択可能なテスト・コンソールが表示されます。サンプルのペイロードが生成されています。図3-29に詳細を示します。
会社Xは、サンプルの支払認可ファイルでテストします(次の例を参照)。
<ns1:PaymentInfo xmlns:ns1="http://www.oracle.com/soasample"> <ns1:CardPaymentType>0</ns1:CardPaymentType> <ns1:CardNum>1234123412341234</ns1:CardNum> <ns1:ExpireDate>0316</ns1:ExpireDate> <ns1:CardName>AMEX</ns1:CardName> <ns1:BillingAddress> <ns1:FirstName>Joe</ns1:FirstName> <ns1:LastName>Smith</ns1:LastName> <ns1:AddressLine>555 Beverly Lane</ns1:AddressLine> <ns1:City>Hollywood</ns1:City> <ns1:State>CA</ns1:State> <ns1:ZipCode>12345</ns1:ZipCode> <ns1:PhoneNumber>5127691108</ns1:PhoneNumber> </ns1:BillingAddress> <ns1:AuthorizationAmount>100</ns1:AuthorizationAmount> </ns1:PaymentInfo>
サンプル・ファイルのインポート後、会社Xは「実行」をクリックします。
これで、クレジット検証設計とテストが完了しました。
3.3 関連ドキュメント
表3-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。
表3-2 関連トピック
| 参照内容 | 参照先 |
|---|---|
|
SOAコンポジット・アプリケーションの作成 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOAアプリケーションの作成に関する項 |
|
データベース接続の作成 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle JCAアダプタ用のアプリケーション・サーバー接続の作成に関する項 |
|
アダプタ構成ウィザードでのデータベース・アダプタの構成 |
『テクノロジ・アダプタの理解』のデータベース用のOracle JCAアダプタに関する項 |
|
XSLTマップ・エディタを使用した変換の設計 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のXSLTマップ・エディタを使用したトランスフォーメーションの作成に関する項 |
|
コンポジット・センサーの作成 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のコンポジット・センサーの定義に関する項 |
|
Oracle SOA Suiteテンプレートの作成 |
『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle SOA Suiteテンプレートおよび再利用可能なサブプロセスに関する項 |
|
Oracle Service Busでのビジネス・サービスの作成 |
『Oracle Service Busでのサービスの開発』のJDeveloperでのService Busアプリケーションの開発に関する項
|
|
パイプラインの追加 |
『Oracle Service Busでのサービスの開発』のOracle Service Busパイプラインの操作に関する項 |
|
プロキシの作成 |
『Oracle Service Busでのサービスの開発』のプロキシ・サービスの作成と構成に関する項 |