著者：Ron Batra（2008年3月）

はじめに/対象範囲

Oracle SOA Suiteを使用して、エンタープライズ・アプリケーション・フレームワークにOracle E-Business Suiteの大規模なA2A（アプリケーション間）統合を実行する場合、サブケースとして公開サービス（おもにOracle Project Accountingとそのほかのデータ要素）を考慮してみましょう。 公開サービスでは、Oracle Enterprise Service Bus（Oracle ESB）データ要素が公開され、公開されたデータ要素は5つのアプリケーションによってサブスクライブされます。 この記事では、イベント駆動型アーキテクチャで生成されたメッセージをチューニングする継続的なプロセスについて重点的に説明します。 図1は、アーキテクチャの概念図です。 この記事ではメッセージ・サイズについて重点的に説明し、サービスの起動やアダプタの選択などの関連トピックについては詳細に説明していません。

イベント駆動型アーキテクチャとメッセージング

イベント駆動型アーキテクチャでは、データ要素の変更は、Oracle ESBフレームワークを通じてリアルタイム/ほぼリアルタイムで転送されます。 こうしたデータ変更は、メッセージに変換されてOracle ESBに公開されます。 旧式のファイル転送を使用した統合方法では、差分トランザクションが単純に収集されてファイルに書き込まれ、このファイルがターゲット・システムに転送されます。 ほとんどの場合、ファイル・サイズは問題にはなりません。 イベント駆動型アーキテクチャとOracle ESBフレームワークでは、メッセージ・サイズとメッセージ容量が設計時の主要な決定事項の1つとなります。 たいていの場合、ビジネス・イベントは変更できないため、メッセージ・サイズとスループットの調整に重点が置かれます。 この調整をうまくおこなうには、データのカーディナリティとアフィニティを厳密に調査して最終設計に実装する必要があります。

統合設計パターンの検討

N+のエンタープライズ・アプリケーションを統合する本シナリオでは、正規化モデルの設計パターンの採用が効果的です。正規化モデルの設計パターンでは、新規サブスクライバを動的に追加し、ドメイン値をマッピングできます。 ここでは、公開サービスを設計しつつ、5つのサブスクリプション・サービスを起動します。サブスクリプション・サービスの数は、コードを大幅に修正することなく動的に変更できます。 通常、正規化モデルの設計に時間を先行投資して、サービスの設計を推進するビジネス要件の厳密な検証をおこなうことは有意義であるといえます。

Oracle E-Business Suiteの統合リポジトリ

http://irep.oracle.comで更新されるOracle Integration Repositoryは、Oracle E-Business Suiteの各製品ファミリーで使用できる統合方法のリストで、もっとも一般的な選択肢（コンカレント・プログラム、EDI、インタフェース・ビュー、Java、オープン・インタフェース、PL/SQL、Webサービス、およびXML Gatewayマップ）が掲載されています。 Oracle ESBフレームワークのアウトバウンド・インタフェース（Oracle ESBへの公開）という今回のケースでは、ビジネス要件に対応するため、さまざま製品ファミリーからデータを抽出して1つの大きなメッセージに結合することが必要でした。 そのため、本項で後ほど説明するビューとトリガーのシステムを開発することを選択しました。

公開されるデータ要素

公開サービスの設計は、サブスクライバ要件に大きく左右されます。 ただし、将来分析や将来のデータ・ニーズの予測を実施しておけば、通常、将来の公開サービスの再設計が不要になるという見返りがあります。 今回のケースでは、Oracle Human Resources（Oracle HR）、Oracle General Ledger（Oracle GL）、Oracle Purchasing（Oracle PO）、Oracle Project Accountingのデータ要素を1つの大きなメッセージに結合して、そのメッセージをOracle ESBに公開することが必要でした。

表1： データ要素一覧

設計方法1： 複雑なSQLビューとステージング表

設計の第1弾では、ビュー、PL/SQLプログラム単位、4つのステージング表の間に作成された親子関係構造を組み合わせて使用しました。 表5では、プロジェクトIDフィールドに基づいたデータセットの取得が必要です。 また、この問合せでは、4つの表の間の親子関係を全結果セットにナビゲートする必要があります。 アダプタ・コードのトレースに（バインド変数にさえ）多数のフェッチが見られたため、効率化の余地があることは明らかでした。 データベースへのSQLコールのトレースは、Oracleデータベースの従来のトレーシング方法を使用して実施しました。

ここでのおもなポイントは、アダプタ・コードで実行が必要な結合の数です。これは、XMLメッセージに変換される結果セットを結合するために実行されます。 これにより、SQL経過時間と実際の実行時間とに大きな差が生じます。 Oracle Application ServerとOracle Database Serverが別の場所に設置されており、ネットワーク待機時間が全公開メッセージに影響を与える場合は、この差がさらに拡大する可能性があります。 今回のケースでは、平均メッセージ・サイズは54 KBであり、1日あたりの平均メッセージ数は1万でした。

設計方法2： GROUP BY句の追加

第2弾では、差分トランザクション・ビューのSQLを変更して、GROUP BY句を追加しました。 その目的は、コスト・トランザクション表に移入されるトランザクション数の削減です。 メッセージ・サイズは約40 KBに縮小され、1日あたりの平均メッセージ数は約1万5千となりました。

設計方法3： ロジックの簡素化による表構造のフラット化

再帰SQLと親子関係による結合を削減するため、プロジェクトIDと日付によって参照されるデータ要素をフラット化（原則として非正規化）することにしました。 一時表では、表1にIDの存在しないレコードのみが作成されます。Oracle ESBへのメッセージ公開後は、一時表に同じデータ要素を保存する必要はなくなり、Oracle ESBキューとその永続性によりパブリッシャのデータ消費が管理されます。

メッセージ・サイズは14 KBに縮小され、メッセージ数は増加し、2時間で5万のメッセージを処理できるようになりました。 これで、処理時間の許容範囲内に十分収まりました。

メッセージ・サイズの決定

メッセージ・サイズの決定時には、2つの測定値を組み合わせて使用しました。 Oracle ESB環境では、メッセージはデータ要素とXML構造（タグ）の組合せにより構成されます。 データ要素のサイズは、データ取得元の表から計算し（例：VARCHAR2(60) + DATE + NUMBER）、データ要素の最大値を取得して、それを上限値と見なすことができます。 こうして得られたバイト数に、データ・マッピング関連のXMLタグのサイズを追加しました。 XMLはテキストのため、これは比較的簡単です。 ただし、この数値はあくまで見積値であり、Oracle ESBでの処理の実際値ではありません。転送方法やプロトコルによっては、メッセージにオーバーヘッドの追加が生じる場合があります。

結論

メッセージのチューニングは、データ抽出レイヤーから開始できます。 データセットや関連アフィニティの複雑さによっては、公開サービスで従来のSQLチューニング方法を使用して、アダプタ経由で十分なメッセージのスループットを確保できます。 統合環境やエンドポイント数によっては、サイズの小さいメッセージから成る大量のメッセージを、サイズの大きいメッセージから成る少量のメッセージよりも高速で処理できる場合があります。 メッセージ・サイズは、イベント駆動型アーキテクチャの重要な要素です。

著者：Ron Batra、Saumitra Chattopadhyay（2008年9月）

概要

エラー処理フレームワークは、エンタープライズ・レベルのサービス指向アーキテクチャ（SOA）統合プロジェクトを成功させるためには不可欠です。 この記事では、Oracle Business Process Execution Language（Oracle BPEL）とOracle Business Activity Monitoring（Oracle BAM）の2つのツールを使用して、リアルタイム・ダッシュボード、エラー処理、およびアラートを統合するフレームワークの開発方法について説明します。

こうした一般的なエラー処理フレームワークは、Oracle BPELとOracle Enterprise Service Busを使用して開発されたサービスやインタフェースに加え、ほかのツールを使用して開発されたOracle E-Business Suiteの拡張機能の監査とエラー報告にも使用できます。 監査コンポーネントを使用すれば、社員はインタフェースやそのほかのサービスの実行履歴を迅速に確認できます。 エラー管理コンポーネントを使用すれば、ユーザーはOracle BPEL/Oracle ESBフレームワークやそのほかのサービスによって報告されたエラーを確認できます。

方法

