| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Integration > WebLogic Integration ソリューションの設計 > 統合ソリューションの設計 |
|
WebLogic Integration ソリューションの設計
|
統合ソリューションの設計
統合スペシャリストは、要件定義の段階で収集したデータに基づいて WebLogic Integration 環境の統合ソリューションを設計します。統合スペシャリストは、ビジネスおよび技術的な要件を WebLogic Integration のアーキテクチャにマッピングする方法と、利用可能な WebLogic Integration のアーキテクチャと機能を最大限に利用する統合ソリューションの設計方法を知らなければなりません。
以下の節では、統合プロジェクトのソリューションを設計するときに考慮する事項について説明します。最後の節では、それらの事項がどのようにサンプル WebLogic Integration アプリケーションの高度な設計の指定と関連するのかを示します。
WebLogic Integration のアーキテクチャについて
統合ソリューションを設計する前に、統合スペシャリストは WebLogic Integration のアーキテクチャを理解する必要があります。WebLogic Integration アーキテクチャの概要については、『WebLogic Integration 入門』の「E ビジネス統合への道」を参照してください。
特に、以下の WebLogic Integration コンポーネントを理解することが重要です。
統合ソリューション トポロジの WebLogic Integration へのマッピング
WebLogic Integration のアーキテクチャを理解することで、統合スペシャリストは要件で指定した統合トポロジを適切な WebLogic Integration の機能にマッピングできます。統合スペシャリストは、以下の事項がどのように実装されるのかを確認する必要があります。
ネットワーク トポロジと管理統制のスコープの定義
地理的に分散した WAN を使用している企業では、別々の場所には別々のドメインがある場合があります。たとえば、本社がニューヨークにあり、出張所がロンドンと東京にある企業では、ドメインが 3 つに分かれている場合があります。
設計方法はドメイン管理のタイプによって決まるので、WebLogic Integration ソリューションを設計するときには、それらの場所がどのように管理されるのかを理解することが重要です。
ドメインは、以下の方法で管理できます。
人間ユーザの会話の定義
WebLogic Integration では、以下の 2 種類の人間ユーザの会話がサポートされます。
人間ユーザに関する統合ソリューション要件の定義の詳細については、人間ユーザ を参照してください。
Worklist ユーザ
注意: Worklist クライアントは WebLogic Integration リリース 7.0 より非推奨となりました。代替機能に関する詳細については、『WebLogic Integration リリース ノート』を参照してください。
Worklist ユーザには、ビジネス プロセスによって直接作業が割り当てられます。このようにタスクの割り当てられたユーザは、ビジネス プロセスと密接に関わります。WebLogic Integration では、Worklist というクライアント アプリケーションを使用してユーザにタスクを割り当てることができます。Worklist を使用して、タスクはユーザまたはロールに割り当てることができます。ロールとは指定されたユーザのグループのエリアスのことであり、そのロールのユーザはすべて、ロールに割り当てられたタスクを実行できます。Worklist では、タスクの割り当てられたユーザがそのタスクを実行してからプロセスが継続されるように指定することもできます。Worklist ユーザは、以下のタイプの Worklist クライアントのいずれかを使用して WebLogic Integration と会話します。
JSP ベースのクライアントとコマンドライン クライアントについては、サンプル コードが WLIHome/samples/bpm_api ディレクトリに用意されています。 カスタム Worklist クライアントの開発については、『BPM クライアント アプリケーション プログラミング ガイド』を参照してください。 クライアント ユーザ クライアント ユーザは、プロセスの一部であるアプリケーションを使用してビジネス プロセスと間接的に会話します。たとえば、販売担当者は JSP ベースのアプリケーションにログインし、販売注文を作成して（注文を処理するワークフローが開始される）、電子メールの確認を受信できます。 クライアント ユーザは、3 種類のメッセージ（以下の節を参照）のいずれかを使用してメッセージ ベースの非同期交換を通じて BPM と会話します。
メールボックス ベースのメッセージ
WebLogic Integration では、B2B Integration で、データベース ベースのメールボックスを通じて BPM プロセスと会話する HTML ベースの Zeroweight Client が提供されます。ブラウザ クライアントによってメールボックスに配置された XML メッセージは、WebLogic Integration プロセス エンジンに送信されます。WebLogic Integration プロセス エンジンによってメールボックスに配置された XML メッセージは、ブラウザ クライアントで読むことができます。ブラウザ クライアントがメールボックスと会話できるようにする JSP タグのライブラリも用意されています。ブラウザ クライアントでは、XML メッセージを処理しなければなりません。詳細については、次の URL で「Zeroweight Client の使用」を参照してください。
http://edocs.beasys.co.jp/e-docs/wli/docs70/interm/b2bhome.htm
注意: WebLogic Integration リリース 7.0 より、このセクションで説明する、Trading Partner Zeroweight Client、B2B Mail Box、B2B JSP ブラウザ タグ ライブラリ機能は非推奨になりました。代替機能の詳細については、『WebLogic Integration リリース ノート』を参照してください。
電子メール メッセージ
WebLogic Integration プロセス エンジンでは、フリー テキストまたは XML データの含まれる電子メール メッセージを送信できます。詳細については、『WebLogic Integration Studio ユーザーズ ガイド』の「アクションの定義」の「電子メール メッセージの送信」を参照してください。電子メールで XML メッセージを受信し、それを BPM プロセス（WebLogic Integration Studio の開始/イベント ノードおよびイベント ノードで表される BPM プロセスなど）に転送するアダプタを作成することもできます。
EIS アプリケーションとの統合
WebLogic Integration では、EIS アプリケーションと統合するためのメカニズムが複数用意されています。以下の節では、それらのメカニズムについて説明します。
方法は、各アプリケーションで個別に選ぶ必要があります。できる限り、EIS アプリケーションは LAN 経由で WebLogic Integration に接続するべきです。EIS アプリケーション統合の統合要件の定義については、アプリケーション統合−アプリケーション統合で使用するエンタープライズ情報システム（EIS）アプリケーション を参照してください。
Application Integrationアダプタ
WebLogic Integration と外部の EIS アプリケーションを統合する最も一般的な方法は、Application Integration アダプタを使用することです。統合する EIS によっては、既製のアダプタが販売されています。カスタム アダプタを開発することも可能です。以下の節では、Application Integration アダプタの利点について説明します。
Application Integration アダプタの詳細については、次の URL にある『Enterprise Application Integration (EAI): Providing Stability in the Whirlwind of E-Commerce』を参照してください。
http://www.bea.com/products/elink/EAI_business_wp.shtml
実際的な機能
Application Integration アダプタは J2EE コネクタ アーキテクチャ（J2EE-CA）に基づいているので、接続管理、トランザクション管理、セキュリティ管理といった実際的な機能を備えています。WebLogic Server によって提供される基盤の J2EE CA エンジンでは、それらの機能がサポートされます。
主な利点は接続のプールです。EIS アプリケーションへの接続は、場合によっては高コストのリソースとなります。WebLogic Integration の接続プール機能を利用すると、そのリソースを多数の WebLogic Integration 要求で共有できます。
汎用性
Application Integration アダプタは、統合要件に合わせてコンフィグレーションされる汎用的なアダプタです。アダプタは、ブラウザを通じてコンフィグレーションします。したがって、開発者でなくてもアダプタをコンフィグレーションできます。コンフィグレーションは、開発者ではなく、統合するアプリケーションの実行に精通している人に委ねるのが適切です。この汎用的なアダプタの設計では、動的な統合環境もサポートされます。
ビジネスレベル インタフェース
サービス アダプタおよびイベント アダプタによって WebLogic Integration プロセス エンジンに提示されるインタフェースは、EIS アプリケーション固有の API 呼び出しではなくビジネスレベル インタフェースです（create_new_customer など）。このため、BPM プロセスの設計者は API を介してプログラム的にアプリケーションと統合する仕組みではなくプロセスの機能に集中することができます。
アプリケーション統合のすべてのサービス メッセージとイベント メッセージは、WebLogic Integration リポジトリの XSD として定義します。
BPM との統合
BPM と Application Integration の機能は、設計時と実行時の両方で直接統合されます。ワークフローを構築するワークフロー設計者は、アプリケーション統合のイベントとサービスを WebLogic Integration Studio で表示できます。
Application Development Kit
WebLogic Integration には、アプリケーション統合のサービス アダプタとイベント アダプタを開発するための Application Development Kit（ADK）があります。詳細については、『アダプタの開発』を参照してください。
他の統合テクニック
EIS アプリケーションの他の統合テクニックには以下のものがあります。
BPM ビジネス オペレーション
WebLogic Integration ソリューションでは、WebLogic Integration プロセス エンジンから始まった要求/応答モデルを BPM ビジネス オペレーションを使用して実装できます。ビジネス オペレーションを使用して、開発者は統合ソリューションで使用される EIS アプリケーション インタフェースをラップする EJB クラスまたは Java クラスを作成します。ビジネス オペレーションを利用すると、この EJB クラスまたは Java クラスは WebLogic Integration プロセス エンジンと統合し、ワークフローから呼び出すことができます。統合スペシャリストは、ビジネス オペレーションを使用して WebLogic Integration プロセス エンジンから EIS を同期的に呼び出します。
JMS ラッパー
WebLogic Integration ソリューションでは、JMS ラッパーを使用して非同期統合モデルを実装できます。開発者は、EIS アプリケーションから WebLogic Integration に（またはその逆方向で）メッセージを送信できる JMS ラッパーを作成できます。それらのメッセージは、以下のいずれかのフォーマットで作成できます。
統合スペシャリストは、JMS ラッパーを使用して WebLogic Integration プロセス エンジンから EIS を非同期で呼び出します。
カスタム アプリケーション統合ソリューションの開発
EIS アプリケーションとの統合を実現する最も簡単な方法は、既製の Application Integration アダプタを購入することです。ただし、カスタム アプリケーションで使用できるそのようなアダプタがない場合は、カスタム統合ソリューションを開発する必要があります。統合スペシャリストは、Application Integration アダプタ、ビジネス オペレーション、または JMS ラッパーのどれを開発するのかを決める必要があります。
既製の Application Integration アダプタを使用する欠点は、カスタムの統合よりも多くの開発作業を要する場合があることです。Application Integration アダプタの設計モデルは、開発者が一度アダプタをビルドし、それを多くの統合環境で利用できるようにするというものです。これは、商用の既製アダプタを開発するのに最適なモデルと言えます。
ただし、EIS アプリケーションの統合要件が単純で変化しない場合（たとえば、変更されることのない 2 つの API メソッドのみを呼び出すようにアプリケーションが設計されている場合）は、ビジネス オペレーションまたは JMS ラッパーを使用する方が開発作業が少なくて済みます。
データベースの統合−サンプルの Application Integration データベース アダプタ
WebLogic Integration では、統合ソリューションで使用できるサンプルの Application Integration データベース アダプタのソース コードが提供されます。このアダプタではサービスとイベントの両方がサポートされます。
必要に応じてソース コードを拡張することもできます。詳細については、『アダプタの開発』の「DBMS アダプタ」を参照してください。
ファイルと FTP の統合−サンプルのアプリケーション統合バイナリ ファイル アダプタ
サンプルのアプリケーション統合バイナリ ファイル アダプタのソース コードは、次の URL の BEA dev2dev Online で提供されています。
http://dev2dev.bea.com/index.jsp
このサンプル アダプタではサービスとイベントの両方がサポートされます。
他の WebLogic Integration クラスタとの統合
ネットワーク トポロジと管理統制のスコープの定義で説明されているように、企業内では他の管理ドメイン（外国のオフィスなど）との統合が必要な場合があります。それらのドメインが一元的に管理されており、WAN 経由で統合ソリューションから認識できる場合は、WebLogic Integration クラスタを各サイトにインストールし、WebLogic Integration でそれらの通信を調整できます。
この場合、各 WebLogic Integration クラスタは個別に扱う必要があります（ビジネス プロセスをローカルの WebLogic Integration クラスタの要件に合わせてカスタマイズする）。WebLogic Integration クラスタのビジネス プロセスは、交換される XML メッセージを使用して統合します。それらの XML メッセージを定義する DTD または XSD は、各 WebLogic Integration クラスタの WebLogic Integration リポジトリに格納します。
WebLogic Integration クラスタの詳細については、『WebLogic Integration ソリューションのデプロイメント』の「WebLogic Integration クラスタについて」を参照してください。
統合オプション
WebLogic Integration クラスタは、WebLogic Integration の以下の機能を使用して統合できます。
注意: XOCP ビジネス プロトコルは、WebLogic Integration の本リリースより非推奨になりました。代替機能に関する詳細については、『WebLogic Integration リリース ノート』を参照してください。
http://dev2dev.bea.com/index.jsp
統合サンプル
ある企業で、営業本部がニューヨークにあり、地域別の倉庫が世界中にあるグローバルな流通システムが運営されているとします。ニューヨークのオフィスでは注文管理システムが使用され、各倉庫では流通アプリケーションが実行されます。それぞれの場所では、WebLogic Integration クラスタが実行されています。
この場合、注文管理アプリケーションは注文を受け、どの地域でその注文に対応すべきかを判断し、その地域に通知します。各地域では、ワークフローで要求を処理し、応答を注文管理システムに送り返すことができます。
企業内の他のドメインとの統合
企業内では、統合ソリューションの管理が及ばない、または統合ソリューションから見ることのできない他の管理ドメイン（外国のオフィスなど）との統合が必要な場合もあります。そのような他のドメインでは、それら独自の統合要件として WebLogic Integration が使用される場合も、使用されない場合もあります。
WebLogic Integration ドメインは、WebLogic Integration の以下の機能を使用して統合できます。
注意: XOCP ビジネス プロトコルは、WebLogic Integration の本リリースより非推奨になりました。代替機能に関する詳細については、『WebLogic Integration リリース ノート』を参照してください。
http://dev2dev.bea.com/index.jsp
BEA TUXEDO および BEA eLink との統合
WebLogic Integration ソリューションでは、WebLogic Server に既にデプロイされている以下のアプリケーションを統合できます。
http://edocs.beasys.co.jp/e-docs/wls/docs70/wtc.html
http://edocs.bea.com/elink/index.html
外部トレーディング パートナとの統合
外部のトレーディング パートナと統合する最も一般的な方法は、B2B 統合ソリューションを開発することです。以下の節では、WebLogic Integration が提供する B2B Integration の機能の基本事項について説明します。
B2B 統合のアーキテクチャ
B2B 統合ソリューションのアーキテクチャは、それがバリュー チェーン統合（ピア ツー ピア コンフィグレーション）であるのか、それとも B2B 交換（ハブ アンド スポーク コンフィグレーション）であるのかによって異なります。それらのアーキテクチャを比較する詳細な説明については、『B2B Integration 入門』の「B2B Integration の基礎」の「コンフィグレーション モデル」を参照してください。
注意: このセクションで説明した 2 つのビジネス プロトコル cXML と XOCP は WebLogic Integration リリース 7.0 より非推奨になっています。代替機能に関する詳細については、『WebLogic Integration リリース ノート』を参照してください。
バリュー チェーン統合ソリューションのピア ツー ピア コンフィグレーション
バリュー チェーン統合ソリューションには、以下のタイプの統合のいずれかまたは両方が関わります。
ピア ツー ピア コンフィグレーションは、次の図のようにバリュー チェーン統合ソリューションで使用します。
図3-1 バリュー チェーン統合ソリューションのピア ツー ピア コンフィグレーション
ピア ツー ピア コンフィグレーションでは、1 つのトレーディング パートナ（企業）がチャネル マスタ（CM）になります。チャネル マスタとは、他のすべてのトレーディング パートナ（サプライヤ、顧客、または両方）が接続される管理エンティティのことです。このコンフィグレーション モデルは、トレーディング パートナが RosettaNet、cXML、または EDI プロトコルを使用して通信する必要がある場合にも使用します。 B2B 交換ソリューションのハブ アンド スポーク コンフィグレーション（非推奨） B2B 交換ソリューションは、トレーディング パートナを B2B トランザクションに参加させます。B2B ハブ アンド スポーク アーキテクチャは、次の図のように B2B 交換ソリューションで使用します。 図3-2 B2B 交換ソリューションのハブ アンド スポーク コンフィグレーション
ハブ アンド スポーク コンフィグレーションでは、1 つの企業が参加トレーディング パートナ（スポーク）の間の B2B メッセージを調整するハブとして機能します。B2B アプリケーションは、XOCP プロトコルを使用する配信チャネルを通じて通信します。このコンフィグレーション モデルでは、メッセージのルーティングとフィルタ処理、サービス品質、会話中のトレーディング パートナに対するサービスといった付加価値サービスを実行するメッセージ フローの仲介機能が提供されます。 ハイブリッド アーキテクチャ WebLogic Integration ソリューションでは、ピア ツー ピア コンフィグレーションとハブ アンド スポーク コンフィグレーションを組み合わせて使用する場合もあります。このコンフィグレーション モデルでは、一部のトレーディング パートナでは XOCP を使用し、その他のトレーディング パートナではピア ツー ピア プロトコル（RosettaNet、cXML、または EDI）を使用してトレーディング パートナ間でメッセージを交換できます。 サポート対象のビジネス プロトコル ビジネス プロトコルは、トレーディング パートナ間で交換されるビジネス メッセージの構造、ビジネス メッセージを処理する方法、および適切な相手にメッセージをルーティングする方法を指定します。 WebLogic Integration は以下のビジネス プロトコルをサポートします。
注意: XOCP ビジネス プロトコルは、WebLogic Integration の本リリースより非推奨になりました。代替機能に関する詳細については、『WebLogic Integration リリース ノート』を参照してください。
注意: cXML ビジネス プロトコルは、WebLogic Integration の本リリースより非推奨になりました。代替機能に関する詳細については、『WebLogic Integration リリース ノート』を参照してください。
これらの異なるビジネス プロトコルを比較する詳細な説明については、『B2B Integration 入門』の「概要」の「E ビジネスの要件を満たす」の「ビジネス プロトコルのサポート」を参照してください。
カスタム アプリケーション開発の統合
WebLogic Integration ソリューションの全体的なアーキテクチャを設計するときには、統合スペシャリストはカスタム コードの開発を要するギャップを識別する必要があります。アプリケーション カスタマイズ オプションには、BPM プラグイン、カスタム アダプタ、およびロジック プラグインがあります。
BPM プラグイン
WebLogic Integration ソリューションでは、BPM プラグイン フレームワークを実装するカスタム BPM プラグインを作成しなければならない場合があります。BPM プラグインの設計と開発の詳細については、『WebLogic Integration BPM プラグイン プログラミング ガイド』を参照してください。
カスタム アダプタ
Application Integration の機能に基づく WebLogic Integration ソリューションでは、カスタム Application Integration アダプタを作成しなければならない場合があります。
カスタム ロジック プラグイン（非推奨）
B2B Integration の機能に基づく WebLogic Integration ソリューションでは、カスタム ロジック プラグインを作成しなければならない場合があります。カスタム ロジック プラグインは、ビジネス メッセージの特殊な処理を実行する Java クラスです。具体的には、ロジック プラグインはビジネス メッセージがノードを経由する場合にルールとビジネス ロジックを必要な箇所に挿入します。詳細については、『B2B Integration ロジック プラグイン プログラミング ガイド』を参照してください。
注意: カスタム ログック プラグインは、本リリースの WebLogic Integration で非推奨となった XOCP プロトコルに基づいています。XOCP に代わる機能の詳細については、『WebLogic Integration リリース ノート』を参照してください。
ビジネス プロセスの実装
統合ソリューション トポロジを定義したら、統合スペシャリストはビジネス プロセスの実装を始めることができます。統合ソリューション要件で定義された各ビジネス プロセスについて、以下の節で説明されているいくつかの項目を実装する必要があります。
ビジネス イベント
ビジネス イベントとは、統合ソリューションのエンド ポイント間を行き来するイベントのことです。一部のイベントは入力としてプロセスに送信され、他のイベントはプロセス内で生成する必要があります。WebLogic Integration で、ビジネス メッセージは XML フォーマットまたはバイナリ フォーマットで送信されます。
各ビジネス イベントについて、統合スペシャリストは以下の事項を定義する必要があります。
これらの定義は、WebLogic Integration リポジトリに格納します。できる限り、メタデータを保持するリポジトリのエンティティの名前としてはイベント名を使用してください。WebLogic Integration では、Application Integration アダプタがコンフィグレーションされるとこの情報が自動的にリポジトリに格納されます。
条件データ
処理上の決定を行う時に必要な、メッセージをルーティングする基準や条件に応じてコードを実行する基準などの、条件データ情報です。通常、このようなデータはビジネス イベントから抽出します。しかし、ビジネス プロセス時に、他のデータから動的に構築されます。条件データはそれぞれ、ワークフロー変数で表現されます。
ビジネス ルール
処理ルールは、プロセスの実行時の実行パスを決めるために条件データに適用されます。それらのルールは、BPM ワークフローの分岐ノードとして表されます。場合によっては、多数の複合的な条件をデータ セットに適用しなければならない場合もあります。それらの条件の結果によって、ワークフローの内容が決まります。条件を適用して結果を返すためには、Java クラスを開発する必要があります。結果は、BPM ワークフローの分岐ノードで使用できます。結果を取得するために作成した Java クラスは、WebLogic Integration プロセス エンジンからビジネス オペレーションとして呼び出すことができます。
マッピング
マッピングは、入力ビジネス メッセージと出力ビジネス メッセージのデータ トランスフォーメーションを定義します。
ビジネス トランザクション
プロセスには、1 つまたは多数のビジネス トランザクションが含まれます。ビジネス トランザクションと調整アクション はビジネス トランザクションのロールバックが必要になった時に実行されるので、両方を定義する必要があります。
データ トランスフォーメーションの定義
以下の節では、WebLogic Integration ソリューションのデータ トランスフォーメーションについて説明します。
データ トランスフォーメーションの詳細については、『WebLogic Integration 入門』の「Data Integration」および『WebLogic Integration データ変換』を参照してください。
XML ベースのデータ トランスフォーメーションについて
XML は、WebLogic Integration で一番よく使用されるメッセージ フォーマットです。次の図は、XML ベースのデータ トランスフォーメーションが WebLogic Integration ソリューションのアーキテクチャにどのように組み込まれるのかを示しています。
図3-3 XML ベースのデータ トランスフォーメーション
XML データの最も一般的なソースには以下のものがあります。
XML は、多くの固有言語がある共通言語です。XML データの各ソースでは、異なる固有言語が使用されます。つまり、異なる固有言語の変換を処理するメカニズムが必要となります。XSLT トランスフォーメーションは、このメカニズムとして使用します。
たとえば、バイヤが発注書を RosettaNet フォーマットでセラーに送信し、セラーがそのデータを（SAP IDOC フォーマットのデータのみを受け付ける）バックエンド SAP ERP システムにインポートする必要があるとします。XSLT トランスフォーメーションを使用すると、RosettaNet の発注データを IDOC に変換できます。
バイナリ-XML トランスフォーメーションの定義
XML は WebLogic Integration で一番よく使用されるメッセージ フォーマットですが、WebLogic Integration はバイナリ メッセージ インタフェースが使用される環境と統合しなければならない場合もあります。WebLogic Integration の Data Integration の機能は、XML フォーマットとバイナリ フォーマットの双方向の変換を実行します。この種の変換では、メッセージのデータ構造と内容は変更されません。メッセージ フォーマット（XML またはバイナリ）のみが変更されます。
バイナリ データのフォーマットは、Format Builder アプリケーションを使用してグラフィカルに作成されるメッセージ フォーマット言語（MFL）ドキュメントで記述します。MFL ドキュメントは、バイナリ データを解析して XML ドキュメントに変換するためにデータ統合実行時クラスで使用されます。
バイナリ-バイナリ トランスフォーメーションの定義
バイナリ-バイナリ トランスフォーメーションおよび任意の組み合わせ（バイナリ-XML や XML-バイナリなど）は、以下の 2 つのツールを組み合わせて使用してサポートします。
XML-XML トランスフォーメーションの定義
データ トランスフォーメーション プロセスは、ソース メッセージのデータ構造と内容を対象のメッセージのデータ構造と内容にマッピングするプロセスです。WebLogic Integration では、XML メッセージでのみデータ トランスフォーメーションがサポートされています。データ トランスフォーメーションのメカニズムには XSLT を使用します。
ユーザは、（WebLogic Integration にバンドルされている）Contivo Analyst などのグラフィカル マッピング ツールを使用して XSL スタイルシートを作成するか、または手動でスタイルシートを作成できます。XSL スタイルシートは、WebLogic Integration リポジトリに格納します。
実行時に、トランスフォーメーションはすべて WebLogic Integration プロセス エンジンによって実行されます。入力メッセージは、ワークフロー変数で提供されます。変換を実行する際、WebLogic Integration プロセス エンジンは WebLogic Integration リポジトリの XSL スタイルシートを参照します。出力メッセージは、別のワークフロー変数に格納されます。
Contivo Analyst を使用した XML-XML トランスフォーメーションの定義
WebLogic Integration には、Contivo Analyst があります。Contivo Analyst は、XSL スタイルシートの生成に使用できる設計時のグラフィカル マッピング ツールです。WebLogic Integration プロセス エンジンは、実行時に XSL スタイルシートを実行してソース メッセージを対象のメッセージに変換できます。ソース メッセージと対象のメッセージは DTD または XSD を使用して定義し、それらの定義は WebLogic Integration リポジトリに格納します。Contivo Analyst のインストール、コンフィグレーション、および使用の詳細については、Contivo の製品マニュアルを参照してください。
WebLogic Integration リポジトリとの Contivo Analyst の統合
Contivo Analyst は、次の図のように WebLogic Integration リポジトリと直接統合されます。
図3-4 WebLogic Integration リポジトリとの Contivo の統合
Contivo Analyst は、リポジトリを参照してソースと対象のメッセージ定義を選択します。選択された定義が Contivo Analyst に読み込まれると、ソースから対象へのマッピングがグラフィカルに指定されます。マッピングが完了すると、Contivo Analyst は XSLT を生成し、それを直接 WebLogic Integration リポジトリに保存します。WebLogic Integration プロセス エンジンでは、XSL Transform ワークフロー アクションを使用して XSLT を実行します。 統合ソリューションでの Contivo Analyst のロール 次の図は、Contivo Analyst がどのように WebLogic Integration ソリューションに組み込まれるのかを示しています。 図3-5 WebLogic Integration ソリューションでの Contivo Analyst のロール
この図で、Contivo Analyst は XML Transformer EJB が顧客間で XML データを変換するために使用する XSL スタイルシートを生成します。 注意: XSL ベースの変換コンポーネントだけでなく、この図では WebLogic Integration ソリューションの他の多くの要素が示されています。それらの要素には、BPM ワークフロー、Application Integration アダプタ、および Data Integration を使用し、Format Builder アプリケーションで作成されたメッセージ フォーマット言語（MFL）ドキュメントを使用してバイナリ-XML トランスフォーメーションを実行するアダプタがあります。 XML ベースのデータ トランスフォーメーションについてで説明されている RosetteNet-IDOC トランスフォーメーションのシナリオを使用して、次の手順は Contivo Analyst がどのように統合ソリューションに組み込まれるのかを示しています。
詳細な設計の作成
統合ソリューションでどの WebLogic Integration コンポーネントを使用するのかが決まったら、統合スペシャリストはビジネス アナリスト、開発者、およびシステム管理者と共同で詳細な設計を作成し、統合ソリューションの構築を開始します。
以下の節では、WebLogic Integration ソリューションの詳細な設計の作成に関連する情報を提供します。
統合設計ツールの使用
以下の WebLogic Integration ツールを使用すると、詳細な設計を作成しやすくなります。
デプロイメント環境の設計
通常、統合スペシャリストは統合ソリューションの構築を始める前にデプロイメント環境を設計します。統合スペシャリストは、デプロイメントのリソースとコストを計画するためにこの情報を必要とします。WebLogic Integration ソリューションのデプロイメントについては、『WebLogic Integration ソリューションのデプロイメント』を参照してください。
たとえば、より多くの作業負荷に対応し、スケーラビリティを高めるためには、統合ソリューションは通常 WebLogic Integration クラスタにデプロイします。クラスタとは、1 つの単位として管理できる複数のサーバのグループのことです。クラスタの設計については、『WebLogic Integration ソリューションのデプロイメント』の「WebLogic Integration クラスタについて」の「クラスタ デプロイメントの設計」を参照してください。
統合設計でのパフォーマンスに関する考慮事項
以下の節では、WebLogic Integration デプロイメントのパフォーマンスに影響する要素について説明します。統合スペシャリストは、統合ソリューションの設計段階でこれらの要素を考慮する必要があります。
WebLogic Integration デプロイメントの実行時パフォーマンスのチューニングについては、『WebLogic Integration ソリューションのデプロイメント』の「パフォーマンスのチューニング」を参照してください。
メッセージの永続性
メッセージの永続性は、ハードウェアやネットワークの障害が発生したときのデータの回復を向上させる WebLogic Integration の機能です。ただし、メッセージの永続性を有効にすると、メッセージを永続データ ストア（データベースまたはファイル）に保存またはパージするために必要な処理オーバーヘッドが発生するので、システム全体のパフォーマンスが低下します。詳細については、『B2B Integration 管理ガイド』の「 永続性と回復のコンフィグレーション」を参照してください。
メッセージのサイズ
大規模メッセージは、特に大容量で交換されるときには、小規模メッセージよりも多くのシステム リソースを消費します。このため、大規模メッセージはパフォーマンスを低下させる場合があります。大規模メッセージは、以下の 2 つの形態で作成されます。
WebLogic Integration B2B Console を使用すると、B2B Integration の機能での大規模メッセージのサポートをコンフィグレーションできます。詳細については、『B2B Integration Administration Console オンライン ヘルプ』の「B2B Integration のコンフィグレーション」の「B2B Integration パラメータの定義」を参照してください。
注意: 大規模メッセージを有効にすると、より小さなメッセージの処理が遅くなる場合があります。
XML の解析と検証
XML の解析は高コストなプロセスなので、できる限り避ける必要があります。XML の検証はさらに高コストなので、高いパフォーマンスが要求されるすべてのデプロイメントで避ける必要があります。XML の解析と検証を管理する際は、以下の事項を考慮してください。
イベント検証キューを使用するには、-validate パラメータを MDBGenerator ユーティリティに渡します。詳細については、『WebLogic Integration の起動、停止およびカスタマイズ』の「WebLogic Integration のカスタマイズ」にある「NULL 変数をサポートする BPM のコンフィグレーション」を参照してください。
ワークフロー
この節では、WebLogic Integration ワークフローのパフォーマンス向上のヒントを紹介します。
同期処理
WebLogic Integration では、JMS イベントを通じて呼び出されるワークフローの代わりに、呼び出されるサブワークフローを使用できます。通常、呼び出されるワークフローは高速ですが、より多くのリソースが消費されます。より多くのリソースが消費されるのは、たとえば、呼び出されるワークフローが実行時に呼び出し元ワークフローをブロックすることが原因です。
高いパフォーマンスが要求されるデプロイメントでは、次のようにしてください。
ビジネス メッセージの同期的送信
WebLogic Integration の高可用性機能を利用するワークフローを設計できます。WebLogic Integration ではRosettaNet プロトコルを使用するビジネス メッセージの送信は非同期が要求されます（ビジネス メッセージの同期送信はサポートしていません）。
ビジネス メッセージの同期的送信には次の利点があります。ビジネス メッセージを送信するタスク ノードが実行を完了したら、必要に応じて即時にワークフローのプロセスを次のノードへ進めることができます。ビジネス メッセージの返信ステータスを待っている間、ワークフローの実行を待機する必要がありません。このセクションでは、RosettaNet ベースのワークフローにおけるメッセージの非同期送信設計の方法について説明しました。
ビジネス メッセージを同期的に送信するワークフローを設計する場合は、次の定義を行います。
注意: 7.0 以前のバージョンの WebLogic Integration を使用して作成された RosettaNet をベースとするワークフローをご使用の場合は、ビジネス メッセージの送信方法を変更する必要があります。既存の RosettaNet ベースのワークフローから現在の WebLogic Integration リリースへ移行する詳しい方法については、『WebLogic Integration 移行ガイド』を参照してください。
次の図では、4 つのノード（T5、T8、C1、E1）がどのように RosettaNet ベースのワークフローで非同期の ビジネス メッセージの送信 タスクと関連性をもっているかを説明します。
図3-6 ビジネス メッセージの送信 ワークフロー
ビジネス メッセージの非同期送信を指定する方法など、RosettaNet プロトコルをベースとするワークフローを作成する手順については、次を参照してください。
メッセージ タイムアウト
[ビジネス メッセージの送信] タスクに関連付けられているノードを定義し、接続したら、タイムアウト値を指定するタスク ノードから分岐ノードに移動します。分岐ノードでは HTTP ステータスが評価され、実行フローが適切であるか判断されます。
タイムアウト値は、メッセージ遅延問題回避するのに十分な大きさになるように指定することが必要です。この問題は、ワークフローが HTTP ステータス イベントを受信側トレーディング パートなから受け取る前にタイムアウト値に到達すると発生します。タイムアウトに到達してからステータス イベントを受け取った場合は、ワークフローはこのステータス イベントを無視します。
一般に、特にリモートのトレーディング パートナとの間では、タイムアウト値は2時間以上に設定する必要があります。テストを行って、適切なタイムアウト値になるよう調整してください。
メッセージの再試行
ワークフローのベースとなるビジネス プロトコルごとに、WebLogic Integration で利用可能な、以前に送ったビジネス メッセージが正常に送信されなかった場合に送り直すように指定するメカニズムが異なります。
RosettaNet プロトコルをベースにしているワークフローには、Studio を使用して、メッセージの再送信機能を RosettaNet ベースのワークフローに埋め込むロジックを設計することが可能です。
ebXML ベースのワークフローには、ワークフローではなく、B2B Console でメッセージ再送信を指定します。この値は、このワークフローに関連する ebXML 会話を実行しているトレーディング パートナに対してドキュメント交換をコンフィグレーションする時に指定します。メッセージ再送信値を指定し、[Delivery Semantics] 選択ボックスで [OnceAndOnlyOnce] を選択すると、B2B エンジンがこの値を使用して、前の試行が失敗した後ビジネス メッセージを何度再送信するかを決定します。ビジネス メッセージが正常に送信された場合は、再送信は実行されません。これにより、メッセージは確実に一度だけ送信されることになります（[Delivery Semantics] 選択ボックスを選択した場合は、B2B エンジンは再送信値を無視します）。
条件
パフォーマンスが重要な場合は、BPM の開始ノードまたはイベント ノードでできる限りイベント条件を使用しないでください。完了ノードの設定に関する詳細については、『WebLogic Integration Studio ユーザーズ ガイド』の「ワークフロー テンプレートの定義」を参照してください。
XPath の使用
XPath を使用するときには、以下のガイドラインを考慮してください。
一時変数の使用
BPM のパフォーマンスを向上させるには、静止状態の前に一時変数を NULL に設定します。このように設定することで、（イベントのように）トランザクションの境界でディスクに書き込まれることがなくなります。
統計収集の無効化
BPM のパフォーマンスを向上させるには、次のフラグを設定して統計の収集を無効にします。
-wli.bpm.server.nostatistics=true
統計の収集が無効になると、WebLogic Integration Studio に統計が表示されなくなります。
Application Integration
デフォルトでは、Application Integration の機能は非同期の要求および応答でのトランザクション対応で永続的なメッセージ配信の使用に依存します。この種の配信では、不要なメッセージングのオーバーヘッドが生じることがあります。システムの全体的なパフォーマンスを向上させるには、以下のソリューションを使用してトランザクション対応で永続的な配信を無効にします。
wlai.jms.asyncServiceTransFlag=false
この問題を解決するには、wlai.properties ファイルの wlai.numAsyncServiceRequestProcessors プロパティを大きな値に設定して非同期プロセッサ スレッドの数を増やします。このプロパティは、wlai.properties ファイルに追加しなければならない場合もあります。このプロパティのデフォルト値は 2 です。つまり、デフォルトでは、特定のサーバ インスタンスの特定の時点で非同期サービス要求は 2 つしか処理されません。
アプリケーションのロギング
プロダクション環境で WebLogic Integration の全体的なパフォーマンスを向上させるには、アプリケーションで実行するロギングを最低限に抑える必要があります。出力のロギングを無効にする方法については、次の URL にある『WebLogic Server 管理者ガイド』の「ログ メッセージを使用した WebLogic Server の管理」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs70/adminguide/logging.html
Secure Sockets Layer
B2B Integration の機能が使用される WebLogic Integration デプロイメントでパフォーマンスを向上させるには、Secure Sockets Layer（SSL）の使用をセキュアなメッセージングが必要な状況のみに制限します。SSL では、ビジネス メッセージの暗号化と解読などのタスクを実行することによって余計な処理オーバーヘッドが生じ、その結果としてシステム全体のパフォーマンスが低下します。
サンプル WebLogic Integration アプリケーションの高度な設計の指定
以下の節では、これまでの節で説明された設計事項と関連するサンプル WebLogic Integration アプリケーションの高度な設計について説明します。
これらの節では、統合ソリューションの要件の決定で定義された要件がどのように WebLogic Integration アーキテクチャのコンポーネントにマッピングされるのかについて説明します。サンプル WebLogic Integration アプリケーションの設計の詳細については、『WebLogic Integration チュートリアル』を参照してください。
WebLogic Integration Studio を使用したビジネス プロセスの自動化
統合ソリューションとビジネス プロセスの指定 で説明されているビジネス プロセスを自動化するために、サンプルの WebLogic Integration アプリケーションでは WebLogic Integration Studio を使用して以下のビジネス プロセスをモデル化および管理します。
これらのビジネス プロセスは、トレーディング パートナの間でプライベート ワークフローと協調的ワークフローを使用します。それらのワークフローでは、ビジネス イベントの指定 で説明されているビジネス イベントとデータ フローの要件の指定 で説明されているデータ フローがカプセル化されます。
ワークフロー設計の詳細については、『WebLogic Integration チュートリアル』の「サンプルについて」の「ビジネス プロセスおよびワークフローのモデル化」を参照してください。
B2B Integration を使用したサプライ チェーンの統合
サプライ チェーンの外部エンティティ（サプライヤ）とのビジネス トランザクションを管理するために、サンプルの WebLogic Integration アプリケーションでは WebLogic Integration の B2B Integration の機能を使用します。具体的に言うと、XOCP プロトコルを通じてトレーディング パートナの間で仲介メッセージングを実現するハブ アンド スポーク コンフィグレーション（外部トレーディング パートナとの統合で説明）に基づいてビルドされます。XOCP を使用することで、サンプルの WebLogic Integration アプリケーションはサービス品質の指定 で説明されているサービス品質（QoS）要件を満たします。
注意: XOCP ビジネス プロトコルは、WebLogic Integration の本リリースより非推奨になりました。代替機能に関する詳細については、『WebLogic Integration リリース ノート』を参照してください。
サンプルの WebLogic Integration アプリケーションは、ハブ、バイヤ、トレーディング パートナである 2 つのサプライヤからなる 4 つのビジネス エンティティをデプロイします。ただし、このシナリオではサプライヤが GCS 外の別々のマシンで独自のソフトウェアを実行するトポロジが求められますが、サンプルを使いやすくするためにサンプルの WebLogic Integration アプリケーションではすべてのエンティティが同じマシンに配置されます。クラスタ環境でこのコードを実行する方法の詳細については、『WebLogic Integration ソリューションのデプロイメント』を参照してください。
独自の設計に B2B Integration 機能を組み込む方法の詳細については、『WebLogic Integration チュートリアル』の「サンプルについて」の「B2B Integration」を参照してください。
Application Integration アダプタを使用した ERP システムの統合
ERP 発注システムと統合するために、サンプルの WebLogic Integration アプリケーションでは Application Integration アダプタを使用します。バイヤ側では、イベント アダプタを使用して発注を ERP システムに追加します。また、サービス アダプタを使用して、選択したサプライヤから受信した発注確認書に基づいて発注を更新します。
Application Integration アダプタの詳細については、『WebLogic Integration チュートリアル』の「サンプルについて」の「Application Integration と Data Integration」を参照してください。
Data Integration を使用したデータ トランスフォーメーションの管理
XML-バイナリおよびバイナリ-XML のデータ トランスフォーメーションを処理するために、サンプルの WebLogic Integration アプリケーションでは Data Integration の機能を使用します。WLIS_SupplierPOPrivate ワークフローでは、以下の変換が実行されます。
Data Integration の詳細については、『WebLogic Integration チュートリアル』の「サンプルについて」の「Application Integration と Data Integration」を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
