Oracle® Fusion Middleware

Oracle SOA Suiteの理解

12c (12.2.1.1.0)

E77337-02(原本部品番号:E68163-02)

2016年8月

Oracle Fusion Middleware Oracle SOA Suiteの理解, 12c (12.2.1.1.0)

E77337-02

Copyright © 2014, 2016, Oracle and/or its affiliates  All rights reserved.

原本著者:  Oracle Corporation

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

第I部 Oracle SOA Suiteの概要

1 Oracle SOA Suiteの概要

- 1.1 Oracle SOA Suiteについて

- 1.2 主要な概念

- 1.3 主要コンポーネント

- 1.4 主要管理ツールとプロセス

- 1.4.1 Oracle JDeveloper

- 1.4.2 Oracle Enterprise Manager Fusion Middleware Control

- 1.4.3 追加の設計およびランタイム・ツール

- 1.5 Oracle SOA Suiteプロセス・フローの概要

第II部 ビジネス課題とOracle SOA Suite

2 会社Xのビジネス課題

- 2.1 会社Xのビジネス課題

- 2.2 ソリューション

3 クレジット検証システムの作成

- 3.1 ビジネス課題

- 3.2 ビジネス・ソリューション

- 3.2.1 クレジット検証コンポジットの作成

- 3.2.2 データベースからのクレジット・カード支払情報の取得

- 3.2.2.1 アダプタ構成ウィザードを使用したデータベース・アダプタの構成

- 3.2.3 BPELプロセスからのデータベース・アダプタの起動

- 3.2.4 XSLT変換を使用した支払ステータスの計算

- 3.2.5 コンポジット・センサーを使用した支払ステータスの追跡

- 3.2.6 validatePaymentコンポジットのデプロイ

- 3.2.7 Oracle Service BusでのSOAコンポジット・アプリケーションの登録

- 3.2.7.1 フォルダとリソースの共有

- 3.2.7.2 SOAコンポジット・アプリケーションのコンポジットURIの登録

- 3.2.7.3 パイプラインとプロキシの構成

- 3.2.8 デプロイおよびテスト

- 3.3 関連ドキュメント

4 注文処理システムの作成

- 4.1 ビジネス課題

- 4.2 ビジネス・ソリューション

- 4.2.1 SOAプロジェクト・テンプレートからのSOAコンポジット・アプリケーションの作成

- 4.2.2 SOAプロジェクト・テンプレートのコンテンツのカスタマイズ

- 4.2.3 インラインBPELサブプロセスでの注文ステータスの更新

- 4.2.4 コンポジット・センサーを使用した注文番号の追跡

- 4.2.5 支払認可後の注文ステータスの更新

- 4.2.6 Oracle Enterprise Manager Fusion Middleware Controlでのデプロイとテスト

- 4.2.7 Oracle Service BusでのProcessOrderコンポジットの登録

- 4.2.7.1 ビジネス・サービスとしてのProcessOrderコンポジットの登録

- 4.2.7.2 パイプライン・テンプレートを使用したプロキシでの新規パイプラインの作成

- 4.2.8 パイプライン・テンプレートのテスト

- 4.3 関連ドキュメント

5 Oracle Service Busでの新規注文チャネルの追加

- 5.1 ビジネス課題

- 5.2 ビジネス・ソリューション

- 5.2.1 Oracle Service Busパイプラインへのファイルベース・プロキシの追加

- 5.2.2 Oracle Service Busデバッガによるコンポーネントのデバッグ

- 5.2.3 Oracle Enterprise Manager Fusion Middleware ControlでのOracle Service Busのモニタリング

- 5.3 関連ドキュメント

6 注文の梱包と出荷

- 6.1 ビジネス課題

- 6.2 ビジネス・ソリューション

- 6.2.1 RESTサービスを使用した出荷リソースの定義

- 6.2.2 梱包BPELプロセスを使用したRESTサービスの公開

- 6.2.3 HTTPアナライザを使用したRESTサービスのテスト

- 6.2.4 データベース内の注文ステータスを更新するためのテンプレートおよびスタンドアロン・サブプロセスの使用

- 6.2.5 コンポジット・センサーを使用した出荷プロバイダの追跡

- 6.2.6 注文の出荷を示す電子メール通知の送信

- 6.3 関連ドキュメント

7 注文の履行

- 7.1 ビジネス課題

- 7.2 ビジネス・ソリューション

- 7.2.1 SOAテンプレートからのプロジェクトの作成

- 7.2.2 ビジネス・ルールを使用した出荷方法の決定

- 7.2.3 コンポジット・センサーを使用した注文番号の追跡

- 7.2.4 RESTインタフェースを使用した梱包サービスへの注文の配信

- 7.2.5 コヒーレンス・アダプタを使用したキャッシュからの出荷プロバイダの読取り

- 7.2.6 Coherenceキャッシュへのデータベース・アダプタ・レスポンスのコピー

- 7.2.7 コンポジットのデプロイとコヒーレンス・アダプタのテスト

- 7.3 関連ドキュメント

8 コンポジットの実行のスケジューリング

- 8.1 ビジネス課題

- 8.2 ビジネス・ソリューション

- 8.2.1 Webサービス・ジョブ定義の作成

- 8.2.2 スケジュールに基づくジョブ・リクエストの発行

- 8.2.3 アダプタへのスケジュールの適用

- 8.3 関連ドキュメント

9 ファイル転送の管理

- 9.1 ビジネス課題

- 9.2 ビジネス・ソリューション

- 9.2.1 転送、ソースおよびターゲットの作成

- 9.2.2 MFTサービスを使用したSOAコンポジット・アプリケーションの作成

- 9.2.3 注文ファイルのSOAコンポジットへの送信

- 9.2.4 ペイロード・タイプの処理

- 9.2.5 インライン・ペイロードを使用したProcessOrderコンポジットの起動

- 9.3 関連ドキュメント

10 B2Bの注文の受入れ

- 10.1 ビジネス課題

- 10.2 ビジネス・ソリューション

- 10.2.1 Oracle B2Bを使用した取引きパートナおよび取引きパートナ・アグリーメントの作成

- 10.2.2 Oracle MFTターゲットとOracle B2Bとの統合

- 10.2.3 Oracle Service BusとOracle B2Bとの統合

- 10.2.4 ProcessOrderコンポジットとOracle B2Bとの統合

- 10.3 関連ドキュメント

11 不正検出の追加

- 11.1 ビジネス課題

- 11.2 ビジネス・ソリューション

- 11.2.1 Oracle Event Processingアプリケーションの作成

- 11.2.2 Oracle Event Processingアプリケーションへのイベントの送信

- 11.2.3 Oracle Enterprise Manager Fusion Middleware Controlからのイベント・データの送信

- 11.3 関連ドキュメント

12 Oracle Business Activity Monitoringを使用したビジネス・インサイトの取得

- 12.1 ビジネス課題

- 12.2 ビジネス・ソリューション

- 12.2.1 コンポジットへのビジネス・インジケータと測定の追加

- 12.2.2 Oracle BAMダッシュボードでのビジネス・インサイトの取得

- 12.3 関連ドキュメント

はじめに

「はじめに」では、このガイド『Oracle SOA Suiteの理解』で使用されているドキュメントのアクセシビリティ機能と規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

第I部 Oracle SOA Suiteの概要

この部は、次の章で構成されています。

- Oracle SOA Suiteの概要

1 Oracle SOA Suiteの概要

この章では、主要な概念、コンポーネント、管理ツールとプロセス、およびプロセス・フローを含むOracle SOA Suiteのアーキテクチャについて説明します。

この章の内容は次のとおりです。

- Oracle SOA Suiteについて

- 主要な概念

- 主要コンポーネント

- 主要管理ツールとプロセス

- Oracle SOA Suiteプロセス・フローの概要

1.1 Oracle SOA Suiteについて

Oracle SOA Suiteは、サービス指向アーキテクチャ(SOA)を使用して統合を構築、デプロイ、管理できる包括的でホットプラグ可能なソフトウェア・スイートです。Oracle SOA Suiteには次の機能があります。

- 一貫したツール

- シングル・デプロイメント・モデルと管理モデル

- エンドツーエンド・セキュリティ

- 統合されたメタデータ管理

Oracle SOA Suiteにより、複雑なアプリケーションの統合を機動的で再利用可能なサービスベースのアプリケーションに変換することで、市場に出すための時間の短縮、ビジネス要件へのより迅速な対応、およびコスト削減を実現できます。以前はパッケージ・アプリケーション・ユーザー・インタフェースでのみアクセス可能であった顧客、金融、注文情報などの重要なビジネス・サービスは、スマートフォンやタブレットなどのモバイル機器に迅速にモデル化できるようになりました。

図1-1に、Oracle SOA Suiteのアーキテクチャの概要を示します。

図1-1 Oracle SOA Suiteのアーキテクチャ

1.2 主な概念

Oracle SOA Suiteのホットプラグ可能なアーキテクチャにより、実行するオペレーティング・システムや基盤となるテクノロジにかかわらず、既存のIT投資や資産を再利用してコストを削減できます。また、Oracle SOA Suiteは、使用しやすく、再利用可能な、統合アプリケーション開発ツールとライフ・サイクル管理により、開発コスト、メンテナンス・コストおよび複雑性のさらなる削減を実現します。企業は、Oracle SOA Suiteによるルール駆動型ビジネス・プロセスの自動化により、効率性と機動性を改善できます。Oracle SOA Suiteが提供するリアルタイムの傾向分析、視覚化およびライフ・サイクル可視性の機能により、企業は重要な変化を予測して、それに対応できるようになります。Oracle SOA Suiteには次の機能があります。

- オンプレミス・アプリケーションとクラウド・アプリケーションの統合による、複雑性の軽減。

- Representational State Transfer (REST)のサポートが可能にする、高速モバイルでの既存の機能の活用。

- 異なるサービスおよびアプリケーションからのSOAコンポジット・アプリケーションの設計。

- 統合された接続フレームワーク(アダプタ、B2Bゲートウェイ、およびOracle Data Integration Suiteとの事前統合を含む)を介したほとんどすべてのデータ・ソース・テクノロジ(メッセージング、データベースなど)、アプリケーションまたは取引パートナへの接続。

- スケーラビリティの高いOracle Service Busによるサービスのルーティング、変換および仮想化。

- Oracle BPEL Process Managerによるプロセス自動化のオーケストレーションおよび構築。

- Oracle Business Rulesを使用して個々のロジック・ブロックを外部化することによる機動性の構築。

- Oracle Event Processingによる複数のデータ・ストリームと時間枠にわたる特定のパターンのリアルタイム検出の実行。

- Oracle Business Activity Monitoringによる、ビジネス・プロセスの操作およびパフォーマンスに対するリアルタイム可視性の実現(特定の状況への対応機能も含まれる)。

- Oracle Enterprise Manager Fusion Middleware Controlでポリシー駆動型の統合セキュリティ・フレームワークおよびグローバル・ポリシー・マネージャを使用することによる、すべてのサービスの一貫した簡単な保護。

- 統合され、最適化されたインフラストラクチャによるSOA・コンポジット・アプリケーションの実行。SOAサービス・インフラストラクチャは、Oracle WebLogic Server、JRockitおよびOracle Coherence上に構築されています。

- Oracle Enterprise Manager Fusion Middleware Controlでネイティブに統合された単一コンソールによる、前述のコンポーネントの管理とモニター。

1.3 主要コンポーネント

Oracle SOA Suiteの主要コンポーネントは次のとおりです。

- Oracle Service Bus
Oracle Service Busは、SOAライフ・サイクル管理用に設計された構成ベースでポリシー駆動型のEnterprise Service Busです。Oracle Service Busには次の機能があります。

- サービスの検出と仲介

- 迅速なサービスのプロビジョニングとデプロイメント

- スケーラビリティと信頼性の高いサービス指向の統合、サービス管理、異なるIT環境での従来のメッセージ・ブローカリング

- 統合ソフトウェア製品でのインテリジェントなメッセージ・ブローカリング、メッセージのルーティングと変換、およびサービス・モニタリングと管理

詳細は、『Oracle Service Busでのサービスの開発』およびOracle Service Busの管理を参照してください。

- Oracle Business Process Execution Language (BPEL) Process Manager
Oracle BPEL Process Managerは、エンドツーエンドのプロセス・フローに個別のサービスのセットを統合するための包括的な、標準ベースの使用しやすいソリューションを提供し、プロセス統合のコストと複雑性を削減します。BPELプロセス・サービス・エンジンは、成熟した、スケーラブルで堅牢なBPELサーバーです。これは標準のBPELプロセスを実行し、デハイドレーション機能を提供します。これにより、長時間実行されているビジネス・フロー・インスタンスの状態が自動的にデータベースで保持され、フェイルオーバーとスケーラビリティの両方を目的としたクラスタリングが可能になります。タスク管理、通知管理、ワークリスト管理などの組込みのヒューマン・ワークフロー・サービスも備わっているため、人と手動タスクをBPELビジネス・フロー・インスタンスに統合できます。Oracle BPEL Process Managerでは、アプリケーションやレガシー・システムの統合、詳細なサービスからの疎粒度のサービスの構成、プロセス中心のコンポジット・アプリケーションの構築、およびルーティングやエスカレーションを含む、ビジネス・プロセスやワークフロー・アプリケーションの自動化が可能になります。

詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』および『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

- Oracle Event Processing
Oracle Event Processingは、リアルタイムでイベントのフィルタリング、関連付けおよび処理を行うアプリケーションを構築するための完全なソリューションです。柔軟なデプロイメント・オプション(スタンドアロン、SOAスタックに統合、埋込みJavaで軽量化)により、高パフォーマンスなイベント処理エンジンを提供します。Oracle Event Processingにより、高速データから実行可能な洞察が得られ、様々なデータ・ソースからの大量の高速データの価値をリアルタイムに最大化できます。また、高速データをネットワーク・エッジにプッシュすることにより、ホスト間の応答が可能になります。

ANSI SQL、Java, Spring Dynamic Modules (DM)、Open Service Gateway initiative (OSGI)などの業界標準に基づいて構築されたOracle Event Processingは、企業全体に複合イベントを供給、処理および公開するためのオープン・アーキテクチャを提供します。Oracle Event Processingは、ビジュアル開発環境と標準Javaベースのツールの両方を備えているため、ITチームは、専門トレーニングや固有のスキル・セットへの投資を必要とせずに、イベント駆動型アプリケーションを開発できます。

詳細は、『Oracle Event Processingアプリケーションの開発』および『Oracle Event Processingの管理』を参照してください。

- Oracle Business Activity Monitoring
Oracle Business Activity Monitoringは、ビジネス・プロセスをリアルタイムでモニターし、情報に基づく戦略的なビジネスの意思決定を可能にします。従来のレポート・システムとは異なり、Oracle Business Activity Monitoringでは、基幹ビジネス・プロセスに対して適時のオペレーショナル・インテリジェンスを実現します。Oracle Business Activity Monitoringは、ビジネス・イベントの発生中およびその前後のデータを分析します。

詳細は、『Oracle BAMでのビジネス・アクティビティのモニタリング』を参照してください。

- Oracle Business Rules
Oracle Business Rulesにより、実行時の動的なビジネスの意思決定が可能になり、ルールのロジックを基礎となるアプリケーション・コードから分離しながらポリシー、計算および判断を自動化できます。これにより、より迅速なルール・メンテナンスが可能になり、ビジネス・アナリストは、プログラマによる支援を受けたりビジネス・プロセスを中断させることなく、ルール・ロジックを変更できるようになります。

詳細は、『Oracle Business Process Managementによるビジネス・ルールの設計』を参照してください。

- Oracle Java EE Connector Architecture (JCA)アダプタ
Oracle JCAアダプタにより、企業内のほとんどすべてのデータ・ソースに接続できます。Oracle JCAアダプタは標準ベースで、WebサービスとJCAテクノロジの両方をサポートしています。Oracle JCAアダプタは、次のものに使用できます。

- パッケージ・アプリケーション

- Tuxedo、Virtual Storage Access Method (VSAM)、Customer Information Control System (CICS)などのレガシーおよびメインフレーム・アプリケーション

- クラウド・アプリケーション

- FTP、ファイル、データベース、AQ、JMS、MQSeries、コヒーレンス、LDAP、ユーザー・メッセージング・サービス、Oracle E-Business Suiteなどのテクノロジおよびプロトコル

詳細は、『テクノロジ・アダプタの理解』を参照してください。

- Oracle B2B
Oracle B2Bは、企業と取引パートナとの電子的な情報交換を可能にします。Oracle B2Bは、Electronic Data Interchange (EDI)、UCCnet、RosettaNet、Chemical Industry Data Exchange (CIDX)、Petroleum Industry Data Exchange (PIDX)、Voluntary Interindustry Commerce Solutions (VICS)、ebXML、Universal Business Language (UBL)など、業界標準のセットをサポートします。

詳細は、『Oracle B2Bユーザーズ・ガイド』を参照してください。

- Oracle SOA for Healthcare
Oracle SOA Suite for Healthcareでは、ヘルスケア・データを処理するアプリケーションを設計、作成および管理できます。Oracle SOA Suite for healthcare integrationは、ヘルスケア統合アプリケーションを作成および構成し、それらのアプリケーションにより処理されたメッセージをモニターおよび管理するWebベースのユーザー・インタフェースを提供します。また、Oracle Document Editorを使用して、メッセージ構造を定義するドキュメント定義を作成および構成することもできます。

詳細は、Oracle SOA Suite Healthcare Integrationユーザーズ・ガイドを参照してください。

Oracle SOA Suiteは、次の追加コンポーネントと統合できます。

- Oracle Enterprise Scheduler
エンタープライズ・アプリケーションには、将来実行される大規模なトランザクションの負荷を軽減したり、定義されたスケジュールに基づいたアプリケーション・メンテナンス作業の実行を自動化したりする機能が必要です。Oracle Enterprise Schedulerにより、Oracle WebLogic Serverクラスタのノード全体に分散された、Java、PL/SQL、バイナリ・スクリプト、Webサービス、Enterprise JavaBeans (EJBs)などの、様々なジョブ・タイプを実行できるようになります。Oracle Enterprise Schedulerは、これらのジョブを安全に実行すると同時に、高可用性とスケーラビリティを実現し、ロード・バランシングを行います。Oracle Enterprise Schedulerの実行は、Oracle Enterprise Manager Fusion Middleware Controlを使用してモニターおよび管理されます。

詳細は、Oracle Enterprise Schedulerでのアプリケーション開発およびOracle Enterprise Schedulerの管理を参照してください。

- Oracle Managed File Transfer。
Oracle Managed File Transferは、高パフォーマンスで、標準ベースのエンドツーエンド管理対象ファイル・ゲートウェイです。これは、ファイル暗号化、スケジューリング、埋込みFTPおよびsFTPサーバーを含む軽量でWebベースの設計時コンソールを使用した設計、デプロイメント、およびファイル転送のモニタリングを特徴とします。

詳細は、『Oracle Managed File Transferの使用』を参照してください。

1.4 主要管理ツールとプロセス

Oracle SOA Suiteでは、多数の開発ツール、モニタリング・ツールおよび管理ツールを提供しています。

1.4.1 Oracle JDeveloper

Oracle JDeveloperは、最新の業界標準のJava、XML、Webサービス、SQL、REST、SCAを使用するサービス指向アプリケーションを構築するためのOracle SOA Suiteで使用される統合開発環境です。Oracle JDeveloperではアプリケーションのモデリング、コーディング、デバッグ、テスト、プロファイリング、チューニングおよびデプロイの各機能を統合して、開発ライフ・サイクル全体をサポートします。Oracle JDeveloperには、SOAプロジェクトで使用される様々なコンポーネントおよびテクノロジを迅速かつグラフィカルに組み立てるためのSOA Composite Editorが搭載されています。ユーザー・フレンドリなウィザードは、ITシステムへの接続など、多くの共通タスクを簡素化するために提供されます。

1.4.2 Oracle Enterprise Manager Fusion Middleware Control。

Oracle Enterprise Manager Fusion Middleware Controlは、SOAコンポジット・アプリケーションを実行時に管理およびモニターするためのWebペースのツールです。管理者は、ビジネス・フロー・インスタンスの追跡、セキュリティ・ポリシーのアタッチ、特定のデータの検索による特定のメッセージの識別、エラー・ホスピタルでのエラーの識別と修正などのタスクを実行します。Oracle Enterprise Manager Fusion Middleware Controlは、プロセスの実行に可視性を提供し、ビジネス・フローの完全にエンドツーエンドのグラフィカルな表示も可能にします。また、それに続いてすべてのコンポーネントを横断的に網羅する特定のメッセージが表示されます。

1.4.3 追加の設計およびランタイム・ツール

Oracle SOA Suiteでは、表1-1で説明するように、一部のコンポーネントに対する追加の設計およびランタイム・ツールが用意されています。

表1-1 追加の設計およびランタイム・ツール

ランタイム・ツール

説明

Oracle BAM Composer

ダッシュボード、アラート、ビジネス・ビュー、キー・パフォーマンス・インディケータ(KPI)、アラートおよびパラメータを作成するためのユーザー・インタフェースを提供します。

Oracle B2Bコンソール

取引パートナおよび取引パートナ・アグリーメントを含む、B2Bトランザクションを作成するためのユーザー・インタフェースを提供します。

Oracle Managed File転送コンソール

次のアーティファクトを定義するための軽量で、Webベースの設計時コンソールを提供します。

- 転送ファイルの元(ソースと呼ばれる)

- ファイルの宛先(ターゲットと呼ばれる)

- ソースをターゲットに関連付ける転送

Oracle Service Busコンソール

サービス・レベル・アグリーメント・アラート、パイプライン・アラート、メッセージング・レポート・アクション、アラート宛先、ビジネス・サービス・エンドポイントのスロットル・グループを作成するための構成ツールを提供します。個別に、または一括して、環境値を更新することもできます。

Oracle SOA Composer

ドメイン値マップ、承認管理の拡張、ビジネス・ルール、デプロイ済コンポジットのコンポジット・センサーを作成するためのランタイム環境を提供します。

Oracle Healthcare for Healthcare Integrationコンソール

プロトコルのメッセージング、エンドポイントの作成と管理、ドキュメントの管理、マップ・セットの作成、Javaコールアウトの作成を行うためのサポートを提供します。

1.5 Oracle SOA Suiteプロセス・フローの概要

このガイドの残りの章では、企業が直面するビジネス課題に対処するため、設計時から実行時にわたってプロセス・フローでOracle SOA Suiteコンポーネントを連携する方法の概要を示します。

詳細は、「会社Xのビジネス課題」を参照してください。

第II部 ビジネス課題とOracle SOA Suite

この部では、ビジネス課題と、設計時から実行時までのOracle SOA Suiteコンポーネントによるこれらの課題の対処方法について説明します。

- 会社Xのビジネス課題

- クレジット検証システムの作成

- 注文処理システムの作成

- 新規注文チャネルの追加

- 注文の梱包と出荷

- 注文の履行

- コンポジットの実行のスケジューリング

- ファイル転送の管理

- B2Bの注文の受入れ

- 不正検出の追加

- Oracle Business Activity Monitoringを使用したビジネス・インサイトの取得

2 会社Xのビジネス課題

この章では、会社Xが直面するビジネス課題、およびOracle SOA Suiteでこれらの課題に対するビジネス・ソリューションを提供する方法について説明します。

この章の内容は次のとおりです。

- 会社Xのビジネス課題

- ソリューション

2.1 会社Xのビジネス課題

会社Xは、オンライン・ビジネス・パートナとのマルチチャネルでの成長に対応するために、自社の注文処理システムを改善する必要があります。また、積極的な店舗拡大も計画されています。そのため、重複するシステムを統合して、注文から履行までのエンドツーエンドの可視性を向上させる必要があります。

注文処理システムを改善するための要件は次のとおりです。

- 注文処理システムは、モバイル機器を含む、複数のプロトコル、データ・フォーマットおよびクライアント・タイプからアクセスできる必要があります:

- ビジネス・トレンドは、会社Xがモバイル・アプリケーションをなるべく早く提供する必要があること、また新しい注文処理サービスがRESTful APIを介したアクセスをサポートする必要があることを示しています。

- 会社Xでは、既存のオンラインの直営店のほか、(FTPを介したカンマ区切り値(CSV)のバッチ・ファイルとして)異なるチャネルから受注するサービスの開始を計画しています。これらの注文は、最終的には、同じ新規の注文プロビジョニング・インフラストラクチャを使用して処理および履行する必要があります。

- 会社Xは、取引パートナとやりとりしたり、電子データ・インタフェース(EDI)サポートを提供する必要があります。

- 大口注文では、履行するために注文を送信する前に、顧客のクレジット履歴を確認する必要があります。そうしない場合、注文は拒否されます。最初に、クレジットは内部部署で確認しますが、後でPayPalと統合する必要があります。クレジット・プロバイダの変更が、注文処理操作に支障を与えないようにする必要があります。

- 注文処理システムは、出荷サービスのタイプ(2日、5-7日の出荷など)に基づいた優先出荷プロバイダで注文を出荷するために、包装部署と直接統合する必要があります。

- 事前定義済収集スケジュールに従って、一括履行プロセスを実行する必要があります。

- 包装部署に送信される履行処理および注文に基づいて、(一括またはオンデマンドのいずれかで)顧客にメッセージを送信する必要があります。

2.2 ソリューション

このガイドのこの章では、会社XがOracle SOA Suiteの機能を使用して、自社のビジネス課題に対処する方法について説明します。表2-1に概要を示します。

表2-1 ビジネス課題への対処

対処する課題

参照先

会社Xは、支払を検証して支払ステータスを返す、クレジット・カード検証コンポジットを設計します。支払が拒否されると、注文は処理されません。Oracle Service Busはコンポジットと統合され、登録およびセキュリティ上の利点を提供します。

クレジット検証システムの作成

会社Xは、新規の注文書を受け入れた後、それを認可するか拒否して、認可された注文を「注文の履行」で設計される注文履行コンポジットに送信する、SOAコンポジット・アプリケーションを設計します。Oracle Service Busにより、注文処理コンポジットが多くのプロトコルおよびデータ・フォーマットで利用可能になり、注文が検証されます。

注文処理システムの作成

会社Xは、プロキシ・サービスをファイル注文チャネルに接続する、Oracle Service Busパイプラインを設計します。プロキシは、受信された顧客注文をファイルごとに処理します。

新規注文チャネルの追加

会社Xは、注文のステータスを出荷済に設定し、顧客に注文が出荷されたことを通知して、データベースの注文ステータスを更新するBPELプロセスを設計します。このプロセスは、出荷リソースを定義するインバウンドRESTインタフェース・サービスに接続されます。

注文の梱包と出荷

会社Xは、注文が処理されるのをリスンするための注文履行コンポジットを設計し、出荷プロバイダを選択して、「注文の梱包と出荷」で設計される梱包および出荷サービスを起動します。

注文の履行

会社Xは、毎日注文される指定カテゴリの製品別合計アイテム数を識別する、問合せインベントリ・コンポジットを設計します。Oracle Enterprise Schedulerを使用して、問合せインベントリ・コンポジットのWebサービス・ジョブを定義し、指定された時刻での実行をスケジューリングしてそのジョブを送信します。

コンポジットの実行のスケジューリング

会社Xは、Managed File Transfer埋込みFTPサーバーを使用してファイルを受信したり、そのファイルをファイル・システムに書き込む、Oracle Managed File Transferフローを設計します。Oracle Managed File Transferは、コンポジットのManaged File Transferサービスを起動し、コンテンツをインラインで渡すか、参照によって渡すかをファイル・サイズに基づいて動的に決定します。

ファイル転送の管理

会社Xは、Oracle B2Bコンソールを使用して、リモート取引パートナからのEDI XML注文を受け入れるドキュメント・フローを構築します。

B2Bの注文の受入れ

会社Xは、関連付けられた電子メール・アドレスで個別認識されている顧客による発注(イベント)のリアルタイムな、時間ベースの分析を提供する、Oracle Event Processingアプリケーションを設計します。注文(イベント)がOracle Event Processingサーバーに渡されると、そのイベントが動的にアクセスされて、潜在的な不正行動を調べるために24時間で$1000を超える注文合計額に達するイベント・パターンが観察されます。

不正検出の追加

会社Xは、BPELプロセスの分析測定と、BPELプロセスのアクティビティにおけるビジネス・インジケータを設計します。Oracle BAM Composerを使用して、これらの分析のダッシュボードを作成し、顧客注文リクエストへのビジネス・インサイトを得ます。

Oracle Business Activity Monitoringを使用したビジネス・インサイトの取得

3 クレジット検証システムの作成

この章では、Oracle SOA Suiteでクレジット検証システムの作成というビジネス課題に対処する方法について説明します。BPELプロセスのinvoke、assign、transformationアクティビティ、データベース・アダプタ、SOAテンプレートおよびコンポジット・センサーを含む、主要なSOAコンポジット・アプリケーション・コンポーネントの作成方法、およびこの課題に対処する方法の概要が示されます。また、このビジネス・ソリューションにおけるOracle Service Busの役割についても説明されます。

この章の内容は次のとおりです。

- ビジネス課題

- ビジネス・ソリューション

- 関連ドキュメント

3.1 ビジネス課題

会社Xは、顧客満足度を高めるためのプロジェクトを立ち上げました。改善の主要領域は、注文ライフ・サイクルの次の部分における注文追跡表示を向上させるために注文プロセスを合理化する必要性です。

- クレジットの承認

- 履行

- 出荷

- 配送

現在のシステムの主な問題は、クレジット・カードの支払が些細な理由により拒否される場合が多いということです。これらの問題を修正するプロセスは会社Xの注文入力システムによって異なるため、顧客に対する一貫したフォローアップや解決策がありません。システムで注文が消失したり、遅れが生じると、顧客は不満を抱きます。

会社Xは、クレジット・カードの不正使用を排除するため、年度末に新しいクレジット・カード不正検出システムも設置する必要があると判断しました。一貫した不正メカニズムでは、すべての注文入力システムでクレジット検証プロセスを統合する必要があります。

最初のステップは、クレジット検証用のすべての注文入力アプリケーションに対して一貫したインタフェースを提供することです。統合されたクレジット検証サービスは、品質管理のために、最初は社内でホストされることになりました。ただし、インタフェースの安定性を確保した後、このサービスは、サード・パーティ・プロバイダに委託されます。将来、会社Xが外部プロバイダにクレジット検証を委託することを決めた場合でも、これは既存のアプリケーションへの影響なしで実行できます。

3.2 ビジネス・ソリューション

このビジネス課題に対処するために、会社Xは表3-1で説明するコンポーネントを使用するビジネス・ソリューションを設計します。

表3-1 ビジネス・ソリューションを提供するコンポーネント

コンポーネント

このコンポーネントがビジネス課題に対処する方法

コンポーネントの説明

SOAコンポジット・アプリケーション

SOAコンポジット・アプリケーションは、支払を検証して、ステータスを返すように設計されます。支払が拒否されると、注文は処理されません。コンポジットは、次のコンポーネントから構成されます。それぞれについて、簡潔に後述します。

- BPELプロセス・サービス・コンポーネント

- データベース・アダプタ

- SOAテンプレート

- コンポジット・センサー

SOAコンポジット・アプリケーションは、次のコンポーネントで構成されます。

- サービス・バインディング・コンポーネント:
外部に対してSOAコンポジット・アプリケーションへのエントリ・ポイントを提供します。

- サービス・コンポーネント
ビジネス・ロジックやアプリケーションの処理ルールを実装します。

- 参照バインディング・コンポーネント:
SOAコンポジット・アプリケーションから外部にある外部サービスに送信するメッセージを有効にします。

- BPELプロセス・サービス・コンポーネント

BPELプロセス(およびそのアクティビティ)は、クレジット・カード支払の検証をオーケストレートし、支払ステータスを返します(データベース・アダプタを起動します)。

BPELプロセスは、ビジネス・プロセスを作成、デプロイおよび管理するための包括的で使用しやすいインフラストラクチャを提供します。BPELは、個別のサービスをエンドツーエンドのプロセス・フローに組み立てるための標準です。BPELプロセスは、プロセス自動化のオーケストレーションおよび構築を実行します。

- データベース・アダプタ

データベース・アダプタは、支払タイプ、カード番号、有効期限、カード名義および1日の利用限度額を含む、データベースからのクレジット・カード支払情報を格納および取得します。クレジット・カード番号がデータベースにない場合、支払は拒否されます。

データベース・アダプタを使用すると、Oracle SOA SuiteおよびOracle Fusion Middlewareとデータベース・エンドポイントとの通信が可能になります。これには、ANSI SQL標準に準拠し、JDBCドライバを備えたOracleデータベース・サーバーおよびリレーショナル・データベースが含まれます。

- SOAテンプレート

1日の利用限度額と合計注文金額に基づいた支払ステータス(認可または拒否)を決定する変換アクティビティを含む、BPELスコープ・アクティビティ・テンプレートがインポートされます。

SOAテンプレートは、Oracle SOA Suiteプロジェクトの再使用可能な部分で、新規プロジェクトの作成に使用されます。テンプレートには、次の3種類があります。

- SOAプロジェクト

- サービス・コンポーネント

- カスタムBPELスコープ・アクティビティ

- コンポジット・センサー

コンポジット・センサーは、クレジット・カード支払ステータスを追跡します。

コンポジット・センサーは、メッセージにトラッキング可能なフィールドを実装する手段を提供します。

Oracle Service Bus

Oracle Service Busは、コンポジット登録とセキュリティ上の次の利点を提供します。

- ビジネス・サービスは、SOAコンポジット・アプリケーションのコンポジットURIを登録します。

- パイプラインは、起動前のSOAコンポジット・アプリケーションを検証します。

- プロキシにより、顧客はコンポジットに直接接続するかわりに、プロキシを介してコンポジットを起動できます。

Oracle Service Busは、構成ベースでポリシー駆動のEnterprise Service Busです。スケーラビリティと信頼性の高いサービス志向の統合やサービス管理、また、異なるIT環境に対して従来のメッセージ・ブローカリングを提供します。

図3-1に、このビジネス・ソリューションの実装方法の概要を示します。

図3-1 支払検証の概要

この章の後続の項では、表3-1のコンポーネントを使用して、クレジット検証のビジネス課題に対処する方法について、より詳細に説明します。

- クレジット検証コンポジットの作成

- データベースからのクレジット・カード支払情報の取得

- BPELプロセスからのデータベース・アダプタの起動

- XSLT変換を使用した支払ステータスの計算

- コンポジット・センサーを使用した支払ステータスの追跡

- validatePaymentコンポジットのデプロイ

- SOAコンポジット・アプリケーションの登録

- デプロイおよびテスト

3.2.1 クレジット検証コンポジットの作成

ビジネス・ソリューションは、クレジット・カード支払を検証し、支払ステータスを返す、SOAコンポジット・アプリケーション内で設計されます。支払が拒否されると、注文は処理されません。このサービスの実装では、BPELプロセスを使用して、データベース・アダプタを起動し、データベースからクレジット・カード・データを取得して、検証を実行します。このサービスは、認可済または拒否済の支払ステータスを返します。

図3-2に、クレジット検証コンポジットの概要を示します。顧客のリクエストは、validatepaymentprocessサービスから発生します。SOAコンポジット・アプリケーション(validatePaymentという名前)はこれらのリクエストを取得し、getPaymentInformationという名前のデータベース・アダプタ参照を起動して、データベースからクレジット・カード情報を取得します。データベース・アダプタは、アダプタ構成ウィザードで構成されます。

図3-2 クレジット検証プロセス

次の例は、インバウンド注文メッセージのコンテンツを示しています。顧客は、クレジット・カード番号、有効期限、カード・タイプおよび請求先住所を提供します。

<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-3 データベース接続

- データベースの「選択」オプションが、データベース問合せを作成するために選択されます(図3-4を参照)。

図3-4 データベース操作タイプ

- 適切なクレジット・カード情報の表がデータベースからインポートされます(図3-5を参照)。

図3-5 インポートされるクレジット・カード情報を含む表

- データベース問合せの「選択」操作の作成に使用する、適切なクレジット・カード・フィルタリング情報が有効になります(図3-6を参照)。

- 有効期限

- 1日の利用限度額

- 現在の限度

図3-6 クレジット・カードのフィルタリング

- 「選択」操作のための適切なクレジット・カード条件が指定されます(図3-7を参照)。ccnbパラメータが、インバウンド・メッセージ(CardNum)で指定される顧客のクレジット・カード番号に対して提供されます(「クレジット検証コンポジットの作成」を参照)。データベース・アダプタは、クレジット・カード番号をキーとして使用して、データベースからクレジット・カード支払情報を取得します。

図3-7 選択条件の定義

データベース・アダプタは、選択内容肢を処理し、指定された操作を実装する参照を生成します。これで、データベース・アダプタ参照getPaymentInformationを表すWSDLファイルがSOAコンポジット・アプリケーションに含まれるようになります。図3-2のコンポジット・ダイアグラムは、getPaymentInformation参照を示しています。

3.2.3 BPELプロセスからのデータベース・アダプタの起動

会社Xは、SOAコンポジット・アプリケーションでBPELプロセス・サービス・コンポーネントを作成します。BPELプロセスは、ビジネス・ソリューションのロジックをオーケストレートします。BPELプロセスのinvokeアクティビティは、パートナ・リンクとしてデータベース・アダプタを起動し、データベースからクレジット・カード情報を取得します。図3-8に詳細を示します。

図3-8 BPELプロセスのgetPaymentInformation参照の起動

BPELプロセス内のinvokeアクティビティは、データベース・アダプタ(getPaymentInformation)をコールします(図3-9を参照)。デザイナの下のプロパティ・インスペクタから、またはinvokeアクティビティをダブルクリックして、invokeアクティビティの詳細を作成および編集できます。

- 名前

- 起動するパートナ・リンク(この例では、データベース・アダプタ)

- ポート・タイプ

- 実行する操作

- 「入力」タブの下の入力変数(データベース・アダプタに送信するクレジット・カード番号が含まれる)

- 「出力」タブの下の出力変数(データベース・アダプタからの結果を返す)

図3-9 データベース・アダプタを起動するinvokeアクティビティ

assignアクティビティは、invokeアクティビティの入力変数の移入に使用されます。assignアクティビティ(setCreditCardNumber)の「コピー・ルール」タブで、CardNumとしてBPELプロセスに渡されるクレジット・カード番号がgetPaymentInformationデータベース・アダプタのccnbパラメータに割り当てられます。図3-10に詳細を示します。

図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プロセスにドラッグできます。

図3-11 カスタム・アクティビティ・テンプレート

カスタムscopeアクティビティは、transformアクティビティで構成されます。この例の変換では、図3-12の「ソース」セクションで示すように、2つの入力変数が期待されています。

- データベースに格納される支払情報を含む、データベース・アダプタの出力変数

- 注文合計金額を含む、BPELプロセスの入力変数

図3-12の「ターゲット・パート」セクションで示すように、出力は、出力メッセージの「ステータス」フィールドにあります。このフィールドは、拒否または認可のいずれかに設定されます。

図3-12 変換変数

XSLTマップ・エディタのマッピングは、図3-13に示します。

図3-13 XSLTマップ・エディタの変換

3.2.5 コンポジット・センサーを使用した支払ステータスの追跡

会社Xは、注文支払のステータス(認可または拒否)を追跡できる必要があります。この要件に対処するために、コンポジット・センサーが使用されます。コンポジット・センサーは、メッセージにトラッキング可能なフィールドを実装する手段を提供します。コンポジット・センサー・データは、実行時にデータベース内に保持されます。これにより、すべての認可済または拒否済の支払を検索できます。

コンポジット・センサーを使用すると、次のタスクを実行できます。

- 受信メッセージおよび送信メッセージを監視できます。

- Oracle Enterprise Manager Fusion Middleware Controlで特定のセンサー詳細を検索することにより、特定のインスタンスを確認します。

- 受信メッセージおよび送信メッセージから計算されたJMSデータをパブリッシュします。

- ビジネス・イベント・サブスクリプションによって開始されたコンポジット・インスタンスを追跡します。

コンポジット・センサーは、インバウンドSOAP Webサービス・バインディング・コンポーネントで定義されます(図3-14を参照)。コンポジット・センサーは、ビジネス・イベント・サブスクリプションを持つ参照バインディング・コンポーネントおよびサービス・コンポーネントで定義することもできます。

図3-14 SOAPサービス・バインディング・コンポーネントのコンポジット・センサー定義

図3-15の「コンポジット・センサーの作成」ダイアログは、XPath式が支払ステータス(認可または拒否)を追跡するために定義されることを示しています。「Enterprise Manager」チェック・ボックスも選択されます。これにより、Oracle Enterprise Manager Fusion Middleware Controlの「フロー・インスタンス」ページでコンポジット・センサーの名前と値(たとえば、Status=Authorized)を表示できるようになります。

図3-15 コンポジット・センサー

センサーは、SOAP Webサービス・バインディング・コンポーネントvalidatepaymentprocessのアイコンとして表示されます。アイコンにカーソルを置くと、コンポジット・センサーの定義が表示されます。図3-16に詳細を示します。

図3-16 コンポジット・センサーの詳細

3.2.6 validatePaymentコンポジットのデプロイ

会社Xは、Oracle JDeveloperでvalidatePaymentコンポジットをデプロイします(図3-17を参照)。

図3-17 validatePaymentコンポジットのデプロイメント

デプロイメント・プロセス中に、「アダプタ構成ウィザードを使用したデータベース・アダプタの構成」でアプリケーション・サーバー接続を作成したサーバーに、コンポジットがデプロイされます。図3-18に詳細を示します。

図3-18 アプリケーション・サーバーへのデプロイメント

コンパイル・エラーがない場合、ビルドが成功し、デプロイメントが開始されます。図3-19に詳細を示します。

図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-20 Oracle Service Busアプリケーションの設計登録の準備完了

設計登録の完了後、ビジネス・ソリューションは図3-21のようになります。

図3-21 Oracle Service Busアプリケーションの登録

次の項では、Oracle Service Busアプリケーションの登録の概要について説明します。

- フォルダとリソースの共有

- SOAコンポジット・アプリケーションのコンポジットURIの登録

- パイプラインとプロキシの構成

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-22 「Service Busリソースのインポート」ウィザード - 「構成」ページ

ウィザードの構成が完了すると、図3-23に示す「アプリケーション」ウィンドウにアーティファクトが表示されます。

図3-23 Oracle Service BusでインポートされたWSDLおよびスキーマ・ファイル・リソース

3.2.7.2 SOAコンポジット・アプリケーションのコンポジットURIの登録

ビジネス・サービス(図3-21のValidateBS)は、SOAコンポジット・アプリケーションのコンポジットURIを登録し、validatePaymentコンポジットを表示します。構成を行うには、「コンポーネント」ウィンドウからOracle Service Busアプリケーションの「外部参照」スイムレーンに「HTTP」アイコンをドラッグします(図3-24を参照)。

図3-24 ValidateBSビジネス・サービス

このアクションにより、次のものを構成するための「ビジネス・サービスの作成」ウィザードが起動します。

- トランスポート・タイプとしての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-25 プロキシのWSDLの選択

ウィザードの後続のページで、「プロキシ・サービスとして公開」チェック・ボックスも選択されます。図3-26に詳細を示します。

図3-26 「プロキシ・サービスとして公開」チェック・ボックス

図3-27は、「コンポーネント」セクションの「ValidatePP」パイプライン、および「公開されたサービス」スイムレーンの「ValidatePS」プロキシを示しています。

図3-27 プロキシおよび「コンポーネント」セクションのパイプラインの構成

3.2.8 デプロイおよびテスト

アプリケーション設計の完了後、会社Xは「ValidatePS」プロキシを右クリックして、「実行」を選択することにより、アプリケーションのエンドツーエンドにデプロイしてテストします。図3-28に詳細を示します。

図3-28 アプリケーションの起動

テスト用のペイロードを選択可能なテスト・コンソールが表示されます。サンプルのペイロードが生成されています。図3-29に詳細を示します。

図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データベース・アダプタの定義に関する項。

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でのサービスの開発』のビジネス・サービスの作成方法に関する項

- フォルダの作成

- リソースのインポート

- ビジネス・サービスの追加

- パイプラインおよびプロキシの作成

パイプラインの追加

『Oracle Service Busでのサービスの開発』のパイプラインの追加方法に関する項

プロキシの作成

『Oracle Service Busでのサービスの開発』のプロキシ・サービスの作成方法に関する項

4 注文処理システムの作成

この章では、Oracle SOA Suiteで注文処理システムの作成というビジネス課題に対処する方法について説明します。SOAコンポジット・テンプレート、インラインBPELサブプロセス、コンポジット・センサー、Oracle Service Busプロキシ・サービス、パイプライン、ビジネス・サービスなどの主要なSOAコンポジット・アプリケーション・コンポーネントの作成方法、およびこの課題に対処する方法の概要を示します。

この章の内容は次のとおりです。

- ビジネス課題

- ビジネス・ソリューション

- 関連ドキュメント

4.1 ビジネス課題

会社Xは、次のビジネス課題に対処する注文処理システムを設計する必要があります。

- モバイル機器を含む、多様なクライアントは、様々なプロトコルを介して、様々なデータ・フォーマットでシステムにアクセスします。

- 新規の注文処理システムは、(開発中のモバイル・アプリケーションへの移行を準備するために)RESTインタフェースからのアクセスをサポートする必要があります。

- 既存のシステムは、XMLおよびカンマ区切り値(CSV)ファイルを使用して発注できる必要があります。これらの注文は、同じ新規の注文プロビジョニング・システムを使用して処理および履行される必要があります。

- システムは、取引パートナとやりとりしたり、電子データ交換(EDI)サポートを提供する必要があります。

4.2 ビジネス・ソリューション

これらのビジネス課題に対処するために、会社Xは、表4-1のコンポーネントを使用するビジネス・ソリューションを設計します。

表4-1 ビジネス・ソリューションを提供するコンポーネント

コンポーネント

このコンポーネントがビジネス課題に対処する方法

コンポーネントの説明

SOAコンポジット・アプリケーション

SOAコンポジット・アプリケーションは、新しい発注書を受け入れ、それらを認可するか拒否して、認可済注文を注文履行システムに転送するように設計されています。コンポジットは、次のコンポーネントから構成されます。それぞれについて、簡潔に後述します。

- SOAプロジェクト・テンプレート

- インラインBPELサブプロセス

- コンポジット・センサー

SOAコンポジット・アプリケーションの詳細は、表3-1を参照してください。

SOAプロジェクト・テンプレート

SOAプロジェクト・テンプレートがインポートされます。テンプレートを使用して、SOAコンポジット・アプリケーションを作成します。コンポジットの事前定義済コンポーネントが、基本のシナリオを実装します:

- Webサービス・コールからの注文の受信

- 注文番号とステータスの作成

- 金額の計算

- データベースへの注文の保存

- 顧客への注文確認と注文番号の返信

次の操作が発生します。

- 支払が拒否された場合、注文ステータスが拒否に設定され、処理が停止します。

- 支払が認可された場合、注文ステータスが認可に設定され、注文は処理のために注文履行システムに送信されます。(「注文の履行」を参照)。処理が終了すると、注文ステータスは「ReadyForShip」に設定されます。

SOAプロジェクト・テンプレートの詳細は、表3-1を参照してください。

インラインBPELサブプロセス

インラインBPELプロセスは、(callアクティビティを使用して)「クレジット検証システムの作成」の支払検証システムを起動し、支払検証の結果に基づいてデータベース内の注文ステータスを更新します。

サブプロセスは、別のプロセスがコンポジット内で再使用できるBPELコードのフラグメントです。このサブプロセス拡張機能には、次の利点があります。

- BPELプロセス・コードを再使用できることで、同じタスクを実行するために、同じアクティビティを何度も作成する必要がなくなります。

- コードのモジュール性。

- コードのメンテナンス(変更内容の伝播により、変更が必要になるたびに複数の場所に更新を実装する必要がなくなります)。

- メモリー・フットプリントが減少します。メモリー・フットプリントは、複雑なプロセスでは大量となる場合があります。

コンポジット・センサー

コンポジット・センサーは注文番号を追跡します。

SOAコンポジット・センサーの詳細は、表3-1を参照してください。

Oracle Service Busプロキシ・サービス、パイプラインおよびビジネス・サービス

Oracle Service Busは、多数のプロトコルやデータ・フォーマットで注文処理コンポジットが利用できるようにし、注文を検証します。

Oracle Service Busの詳細は、表3-1を参照してください。

図4-1に、このビジネス・ソリューションの実装方法の概要を示します。

図4-1 注文プロセスの概要

この章の後続の項では、表4-1のコンポーネントを使用して、注文処理のビジネス課題に対処する方法について、より詳細に説明します。

- SOAプロジェクト・テンプレートからのSOAコンポジット・アプリケーションの作成

- SOAプロジェクト・テンプレートのコンテンツのカスタマイズ

- インラインBPELサブプロセスでの注文ステータスの更新

- コンポジット・センサーを使用した注文番号の追跡

- 支払認可後の注文ステータスの更新

- デプロイとテスト

- ProcessOrderコンポジットの登録

- パイプライン・テンプレートのテスト

4.2.1 SOAプロジェクト・テンプレートからのSOAコンポジット・アプリケーションの作成

「XSLT変換を使用した支払ステータスの計算」で説明しているように、テンプレートによって、既存のコンポジット、サービス・コンポーネントおよびカスタム・アクティビティを再利用できます。会社Xでは、新規の注文書の受入れと承認、および注文履行システムへの転送を処理するSOAコンポジット・アプリケーションを設計するためのビジネス要件が頻繁に発生します。このため、これらの機能(必要に応じて、Oracle JDeveloperで複数のアプリケーションにインポート可能)を持つProcessOrderTemplateというプロジェクト・テンプレートを作成しています。テンプレートは、特定のプロジェクトのビジネス要件に合せてカスタマイズできます。その特定のインポート済テンプレートに対して行った変更は、以前にそのテンプレートを使用して作成したプロジェクトには伝播されません。

ProcessOrderTemplateプロジェクト・テンプレートは、「ツール」→「プリファレンス」→「SOA」→「テンプレート」を選択して、テンプレート記憶域の場所を指定することにより、Oracle JDeveloperで登録されます。テンプレートはJARファイルとして提供されます。これにより、テンプレートが、Oracle JDeveloperでの選択用に表示されます。

プロジェクト・テンプレートは多数の事前定義済コンポーネントで構成されており、次の機能があります。

- SOAP Webサービスから注文を受信します。

- 注文番号を作成し、注文日を現在の日付に設定して、注文ステータスを「新規」の値に設定します。

- 注文合計額を計算します。

- データベース内の注文を「新規」のステータス値で保存します。

- クライアントに注目確認と注文番号を返します。

会社Xは、新しいSOAプロジェクトを作成する、「SOAプロジェクトの作成」ウィザードを起動します。ウィザードの実行中に、テンプレートに基づいたプロジェクトを作成することを選択します。「SOAプロジェクトの作成」ウィザードの「SOAテンプレート」を選択すると(ダイアログが更新されて選択可能な既存のテンプレートが表示される)、このプロジェクト・テンプレートが新規アプリケーションにインポートされます。「ProcessOrderTemplate」が選択され、プロジェクト名は「ProcessOrder」に短縮されます。図4-2に詳細を示します。

図4-2 「SOAプロジェクトの作成」ダイアログのSOAコンポジット・テンプレートの選択

インポート後、プロジェクトとその事前定義済コンポーネントは図4-3のようになります。

- receiveOrder_clientサービスは、顧客から注文を受信します。

- receiveOrder BPELプロセス・サービス・コンポーネントは、注文番号(クライアントに返される)および注文日を設定し、validateAndProcessOrder BPELプロセス・サービス・コンポーネントをコールします。

- validateAndProcessOrder BPELプロセス・サービス・コンポーネントは、注文を変数に割り当て、支払の検証に使用される注文合計額を計算します。また、注文の検証と処理の一環として、3つのパートナ・リンクを起動します。

- writeOrderToFileファイル・アダプタ参照は、ファイル・アダプタを使用して、ファイルに注文を書き込みます。

- writeOrderToDatabase参照は、データベース・アダプタを使用して、データベースに注文を書き込みます。

- updateOrderStatus参照は、返された値に応じて、データベース内の注文ステータスを拒否または認可に更新します。

図4-3 SOAコンポジット・アプリケーションのインポート済テンプレート

4.2.2 SOAプロジェクト・テンプレートのコンテンツのカスタマイズ

テンプレートのvalidateAndProcessOrder BPELプロセスは、注文を変数に割り当て、支払の検証に使用される注文合計額を計算します。図4-4に示すプロセスのアクティビティは、次のタスクを実行します。

- XSLT変換アクティビティは、注文合計額を計算します。

- assignアクティビティが、注文合計額を注文メッセージに追加します。

- scopeアクティビティ(閉じた状態にある)には、データベースやファイル内の注文ステータスの更新に関与するすべてのアクティビティが含まれています。

図4-4 validateAndProcessOrder BPELプロセスの主要なアクティビティ

- 支払が拒否された場合、注文がキャンセルされ、データベースの注文ステータスが更新されます。

- 支払が認可された場合、データベースとファイルの注文ステータスが更新され、注文が処理されます。処理が完了すると、ステータスが「ReadyForShip」に更新されます。

注文処理は、最初の検証を終えた支払に対してのみ実行されます。ProcessOrderコンポジットには、この機能は含まれません。ただし、会社Xは、「クレジット検証システムの作成」でvalidatePaymentコンポジットを作成しています。会社Xは、インポートしたコンポジット・テンプレートをカスタマイズし、validatePaymentコンポジットを起動して支払を検証します。支払が認可されると、ProcessOrderコンポジットが注文を処理します。インポート済テンプレートに対するこのカスタマイズは、このテンプレートの他のプロジェクトのユーザーには伝播されません。

会社Xは、SOAP Webサービスを「外部参照」スイムレーンにドラッグし、「Webサービスの作成」ダイアログを起動して、ProcessOrderコンポジットをカスタマイズします。このダイアログから、Oracle SOA Suiteを使用して、Oracle JDeveloperの統合サーバーまたはリモート・アプリケーション・サーバー上のOracle SOA SuiteまたはOracle Service Busプロジェクトにデプロイされているサービスを参照できます。次のものを参照できます。

- WSDL URLの選択。

- ファイル・システム、Oracle Metadata Servicesリポジトリ(MDSリポジトリ)、UDDIレジストリまたはWeb Services Inspection Language (WSIL)ファイルからのWSDLの読取り。

validatePaymentのOracle Service Busプロキシ・サービスは、「WSDL URL」フィールドの右側にあるアイコンをクリックして選択されます。このアイコンを選択すると、サービスを参照できます。「SOAコンポジット・アプリケーションの登録」で作成したValidatePSプロキシ・サービスが選択されます(図4-5を参照)。

図4-5 「WSDLの選択」ダイアログのValidatePSプロキシの選択

新規Webサービス(validatePaymentService)は、「SOAコンポジット・アプリケーションの登録」で定義したvalidatePaymentプロキシ・サービスを起動します。ポート・タイプは自動的に追加されます。図4-6に詳細を示します。

図4-6 validatePaymentプロキシのWSDLファイルのコール

validateAndProcessOrder BPELプロセスは、SOAコンポジット・エディタの新しいvalidatePaymentService SOAP Webサービスにワイヤリングされます(図4-7を参照)。

図4-7 validatePaymentService SOAP Webサービスの起動

会社Xは、次のものを追加して、validateAndProcessOrder BPELプロセスをさらにカスタマイズします。

- validatePaymentServiceパートナ・リンクを起動するinvokeアクティビティ(validatePayment)

- validatePayment invokeアクティビティの前のassignアクティビティ(Webサービス・コールの入力変数に正しい値を割り当てる)

- invokeアクティビティの後のassignアクティビティ(Webサービス・コールから注文メッセージへの支払ステータスのリプライを割り当てる)図4-8に詳細を示します。

図4-8 コンポジット・テンプレートのvalidateAndProcessOrder BPELプロセスへのカスタマイズ

図4-9に、完了したコンポジットを示します。

図4-9 完了したコンポジット

4.2.3 インラインBPELサブプロセスでの注文ステータスの更新

会社Xには、同じBPELプロセスで少なくとももう一度、validateAndProcessOrder BPELプロセスの注文ステータス更新部分を使用する要件があります。1つの方法は、すでに使用しているのと同じassignアクティビティとinvokeアクティビティを作成することです。ただし、これは間違いやすいプロセスで、変更が必要なたびに、すべての場所でそれを反映する必要があります。これを回避するために、会社Xでは、BPELサブプロセスを使用します。このロールには2つのタイプがあります。

- スタンドアロン: 再使用されるアクティビティが多数含まれるBPELプロセスのフラグメント。スタンドアロン・サブプロセスにはインタフェースがなく、別のBPELプロセスからのみコールされます。スタンドアロン・プロセスは、他の複数のBPELプロセスへのパートナ・リンクを持つことができます。

- インライン: 単一BPELプロセス内で再使用されるアクティビティ・グループ用。インライン・プロセスは親BPELプロセス・コードの一部であるため、コンポジット・ビューには表示されません。インライン・サブプロセスでは、callアクティビティを使用します。
インライン・サブプロセスは、会社Xのビジネス要件に適しています。

validateAndProcessOrder BPELプロセス内で、updateOrderStatusScopeという注文ステータスの更新を担当するscopeアクティビティを右クリックし、「サブプロセスに変換」を選択します。これにより、「インライン・サブプロセスの作成」ダイアログが起動します。会社Xは、サブプロセスの名前を変更し、scopeアクティビティをサブプロセスのcallアクティビティに自動的に置き換えることを選択します。図4-10に詳細を示します。

図4-10 インライン・サブプロセスの作成

これにより、scopeアクティビティがcallアクティビティに変換されます。callアクティビティは、スタンドアロン・サブプロセスおよびインライン・サブプロセスで参照サブプロセス・コードを実行します。また、callアクティビティは、「コンポーネント」ウィンドウの「サブプロセス」部分に追加されます。このcallアクティビティは、必要に応じてBPELプロセスの他の場所にドラッグ・アンド・ドロップできます。図4-11に詳細を示します。

図4-11 BPELプロセスおよび「コンポーネント」ウィンドウのcallアクティビティ

4.2.4 コンポジット・センサーを使用した注文番号の追跡

「コンポジット・センサーを使用した支払ステータスの追跡」で、会社Xは、注文支払のステータスを追跡するためのコンポジット・センサーを追加しました。

ここでは、コンポジット・センサーで注文番号を追跡するという追加要件があります。インポート済コンポジット・テンプレートに含まれているSOAP Webサービスreceiveorder_client (図4-3を参照)は、注文確認メッセージでorderNumberを返します。会社Xは、図4-12の「コンポジット・センサーの作成」ダイアログに示されているように、注文番号を追跡するために、このサービス(XPath式を含む)でコンポジット・センサーを定義します。

図4-12 コンポジット・センサーで定義されている式

「コンポジット・センサーの作成」ダイアログの「Enterprise Manager」チェック・ボックスも選択されます(図4-13を参照)。これにより、Oracle Enterprise Manager Fusion Middleware Controlの特定のビジネス・フロー・インスタンスで、「フロー・インスタンス」ページまたは「フローのトレース」ページのコンポジット・センサーの名前と値(たとえば、OrderNumber=1234)を追跡できるようになります。Oracle Enterprise Manager Fusion Middleware ControlはWebブラウザ・ベースのグラフィカル・ユーザー・インタフェースで、デプロイ済コンポジットをモニターおよび管理するために使用します。

図4-13 コンポジット・センサーの「Enterprise Manager」チェック・ボックス

コンポジット・センサーの定義は、receiveorder_client SOAP Webサービス・バインディング・コンポーネント上のアイコンにカーソルを置くことにより表示されます。図4-14に詳細を示します。

図4-14 コンポジット・センサーの定義

4.2.5 支払認可後の注文ステータスの更新

支払が有効な場合は、注文ステータスがデータベースで「ReadyForShip」に設定されます。このステータスの更新は、「注文の履行」で説明する注文履行プロセスをトリガーします。

会社Xは、ifアクティビティを追加して、validateAndProcessOrder BPELプロセスをさらにカスタマイズします。ifアクティビティは、2つ以上のブランチのどちらを実行するかを決定するための特定のアクティビティ条件動作を定義します。ブランチのセットから、実行するアクティビティが1つだけ選択されます。このビジネス・シナリオのifアクティビティは、次のブランチで構成されます。

- 支払が認可された場合、注文が続行されます。ifブランチのassignアクティビティは、注文ステータスをデータベース内で「ReadyForShip」に更新します。

- 支払が拒否された場合、処理が終了し、未認可の支払に関して通知する電子メールが顧客に送信されます。

図4-15に詳細を示します。ifアクティビティが、「インラインBPELサブプロセスでの注文ステータスの更新」で作成したupdateOrderStatusSP callアクティビティの下に追加されます。

図4-15 ifアクティビティ

支払が認可された場合、式がifブランチで定義されます(図4-16を参照)。

図4-16 ifブランチでの支払の認可

支払が認可されると、注文処理が完了します。assignアクティビティがifブランチに追加され、注文ステータスがデータベース内で「ReadyForShip」に更新されます。図4-17に、assignアクティビティのコピー・ルールのコンテンツを示します。

図4-17 assignアクティビティ

図4-18に、assignアクティビティのコピー・ルールにおけるXPath式のコンテンツを示します。

図4-18 ReadyForShip式

支払が拒否された場合は注文処理が停止するため、elseブランチは不要で削除されます。

4.2.6 Oracle Enterprise Manager Fusion Middleware Controlでのデプロイとテスト

会社Xは、プロジェクトのビジネス・フロー・インスタンスをデプロイおよび作成します。Oracle Enterprise Manager Fusion Middleware Controlの「フローのトレース」ページに、2つのコンポジット・センサーの名前と値が表示されます。支払が認可されたので、プロジェクトは注文履行システムに送信されます。図4-19に詳細を示します。

図4-19 「フローのトレース」ページのコンポジット・センサーの名前と値

監査証跡は、注文が認可および「ReadyForShip」とマークされていることを示します。図4-20に詳細を示します。

図4-20 ビジネス・フロー・インスタンスのフロー

4.2.7 Oracle Service BusでのProcessOrderコンポジットの登録

「クレジット検証システムの作成」のvalidatePaymentコンポジットと同様に、会社Xは、Oracle Service Busを使用して、ProcessOrderコンポジットを登録し、外部顧客が利用できるようにします。

Oracle Service Busは、ProcessOrderコンポジットのコア・ビジネス・ロジックを中断させることなく、異なるプロトコルやデータ・フォーマットでこのコンポジットを使用できるようにします。また、Oracle Service Busは、注文データの検証と監査も実行します。

会社Xは、追加のプロジェクトを含めるように、「SOAコンポジット・アプリケーションの登録」で作成したOracle Service Busアプリケーションを更新します。これらのプロジェクトでは、パイプライン・テンプレートを使用します。

パイプライン・テンプレートは、プロキシ・サービスのプロトタイプ・メッセージ・フローの設計に使用されます。パイプライン・テンプレートによって、メッセージ・フローの一般的な形状またはパターンが定義されます。その後、パイプライン・テンプレートから具象パイプラインを生成できます。すべての具象パイプラインは、カスタム・ロジックを挿入可能な場所が指定されているパイプライン・テンプレートによって定義されるメッセージ・フローを使用します。

