|
ここでは、Trading Partner Integration のための WebLogic Integration ソリューション構築の基本概念、アーキテクチャ、およびタスクについて説明します。内容は以下のとおりです。
WebLogic Integration の包括的な概要については、『WebLogic Integration 入門』(http://edocs.beasys.co.jp/e-docs/wli/docs92/overview/) を参照してください。Trading Partner Integration のチュートリアル (下記 URL から入手可能) では、サンプルの ebXML ソリューションおよび RosettaNet ソリューションを構築および実行する手順を具体的に説明しています。
WebLogic Integration を使用すると、トレーディング パートナとの関係を自動化および管理することができ、それによって、顧客、サプライヤ、販売代理店、その他のパートナとのビジネス プロセスを簡素化して効率を上げ、バリュー チェーン全体にわたるビジネス トランザクションのトップダウン ビューを取得することができます。Trading Partner Integration は、B2B Integration の名でも知られています。
WebLogic Integration には、以下の Trading Partner Integration 機能があります。
WebLogic Integration では、WebLogic Workshop の統一されたプログラミング モデルや実行時フレームを活用して、容易に実装できるコントロールやテンプレートによる、ビジネス プロセスのエンド ツー エンド統合を実現します。
WebLogic Integration では、次の B2B プロトコルおよび標準をサポートしています。
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 内のトレーディング パートナ管理ホームページです。管理者はここから、トレーディング パートナ プロファイル、セキュリティ証明書、プロトコル バインディング、サービス、メッセージ トラッキングおよび監査、トレーディング パートナ アクティビティ、システム デフォルト、トレーディング パートナ プロファイル情報のインポート/エクスポートなどを管理できます。
WebLogic Integration Adiministration Console のトレーディング パートナ管理モジュールの詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」を参照してください。これには、以下の内容が含まれます。
WebLogic Integration では、「トレーディング パートナ」は、ビジネスの明確な目的に関連付けられているあらかじめ定義された役割を担うことによって、特定のビジネス トランザクションまたはサービスに参加するために他のエンティティと契約を結ぶエンティティであるとされています。トレーディング パートナ アプリケーションは、ビジネス パートナ間のシステム ツー システム対話におけるノードです。
トレーディング パートナのグループには、次のような形態があります。
トレーディング パートナ プロファイルには、トレーディング パートナの識別情報と、ビジネス トランザクションの実行に必要な証明書やプロトコル バインディングがすべて含まれます。トレーディング パートナ情報は、WebLogic Integration Administration Console で管理できます。トレーディング パートナ プロファイルの管理の詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
デフォルトでは、各トレーディング パートナは以下の「基本プロパティ」を持ちます。
以上のデフォルトのプロパティのほかに、アプリケーション固有の要件に対応するために、TPM リポジトリ内の個々のトレーディング パートナについて、カスタム拡張 (拡張プロパティ) を追加することができます。たとえば、追加の連絡先情報、電信振替のための銀行口座情報、各トレーディング パートナに対する社内ベンダ ID などを含めることができます。これらのプロパティは、TPM コントロールを使用してビジネス プロセスや Web サービスから取得したり、XML ドキュメント内でサブツリー間を移動して取得したりできます。WebLogic Integration Administration Console での拡張プロパティの管理の詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
WebLogic Integration では、各トレーディング パートナに関連付けられたデジタル証明書を使用して、メッセージ交換時にトレーディング パートナの ID を認証します。WebLogic Integration でのデジタル証明書の格納方法および使用方法の詳細については、「転送レベルのセキュリティ」を参照してください。WebLogic Integration Administration Console での証明書の管理の詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
ここでは、サービス、サービス プロファイル、およびプロトコル バインディングについて説明します。
「サービス」は、ローカル トレーディング パートナから提供されるビジネス プロセスか、リモート トレーディング パートナ上のコントロールを経由して呼び出されるビジネス プロセスを表します。
WebLogic Integration Administration Console でのサービスの管理の詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
「サービス プロファイル」には、使用するサービス バインディングに関する、2 つのトレーディング パートナ間の契約の概念が含まれています。 サービス プロファイルは、サービスの提供および呼び出しを行うローカル トレーディング パートナとリモート トレーディング パートナの「プロトコル バインディング」および URL エンドポイントを指定します。WebLogic Integration Administration Console でのサービス プロファイルの管理の詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
「プロトコル バインディング」は、ビジネス プロトコル (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 Administration Console の使用』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
注意 : | トレーディング パートナのメッセージングに ebXML プロトコルを使用する場合、[再試行回数]、[再試行間隔]、および [永続化の持続期間] の各値には必ずリモート トレーディング パートナの値が使用され、ローカル トレーディング パートナの値は使用されません。 |
WebLogic Integration で提供されるバルク管理ユーティリティにより、TPM リポジトリの管理、他のトレーディング パートナとのトレーディング パートナ情報やサービス情報の交換、他のサーバへの情報の移植などのタスクが簡略化されます。データ交換は、WebLogic Integration に添付された tpm.xsd
スキーマに準拠する、XML データ ファイルを使用して行われます。
WebLogic Integration のエクスポート、インポート、およびバルク削除のオペレーションは、WebLogic Integration Administration Console でも Bulk Loader コマンド ライン ユーティリティでも実行できます。TPM リポジトリのバルク管理の詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
コンソールまたは Bulk Loader ユーティリティを使用して TPM データをエクスポートすると、インポートに適したファイルが作成されます。構造要件の詳細、およびインポート、エクスポート、バルク削除でのファイルの使用方法の詳細については、『WebLogic Integration ソリューションの管理』の「Bulk Loader の使用」を参照してください。
BEA WebLogic Platform の Configuration Wizard で新しい WebLogic Integration ドメインを作成すると、トレーディング パートナ管理 (TPM) リポジトリには、デフォルトのトレーディング パートナとプロトコル バインディングとが自動的に入力されます。Configuration Wizard の詳細については、WebLogic Platform のドキュメントにある『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』を参照してください。
WebLogic Integration ドメインでは、開発用およびテスト用として、次の 2 つのトレーディング パートナが事前にコンフィグレーションされています。
Trading Partner Integration のチュートリアルの詳細については、『トレーディング パートナのチュートリアル』を参照してください。
デフォルトのトレーディング パートナには、以下に示すプロトコル バインディングが事前にコンフィグレーションされています。
ebXML 1.0 を除くすべてのプロトコル バインディングがデフォルトとしてマークされています。実行時に特定のプロトコル情報がない場合は、デフォルトのバインディングが自動的に使用されるようにできます。ebXML 1.0 を使用する場合は、プロトコル バインディングを WebLogic Integration Administration Console で明示的にコンフィグレーションする必要があります。
WebLogic Integration では、Java Management Extensions (JMX) Management Beans (MBeans) を使用して TPM リポジトリにアクセスする、ユーザが作成したアプリケーションがサポートされます。
MBean API の詳細については、WebLogic Integration の Javadoc を参照してください。
ここでは、トレーディング パートナ ビジネス プロセスについて理解するために必要な概念を紹介します。内容は以下のとおりです。
WebLogic Integration では、トレーディング パートナ同士の通信が、先進的な B2B プロトコル (ebXML または RosettaNet) を使用して共同作業を行う WebLogic Workshop ビジネス プロセスを通じて行われます。ビジネス プロセスの構築、テスト、実行には、WebLogic Workshop の統合プログラミング モデルと実行時フレームワークを使用します。WebLogic Integration では、そのようなビジネス プロセスを容易かつ迅速に実装するためのコントロール、テンプレート、その他のメカニズムを備えています。WebLogic Integration でビジネス プロセスを構築する方法の概要については、以下のトピックを参照してください。
ビジネス プロトコルごとのビジネス プロセスの構築方法の詳細については、以下を参照してください。
ここでは、トレーディング パートナ間の会話と、会話においてトレーディング パートナが担うロールについて説明します。
トレーディング パートナ同士があるビジネス用途のためにビジネス メッセージを交換する場合、トレーディング パートナは「会話」に参加します。会話は、トレーディング パートナ間で交換される 1 つまたは複数の一連のビジネス メッセージです。複雑な会話なのか、シンプルな会話なのか、あるいは、長く続く会話なのか、すぐに完結する会話なのか、といった会話ごとの性質は、そのビジネス用途によって異なります。
会話の中で参加者がどのようなビジネス メッセージを交換できるかは、会話の中でトレーディング パートナが担う「ロール」によって異なります。会話には必ず、次の 2 つのロールが関与します。
これら 2 つのロールは、会話に関与するすべてのビジネス プロセスに必須ですが、開始者と参加者とではビジネス プロセスの設計パターンが非常に異なります。会話では、それらのビジネス プロセスの動作は、非常に異なるものでありながら協調的です。たとえば、開始者ビジネス プロセスが参加者に要求を送り、参加者ビジネス プロセスはその要求を受け取って、応答を開始者に返します。
所定のロールで会話に参加する各トレーディング パートナは、そのロールに求められる協調的ビジネス プロセスを実装する必要があります。強調的ビジネス プロセスは、会話における各トレーディング パートナのロールに応じて、適切なビジネス メッセージを適切なタイミングで処理するために必要なプロセスをカプセル化します。
通常、これらのロールは、会話の性質に応じてネーミングされます。たとえば、買い手に請求書を送り、その受け取りの確認を取得するサプライヤが会話に関与する場合は、サプライヤが会話の開始者、買い手が参加者です。この場合、請求書が要求ドキュメントであり、確認が応答ドキュメントです。
WebLogic Integration 環境では、「協調的ビジネス プロセス」は、トレーディング パートナのロールを会話内に実装するプロセスです。会話のメッセージ コレオグラフィは、協調的ビジネス プロセスによって定義されます。
次の図は、トレーディング パートナ間の基本の対話的ビジネス プロセスを示します。買い手のビジネス プロセスでは、合意済みのビジネス プロトコル (ebXML または RosettaNet) を使用して、売り手に対して注文が送信されます。売り手のビジネス プロセスでは、要求を受信し、データベースに注文を書き込んで、内部のバックエンド システムから請求書を受信し、同じビジネス プロトコルを使用して請求書を買い手に送信します。
ここでは、トレーディング パートナの会話におけるビジネス プロセスの各種カテゴリについて説明します。
ここでは、開始者と参加者のビジネス プロセスに使用できる WebLogic Integration のコントロールとテンプレートについて説明します。
次の表は、開始者ビジネス プロセスで参加者との通信の処理に使用する WebLogic Workshop コントロールの説明です。
次の表は、参加者ビジネス プロセスで会話開始者との通信の処理に使用する WebLogic Workshop テンプレートの説明です。
TPM (トレーディング パートナ管理) コントロールを使用すると、WebLogic Workshop のビジネス プロセスおよび Web サービスにおいて、TPM リポジトリに格納されているトレーディング パートナ情報やサービス情報にクエリ (読み取り専用) アクセスできるようになります。TPM リポジトリへのアクセスは、アクティブなトレーディング パートナ、サービス、およびアクティブ サービス プロファイルとその子だけに制限されています。ビジネス プロセスおよび Web サービスでの TPM コントロールの使用方法の詳細については、WebLogic Workshop ヘルプの「TPM コントロール」を参照してください。Web サービスの使用方法の詳細については、WebLogic Workshop ヘルプの「Web サービスを構築する」を参照してください。
ビジネス プロセスや Web サービスでは、TPM リポジトリ内のデータに、プロセス コントロールやサービス ブローカ コントロールからアクセスすることもできます。これらのコントロールは、セレクタで使用できる lookupTPMProperties XQuery 関数を提供します。これらのコントロールの詳細については、Integration コントロール使用のガイドの「プロセス コントロール」と「サービス ブローカ コントロール」を参照してください。
ビジネス プロセスは、ファイアウォールを越え、インターネットを経由して、複数のアプリケーション、会社の複数の部門、および複数のビジネス パートナ (トレーディング パートナ) にまたがることがあります。企業のビジネス プロセスは、「パブリック」と「プライベート」という 2 つのカテゴリに大まかに分類できます。
パブリック プロセスは「インタフェース」プロセスです。パブリック プロセスの定義と設計は、それを使用する組織によって認識、理解、合意されており、RosettaNet Partner Interface Processes (PIP) のように、業界や業界内のセグメントでのカスタマイズや標準化されていることもあります。パブリック プロセスは、トレーディング パートナ間の正式な規約の一部として、メッセージ交換の内容とセマンティクスを指定します。これらのプロセスは、トレーディング パートナごとに異なる方法で実装できます。
トレーディング パートナ統合のコンテキストでは、複数のトレーディング パートナ間での複数の会話における協調的ビジネス プロセスの再利用が想定される場合、そのビジネス プロセスはパブリック プロセスとして設計される必要があります。
会話の参加者は、プライベートの非協調的ビジネス プロセスを実装することもできます。これにより、参加者のバックエンド処理の統合が可能になります。プライベート プロセスは、組織内で実行されるビジネス プロセスです。プライベート プロセスの定義と設計は、その組織に固有であり、組織外では認識されません。プライベート プロセスは、トレーディング パートナの企業内で、パブリック プロセスやバックエンド ビジネス システムとインタフェースします。パブリック プロセスのコンテキストでは、プライベート プロセスは、パブリック ビジネス プロセスの一部であるタスクを実装するサブビジネス プロセスまたはサブプロセスであると考えることができます。たとえば、トレーディング パートナが実装できるプライベート ビジネス プロセスには、協調的ビジネス プロセスと連携して動作するものや、トレーディング パートナのローカルで発生するプロセスを実装するものがありますが、それらのプライベート ビジネス プロセスが必ずしもサービス契約に明文化されているとは限りません。
会話におけるビジネス プロセスの最終的な結果は 2 つあります。成功か失敗です。
ビジネス プロセスは、タイマー コントロール、再試行ループ、パラレル ブランチなどの WebLogic Workshop メカニズムを使用して、このような想定されるすべてのシナリオに対応できなければなりません。
失敗した各ビジネス メッセージはファイルに保存され、そのファイルの URI と、もしあればその他の情報 (MessageID、FromTP、ToTP、ProcessURI、ProcessInstance、および Timestamp) が、wli.b2b.failedmessage.queue
という専用 JMS キューに追加されます。メッセージの失敗を処理するために、カスタム キュー リスナまたはイベント ジェネレータが作成されます。
ここでは、WebLogic Integration がトレーディング パートナとの間でビジネス メッセージをやりとりする動作を理解するために必要な概念を紹介します。内容は以下のとおりです。
WebLogic Integration の信頼性が高くロールベースの XML メッセージングは、長大なメッセージのサポートなど高度な送受信機能をサポートしています。トレーディング パートナ間の、高速かつ高信頼性のビジネス メッセージ交換をサポートするために、WebLogic Integration では、実行時に以下のメッセージング サービスを提供します。
ビジネス プロトコルは、ビジネス プロセスに関連付けられています。ビジネス プロセスは、トレーディング パートナ間のビジネス情報の交換を管理します。ビジネス プロトコルは、ビジネス メッセージの構造、メッセージの処理方法、および適切な受信者へのメッセージのルーティング方法を指定します。また、ビジネス プロトコルは、永続性および信頼性に関連する、メッセージの特性を指定する場合もあります。
ビジネス メッセージは、トレーディング パートナ間の通信の基本単位であり、会話の一部として交換されます。1 つのビジネス メッセージには、1 つまたは複数の XML ビジネス ドキュメント、1 つまたは複数の添付ファイル、またはその両方の組み合わせが含まれます。
ビジネス メッセージの内容とフォーマットは、どのビジネス プロトコルを会話に使用するかによって異なります。メッセージごとのフォーマットの詳細については、以下のトピックを参照してください。
XML フォーマットおよび非 XML フォーマットの添付ファイルをビジネス メッセージに含めることができます。添付ファイルについては、WebLogic Workshop ビジネス プロセスは、以下の Java 型をサポートしています。
XmlObject データ型) と非 XML データ (RawData データ型) がある。異なる種類のペイロード (XML と非 XML) を同じメッセージで送信するときに使用される。メッセージ部分の実際の数は、処理されるまで不明なことがある。MessageAttachment オブジェクトの操作については、WebLogic Workshop ヘルプの「メッセージ添付ファイルを使用する」を参照してください。
|
注意 : | 型付き XML データや型付き MFL データを添付ファイルにすることもできますが、その場合は対応する XML Bean クラス名や MFL クラス名をパラメータ内で指定する必要があります。 |
これらのデータ型の詳細については、WebLogic Workshop ヘルプの「データ型を処理する」を参照してください。
実行時の JMS キュー内のビジネス メッセージの処理を高速化するために、WebLogic Integration では、長大な添付ファイルを一時的にドキュメント ストア データベースに格納します。
ここでは、ebXML および RosettaNet のビジネス メッセージの実行時の処理について説明します。着信ビジネス メッセージと発信ビジネス メッセージとでは、経由するパスが異なります。全体のフローは、基底のビジネス プロトコルに関係なく同じです。ただし、WebLogic Integration のメッセージング インフラストラクチャでは、ebXML ビジネス メッセージと RosettaNet ビジネス メッセージを別々に処理するために、それぞれに特化した基底のコンポーネントを用意しています。
wli.internal.msgtracking.queue
) に送信されます。このキューをリスンするメッセージ駆動型 Bean が、WebLogic Integration Administration Console のトレーディング パートナ管理モジュールで設定されているトラッキング レベルに基づき、各種メッセージ トラッキング テーブルを更新します。
コンフィグレーションの手順については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「モードとメッセージ トラッキングのコンフィグレーション」を参照してください。
B2BdefaultWebApp/WEB-INF/web.xml
で指定された Transport Servlet Filter によって受信されます。
アンパックの方法は、使用されるビジネス プロトコルや、TPM リポジトリでコンフィグレーションされている設定によって異なります。たとえば、デコーダは、メッセージの各 MIME パートを分解し、XML コンポーネントを検証し (RosettaNet の場合)、必要なすべての復号化を行い (RosettaNet の場合)、すべてのデジタル署名を検証します。
注意 : | ebXML の場合も、デコーダは同様の動作を行いますが、選択されている信頼性のあるメッセージ オプションによって動作は異なります。 |
wli.internal.msgtracking.queue
) に送信されます。このキューをリスンするメッセージ駆動型 Bean が、WebLogic Integration Administration Console のトレーディング パートナ管理モジュールで設定されているトラッキング レベルに基づき、各種メッセージ トラッキング テーブルを更新します。コンフィグレーションの手順については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「モードとメッセージ トラッキングのコンフィグレーション」を参照してください。
WebLogic Integration には、Trading Partner Integration のための以下の実行時モニタ機能があります。
WebLogic Integration は、他のトレーディング パートナに送られたり、他のトレーディング パートナから取得したりしたビジネス メッセージのフローおよびステート情報を追跡します。WebLogic Integration Administration Console のメッセージ トラッキング モジュールに実行時のデータと統計を表示することにより、ビジネス メッセージのリアルタイム モニタリング、プロセス解析、トラブルシューティング、およびレポートを実行できます。
WebLogic Integration では、メッセージの履歴情報を実行時リポジトリで管理します。個々のサービス プロファイルのメッセージ トラッキング レベルのコンフィグレーション方法は、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」の「サービス プロファイルのサービスへの追加」で説明しています。WebLogic Integration では、メッセージの履歴情報が実行時データベースで管理されます。この情報の定期的なアーカイブとパージをスケジュールすることができます。メッセージ トラッキングの詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「メッセージのモニタ」を参照してください。
WebLogic Integration Administration Console の統計モジュールには、システムとサービス プロファイルの実行時統計が表示されます。以下は、システム概要統計の例です。
詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理」にある「統計の表示」を参照してください。
ここでは、Trading Partner Integration ソリューションの実装に関連するフェーズ、タスク、ツールの概要を説明します。内容は以下のとおりです。
最初のフェーズは、ソリューションのプランニングです。以下の作業が必要です。
トレーディング パートナ統合ソリューションの大まかな要件を把握したら、以下のツールを使用して、ソリューションを設計、構築、およびテストします。
各ビジネス プロトコルに関連付けられたタスクの詳細については、以下のトピックを参照してください。
トレーディング パートナ統合ソリューションの設計、構築、およびテストが完了したら、以下のツールを使用して、ソリューションをプロダクション環境にデプロイします。
トレーディング パートナ統合ソリューションをプロダクション環境にデプロイしたら、同じツール (WebLogic Integration Administration Console および WebLogic Server Administration Console) を使用して、そのデプロイメントをモニタおよび調整します。