例外フレームワークは、Oracle BPEL/Oracle ESBサービスやOracle BPEL以外のサービスで使用される複数のOracle BAMオブジェクトから構成されます。 そのため、各Oracle BPELサービスでコードを再利用して、一貫した監査情報、エラー、および基本レポート・データをレポートできます。 また、定義済みの各Oracle BAMオブジェクトには、Webサービスとして公開されたOracle BPEL/Oracle ESBサービスも含まれているため、Oracle BPEL/Oracle ESB以外のプロセスを使用して監査情報とエラー情報をフレームワークにレポートできます。
さらにこのフレームワークでは、エラーが発生すると、該当ロールに通知が送信されます。 Oracle BAMレポートとダッシュボードにはさまざまな機能が組み込まれており、認証/認可を受けた適切な権限をもつユーザーのみがこの機能にアクセスできるようになっています。

設計の前提条件

このソリューションは、次の前提条件に基づいて設計されています。
· Oracle BPELサービスのすべてにおいて、エラー情報や監査情報は、本仕様の一部として定義されたOracle BAMオブジェクトを使用してフレームワークに送信されます。
· Oracle BPEL以外のアプリケーションのプロセスでフレームワークにエラーを送信する場合は、次の2つの方法があります。
a. XMLペイロードを使用して標準SOAP Webサービスをコールし、データを送信します。
b. 中央の表に監査情報とエラー情報を書き込みます。この情報は、Oracle Enterprise Linkにより、Oracle BAMダッシュボードと同期化されます。
· 電子メール通知は、エラー発生時に送信されます。 通知の連絡先情報は、Oracle BAMスキーマに保存されます。 エラー・タイプごとに、1つまたは複数の連絡先を設定できます。
· 詳細エラー表は、別のスキーマに作成されます。 この表には、インタフェースによって生成されたエラーの詳細が保存されます。
· Oracle BPEL以外のツールを使用して開発したインタフェースと拡張機能は、中央の例外表に移入されます。 これは、大規模なOracle E-Business Suiteの開発コンポーネントを使用するプロジェクトでは重要です。
· Oracle BPELプロセスのエラーは、Oracle BAMでセンサーにより取得されます。
· Oracle BPELプロセスのエラーは、中央のエラー表に取得されます。
· エラー表のデータは、Oracle Enterprise Linkを使用してOracle BAMに送信されます。
· エラー・レポートは、Oracle BAMダッシュボード経由でリアルタイムに公開されます。
· エラーの電子メール通知は、Oracle BAMアラート経由で送信されます。

アーキテクチャの概念図

図1： Oracle BPEL/Oracle BAMをエラー処理フレームワークに統合するアーキテクチャの概念図

Oracle BPELプロセスのエラー・シナリオ

すべての状況で、Oracle BPELサービス/プロセスのエラーは、提供されたOracle BAMオブジェクトを使用してフレームワークにレポートされます。 Oracle BPELプロセス環境では、発生するエラーは大きく次の3つに分類されます。

1. アダプタのエラー： アダプタ・フレームワーク自体により発生するエラーです。 エラーの処理方法は、インタラクションがインバウンドかアウトバウンドかによって異なります。 いずれの場合でも、このエラーが発生すると、センサーを使用してOracle BPELからOracle BAMにエラー・メッセージが送信されます。

2. Oracle BPELプロセスのエラー： Oracle BPELプロセスで発生するエラーは、次の2つのタイプに分類されます。

テクニカル・エラー： アクティビティの実行時にエラーが発生することがあります。 このエラーは組込みのtry/catchメカニズムにより直接検出し、Oracle BAMの標準センサー技術を使用してレポートできます。
ビジネス・プロセスのエラー： Partnerlinkでビジネス・プロセスのエラー（個人のクレジット・チェックが実行できない場合など）が発生することがあります。 このエラーは、Oracle BPELプロセスで検出し、センサーを使用してOracle BAMにレポートできます。

Oracle BPELプロセスのコールでは、データをOracle BAMセンサーに渡す前に、関連エラー情報をすべて収集しておく必要があります。

3. Oracle BPEL以外のプロセスのエラー：