会社Xは、Oracle Service Busアプリケーションを右クリックし、「インポート」→「Service Busリソース」を選択して、テンプレートをインポートします。図4-21に詳細を示します。

図4-21 Oracle Service Busリソースの選択

これにより、使用するパイプライン・テンプレートを選択するための「Service Busリソースのインポート」ダイアログが起動します。完了後、インポート済テンプレートは「アプリケーション」ウィンドウに表示されます(図4-22を参照)。

図4-22 「アプリケーション」ウィンドウのインポート済Oracle Service Busパイプライン・テンプレート

4.2.7.1 ビジネス・サービスとしてのProcessOrderコンポジットの登録

会社Xは、「外部参照」列を右クリックし、「トランスポートの挿入」→「HTTP」を選択して、コンポジットをビジネス・サービスとして登録します(図4-23を参照)。

図4-23 ビジネス・サービスの作成

このアクションにより、「ビジネス・サービスの作成」ウィザードが起動します。ここで、次のものを設定します。

- トランスポート・タイプとしてのHTTP。

- サービス・タイプとしてのProcessOrderの具象的なWSDL。

- WSDLファイル

- エンドポイントURIとしてのコンポジット。Oracle Service Busでは、アプリケーションのロード・バランシングやフェイルオーバーをサポートするために、ビジネス・サービスで複数のエンドポイントを持つこともできます。

4.2.7.2 パイプライン・テンプレートを使用したプロキシでの新規パイプラインの作成

会社Xは、「コンポーネント」ウィンドウからOracle JDeveloperの「コンポーネント」セクションに「パイプライン」アイコンをドラッグして、パイプライン・テンプレート(SharedSB)を作成します(図4-24を参照)。

図4-24 パイプライン・テンプレート

これにより、使用するインポート済パイプライン・テンプレートを選択するための「パイプライン・サービスの作成」ダイアログが起動します。構成中に、WSDLベース・サービス用のテンプレート、パイプラインに使用する特定のWSDL(図4-25を参照)を選択し、そのパイプラインをプロキシ・サービスとして公開します。

図4-25 「WSDLの選択」ダイアログ

構成の完了後、「パイプライン・サービスの作成」ダイアログは図4-26のようになります。

図4-26 完了した「パイプライン・サービスの作成」ダイアログ

パイプラインがアプリケーションに表示されます(図4-27を参照)。パイプラインの黄色のアイコンは、完全に実装される前に、追加の構成が必要であることを示しています。

図4-27 アプリケーションのパイプライン

「ProcessPP」をダブルクリックすると、ProcessPPが編集用に表示されます。ここには、いくつかの機能(たとえば、データ検証、ルーティング、レポーティング、エラー状態のアラート、エラー処理)が部分的に構成された状態で含まれています。赤色のフラグは、追加の構成が必要な領域を示しています。「リクエストのステージ」メッセージは、パイプラインにおいてプレースホルダ情報が提供されている領域を示しています。ここで、会社Xは(変換やメッセージ・エンリッチメントなどの)カスタマイズを行えます。図4-28に詳細を示します。

図4-28 事前構成されたパイプライン・テンプレート

テンプレートでは、パイプラインのエラー・ハンドラを定義することもできます(図4-29を参照)。事前定義されたエラー・ハンドラは、エラーとその詳細情報をコール元に返し、この処理でなんらかの不具合が発生していることを示すアラートをOracle Enterprise Manager Fusion Middleware Controlに送信します。

図4-29 パイプライン・テンプレートのエラー処理

会社Xは、データ検証ステージを開いて、「検証」アクションを選択することでデータ検証を構成します。この部分で、ProcessOrderコンポジットで予期されるOrderスキーマ・エレメント・タイプに対して受信ペイロードを検証できます。Oracle Service Busでの検証によって、バック・エンド(正常な注文の処理が行われる)にリソースが保存されます。会社Xでは、他のすべての詳細は事前構成されているため、検証の基準となるOrderタイプのみを選択する必要があります。

会社Xは、コンポジットから返される注文番号(図4-30を参照)をレポートするように、図4-28に示したレスポンス・フローの「監査」ステージの「レポート」アクションを構成します。テンプレートでは、エラーに備えて受信注文のコピーがすでに保存されているため、それをOracle Enterprise Manager Fusion Middleware Controlにレポートします。

図4-30 OrderNumberの選択

また、会社Xは、図4-28のテンプレートの「ルーティング」アイコンをダブルクリックし、プロパティ・インスペクタの「ルーティング」タブを選択して、「ProcessBS」ビジネス・サービスを選択することにより、ルーティング・ノードも構成します。図4-31に詳細を示します。

図4-31 ビジネス・サービスの選択

構成の完了後、Oracle Service Busアプリケーションは図4-32のようになります。

図4-32 Oracle Service Busアプリケーション

4.2.8 パイプライン・テンプレートのテスト

会社Xは、左スイムレーンの「ProcessPS」サービスを右クリックし、「実行」を選択してテストします(図4-33を参照)。テスト・フェーズ中には、正常な注文と不正な注文が送信されます。

図4-33 パイプライン・テンプレートのテスト

4.3 関連ドキュメント

表4-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。

表4-2 関連ドキュメント

参照内容

参照先

SOAコンポジット・アプリケーションの作成

『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOAアプリケーションの作成に関する項

コンポジット・テンプレートとインライン・サブプロセスの作成と使用

『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle SOA Suiteテンプレートおよび再使用可能なサブプロセスに関する項

コンポジット・センサーの作成

『Oracle SOA SuiteでのSOAアプリケーションの開発』のコンポジット・センサーの定義に関する項

Oracle Service Busでのビジネス・サービスの作成

ビジネス・サービスの作成と構成に関する項

パイプライン・テンプレートの使用

『Oracle Service Busでのサービスの開発』のパイプライン・テンプレートの使用に関する項

5 Oracle Service Busでの新規注文チャネルの追加

この章では、Oracle SOA Suiteで新規注文チャネルの追加というビジネス課題に対処する方法について説明します。Oracle Service Busのファイルベースのプロキシ、ネイティブ・フォーマット・ビルダー・ウィザード、Oracle Enterprise Manager Fusion Middleware Control、Oracle Service Busデバッガなどの主要なコンポーネントを使用して、この課題に対処する方法の概要を示します。

この章の内容は次のとおりです。

- ビジネス課題

- ビジネス・ソリューション

- 関連ドキュメント

5.1 ビジネス課題

会社Xには、バック・エンド・アプリケーションに影響を及ぼすことなく、レガシー・システムで通常の区切り形式で発注するという要件があります。「注文処理システムの作成」で設計したProcessOrderコンポジットのバック・エンド・ビジネス・ロジックの中断を最小化するために、プロトコルおよびデータ変換が提供される必要があります。

5.2 ビジネス・ソリューション

これらのビジネス課題に対処するために、会社Xは表5-1のコンポーネントを使用するビジネス・ソリューションを設計します。

表5-1 ビジネス・ソリューションを提供するコンポーネント

コンポーネント

このコンポーネントがビジネス課題に対処する方法

コンポーネントの説明

Oracle Service Busファイルベース・プロキシ

Oracle Service Busパイプラインは、プロキシ・サービスをファイル注文チャネルに接続します。プロキシは、受信された顧客注文をファイルごとに処理します。

パイプラインは、起動前のアプリケーションを検証します。プロキシにより、顧客はコンポジットに直接接続するかわりに、プロキシを介してコンポジットを起動できます。

ネイティブ・フォーマット・ビルダー・ウィザード

ファイル・アダプタは、注文処理コンポジットで使用するために、カンマ区切りの注文をXMLスキーマ・ファイルに変換します。

ネイティブ・フォーマット・ビルダー・ウィザードにより、区切り、固定長、複合タイプ、データ型記述(DTD)、COBOLコピーブックなどの様々なファイル形式からネイティブ・スキーマ・ファイルを作成できます。

Oracle Service Busデバッガ

Oracle Service Busパイプラインに設定されるブレークポイント・デバッガは、エンドツーエンド・アプリケーションをテストおよびデバッグします。

Oracle Service Busデバッガでは、パイプラインおよび分割-結合をトラブルシューティングするために、Oracle JDeveloper内で直接ブレークポイントを設定できます。

Oracle Enterprise Manager Fusion Middleware Control。

Oracle Enterprise Managerにより、Oracle Service Busアプリケーションをモニターおよび管理できます。

Oracle Enterprise Manager Fusion Middleware Controlは、デプロイ済アプリケーションをモニターおよび管理するためのWebブラウザ・ベースのグラフィカル・ユーザー・インタフェースを提供します。

図5-1に、このビジネス・ソリューションの実装方法の概要を示します。

図5-1 注文チャネル

この章の後続の項では、表5-1のコンポーネントを使用して、新規注文チャネルのビジネス課題に対処する方法について、より詳細に説明します。

- パイプラインへのファイルベース・プロキシの追加

- デバッガによるコンポーネントのデバッグ

- モニタリング

5.2.1 Oracle Service Busパイプラインへのファイルベース・プロキシの追加

会社Xの顧客ベースには、XML形式で注文を発行できないレガシーな会社が含まれます。この場合、かわりにカンマ区切り形式を使用します。会社Xは、これらのカンマ区切りの注文を有効なXML形式に変換できる必要があります。

Oracle SOA Suiteには、アダプタ構成ウィザードが含まれており、アプリケーションをファイル・システム、データベース表、データベース・キュー、FTPサーバー、Java Message Services (JMS)、IBM WebSphere MQおよび他のシステムと統合できます。12c,では、アダプタ構成ウィザードを、Oracle SOA SuiteとOracle Service Busの両方で使用できます。

会社Xは、Oracle JDeveloperの「アプリケーション」ウィンドウのOracle Service Busアプリケーションで「ProcessOrder」プロジェクトを開きます。図5-2に詳細を示します。

図5-2 「コンポーネント」ウィンドウのファイル・アダプタ・アイコン

会社Xは、「コンポーネント」ウィンドウから「公開されたサービス」スイムレーンに「ファイル」アイコンをドラッグします。これにより、ProcessOrderコンポジットの新規ファイルベース・プロキシを追加するためのアダプタ構成ウィザードが起動します。

ファイル・アダプタにより、ローカル・ファイル・システム上で、Oracle Service Busのビジネス・サービスとプロキシ・サービスが交換(読取りおよび書込み)可能になります。ファイル・コンテンツは、XMLデータ・フォーマットと非XMLデータ・フォーマットのどちらでも構いません。このシナリオでは、ファイル・アダプタは、毎分ポーリングされる指定のディレクトリからカンマ区切り値(.csv)ファイルを読み取るように構成されます。ウィザードの最後のページで、会社Xは、顧客が提出したネイティブのカンマ区切り形式から有効なXMLスキーマ・ファイルを作成するオプションを選択します。これを選択すると、ネイティブ・フォーマット・ビルダー・ウィザードが起動します。図5-3に詳細を示します。

ネイティブ・フォーマット・ビルダー・ウィザードにより、区切り、固定長、複合タイプ、データ型記述(DTD)、COBOLコピーブックなどの様々なファイル形式からネイティブ・スキーマ・ファイルを作成できます。ネイティブ・スキーマは注釈と追加属性付きのXMLスキーマ定義であり、これを使用してネイティブ・フォーマット・ファイルをXMLに変換できます(逆も同様)。このネイティブ・スキーマにより、アダプタ構成ウィザードで、アダプタがアプリケーションと通信するためのWSDLファイルを作成できます。

図5-3 ネイティブ形式のスキーマを定義するオプションの選択

このシナリオでは、次のようにネイティブ・フォーマット・ビルダー・ウィザードを構成します。

- スキーマを作成するネイティブ・メッセージ形式として、「複合タイプ」(フィールドそのものがレコードで複数のデリミタ・タイプを持つ可能性があるレコードが含まれています)を選択します。

- ネイティブ・フォーマット・ファイルとルート要素(Order)を指定します。

- 住所、請求、出荷およびアイテムに対応するデータの複合タイプを指定します。

- データのデリミタ(カンマ)を指定します。

- データ・ファイルのフィールドに対応するスキーマ要素を指定します。

- 自動生成される要素C1,C2.....C7の名前を、生成されるXMLファイルで予期される要素名に変更します。

図5-4に、FirstName、LastName、AddressLine、City、State、ZipCodeおよびPhoneNumberの定義されたスキーマ要素を持つ複合タイプAddressTypeを示します。カンマ区切りファイルは、ページの右側に表示されます。

図5-4 スキーマ・ファイルの複合タイプの設計

図5-5に示すように、構成プロセスはすべての必要な複合タイプに対して繰り返されます。

図5-5 スキーマ・ファイルの複合タイプの設計の完了

完了すると、スキーマ・ファイルが作成されます。図5-6に詳細を示します。

図5-6 スキーマ・ファイルとスキーマ要素の作成

会社Xは、新規作成されたProcessPS_FileプロキシをProcessPPパイプラインにワイヤリングします。図5-7に詳細を示します。

図5-7 ProcessPPパイプラインにワイヤリングされたファイル・プロキシ

5.2.2 Oracle Service Busデバッガによるコンポーネントのデバッグ

Oracle JDeveloperは、Oracle Service Busプロジェクト・コンポーネントを評価し、修復するための包括的なデバッガを提供します。デバッガは、Oracle JDeveloper内に直接トラブルシューティング環境を提供することにより、開発サイクルを短縮します。つまり、Oracle JDeveloperでOracle Service Busアプリケーションを構築して実行したり、コンソールを起動して監査証跡とフロー・トレースをテストまたは表示したり、Oracle JDeveloperに戻って問題を修正したり、これらの手順を繰り返す必要はありません。かわりに、パイプラインと分割-結合をトラブルシューティングするためのブレークポイントをOracle JDeveloper内で直接設定できます。

会社Xは、validatePaymentパイプラインに移動して、Oracle JDeveloperでパイプラインをデバッグします。パイプライン・エディタで「レポート」アクションを選択し、メニューから「ブレークポイントの切替え」を選択します。

図5-8に詳細を示します。

図5-8 ブレークポイントの設定

ブレークポイントを設定した後、会社Xはプロキシを右クリックし、「実行」を選択してデバッガを起動します。図5-9に詳細を示します。

図5-9 Oracle Service Busプロキシのデバッグの開始

これにより、テスト・コンソールへのサンプル・データの入力、変数の確認、デバッグ・モードでのパイプラインのステップ実行、および必要に応じたデータ変更が可能になります。図5-10に詳細を示します。

図5-10 Oracle Service Busパイプラインのデバッグ

5.2.3 Oracle Enterprise Manager Fusion Middleware ControlでのOracle Service Busのモニタリング

会社Xは、Oracle Service Busアプリケーションをデプロイします(図5-11を参照)。

図5-11 Oracle Service Busアプリケーションのデプロイメント

会社Xは、Oracle Enterprise Manager Fusion Middleware ControlからOracle Service Busをモニターします。Oracle Enterprise Manager Fusion Middleware ControlはWebブラウザ・ベースのグラフィカル・ユーザー・インタフェースで、デプロイ済コンポジットをモニターおよび管理するために使用します。

12c,以降、Oracle Service BusとOracle SOA Suiteの管理は、単一の統合されたOracle Enterprise Manager Fusion Middleware Controlから実行されます。

パフォーマンスを最適化するため、サービスはデフォルトでは表示されません。したがって、会社Xは、ナビゲータで「ProcessOrderSB」を選択し、「操作」タブをクリックしてから「検索」をクリックし、ProcessOrderSBのすべてのサービスを表示します。図5-12に詳細を示します。

図5-12 ProcessOrderSBの検索

「タイプ」リストでは、詳細の表示をフィルタリングできます(図5-13を参照)。

図5-13 詳細のフィルタ表示

会社Xは、Oracle Service Busホーム・ページを使用して、ページの上部に表示される各タブの下にある追加の詳細をモニターします。図5-14に、「グローバル設定」タブの詳細を示します。

図5-14 Oracle Service Busホーム・ページ

5.3 関連ドキュメント

表5-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。

表5-2 関連ドキュメント

参照内容

参照先

アダプタ構成ウィザードでのファイル・アダプタの構成

『テクノロジ・アダプタの理解』のOracle JCA Adapters for Files/FTPに関する項

ネイティブ・フォーマット・ビルダー・ウィザードを使用したネイティブ・スキーマ・ファイルの作成

『テクノロジ・アダプタの理解』のネイティブ・フォーマット・ビルダー・ウィザードに関する項

Oracle Enterprise Manager Fusion Middleware ControlでのOracle Service Busのモニタリング

『Oracle Service Busの管理』のOracle Service Bus管理のスタート・ガイドに関する項

Oracle JDeveloperでのOracle Service Busアプリケーションのデバッグ

『Oracle Service Busでのサービスの開発』のOracle Service Busアプリケーションのデバッグに関する項

6 注文の梱包と出荷

この章では、Oracle SOA Suiteで注文の梱包および出荷というビジネス課題に対処する方法について説明します。RESTサービス、BPELプロセス、HTTPアナライザ、BPELプロセス・コンポーネント・テンプレート、スタンドアロンBPELサブプロセス、コンポジット・センサー、Oracle User Messaging Serviceアダプタなどの主要なSOAコンポジット・アプリケーション・コンポーネントを使用して、この課題に対処する方法の概要を示します。

この章の内容は次のとおりです。

- ビジネス課題

- ビジネス・ソリューション

- 関連ドキュメント

6.1 ビジネス課題

会社Xには、優先出荷プロバイダを特定の出荷方法に割り当てる要件があります。この方法は、顧客が発注したときに選択した出荷速度と出荷先(住所の州)に基づいて計算されます。注文が出荷されると、顧客に出荷プロバイダの確定通知が送信される必要があります。注文ステータスも、出荷済に更新される必要があります。

6.2 ビジネス・ソリューション

このビジネス課題に対処するために、会社Xは表6-1のコンポーネントを使用するビジネス・ソリューションを設計します。

表6-1 ビジネス・ソリューションを提供するコンポーネント

コンポーネント

このコンポーネントがビジネス課題に対処する方法

コンポーネントの説明

RESTサービス

インバウンドRESTアダプタ・サービスは、出荷リソースを定義します。

RESTは、ネットワーク・アプリケーションの設計用のアーキテクチャです。RESTfulアプリケーションは、HTTPリクエストを使用してデータのポスト(作成と更新)、データの取得(たとえば問合せの作成)、データの更新およびデータの削除を実行します。

BPELプロセス

BPELプロセスは注文のステータスを出荷済に設定し、注文が出荷されたことを顧客に通知して、データベース内の注文ステータスを更新します。このプロセスは、RESTインタフェースに接続され、サービスとして公開されます。

BPELプロセスにより、プロセス・オーケストレーションおよび同期または非同期プロセスの保存ができます。一連のビジネス・アクティビティとサービスをエンドツーエンドのプロセス・フローに統合するビジネス・プロセスを設計します。

HTTPアナライザ

HTTPアナライザは、RESTサービスのWeb Application Description Language (WADL) URLをテストし、サービスが正しく機能していることを確認します。

HTTPアナライザを使用して、HTTPリクエスト/レスポンス・パッケージ・ペアのコンテンツを検査できます。リクエスト・パッケージの内容を編集して再送信し、戻されるレスポンス・パケットを確認できます。

BPELプロセス・コンポーネント・テンプレート

コンポーネント・テンプレートにはinvokeアクティビティと、注文番号と注文ステータスを取得し、それをデータベース・アダプタの入力変数に割り当てるassignアクティビティが含まれます。

Oracle SOA Suiteテンプレートの詳細は、表3-1を参照してください。

スタンドアロンBPELサブプロセス

スタンドアロンBPELプロセスは、データベース・アダプタ参照をコールして、注文ステータスを更新します。

スタンドアロンBPELサブプロセスは、再使用されるアクティビティが多数含まれるBPELプロセスのプラグメントです。スタンドアロン・サブプロセスにはインタフェースがなく、別のBPELプロセスからのみコールされます。

コンポジット・センサー

コンポジット・センサーは特定の出荷プロバイダのすべての注文を追跡します。

コンポジット・センサーの詳細は、表3-1を参照してください。

Oracle Enterprise Manager Fusion Middleware Control。

Oracle Enterprise Manager Fusion Middleware Controlは、インスタンス内のコンポジット・センサーをモニターし、テスト用に使用されるWADL URLへのアクセスを提供します。

Oracle Enterprise Manager Fusion Middleware ControlはWebブラウザ・ベースのグラフィカル・ユーザー・インタフェースで、デプロイ済コンポジットをモニターおよび管理するために使用します。

Oracle User Messaging Service (UMS)アダプタ

UMSアダプタは、注文が出荷されたことを示す電子メール通知を顧客に送信します。

UMSは、ユーザーとアプリケーション間の通信を可能にするOracle Fusion Middlewareコンポーネントです。UMSでは、電子メール、SMS、インスタント・メッセージ、ボイスなどの様々なメッセージング・チャネルがサポートされます。UMSは、サーバー、ドライバおよびアプリケーションで構成されます。

図6-1に、このビジネス・ソリューションの実装方法の概要を示します。

図6-1 梱包および出荷プロセスの概要

この章の後続の項では、表6-1のコンポーネントを使用して、梱包および出荷のビジネス課題に対処する方法について、より詳細に説明します。

