アグリーメントの作成とデプロイは、Oracle B2Bプロセス・フローの最後のステップです。
この章の内容は次のとおりです。
詳細は、次を参照してください:
アグリーメントをエクスポートし、デプロイメントの状態を管理する方法はデプロイメントの管理 ,
アグリーメントをエクスポートする方法は データのインポートおよびエクスポート ,
アグリーメントは、ホスト取引パートナおよび1つのリモート取引パートナの2つの取引パートナで構成され、これらのパートナ間におけるビジネス・トランザクションのタイプを表します。
たとえば、Acme社とGlobalChips社がEDIFACTとRosettaNetの相互の交換に参加している場合は、各交換についてアグリーメントを作成します。交換が双方向の場合は、各方向についてアグリーメントが必要です。汎用ファイル・プロトコルを使用して送信するカスタム・ドキュメントを使用して、Acme社が販売オーダーをGlobalChips社に送信する場合は、Acme社がオーダーを送信するアウトバウンド方向のアグリーメント、およびAcme社が受信者になるインバウンド方向のアグリーメントを作成します。アグリーメントのコンポーネントに対する変更(ドキュメント定義の変更など)は、そのアグリーメントで自動的に有効になります。
アグリーメントの作成は、B2Bトランザクションの設計の最終ステップです。アグリーメントを作成する前に、ドキュメント定義の作成と取引パートナの構成を完了しておく必要があります。詳細は、 ドキュメント定義の作成,および 取引パートナの構成 を参照してください。
この項では、2つの取引パートナ間のアグリーメントを作成するために必要な手順全体を示します。
図6-1に、アグリーメントを使用するためのOracle B2Bインタフェースを示します。リモート取引パートナのアグリーメントをホスト取引パートナとともに確認するには、リモート取引パートナ名をクリックします。
図6-2に、アグリーメントを作成する手順を示します。
手順1: リモート取引パートナの識別
ホスト取引パートナはアグリーメントに自動的に含まれるため、リモート取引パートナのみを識別する必要があります。これを行うには、次の2つの方法があります。1つは、「パートナ」リージョンからパートナを選択してアグリーメントを追加する方法です。もう1つは、ホスト取引パートナを選択して、「アグリーメント」リージョンの「追加」をクリックし、「新規アグリーメント」リージョンの「パートナの選択」ボタンをクリックする方法です。
手順2: ドキュメント定義の選択
ドキュメント定義はホスト取引パートナに対して選択します。図6-3に示すように、選択内容は「ドキュメント定義の選択」ダイアログに反映されます。
アウトバウンドとインバウンドの両方のアグリーメントが必要になる交換の場合は、次の手順を実行します。
手順3: アグリーメントのIDと名前の指定
アグリーメント識別子とアグリーメント名を指定します。これらのフィールドには同じ値を指定できます(追跡するために同じ値にする必要がある場合)。
手順4: 検証、変換および機能確認のオプションの選択
表6-1では、アグリーメントの作成時に設定可能な検証、変換および機能確認のオプションについて説明します。
表6-1 アグリーメントのオプション
オプション | 説明 |
---|---|
検証 |
構成済のECSファイルに対してドキュメントの検証を有効にする場合に選択します。 |
変換 |
XMLからネイティブ・フォーマットへの変換、またはその逆の変換(例: EDIとHL7の間の変換)を有効にする場合に選択します。「トランスレーション」が選択されていない場合(トランスレーションなし)は、「B2BでFAを処理」プロパティの値に関係なく、B2Bで機能確認を含むビジネス・メッセージを相関付けることはできません。プロパティの詳細は、「Fusion Middleware Controlで設定するプロパティ」を参照してください。 |
機能確認 |
成功またはエラーの条件に対して機能確認を有効にする場合に選択します。 |
自動処理されるFA |
trueに設定すると、B2BでインバウンドEDIおよびHL7メッセージの機能確認(FA)メッセージが自動生成されます。インバウンドFAメッセージが使用されるのは、このオプションがtrueの場合です。このオプションをfalseに設定すると、B2BでFAドキュメントは自動生成されません。バックエンド・アプリケーション(ミドルウェア)がFAを生成し、アウトバウンド・メッセージとしてB2Bに提供する必要があります。このオプションを「false」に設定すると、インバウンドFAドキュメントはバックエンド・アプリケーションに戻されます。 (アグリーメント・レベルの設定が示すとおり)ドキュメントにFAが必要ない場合、このオプションは無視されます。このプロパティのデフォルト値はtrueです。 詳細は、「Fusion Middleware Controlで設定するプロパティ」を参照してください。 「自動処理される機能確認」をfalseに設定する場合は、バックエンド・アプリケーションに送信するインバウンドFAに対する「インバウンド機能確認の通知」もfalseに設定する必要があります。(「自動処理される機能確認」がfalseに設定されているときに)「インバウンド機能確認の通知」をtrueに設定すると、着信997 (FAドキュメント)によって通知のみが生成され、着信997自体はバックエンド・アプリケーションに戻されません。 |
ドキュメント再試行間隔 |
ドキュメント再試行間隔の時間を分単位で入力します。再試行の構成の詳細は、配信再試行オプションの構成を参照してください。 |
ドキュメント再試行数 |
メッセージを再試行する回数を入力します。再試行の構成の詳細は、配信再試行オプションの構成を参照してください。 |
手順5: リモート取引パートナのチャネルの選択
リモート取引パートナの設定時に作成したチャネルのリストが表示されます(リスニング・チャネルはアグリーメントに含まれません)。
手順6: 識別子の追加
ホスト取引パートナおよびリモート取引パートナの識別子タイプがリストされます。このアグリーメントに適用する識別子を選択します。複数の識別子を選択するには、[Shift]キーを押しながら識別子をクリックします。
アウトバウンド・アグリーメントについては、表6-2にリストされている識別子タイプを交換プロトコルとともに使用します。
表6-2 交換プロトコルとともに使用する識別子タイプ
交換プロトコル | 識別子タイプ |
---|---|
Generic File-1.0 |
名前 |
Generic FTP-1.0 |
名前 |
Generic SFTP-1.0 |
名前 |
Generic AQ-1.0 |
名前 |
Generic JMS-1.0 |
名前 |
AS2 - 1.1 |
名前、AS2識別子 |
AS1-1.0 |
名前、AS1識別子 |
ebMS-1.0、ebMS-2.0 |
名前、ebMS識別子 |
RosettaNet-V02.00、RosettaNet-01.10 |
名前、DUNS |
MLLP交換 |
名前、MLLP ID |
Generic HTTP-1.0 |
名前、汎用識別子 |
Generic Email-1.0 |
名前、汎用識別子 |
識別子のタイプの詳細は、「タイプの作成」を参照してください。
手順7: アグリーメントの保存と検証
「保存」をクリックすると、アグリーメントが保存されて検証されます。
アグリーメントを作成するには:
アグリーメントの作成が完了すると、デプロイの準備が整います。アグリーメントは、「管理」→「デプロイ」ページにリストされます。「アグリーメントのデプロイ」を参照してデプロイを続行します。
デプロイメントは、アグリーメントを設計時リポジトリから実行時リポジトリにアクティブ化するプロセスです。
アグリーメントをデプロイした後に、「デプロイメントの管理」タブおよび「レポート」タブを使用します。詳細は、次を参照してください:
アグリーメントの作成、保存および検証を行った後は、次の方法でアグリーメントをデプロイできます。
同じページ(「パートナ」→「アグリーメント」タブ)から、「デプロイ」ボタンを使用します(図6-1を参照)
図6-4に示すように、「管理」→デプロイ・ページからデプロイします。複数のアグリーメントを選択して同時にデプロイする場合は、この方法でデプロイします。
注意:
プロパティb2b.deploy.validation=false
を設定して、デプロイメント中は検証をオフにします。
このプロパティは、Oracle Enterprise Manager Fusion Middleware Controlで設定します。プロパティを変更する場合は、SOAサーバーを再起動する必要があります。詳細は、「Fusion Middleware Controlで設定するプロパティ」を参照してください。
「デプロイ」タブからアグリーメントをデプロイするには: