ナビゲーションをスキップ

Trading Partner Integration の紹介

  前 次 vertical dots separating previous/next from contents/index/pdf 目次  

はじめに

ここでは、トレーディング パートナ統合のための WebLogic Integration ソリューション構築の基本概念、アーキテクチャ、およびタスクについて説明します。内容は以下のとおりです。

WebLogic Integration の包括的な概要については、『WebLogic Integration 入門』(http://edocs.beasys.co.jp/e-docs/wli/docs81/overview/index.html) を参照してください。Trading Partner Integration のチュートリアル (下記 URL から入手可能) では、サンプルの ebXML ソリューションおよび RosettaNet ソリューションを構築および実行する手順を具体的に説明しています。

 


Trading Partner Integration について

WebLogic Integration を使用すると、トレーディング パートナとの関係を自動化および管理することができ、それによって、顧客、サプライヤ、販売代理店、その他のパートナとのビジネス プロセスを簡素化して効率を上げ、バリュー チェーン全体にわたるビジネス トランザクションのトップダウン ビューを取得することができます。Trading Partner Integration は、B2B Integration の名でも知られています。

WebLogic Integration には、以下のトレーディング パートナ統合機能があります。

パブリック プロセスやプライベート プロセスの視覚的な統合

WebLogic Integration では、WebLogic Workshop の統一されたプログラミング モデルや実行時フレームを活用して、容易に実装できるコントロールやテンプレートによる、ビジネス プロセスのエンド ツー エンド統合を実現します。

業界最先端のプロトコルおよび規格のサポート

WebLogic Integration では、次の B2B プロトコルおよび標準をサポートしています。

トレーディング パートナ管理 (TPM) とリポジトリ アクセス

WebLogic Integration は、統合 WebLogic Integration Administration Console から使用できる高度なトレーディング パートナ管理機能を備えています。管理者は、このコンソールから、トレーディング パートナのプロファイル情報のリポジトリを容易に一元管理できます。たとえば、トレーディング パートナ間のセキュアなメッセージ交換に使用されるプロトコル バインディング、パブリック プロセスを表すサービス、セキュリティ、バルク インポート/エクスポートなどの機能があります。容易に実装できるコントロールにより、権限を有するビジネス プロセスや Web サービスからトレーディング パートナ情報に動的にアクセスすることが可能です。Administration Console に加えて MBean API も用意されており、これによって、「サードパーティ アクセス用 MBean API」で説明されているように、TPM リポジトリにアクセスするようサードパーティ製 MBean クライアントを記述することができます。

実行時情報への容易なアクセス

WebLogic Integration で提供されている柔軟性の高い実行時追跡、監査、レポート機能を使用すると、バリュー チェーン全体のトレーディング パートナのアクティビティやビジネス トランザクションを表示できます。

高いパフォーマンスと可用性

WebLogic Integration では、トレーディング パートナ間でビジネス メッセージの交換を高速かつ信頼性の高い方法で行うことができ、スケーラビリティやフェイルオーバに対応するためのクラスタ化コンフィグレーション、メッセージの永続性、低レベルの確認応答と受信、トランザクションの整合性がサポートされています。

高セキュリティ、監査、否認防止

WebLogic Integration では、SSL による転送レベルのセキュリティ、デジタル署名および暗号によるメッセージ レベルのセキュリティを使用して、トレーディング パートナ間で、プライベートでセキュリティ保護された信頼性の高いビジネス メッセージ交換が可能です。さまざまな目的で使用される証明書およびプライベート キーは保護されたキーストアに保存され、パスワードは暗号化されて WebLogic Integration PasswordStore に保存されます。

トレーディング パートナの有効化

WebLogic Integration は WebLogic Integration - Business Connect とともに動作します。WebLogic Integration - Business Connect は、独自の B2B サーバを持たない小規模トレーディング パートナ向けに設計された軽量 B2B サーバです。インストール ソリューションが不要なトレーディング パートナの場合、WebLogic Integration は簡単に拡張してブラウザまたは FTP インタフェースを提供できます。

 


トレーディング パートナの管理の概念

トレーディング パートナ統合の基本的な要素は、トレーディング パートナ プロファイル、サービス、およびサービス プロファイルです。ここでは、トレーディング パートナ管理について理解するために必要な概念を紹介します。内容は以下のとおりです。

トレーディング パートナ管理について

トレーディング パートナ プロファイル、サービス、およびサービス プロファイルの情報はすべて、「トレーディング パートナ管理 (TPM) リポジトリ」内にあります。このリポジトリは、リレーショナル データベースに格納されています。管理者は、WebLogic Integration Administration Console から TPM リポジトリを管理できます。

次の図は、WebLogic Integration Administration Console 内のトレーディング パートナ管理ホームページです。管理者はここから、トレーディング パートナ プロファイル、セキュリティ証明書、プロトコル バインディング、サービス、メッセージ トラッキングおよび監査、トレーディング パートナ アクティビティ、システム デフォルト、トレーディング パートナ プロファイル情報のインポート/エクスポートなどを管理できます。

図 1-1 WebLogic Integration Administration Console でのトレーディング パートナ管理


 

WebLogic Integration Adiministration Console のトレーディング パートナ管理モジュールの詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」を参照してください。これには以下の内容が含まれます。

トレーディング パートナ

WebLogic Integration では、「トレーディング パートナ」は、ビジネスの明確な目的に関連付けられているあらかじめ定義された役割を担うことによって、特定のビジネス トランザクションまたはサービスに参加するために他のエンティティと契約を結ぶエンティティであるとされています。トレーディング パートナ アプリケーションは、ビジネス パートナ間のシステム ツー システム対話におけるノードです。

トレーディング パートナの種類

トレーディング パートナのグループには、次のような形態があります。

トレーディング パートナ プロファイル

トレーディング パートナ プロファイルには、トレーディング パートナの識別情報と、ビジネス トランザクションの実行に必要な証明書やプロトコル バインディングがすべて含まれます。トレーディング パートナ情報は、WebLogic Integration Administration Console で管理できます。トレーディング パートナ プロファイルの管理の詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある、以下のトピックを参照してください。

基本プロパティと拡張プロパティ

デフォルトでは、各トレーディング パートナは、以下の「基本プロパティ」を持ちます。

表 1-1 トレーディング パートナの基本プロパティ

プロパティ

説明

ビジネス名

トレーディング パートナの名前。

ビジネス ID

ビジネス プロセスにおいてトレーディング パートナの一意識別に使用される。

ビジネス ID タイプ

ビジネス ID のタイプ。たとえば、DUNS 番号、顧客 ID 番号、ベンダ ID 番号など。

タイプ

このトレーディング パートナがホスト システムに対してローカルか、リモートかを指定する。

ステータス

特定の操作 (たとえば、ビジネス プロセスまたは Web サービスが TPM リポジトリ内のトレーディング パートナ情報にアクセスする操作) に対してトレーディング パートナを表示対象 (有効) または非表示 (無効) にする。詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「トレーディング パートナおよびサービス プロファイルの有効化および無効化」を参照。

説明

トレーディング パートナについての簡単な説明。

デフォルトのトレーディング パートナ

これが選択されると、そのトレーディング パートナは、特定のトレーディング パートナ情報がない場合にローカル ホスト システムのメッセージの送受信を行う、デフォルトのトレーディング パートナに指定される。

連絡先情報

電子メール アドレス、住所、電話番号、FAX 番号などの情報。


 

以上のデフォルトのプロパティのほかに、アプリケーション固有の要件に対応するために、TPM リポジトリ内の個々のトレーディング パートナについて、カスタム拡張 (拡張プロパティ) を追加することができます。たとえば、追加の連絡先情報、電信振替のための銀行口座情報、各トレーディング パートナに対する社内ベンダ ID などを含めることができます。これらのプロパティは、TPM コントロールを使用してビジネス プロセスや Web サービスから取得したり、XML ドキュメント内でサブツリー間を移動して取得したりできます。WebLogic Integration Administration Console での拡張プロパティの管理の詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある以下のトピックを参照してください。

デジタル証明書

WebLogic Integration では、各トレーディング パートナに関連付けられたデジタル証明書を使用して、メッセージ交換時にトレーディング パートナの ID を認証します。WebLogic Integration でのデジタル証明書の格納方法および使用方法の詳細については、「転送レベルのセキュリティ」を参照してください。WebLogic Integration Administration Console での証明書の管理の詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある以下のトピックを参照してください。

サービス、サービス プロファイル、プロトコル バインディング

ここでは、サービス、サービス プロファイル、およびプロトコル バインディングについて説明します。

サービス

「サービス」は、ローカル トレーディング パートナから提供されるビジネス プロセスか、リモート トレーディング パートナ上のコントロールを経由して呼び出されるビジネス プロセスを意味します。

WebLogic Integration Administration Console でのサービスの管理の詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある以下のトピックを参照してください。

サービス プロファイル

「サービス プロファイル」には、使用するサービス バインディングに関する、2 つのトレーディング パートナ間の契約の概念が含まれています。サービス プロファイルは、サービスの提供および呼び出しを行うローカル トレーディング パートナとリモート トレーディング パートナの「プロトコル バインディング」および URL エンドポイントを指定します。WebLogic Integration Administration Console でのサービス プロファイルの管理の詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある以下のトピックを参照してください。

プロトコル バインディング

「プロトコル バインディング」は、ビジネス プロトコル (ebXML 1.0 または 2.0、あるいは RosettaNet 1.1 または 2.0)、転送プロトコル (HTTP 1.0、HTTP 1.1、HTTPS 1.1 など)、URL エンドポイント、タイムアウト、再試行数、再試行間隔、デジタル署名、その他の情報を指定します。WebLogic Integration Administration Console でのプロトコル バインディングの管理の詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある以下のトピックを参照してください。

注意 : トレーディング パートナのメッセージングに ebXML プロトコルを使用している場合、[再試行回数]、[再試行間隔]、および [永続化の持続期間] の各値には必ずリモート トレーディング パートナの値が使用され、ローカル トレーディング パートナの値は使用されません。

TPM リポジトリでのデータ交換

WebLogic Integration で提供されるバルク管理ユーティリティにより、TPM リポジトリの管理、他のトレーディング パートナとのトレーディング パートナ情報やサービス情報の交換、他のサーバへの情報の移植などのタスクが簡略化されます。データ交換は、WebLogic Integration に添付された tpm.xsd スキーマに準拠する、XML データ ファイルを介して行われます。WebLogic Integration - Business Connect を使用するトレーディング パートナについては、WebLogic Integration - Business Connect またはビジネス接続フォーマットを使用する WebLogic Integration からエクスポートされた単一のトレーディング パートナ プロファイルをインポートすることもできます。WebLogic Integration - Business Connect からのプロファイルのエクスポートの詳細については、次の URL にある WebLogic Integration - Business Connect のドキュメントを参照してください。

http://edocs.bea.com/wlibc/docs81/index.html

WebLogic Integration のエクスポート、インポート、およびバルク削除のオペレーションは、WebLogic Integration Administration Console でも Bulk Loader コマンド ライン ユーティリティでも実行できます。TPM リポジトリのバルク管理の詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある以下のトピックを参照してください。

コンソールまたは Bulk Loader ユーティリティを使用して TPM データをエクスポートすると、インポートに適したファイルが作成されます。必要な構造の詳細や、インポート、エクスポート、バルク削除のオペレーションでのファイルの使用方法の詳細については、『WebLogic Integration ソリューションの管理』の「Bulk Loader の使用」を参照してください。

デフォルトの TPM リポジトリ設定

BEA WebLogic Platform の Configuration Wizard で新しい WebLogic Integration ドメインを作成すると、トレーディング パートナ管理 (TPM) リポジトリには、デフォルトのトレーディング パートナとプロトコル バインディングとが自動的に入力されます。Configuration Wizard の詳細については、WebLogic Platform のドキュメントにある『コンフィグレーション ウィザードの使い方』を参照してください。

デフォルトのトレーディング パートナ

WebLogic Integration ドメインでは、開発用およびテスト用として、次の 2 つのトレーディング パートナが事前にコンフィグレーションされています。

表 1-2 WebLogic Integration ドメインでのデフォルトのトレーディング パートナのコンフィグレーション 

トレーディング パートナの名前

トレーディング パートナの ID

説明

Test_TradingPartner_1

000000001

デフォルトのローカル トレーディング パートナ。チュートリアルでは、通常、このトレーディング パートナが会話「開始者」になる。

Test_TradingPartner_2

000000002

チュートリアルでは、通常、このトレーディング パートナが会話「参加者」になる。


 

Trading Partner Integration のチュートリアルの詳細については、『トレーディング パートナのチュートリアル』を参照してください。

デフォルトのプロトコル バインディング

デフォルトのトレーディング パートナには、以下に示すプロトコル バインディングが事前にコンフィグレーションされています。

ebXML 1.0 を除くすべてのプロトコル バインディングがデフォルトとしてマークされています。実行時に特定のプロトコル情報がない場合は、デフォルトのバインディングが自動的に使用されるようにできます。ebXML 1.0 を使用する場合は、プロトコル バインディングを WebLogic Integration Administration Console で明示的にコンフィグレーションする必要があります。

サードパーティ アクセス用 MBean API

WebLogic Integration では、Java Management Extensions (JMX) Management Beans (MBeans) を使用して TPM リポジトリにアクセスする、ユーザが作成したアプリケーションがサポートされます。

MBean API の詳細については、WebLogic Integration の Javadoc を参照してください。

 


トレーディング パートナ ビジネス プロセスの概念

ここでは、トレーディング パートナ ビジネス プロセスについて理解するために必要な概念を紹介します。内容は以下のとおりです。

Trading Partner Integration のビジネス プロセスについて

WebLogic Integration では、トレーディング パートナ同士の通信が、先進的な B2B プロトコル (ebXML または RosettaNet) を使用して共同作業を行う WebLogic Workshop ビジネス プロセスを通じて行われます。ビジネス プロセスの構築、テスト、実行には、WebLogic Workshop の統合プログラミング モデルと実行時フレームワークを使用します。WebLogic Workshop では、そのようなビジネス プロセスを容易かつ迅速に実装するためのコントロール、テンプレート、その他のメカニズムを備えています。WebLogic Workshop でビジネス プロセスを構築する方法の概要については、WebLogic Workshop ヘルプの以下のトピックを参照してください。

ビジネス プロトコルごとのビジネス プロセスの構築方法の詳細については、以下を参照してください。

会話とロール

ここでは、トレーディング パートナ間の会話と、会話においてトレーディング パートナが担うロールについて説明します。

会話

トレーディング パートナ同士があるビジネス用途のためにビジネス メッセージを交換する場合、トレーディング パートナは「会話」に参加します。会話は、トレーディング パートナ間で交換される 1 つまたは複数の一連のビジネス メッセージです。複雑な会話なのか、シンプルな会話なのか、あるいは、長く続く会話なのか、すぐに完結する会話なのか、といった会話ごとの性質は、そのビジネス用途によって異なります。

ロール : 開始者と参加者

会話の中で参加者がどのようなビジネス メッセージを交換できるかは、会話の中でトレーディング パートナが担う「ロール」によって異なります。会話には必ず、次の 2 つのロールが関与します。

ロールベースの設計パターン

これら 2 つのロールは、会話に関与するすべてのビジネス プロセスに必須ですが、開始者と参加者とではビジネス プロセスの設計パターンが非常に異なります。会話では、それらのビジネス プロセスの動作は、非常に異なるものでありながら協調的です。たとえば、開始者ビジネス プロセスが参加者に要求を送り、参加者ビジネス プロセスはその要求を受け取って、応答を開始者に返します。

所定のロールで会話に参加する各トレーディング パートナは、そのロールに求められる協調的ビジネス プロセスを実装する必要があります。強調的ビジネス プロセスは、会話における各トレーディング パートナのロールに応じて、適切なビジネス メッセージを適切なタイミングで処理するために必要なプロセスをカプセル化します。

ロールのネーミング

通常、これらのロールは、会話の性質に応じてネーミングされます。たとえば、買い手に請求書を送り、その受け取りの確認を取得するサプライヤが会話に関与する場合は、サプライヤが会話の開始者、買い手が参加者です。この場合、請求書が要求ドキュメントであり、確認が応答ドキュメントです。

協調的ビジネス プロセス

WebLogic Integration 環境では、「協調的ビジネス プロセス」は、トレーディング パートナのロールを会話内に実装するプロセスです。会話のメッセージ コレオグラフィは、協調的ビジネス プロセスによって定義されます。

会話のサンプル

次の図は、トレーディング パートナ間の基本の対話的ビジネス プロセスを示します。買い手のビジネス プロセスでは、合意済みのビジネス プロトコル (ebXML または RosettaNet) を使用して、売り手に対して注文が送信されます。売り手のビジネス プロセスでは、要求を受信し、データベースに注文を書き込んで、内部のバックエンド システムから請求書を受信し、同じビジネス プロトコルを使用して請求書を買い手に送信します。

図 1-2 会話におけるロールベースの協調的ビジネス プロセス


 

ビジネス プロセスのタイプ

ここでは、トレーディング パートナの会話におけるビジネス プロセスの各種カテゴリについて説明します。

開始者と参加者のビジネス プロセス

ここでは、開始者と参加者のビジネス プロセスに使用できる WebLogic Workshop のコントロールとテンプレートについて説明します。

開始者ビジネス プロセスと WebLogic Workshop コントロール

次の表は、開始者ビジネス プロセスで参加者との通信の処理に使用する WebLogic Workshop コントロールの説明です。

表 1-3 開始者ビジネス プロセスで使用される WebLogic Workshop コントロール 

コントロール名

説明

ebXML コントロール

ebXML コントロールを使用すると、WebLogic Workshop ビジネス プロセスでは、ebXML 経由でトレーディング パートナとビジネス メッセージおよびデータを交換可能。ebXML コントロールは、ebXML 1.0 と ebXML 2.0 の両方のメッセージング サービスをサポートする。ebXML コントロールは、開始者ビジネス プロセスにおいて参加者との ebXML ビジネス メッセージの交換を管理する場合のみ使用する。ebXML コントロールの使用方法の詳細については、WebLogic Workshop ヘルプの「ebXML コントロール」と、「ebXML 開始者ビジネス プロセス」を参照。

RosettaNet コントロール

WebLogic Workshop ビジネス プロセスで、トレーディング パートナとのビジネス メッセージおよびデータの交換を RosettaNet で行えるようにする。RosettaNet コントロールは、開始者ビジネス プロセスにおいて参加者との RosettaNet ビジネス メッセージの交換を管理する場合のみ使用する。RosettaNet コントロールの使用方法の詳細については、WebLogic Workshop ヘルプの「RosettaNet コントロール」と、「RosettaNet 開始者ビジネス プロセス」を参照。


 

参加者ビジネス プロセスと WebLogic Workshop テンプレート

次の表は、参加者ビジネス プロセスで会話開始者との通信の処理に使用する WebLogic Workshop テンプレートの説明です。

表 1-4 参加者ビジネス プロセスで使用される WebLogic Workshop テンプレート 

ビジネス プロトコル

説明

ebXML 参加者ビジネス プロセス ファイル

テンプレートは、ebXML 会話のパブリック参加者ビジネス プロセスを構築するための土台になる。このファイルは、ebXML 参加者ビジネス プロセスの構築に必須ではないが、ebXML 開始者ビジネス プロセスと簡単に統合するために必要となるノードおよびビジネス プロセス注釈を含んでいる。参加者ビジネス プロセスの使用方法については、WebLogic Workshop ヘルプの 「ebXML 参加者ビジネス プロセスを構築する」および「@jpd:ebxml 注釈」を参照してください。

RosettaNet 参加者ビジネス プロセス ファイル

テンプレートは、RosettaNet 会話のパブリック参加者ビジネス プロセスを構築するための土台になる。このファイルは、RosettaNet 参加者ビジネス プロセスの構築に必須ではないが、RosettaNet 開始者ビジネス プロセスと簡単に統合するために必要となるノードおよびビジネス プロセス注釈を含んでいる。参加者ビジネス プロセスの使用方法については、WebLogic Workshop ヘルプの 「RosettaNet 参加者ビジネス プロセスを構築する」および「@jpd:rosettanet 注釈」を参照してください。


 

ビジネス プロセスおよび Web サービスのための TPM コントロール

TPM (トレーディング パートナ管理) コントロールを使用すると、WebLogic Workshop のビジネス プロセスおよび Web サービスにおいて、TPM リポジトリに格納されているトレーディング パートナ情報やサービス情報にクエリ (読み取り専用) アクセスできるようになります。TPM リポジトリへのアクセスは、アクティブなトレーディング パートナ、サービス、およびアクティブ サービス プロファイルとその子だけに制限されています。ビジネス プロセスおよび Web サービスでの TPM コントロールの使用方法の詳細については、WebLogic Workshop ヘルプの「TPM コントロール」を参照してください。Web サービスの使用方法の詳細については、WebLogic Workshop ヘルプの「Web サービスを構築する」を参照してください。

プロセス コントロールやサービス ブローカ コントロールからの TPM リポジトリ ルックアップ

ビジネス プロセスや Web サービスでは、TPM リポジトリ内のデータに、プロセス コントロールやサービス ブローカ コントロールからアクセスすることもできます。これらのコントロールは、セレクタで使用できる lookupTPMProperties XQuery 関数を提供します。これらのコントロールの詳細については、WebLogic Workshop ヘルプの「プロセスコントロール」および「サービス ブローカ コントロール」を参照してください。

パブリック ビジネス プロセスとプライベート ビジネス プロセス

ビジネス プロセスは、ファイアウォールを越え、インターネットを経由して、複数のアプリケーション、会社の複数の部門、および複数のビジネス パートナ (トレーディング パートナ) にまたがることがあります。企業のビジネス プロセスは、「パブリック」と「プライベート」という 2 つのカテゴリに大まかに分類できます。

パブリック ビジネス プロセス

パブリック プロセスは「インタフェース」プロセスです。パブリック プロセスの定義と設計は、それを使用する組織によって認識、理解、合意されており、RosettaNet Partner Interface Processes (PIP) のように、業界や業界内のセグメントでのカスタマイズや標準化されていることもあります。パブリック プロセスは、トレーディング パートナ間の正式な規約の一部として、メッセージ交換の内容とセマンティクスを指定します。これらのプロセスは、トレーディング パートナごとに異なる方法で実装できます。

トレーディング パートナ統合のコンテキストでは、複数のトレーディング パートナ間での複数の会話における協調的ビジネス プロセスの再利用が想定される場合、そのビジネス プロセスはパブリック プロセスとして設計される必要があります。

プライベート ビジネス プロセス

会話の参加者は、プライベートの非協調的ビジネス プロセスを実装することもできます。これにより、参加者のバックエンド処理の統合が可能になります。プライベート プロセスは、組織内で実行されるビジネス プロセスです。プライベート プロセスの定義と設計は、その組織に固有であり、組織外では認識されません。プライベート プロセスは、トレーディング パートナの企業内で、パブリック プロセスやバックエンド ビジネス システムとインタフェースします。パブリック プロセスのコンテキストでは、プライベート プロセスは、パブリック ビジネス プロセスの一部であるタスクを実装するサブビジネス プロセスまたはサブプロセスであると考えることができます。たとえば、トレーディング パートナが実装できるプライベート ビジネス プロセスには、協調的ビジネス プロセスと連携して動作するものや、トレーディング パートナのローカルで発生するプロセスを実装するものがありますが、それらのプライベート ビジネス プロセスが必ずしもサービス契約に明文化されているとは限りません。

成功パスと失敗パス

会話におけるビジネス プロセスの最終的な結果は 2 つあります。成功か失敗です。

ビジネス プロセスは、タイマー コントロール、再試行ループ、パラレル ブランチなどの WebLogic Workshop メカニズムを使用して、このような想定されるすべてのシナリオに対応できなければなりません。

失敗した各ビジネス メッセージはファイルに保存され、そのファイルの URI と、もしあればその他の情報 (MessageID、FromTP、ToTP、ProcessURI、ProcessInstance、および Timestamp) が、wli.b2b.failedmessage.queue という専用 JMS キューに追加されます。メッセージの失敗を処理するために、カスタム キュー リスナまたはイベント ジェネレータが作成されます。

 


メッセージングの概念

ここでは、WebLogic Integration がトレーディング パートナとの間でビジネス メッセージをやりとりする動作を理解するために必要な概念を紹介します。内容は以下のとおりです。

Trading Partner Integration 向けメッセージング サービス

WebLogic Integration の信頼性が高くロールベースの XML メッセージングは、長大なメッセージのサポートなど高度な送受信機能をサポートしています。トレーディング パートナ間の、高速かつ高信頼性のビジネス メッセージ交換をサポートするために、WebLogic Integration では、実行時に以下のメッセージング サービスを提供します。

ビジネス プロトコル

ビジネス プロトコルは、ビジネス プロセスに関連付けられています。ビジネス プロセスは、トレーディング パートナ間のビジネス情報の交換を管理します。ビジネス プロトコルは、ビジネス メッセージの構造、メッセージの処理方法、および適切な受信者へのメッセージのルーティング方法を指定します。また、ビジネス プロトコルは、永続性および信頼性に関連する、メッセージの特性を指定する場合もあります。

ビジネス メッセージ

ビジネス メッセージは、トレーディング パートナ間の通信の基本単位であり、会話の一部として交換されます。1 つのビジネス メッセージには、1 つまたは複数の XML ビジネス ドキュメント、1 つまたは複数の添付ファイル、またはその両方の組み合わせが含まれます。

ビジネス メッセージ フォーマット

ビジネス メッセージの内容とフォーマットは、どのビジネス プロトコルを会話に使用するかによって異なります。メッセージごとのフォーマットの詳細については、以下のトピックを参照してください。

添付ファイル

XML フォーマットおよび非 XML フォーマットの添付ファイルをビジネス メッセージに含めることができます。添付ファイルについては、WebLogic Workshop ビジネス プロセスは、以下の Java 型をサポートしています。

表 1-5 ビジネス メッセージ添付ファイルの型 

データ型

説明

XmlObject

デフォルト。未タイプ XML フォーマットのデータを表す。XML データは、設計時には指定されない。

XmlObject[]

1 つまたは複数の XmlObject 要素の配列。ebXML メッセージでのみ使用可能。

RawData

任意の非 XML 構造化データまたは非構造化データを表す。たとえば、PDF、DOC、GIF、JPG のファイルや他のバイナリ ファイル。

RawData[]

1 つまたは複数の RawData 要素の配列。ebXML メッセージでのみ使用可能。

MessageAttachment[]

ebXML または RosettaNet のビジネス メッセージの 1 つまたは複数の部分を含む配列。メッセージ パートには未タイプ XML データ (XmlObject データ型) と非 XML データ (RawData データ型) がある。異なる種類のペイロード (XML と非 XML) を同じメッセージで送信するときに使用される。メッセージ パートの実際の数は、処理されるまで不明。MessageAttachment オブジェクトの操作方法については、WebLogic Workshop ヘルプの「メッセージ添付ファイルを使用する」を参照。


 

注意 : 型付き XML データや型付き MFL データを添付ファイルにすることもできます (対応する XML Bean クラス名や MFL クラス名をパラメータ内で指定する必要があります)。

これらのデータ型の詳細については、WebLogic Workshop ヘルプの「データ型を処理する」を参照してください。

実行時の JMS キュー内のビジネス メッセージの処理を高速化するために、WebLogic Integration では、長大な添付ファイルを一時的にドキュメント ストア データベースに格納します。

ビジネス メッセージの実行時処理

ここでは、ebXML および RosettaNet のビジネス メッセージの実行時の処理について説明します。着信ビジネス メッセージと発信ビジネス メッセージとでは、経由するパスが異なります。全体のフローは、基本となるビジネス プロトコルに関係なく同じです。ただし、WebLogic Integration のメッセージング インフラストラクチャでは、ebXML ビジネス メッセージと RosettaNet ビジネス メッセージを別々に処理するために、それぞれに特化した基本コンポーネントを用意しています。

発信メッセージのパス

次の図は、発信ビジネス メッセージのパスを示します。

図 1-3 発信トレーディング パートナ メッセージのパス


 

上の図は、以下のプロセス フローを表します。

  1. WebLogic Integration ビジネス プロセスからビジネス メッセージが送信されます。
  2. 適切なエンコーダ (RosettaNet または ebXML) が、以下からの入力を使用してメッセージを適宜パッケージ化します。
  3. パッケージ化の方法は、使用されるビジネス プロトコルや、TPM リポジトリでコンフィグレーションされている設定によって異なります。たとえば、エンコーダは、暗号化 (RosettaNet 用)、デジタル署名、必須メッセージ ヘッダの生成、MIME パッケージ化、メッセージ永続性などを処理します。

  4. メッセージが WebLogic Integration ドキュメント ストアに保持され、かつ、以下の適切な JMS キューに転送されます。
  5. キューに関連付けられた以下のメッセージ駆動型 Bean から、リモート トレーディング パートナのエンドポイント URL に向けて、メッセージが非同期に HTTP(S) 経由で送信されます。
  6. 発信メッセージのメッセージ トラッキング情報が、メッセージ トラッキング キュー (wli.internal.msgtracking.queue) に送信されます。このキューをリスンするメッセージ駆動型 Bean が、WebLogic Integration Administration Console のトレーディング パートナ管理モジュールで設定されているトラッキング レベルに基づき、各種メッセージ トラッキング テーブルを更新します。
  7. コンフィグレーションの手順については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある「モードとメッセージ トラッキングのコンフィグレーション」を参照してください。

着信トレーディング パートナ メッセージのパス

次の図は、着信ビジネス メッセージのパスを示します。

図 1-4 着信メッセージのパス


 

上の図は、以下のプロセス フローを表します。

  1. ローカルのトレーディング パートナに向けて送信された着信トレーディング メッセージが、B2BdefaultWebApp/WEB-INF/web.xml で指定された Transport Servlet Filter によって受信されます。
  2. Transport Servlet Filter が、URL を検査し、着信要求が TPI URL/要求かどうかを判別します。
  3. メッセージが転送サーブレットから適切なデコーダ (RosettaNet または ebXML) に送られ、そこでアンパックされます。
  4. アンパックの方法は、使用されるビジネス プロトコルや、TPM リポジトリでコンフィグレーションされている設定によって異なります。たとえば、デコーダは、メッセージの各 MIME パートを分解し、XML コンポーネントを検証し (RosettaNet の場合)、必要なすべての復号化を行い (RosettaNet の場合)、すべてのデジタル署名を検証します。

  5. デコーダがメッセージ (ebXML のペイロードまたは RosettaNet のサービス内容) と、添付ファイルがあれば添付ファイルを、WebLogic Integration ドキュメント ストアに保持します。
  6. デコーダが、送り先パーティと送り元パーティ、サービス名、その他、メッセージのディスパッチに役立つ関連情報を取得します。
  7. デコーダがメッセージを Async Dispatcher Queue にディスパッチします。
  8. 受信ノードのメソッド シグネチャに適するようにメッセージ パートがパッケージ化されます。

  9. RosettaNet の場合、デコーダは、受信されたビジネス メッセージの送り元のトレーディング パートナにも応答します。
  10. 注意 : ebXML の場合も、デコーダは同様の動作を行いますが、選択されている信頼性のあるメッセージ オプションによって動作は異なります。

  11. Async Dispatcher Module が、ビジネス プロセス上の適切な受信ノードにメッセージをディスパッチします。
  12. 着信メッセージのメッセージ トラッキング情報が、メッセージ トラッキング キュー (wli.internal.msgtracking.queue) に送信されます。このキューをリスンするメッセージ駆動型 Bean が、WebLogic Integration Administration Console のトレーディング パートナ管理モジュールで設定されているトラッキング レベルに基づき、各種メッセージ トラッキング テーブルを更新します。コンフィグレーションの手順については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある「モードとメッセージ トラッキングのコンフィグレーション」を参照してください。

 


実行時モニタの概念

WebLogic Integration には、トレーディング パートナ統合のための以下の実行時モニタ機能があります。

メッセージ トラッキング

WebLogic Integration は、他のトレーディング パートナに送られたり、他のトレーディング パートナから取得したりしたビジネス メッセージのフローおよびステート情報をトラッキングします。WebLogic Integration Administration Console のメッセージ トラッキング モジュールに実行時のデータと統計を表示することにより、ビジネス メッセージのリアルタイム モニタリング、プロセス解析、トラブルシューティング、およびレポートを実行できます。

以下は、ビジネス メッセージの概要の例です。


 

以下は、単一ビジネス メッセージの詳細の例です。


 

WebLogic Integration では、メッセージの履歴情報を実行時リポジトリで管理します。個々のサービス プロファイルのメッセージ トラッキング レベルのコンフィグレーション方法を、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「サービスへのサービス プロファイルの追加」で説明しています。WebLogic Integration では、メッセージの履歴情報が実行時データベースで管理されます。この情報の定期的なアーカイブとパージをスケジュールすることができます。メッセージ トラッキングの詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「メッセージのモニタ」を参照してください。

実行時統計の表示

WebLogic Integration Administration Console の統計モジュールには、システムとサービス プロファイルの実行時統計が表示されます。以下は、システム概要統計の例です。


 

以下は、サービス プロファイル統計の例です。


 

詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「統計の表示」を参照してください。

 


Trading Partner Integration の各フェーズのまとめ

ここでは、トレーディング パートナ統合ソリューションの実装に関連するフェーズ、タスク、ツールの概要を説明します。内容は以下のとおりです。

フェーズ 1 : ソリューションのプランニング

最初のフェーズは、ソリューションのプランニングです。以下の作業が必要です。

詳細については、以下のトピックを参照してください。

フェーズ 2 : ソリューションの設計、構築、テスト

トレーディング パートナ統合ソリューションの大まかな要件を把握したら、以下のツールを使用して、ソリューションを設計、構築、およびテストします。

各ビジネス プロトコルに関連付けられたタスクの詳細については、以下のトピックを参照してください。

フェーズ 3 : ソリューションのデプロイ

トレーディング パートナ統合ソリューションの設計、構築、およびテストが完了したら、以下のツールを使用して、ソリューションをプロダクション環境にデプロイします。

詳細については、以下のトピックを参照してください。

フェーズ 4 : ソリューションの管理と調整

トレーディング パートナ統合ソリューションをプロダクション環境にデプロイしたら、同じツール (WebLogic Integration Administration Console および WebLogic Server Administration Console) を使用して、そのデプロイメントをモニタおよび調整します。

詳細については、以下のトピックを参照してください。

 


次の手順

この時点で、以下のトピックに進むことができます。

 

ナビゲーション バーのスキップ  ページの先頭 前 次