- RESTサービスを使用した出荷リソースの定義

- 梱包BPELプロセスを使用したRESTサービスの公開

- HTTPアナライザを使用したRESTサービスのテスト

- データベース内の注文ステータスを更新するためのテンプレートおよびスタンドアロン・サブプロセスの使用

- コンポジット・センサーを使用した出荷プロバイダの追跡

- 注文の出荷を示す電子メール通知の送信

6.2.1 RESTサービスを使用した出荷リソースの定義

会社Xは、このビジネス課題に対処するため、PackAndShipServiceという名前のSOAコンポジット・アプリケーションを作成します。Webサービスを使用するかわりに、会社XはコンポジットのRESTサービスを使用して、出荷リソースを定義します。

RESTは、ネットワーク・アプリケーションの設計用のアーキテクチャです。RESTfulアプリケーションは、HTTPリクエストを使用してデータのポスト(作成と更新)、データの取得(たとえば問合せの作成)、データの更新およびデータの削除を実行します。

Oracle SOA Suiteでは次のRESTサポートを提供します。

- SOAコンポジット・アプリケーションでのサポート:

- 新規または既存のサービスでのRESTサポートの有効化。

- 外部REST APIとの統合。

- RESTful状態遷移セットの編成 (RPC/HATEOAS (Hypermedia as the Engine of Application State)アプローチ)。

- XML、JavaScript Object Notation (JSON) (XMLへおよびXMLからの自動翻訳を含む)、URIサンプルおよびURLエンコードGET/POSTデータのサポート。

- RESTサービス操作用のサンプルURIの生成。

- WADLサービスのサポート。WADLは、デプロイ済のOracle SOA SuiteまたはOracle Service Busサービス、あるいはJersey RESTサービスなど、Oracle SOA SuiteまたはOracle Service Bus以外のサービスでも提供できます。

- 開発の容易さ:

- Oracle JDeveloperにより、RESTインタフェースとWSDL操作バインディングをモデル化するためのウィザードを提供。

- デプロイメント時に使用する各メソッドを公開する読取り可能APIを提供。

- Oracle JDeveloperからOracle RESTエンドポイント(Oracle Service Busなど)をブラウズおよび消費可能。

- Oracle Web Service Manager (OWSM)ポリシーのRESTセキュリティのサポート。

会社Xは、「コンポーネント」ウィンドウからOracle JDeveloperの「公開されたサービス」スイムレーンにRESTバインディング・アダプタをドラッグします。梱包サービスは、注文の梱包および出荷に必要なすべての情報を含む出荷リソースがあることを前提としています。また、このサービスは、更新された注文ステータスが設定された出荷リソースを返します。

会社Xは、次のRESTサービスの詳細を定義します。

- RESTインバウンド・インタフェースの作成。

- shippingRESTリソースの作成。

- 次のものが設定されたpackandShip操作バインディングの作成。

- POST HTTP動詞。

- サンプル・リクエストXMLペイロード(図6-2を参照)。

図6-2 サンプルXMLペイロード

- 「SOAプロジェクト・テンプレートからのSOAコンポジット・アプリケーションの作成」で作成したProcessOrderプロジェクトから選択されたリクエスト・スキーマ・ファイル。このスキーマ・ファイルには、Shipping要素が含まれます(図6-3を参照)。

図6-3 スキーマ・ファイルの出荷要素

- ProcessOrderプロジェクトから選択されたレスポンス・スキーマ・ファイル。このスキーマ・ファイルは、リクエスト用に選択されるものと同じで、図6-3に示すShipping要素も含まれています。

設計の完了後、「RESTバインディングの作成」ダイアログは図6-4のようになります。

図6-4 「RESTバインディングの作成」ダイアログ - 設計の完了

これにより、「公開されたサービス」スイムレーンにRESTサービス・バインディング・コンポーネントが作成されます(図6-5を参照)。

図6-5 Oracle JDeveloperの公開されたサービス・スイムレーンのRESTサービス

6.2.2 梱包BPELプロセスを使用したRESTサービスの公開

会社Xは、RESTサービスをBPELプロセスに接続することによって公開します(図6-6を参照)。

図6-6 BPELプロセスに接続されたRESTサービス

このサービスは、「注文の履行」の注文履行サービスによって決定される、出荷プロバイダおよび出荷方法に基づいた梱包および出荷を開始します。BPELプロセスは、次のアクティビティで構成されます。

- receiveアクティビティは、RESTサービスからのコールを受信します。

- 空のアクティビティが梱包と出荷をシミュレートします。このアクティビティの処理後、注文ステータスが出荷済に更新されます。

- assignアクティビティは、注文番号とステータスを2つの変数に割り当てます:

- orderNumberは、入力変数から設定されます。

- orderStatusは、出荷済に設定されます。

- assignアクティビティは、入力変数の値(更新済ステータスを持つ)を出力変数に割り当てます。

- replyアクティビティは、RESTサービスに情報を返します。

図6-7に、BPELプロセスの完全な設計を示します。

図6-7 RESTサービスとBPELプロセスとの統合

6.2.3 HTTPアナライザを使用したRESTサービスのテスト

RESTサービスが正常に機能していることを確認するために、会社Xはまず、HTTPアナライザでテストするためのSOAコンポジット・アプリケーションをデプロイします。

デプロイメントを実行するには、「アプリケーション」ウィンドウの「PackAndShipService」を右クリックし、「デプロイ」を選択して、「デプロイ」ウィザードの各ページを順次移動します。デプロイメントは、Oracle JDeveloperの埋込みローカル・サーバーであるIntegratedWebLogicServerに対して実行されます。

HTTPアナライザを使用して、HTTPリクエスト/レスポンス・パッケージ・ペアのコンテンツを検査できます。リクエスト・パッケージの内容を編集して再送信し、戻されるレスポンス・パケットを確認できます。

サービスをテストするには、まず、Oracle Enterprise Manager Fusion Middleware ControlのPackAndShipService SOAコンポジット・アプリケーションのホーム・ページから、WADLファイルURLをコピーします(図6-8を参照)。

Oracle SOA SuiteのRESTサービスは、WSDLファイルのかわりにWADLファイルを公開して、そのインタフェースを定義します。WADLでは、HTTPベースWebアプリケーション(一般的にはREST Webサービス)の判読可能なXML説明が用意されています。WADLにより、Webの既存HTTPアーキテクチャに基づいて、Webサービスの再利用が単純になります。

図6-8 Oracle Enterprise Manager Fusion Middleware ControlでのWADL URLの場所

会社Xは、「ツール」→「HTTPアナライザ」を選択して、Oracle JDeveloperのHTTPアナライザを開きます。「URLを開く」をクリックして、プロンプトが表示されたら、Oracle Enterprise Manager Fusion Middleware ControlからコピーしたWADL URLを入力します。図6-9に詳細を示します。

図6-9 HTTPアナライザ

図6-10の「サービス」ダイアログに、RESTサービスに関する詳細が表示されます。会社Xは、「テスト」をクリックします。

図6-10 「サービス」ダイアログ

会社Xは、図6-2で指定したサンプル・リクエストXMLペイロードを「リクエストHTTPヘッダー」セクションにコピーして貼り付け、「リクエストの送信」をクリックします(図6-11を参照)。

図6-11 HTTPアナライザへのリクエストXMLペイロードの入力

6.2.4 データベース内の注文ステータスを更新するためのテンプレートおよびスタンドアロン・サブプロセスの使用

出荷メッセージの注文ステータスを更新するほかに、会社Xはデータベース内のステータスも更新します。これは共通のタスクであるため、複数のプロジェクトで必要に応じて再使用するために、updateOrderStatusSPという名前のコンポーネント・テンプレートを作成します。会社Xは、「XSLT変換を使用した支払ステータスの計算」および「SOAプロジェクト・テンプレートのコンテンツのカスタマイズ」で同様の共通タスクのテンプレートを使用しています。

図6-12に、コンポーネント・テンプレートのコンテンツを示します。

図6-12 BPELプロセス・コンポーネント・テンプレートのコンテンツ

会社Xは、「コンポーネント」ウィンドウの「コンポーネント・テンプレート」セクションからSOAコンポジット・アプリケーションにテンプレートをドラッグします。完全に拡張した後、コンポジットは図6-13のようになります。

図6-13 拡張されたテンプレートを含むSOAコンポジット・アプリケーション

コンポーネント・テンプレートにはinvokeアクティビティと、注文番号と注文ステータスを取得し、それをデータベース・アダプタの入力変数に割り当てるassignアクティビティが含まれます。

packAndShipOrder BPELプロセスは、updateOrderStatusSPコンポーネント・テンプレートと接続する必要があります。このタスクに対処するために、会社Xは、スタンドアロンBPELプロセスを使用して、データベース・アダプタ参照をコールし、注文ステータスを更新します。サブプロセスは、複数のプロジェクトで機能の再使用を可能にするという点で、テンプレートと類似しています。スタンドアロンBPELサブプロセスは、再使用されるアクティビティが多数含まれるBPELプロセスのプラグメントです。スタンドアロン・サブプロセスにはインタフェースがないため、別のBPELプロセスからのみコールされます。スタンドアロン・プロセスは、他の複数のBPELプロセスへのパートナ・リンクを持つことができます。

会社Xは、packAndShipOrder BPELプロセスを開いて、スタンドアロンBPELプロセスを「コンポーネント」ウィンドウの「スタンドアロン」セクションからそのプロセスにドラッグします。

スタンドアロンBPELプロセスは、updateOrderStatusSPテンプレートをコールする、callアクティビティとして表示されます。その機能は次のとおりです。

- 注文番号

- 注文ステータス

図6-14に、callアクティビティのコンテンツを示します。callアクティビティにより、スタンドアロン・サブプロセスおよびインライン・サブプロセス内の参照サブプロセス・コードを実行できます。

図6-14 callアクティビティのコンテンツ

6.2.5 コンポジット・センサーを使用した出荷プロバイダの追跡

会社Xは、「コンポジット・センサーを使用した支払ステータスの追跡」で注文支払のステータスを追跡するために、また、「コンポジット・センサーを使用した注文番号の追跡」で注文番号を追跡するために、コンポジット・センサーを追加しました。

ここでは、コンポジット・センサーで出荷プロバイダを追跡するという追加要件があります。これにより、特定の出荷プロバイダで出荷されたすべての注文が検索可能になります。

会社Xは、RESTサービス上でコンポジット・センサーを定義します。図6-15の「コンポジット・センサー」ダイアログで示されているように、その定義には、出荷プロバイダを追跡するためのXPath式が含まれます。

図6-15 出荷受注を追跡するためのコンポジット・センサー

「コンポジット・センサー」ダイアログの「Enterprise Manager」チェック・ボックスも選択されます。これにより、Oracle Enterprise Manager Fusion Middleware Controlの特定のビジネス・フロー・インスタンスで、「フロー・インスタンス」ページまたは「フローのトレース」ページのコンポジット・センサーの名前と値を追跡できるようになります。図6-16に詳細を示します。

図6-16 「フローのトレース」ページのコンポジット・センサーの名前と値

6.2.6 注文の出荷を示す電子メール通知の送信

会社Xは、注文を出荷したことを電子メールで顧客に通知できる必要があります。このタスクに対処するために、会社XはUMSアダプタを構成して、顧客に電子メール通知を送信します。

UMSは、ユーザーとアプリケーション間の通信を可能にするOracle Fusion Middlewareコンポーネントです。UMSでは、電子メール、SMS、インスタント・メッセージ、ボイスなどの様々なメッセージング・チャネルがサポートされます。UMSは次のコンポーネントで構成されます。

- UMSサーバー: アプリケーションとユーザー間のメッセージ・フローをオーケストレートします。

- UMSドライバ: UMSをメッセージ・ゲートウェイに接続し、コンテンツをUMSでサポートされている様々なプロトコルに適応させます。

- UMSクライアント・アプリケーション: メッセージの送受信のビジネス・ロジックを実装します。

UMSアダプタは、「コンポーネント」ウィンドウの「テクノロジ」セクションから「外部参照」スイムレーンにドラッグされます。会社XはUMSアダプタを構成して、次のタスクを実行します。

- アウトバウンド通知の送信

- 通知チャネルとしての電子メールの使用

- 電子メールの件名への「Your Order Has Been Shipped」という文の追加

- 「From」および「To」の電子メール・アドレスの構成

図6-17に詳細を示します。

図6-17 UMSアダプタ構成ウィザード

UMSの構成が完了すると、packAndShipOrder BPELプロセスがNotifyUser UMSアダプタ参照に接続されます。図6-18に詳細を示します。

図6-18 UMSアダプタに接続されたBPELプロセス

構成を完了するために、会社Xは、packAndShipOrder BPELプロセスに適切なアクティビティを追加します:

- invokeアクティビティ: UMSアダプタを起動します(入力変数を使用)。

- assignアクティビティ: invokeアクティビティの入力変数のペイロードを移入します。

図6-19に、SOAコンポジット・エディタでのこの完了したビジネス・ソリューションの表示の概要を示します。

図6-19 完了したSOAコンポジット・アプリケーション

6.3 関連ドキュメント

表6-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。

表6-2 関連ドキュメント

参照内容

参照先

REST操作の統合

『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOAコンポジット・アプリケーションにおけるREST操作の統合に関する項

BPELプロセスの作成と設計

『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle BPEL Process Managerのスタート・ガイドに関する項

HTTPアナライザの使用

『Oracle JDeveloperによるアプリケーションの開発』のHTTPアナライザによるHTTPのモニタリングに関する項

Oracle SOA SuiteテンプレートとスタンドアロンBPELサブプロセスの作成

『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle SOA Suiteテンプレートおよび再使用可能なサブプロセスに関する項

コンポジット・センサーの作成

『Oracle SOA SuiteでのSOAアプリケーションの開発』のコンポジット・センサーの定義に関する項

UMSアダプタの構成

『テクノロジ・アダプタの理解』のOracle JCA Adapter for UMSに関する項

Oracle User Messaging Serviceによるアプリケーションの開発

統合WebLogic Serverの使用

『SOA SuiteおよびBusiness Process Management SuiteのQuick Start for Developersのインストール』のQuick Startの配布の概要に関する項

7 注文の履行

この章では、Oracle SOA Suiteで注文履行システムの作成というビジネス課題に対処する方法について説明します。プロジェクト・テンプレート、ビジネス・ルール、コンポジット・センサー、RESTバインディング参照、コヒーレンス・アダプタなどの主要なSOAコンポジット・アプリケーション・コンポーネントを使用して、この課題に対処する方法の概要を示します。

この章の内容は次のとおりです。

- ビジネス課題

- ビジネス・ソリューション

- 関連ドキュメント

7.1 ビジネス課題

会社Xには、処理する注文をリスニングし、出荷プロバイダ(たとえば、米国郵政公社(USPSまたはUPS))を選択して、梱包および出荷サービスを起動するシステムを作成する要件があります。このシナリオで起動する梱包および出荷サービスは、「注文の梱包と出荷」で設計したPackAndShipServiceコンポジットです。

7.2 ビジネス・ソリューション

このビジネス課題に対処するために、会社Xは表7-1のコンポーネントを使用するビジネス・ソリューションを設計します。

表7-1 ビジネス・ソリューションを提供するコンポーネント

コンポーネント

このコンポーネントがビジネス課題に対処する方法

コンポーネントの説明

プロジェクト・テンプレートを含むSOAコンポジット・アプリケーション

プロジェクト・テンプレートから作成された注文履行コンポジットは、処理する注文をリスニングし、出荷プロバイダを選択して、「注文の梱包と出荷」で作成した梱包および出荷サービス(PackAndShipService)を起動します。注文履行コンポジットは、注文がデータベース内でReadyForShipとして更新されるとトリガーされます。その後、注文メッセージの出荷速度を確認し、出荷速度および出荷先(州)に基づいた出荷方法を決定して、データベースまたはCoherenceキャッシュから優先出荷プロバイダを読み取り、梱包および出荷RESTサービスをコールします。

テンプレートの詳細は、表3-1を参照してください。

ビジネス・ルール

ビジネス・ルール(デシジョン表)は、速度および出荷先(州)に基づいて出荷方法を決定します。出荷方法に基づいて、優先出荷プロバイダがデータベースから取得されます。

ビジネス・ルールを使用すると、実行時の動的な意思決定が可能になり、基礎となるアプリケーション・コードからルール・ロジックを分離しながら、ポリシー、計算および判断を自動化できます。これにより、より機動的なルール・メンテナンスが可能になり、ビジネス・アナリストは、プログラマの支援を受けずに、ルール・ロジックを変更できるようになります。その際に、ビジネス・プロセスが中断されることはありません。

コンポジット・センサー

コンポジット・センサーは注文番号を追跡します。

コンポジット・センサーの詳細は、表3-1を参照してください。

REST参照

アウトバンドREST参照は、注文を梱包および出荷サービスに配信します。

RESTバインディングの詳細は、表6-1を参照してください。

コヒーレンス・アダプタ

コヒーレンス・アダプタは、最初はデータベースから、後続の読取り操作はCoherenceキャッシュから適切な出荷プロバイダを読み取ります。

追加のコヒーレンス・アダプタは、データベース・アダプタのレスポンスをCoherenceキャッシュにコピーして、次回の参照時にキャッシュで出荷プロバイダを利用できるようにします。

Coherenceキャッシュは、データベースとクライアント・アプリケーション間の仲介として機能するデータ・オブジェクトのコレクションです。データベース・データをキャッシュにロードして、異なるアプリケーションで使用できます。Coherenceキャッシュによってデータベースの負荷が軽減され、データベース・データへのより高速なアクセスが可能になります。

この章の後続の項では、表7-1のコンポーネントを使用して、注文履行のビジネス課題に対処する方法について、より詳細に説明します。

- SOAテンプレートからのプロジェクトの作成

- ビジネス・ルールを使用した出荷方法の決定

- コンポジット・センサーを使用した注文番号の追跡

- RESTインタフェースを使用した梱包サービスへの注文の配信

- コヒーレンス・アダプタを使用したキャッシュからの出荷プロバイダの読取り

- Coherenceキャッシュへのデータベース・アダプタ・レスポンスのコピー

- コンポジットのデプロイとコヒーレンス・アダプタのテスト

7.2.1 SOAテンプレートからのプロジェクトの作成

会社Xでは、処理する注文のリスニング、出荷プロバイダの選択、梱包および出荷サービスの起動を処理するSOAコンポジット・アプリケーションを設計するためのビジネス要件が頻繁に発生します。この課題に対処するため、これらの機能(必要に応じて、Oracle JDeveloperで複数のアプリケーションにインポート可能)を持つFulfillOrderTemplateというプロジェクト・テンプレートを作成しています。テンプレートは、特定のプロジェクトのビジネス要件に合せてカスタマイズできます。その特定のインポート済テンプレートに対して行った変更は、以前にそのテンプレートを使用して作成したプロジェクトには伝播されません。

以前のテンプレートと同様に、FulfillOrderTemplateプロジェクト・テンプレートは、「ツール」→「プリファレンス」→「SOA」→「テンプレート」を選択して、テンプレート記憶域の場所を指定することにより、最初にOracle JDeveloperで登録されます。

会社Xは、新規SOAプロジェクトを作成する「SOAプロジェクトの作成」ウィザードを起動し、テンプレートに基づいてプロジェクトを作成することを選択します。「SOAプロジェクトの作成」ウィザードの「SOAテンプレート」を選択すると(ダイアログが更新されて選択可能な既存のテンプレートが表示される)、このプロジェクト・テンプレートが新規アプリケーションにインポートされます。「FulfillOrderTemplate」が選択され、プロジェクト名は「FulfillOrder」に短縮されます(図7-1を参照)。

図7-1 プロジェクト・テンプレートの選択

作成の完了後、コンポジットは図7-2のようになります(プロジェクト・テンプレートがインポートされている)。

図7-2 SOAコンポジット・アプリケーションのコンテンツ

インポートされたプロジェクト・テンプレートは、次のコンポーネントで構成されます。

- 最初のデータベース・アダプタ(ReceiveOrdersReadyForShipment)。「ReadyForShip」ステータスの注文をリスニングし、データベースからレコードを読み取り、注文ごとに新規BPELプロセスをトリガーします。注文を再度読み取れないようにするには、このステータスを「ReadyForPack」に変更します。

- 2番目のデータベース・アダプタ(getShippingProvider)。主キーとして出荷方法IDを使用して、データベースから出荷プロバイダを読み取ります。出荷方法ごとの優先出荷プロバイダのリストはデータベースで保持されます。たとえば、USPSは、USAFirstClassの出荷(出荷方法ID =1)に使用され、UPSは、USAPriorityの出荷(出荷方法ID =2)に使用されます。

- オープンのreceiveOrderToShip BPELプロセス。図7-3で表示されています。このプロセスは、ReceiveOrdersReadyForShipmentデータベース・アダプタ・サービスによって起動されます。XSLTマップは、メッセージを正規の注文メッセージに変換します。fulfillOrder BPELプロセスが起動されます(正規の注文メッセージが入力として渡される)。

図7-3 receiveOrderToShip BPELプロセスのコンテンツ

- 履行BPELプロセス(図7-4を参照)。受信注文メッセージには、顧客によって選択された出荷速度が含まれます:

- 翌日出荷