いずれの統合プロジェクトでも、エンド・アプリケーションに大量のサービスを開発する必要があり、開発したサービスはOracle BPELからWebサービスとして起動できるようにする必要があります。 こうしたサービスは、そのアプリケーションのコア・テクノロジーを使用して開発します。 たとえば、Oracle E-Business Suiteをほかのアプリケーションと統合する場合は、PL/SQLとスケジューラ（Oracle Concurrent Manager）を使用してサービスを開発する必要があります。 同時プロセス内のエラーは、Oracle BAMオブジェクトを直接操作できません。 そのため、同時プロセス（PL/SQL）コードを使用して、次の2つの方法のうちのいずれかを実行することになります。
· XMLペイロードを使用して標準SOAP Webサービスをコールし、データを送信します。
· 中央の表に監査情報とエラー情報を書き込みます。この情報は、Oracle Enterprise Linkにより、Oracle BAMダッシュボードと同期化されます。

Oracle BPELプロセスの監査シナリオ

インタフェースの監査情報の取得は、パフォーマンス/ロード/停止時間の統計情報を作成し、一部の環境を規制するために非常に重要です。
一般に、ユーザーの関心事項は次のとおりです。
a. 日次/週次/月次のインタフェースの最小/最大/平均トランザクション数
b. インタフェースのピーク時間
c. 日次/月次の失敗トランザクション数
d. インタフェースの最小/最大/平均処理時間

監査情報は、Oracle BPELプロセスでセンサーを使用して取得できます。 少なくとも、フロー開始時に1つ、フロー終了時に1つの、合計2つのセンサーが必要です。 監査情報は、このほかにも、Oracle BPEL プロセス内のほかの主要アクティビティから取得できます。

Oracle BPELプロセスのレポート・シナリオ

エラー情報と監査情報のほかにユーザーが関心をもつ事項は、インタフェースで処理されるビジネス・データに基づいたレポートの表示です。 たとえば購買インタフェースでは、1日に承認された最大PO額と、承認/却下された合計PO額がユーザーの関心事項でしょう。
こうしたレポートを取得するには、センサーを使用して、Oracle BPELアクティビティからレポート・オブジェクトにビジネス・データを取得する必要があります。

エラーの修正と再送信

エラーのアラート/通知を受信したら、エンド・アプリケーションからメッセージを再送信するのではなく、インタフェース表でデータを修正して、ミドルウェアからそのプロセスを再送信したいと考えるユーザーも存在するでしょう。 たとえば、顧客から送信されたEDI850（インバウンド販売注文）について、システムのデータ問題により、ERPシステムで注文が作成されなかった場合を考えてみましょう。 この場合、顧客に同じドキュメントの再送信を要求できない可能性があります。 我々のシナリオでは、ユーザーがインタフェースのステージング表でエラー・レコードの問合せ、エラーの分析、エラーの修正（必要な場合）をおこない、最後にそのプロセスを再送信できる修正プロセスが必要です。

ほとんどのERPアプリケーションでは、インバウンド・データが実表にインポートされる前にインタフェース表に保存されます。 そうでない場合は、ステージング表とインタフェース表をミドルウェア・データベース・サーバーに作成できます。 いずれの場合にも、エラー・トランザクションはインタフェース表で'エラー'としてフラグ付けされます。 また、Oracle BPELインスタンスIDもインタフェース表に保存されるため、エラー表とインタフェース表のレコードをリンクできます。

作成する修正フォームでは、次の機能を使用できます。
· ユーザーは、一意のビジネス文書番号（注文番号など）やOracle BPELインスタンスIDを使用して、レコードに問合せを実行できます。
· レコードは、エラーの詳細説明と一緒にフォーム内に表示されます。
· 更新可能フィールドをユーザーが修正できます。
· ユーザーは最後にトランザクションを再送信できます。
· フォームからOracle BPELのResubmit APIをコールして、古いインスタンスを再送信できます。
· または、新規Oracle BPELインスタンスを起動できます。

結論

Oracle BAM Active Studioは、レポートを作成して配信する堅牢なWebベースのレポート・ツールです。 パワー・ユーザーは、Oracle BAM Active Studioからほかのユーザーとレポートを共有して、レポート配信のアラートを電子メールで作成できます。 レポートは、画面上でデータがライブ更新されるリアルタイム・レポートか、ポイント・イン・タイム・レポートのいずれかを使用できます。 また、Oracle BAMダッシュボードをエンタープライズ・ポータルとリンクすることもできます。

Oracle BPELは、センサーを使用して、Oracle BAMとリアルタイムで統合できます。 Oracle BPELとOracle BAMの機能を組み合わせて使用することにより、複数の用途に適った効率的でユーザー・フレンドリーな統合フレームワークを構築できます。