| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Integration > B2B トピック > B2B Integration 管理ガイド > コンフィグレーション要件 |
|
B2B Integration 管理ガイド
|
コンフィグレーション要件
この章では、WebLogic Integration B2B Integration コンフィグレーションをいくつか取り上げて、標準的な参加者のためのコンフィグレーション要件の例を示します。この章の内容は以下のとおりです。
この章の情報は、トレーディング パートナとの会話の管理に使用する協調的ワークフローのコンフィグレーションを対象としています。Messaging API または cXML API を使用して Java メッセージング アプリケーションを作成する場合は、『B2B Integration メッセージング アプリケーション プログラミング ガイド』を参照してください。ロジック プラグインを使用してコラボレーションに機能を追加する場合は、『B2B Integration ロジック プラグイン プログラミング ガイド』を参照してください。
注意: XOCP および cXML プロトコル、B2B ブラウザおよびファイル共有クライアントは、このリリースの WebLogic Integration から非推奨になっています。XOCP、cXML、B2B ブラウザおよびファイル共有クライアントに代わる機能についての情報は、『WebLogic Integration リリース ノート』を参照してください。
コンフィグレーションの概要
以下の節では、WebLogic Integration でサポートされている基本的な B2B 統合アプリケーションの一部を設定する方法について説明します。これらの基本的なコンフィグレーションでは、より複雑なシナリオで必要な概念を示します。B2B エンジン プロパティ（B2B エンジン名、説明、環境設定など）の設定に加えて、以下のエンティティのプロパティをコンフィグレーションする必要があります。
次の図は、コンフィグレーションする必要があるエンティティの概要です。これは、WebLogic Integration B2B Console でどのように情報が構成されるかを示したものです。リポジトリに情報が格納される方法の概要については、リポジトリの操作を参照してください。具体的なプロパティを設定するのに必要な情報の詳細は、B2B Console のオンライン ヘルプで説明します（ヘルプの利用参照）。
図1-1 B2B Integration のコンフィグレーションの概要
前の図で示したように、各配信チャネルは、ビジネス プロトコル バインディングを定義するドキュメント交換に関連付けられます。ドキュメント交換で定義されるパラメータは、選択したプロトコルによって異なります。次の図は、WebLogic Integration でサポートされているビジネス プロトコルを示します。 図1-2 ドキュメント交換で定義されているビジネス プロトコルのバインディング
以下の節では、複数のサンプル アプリケーションの参加者に対するコンフィグレーション要件について説明します。コンフィグレーションは通常、B2B Console で実行されますが、これらの例は、コンフィグレーションの実行方法を示すものではありません。B2B Integration コンポーネントのインポートとエクスポートの説明に従って、あるシステムで作成されたトレーディング パートナ、会話定義、コラボレーション アグリーメント、およびワークフローをエクスポートして別のシステムにインポートできます。 トレーディング パートナのエンコーディングに関する注意 XML ドキュメントと同様に、トレーディング パートナ間でやり取りするメッセージは、有効な文字セットでエンコードされる可能性があります。デフォルトでは、メッセージは UTF-8 でエンコーディングされています。他のエンコーディングをサポートするために、トレーディング パートナのコンフィグレーションには、encoding プロパティがあります。このプロパティは、B2B エンジンが、そのトレーディング パートナに送信されたメッセージをエンコードする方法を指定します（図1-1 で示されるトレーディング パートナの一般的なプロパティを参照）。 エンコーディングの仕様は、XOCP プロトコルに対してのみ影響します。B2B エンジンは、エンコーディング プロパティの設定に関係なく、すべての cXML、RosettaNet および ebXML メッセージを UTF-8 でエンコードします。 次の節のXOCP アプリケーション（非推奨）,で説明するように、XOCP プロトコルのメッセージは常に、ハブとしてコンフィグレーションされたトレーディング パートナの配信チャネルでルーティングされます。 図1-3 メッセージ配信
上の図では、以下のエンコーディング設定がトレーディング パートナに適用されているものとします。
これらの設定を基に、TP1 から TP3 へのメッセージのエンコーディングは、次のように処理されます。
このシナリオのメッセージ エンコーディングは、次の図のようにまとめることができます。
図1-4 メッセージ エンコーディング
エンコーディング プロパティを使用したときに期待した結果を得るために、トレーディング パートナと、それに関連付けられた配信チャネルをコンフィグレーションしたときにメッセージがどのように処理されるかに留意する必要があります。 TP3 の Shift_JIS でエンコードされたペイロード情報が必要な場合は、TP2 のエンコーディングを Shift_JIS に設定する必要があります。 次の節では、XOCP プロトコルでメッセージをルーティングするためにトレーディング パートナ定義、会話定義、コラボレーション アグリーメントをコンフィグレーションする方法の詳細を説明します。必要に応じて、適切にエンコーディングされたメッセージをトレーディング パートナが受信するように、ダミーのトレーディング パートナとコラボレーション アグリーメントをコンフィグレーションできます。 有効なエンコーディング名とエリアスのリストについては、次の URL にアクセスしてください。http://www.iana.org/assignments/character-sets
XOCP アプリケーション（非推奨）
以下の節では、XOCP 配信チャネルのコンフィグレーション、およびピア ツー ピアの仲介メッセージング アプリケーションで XOCP を使用するように B2B エンジンをコンフィグレーションする方法の例を示します。
XOCP ハブおよびスポーク配信チャネル
XOCP プロトコルの配信チャネルは、以下のいずれかにコンフィグレーションする必要があります。
ハブ配信チャネルは、会話定義のどちらかのロールに対してプロキシとして機能するユニークな配信チャネルです。ハブ配信チャネルで想定されるロールは、会話定義に対するコラボレーション アグリーメントのコンフィグレーションによって異なります。たとえば、トレーディング パートナのハブ配信チャネルが、あるコラボレーション アグリーメントではサプライヤのロールに割り当てられ、同じ会話定義の別のコラボレーション アグリーメントではバイヤのロールに割り当てられている場合、メッセージは次のように処理されます。
つまり、会話定義で同じロールに関連付けられた複数のトレーディング パートナが、ハブ配信チャネルを持つコラボレーション アグリーメントに参加した場合、その配信チャネルを使用して、それらのトレーディング パートナにメッセージをブロードキャストできます。一部のトレーディング パートナに対するブロードキャストを制限する必要がある場合、ルーティングおよびフィルタ処理の XPath 式で説明されているとおり、XPath フィルタ式を使用できます。
XOCP アプリケーションは、配信チャネルとコラボレーション アグリーメントに対してハブとスポークのコンフィグレーションを必ず必要としますが、XOCP プロトコルを使用するトレーディング パートナは、ピア ツー ピアまたは仲介によるメッセージの交換のいずれかに参加できます。
以下の節では、これらの基本的な XOCP メッセージ交換方法の詳細な例を示します。これらの例自体で示すのは、単純なシナリオです。これを基に、より複雑なデプロイメントを作成できます。
XOCP ピア ツー ピア メッセージング
コンピュータ メーカーの ABC International、チップ サプライヤの XYZ Systems という 2 つのトレーディング パートナが、WebLogic Integration から Query Price and Availability（QPA）トランザクションに参加するものとします。ABC International はバイヤで、2 つのトランザクションの開始者です。メッセージの交換には XOCP プロトコルを使用しています。双方のトレーディング パートナには、WebLogic Integration がインストールされています。
次の節では、以下の方法の例を示します。
必要なプライベートおよび協調的（パブリック）ワークフローが作成されていることを前提とします。この例の協調的ワークフローは、それぞれ QPA_Public_Supplier および QPA_Public_Buyer という名前です。Studio（B2B Integration プラグインで提供されている拡張機能付き）の使用の詳細については、『B2B Integration ワークフローの作成』を参照してください。
警告: この例では、2 つの配信チャネル（1 つのハブと 1 つのスポーク）用にコンフィグレーションされた単一のトレーディング パートナを示します。現在、このコンフィグレーションには制限があります。2 つの配信チャネルで 1 つのトレーディング パートナを設定しないでください。代わりに、それぞれに独自の配信チャネルを定義して 2 つのトレーディング パートナを設定します。1 つのトレーディング パートナでハブ配信チャネルをコンフィグレーションし、もう 1 つのトレーディング パートナでスポーク配信チャネルをコンフィグレーションします。
トレーディング パートナ
ABC International と XYZ Systems 双方のトレーディング パートナ定義を提供する必要があります。
注意: 簡略化のために、この例では SSL または署名による証明書を使用しません。セキュリティ コンフィグレーションの詳細については、『B2B Integration セキュリティの実装』を参照してください。
次の図では、ABC WebLogic Integration コンフィグレーションの ABC International トレーディング パートナ用に定義する情報をまとめています。
図1-5 ABC コンフィグレーションでの ABC International トレーディング パートナ定義
トレーディング パートナのタイプ（「General」ボックス内）は Local で、コンフィグレーションには、ハブおよびスポークの配信チャネル（XOCP-hub-dc と XOCP-spoke-dc）、ドキュメント交換（XOCP-hub-de と XOCP-spoke-de）、転送（XOCP-hub-transport と XOCP-spoke-transport）が定義されています。各転送は、配信チャネル エンドポイントとして機能する URI（http://abc.com/xocp-hub-transport と http://abc.com/xocp-spoke-transport）に関連付けられています。 注意: この例の初め（XOCP ピア ツー ピア メッセージングを参照）で説明したように、現在の WebLogic Integration には、2 つのトレーディング パートナのコンフィグレーションが必要な制限があります。たとえば、ABC International-Spoke というトレーディング パートナと ABC International というトレーディング パートナをコンフィグレーションします。ABC International の定義には、XOCP-hub-dc、XOCP-hub-de、および XOCP-hub-transport 定義が含まれる一方で、ABC International-Spoke 定義には、XOCP-spoke-dc、XOCP-spoke-de、および XOCP-spoke-transport 定義が含まれます。 次の図では、XYZ WebLogic Integration コンフィグレーションの ABC International トレーディング パートナ用に定義する情報をまとめています。 図1-6 XYZ コンフィグレーションでの ABC International トレーディング パートナ定義
この場合、トレーディング パートナのタイプ（「General」ボックス内）は Remote で、コンフィグレーションには、ハブのみの配信チャネル（XOCP-hub-dc）、ドキュメント交換（XOCP-hub-de）、転送（XOCP-hub-transport）が定義されています。転送は、配信チャネル エンドポイントとして機能する URI（http://abc.com/xocp-hub-transport）に関連付けられています。 次の図では、ABC WebLogic Integration コンフィグレーションの XYZ Systems トレーディング パートナ用に定義する情報をまとめています。 図1-7 ABC International コンフィグレーションでの XYZ Systems トレーディング パートナ定義
この場合、トレーディング パートナのタイプ（「General」ボックス内）は Remote で、コンフィグレーションには、スポークのみの配信チャネル（XOCP-spoke-dc）、ドキュメント交換（XOCP-spoke-de）、転送（XOCP-spoke-transport）が定義されています。転送は、配信チャネル エンドポイントとして機能する URI（http://xyz.com/xocp-spoke-transport）に関連付けられています。 XYZ WebLogic Integration コンフィグレーションの XYZ Systems トレーディング パートナ用に定義する情報は、前の図と同じです。ただし、XYZ WebLogic Integration コンフィグレーションのトレーディング パートナのタイプ（「General」ボックス内）を Local に設定する必要があります。 会話定義 次の図では、ABC WebLogic Integration コンフィグレーションの Query Price and Availability（QPA）会話定義で必要な設定を示します。 図1-8 QPA 用の会話定義
XYZ WebLogic Integration コンフィグレーションの会話定義は同じです。ただし、BPM オーガニゼーション（「WLPI organization」として示されている部分）を、XYZ Systems で定義されたオーガニゼーション（XYZ_Org など）を反映するように変更する必要があります。 コラボレーション アグリーメント 次の図で示すコラボレーション アグリーメントは、ABC WebLogic Integration コンフィグレーションでのみ必要です。コラボレーション アグリーメントを使用すると、XOCP ハブおよびスポーク配信チャネルで説明されているように、ハブ配信チャネルをバイヤのロールのプロキシとして機能させることができます。 図1-9 コラボレーション アグリーメント ABC-ABC
注意: 図1-5 の次の注意で説明されているように、2 つのトレーディング パートナを作成した場合は、前のコラボレーション アグリーメントのバイヤのロールのトレーディング パートナ名が ABC International-Spoke に変更されます。 次の図で示すコラボレーション アグリーメントは、ABC と XYZ 双方の WebLogic Integration コンフィグレーションで必要です。 図1-10 コラボレーション アグリーメント ABC-XYZ
仕組み 次の図では、ABC International と XYZ Systems による Query Price and Availability（QPA）メッセージを WebLogic Integration がサポートする仕組みを示します。 図1-11 QPA コラボレーションの概要 : XOCP ピア ツー ピア
注 1 注 2 XOCP 仲介メッセージング この例では、コンピュータ メーカーの ABC International は、注文管理トランザクションの仲介者として IntCo との契約を予定しています。チップ サプライヤ 2 社、TUV Corporation と XYZ Systems は、IntCo と契約しています。 IntCo は、Query Price and Availability（QPA）トランザクションで、ABC International とチップ サプライヤ 2 社の間の仲介者として機能します。IntCo は、会話のロールに直接には参加しませんが、ABC International とサプライヤの間のトランザクションの仲介者として振る舞います。 ABC International はバイヤで、2 つのトランザクションの開始者です。メッセージの交換には XOCP プロトコルを使用しています。すべての参加者には、WebLogic Integration がインストールされています。 次の節では、以下の方法の例を示します。
ABC International のハブ配信チャネル（XOCP-hub-dc）は、サプライヤのロールに送信されたメッセージを受信します。XOCP ハブおよびスポーク配信チャネルで説明されているように、XOCP-hub-dc でバイヤのロールが割り当てられているすべてのコラボレーション アグリーメントが識別されます。ここでは、一方のコラボレーション アグリーメント Query-Price ABC-XYZ がその条件に合致しています。このアグリーメントを基に、サプライヤのロールに割り当てられた XYZ Systems の配信チャネル（http://xyz.com/xocp-spoke-transport の XYZ Systems XOCP-spoke-dc）にメッセージが配信されます。
ABC International のハブ配信チャネル（XOCP-hub-dc）は、バイヤのロールに送信されたメッセージを受信します。XOCP-hub-dc でサプライヤのロールが割り当てられているすべてのコラボレーション アグリーメントが識別されます。ここでは、一方のコラボレーション アグリーメント Query-Price ABC-ABC がその条件に合致しています。このアグリーメントを基に、バイヤのロールに割り当てられた XYZ Systems の配信チャネル（http://abc.com/xocp-spoke-transport の ABC International XOCP-spoke-dc）にメッセージが配信されます。
必要なプライベートおよび協調的（パブリック）ワークフローが作成されていることを前提とします。この例の協調的ワークフローは、それぞれ QPA_Public_Supplier および QPA_Public_Buyer という名前です。Studio（B2B Integration プラグインで提供されている拡張機能付き）の使用の詳細については、『B2B Integration ワークフローの作成』を参照してください。
トレーディング パートナ
トレーディング パートナは、次のようにコンフィグレーションする必要があります。
注意: 簡略化のために、この例では SSL または署名による証明書を使用しません。セキュリティ コンフィグレーションの詳細については、『B2B Integration セキュリティの実装』を参照してください。
次の図では、ABC、TUV、および XYZ の WebLogic Integration コンフィグレーションで必要な IntCo のトレーディング パートナ定義をまとめています。
図1-12 ABC、TUV、XYZ コンフィグレーションでの IntCo トレーディング パートナ定義
トレーディング パートナのタイプ（「General」ボックス内）は Remote で、コンフィグレーションには、ハブのみの配信チャネル（XOCP-hub-dc）、ドキュメント交換（XOCP-hub-de）、転送（XOCP-hub-transport）が定義されています。転送は、配信チャネル エンドポイントとして機能する URI（http://intco.com/xocp-hub-transport）に関連付けられています。 IntCo コンフィグレーションの IntCo トレーディング パートナ定義は、前の図の定義と同じにします。ただし、IntCo WebLogic Integration コンフィグレーションのトレーディング パートナのタイプ（「General」ボックス内）を Local に設定する必要があります。 他の各トレーディング パートナは、自身の WebLogic Integration コンフィグレーションの一部として固有のトレーディング パートナ定義を提供する必要があります。 次の図では、TUV Corporation コンフィグレーションで必要な TUV Corporation のトレーディング パートナ定義をまとめています。 図1-13 TUV コンフィグレーションでの TUV Corporation トレーディング パートナ定義
トレーディング パートナのタイプは Local で、コンフィグレーションには、スポーク配信チャネル（XOCP-spoke-dc）、ドキュメント交換（XOCP-spoke-de）、転送（XOCP-spoke-transport）が定義されています。転送は、配信チャネル エンドポイントとして機能する URI（http://tuv.com/xocp-spoke-transport）に関連付けられています。 次の図では、XYZ コンフィグレーションで必要な XYZ Systems のトレーディング パートナ定義をまとめています。 図1-14 XYZ コンフィグレーションでの XYZ Systems トレーディング パートナ定義
トレーディング パートナのタイプは Local で、コンフィグレーションには、スポーク配信チャネル（XOCP-spoke-dc）、ドキュメント交換（XOCP-spoke-de）、転送（XOCP-spoke-transport）が定義されています。転送は、配信チャネル エンドポイントとして機能する URI（http://xyz.com/xocp-spoke-transport）に関連付けられています。 次の図では、ABC コンフィグレーションで必要な ABC International のトレーディング パートナ定義をまとめています。 図1-15 ABC コンフィグレーションでの ABC International トレーディング パートナ定義
トレーディング パートナのタイプは Local で、コンフィグレーションには、スポーク配信チャネル（XOCP-spoke-dc）、ドキュメント交換（XOCP-spoke-de）、転送（XOCP-spoke-transport）が定義されています。転送は、配信チャネル エンドポイントとして機能する URI（http://abc.com/xocp-spoke-transport）に関連付けられています。 IntCo WebLogic Integration コンフィグレーションでの XYZ、TUV、ABC トレーディング パートナ定義の要件は、トレーディング パートナのタイプを除けば、上記のリストとまったく同じです。IntCo WebLogic Integration コンフィグレーションの XYZ、TUV、ABC では、トレーディング パートナは Remote に設定されます。 会話定義 次の図では、IntCo WebLogic Integration コンフィグレーションの Query Price and Availability（QPA）会話用に定義する情報をまとめています。 図1-16 QPA 用の会話定義
ABC、TUV、XYZ の WebLogic Integration コンフィグレーションの会話定義は同じです。ただし、BPM オーガニゼーション（「WLPI organization」として示されている部分）を、各企業で定義されたオーガニゼーションを反映するように変更する必要があります。 コラボレーション アグリーメント 次の図で示すコラボレーション アグリーメントは、IntCo WebLogic Integration コンフィグレーションで必要です。コラボレーション アグリーメントを使用すると、XOCP ハブおよびスポーク配信チャネルで説明されているように、IntCo ハブ配信チャネルをバイヤのロールのプロキシとして機能させることができます。 図1-17 コラボレーション アグリーメント IntCo-to-Supplier
注意: IntCo では、前の図のように 1 つのアグリーメントをコンフィグレーションすることも、サプライヤごとに 1 つずつの 2 つのアグリーメントをコンフィグレーションすることもできます。2 つのアグリーメントをコンフィグレーションする場合、適切なトレーディング パートナで使用するためにそれぞれをエクスポートすることができます。 対応するアグリーメントは、TUV コンフィグレーションおよび XYZ コンフィグレーションで必要です。TUV コンフィグレーションのコラボレーション アグリーメントを次の図に示します。 図1-18 TUV-IntCo のコラボレーション アグリーメント
XYZ コンフィグレーションで必要なアグリーメントを次の図に示します。 図1-19 コラボレーション アグリーメント XYZ-IntCo
次の図で示すコラボレーション アグリーメントは、IntCo WebLogic Integration コンフィグレーションで必要です。コラボレーション アグリーメントを使用すると、XOCP ハブおよびスポーク配信チャネルで説明されているように、IntCo ハブ配信チャネルをサプライヤのロールのプロキシとして機能させることができます。 図1-20 コラボレーション アグリーメント IntCo-to-Buyer
この図のアグリーメントは、ABC コンフィグレーションでも必要です。 仕組み 次の図は、ABC International と 2 つのサプライヤ（TUV Corporation および XYZ Systems）の間の Query Price and Availability メッセージの交換を IntCo が仲介する仕組みを示します。 図1-21 IntCo が仲介する QPA コラボレーション
ABC QPA_Public_Buyer ワークフローの Send QPA アクションによってサプライヤのロールに送信されたメッセージは、ABC コンフィグレーションのコラボレーション アグリーメントで指定した IntCo ハブ配信チャネルに転送されます。 IntCo ハブ配信チャネル（XOCP-hub-dc）が、サプライヤ ロールに送信されたメッセージを受信すると、XOCP-hub-dc がバイヤのロールに割り当てられている Query-Price 会話定義が識別されます。ここでは、一方のコラボレーション アグリーメント Query-Price IntCo-to-Supplier がその条件に合致しています。このアグリーメントを基に、TUV Corporation の配信チャネル（http://tuv.com/xocp-spoke-transport の XOCP-spoke-dc）と XYZ Systems の配信チャネル（http://xyz.com/xocp-spoke-transport の XOCP-spoke-dc）にメッセージが配信されます。 TUV または XYZ の QPA_Public_Supplier ワークフローの Send Reply アクションによってバイヤのロールに送信されたメッセージは、各コンフィグレーションで定義されているコラボレーション アグリーメントで指定した IntCo ハブ配信チャネルに送信されます。 IntCo ハブ配信チャネル（XOCP-hub-dc）が、バイヤ ロールに送信されたメッセージを受信すると、XOCP-hub-dc がサプライヤのロールに割り当てられている Query-Price 会話定義が識別されます。ここでは、一方のコラボレーション アグリーメント Query-Price IntCo-to-Buyer がその条件に合致しています。このアグリーメントを基に、ABC International の配信チャネル（http://abc.com/xocp-spoke-transport の XOCP-spoke-dc）にメッセージが配信されます。
RosettaNet アプリケーション
この例は、XOCP ピア ツー ピア メッセージングで説明したのと同じ状況です。コンピュータ メーカーの ABC International、チップ サプライヤの XYZ Systems という 2 つのトレーディング パートナが、WebLogic Integration から Query Price and Availability（QPA）トランザクションに参加します。ここでは、トレーディング パートナは、RosettaNet プロトコルを使用しており、PIP 3A2 を利用してパブリック プロセスを実行します。
Partner Interface Processes（PIP）に参加しているトレーディング パートナは、PIP の各ロールで定義されたパブリック プロセスを実装し、プライベート プロセスとワークフローに加えて、パブリック プロセスに内部システムを接続する必要があります。
WebLogic Integration で提供された PIP 3A2 テンプレートがカスタマイズされ、必要に応じて内部システムと会話するプライベート プロセスに接続されていることを前提とします。この例の協調的ワークフローは、それぞれ PIP3A2_Product_Supplier および PIP3A2_Customer という名前です。
Studio（B2B Integration プラグインで提供されている拡張機能付き）を使用する際の一般的な情報については、『B2B Integration ワークフローの作成』を参照してください。WebLogic Integration で提供されている PIP テンプレートのカスタマイズと RosettaNet セキュリティのコンフィグレーションについては、『B2B Integration RosettaNet の実装』を参照してください。
次の節では、以下の方法の例を示します。
注意: WebLogic Integration ドメインで RosettaNet を使用する前に、『B2B Integration RosettaNet の実装』の「環境の設定」の説明に従ってドメインの設定を変更する必要があります。
トレーディング パートナ
ABC International と XYZ Systems 双方のトレーディング パートナ定義を提供する必要があります。
注意: 簡略化のために、この例では SSL または署名による証明書を使用しません。セキュリティ コンフィグレーションの詳細については、『B2B Integration セキュリティの実装』を参照してください。
次の図では、ABC コンフィグレーションの ABC International トレーディング パートナ用に定義する情報をまとめています。
図1-22 ABC コンフィグレーションでの ABC International トレーディング パートナ定義
トレーディング パートナのタイプ（「General」ボックス内）は Local で、コンフィグレーションには、単独の RosettaNet 配信チャネル（RosettaNet-dc）、ドキュメント交換（RosettaNet-de）、転送（RosettaNet-transport）が定義されています。転送は、配信チャネル エンドポイントとして機能する URI（http://abc.com/rosettanet-transport）に関連付けられています。 XYZ WebLogic Integration コンフィグレーションの ABC トレーディング パートナ定義は、前の図の定義と同じにします。ただし、XYZ WebLogic Integration コンフィグレーションのトレーディング パートナのタイプを Remote に設定する必要があります。 次の図では、XYZ WebLogic Integration コンフィグレーションの XYZ Systems トレーディング パートナ用に定義する情報をまとめています。 図1-23 XYZ コンフィグレーションでの XYZ Systems トレーディング パートナ定義
トレーディング パートナのタイプは Local で、コンフィグレーションには、単独の RosettaNet 配信チャネル（RosettaNet-dc）、ドキュメント交換（RosettaNet-de）、転送（RosettaNet-transport）が定義されています。転送は、配信チャネル エンドポイントとして機能する URI（http://xyz.com/rosettanet-transport）に関連付けられています。 ABC WebLogic Integration コンフィグレーションの XYZ トレーディング パートナ定義は、前の図の定義と同じにします。ただし、ABC WebLogic Integration コンフィグレーションのトレーディング パートナのタイプを Remote に設定する必要があります。 会話定義 次の図では、ABC WebLogic Integration コンフィグレーションの Query Price and Availability（QPA）会話定義で必要な設定を示します。 図1-24 PIP 3A2 用の会話定義
XYZ WebLogic Integration コンフィグレーションの会話定義は同じです。ただし、BPM オーガニゼーション（「WLPI organization」として示されている部分）を、XYZ Systems で定義されたオーガニゼーション（XYZ_Org など）を反映するように変更する必要があります。 コラボレーション アグリーメント 次の図で示すコラボレーション アグリーメントは、ABC と XYZ 双方の WebLogic Integration コンフィグレーションで必要です。 図1-25 コラボレーション アグリーメント Query-Price-PIP3A2-ABC-XYZ
仕組み 次の図では、RosettaNet 2.0 を使用した ABC International と XYZ Systems による Query Price and Availability メッセージの交換を WebLogic Integration がサポートする仕組みを示します。 図1-26 QPA コラボレーションの概要 : RosettaNet
cXML アプリケーション（非推奨）
ここでは、トレーディング パートナ、会話定義、コラボレーション アグリーメントをコンフィグレーションする際の cXML 固有の要件について概要を説明します。WebLogic Integration で cXML の実装に使用するアーキテクチャ、cXML セキュリティ、および cXML API の使用方法については、『B2B Integration cXML の実装』を参照してください。
cXML で交換されるドキュメントは、Request、Response、Message という 3 つの基本的な文書型に分類されます。それぞれの基本的な文書型には、サブタイプがあります。たとえば Request には、OrderRequest、PunchOutSetupRequest、SupplierDataRequest、SupplierListRequest、または GetPendingRequest などがあります。Request-Response が一組になって cXML トランザクションを構成します。たとえば、PunchOutSetupRequest と PunchOutSetupResponse が組み合わさって PunchOutSetup トランザクションになります。
各ドキュメントの構造は、特定の文書型および cXML のバージョンに対する cXML DTD に従います。
次の図では、3 種類の文書型の基本構造の例を示します。
図1-27 cXML の文書型
cXML トランザクションに対してトレーディング パートナと会話定義を定義するときに、一部のパラメータに割り当てられた値は、cXML ルートと Header 要素に表示される特定の要素と属性に一致している必要があります。また、会話定義名は cXML トランザクションに一致する必要があり、割り当てられた値は Buyer および Supplier でなくてはなりません。 次の表では、要件を示します。
ebXML アプリケーション
コンピュータ メーカーの ABC International、チップ サプライヤの XYZ Systems という 2 つのトレーディング パートナが、WebLogic Integration から Query Price and Availability（QPA）トランザクションに参加するものとします。ABC International はバイヤで、2 つのトランザクションの開始者です。メッセージの交換には ebXML ビジネス プロトコルを使用しています。WebLogic Integration は ABC International にインストールされ、WebLogic Integration - Business Connect は XYZ Systems にインストールされています。
WebLogic Integration - Business Connect のトレーディングパートナについて
WebLogic Integration - Business Connect がデプロイされるトレーディング パートナは、自らおよびそのトレーディング パートナ用のトレーディング パートナ コンフィグレーション データを格納します。WebLogic Integration と WebLogic Integration - Business Connect トレーディング パートナ間の E ビジネス トランザクションをサポートするのに必要な他のコンフィグレーション データ（会話定義、コレボレーション定義など）は、WebLogic Integration がデプロイされるトレーディング パートナ側に B2B Console を使用して入力する必要があります。WebLogic Integration 環境は、WebLogic Integration トレーディング パートナによって作成されたトレーディング パートナ コンフィグレーション データ ファイルのWebLogic Integration - Business Connect トレーディング パートナによる消費をサポートし、また、その逆もサポートします。
次の節では、以下の方法の例を示します。
トレーディング パートナ
ABC International と XYZ Systems 双方のトレーディング パートナを作成する必要があります。
注意: WebLogic Integrationは、ebXML コラボレーションを遂行するための SSL ベースのセキュア プラットフォームを提供します。セキュリティ設定は、この節で提示する例では明記されていません。セキュリティのコンフィグレーションについては、『B2B Integration ebXML の実装』の「ebXML の管理」の「セキュリティのコンフィグレーション」を参照してください。
WebLogic Integration トレーディング パートナ用のコンフィグレーション
ABC International トレーディング パートナのコンフィグレーション用のデータを次の図にまとめます。
図1-28 ABC International リポジトリでの ABC International トレーディング パートナ定義
注意: ビジネス トランザクションに関与する各トレーディング パートナは、他のトレーディング パートナに対するトレーディング パートナ定義を設定している必要があります。
この場合、ABC International の WebLogic Integration リポジトリには、この図の ABC International トレーディング パートナが格納されています。また、トレーディング パートナのデータは XYZ Systems に送信されます（トレーディング パートナ データの WebLogic Integration リポジトリからのエクスポートについては、B2B Integration コンポーネントのインポートとエクスポートを参照）。
WebLogic Integration - Business Connect トレーディング パートナ用のコンフィグレーション
ABC International は、XYZ Systems のトレーディング パートナ用のトレーディング パートナ データを WebLogic Integration リポジトリにインポートします。
WebLogic Integration - Business Connect によって作成されたトレーディング パートナのプロファイルが WebLogic Integration リポジトリにインポートされると、インポートされたトレーディング パートナの要素は、同等の WebLogic Integration 固有要素にマップされます。
ただし、WebLogic Integration リポジトリで定義する必要のある要素の中には、WebLogic Integration - Business Connect のトレーディング パートナ プロファイルに同等の要素がないものもあります。インポートされたデータから WebLogic Integration 固有要素にマップする値がない場合、それらの要素には、WebLogic Integration によってデフォルト値が割り当てられます。
XYZ Systems のトレーディング パートナのコンフィグレーション用のデータ（WebLogic Integration リポジトリへのインポート後）を次の図にまとめます。
図1-29 ABC International リポジトリでの XYZ Systems トレーディング パートナ定義
上の図で、 トレーディング パートナ要素の以下の指定に注目してください。
インポートされたトレーディング パートナ要素の WebLogic Integration リポジトリへのマッッピングの詳細は、『B2B Integration ebXML の実装』の「ebXML の管理」を参照してください。
会話定義
Query Price and Availability（QPA）会話に対する会話定義は、ABC International の WebLogic Integration リポジトリに作成されます。QPA の会話定義の要素を次の図に示します。
図1-30 QPA 用の会話定義
コラボレーション アグリーメント ABC International、XYZ Systems 間の QPA 会話用のコラボレーション アグリーメントは、ABC International の WebLogic Integration リポジトリに作成されます。コラボレーション アグリーメントの要素を次の図に示します。 図1-31 コラボレーション アグリーメント Query-Price-ABC-XYZ
ebXML ベースの会話定義に関連付けられたロールが必ず 2 つ存在する点に注意してください。これらのロールには、initiator と participant という定義済みの名前があります。 WebLogic Integration - Business Connect デプロイ時のコンフィグレーション上の考慮事項 この節では、WebLogic Integration をデプロイするトレーディング パートナが、トレーディング パートナ軽量クライアント、すなわち、WebLogic Integration - Business Connect とのビジネス トランザクションにかかわる場合の、コンフィグレーション情報について説明します。内容は以下のとおりです。
WebLogic Integration - Business Connect でのセキュリティおよび暗号化のコンフィグレーション
WebLogic Integration - Business Connect とWebLogic Integration の相互運用には、WebLogic Integration - Business Connect をデプロイするトレーディング パートナのコンフィグレーションを行う際に、セキュリティと暗号化のオプションをオフにする必要があります
WebLogic Integration - Business Connect トレーディング パートナに対するセキュリティと暗号化のオプションをオフにするには、次の手順に従います。
WebLogic Integration の Business Connect クライアントのコンフィグレーションに関する情報については、『Using WebLogic Integration - Business Connect』または WebLogic Integration の Business Connect Administrator ツールのオンライン ヘルプを参照してください。
WebLogic Integration と WebLogic Integration - Business Connect 間での SSL の使用法
WebLogic Integration環境では、各企業は、トレーディング パートナとの E ビジネス会話にかかわる上で必要な、トレーディング パートナに対する仕様、会話定義、コラボレーション アグリーメント、およびワークフローを、それぞれのリポジトリに入力します。WebLogic Integration には、このコンフィグレーション データをトレーディング パートナ間で交換するためのツールが備わっています。これらのツールは、トレーディング パートナの 1 つが WebLogic Integration - Business Connect をデプロイする場合にも使用できます（詳細は、『B2B Integration ebXML の実装』、「はじめに」の「ebXML メッセージ機能を使用するための環境コンフィグレーション」を参照）。
ただし、トレーディング パートナ間のビジネス トランザクションに SSL を使用する場合、その一方が WebLogic Integration - Business Connect をデプロイしようとしているときは、WebLogic Integration 環境の外部で必要な証明書を交換する必要があります。SSL の使用法については、『B2B Integration ebXML の実装』の「ebXML の管理」の「セキュリティのコンフィグレーション」を参照してください。
ブラウザ クライアント（非推奨）
トレーディング パートナが、会話に参加するためにバックエンド システムとの統合をほとんど、あるいはまったく必要としない場合もあります。この場合、トレーディング パートナは、WebLogic Integration をインストールしていなくてもかまいません。WebLogic Integration をインストールしているトレーディング パートナはホストとして、小規模なトレーディング パートナが、Web ブラウザまたはファイル共有クライアントを介して、認可された会話にサブスクライブおよび参加できるようにします。
トレーディング パートナにバックエンド システムと統合する必要性がない場合、そのパートナがブラウザ クライアントとして参加できるようにコンポーネントをホストすることが適切な方法です。ファイル共有クライアントには多くの場合、バックエンド システム統合の要件があります。また通常、ファイル共有クライアントは、ブラウザ クライアントの場合よりも多くのメッセージを処理します。
ここでは、ブラウザ クライアントをサポートするための要件について説明します。次の節では、ファイル共有クライアントをサポートするための要件について説明します。
会話メッセージをブラウザ クライアントに表示する前に、ブラウザ エンドポイントで使用できる形式にメッセージを変換するための処理が必要です。この処理は、トレーディング パートナを代表してホストされる必要があります。
次の図では、トレーディング パートナのホスティングに必要な要素の概略を示します。
図1-32 ブラウザ クライアント ホスト
要求された Java Server Page（JSP）、サーブレット、スタイル シート、静的 HTML ページ、JSP タグ ライブラリ、スクリプト、アプレットを含む Web アプリケーションは、ブラウザ クライアントにインタフェースを提供します。 ブラウザ クライアント メッセージに対して信頼性のある、セキュリティ保護されたストレージを提供する受信および送信メールボックスは、Web アプリケーションによって JSP タグ ライブラリのタグで作成されます。JSP タグ ライブラリは、WebLogic Integration に含まれています。JSP タグ ライブラリは、メールボックスに対するインタフェースを提供し、メールボックスの作成および削除をサポートし、格納されたメッセージをブラウザ クライアントが管理できるようにします。 メールボックスの作成には、CreatemboxTag が使用されます。メールボックスは、次のように命名する必要があります。
ワークフローは、メールボックスと B2B エンジンの間のインタフェースを提供します。メールボックスと会話するワークフローは、協調的ワークフローを開始する、または協調的ワークフローで開始されるプライベート ワークフローと見なされるため、トレーディング パートナのロールを実装する協調的ワークフローになることができます。
適切な形式の XML メッセージは、以下の間で交換されます。
メッセージは次のように交換されます。
WebLogic Integration には、ブラウザ クライアント サンプルが含まれています。提供されたサンプル Web アプリケーションの主要なコンポーネントとワークフローは、ブラウザ クライアントに対するサポートを実装するために、カスタマイズしたり、そのまま再利用することが可能です。サンプル Web アプリケーションのコンポーネントのカスタマイズについては、『B2B Integration サンプルの使い方』の「Trading Partner Lightweight Client サンプル」を参照してください。
必要な JSP ページを開発し、説明に従って他のコンポーネントを変更すると、Web Application aRchive（WAR）ファイル形式にコンポーネントをパッケージ化して、必要に応じて WebLogic Server でデプロイできるようになります。
次の例では、ブラウザ クライアントをサポートするために定義する必要がある情報を示します。
ブラウザ クライアントのホスティング
この例の状況は、RosettaNet アプリケーションで説明したものと同様です。コンピュータ メーカーの ABC International、チップ サプライヤの XYZ Systems という 2 つのトレーディング パートナが、Query Price and Availability（QPA）トランザクションに参加します。ここでは、ABC International は、XYZ Systems がブラウザ クライアントとして参加できるようにするのに必要なコンポーネントをホストします。
協調的およびプライベート顧客ワークフロー、PIP3A2_Customer と PIP3A2_Private_Customer は、RosettaNet の例で使用するワークフローと同じです。製品サプライヤ ロールの協調的およびプライベート ワークフロー、PIP3A2_Product_Supplier と PIP3A2_Private_Web_Product_Supplier は、ブラウザ クライアントとして XYZ Systems をサポートするようにカスタマイズされていることを前提とします。
すべてのワークフローは、ABC International システムでホストされます。
ホスト システム ABC International では、以下の要素がコンフィグレーションされます。
XYZ Systems のトレーディング パートナ定義は、図1-23 で示された定義と同じですが、以下の部分が異なっています。
PIP3A2_Customer ワークフローと PIP3A2_Product_Supplier ワークフローの間のメッセージ交換は、図1-26 で示されたものと同じです。ただし、この例では、メッセージ交換は同じ WebLogic Integration インスタンス内で行われます。
XYZ Systems をブラウザとしてサポートするのに必要な処理は、Web アプリケーションと PIP3A2_Private_Web_Product_Supplier ワークフローで発生します。このワークフローは、以下を実行します。
次の図では、開始ノードでメッセージが受信されてから、PIP3A2_Private_Web_Product_Supplier ワークフローの Send Reply タスクが実行されるまでの間に実行されるアクションの概略を示します。
図1-33 QPA コラボレーションの概要 : ブラウザ クライアント
ファイル共有クライアント（非推奨）
前の節で説明したように、WebLogic Integration を持つトレーディング パートナは、バックエンド システムとの統合をほとんど、あるいはまったく必要としない他のトレーディング パートナのホストとして機能できます。
トレーディング パートナにバックエンド システムと統合する必要性があまりない場合、そのパートナがファイル共有クライアントとして参加できるようにコンポーネントをホストすることが適切な方法です。ファイル共有クライアントは多くの場合、ブラウザ クライアントの場合よりも多くのメッセージを処理します。
前の節では、ブラウザ クライアントをサポートするための要件について説明しました。ここでは、ファイル共有クライアントをサポートするための要件について説明します。
会話メッセージをファイル共有クライアントに表示する前に、ファイル共有エンドポイントで使用できる形式にメッセージを変換するための処理が必要です。この処理は、トレーディング パートナを代表してホストされる必要があります。
次の図では、トレーディング パートナのホスティングに必要な要素の概略を示します。
図1-34 ファイル共有ホスト
WebLogic Integration は、ファイル共有デーモンを提供します。ファイル共有デーモンは、受信および送信メールボックスを持つローカル ファイル システム上で、受信ディレクトリのファイルと送信ディレクトリのファイルを次のように同期させます。
顧客かサード パーティのどちらかで提供された FTP クライアントは、ファイル システム上の受信および送信ディレクトリに対するインタフェースとして機能します。受信および送信ディレクトリのメッセージ ファイルを、ファイル共有クライアント ロケーションのファイル システムに転送するメカニズム、およびメッセージへの送信または返信に必要な処理は、ファイル共有クライアントによって実装されます。
次の例では、ファイル共有クライアントをサポートするために定義する必要がある情報を示します。
ファイル共有クライアントのホスティング
この例の状況は、ブラウザ クライアント（非推奨）で説明したのと同じです。コンピュータ メーカーの ABC International、チップ サプライヤの XYZ Systems という 2 つのトレーディング パートナが、Query Price and Availability（QPA）トランザクションに参加します。ここでは、ABC International は、XYZ Systems がファイル共有クライアントとして参加できるようにするのに必要なコンポーネントをホストすることに同意しています。
協調的およびプライベート顧客ワークフロー、PIP3A2_Customer と PIP3A2_Private_Customer は、ブラウザ クライアントの例で使用するワークフローと同じです。製品サプライヤ ロールの協調的およびプライベート ワークフロー、PIP3A2_Product_Supplier と PIP3A2_Private_FTP_Product_Supplier は、ファイル共有クライアントとして XYZ Systems をサポートするようにカスタマイズされていることを前提とします。
すべてのワークフローは、ABC International システムでホストされます。
ABC International は、ドメインに対する config.xml ファイルを変更し、ファイル共有デーモンに対するコンフィグレーション ファイルを編集します。必要な変更については、『B2B Integration サンプルの使い方』、「Trading Partner Zeroweight Client サンプル」の「Zeroweight Client のコンフィグレーション」を参照してください。
ホスト システム ABC International では、以下の要素がコンフィグレーションされます。
XYZ Systems のトレーディング パートナ定義は、図1-23 で示された定義と同じですが、以下の部分が異なっています。
PIP3A2__Customer ワークフローと PIP3A2__Product Supplier ワークフローの間のメッセージ交換は、図1-26 で示されたものと同じです。ただし、この例では、メッセージ交換は同じ WebLogic Integration インスタンス内で行われます。
XYZ Systems をファイル共有クライアントとしてサポートするのに必要な処理は、ファイル共有ロケーションと PIP3A2_Private_FTP_Product_Supplier ワークフローで発生します。このワークフローは、以下を実行します。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