- 2営業日出荷

- 標準の出荷: 3-5営業日

- 出荷速度は問わない

ビジネス・ルールでは、出荷速度および出荷先住所に基づいて出荷方法が決定されます。出荷方法IDは、出荷プロバイダを取得する際のデータベース・コールへの入力として使用されます。

図7-4 履行BPELプロセスのコンテンツ

7.2.2 ビジネス・ルールを使用した出荷方法の決定

ビジネス・ルールを使用すると、実行時に動的な意思決定を行うことができます。これにより、基礎となるアプリケーション・コードからルール・ロジックを分離しながら、ポリシー、計算および判断を自動化できます。

会社Xは、出荷方法IDを決定するためのビジネス・ルールを追加します。ビジネス・ルールは、出荷先(州)およびリクエストされた出荷速度を入力としてとり、出荷方法IDを返します。たとえば、USPSは、USAFirstClassの出荷(出荷方法ID =1)に使用され、UPSは、USAPriorityの出荷(出荷方法ID =2)に使用されます。

会社Xは、「コンポーネント」ウィンドウの「コンポーネント」セクションからSOAコンポジット・アプリケーションに「ビジネス・ルール」アイコンをドラッグします。構成の完了後、「ビジネス・ルールの作成」ダイアログは図7-5のようになります。

図7-5 定義済ビジネス・ルールの入力ファクトと出力ファクト

図7-5に示す入力ファクトと出力ファクトの両方が、スキーマ・ファイルの出荷要素タイプで定義されます(図7-6を参照)。ファクトは、ルールの推論対象のオブジェクトです。各ファクトはファクト・タイプのインスタンスです。

図7-6 出荷要素タイプ

ビジネス・ルールの作成後、コンポジットのビジネス・ルール・サービス・コンポーネントを、ルール・エディタにアクセスするためにクリックします。ルール・エディタ内で、デシジョン表が定義されます(図7-7を参照)。デシジョン表は、数多くのルールで多数のプロパティ値の組合せを分析する必要がある場合に、よりコンパクトかつ直観的に使用できる代替のビジネス・ルール・フォーマットです。デシジョン表を使用すると、すべての組合せを網羅する、または競合する組合せが存在しないルールのセットを作成できます。

次のルール条件が配送速度に対して定義されます。ルール条件は、文のIF部分を表します。ルール条件はRules Engine内の使用可能なファクトに対する問合せのようなもので、問合せから返されるそれぞれの行に対してルールを有効にします。ルール条件は、ファクトの組合せで条件式がtrueになるたびにルールをアクティブにします。

- 翌日出荷

- 2営業日出荷

- 標準の出荷: 3-5営業日

- どれでもよい(出荷速度は問わない)。この配送方法の場合、TX (テキサス州)の条件が設定されます。他のルール条件では州が設定されていないため、配送速度が唯一の要件になります。

次の出荷方法IDルール・アクションが、ルール条件ごとに定義されます。ルール・アクションは、文のTHEN部分を表します。THEN部分には、ルールの起動時に実行されるアクションが含まれます。ルールはアクティブ化され、優先度など競合解決メカニズムを使用して他のルールのアクティブ化の中から選択された後、起動されます。

- 1 - USPS: USAFirstClassの出荷用

- 2 - UPS: USAPriorityの出荷用

- 3 - USAフリー・メール

- 4 - UPS翌日配送の航空便

図7-7 ルール・エディタのディシジョン表

ビジネス・ルールを統合するには、「コンポーネント」ウィンドウの「SOAコンポーネント」セクションから履行プロセスに「ビジネス・ルール」アイコンをドラッグします(図7-8を参照)。

図7-8 ビジネス・ルールの履行BPELプロセスへの統合

会社Xは、このアクティビティによって起動されるディクショナリを選択します。入力ファクトと出力ファクトも定義されます。入力コピー・ルールの場合、ShippingTypeが、inputVariableプロセスからビジネス・ルールのdsIn (入力ファクト)変数にコピーされます。図7-9に詳細を示します。

図7-9 入力コピー・ルール

出力コピー・ルールの場合、ShippingMethodが、ビジネス・ルールのdsOut (出力ファクト)変数からshippingMethodIDプロセス変数にコピーされます。図7-10に詳細を示します。

図7-10 出力コピー・ルール

設計の完了後、fulFillmentプロセスは図7-11のようになります。

図7-11 ルール・ディクショナリの起動

7.2.3 コンポジット・センサーを使用した注文番号の追跡

前の各章で実行したように、会社Xは、メッセージのフィールドを追跡するためにコンポジット・センサーを追加します。このシナリオでは、注文番号のステータスが追跡されます。センサーが、ReceiveOrderReadyForShipmentデータベース・アダプタ・サービス上に設定されます。図7-12に詳細を示します。

図7-12 コンポジット・センサー

図7-13の「コンポジット・センサー」ダイアログに示すように、この定義には、注文番号を追跡するためのXPath式が含まれます。

図7-13 「コンポジット・センサー」ダイアログ

「コンポジット・センサーの作成」ダイアログの「Enterprise Manager」チェック・ボックスも選択されます。これにより、Oracle Enterprise Manager Fusion Middleware Controlの特定のビジネス・フロー・インスタンスで、「フロー・インスタンス」ページまたは「フローのトレース」ページのコンポジット・センサーの名前と値を追跡できるようになります。図7-14に詳細を示します。

図7-14 「フローのトレース」ページのコンポジット・センサーの名前と値

7.2.4 RESTインタフェースを使用した梱包サービスへの注文の配信

RESTサービスは、「梱包BPELプロセスを使用したRESTサービスの公開」ではWebサービスの代替として使用されています。RESTはHTTPリクエストを使用して、データのポスト(作成と更新)、データの取得(問合せの作成など)、データの更新およびデータの削除を実行します。

このビジネス・シナリオの場合、会社XはREST参照を使用して、「注文の梱包と出荷」で作成したPackAndShipサービスをコールします。会社XはRESTバインディングをコンポジットの「外部参照」スイムレーンにドラッグして、次の詳細を定義します。

- RESTアウトバウンド・インタフェース。

- 出荷RESTリソース。

- POST HTTP動詞を使用し、WADLファイルに基づいたpackandShip操作バインディング。WADLでは、HTTPベースWebアプリケーション(一般的にはREST Webサービス)の判読可能なXML説明が用意されています。WADLにより、Webの既存HTTPアーキテクチャに基づいて、Webサービスの再利用が単純になります。WADLファイルを選択すると、すべての操作バインディングの詳細が「RESTバインディングの作成」ダイアログに自動的に移入されます。図7-15に詳細を示します。

図7-15 RESTバインディング

構成が完了すると、会社Xは、fulfillOrder BPELプロセスをREST参照に接続します(図7-16を参照)。

図7-16 REST参照に接続されたBPELプロセス

構成を完了するために、会社Xは、fulfillOrderプロセスに必要なアクティビティを追加します:

- invokeアクティビティはPackAndShipOrderパートナ・リンクを起動し、必要な入力変数と出力変数を定義します。

- assignアクティビティは入力変数の出荷要素を、REST参照の入力変数の出荷要素にマップします。

BPELプロセスは一方向であるため、RESTサービスの戻り値を割り当てる必要はありません。

図7-17に詳細を示します。

図7-17 fulFillment BPELプロセスのコンテンツ

7.2.5 コヒーレンス・アダプタを使用したキャッシュからの出荷プロバイダの読取り

このコンポジットで使用されるデータベース・アダプタは、データベースに定期的にアクセスします。データベースの負荷を軽減し、データベース・データへのアクセスをより高速にするために、会社Xは、コヒーレンス・アダプタをコンポジットに統合します。コヒーレンス・アダプタは、データベース・データの初回読取り時に、そのデータをキャッシュに配置します。

Coherenceキャッシュは、データベースとクライアント・アプリケーションの間の仲介として機能するデータ・オブジェクトの集合です。データベース・データをキャッシュにロードして、異なるアプリケーションで使用できます。コヒーレンス・アダプタにより、Coherenceキャッシュへのアイテムの追加、アイテムの取得、アイテムの削除、アイテムの問合せなど、有用なコヒーレンス操作を実行できます。

会社Xは、「コンポーネント」ウィンドウの「テクノロジ」セクションからコンポジットの「外部参照」スイムレーンに「コヒーレンス」アイコンをドラッグします。アダプタ構成ウィザードを使用すると、次のコヒーレンス・アダプタの詳細を構成できます。

- コヒーレンス接続のJNDI名。

- 実行する操作。この場合、get操作がCoherenceキャッシュからデータを取得するために選択されます。

- キャッシュ・タイプ(XML)。

- キャッシュ名。

- キー・タイプ(文字列) (invokeアクティビティのjca.coherence.Keyプロパティで後で移入)。

- データベース参照レスポンス・スキーマ・ファイル(データベース参照からのレスポンスを直接Coherenceキャッシュに格納)。

アダプタの構成が完了すると、fulfillOrder BPELプロセスがコヒーレンス・アダプタに接続されます(図7-18を参照)。

図7-18 コヒーレンス・アダプタに接続されたfulfillOrder BPELプロセス

構成を完了するために、会社Xは、fulfillOrderプロセスに必要なアクティビティを追加して構成します:

- invokeアクティビティは次のように構成されます。

- QueryCoherenceパートナ・リンクを起動します。

- 入力変数および出力変数を定義します。

- jca.coherence.KeyプロパティをshippingMethodIDの値(「プロパティ」タブの下)に割り当てます。この値は、アダプタの起動時に入力変数として送信され、入力値をコヒーレンス問合せ呼出しに割り当てるassignアクティビティ文の作成を不要にします。

- ifアクティビティは次のように構成されます。

- if部分が、コヒーレンス問合せの出力変数からプロセス入力変数(出荷要素内)の出荷プロバイダ名に、出荷プロバイダ名を割り当てます。これは、「注文の梱包と出荷」で設計したPackAndShipServiceで、後で使用されます。

- else部分には、getShippingProviderデータベース・アダプタの起動と、その2つのassignアクティビティが含まれます。

完了後、構成は図7-19のようになります。

図7-19 if文

7.2.6 Coherenceキャッシュへのデータベース・アダプタ・レスポンスのコピー

会社Xは、別のコヒーレンス・アダプタをコンポジットの「外部参照」スイムレーンに追加します。このアダプタは、データベース・アダプタ・レスポンスをCoherenceキャッシュにコピーして、次回参照時にキャッシュで出荷プロバイダを利用できるようにします。

コヒーレンス・アダプタは次のように構成されます。

- コヒーレンス接続のJNDI名。

- 実行する操作。この場合、アイテムをキャッシュに配置するためにput操作が選択されます。

- キャッシュ・タイプ(XML)。

- キャッシュ名。

- キー・タイプ(文字列)。

- shippingMethodKeyのキー値。

- データベース参照レスポンスのスキーマ・ファイル。

構成を完了するために、会社Xは、履行プロセスを新規コヒーレンス・アダプタに接続します(図7-20を参照)。

図7-20 2番目のコヒーレンス・アダプタに接続されたBPELプロセス

構成を完了するために、会社Xは、fulfillOrderプロセスに必要なアクティビティを追加します:

- invokeアクティビティは次のように構成されます。

- putIntoCoherenceパートナ・リンクを起動します。

- 入力変数および出力変数を定義します。

- jca.coherence.KeyプロパティをshippingMethodIDの値(「プロパティ」タブの下)に割り当てます。この値は、アダプタの起動時に入力変数として送信され、入力値をコヒーレンス問合せ呼出しに割り当てるassignアクティビティ文の作成を不要にします。

- assignアクティビティは、コヒーレンス・アダプタの入力変数にデータベース・コールの出力変数を移入します。

構成の完了後、履行プロセスは図7-21のようになります。

図7-21 履行BPELプロセスのコンテンツ

図7-22に、SOAコンポジット・エディタでのこの完了したビジネス・ソリューションの表示を示します。

図7-22 完了したSOAコンポジット・アプリケーション

7.2.7 コンポジットのデプロイとコヒーレンス・アダプタのテスト

最初は、両方のコヒーレンス・アダプタが実行されます。Coherenceキャッシュには何も置かれていないため、queryCoherence参照は、空の変数を返します。putCoherence参照は、Coherenceキャッシュにコンテンツを配置します。図7-23に詳細を示します。

図7-23 フロー・トレース

メッセージがCoherenceキャッシュに配置されたら、監査証跡が変更されます。図7-24に詳細を示します。

図7-24 変更を示したフロー・トレース

queryCoherence参照は、出荷方法変数を返します。データベースに再度問い合せる必要はありません。図7-25に詳細を示します。

図7-25 返された出荷方法変数

7.3 関連ドキュメント

表7-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。

表7-2 関連ドキュメント

参照内容

参照先

プロジェクト・テンプレートの追加

『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle SOA Suiteテンプレートおよび再使用可能なサブプロセスに関する項

ビジネス・ルールの設計

『Oracle Business Process Managementによるビジネス・ルールの設計』のOracle Business Rulesの概要に関する項

『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle Business Rulesのスタート・ガイドに関する項

『Oracle Business Process Managementによるビジネス・ルールの設計』のデシジョン表の使用に関する項

コンポジット・センサーの作成

『Oracle SOA SuiteでのSOAアプリケーションの開発』のコンポジット・センサーの定義に関する項

REST参照の追加

『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOAコンポジット・アプリケーションにおけるREST操作の統合に関する項

コヒーレンス・アダプタの構成

『テクノロジ・アダプタの理解』のOracle JCA Adapter for Coherenceに関する項

8 コンポジットの実行のスケジューリング

この章では、Oracle SOA Suiteで十分なインベントリ・レベルを維持するというビジネス課題に対処する方法について説明します。Oracle Enterprise Schedulerなどの主要なSOAコンポジット・アプリケーション・コンポーネントを作成して、この課題に対処する方法の概要を示します。

この章の内容は次のとおりです。

- ビジネス課題

- ビジネス・ソリューション

- 関連ドキュメント

8.1 ビジネス課題

会社Xは、十分なインベントリを維持するというビジネス課題に直面しています。注文が処理されると、ウェアハウスのアイテムのストックが減るため、インベントリを補充する必要があります。注文される製品のカテゴリごとに、会社Xには異なるサプライヤがあります。一日の終わりに、注文された各製品のアイテム数を識別し、インベントリを元のレベルに戻すため、各サプライヤに対して個別のレポートが実行される必要があります。

8.2 ビジネス・ソリューション

これらのビジネス課題に対処するために、会社Xは表8-1のコンポーネントを使用するビジネス・ソリューションを設計します。

表8-1 ビジネス・ソリューションを提供するコンポーネント

コンポーネント

このコンポーネントがビジネス課題に対処する方法

コンポーネントの説明

SOAコンポジット・アプリケーション

問合せインベントリ・コンポジットは、指定されたカテゴリに対してその日に注文された製品ごとの合計アイテム数を識別します。この問合せは、その日の間に減ったインベントリ数を識別します。

SOAコンポジット・アプリケーションの詳細は、表3-1を参照してください。

Oracle Enterprise Schedulerジョブ

Oracle Enterprise Schedulerを使用して、問合せインベントリ・コンポジットのWebサービス・ジョブを定義し、指定された時刻での実行をスケジューリングしてそのジョブを送信します。

Oracle Enterprise Schedulerでは、Oracle Enterprise Manager Fusion Middleware Controlで、ジョブ・リクエストの管理、メタデータの定義およびジョブのスケジューリングを実行できます。

Oracle Enterprise Schedulerアダプタのアクティブ化および非アクティブ化

Oracle Enterprise Schedulerは、アクティブ化と非アクティブ化の繰返しスケジュールを使用して、「注文の履行」で作成した履行サービスのデータベース・アダプタをアクティブ化および非アクティブ化します。

Oracle Enterprise Schedulerにより、指定された時刻にアクティブ化および非アクティブ化するようにコンポジットのアダプタをスケジューリングできます。

この章の後続の項では、表8-1のコンポーネントを使用してクレジット検証ビジネス課題に対処する方法について、より詳細に説明します。

- Webサービス・ジョブ定義の作成

- スケジュールに基づくジョブ・リクエストの発行

- アダプタへのスケジュールの適用

8.2.1 Webサービス・ジョブ定義の作成

十分なインベントリ・レベルを識別および維持するための要件に対処するため、会社Ｘは、Oracle Enterprise Schedulerを使用します。

Oracle Enterprise Schedulerを使用すると、より大規模なトランザクションを後でジョブとして実行するために遅延させたり、定義されたスケジュールに基づいたアプリケーション・メンテナンス作業の実行を自動化することができます。また、Oracle Enterprise Schedulerを使用して、Oracle WebLogic Serverクラスタのノード全体に分散されたJava、PL/SQL、バイナリ・スクリプト、Webサービス、EJBなどの各種ジョブ・タイプを実行することもできます。Oracle Enterprise Schedulerは、これらのジョブを安全に実行すると同時に、高可用性とスケーラビリティを実現し、ロード・バランシングを行います。また、Oracle Enterprise Schedulerは、Oracle Enterprise Manager Fusion Middleware Controlコンソールを使用したモニタリングと管理を提供します。

会社Xは、インベントリを問い合せるqueryInventoryコンポジットのジョブ定義を作成します。コンポジットには、同期BPELプロセスとWebサービスがサービス・バインディング・コンポーネントとして含まれています。リクエスト固有のメタデータをジョブ定義として関連付けます。

会社Xは、Oracle Enterprise Manager Fusion Middleware Controlナビゲータで「ESSAPP」を選択し、「スケジューリング・サービス」メニューから「ジョブ・メタデータ」→「ジョブ定義」を選択して、ジョブ定義を作成します。図8-1に詳細を示します。

図8-1 ジョブ定義の作成

会社Xは、次の詳細でジョブ定義を構成します。

- QueryInventoryのジョブ名と表示名

- soaのパッケージ値

- syncWebServiceJobTypeのジョブ・タイプ

完了後、構成は図8-2のようになります。

図8-2 ジョブ定義の構成

8.2.2 スケジュールに基づくジョブ・リクエストの発行

会社Xは、「Webサービス・ジョブ定義の作成」で作成したジョブ定義を実行するスケジュールを作成します。スケジュールは、ジョブがいつ実行されるかを決定します。

Oracle Enterprise Manager Fusion Middleware Controlナビゲータの「スケジューリング・サービス」メニューから、会社は、「ジョブ・リクエスト」→「ジョブ・リクエストの発行」を選択します。QueryInventoryジョブ定義を選択し、ジョブを実行するためのスケジュールを定義します。図8-3に詳細を示します。

図8-3 ジョブ・リクエストの発行

ジョブの実行後、出力を確認できます。会社Xは、「スケジューリング・サービス」メニューから、「ジョブ・リクエスト」→「ジョブ・リクエストの検索」を選択し、「リクエスト詳細」ページに移動します。ページ下部の「ログおよび出力」セクションで、Webサービス・レスポンスに関する詳細がXMLファイルとして提供されます。図8-4に詳細を示します。

図8-4 Webサービス・レスポンスの出力結果

8.2.3 アダプタへのスケジュールの適用

Oracle Enterprise Schedulerにより、指定された時刻にアクティブ化および非アクティブ化するようにコンポジットのアダプタをスケジューリングすることもできます。システム負荷が最小であるときにアダプタをアクティブ化するようにスケジュールできます。「注文の履行」で設計した履行コンポジットには、サービス入力としてデータベース・アダプタが含まれます。

会社Xは、Oracle Enterprise Schedulerで繰返しスケジュールを使用して、データベース・アダプタをアクティブ化および非アクティブ化します。会社Xは、「スケジューリング・サービス」リストから、「ジョブ・リクエスト」→「スケジュールの定義」を選択します。会社Xは、表8-2に表示されている詳細で、データベース・アダプタのアクティブ化および非アクティブ化のジョブ定義を構成します。データベース・アダプタは、10分ごとにアクティブ化してから、10分ごとに非アクティブ化するように構成されます。

表8-2 アダプタのアクティブ化と非アクティブ化の構成

要素

アダプタのアクティブ化

アダプタの非アクティブ化

名前

activateSched

deactivateSched

表示名

activateSched

deactivateSched

パッケージ

soa

soa

頻度

毎時/分

毎時/分

毎

10分

10分

非アクティブ化は、5分、15分、25分ごとに発生します。アクティブ化は、10分、20分、30分ごとに発生します。

開始日

今から10分

今から5分

終了日の使用

未チェック

未チェック

完了後、アダプタのアクティブ化および非アクティブ化の構成は図8-5のようになります。

図8-5 アダプタ・ジョブのアクティブ化と非アクティブ化

会社Xは、Oracle Enterprise Manager Fusion Middleware Controlのデータベース・アダプタ・ホーム・ページに移動し、データベース・アダプタのアクティブ化および非アクティブ化を選択します。図8-6に詳細を示します。

図8-6 データベース・アダプタ・ホーム・ページのデータベース・アダプタのアクティブ化および非アクティブ化

会社Xは、指定された時刻に、データベース・アダプタをアクティブ化および非アクティブ化することを選択します。図8-7に詳細を示します。

図8-7 アダプタのアクティブ化スケジュール

8.3 関連ドキュメント

表8-3では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。

表8-3 関連ドキュメント

参照内容

参照先

ジョブ定義とスケジュールの作成

『Oracle Enterprise Schedulerの管理』のOracle Enterprise Schedulerリクエストの管理に関する項

アダプタのアクティブ化および非アクティブ化

『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle Enterprise Schedulerを使用したJCAアダプタ・エンドポイントのアクティブ化および非アクティブ化のスケジューリングに関する項

9 ファイル転送の管理

この章では、Oracle Managed File Transfer (MFT)の使用方法、およびSOAコンポジット・アプリケーションとOracle MFTの統合方法の概要を説明します。

この章の内容は次のとおりです。

- ビジネス課題

- ビジネス・ソリューション

- 関連ドキュメント

9.1 ビジネス課題

会社Xには、コンポジットを異なるエンドポイント・タイプ(ファイルベースのエンドポイント・タイプやFTPベースのエンドポイント・タイプなど)と相互作用させる要件があります。たとえば、FTPサーバーを使用して、ファイルをファイル・システムに書き込めるようにする必要があります。

9.2 ビジネス・ソリューション

これらのビジネス課題に対処するために、会社Xは表9-1のコンポーネントを使用するビジネス・ソリューションを設計します。

表9-1 ビジネス・ソリューションを提供するコンポーネント

コンポーネント

このコンポーネントがビジネス課題に対処する方法

コンポーネントの説明

Oracle MFT転送

- Oracle MFT転送はファイルを受信し、そのファイルをMFT埋込みFTPサーバーを使用してファイル・システムに書き込みます。

- Oracle MFTは、SOAコンポジット・アプリケーション内のMFTサービスを起動し、コンテンツをインラインで渡すか参照によって渡すかをファイル・サイズに基づいて動的に決定します。

Oracle MFTは、高パフォーマンスで標準ベースのエンドツーエンド管理対象ファイル・ゲートウェイです。Oracle MFTは、ファイル暗号化、スケジューリング、埋込みFTPおよびsFTPサーバーを含む軽量のWebベース設計時コンソールを使用した設計、デプロイメントおよびファイル転送のモニタリングを提供します。

この章の後続の項では、表9-1のコンポーネントを使用してファイル転送のビジネス課題に対処する方法について、より詳細に説明します。

- 転送、ソースおよびターゲットの作成

- MFTサービスを使用したSOAコンポジット・アプリケーションの作成

- 注文ファイルのSOAコンポジットへの送信

- ペイロード・タイプの処理

- インライン・ペイロードを使用したProcessOrderコンポジットの起動

9.2.1 転送、ソースおよびターゲットの作成

Oracle MFTのファイル配信構造は、次のアーティファクト・タイプで構成されます。

- ソースは、ファイルの配信元を定義します。

- ターゲットは、ファイルの宛先を定義します。

- 転送は、1つのソースを1つ以上のターゲットに関連付けます。

これらのアーティファクトは、Oracle Managed File Transferコンソールのデザイナ・ページで作成します。

会社Xは、OrdersTransferという転送を作成します(図9-1を参照)。このページには、ソースおよびターゲットを作成するためのオプションが含まれています。

図9-1 転送の作成

会社Xは、次のソースおよびターゲットのアーティファクトを作成します。

- CreateSourceというソース。ファイルは/ordersディレクトリに配置されます。FTP埋込みサーバーが、ファイルの転送用に選択されます。図9-2に詳細を示します。Order*.xmlのパターンに従うファイルを処理するために、ソース・ロケーションのより詳細な定義が行われます。

図9-2 ソース・ロケーション

- OrdersFileTargetというターゲット。転送ファイルが/tmp/ordersディレクトリに配置されます。ファイル・ターゲットは、/tmp/orders/outputなどのサブディレクトリでこの場所をオーバーライドすることで再利用できます。圧縮レベルを選択するために、ターゲットのより詳細な定義が行われます。図9-3に詳細を示します。

図9-3 ターゲット・ロケーション

デプロイメント後、/ordersのOrders*.xmlのパターンに従うファイルは、圧縮形式で/tmp/ordersに書き込まれます。図9-4のOracle Managed File Transferコンソールに、転送結果が表示されます。

図9-4 転送結果

9.2.2 MFTサービスを使用したSOAコンポジット・アプリケーションの作成

会社Xは、「MFTProcessor」という名前のSOAコンポジットと空のBPELプロセスを、「BPELプロセスの作成」ダイアログの「サービスを後で定義」を選択することにより作成します。会社Xは、SOAコンポジット・エディタで、「コンポーネント」ウィンドウの「テクノロジ」セクションからコンポジットの「公開されたサービス」スイムレーンにMFTアイコンをドラッグすることで、Oracle MFTサービスを作成します。Oracle MFTサービスは、ファイル・コンテンツをインラインで渡すか参照によって渡すかを、ファイル・サイズに基づいて動的に決定するように設計されます。構成の完了後、サービスは図9-5のようにコンポジットにワイヤリングされます。

図9-5 BPELプロセスに接続されたOracle MFTサービス

構成を完了するために、会社Xは、MFTBPELProcess BPELプロセスに必要なアクティビティを追加して構成します:

- receiveアクティビティは、Oracle MFTサービスによって起動され、入力変数で構成されます。

- assignアクティビティは、レスポンスとしてペイロード・タイプを送信します。

- replyアクティビティは、Oracle MFTサービスに出力変数を返します。

完了後、BPELプロセス・デザインは図9-6のようになります。

図9-6 MFTサービスを使用したBPELプロセス

コンポジットは、Oracle Enterprise Manager Fusion Middleware Controlでデプロイおよび確認されます。

9.2.3 注文ファイルのSOAコンポジットへの送信

会社Xは、追加のOracle MFTターゲットを作成して、デプロイされたMFTProcessorコンポジットを起動します。MFTProcessorコンポジットのエンドポイントURLを、Oracle Enterprise Manager Fusion Middleware Controlの「Webサービスのテスト」ページからコピーします。図9-7に詳細を示します。

図9-7 デプロイ済コンポジットのエンドポイントURLのコピー

Oracle Managed File Transferコンソールで、会社Xは、「Webサービスのテスト」ページからコピーされたコンポジットのURLを使用してOrdersSOATargetターゲットを作成し、ファイル配信方法としてインライン添付を選択します。図9-8に詳細を示します。

図9-8 MFTターゲット

再デプロイメント後、/ordersディレクトリのOrders*.xmlパターンに従うファイルが、/tmp/ordersディレクトリに転送されます。Oracle Managed File Transferコンソールに、転送結果が表示されます(図9-9を参照)。OrdersSOATargetターゲットは、以前に作成したOrdersFileTargetソースとともに表示されます。

図9-9 出力結果

Oracle Enterprise Manager Fusion Middleware Controlのコンポジットのビジネス・フロー・インスタンスの監査証跡にある「ペイロードの表示」リンクに、このファイルがOracle MFT埋込みFTPサーバーを指すFTP参照として送信されたことが示されます。図9-10に詳細を示します。

図9-10 監査証跡

9.2.4 ペイロード・タイプの処理

会社Xは、MFTProcessorコンポジットのBPELプロセスにifアクティビティを追加します。各ifアクティビティ・ブランチは、Oracle MFTがSOAコンポジットに送信する各種ペイロードを処理するためのXPath式を定義し、「注文処理システムの作成」で作成したProcessOrderサービスをコールするためのインライン処理を実装します。図9-11に詳細を示します。

図9-11 Ifアクティビティ・ブランチ

ブランチは次のように定義されます。

- FtpRefFile: 参照によりファイルを渡します。ファイルはFTPを使用して転送されます。このブランチは、xp20:compare($PayloadType,'FtpRefFile') = 0のXPath式を使用します。

- FtpRefDir: 参照によりファイルのディレクトリを渡します。ファイルのディレクトリは、FTPを使用して転送されます。このブランチは、xp20:compare($PayloadType,'FtpRefDir') = 0のXPath式を使用します。

- FileRefFile: 参照によりファイルを渡します。ファイルは、ファイル・アダプタを使用した特別な処理を経た後で渡されます。このブランチは、xp20:compare($PayloadType,'FileRefFile') = 0のXPath式を使用します。

- FileRefDir: 参照によりファイルのディレクトリを渡します。ファイルのディレクトリは、ファイル・アダプタを使用した特別な処理を経た後で渡されます。このブランチは、xp20:compare($PayloadType,'FileRefDir') = 0のXPath式を使用します。

- InlineBinary: バイナリ・ファイルをインラインで渡します。このブランチは、xp20:compare($PayloadType,'InlineBinary') = 0のXPath式を使用します。

- InlineXML: XMLファイルをインラインで渡します。これはelseブランチであるため、式は必要ありません。

再デプロイメント後、ビジネス・フロー・インスタンスの監査証跡には、2つの注文ファイルが表示されます(OrderSample.xmlおよびOrderSampleLarge.xml)。各ファイルは、ifブランチのXPath式に基づいて、SOA BPELプロセスの異なるパスをとります。図9-12に詳細を示します。

図9-12 監査証跡

「フローのトレース」ページの「トレース」表には、「Managed File Transfer」名の隣にリンクがあり、Oracle Managed File Transferコンソールに移動できます。図9-13に詳細を示します。

図9-13 Oracle Managed File Transferコンソールへのリンク

9.2.5 インライン・ペイロードを使用したProcessOrderコンポジットの起動

会社Xは、「コンポーネント」ウィンドウの「テクノロジ」セクションからMFTProcessorコンポジットの「外部参照」スイムレーンにSOAPアイコンをドラッグします。SOAPサービス参照は、ProcessOrderエンドポイントを起動するように構成されます。図9-14に詳細を示します。

図9-14 SOAP参照

SOAP構成の完了後、会社Xは、BPELプロセスに必要なアクティビティを追加して構成します:

- Webサービスが起動されるように、invokeアクティビティが、ifアクティビティのelse部分に追加されます。入力変数と出力変数が作成されます。

- assignアクティビティは、ProcessOrder入力変数にMFTサービス入力ペイロードをマップします。

再デプロイメント後のOrdersSample.xmlファイルは、/ordersに配置されてから/tmp/ordersに転送されます。Oracle Managed File Transferコンソールに、転送結果が表示されます(図9-15を参照)。

図9-15 出力ファイル

監査証跡に、ProcessOrderコンポジットが起動され、注文が処理されたことが示されます。図9-16に詳細を示します。

図9-16 監査証跡

9.3 関連ドキュメント

表9-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。

表9-2 関連ドキュメント

参照内容

参照先

主要なOracle MFTの概念

『Oracle Managed File Transferの使用』のOracle Managed File Transferの理解に関する項

Oracle MFT転送、ターゲットおよびソース

『Oracle Managed File Transferの使用』のアーティファクトの設計: 転送、ソースおよびターゲットに関する項

10 B2Bの注文の受入れ

この章では、Oracle SOA Suiteで、電子データ交換(EDI)ドキュメント・プロトコルなどのB2B標準に従う注文を受け入れるというビジネス課題に対処する方法について説明します。Oracle B2B、Oracle Managed File Transfer (MFT)、Oracle Service Busなどの主要なSOAコンポジット・アプリケーション・コンポーネントを使用して、この課題に対処する方法の概要を示します。

この章の内容は次のとおりです。

- ビジネス課題

- ビジネス・ソリューション

- 関連ドキュメント

10.1 ビジネス課題

会社Xには、注文処理システムで、いくつかの異なる入力チャネルから送信されたEDI XMLドキュメントの注文を受け入れる要件があります。

10.2 ビジネス・ソリューション

このビジネス課題に対処するために、会社Xは表10-1のコンポーネントを使用するビジネス・ソリューションを設計します。

表10-1 ビジネス・ソリューションを提供するコンポーネント

コンポーネント

このコンポーネントがビジネス課題に対処する方法

コンポーネントの説明

Oracle B2B

Oracle B2Bコンソールを使用して、リモート取引パートナからのEDI XML注文を受け入れるドキュメント・フローを構築します。

Oracle B2Bを使用すると、小売業者、サプライヤ、メーカーなどの企業間でドキュメントを安全かつ確実に交換できます。B2B E-Commerceは、成熟したビジネス・ドキュメント、従来のビジネス・プロセス、業界固有のメッセージング・サービスを表しています。B2B E-Commerceには、完全なエンドツーエンドのビジネス・プロセスを管理するアーキテクチャが必要です。Oracle B2Bは、ビジネス･プロセスのプラットフォーム、エンド･ツー･エンドのインスタンス追跡、可視性、監査、プロセス･インテリジェンス、ガバナンス、セキュリティの統合を可能にするアーキテクチャを提供します。

Oracle MFT

Oracle MFTは、Oracle B2Bと統合され、EDI XML注文のOracle B2Bへの送信を埋込みFTPサーバーで行えるようにします。

Oracle MFTの詳細は、表9-1を参照してください。

Oracle Service Bus

Oracle Service BusはOracle B2Bと統合されます。これにより、Oracle Service Busでキューから注文を読み取って、それをEDI XMLフォーマットからProcessOrderコンポジットへの送信用の正規の注文メッセージに変換できます。

Oracle Service Busの詳細は、表3-1を参照してください。

図10-1に、このビジネス・ソリューションの実装方法の概要を示します。

図10-1 概要

この章の後続の項では、表10-1のコンポーネントを使用してEDI XMLドキュメント注文のビジネス課題に対処する方法について、より詳細に説明します。

- Oracle B2Bを使用した取引きパートナおよび取引きパートナ・アグリーメントの作成

- Oracle MFTターゲットとOracle B2Bとの統合

- Oracle B2Bとの統合

- ProcessOrderコンポジットとOracle B2Bとの統合

10.2.1 Oracle B2Bを使用した取引きパートナおよび取引きパートナ・アグリーメントの作成

注文処理システムでEDI XMLフォーマットの注文の受入れを可能にするというビジネス課題に対処するために、会社Xは、Oracle B2Bを使用します。Oracle B2Bにより、会社Xと、EDI XMLフォーマットで注文を送信する任意の取引パートナ間の取引パートナ・アグリーメントを作成できます。取引パートナ・アグリーメントは、2つの取引パートナ(ホスト取引パートナとリモート取引パートナ)で構成されます。取引パートナ・アグリーメントには、これら2つの取引パートナ(イニシエータとして機能しているパートナと応答者として機能しているパートナ)がビジネス・ドキュメントを交換する際の条件が定義されています。

会社Xは、Oracle B2Bコンソールで次の管理タスクを実行します。

- キューイング配信方法をJMSに設定します。

- EDI_XML_850という名前のドキュメント・タイプを作成します。

- インバウンドEDI XML 850ファイル用のX12_4010_850_XML_Defという名前のドキュメント定義を作成し、ルート・ノード名を作成します。ドキュメント定義は、実行時に処理されるトランザクション構造を定義し、主要な識別構成が含まれます。B2B Gatewayがこのルート・ノードでXMLファイルを検出する場合は、このドキュメント定義を照合することによって、取引パートナ・アグリーメントが導き出されます。

- WSDLファイルをインポートします。

- Webサービス・リスニング・チャネルを作成します。

会社Xは、取引パートナからの新規XMLドキュメント・トランザクションを受け入れるために、次の取引パートナと取引パートナ・アグリーメントを作成します。取引パートナ・アグリーメントは、取引に関係するドキュメントとパートナ、処理の方向、プロトコルの種類を指定する点で契約書と類似しており、デジタル署名、メッセージの暗号化、注文確認の必要性の有無などを指定するセキュリティ・パラメータが含まれます。

- Partner1という取引パートナを作成し、以前に作成したX12_4010_850_XML_Defドキュメント定義を選択します。これにより、Partner1が、このドキュメント定義を使用してホスト取引パートナ会社X(Oracle B2BコンソールではMyCompanyと呼ばれる)と取引できることがOracle B2Bに通知されます。

- Partner1をホスト取引パートナ(会社X)に関連付ける取引パートナ・アグリーメントを作成します。アグリーメントは、ドキュメント、メッセージの方向、配信チャネルおよびその他の設定を指定します。
図10-2では、以前に作成したドキュメント定義と、その処理方向(リモートPartner1がホスト会社X(Oracle B2BコンソールではMyCompanyと呼ばれる)にインバウンドEDI XML注文を送信している)が選択されています。

図10-2 ドキュメント定義と方向の選択

デプロイメント後、会社Xは、Webサービス・リスニング・チャネルにXMLペイロードを提出することによって構成をテストします。Oracle B2Bコンソールの「レポート」タブに、詳細が表示されます(図10-3を参照)。

図10-3 「レポート」タブ

「詳細」列のリンクに移動すると、メッセージがJMSキュー「jms/b2b/B2B_IN_QUEUE」に書き込まれたことが示されます。図10-4に詳細を示します。

図10-4 レポート結果

10.2.2 Oracle MFTターゲットとOracle B2Bとの統合

会社Xには、FTPサーバーによって送信されたEDI XML注文を受け入れる要件もあります。会社Xは、「ファイル転送の管理」で説明した、Oracle MFTを使用するようにOracle B2Bを構成します。これにより、Partner1が、次のチャネルを介してEDI XML注文を会社Xに送信できるようになります。

- Webサービス(前述のとおり)

- Oracle MFTを使用したFTPサーバー

会社Xは、Oracle Managed File Transferコンソールの「管理」タブでOracle B2Bサーバーに接続して、最初にOracle MFTを構成します。図10-5に詳細を示します。

図10-5 Oracle B2BサーバーへのOracle MFTの構成

会社Xは、B2BタイプのB2B_Ordersという名前のターゲットを作成します。ターゲットは、ファイルの宛先を定義します。「管理」タブで作成したドメインの別名が選択されます。図10-6に詳細を示します。

図10-6 B2B_Ordersターゲット

転送は、1つのソースを1つ以上のターゲットに関連付けます。会社Xは、Orders2B2BTransferという名前の新規転送を作成し、次のように構成します。

- 「転送、ソースおよびターゲットの作成」で作成した既存のソース「OrdersFTPEmbeddedSource」を選択します。ソースはファイルの転送元を定義します。OrdersFTPEmbeddedSourceは、FTP埋込みサーバーを使用して、/ordersディレクトリのファイルを転送するように構成されます。

- B2B_Ordersターゲットを選択します。

- フィルタリング・パターンとして「EDI_XML_850」を入力します。

- 配信方法として「インライン」を選択します。

- 「最大インライン・サイズ(バイト)」フィールドに「1000000」と入力します。

図10-7に詳細を示します。

図10-7 転送、ソースおよびターゲットが定義されたOracle MFT転送

/ordersディレクトリのEDI_XML_850パターンに従うEDI XMLファイルのデプロイメントと配置の後は、Oracle B2Bコンソールの「レポート」ページに、メッセージが配信されたことが示されます。

10.2.3 Oracle Service BusとOracle B2Bとの統合

Oracle B2Bと統合するために、会社Xは、Oracle JDeveloperでB2B_SB_ReceiveOrderという名前のOracle Service Busプロジェクトを作成します。会社Xの全体的な目的は、Oracle Service Busプロジェクトがキューからメッセージを読み取り、それを「注文処理システムの作成」で作成したProcessOrderコンポジットへの提出用に、EDI XMLから正規の注文メッセージに変換することです。

Oracle Service Busプロジェクトは、「SOAコンポジット・アプリケーションの登録」で作成した既存のOracle Service Busアプリケーション内で作成されます。このプロジェクトは、JMSキューからOracle B2Bメッセージを取得し、それを正規のXMLフォーマットに変換した後、ファイルに書き込みます。図10-8に詳細を示します。実装後、会社Xは、「SOAコンポジット・アプリケーションの登録」で作成したValidatePSプロセスの注文プロキシをコールするようにOracle Service Busプロセスを拡張します。

図10-8 Oracle Service BusアプリケーションのB2B_SB_ReceiveOrderプロジェクト

プロジェクトのコンポーネントは、次のタスクを実行します。

- JMSReceiveOrder_ProxyService.proxy: B2B_IN_QUEUE.JMSキューからOracle B2Bメッセージ(注文)を取得します。JMS URLポートは、Oracle B2Bを実行しているSOAサーバーを指します。

- MapEDI850ToCanonicalOrder.pipeline: Oracle B2Bメッセージを正規の注文XMLフォーマットに変換します。

- WriteCanonicalToFile.bix: 正規の注文XMLフォーマットを/tmp/b2b/osbfilesディレクトリ内のファイルに書き込みます。

デプロイメント後、注文は、WebサービスおよびOracle MFTチャネルから取得されて変換された後、ディレクトリに書き込まれます。Oracle Enterprise Manager Fusion Middleware Controlの「メッセージ・レポート」セクションに、メッセージがOracle Service Busで処理されたことが示されます。図10-9に詳細を示します。

図10-9 「メッセージ・レポート」の詳細

10.2.4 ProcessOrderコンポジットとOracle B2Bとの統合

会社Xは、Oracle B2Bを「注文処理システムの作成」で作成したProcessOrderコンポジットと統合します。

会社Xは、次のタスクとテストを実行することで、Oracle B2BがProcessOrderコンポジットを起動して、注文の受信と処理を行っていることを確認します。

- MapEDI850ToCanonicalOrderパイプラインを編集して、ルート・ノード宛先ビジネス・サービスを、「ビジネス・サービスとしてのProcessOrderコンポジットの登録」で作成したProcessBSビジネス・サービスに変更します。

- WebサービスおよびOracle MFTチャネルを再デプロイしてテストします。

- Oracle B2Bコンソールの「レポート」タブと、Oracle Enterprise Manager Fusion Middleware ControlのOracle Service Busの「メッセージ・レポート」ページで注文を追跡します。

- Oracle Enterprise Manager Fusion Middleware ControlのProcessOrderコンポジット・ビジネス・フロー・インスタンスをチェックして、注文が正常に受信されて処理されたことを確認します。

10.3 関連ドキュメント

表10-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。

表10-2 関連ドキュメント

参照内容

参照先

Oracle B2Bの理解

『Oracle B2Bユーザーズ・ガイド』のOracle B2Bの概要に関する項

Oracle B2Bでの取引パートナおよび取引パートナ・アグリーメントの作成

『Oracle B2Bユーザーズ・ガイド』の取引パートナの構成に関する項

『Oracle B2Bユーザーズ・ガイド』の取引パートナ・アグリーメントの作成とデプロイに関する項

Oracle MFT転送、ターゲットおよびソースの作成

Oracle Managed File Transferの使用のアーティファクトの設計: 転送、ソースおよびターゲットに関する項

Oracle Service Busでのパイプラインの追加

『Oracle Service Busでのサービスの開発』のパイプラインの追加方法に関する項

Oracle Service Busでのプロキシの追加

『Oracle Service Busでのサービスの開発』のプロキシ・サービスの作成方法に関する項

Oracle Service Busでのデータの変換

『Oracle Service Busでのサービスの開発』のデータの変換に関する項

11 不正検出の追加

この章では、Oracle SOA Suiteで不正検証システムの作成というビジネス課題に対処する方法について説明します。Oracle Event Processingおよびイベント配信ネットワーク(EDN)などの主要なコンポーネントを作成および使用して、この課題に対処する方法の概要を示します。

この章の内容は次のとおりです。

- ビジネス課題

- ビジネス・ソリューション

- 関連ドキュメント

11.1 ビジネス課題

会社Xには、潜在的なクレジット・カードの不正使用を排除するために、新しいクレジット・カード不正検出システムを実装するという要件があります。

11.2 ビジネス・ソリューション

このビジネス課題に対処するために、会社Xは表11-1のコンポーネントを使用するビジネス・ソリューションを設計します。

表11-1 ビジネス・ソリューションを提供するコンポーネント

コンポーネント

このコンポーネントがビジネス課題に対処する方法

コンポーネントの説明

Oracle Event Processingアプリケーション

Oracle Event Processingアプリケーションは、関連付けられた電子メール・アドレスで個別認識されている顧客の発注(イベント)に対し、リアルタイムで時間ベースの分析を提供します。注文(イベント)がOracle Event Processingサーバーに渡されると、そのイベントが動的にアクセスされて、潜在的な不正行動を調べるために24時間で$1000を超える注文合計額に達するイベント・パターンが観察されます。

Oracle Event Processingは、リアルタイム・ストリーミング・イベントをモニターするアプリケーションを開発、管理するための高スループットで低遅延のプラットフォームです。Oracle Event Processingは、イベント・データをリアルタイムに処理します。

ビジネス・イベントおよびイベント配信ネットワーク(EDN)

Oracle Event Processingアプリケーションは、イベント(FraudCheckRequest)を公開するコンポジットから特定のイベントを受信して、EDN上のイベント(FraudCheckResponse)にサブスクライブします。

目的の状況が発生したときにビジネス・イベントが起動されます。たとえば、ローン・フローのシナリオで、ローン・プロセスを実行しているBPELプロセス・サービス・コンポーネントは、プロセスの完了時にローン完了イベントを起動できます。ビジネス・イベントは、EDNに公開されます。

SOAコンポジット・アプリケーション

注文イベントをOracle Event Processingアプリケーションに公開して、結果イベント(結果分析を含む)にサブスクライブすることによって、SOAコンポジット・アプリケーションを使用したOracle Event Processingアプリケーションのテストが行われます。

SOAコンポジット・アプリケーションの詳細は、表3-1を参照してください。

この章の後続の項では、表11-1のコンポーネントを使用して不正検出システムのビジネス課題に対処する方法について、より詳細に説明します。

- アプリケーションの作成

- アプリケーションへのイベントの送信

- イベント・データの送信

11.2.1 Oracle Event Processingアプリケーションの作成

クレジット・カード不正検出課題に対処するために、会社Xは、Oracle Event Processingを使用して、各インバウンド注文(イベント)に動的にアクセスし、潜在的な不正使用アクティビティのイベント・パターンを観察します。

会社Xは、Oracle JDeveloperでFraudOEPApplicationという名前のOracle Event Processingアプリケーションを作成します。このアプリケーションは、イベント(FraudCheckRequest)を公開するコンポジットから特定のイベントを受信し、EDN上のイベント(FraudCheckResponse)にサブスクライブします。これらのイベントの定義は、関連するスキーマ・ファイルとともにイベント定義言語(EDL)ファイルで提供されます。EDLファイルは、ビジネス・イベント定義の作成に使用するスキーマです。

EDNは、標準のJMSメッセージング・インフラストラクチャに基づいています。会社Xは、Oracle WebLogic Server管理コンソールのSOAJMSModule内でJMSトピックを作成することにより、Oracle Event ProcessingアプリケーションでJMS実装を使用します。図11-1に詳細を示します。

図11-1 JMSトピックの構成

会社Xは、「コンポーネント」ウィンドウからドラッグして構成される次のコンポーネントでOracle Event Processingアプリケーションを設計します。

- 次のアーティファクトで構成されるedn-inbound-adapterというEDNインバウンド・アダプタ:

- アプリケーションで使用されるEDNイベント・タイプ名を含むEDLファイル(FraudCheckEvent.edl):

<?xml version = '1.0' encoding = 'UTF-8'?>
<ns0:definitions xmlns:ns0="http://schemas.oracle.com/events/edl"
targetNamespace="http://xmlns.oracle.com/Application2/Project1/
FraudCheckEvent">
<ns0:schema-import location="../Schemas/FraudCheckType.xsd"
namespace="http://www.oracle.com/oep"/>
<ns0:event-definition name="FraudCheckRequest">
<ns0:content xmlns:ns1="http://www.oracle.com/oep"
element="ns1:FraudCheckRequest"/>
</ns0:event-definition>
<ns0:event-definition name="FraudCheckResponse">
<ns0:content xmlns:ns2="http://www.oracle.com/oep"
element="ns2:FraudCheckResponse"/>
</ns0:event-definition>
</ns0:definitions>

- FraudCheckRequestというイベント・タイプ

- EDLファイルに関連付けられているスキーマ・ファイル

- 「コンテキスト・プロパティ」セクションで選択されるFraudCheckRequestイベント・タイプに関連付けられているednInputChannelというイベント・チャネル(図11-2を参照)。これはイベント・タイプをチャネルに関連付けます。

図11-2 インバウンド・チャネルに関連付けられているイベント・タイプ

- ストリーミング・イベント・データに適用されるComplex Query Language (CQL)ルールが移入されるednProcessorというプロセッサ。必要なCQLは、不正検出に関連します(図11-3を参照)。$1000以上のリクエストの場合は、しきい値を超えます。

図11-3 プロセッサの不正検出CQL

- 「コンテキスト・プロパティ」セクションで選択されるFraudCheckResponseイベント・タイプに関連付けられているednOutputChannelという2番目のイベント・チャネル(図11-4を参照)。これはイベント・タイプをチャネルに関連付けます。

図11-4 アウトバウンド・チャネルに関連付けられているイベント・タイプ

- 次のアーティファクトで構成されるedn-outbound-adapterというEDNアウトバウンド・アダプタ:

- アプリケーションによって使用されるEDNイベント・タイプ名を含むEDLファイル(FraudCheckEvent.edl)

- FraudCheckResponseのイベント・タイプ

注意:

スキーマ・ファイルは必要ありません。

これらのコンポーネントは、デザイナの次の注文でワイヤリングされます。

edn-inbound-adapter→ednInputChannel→ednProcessor→ednOutputChannel→edn-outbound-adapter

11.2.2 Oracle Event Processingアプリケーションへのイベントの送信

Oracle Event Processingアプリケーションをテストするには、会社Xはまず、Oracle Event Processingサーバーへの接続を作成し、アプリケーションをデプロイします。デプロイしたら、アプリケーションはイベントが分析用に送信されるのを待機できます。

会社Xには、Oracle Event ProcessingアプリケーションにEDNイベントを送信可能なテスト・コンポジット(EDNOEPv2Proj)があります。生成されたEDNイベントはテスト・コンポジットに返され、ファイル・アダプタを使用して、その情報をレビューおよび分析用のファイルに書き込みます。図11-5に詳細を示します。テスト・アプリケーションは、2つのOracle Mediatorサービス・コンポーネントで構成されます。Oracle Mediatorにより、異なるコンポーネント間でイベントをルーティングできます。

- 1番目のOracle Mediatorは、Oracle Event Processingアプリケーションに送信されるFraudCheckRequestイベントを公開します。

- 2番目のOracle Mediatorは、テスト・コンポジットに返されるFraudCheckResponseイベントをサブスクライブします。

図11-5 イベントを送受信するためのテスト・コンポジット

Oracle Enterprise Manager Fusion Middleware Controlコンソールの「ビジネス・イベント」ページの「サブスクリプション」タブ。テスト・コンポジットは、このページに表示される、FraudCheckRequestおよびFraudCheckResponseイベント・タイプにマッピングするOracle WebLogic Server JMSトピックを使用します。図11-6に詳細を示します。

図11-6 ビジネス・イベント

11.2.3 Oracle Enterprise Manager Fusion Middleware Controlからのイベント・データの送信

会社Xは、Oracle Enterprise Manager Fusion Middleware Controlの「Webサービスのテスト」ページを使用して、SOAコンポジットにイベント・データを送信し、Oracle Event Processingアプリケーションでその統合をテストします。これは、CQL Group By句によって使用される電子メール・アドレスで、関連する注文と合計金額(ドル)のコレクションごとに識別します。図11-7に詳細を示します。

図11-7 「Webサービスのテスト」ページ

コンポジットが指定されたデータで実行されると、リクエストがOracle Event Processingアプリケーションで正常に処理されたことを示すメッセージが表示されます。EDNイベントがアプリケーションによって正常に公開および受信され、そのペイロードが分析されます。結果が出力ファイルで提供されます。$1000以上の値が指定される場合、出力ファイルは、しきい値を超えていることを示します。これは、権限のないユーザーによるクレジット・カードの不正使用の潜在的なインジケータとなる場合があります。ステータスは、「アプリケーションの作成」のOracle Event Processingアプリケーションで指定されたCQL文によって決定されます。図11-8に詳細を示します。

図11-8 出力ファイル

テストの完了後、会社Xは、Oracle Event Processingアプリケーションを前の章で説明したビジネス・ソリューションと統合できます。

11.3 関連ドキュメント

表11-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。

表11-2 関連ドキュメント

参照内容

参照先

Oracle Event Processingアプリケーションの開発

Oracle Event Processingアプリケーションの開発のアプリケーションの開発の概要に関する項

Oracle Event Processingの管理

『Oracle Event Processingの管理』のサーバー管理の概要に関する項

ビジネス・イベントの作成と管理およびEDNの使用

『Oracle SOA SuiteでのSOAアプリケーションの開発』のビジネス・イベントおよびイベント配信ネットワークの使用に関する項

『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のビジネス・イベントの管理に関する項

Oracle Mediatorを使用したビジネス・イベントの公開とサブスクライブ

『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle Mediator Serviceコンポーネントの使用に関する項

Oracle Enterprise Manager Fusion Middleware Controlでのテスト・インスタンスの作成

『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のビジネス・フローのテスト・インスタンスの起動に関する項

12 Oracle Business Activity Monitoringを使用したビジネス・インサイトの取得

この章では、Oracle SOA Suiteで顧客の注文リクエストに対してビジネス・インサイトを得るというビジネス課題に対処する方法について説明します。プロセス分析およびOracle Business Activity Monitoring (BAM)などの主要なSOAコンポジット・アプリケーション・コンポーネントを使用して、この課題に対処する方法の概要を示します。

この章の内容は次のとおりです。

- ビジネス課題

- ビジネス・ソリューション

- 関連ドキュメント

12.1 ビジネス課題

会社Xには、次のトレンドを識別するために、顧客注文システムに対するビジネス・インサイトを得るという要件があります。

- 承認、受信または却下された注文数。

- 基準に満たない収入、信用または年齢などの拒否の理由。

- 州別の自動または手動のクレジット・カード承認数。

12.2 ビジネス・ソリューション

このビジネス課題に対処するために、会社Xは表12-1のコンポーネントを使用するビジネス・ソリューションを設計します。

表12-1 ビジネス・ソリューションを提供するコンポーネント

コンポーネント

このコンポーネントがビジネス課題に対処する方法

コンポーネントの説明

プロセス分析

プロセス分析測定とビジネス・インジケータは、BPELプロセスのアクティビティで定義されます。

プロセス分析により、BPELプロセスの分散データを収集するための共通測定メカニズムが提供されます。

Oracle BAM

SOAコンポジットが分析測定とビジネス・インジケータで構成されているとき、コンポジットのデプロイ時に、コンポジット固有の物理および論理データ・オブジェクトがOracle BAMで自動的に作成されます。Oracle BAM Composerを使用して、これらの分析のダッシュボードを作成し、顧客注文リクエストへのビジネス・インサイトを得ます。

Oracle BAMは、ビジネス・プロセスをリアルタイムでモニターし、情報に基づく戦略的なビジネスの意思決定を支援します。

この章の後続の項では、表12-1のコンポーネントを使用して、ビジネス・インサイトの課題に対処する方法について、より詳細に説明します。

- コンポジットへのビジネス・インジケータと測定の追加

- Oracle BAMダッシュボードでのビジネス・インサイトの取得

12.2.1 コンポジットへのビジネス・インジケータと測定の追加

Oracle SOA Suiteは、BPELプロセス、Oracle BPMおよびヒューマン・ワークフローなどのコンポーネントにおいて共通プロセス・スキーマを提供します。Oracle BAMは、Oracle BAMサーバーで保持されるデータ・オブジェクトとしてこのスキーマをモデリングします。これらのデータ・オブジェクトは、事前シードされ、自動的にプロセスによって移入されます。

Oracle SOA Suiteにはプロセス分析と呼ばれる機能があります。この機能を使用して、会社Xは、BPELプロセスのアクティビティで、ビジネス・インジケータや測定などのユーザー・メトリックを指定できます。コンポジットがデプロイされると、対応するカスタム導出データ・オブジェクトがOracle BAMで作成および更新されます。

会社Xは、ユーザー・メトリックスを指定するBPELプロセスをOracle JDeveloperで開き(このシナリオの場合、CCComposite)、分析ビューに変更アイコンをクリックします(図12-1を参照)。これにより、分析ビューのプロセスが開きます。分析ビューにより、BPELプロセスでビジネス・インジケータおよび測定を定義できます。

図12-1 BPELプロセスの分析ビュー

- ビジネス・インジケータは、「構造」ウィンドウで定義され、次のタイプで構成されています。

- カウンタ: プロセス・インスタンスがBPELアクティビティなどのマーク済要素を完了した回数を追跡します。

- ディメンション: グループをラベルしたりメジャーをフィルタします。

- メジャー: 売上金額や従業員の給料などの変数の値を格納します。
図12-2に、「構造」ウィンドウ内の定義済ビジネス・インジケータを示します。

図12-2 「構造」ウィンドウで定義されたビジネス・インジケータ

- 測定が「コンポーネント」ウィンドウに表示され、構成用にアクティビティ上にドラッグ・アンド・ドロップされます。使用可能なタイプは次のとおりです。

- カウンタ・マーク: カウンタ・マークが取得されるBPELアクティビティ。このBPELプロセスでは、会社Xは、手動の承認数、自動の承認数および却下された注文数を追跡するためのカウンタ・マークを定義します。

- 間隔の開始: 間隔が開始するBPELアクティビティ。

- 間隔の停止: 間隔が終了するBPELアクティビティ。

- 単一マーク: 単一マークが取得されるBPELアクティビティ。

図12-3に詳細を示します。「コンポーネント」ウィンドウから適切なBEPLアクティビティ上にドラッグして構成された測定は、テキスト注釈で示されます。定義済ビジネス・インジケータは、「構造」ウィンドウに表示されます。

図12-3 定義済ビジネス・インジケータおよび測定分析を含むBPELプロセス

SOAコンポジットが分析測定とビジネス・インジケータで構成されているとき、コンポジットのデプロイ時に、コンポジット固有の物理および論理データ・オブジェクトがOracle BAMで自動的に作成されます。このようなコンポジット固有のデータ・オブジェクトには、ビジネス・インジケータ用の列があり、そのコンポジットのプロセスに対応する分析情報が含まれています。

12.2.2 Oracle BAMダッシュボードでのビジネス・インサイトの取得

会社Xは、処理注文リクエストを開始するコンポジットをデプロイします。

会社XがSOAコンポジット・アプリケーションでビジネス・インジケータと測定を指定する場合に、コンポジットがデプロイされると、対応するカスタム導出データ・オブジェクトがOracle BAMで作成および更新されます。Oracle BAMデータ・オブジェクトには、コンポジットで定義された測定ごとの適切な分析が含まれています。

会社Xは、Oracle BAM Composerにログインし、Oracle BAM Composerで、クレジット・カード処理という新規のプロジェクトを作成します。作成時に、デプロイ済CCCompositeコンポジットに対応するアクティビティ・データ・オブジェクトをこのプロジェクトに追加します(図12-4を参照)。このようなコンポジット固有のデータ・オブジェクトには、ビジネス・インジケータ用の列があり、そのSOAコンポジットのプロセスに対応する分析情報が含まれています。

図12-4 アクティビティ・データ・オブジェクトの選択

会社Xは、プロジェクトのクレジット・カード処理という表示名でダッシュボードを作成します。Oracle BAMには、Oracle BPM SuiteとOracle SOA Suiteのすべての主要コンポーネントのための、即時利用可能な一連の豊富なダッシュボードが備えられています。これらのダッシュボードには、タスクのキュー深度やビジネス・プロセスのボトルネック分析などのメトリックが含まれています。

会社Xは、承認、受信および却下されたアプリケーションを月別に表示するための3つの異なるカウンタのある棒グラフを設計します。

- 月別アプリケーションのステータスという表示名

- 会社XがOracle JDeveloperのCCCompositeコンポジットで設計した測定とディメンションでモデリングされるビジネス・ビュー問合せ。

- /oracle/processanalytics/CCComposite Activityのデータ・オブジェクト。

- APPROVE_COUNTER BIのカウンタ(表示名は、「承認済」に変更されます)。

- RCV_COUNTER BIのカウンタ(表示名は、「受信済」に変更されます)。

- REJECT_COUNTER BIのカウンタ(表示名は、「却下済」に変更されます)。

- 1か月の時間ディメンション

図12-5に詳細を示します。

図12-5 承認、受信および却下されたアプリケーションを月別に表示するための棒グラフ

会社Xは、州別の手動および自動の承認数を追跡するための2番目の棒グラフを設計します。

- 州別の承認という表示名

- 会社XがOracle JDeveloperのCCCompositeコンポジットで作成した測定とディメンションでモデリングされるビジネス・ビュー問合せ

- /oracle/processanalytics/CCComposite Activityのデータ・オブジェクト

- AUTOMATIC_COUNTER BIのカウンタ(表示名は、「自動」に変更されます)

- MANUAL_COUNTER BIのカウンタ(表示名は、「手動」に変更されます)

- 州に基づくディメンション

図12-6に詳細を示します。

図12-6 州別の自動および手動の承認数を追跡するための2番目の棒グラフ

会社Xは、「月別アプリケーション・ステータス」グラフの右に、様々な理由により却下されたアプリケーションの数を追跡する円グラフを設計します。

- 理由別の却下されたアプリケーションという表示名

- 会社XがOracle JDeveloperのCCCompositeコンポジットで作成した測定とディメンションでモデリングされるビジネス・ビュー問合せ

- /oracle/processanalytics/CCComposite Activityのデータ・オブジェクト

- REJECT_COUNTER BIのカウンタ(表示名は、「却下済」に変更されます)

- 理由別の却下に設定されるディメンション(基準に達しない年齢、信用または収入)

- 円グラフの場合、「テキスト・タイプ」はテキストとパーセンテージに設定される

図12-7に詳細を示します。

図12-7 様々な理由により却下されたアプリケーション数を追跡する円グラフ

完了後、ダッシュボード全体は図12-8のようになります。

図12-8 Oracle BAMダッシュボード

12.3 関連ドキュメント

表12-2では、この章で説明したコンポーネントと機能をより詳しく説明するドキュメントの参照先を示します。

表12-2 関連ドキュメント

参照内容

参照先

プロセス分析の作成

『Oracle SOA SuiteでのSOAアプリケーションの開発』のBPELプロセス分析の構成に関する項

Oracle BAMダッシュボードの設計

Oracle BAMによるビジネス・アクティビティのモニタリングのプロジェクトの計画および作成に関する項

Oracle BAMによるビジネス・アクティビティのモニタリングのダッシュボードの作成に関する項

Oracle BAMによるビジネス・アクティビティのモニタリングのビジネス問合せの作成に関する項

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。