| Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド 11g リリース1（11.1.1.4.0） B61381-02 |
|
 戻る |
 次へ |
図5-1に示すように、Oracle B2Bプロセス・フローの3番目のステップは、取引パートナの構成です。
取引パートナの構成で行う作業には、取引パートナ・プロファイルの作成（識別子、コンタクト情報、取引パートナ・パラメータおよびキー・ストア情報の値の指定）、取引パートナ・ユーザーの追加、ドキュメント定義の追加、送信者ロールと受信者ロールの割当て、チャネルの詳細（セキュリティなど）の構成があります。
項目は次のとおりです。
Oracle B2Bのトランザクションには、2つの取引パートナ（ホスト取引パートナとリモート取引パートナ）が必要です。ホスト取引パートナは、通常、Oracle B2Bがインストールされている組織です。リモート取引パートナは、ホスト取引パートナがE-Businessトランザクションを行う相手組織です。トランザクションに参加する取引パートナには、ホスト（バックエンド）アプリケーション、データベース、顧客があります。トランザクションの起動側またはレスポンダには、ホスト取引パートナまたはリモート取引パートナを指定できます。
ホスト取引パートナ組織は、ホスト・パートナとリモート・パートナを含むすべての取引パートナを構成します。リモート・パートナは、ホスト取引パートナによってリモート取引パートナごとに作成された取引パートナ・ユーザーを使用して、Oracle B2B内の自社データにアクセスできます。図5-2に、取引パートナを構成するステップを示します。
Oracle B2Bには、デフォルトのホスト取引パートナ名「会社」が用意されています。このデフォルトを更新して、自社を反映させることができます。1つ以上のリモート取引パートナを作成した後、クローニング機能を使用して、類似したトランザクションに参加する新しい取引パートナを作成します。クローニングすると、ソース取引パートナのドキュメント定義とデリバリ・チャネル（MLLPチャネルを除く）はコピーされますが、識別子、コンタクトおよびユーザーはコピーされません。取引パートナを新規に作成する際にデリバリ・チャネル名を変更してください。
取引パートナを作成および構成すると、その情報はOracleメタデータ・リポジトリの取引パートナ・プロファイルとして保存されます。パートナ・データは、「プロファイル」タブの「エクスポート」ボタンを使用して、ZIPファイルにエクスポートできます。
取引パートナ・プロファイルを作成する手順は、次のとおりです。
これは、Oracle B2Bの設定時に最初に実行します。
「パートナ」リンクをクリックします。
「会社」をクリックします。
図5-3に示すように、「編集」をクリックします。
ホスト取引パートナ名とオプションのアイコン・ファイルを入力し、「OK」をクリックします。
オプションのアイコン・ファイルは、16x16ピクセルのPNGファイルである必要があります。
ホスト取引パートナ名が「パートナ」リストに表示されます。
「パートナ」リンクをクリックします。
図5-4に示すように、「追加」をクリックします。
パートナ名を入力して「OK」をクリックします。
リモート取引パートナ名が「パートナ」リストに表示されます。
（オプション）「編集」をクリックし、図5-5に示すように、リモート取引パートナのアイコンとして16x16ピクセルのPNGファイルを追加して、「OK」をクリックします。
このタスクを実行する別の方法として、クローン機能の使用があります。作成する取引パートナに類似している取引パートナがすでに作成されている場合は、図5-6に示すように、「クローン」アイコンをクリックし、クローニングされていない取引パートナ情報（識別子、コンタクトおよびユーザー）を入力します。
|
注意: リモート取引パートナを削除するには、「削除」アイコンを使用します。ただし、デプロイ済の取引パートナ・アグリーメントの一部であるリモート取引パートナは削除できません。最初に、アグリーメントを削除する必要があります。 |
識別子タイプを使用すると、実行時にOracle B2Bで取引パートナを識別できます。通常の識別処理では、最初にパートナ、次にドキュメントが識別され、その後パートナとドキュメントの組合せでアグリーメントが識別されます。Oracle B2Bは、各取引パートナにデフォルトの識別子タイプである名前を提供しています。値は取引パートナの名前です。
ホスト取引パートナとリモート取引パートナの両方の識別子タイプと値を追加します。ここで追加するタイプの作成方法は、第10章「タイプの作成」を参照してください。
「パートナ」リンクをクリックします。
「プロファイル」タブをクリックします。
取引パートナを選択します。
図5-7に示すように、「識別子」領域で「追加」をクリックします。
「タイプ」リストから、識別子タイプを選択します。
識別子タイプの詳細は、表10-1「Oracle B2Bに定義されている識別子タイプ」を参照してください。
値を入力します。
「保存」をクリックします。
（オプション）取引パートナのコンタクト情報を追加する場合は、あらかじめシードされているタイプ（コンタクト名、電子メール、FAX、電話）を使用します。「管理」 > 「タイプ」ページでコンタクト・タイプを作成することもできます。詳細は、第10.2項「カスタム・コンタクト情報タイプの作成」を参照してください。
「パートナ」リンクをクリックします。
「プロファイル」タブをクリックします。
「コンタクト情報」領域で「追加」をクリックします。
図5-8に示すように、「タイプ」の下のリストから選択して値を入力します。
「保存」をクリックします。
（オプション）取引パートナ・パラメータと取引パートナの値を追加する場合は、事前に「管理」 > 「タイプ」ページで、パラメータを作成する必要があります（パラメータを作成していない場合、「追加」アイコンは表示されません）。詳細は、第10章「タイプの作成」を参照してください。
「パートナ」リンクをクリックします。
「プロファイル」タブをクリックします。
図5-9に示すように、「パラメータ」領域で「追加」をクリックします。
図5-10に示すように、パラメータを選択して「OK」をクリックします。
「保存」をクリックします。
このページでは、特定の取引パートナの値を更新することもできます。
（オプション）ホスト取引パートナ・セキュリティのキー・ストア・パスワードおよびキー・ストアの場所を追加します。デジタル署名、暗号化またはSSLが有効な場合は、キー・ストアの場所を指定する必要があります。デジタル署名および暗号化を指定する場合は、タスク5: 「セキュリティの構成」を参照してください。セキュリティ・パラメータの詳細は、表5-6を参照してください。
Oracle B2Bのキー・ストアを選択できます。SSLを使用している場合は、B2BとOracle WebLogic Serverの両方のSSL構成に同じキー・ストアを使用して、取引パートナとメッセージを交換する際のSSLに関連する問題を回避してください。
「パートナ」リンクをクリックします。
「プロファイル」タブをクリックします。
ホスト取引パートナを選択します。
図5-11に示すように、「キー・ストア」セクションで、パスワードと場所を指定します。
「保存」をクリックします。
|
注意: 以前に誤ったキー・ストア・パスワードを入力してパスワードを再入力する場合（キー・ストアに接続しようとしてエラーになった場合）は、正しいパスワードを入力した後、サーバーを再起動する必要があります。 |
ホスト取引パートナ管理者（デフォルトのログイン・ユーザー名とパスワードの組合せ）は、ホスト取引パートナおよびリモート取引パートナのユーザーをさらに追加できます。これらのユーザーは、Oracle B2Bにログインして、各自の取引パートナ・データにのみアクセスできます。
次のロールが使用可能です。
管理者ロールを持つユーザーは、自身の取引パートナ・データについてのみ、B2Bのすべての機能にアクセスできます。他の取引パートナのデータは表示されません。監視ロールを持つユーザーは、自身の取引パートナ・データについてのみ、レポート機能にアクセスできます。他のリンク、および他の取引パートナのデータは、表示されません。Oracle B2Bでは、ドキュメント・タイプに基づいたアクセスの制限もサポートしています。詳細は、第1.4.2項「ドキュメント・タイプへのアクセスの制限」を参照してください。
ユーザーを追加する手順は、次のとおりです。
Oracle B2Bでユーザーをプロビジョニングするには、アイデンティティ・ストアにそのユーザーを作成する必要があります。ユーザーを作成するには様々なツールを使用できますが、その1つとして、図5-12に示すように、Oracle WebLogic Server管理コンソールの「セキュリティ・レルム」機能を使用する方法があります。
図5-12 Oracle WebLogic Server管理コンソール: 「セキュリティ・レルム」
|
注意: Oracle B2Bを管理対象サーバーで実行している場合は、デフォルトのファイルベースのポリシー・ストアがサポートされないため、LDAPベースのポリシー・ストアを使用することをお薦めします。 |
myrealm設定の「ユーザーとグループ」タブに、そのレルム内のすべてのユーザーを含むテーブルが表示されます。「新規」をクリックし、図5-13に示すページでユーザーおよびユーザー・パスワードを追加します。
図5-13 Oracle WebLogic Server管理コンソール: 新しいユーザーの追加
デフォルトの管理者はユーザーを追加できます。ホスト管理者およびリモート管理者は、デフォルトの管理者によって権限が付与されている場合は、ユーザー（各自のデータのみに対するリモート管理者）を追加できます。
デフォルトの管理者は、ユーザーにドキュメント・タイプを追加できます。ホスト管理者およびリモート管理者は、デフォルトの管理者によって権限が付与されている場合は、ユーザー（各自のデータのみに対するリモート管理者）に対してドキュメント・タイプを追加できます。ドキュメント・タイプをここで追加しなかった場合、ユーザーはすべてのドキュメント・タイプにアクセスできるようになります。
Oracle B2Bのホスト管理者は、すべてのドキュメント定義を作成します。作成したドキュメント定義はホスト取引パートナに自動的に割り当てられます。ホスト管理者は、ドキュメント定義をリモート取引パートナに割り当てることができます。ホスト取引パートナとリモート取引パートナの両方について、各ドキュメントの送信者と受信者を識別する必要があります。
ドキュメント定義を追加した後でその定義を更新する方法は、第8.9項「ドキュメントの詳細の変更」を参照してください。
|
注意: ホスト取引パートナに自動的に関連付けられているドキュメント定義を（「管理」 > 「ドキュメント」で）削除する場合は、その前に、ホスト取引パートナ・プロファイル（およびリモート取引パートナ・プロファイル）からその定義を削除する必要があります。 |
Acme（購入者）がGlobalChipsに発注を送信するシナリオを考えてみます。Acmeでは、このトランザクションの一環としてGlobalChips（販売者）が発注を受信したことを示す確認を受信します。したがって、このEDIFACTトランザクションでは、2つのドキュメント定義（発注のドキュメント定義と機能確認のドキュメント定義）が使用されます。GlobalChipsは、発注を受信して確認を送信します。
取引パートナ・プロファイルに追加するために必要となるドキュメント定義の作成の詳細は、第4章「ドキュメント定義の作成」を参照してください。
ドキュメント定義を追加する手順は、次のとおりです。
ホスト取引パートナ・プロファイルとリモート取引パートナ・プロファイルの両方に、ドキュメント定義を追加します。このページでは、リモート取引パートナのドキュメント・タイプ・パラメータやドキュメント・バージョン・パラメータを変更することもできます。詳細は、第8章「ドキュメント・プロトコルの使用」を参照してください。
「バージョン・パラメータのオーバーライド」および「DocTypeパラメータのオーバーライド」パラメータの使用を含めた、リモート取引パートナに対するドキュメント・プロトコル・バージョンおよびドキュメント・タイプ・パラメータの変更方法は、第8.9項「ドキュメントの詳細の変更」を参照してください。
チャネルでは、メッセージの配信方法を定義します。取引パートナのセキュリティ特性、トランスポート・プロトコル、交換プロトコル、交換プロトコル・オーバーライド要素を指定し、定義されている場合はデジタル・エンベロープ、暗号化資格証明、デジタル署名、署名資格証明および検証のサポートも指定します。
ホスト取引パートナに対して外部デリバリ・チャネルを構成すると、アグリーメントの作成時に、すべてのリモート取引パートナに対してその外部デリバリ・チャネルを使用できます。その結果、デリバリ・チャネルを複数回（リモート取引パートナごとに1回ずつ）作成しなくても済みます。リモート取引パートナに対して外部デリバリ・チャネルを構成すると、アグリーメントの作成時に、そのリモート取引パートナに対してのみその外部デリバリ・チャネルを使用できます。ホスト取引パートナに対して内部デリバリ・チャネル（AQ、ファイルまたはJMSのトランスポートを使用したOracle B2Bへのインバウンド・メッセージ用）を構成すると、インバウンド・アグリーメントの作成時に、そのホスト取引パートナに対してのみその内部デリバリ・チャネルを使用できます。
ホスト取引パートナに対してJMS内部デリバリ・チャネルを構成することで、カスタムJMS例外キューを作成することもできます。詳細は、次の説明を参照してください。
表5-1に、Oracle B2Bで使用可能なチャネルおよび交換プロトコルを示します。
表5-1 Oracle B2Bで使用可能なチャネルおよび交換プロトコル
| プロトコル | 説明 |
|---|---|
|
Applicability Statement 2バージョン1.1: EDI over the Internetの使用に関する仕様。AS2では、HTTPまたはHTTPSを介したS/MIMEサポートが提供されます。AS2は、 |
|
|
（リモート取引パートナのみ） |
Minimum Lower Layer Protocol（MLLP）: ミニマルなOSIセッション・レイヤーを形成するプロトコルです。 MLLP（およびTCPトランスポート・プロトコル）は、リモート取引パートナに対してのみ使用できます。MLLPは、HL7またはカスタム・ドキュメントで使用されます。MLLPを使用すると、同じチャネルを使用してメッセージを送信または受信したり、サーバーまたはクライアントとして構成できます。 MLLP接続は永続的または一時的にできます。 永続接続は、次のように機能します。
一時接続は、次のように機能します。
詳細は、第5.5.1項「MLLPについて」を参照してください。 |
|
Electronic business Extensible Markup Language（ebXML）Messaging Service（ebMS）: XMLドキュメントを交換するために使用される仕様。ebMSは、SOAP Webサービス・メッセージ・フォーマットに基づいています。Oracle B2Bでは、ebMS 1.0および2.0がサポートされ、HTTP、HTTPS、および電子メール・トランスポート・プロトコルとSOAPパッケージング・プロトコルが使用されます。ebMSプロトコルでは、ドキュメント間の相関がサポートされます。また、Oracle B2Bでは、大規模ドキュメントについて、XMLDSig、XML EncryptおよびgZipベースの圧縮もサポートされます。 |
|
|
RosettaNet 2.0には、RosettaNet 1.1固有の側面は含まれておらず、複数の転送プロトコル、ハブベースのルーティング、添付、ペイロード暗号化などのサポートが追加されています。 |
|
|
取引パートナ間で交わされるXMLフォーマットのビジネス文書において信頼性の高いPIPのトランスポートを実現する、ソフトウェア・アプリケーションを作成するための実装ガイドライン。トランスポート、ルーティング、パッケージング、セキュリティ、シグナルおよび取引パートナ・アグリーメントのガイドラインが提供されます。 RosettaNetで指定されるエンベロープまたはコンテナ・フォーマットは、ビジネス文書（ペイロード）の交換時に変わりませんが、ドキュメント交換方法やXMLスキーマは、使用されるPIPおよびドキュメント・タイプによって変わります。RosettaNetのエンベロープ・フォーマットは、使用する特定の転送プロトコルにも関係ありません。 |
|
|
Applicability Statement 1: EDI over SMTPの使用に関する仕様。AS1は、XMLファイルやTXTファイルなどの非EDIドキュメント・タイプも処理します。 |
|
|
ローカル・ファイル・システムでファイルとの間でメッセージを送受信するトランスポート。 |
|
|
Oracle AQのシングル・コンシューマ・キューまたはマルチ・コンシューマ・キューとの間でメッセージを送受信するトランスポート。 |
|
|
リモートFTPサーバーでファイルとの間でメッセージを送受信するトランスポート。 |
|
|
リモートSFTPサーバーでファイルとの間でメッセージを送受信するトランスポート。 |
|
|
JMSキューまたはトピックとの間でメッセージを送受信するトランスポート。ユーザー名とパスワードを指定しない場合は、接続先が分散されていると、クラスタ化された環境の場合も含めて、ローカルJNDIが使用されます。 Oracle B2Bでは、javax.jms.ObjectMessageはサポートされていません。 |
|
|
Webサーバーとの間でメッセージを送受信するトランスポート。 |
|
|
電子メール・サーバーとの間でメッセージを送受信するトランスポート。 |
選択したチャネルとトランスポート・プロトコルに応じて、図5-19に示すように、トランスポート・プロトコル・パラメータ、チャネル属性、交換プロトコル・パラメータ、セキュリティ・パラメータなどのチャネルの詳細を指定します。
「トランスポート・プロトコル・パラメータ」では、プロトコル・エンドポイントの所定の使用方法に固有のプロパティを定義します。トランスポートの役割は、選択されているトランスポート・プロトコル、モード（同期または非同期）、サーバーおよびプロトコル・エンドポイント・アドレス（URIなどの取引パートナのアドレス）を使用して、メッセージを配信することです。トランスポート・プロトコル・パラメータの説明は、表5-3を参照してください。
「チャネル属性」では、ホスト取引パートナのホスト・アプリケーションとそのインストールの間の通信インタフェースを定義します。チャネル属性の説明は、表5-4を参照してください。
「交換プロトコル・パラメータ」では、ヘッダー、確認、およびヘッダーとペイロードをまとめるパッケージング（メッセージ交換メカニズム）を定義します。交換プロトコル・パラメータの説明は、表5-5を参照してください。
セキュリティ・パラメータでは、署名、暗号化、デジタル署名などの機能を定義します。使用可能な場合は、AES設定を使用したメッセージ暗号化をお薦めします。セキュリティ・パラメータの説明は、表5-6を参照してください。
次に注意事項を記載します。
セキュリティ・パラメータは、一般交換プロトコル（Generic File-1.0、Generic AQ-1.0、Generic FTP-1.0、Generic SFTP-1.0、Generic JMS-1.0、Generic HTTP-1.0およびGeneric Email-1.0）には指定しません。
MLLPチャネルには、セキュリティ・パラメータは適用されません。
取引パートナのチャネルを構成する手順は、次のとおりです。
「トランスポート・プロトコル・パラメータ」タブをクリックします。
タスク1で選択したチャネルとトランスポート・プロトコルに応じて、表5-3に記載されているように、トランスポート・プロトコル・パラメータを指定します。
表5-3に、トランスポート・プロトコル・パラメータ（アルファベット順にリスト）とそのパラメータが適用されるプロトコルを示します。
表5-3 トランスポート・プロトコル・パラメータ
| パラメータ | 説明 | パラメータを使用するプロトコル |
|---|---|---|
|
追加トランスポート・ヘッダー |
取引パートナへのメッセージの送信に使用されるカスタムHTTPヘッダー。 同期レスポンス処理の場合は、追加のトランスポート・ヘッダーを設定する必要があります。送信者がレスポンスをインバウンド・メッセージとして処理するには、 |
AS2（オプション） Generic HTTP（オプション） |
|
アーカイブ・ディレクトリ |
B2Bチャネルは処理されたファイルをこのディレクトリに移動します。デフォルトでは、この移動は破壊読取りで、処理されたファイルがエンドポイントから削除されます。この場合、ファイルは指定のパスに移動されます。 |
Generic File-1.0（オプション） Generic FTP-1.0（オプション） Generic SFTP-1.0（オプション） |
|
キャッシュ接続 |
有効にすると、（リストの表示と処理が異なるセッションで実行されるデフォルトとは反対に）ファイル・リストの表示とファイルの処理が同じセッションで実行されます。 |
Generic FTP-1.0（オプション） |
|
チャネル・マスク |
FTPのSSLを有効にするには、次のいずれかを入力します。
デフォルトはNone（非SSL）です。 |
Generic FTP（オプション） |
|
暗号スイート |
暗号化の優先暗号化を指定します。 |
Generic FTP（オプション） |
|
コネクション・ファクトリ |
コネクション・ファクトリのJNDIロケーションまたはJavaクラス名（たとえば、 |
Generic JMS（オプション） |
|
接続モード |
「クライアント」または「サーバー」から選択します。 |
MLLP-1.0（必須、リモート取引パートナのみ） |
|
コンシューマ |
メッセージを受信するクライアント。 |
Generic AQ（オプション） |
|
コンテンツ・タイプ |
電子メール経由で送信されるペイロードのコンテンツ・タイプ。デフォルトのコンテンツ・タイプは |
AS1（オプション） Generic Email（オプション） |
|
制御ポート |
デフォルトのFTPポート値（21）を変更する場合に値を指定します。 |
Generic FTP（オプション） |
|
データ・ポート |
アクティブなFTP接続の場合は、このオプションを使用してFTPサーバーの静的/固定データ・ポートを構成します。 |
Generic FTP（オプション） |
|
データソース |
AQキューにアクセスするための、JDBCデータ・ソースのJNDI名。 |
Generic AQ（オプション） |
|
接続先名 |
JMS接続先名。 |
Generic JMS（オプション） |
|
接続先プロバイダ |
リモート・サーバーで使用可能なJMSキューまたはJMSトピックに、B2Bを接続できるようにします。ターゲット・サーバーへの接続に必要なJNDIプロパティには、値が期待されます。各キー/値のペアには、セパレータとして |
Generic JMS-1.0（オプション） |
|
ディレクトリ名フォーマット |
取得するディレクトリ名フォーマット。 |
Generic FTP（オプション） |
|
電子メールID |
メッセージが配信される電子メール・アドレス（AQまたはJMSでファイル・チャネルやキューのパスを指定するのと同様です）。 |
AS1（必須） Generic Email（必須） |
|
電子メール・サーバー |
「IMAP」または「POP3」を選択します。 |
AS1（必須） Generic Email（必須） |
|
CCCの有効化 |
SSLセッションでの認証と、プレーン・ソケットでの残りのファイル転送コマンドをB2Bで実行できるようにします。 |
Generic FTP-1.0（オプション） |
|
マーカーの有効化 |
有効にすると、ソースと同じ名前で0バイトのファイルが作成され、読取りまたは書込みが完了したことを意味します。ファイル名はソースと同じですが、 |
Generic File-1.0（オプション） Generic FTP-1.0（オプション）-1.0 Generic SFTP-1.0（オプション） |
|
エンコーディング |
インバウンド・ファイルの内容を変換するためにB2Bで使用するエンコーディング。 |
Generic FTP（オプション） |
|
ファイル名フォーマット脚注1 |
次のファイル名フォーマットを使用できます。 %FROM_PARTY% %TO_PARTY% %DOCTYPE_NAME% %DOCTYPE_REVISION% %MSG_ID% %TIMESTAMP% ebMSドキュメントの場合にのみ、次のファイル名フォーマットを使用できます。 %ACTIONNAME% これらのファイル名フォーマットは任意の組合せで使用できます。次に例を示します。 %TO_PARTY%_%DOCTYPE_NAME%_%DOCTYPE_REVISION%.dat この場合は、 脚注を参照してください。 |
Generic File（オプション） Generic FTP（オプション） Generic SFTP（オプション） |
|
ファイル名セパレータ |
キーを区切るファイル名フォーマットのセパレータ。_（アンダースコア）以外の文字をファイル名セパレータとして使用する場合は、「ファイル名セパレータ」フィールドで値を指定します。 「ファイル名セパレータ」パラメータは「ファイル名フォーマット」パラメータと連携するため、「ファイル名フォーマット」パラメータと「ファイル名セパレータ」パラメータで同じセパレータ値を使用する必要があります。 たとえば、ファイル名フォーマット 文字$と^は、ファイル名セパレータとして使用できません。 デフォルト値は、_（アンダースコア）です。 |
Generic File（オプション） Generic FTP（オプション） Generic SFTP（オプション） |
|
フォルダ |
絶対ディレクトリ・パスを使用してください。 |
AS1（オプション） Generic Email（オプション） |
|
フォルダ名 |
絶対ディレクトリ・パスを使用してください。 |
Generic File（必須） Generic FTP（必須） |
|
ホスト名 |
メッセージを交換する取引パートナのトランスポート・サーバーまたは電子メール・サーバー。 MLLP 1.0プロトコルでは、接続モードが「サーバー」の場合、ホスト名はB2Bサーバーである必要があります。接続モードが「クライアント」の場合、ホスト名はリモートB2Bサーバー（MLLPサーバー）である必要があります。 |
AS1（必須） Generic AQ（オプション） Generic FTP（必須） MLLP-1.0（必須、リモート取引パートナのみ） Generic SFTP（必須） Generic Email（必須） |
|
ペイロードのみマップ |
JMSマップ・メッセージにペイロードのみが含まれていることを示します。 |
Generic JMS（オプション） |
|
トピック |
JMSが（キューではなく）トピックと通信していることを示す場合に選択します。 |
Generic JMS（オプション） |
|
VANメールボックス |
有効にすると、B2BではエンドポイントをVANメールボックスとして処理し、適切に操作します。 |
Generic FTP-1.0（オプション） |
|
メッセージ・タイプ |
JMSメッセージ・タイプ（BYTES、TEXTまたはMAP）を選択します。 |
Generic JMS（オプション） |
|
最小経過時間 |
エンドポイントに到着したファイルは、入力した時間間隔（ミリ秒単位）の経過後に処理されます。 |
Generic File-1.0（オプション） Generic FTP-1.0（オプション） Generic SFTP-1.0（オプション） |
|
パスフレーズおよびパスフレーズの確認 |
秘密鍵ファイルの場所を入力し、秘密鍵ファイルをパスフレーズで保護する場合は、パスフレーズを入力します。 |
Generic SFTP（オプション） |
|
パスワードおよびパスワードの確認 |
パスワード認証を使用するには、キー・ストア・パスワードを指定します。キー・ストア・パスワードはHTTP基本認証に使用されます。 |
AS1（オプション） AS2（オプション） Generic AQ（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） Generic FTP（オプション） Generic HTTP（オプション） Generic SFTP（オプション） Generic JMS（オプション） Generic Email（オプション） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） |
|
パス |
メッセージを送受信する絶対ディレクトリ・パス。 |
Generic SFTP（必須） |
|
永続接続 |
「false」（デフォルト値）に設定すると、メッセージは新しい接続で送信され、確認の受信後にその接続はクローズされます。メッセージ受信者が取引パートナに確認を返信した後、接続がクローズされます。「true」に設定すると、キャッシュされている接続を使用して、すべてのメッセージが交換されます。 |
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
ポーリング間隔 |
Oracle B2Bがサーバーに対してインバウンド・メッセージをポーリングする時間間隔（秒単位）。 |
AS1（オプション） Generic File（該当なし） Generic AQ（オプション） Generic FTP（該当なし） MLLP-1.0（オプション、リモート取引パートナのみ） Generic SFTP（該当なし） Generic JMS（オプション） Generic Email（該当なし） |
|
ポート番号（またはポート） |
AQはデフォルト・ポート1521で実行されます。 SFTPはデフォルト・ポート22で実行されますが、別のポートに変更できます。 FTPはデフォルト・ポート21で実行されます。これは表示されません。このポート番号の変更方法は、「制御ポート」の説明を参照してください。 MLLP 1.0プロトコルでは、接続モードが「サーバー」の場合、ポートは有効なTCPポート番号である必要があります。接続モードが「クライアント」の場合、ポートはMLLPサーバーで使用されるポートと同じである必要があります。 |
Generic AQ（オプション） MLLP-1.0（必須、リモート取引パートナのみ） Generic SFTP（必須） |
|
ファイル名の保持 |
ファイル名を保持します。 |
Generic File-1.0（オプション） Generic FTP-1.0（オプション） Generic SFTP-1.0（オプション） |
|
秘密鍵 |
公開鍵認証を使用するには、秘密鍵ファイルの場所を指定します。秘密鍵ファイルをパスフレーズで保護する場合は、パスフレーズも指定します。 |
Generic SFTP（オプション） |
|
キュー名 |
AQキュー名。 |
Generic AQ（オプション） |
|
受信者 |
メッセージをAQキューに配信する際に使用される値。たとえば、受信者を |
Generic AQ（オプション） |
|
添付ファイルとして送信 |
有効にすると、メッセージ（ペイロード）は、ペイロードがメッセージ本文となる通常の配信ではなく、電子メールの添付ファイルとして送信されます。 |
AS1（オプション） Generic Email（オプション） |
|
順序（順序付け） |
受信EDI、HL7またはカスタム・メッセージをバックエンド・アプリケーションに順番に配信する必要がある場合は、このプロパティを有効にします。 詳細は、第5.5.2項「メッセージの順序付け」を参照してください。 |
MLLP-1.0（オプション、リモート取引パートナのみ） Generic File-1.0（オプション） Generic FTP-1.0（オプション） Generic SFTP（オプション） |
|
SID |
Oracleデータベースを識別するためのシステムID。 |
Generic AQ（オプション） |
|
件名 |
電子メール・メッセージの件名ヘッダー。 |
AS1（オプション） Generic Email（オプション） |
|
サブスクライバID |
JMSサブスクライバID。JMSがトピックと通信する場合に必要です。 |
Generic JMS |
|
タイムアウト |
MLLP一時接続が確認メッセージのソケットをオープン状態に維持する長さを定義します。デフォルトのタイムアウト値は300秒です。このパラメータは、MLLP一時接続（永続接続ではない）にのみ適用されます。 タイムアウトは、HTTPデリバリ・チャネルで追加のトランスポート・ヘッダーとして構成できます。 値の例: |
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
タイムスタンプ・フォーマット タイムスタンプ・フォーマット、タイムスタンプ・オフセットおよびタイムスタンプ・ソースのパラメータについて: パラメータ受信側ファイルの最小経過時間の値がゼロより大きい場合、B2Bでは、処理対象ファイルとして選択する前に、ファイルが変更されていないことが確認されます。つまり、FTPサーバーのシステム・タイムスタンプは、B2Bサーバーのシステム・タイムスタンプと異なることがあります。タイムスタンプ・フォーマット、タイムスタンプ・オフセットおよびタイムスタンプ・ソースの各パラメータは、受信側ファイルの最終更新時間を取得するために使用されます（この表の「最小経過時間」も参照してください）。 |
受信者読込み順タイムスタンプ・フォーマットは、FTPコマンドを使用して取得されるレスポンス文字列からタイムスタンプを解析する方法を指定します。索引情報も含まれます。次に例を示します。 [43,55,' [4,+14,' 複数のフォーマット・マスクを、次のように角カッコで囲んで指定できます。 format-mask = start "," end "," "'" time-pattern "'" ["," current-year] 各要素は次のとおりです。 start = integer end = integer time-pattern = java.text.SimpleDateFormat | "N" current-year = "CY" TimestampFormats = {"[" format-mask "]" }+ 例: [41,53,' 年が指定されない時間パターンには、
t = "12:00 am, January 1, 1970 UTC" + N milliseconds |
Generic FTP-1.0（オプション） |
|
タイムスタンプ・オフセット |
受信者読込み順タイムスタンプ・オフセットは、B2Bサーバーが実行されているシステム時間に対して、ファイルのタイムスタンプを変換する際に使用されます。 たとえば、 注意:
|
Generic FTP-1.0（オプション） |
|
タイムスタンプ・ソース |
受信者読込み順タイムスタンプ・ソースは、タイムスタンプの取得に使用するフォーマットを次のように指定します。
|
Generic FTP-1.0（オプション） |
|
転送タイプ |
「バイナリ」または「ASCII」のファイル転送モードを選択します。 |
Generic FTP-1.0（オプション） |
|
URL |
取引パートナのHTTPまたはHTTPSエンドポイントURL。 |
AS2（必須） ebMS-2.0（必須） ebMS-1.0（必須） Generic HTTP（必須） RosettaNet-V02.00（必須） RosettaNet-01.10（必須） |
|
JMS IDの使用 |
JMSメッセージIDをB2BメッセージIDとして使用します。これにより、JMSレベルでの相関が円滑化されます。 |
Generic JMS-1.0（オプション） |
|
ユーザー名 |
ターゲット・サーバーに接続するためのユーザー名（ログイン名）。HTTP基本認証に使用されます。B2Bでは構成済のJNDIデータ・ソースを使用してキューに接続するため、AQおよびJMSではこの値はオプションです。 |
AS1（オプション） AS2（オプション） Generic AQ（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） Generic FTP（必須） Generic HTTP（オプション） Generic SFTP（必須） Generic JMS（オプション） Generic Email（オプション） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） |
|
プロキシの使用 |
プロキシ・サーバーを選択します（使用している場合）。 |
AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） Generic FTP（オプション） Generic HTTP（オプション） Generic SFTP（オプション） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） |
脚注1 File/FTPチャネルでは、ファイル名フォーマットが設定されていると、ディレクトリ名フォーマットは無視されます。
「保存」をクリックします。
タスク1で選択したチャネルとトランスポート・プロトコルに応じて、表5-4に記載されているように、チャネル属性を指定します。
表5-4 チャネル属性
| パラメータ | 説明 | パラメータを使用するプロトコル |
|---|---|---|
|
確認モード |
取引パートナがメッセージを受信するモードとして、「同期」、「非同期」または「なし」を選択します。すべての一般交換について「なし」を選択します。 MLLP交換では、一時接続には「同期」または「非同期」を選択します。永続接続には「なし」を選択します。 |
AS1（オプション） AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） MLLP-1.0（必須、リモート取引パートナのみ） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） |
|
圧縮済 |
メッセージ圧縮が適用される場合に選択します。 |
AS1（オプション） AS2（オプション） このパラメータは、AS1およびAS2でのみ使用可能ですが、その他のプロトコルのB2Bインタフェースに表示されることがあります。 |
|
説明 |
追加の説明を記述してください。 |
AS1（オプション） AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） MLLP-1.0（オプション、リモート取引パートナのみ） Generic File（オプション） Generic AQ（オプション） Generic FTP（オプション） Generic HTTP（オプション） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） Generic SFTP（オプション） Generic JMS（オプション） Generic Email（オプション） |
|
チャネルの有効化/チャネルの無効化 |
チャネルは、ホスト取引パートナのホスト・アプリケーションとそのインストールの間の通信インタフェースです。 |
MLLP-1.0（必須、リモート取引パートナのみ） |
|
内部 注意: B2Bインタフェースでは、「内部」が選択されている場合は無効なプロトコルの選択が許可されますが、一般交換プロトコル以外のプロトコルは選択しないでください。 |
このオプションは、チャネルがホスト取引パートナの企業内のみで機能する場合に選択します。 |
このオプションが選択されている場合は、一般プロトコルのみが有効です。 Generic File（オプション） Generic AQ（オプション） Generic FTP（オプション） Generic HTTP（オプション） Generic SFTP（オプション） Generic JMS（オプション） Generic Email（オプション） このオプションが選択されていない場合は、すべてのプロトコルが有効です。 AS1（オプション） AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） Generic File（オプション） Generic AQ（オプション） Generic FTP（オプション） Generic HTTP（オプション） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） Generic SFTP（オプション） Generic JMS（オプション） Generic Email（オプション） |
|
再試行数 |
Oracle B2Bがメッセージの送信を再試行する回数。 詳細は、第5.5.5項「配信再試行オプションの構成」を参照してください。 |
AS1（オプション） AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） Generic File（オプション） Generic AQ（オプション） Generic FTP（オプション） Generic HTTP（オプション） MLLP-1.0（オプション、リモート取引パートナのみ） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） Generic SFTP（オプション） Generic JMS（オプション） Generic Email（オプション） |
|
再試行間隔 |
B2Bがメッセージの再送信を試行する間隔（分単位）。メッセージのステータスが「完了」でない場合、B2Bはメッセージの再送信を試みます。 確認を含むプロトコルの場合、B2Bは確認を待機します（以前は「確認所要時間」パラメータと呼ばれていました）。確認を受信しなかった場合は、再試行間隔設定に従って再試行が実行されます。 詳細は、第5.5.5項「配信再試行オプションの構成」を参照してください。 |
AS1（オプション） AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） Generic File（オプション） Generic AQ（オプション） Generic FTP（オプション） Generic HTTP（オプション） MLLP-1.0（オプション、リモート取引パートナのみ） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） Generic SFTP（オプション） Generic JMS（オプション） Generic Email（オプション） |
|
トランスポート・コールアウト |
インバウンド・メッセージの場合、B2Bはトランスポートからメッセージを受信した直後にトランスポート・コールアウトを起動します。アウトバウンド・メッセージの場合は、トランスポートにメッセージを送信する直前にトランスポート・コールアウトを起動します。 |
AS1（オプション） AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） Generic File（オプション） Generic AQ（オプション） Generic FTP（オプション） Generic HTTP（オプション） MLLP-1.0（オプション、リモート取引パートナのみ） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） Generic SFTP（オプション） Generic JMS（オプション） Generic Email（オプション） |
「保存」をクリックします。
「交換プロトコル・パラメータ」タブをクリックします。
タスク1で選択したチャネルと交換プロトコルに応じて、表5-5に記載されているように、交換プロトコル・パラメータを指定します。
表5-5 交換プロトコル・パラメータ
| パラメータ | 説明 | パラメータを使用するプロトコル |
|---|---|---|
|
改行文字 |
この値には1文字のみを指定できます。改行文字はワイヤ・メッセージ・ペイロードには表示されません。デフォルト値は0x0D（16進）です。 |
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
即時確認カスタム・ファイル |
確認がカスタマイズされているファイルを参照します。 |
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
HL7確認の破棄 |
FAをトランスポート・レベルで相関付けるには、このプロパティを有効にします。これにより、取引パートナ・アグリーメントの識別、トランスレーションなどが含まれる従来のメッセージ相関が回避され、パフォーマンスが向上します。確認は、相関後にトランスポート・レイヤーで停止されるため、ワイヤ・メッセージ・レポートに表示されますが、ビジネス・メッセージ・レポートには表示されません。 このプロパティを有効にするには、次のコードのいずれかを選択します。選択したコードがMSA.2セグメントにある場合、確認はトランスポート・レイヤーで停止されます。 AA - アプリケーション確認: 受入 AE - アプリケーション確認: エラー AR - アプリケーション確認: 拒否 CA - アプリケーション確認: コミット受入 CE - アプリケーション確認: コミット・エラー CR - アプリケーション確認: コミット拒否 「なし」を選択すると、このプロパティは無効になります。 MSA.2は、MSAセグメントの2番目の要素です。 |
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
重複削除 |
有効にすると、アウトバウンド・メッセージに重複削除ヘッダーが追加されます。このフラグはインバウンド・メッセージ・フローには適用されません。 |
ebMS-2.0（オプション） ebMS-1.0（オプション） |
|
終了ブロック |
このプロパティは、メッセージの終了を示すために使用します。一般に、「終了ブロック」は、メッセージが取引パートナに送信された後に送信されます。 |
MLLP-1.0（オプション、リモート取引パートナのみ） TCP汎用サポートの場合のみ |
|
終了ブロック文字 |
この値には1文字のみを指定できます。終了ブロックはワイヤ・メッセージ・ペイロードには表示されません。デフォルト値は0x1C（16進）です。 |
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
ヘッダー長 |
このプロパティは、実際のデータの前に置かれるヘッダーのサイズを定義します（開始ブロック、メッセージ長および埋込みヘッダーが含まれます）。 |
MLLP-1.0（オプション、リモート取引パートナのみ） TCP汎用サポートの場合のみ |
|
TPをデリバリ・チャネルにより識別 |
デリバリ・チャネルを使用して取引パートナを識別します。 （MLLP IDを使用せずに）リモート取引パートナに構成されているデリバリ・チャネルで受信メッセージを識別する場合は、このパラメータを有効にします。この機能は、送信者の識別が重要ではない状況で、匿名取引パートナとして機能します。このパラメータの選択を解除した場合は、MLLP交換にMLLP ID（またはHL7メッセージ・アプリケーションIDやHL7メッセージ機能IDなど、アグリーメントを識別するためのドキュメント・レベル識別子）が必要です。 |
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
即時確認 注意: 受信ビジネス・メッセージ（たとえば、管理番号1017）のMLLP即時確認には、管理番号にAの接頭辞が付きます（A1017など）。これは確認管理番号であることを取引パートナに示します。接頭辞の付いた文字列が、許容される長さを超える場合（たとえば、受信終了時に検証ルール違反となる場合）は、「確認制御IDのマップ」パラメータを使用します。 |
即時確認は、ドキュメント・レイヤーではなくTCPトランスポート・レイヤーで生成および送信されます。即時確認は機能確認にかわるものです。機能確認はトランスレーションや検証のエラーを取得するため、（たとえば、ビジネス上重要なヘルスケア・アプリケーションの）機能確認の所要時間が望ましくない場合に使用できます。 Oracle B2Bでは、次のモードで即時確認を送信できます。
|
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
確認制御IDのマップ |
ビジネス・メッセージのMSH.10メッセージ・ヘッダーを即時確認のMSH.10メッセージ・ヘッダーにマップする場合に選択します。 |
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
トリガー・イベントのマップ |
トリガー・イベントを備えた即時確認を送信します。 |
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
メッセージ長索引 |
このプロパティは、ヘッダーに使用可能なデータ・サイズを示します開始索引から終了索引まででメッセージ・サイズを定義します。たとえば、データ長が最初の4バイトの場合、ヘッダー・サイズは「4」で、「メッセージ長索引」は「1-4」です。 |
MLLP-1.0（オプション、リモート取引パートナのみ） TCP汎用サポートの場合のみ |
|
メッセージ順序セマンティック |
CPP/CPAのプレースホルダ。実行時には使用されません。 |
ebMS-2.0（オプション） |
|
期間の保持 |
CPP/CPAのプレースホルダ。実行時には使用されません。 |
ebMS-2.0（オプション） |
|
受信配信オプション |
このパラメータは、非同期モードの場合に、MDNを返信する必要があるURLを構成するために使用します。 |
AS2（オプション） |
|
ヘッダーの保持 |
メッセージを取引パートナ（アウトバウンド・メッセージの場合）またはOracle B2B（インバウンド・メッセージの場合）に送信している間、ヘッダーを保持する場合は、このプロパティを選択します。 ヘッダーを保持する場合、B2Bではカスタム・ヘッダーは処理されません。トランスポート・コールアウトを使用して処理されます。 |
MLLP-1.0（オプション、リモート取引パートナのみ） TCP汎用サポートの場合のみ |
|
パーティタイプと値の送信 |
有効にすると、メッセージ・ヘッダーからの送信パーティ・タイプと値がバックエンド・アプリケーションに送信されます。 |
ebMS-2.0（オプション） ebMS-1.0（オプション） |
|
署名および圧縮済 |
選択すると、メッセージは最初に署名され、次に圧縮されます。選択しない場合、メッセージは最初に圧縮され、次に署名されます。 |
AS1（オプション） AS2（オプション） |
|
開始ブロック |
このプロパティは、メッセージの開始を示すために使用します。一般に、「開始ブロック」は、メッセージが取引パートナに送信される前に送信されます。 |
MLLP-1.0（オプション、リモート取引パートナのみ） TCP汎用サポートの場合のみ |
|
開始ブロック文字 |
この値には1文字のみを指定できます。開始ブロックはワイヤ・メッセージ・ペイロードには表示されません。デフォルト値は0X08（16進）です。 |
MLLP-1.0（オプション、リモート取引パートナのみ） |
「保存」をクリックします。
「セキュリティ」タブをクリックします。
タスク1で選択したチャネルとトランスポート・プロトコルに応じて、表5-6に記載されているように、セキュリティ・パラメータを指定します。
|
注意: ホスト取引パートナに対してキー・ストアの場所を指定すると、使用可能な証明書によって「デジタル署名」リストと「暗号化」リストが移入されます。詳細は、タスク6: 「ホスト取引パートナのキー・ストア情報の指定」を参照してください。 |
表5-6 セキュリティ・パラメータ
| パラメータ | 説明 | パラメータを使用するプロトコル |
|---|---|---|
|
確認署名済 |
レスポンダがメッセージの受信を確認するようにするには、このオプションを選択します。提供する必要のあるデータはありません。 |
AS1（オプション） AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） |
|
デジタル署名 |
デジタル署名証明書を使用するには、キー・ストアに対応する秘密鍵が必要です。 「メッセージ署名済」を選択した場合は、AS1に対して次のオプションを選択します。 SMIME 3.0（SHA1 - RSAを使用） 「メッセージ署名済」を選択した場合は、AS2に対して次のいずれかのオプションを選択します。 SMIME 3.0（MD5 - RSAを使用） SMIME 3.0（SHA1 - RSAを使用） 「メッセージ署名済」を選択した場合は、ebMS-2.0およびebMS-1.0に対して次のいずれかのオプションを選択します。 XMLDSIG（SHA1 - RSAを使用） XMLDSIG（SHA1 - DSAを使用） 「メッセージ署名済」を選択した場合は、RosettaNet-V02.00に対して次のいずれかのオプションを選択します。 SMIME 3.0（MD5 - RSAを使用） SMIME 3.0（SHA1 - RSAを使用） SMIME 2.0（MD5 - RSAを使用） SMIME 2.0（SHA1 - RSAを使用） XMLDSIG（SHA1 - RSAを使用） XMLDSIG（SHA1 - DSAを使用） 「メッセージ署名済」を選択した場合は、RosettaNet-01.10に対して次のいずれかのオプションを選択します。 SMIME 3.0（MD5 - RSAを使用） SMIME 3.0（SHA1 - RSAを使用） SMIME 2.0（MD5 - RSAを使用） SMIME 2.0（SHA1 - RSAを使用） |
AS1 AS2 ebMS-2.0 ebMS-1.0 RosettaNet-V02.00 RosettaNet-01.10 |
|
暗号化 |
暗号化証明書を使用する場合、秘密鍵の登録は不要です。 「メッセージ暗号化済」を選択した場合は、AS1およびAS2に対して次のいずれかのオプションを選択します。 SMIME 3.0（DESを使用） SMIME 3.0（3DESを使用） SMIME 3.0（RC2 - 40を使用） SMIME 3.0（RC2 - 64を使用） SMIME 3.0（RC2 - 128を使用） 「メッセージ暗号化済」を選択した場合は、ebMS-2.0およびebMS-1.0に対して次のいずれかのオプションを選択します。 XMLENC（3DES - RSA-v1.5を使用） XMLENC（AES -128 RSA-OAEPを使用） XMLENC（AES -192 RSA-OAEPを使用） XMLENC（AES -256 RSA-OAEPを使用） |
AS1 AS2 ebMS-2.0 ebMS-1.0 RosettaNet-V02.00（オプション） |
|
メッセージ暗号化済 |
メッセージの暗号化を可能にするには、このオプションを選択します。このオプションでは、「暗号化」フィールドで暗号化スキーマを選択する必要があります。 |
AS1（オプション） AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） RosettaNet-V02.00（オプション） |
|
メッセージ署名済 |
「デジタル署名」フィールドにデジタル署名を指定するには、このオプションを選択します。 |
AS1（オプション） AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） |
「保存」をクリックします。
|
注意: AS1の場合、署名にはSHA1のみがサポートされています。AS1の署名にはMD5はサポートされていません。 |
MLLPデリバリ・チャネルは、サーバーとクライアント間の双方向ハンドシェイクによって確立されます。このデリバリ・チャネルは、その他のトランスポートとは異なり常に双方向で、メッセージの送受信に使用されます。MLLPデリバリ・チャネルはリモート取引パートナのみに対して構成され、サーバー・ソケットまたはクライアント・ソケットとして構成されます。サーバー・ソケットとしてのチャネルは、指定されたポートで接続を受け入れます。クライアント・ソケットとしてのチャネルは、指定されたIPアドレスおよびポートで接続を確立します。いずれのソケット・タイプの場合も、永続的または一時的な接続タイプを指定します。永続接続は、一度確立されるとキャッシュされ、エンドポイントのライフサイクル全体にわたってメッセージ交換用チャネルとして機能します。一時接続は、ビジネス・メッセージとその確認で構成される1組のメッセージ交換用チャネルとして機能します。第5.5.1.1「接続モードの上書き」を参照してください。
送信側にはMLLPクライアント・デリバリ・チャネルを構成し、受信側にはMLLPサーバー・チャネルを構成してください。たとえば、HL7のカスタムまたは位置指定フラット・ファイルのメッセージをAcmeからGlobalChipsに送信する場合は、Acme側にクライアントMLLP永続チャネルを用意し、GlobalChips側にサーバーMLLP永続チャネルを用意します。サーバーおよびクライアントのMLLP接続タイプ（永続または一時）は一致（双方とも永続または双方とも一時に）する必要があります。ただし、接続が事前に確立されている場合は、送信側にサーバー・チャネル、受信側にクライアント・チャネルが確保される場合もあります。
MLLPは双方向チャネルのため、リスニング・チャネルとはみなされず、メッセージの送信と受信の両方に同じMLLPデリバリ・チャネルを使用できます。
MLLPはデフォルトでは単一のデリバリ・チャネル・モードで機能するため、アグリーメントの作成時に、リモート取引パートナに対してデリバリ・チャネルを選択します。単一でないMLLPデリバリ・チャネル・モードで操作する必要がある場合は、別のアグリーメントで異なるMLLPデリバリ・チャネルを選択します。
構成を手動で変更せずにメッセージの接続モードを上書きする場合、一時接続から永続接続に変更するには、次のプロパティを設定します。
CONNMODE:Permanent
デフォルトの統合では、次のようにします。
b2b.connMode:Permanent
永続接続から一時接続に変更することもできます。
MLLPではSB（開始バイト）、EB（終了バイト）およびCRを使用してメッセージを解析します。SBとEBではなく、データ長または開始文字列と終了文字列を使用してメッセージを解析するために、Oracle B2BにはTCPに対する汎用ソリューションが用意されています。
TCPに対する汎用サポートでは、「交換プロトコル・パラメータ」タブ（図5-21を参照）の「開始ブロック」、「終了ブロック」、「ヘッダー長」、「メッセージ長索引」および「ヘッダーの保持」パラメータを使用します。
|
注意: MLLPプロトコルを使用して汎用TCPチャネルを作成すると、図5-21に示すように、「交換プロトコル・パラメータ」タブにパラメータが表示されます。チャネルの作成が終了すると、タブの下に2つのサブタブが表示され、MLLP固有のパラメータと汎用TCP固有のパラメータがそれぞれ分類されます。 |
これらのパラメータの詳細は、表5-5「交換プロトコル・パラメータ」を参照してください。
表5-7では、汎用TCPをサポートするパラメータを使用してデータを送受信する場合に、Oracle B2BでMLLPを使用してメッセージをどのように処理するかを説明します。
表5-7 汎用TCPソリューション
| 汎用TCPソリューション | 説明 |
|---|---|
|
開始ブロックと終了ブロックを指定したデータの送受信 |
リモート取引パートナに対してMLLP-1.0を選択した場合は、「交換プロトコル・パラメータ」タブの「開始ブロック」パラメータと「終了ブロック」パラメータを使用します。「開始ブロック」パラメータと「終了ブロック」パラメータの詳細は、表5-5を参照してください。 例: |
|
開始ブロック、終了ブロックおよびデータ長を指定したデータの送受信 |
リモート取引パートナに対してMLLP-1.0を選択した場合は、「交換プロトコル・パラメータ」タブの「開始ブロック」、「終了ブロック」、「メッセージ長索引」および「ヘッダー長」パラメータを使用します。これらのパラメータの詳細は、表5-5を参照してください。 例: |
|
データ長を指定したデータの送受信 |
リモート取引パートナに対してMLLP-1.0を選択した場合は、「交換プロトコル・パラメータ」タブの「メッセージ長索引」パラメータと「ヘッダー長」パラメータを使用します。「メッセージ長索引」パラメータと「ヘッダー長」パラメータの詳細は、表5-5を参照してください。 例: 例: つまり、15HDRDATADATADATAでは、次のように構成します。 メッセージ長索引=1-2 ヘッダー長=5 15は、メッセージ長索引の終了索引の後に開始する長さを示します。HDRはヘッダーです。 |
|
開始ブロックとデータ・サイズを指定したデータの送受信 |
リモート取引パートナに対してMLLP-1.0を選択した場合は、「交換プロトコル・パラメータ」タブの「開始ブロック」、「メッセージ長索引」および「ヘッダー長」パラメータを使用します。「開始ブロック」、「メッセージ長索引」および「ヘッダー長」パラメータの詳細は、表5-5を参照してください。注意: この場合、開始ブロックはヘッダーの一部であり、最小メッセージ長索引を開始ブロック・サイズより大きくする必要があります。 例: |
|
バックエンド・アプリケーション・ヘッダーを保持し、B2Bで開始ブロック、データ・サイズおよび終了ブロックを追加しない |
ヘッダーを追加せずに取引パートナにデータを送信し、バックエンド・アプリケーション・ヘッダーを保持する場合は、「ヘッダーの保持」プロパティを選択します。「ヘッダーの保持」プロパティの詳細は、表5-5を参照してください。 |
MLLPの動的IP機能には、デリバリ・チャネルに関連付けられているエンドポイントを動的に変更する柔軟性があります。これは、メッセージ・エンキュー・ヘッダーのactionName/eventName属性を介して、デリバリ・チャネルのIPアドレスを上書きすることで変更します。
次に例を示します。
eventName=DynamicIP:GlobalChips:IP_address:port_number
または
actionName=DynamicIP:GlobalChips:IP_address:port_number
B2Bコンポジット（SOA Service Component Architecture（SCA）アセンブリ・モデルの一部）で、次の構文を使用してこの機能を使用することもできます。
b2b.toDynamicIP=GlobalChips:IP_address:port_number
b2b.toDynamicIPプロパティは、B2Bに送信される正規化されたメッセージ・プロパティに設定されます。
Oracle B2Bにより、各メッセージに一意の管理番号が生成されます。同じ取引パートナに相当する動的エンドポイントを複数必要とするブロードキャストの場合は、バックエンド・アプリケーションで管理番号を指定する必要があります。Oracle B2Bでは、確認の相関のために動的エンドポイント詳細を格納して使用します。それ以外の構成は必要ありません。
アウトバウンド・メッセージのカスタム・ヘッダーを抽出するには、バックエンド・アプリケーションのactionNameプロパティにCUSTOM_HEADERプロパティを追加します。このプロパティは、CalloutMessageのCUSTOM_HEADERパラメータとしてコールアウトで使用できるようになります。コールアウトのプロパティは、取得して使用できます。
次に例を示します。
eventName= CUSTOM_HEADER:your_value
デフォルトの統合では、次のようにします。
b2b.customHeader= your_value
インバウンド・メッセージのカスタム・ヘッダーを抽出するには、コールアウトのCalloutMessageパラメータとしてCUSTOM_HEADERプロパティを設定します。このプロパティは、バックエンド・アプリケーションのactionNameプロパティの一部として使用できるようになります。詳細は、例13-1「CUSTOM_HEADERプロパティの設定と取得」を参照してください。
マルチスレッド・システムでは、最初に生成されたメッセージが最初に送信先に届くとはかぎらないため、メッセージを順番に交換することは難題です。このビジネス要件がある企業のために、Oracle B2Bにはシーケンサとディスパッチャが用意されています。シーケンサは、着信時刻に基づいてメッセージを順序付けします。ディスパッチャは、順序付けされたメッセージをディスパッチします。メッセージの順序付けは、アウトバウンド方向とインバウンド方向の両方に使用できます。
メッセージの順序付けでサポートされているプロトコルには、MLLP交換（TCPトランスポート）や一般交換（FILE、FTP、SFTP、JMS、AQ、HTTPトランスポート）などがあります。
|
注意: メッセージ順序付けは、すべてのドキュメントで動作しますが、EDI、HL7およびカスタム・ドキュメント・プロトコルについてのみ認証されています。順序付けは、一時モードのMLLP接続ではサポートされていません。 EDIバッチ処理は、メッセージの順序付けではサポートされていません。BATCHの一部として順序付けがメッセージ有効になっている場合、エラーが発生し、一部のメッセージが処理されない可能性があります。順序付けされたメッセージではEDIバッチ処理を使用しないでください。 FunctionalAck（FA）およびAcknowledgement（ACK/MDN）は順序付けされません。 順序付けでは、デリバリ・チャネルの再試行機能はサポートされません。失敗したドキュメント配信試行の配信を再試行するには、デリバリ・チャネルでの再試行設定ではなく、順序付け機能の自動スタック・ハンドラを使用してください。ドキュメントを順序付けするときは、ドキュメントに使用するデリバリ・チャネルでは再試行の設定を使用しないでください。 |
AQおよびJMSデリバリ・チャネルに対するアウトバウンド・メッセージの順序付け
AQおよびJMSデリバリ・チャネルの場合にアウトバウンド・メッセージの順序付けを可能にするには、例5-1で示されているように、ACTION_NAMEプロパティをTARGET:sequence_target_nameに設定することで、メッセージをエンキューします。
一方、b2b.jarに付属のENQUEUEユーティリティを使用している場合は、eventName（ACTION_NAMEではなく）をTARGET:sequence_target_nameに設定します（例: eventName=TARGET:sequence1）。
デフォルトのチャネルを使用している場合に順序付けを可能にするには、b2b.sequencingTarget = sequence_target_nameを使用します。
ユーザー作成のAQエンキュー・ユーティリティを使用するときは、AQヘッダーとしてACTION_NAMEを使用します。B2Bで提供されているb2b.jarのエンキュー・ユーティリティを使用するときは、eventNameを使用します。
FTPおよびSFTPデリバリ・チャネルに対するアウトバウンド・メッセージの順序付け
FTP/SFTPの順序付けを有効にするには、デリバリ・チャネルの構成で順序付けフラグを選択しただけでは動作しません。FTPリスニング・チャネルで次のパラメータも構成する必要があります。
順序付け
タイムスタンプ・フォーマット
タイムスタンプ・オフセット
タイムスタンプ・ソース
次に示すのはパラメータの値の例です。順序付け: true、タイムスタンプ・フォーマット: 43,55,'MMM d yyyy'、タイムスタンプ・オフセット: +0000、タイムスタンプ・ソース: MMM dd yyyy
順序付けを有効にした場合、ファイルがフォルダにコピーされる順序は、ファイルが処理された順序になることに注意してください。大きいペイロードをコピーする場合、パートナは大きいペイロードのコピーが完了するまで待つ必要があります。順序付けはファイルの最終更新タイムスタンプに基づくため、送信者はその後で次のファイルを送信できます。
HTTPデリバリ・チャネルに対するアウトバウンド・メッセージの順序付け
b2b/sequenceReceiverでメッセージをポストし、追加のHTTPヘッダーTARGET:sequence_target_nameを追加します。追加しないと、シーケンス・ターゲットとしてIPアドレスが使用されます。
このヘッダー付きでエンキューされたメッセージは、FTP、SFTP、JMS、AQ、HTTP/HTTPSなどのトランスポート・プロトコルに対して指定されているシーケンス・ターゲットに基づいて順序付けされます。このヘッダー付きでエンキューされたメッセージは、Oracle B2Bによって処理され、エンキュー時刻に基づいて、取引パートナに順番に配信されます。
順序付けされたメッセージをディスパッチするには、図5-22に示すように、「アウトバウンド・ディスパッチャ数」パラメータを構成します。
デフォルトの値は0で、ディスパッチ（スタック）なしで順序付けする設定です。メッセージ・ロードに応じて、「アウトバウンド・ディスパッチャ数」を適切な値に設定します。
バースト・モードでの順序付け
AQおよびJMSでの順序付けの場合、Oracle B2Bサーバーは、メッセージがキューに追加されている間にポーリングを行わない場合があります。Oracle B2Bがポーリングを開始すると、複数のメッセージがバースト・モードで送信できるようになり、Oracle B2Bは通常の状態での順序を維持できません。バースト・モードでの順序を保証するため、次のことをお薦めします。
AQの場合、TARGET:target_nameプロパティとともに、値としてタイムスタンプを指定したB2B_SEQUENCE_TIMESTAMPのフラグを追加します。
次に例を示します。
TARGET:targetname;B2B_SEQUENCE_TIMESTAMP:1284371552121
この例では、1284371552121はミリ秒単位の時間です（Javaの場合）。
JMSの場合、値としてミリ秒単位の時間を指定したB2B_SEQUENCE_TIMESTAMPとして、新しいヘッダーを追加できます。
インバウンド・メッセージの順序付けは、デリバリ・チャネルの構成の一部として有効になります。これらのデリバリ・チャネルで受信された受信メッセージは、Oracle B2Bによって処理され、インバウンド時刻に基づいた順序付け方法で配信されます。
インバウンド・メッセージの順序付けを有効にするには、図5-23に示すように、デリバリ・チャネルの「順序」プロパティを有効にします。
順序付けされたメッセージをディスパッチするには、図5-22に示すように、「インバウンド・ディスパッチャ数」パラメータを構成します。
AQおよびJMSで、パートナからインバウンド・メッセージを受信したとき、ヘッダーTARGETがある場合は（アウトバウンド・メッセージの順序付けが有効になるのと同様に）、同じ値が使用されて、インバウンド・メッセージは特定のターゲットで順序付けされます。
HTTPインバウンド・メッセージの順序付けの場合は、Oracle B2BでURI /b2b/sequenceReceiverが公開され、このエンドポイントに到着するリクエストは順番に処理されます。複数のシーケンス・ターゲットを使用する場合は、HTTPヘッダーSEQUENCE_TARGETをリクエストに追加することでターゲットを指定できます。
SEQUENCE_TARGETをヘッダーとしてアウトバウンドHTTPメッセージに追加するには、デリバリ・チャネルの「追加トランスポート・ヘッダー」パラメータを使用します。詳細は、表5-3を参照してください。
受信メッセージのHTTPヘッダーにSEQUENCE_TARGETがヘッダーとして含まれる場合は、この値がシーケンス・ターゲットとして使用されます。SEQUENCE_TARGETが使用できず、FROM HTTPヘッダーがある場合は、それがシーケンス・ターゲットとして使用されます。FROM HTTPヘッダーが存在しない場合、B2Bはメッセージの送信元のIPアドレスをシーケンス・ターゲットとして使用します。HTTPリクエストの送信元のIPアドレスは、デフォルトでシーケンス・ターゲットとして処理されます。
通常、取引パートナ停止時間は、バックエンド・アプリケーションでのメッセージのスタックによって処理されます。この場合は、停止時間終了後にB2Bでメッセージ全体を処理する必要があります。そのため、停止時間中はB2Bアプリケーションが十分に活用されない状態になり、取引パートナからメッセージが配信された際には過負荷状態になります。メッセージ処理が急増するため、通常のメッセージ・フローにも影響を与えます。
自動スタック・ハンドラを使用すると、Oracle B2Bは失敗したアウトバウンド・メッセージを順番に再試行します。エンドポイントが配信用にアップすると、シーケンスのすべてのメッセージが配信対象になり、エンドポイントでのメッセージ配信が過負荷状態になる可能性があります。流出を減らすには、b2b.OutboundDispatchIntervalプロパティを使用します。このプロパティでは、メッセージのディスパッチの間隔をミリ秒単位で設定します。
取引パートナの配信失敗時は、対応するメッセージがディスパッチャによって取得されないようにマークされ、バックエンド・アプリケーションではなくB2Bにメッセージがスタックされることになります。メッセージを処理するには、次のプロパティを設定します。
Auto Stack Handler = true
Auto Stack Handler Interval = interval (in seconds)
「自動スタック・ハンドラ」および「自動スタック・ハンドラ間隔」パラメータは、図5-22に表示されています。trueに設定すると、スタックされたメッセージは、ディスパッチャによって適切な間隔で配信できるようになります。「自動スタック・ハンドラ間隔」には、変化する間隔をカンマ区切りの値で指定することもできます。
B2Bが応答しなくなる
アウトバウンド順序付けメッセージの一部として数千のメッセージを実行した後でB2Bが応答しなくなる場合は、ディスパッチャの数を確認してください。ディスパッチャの推奨される最大数は5です。
順序付けされたメッセージの失敗
順序付けされたメッセージの失敗は、次のことが原因である場合があります。
アグリーメント未検出
ECSファイルを更新することで解決できる検証エラー
失敗したメッセージは次のオプションで解決できます。
インバウンドの場合: ワイヤ・メッセージを再送信します。
アウトバウンドの場合: アプリケーション・メッセージを再送信します。
それ以外で、失敗したメッセージは処理しないが、ブロックされているメッセージ（失敗したメッセージの後にあるメッセージ）は配信できるようにする場合は、シーケンス・マネージャ・テーブルの行を手動で削除できます。
同期サポートはコールアウトを使用して提供されます。同期サポートには、受信リクエストに同期方式で応答するプラットフォームが用意されています。
企業には、ビジネス・レスポンスを同期して送信する複数の要件が存在する可能性があります。たとえば、受信ドキュメント270には、同期するドキュメント・レスポンス271が期待される場合があります。企業では、HTTPプロトコル経由で選択した単純なカスタム・ドキュメントの同期サポートを設定する必要があります。
コールアウトは、同期レスポンスを可能にする重要なコンポーネントです。このモデルでは、コールアウトは、受信リクエスト・メッセージをバックエンド・アプリケーションに配信し、バックエンド・アプリケーションから対応するビジネス・レスポンスを取得する役割を果たします。バックエンド・アプリケーションの機能は企業によって異なる可能性があります。したがって、コールアウト実装者は、バックエンド・アプリケーションとの間でメッセージを送受信するために独自のアプローチを選択できます。
B2Bエンジンは、構成済のコールアウトへの入力としてインバウンド・メッセージを用意し、バックエンド・アプリケーションから受信したレスポンスを出力として提供するために、コールアウトを必要とします。コールアウトの出力は、B2Bでアウトバウンド・メッセージとして処理され、同じ出力が同じHTTP接続のインバウンド・メッセージに対するレスポンスとして戻されます。
同期レスポンスを構成する手順は、次のとおりです。
インバウンドおよびアウトバウンド・アグリーメントを設定します。
インバウンド・リクエストを送信してバックエンド・アプリケーションからビジネス・レスポンスを受信する機能を備えたコールアウトを作成します。
コード・サンプルは、例13-3「同期コールバック・コールアウトのサンプル・コード」を参照してください。
コールアウト出力には、Oracle B2Bがその出力をアウトバウンド・メッセージとして処理するために必要なすべての値が存在している必要があります。これには、TO_PARTY、DOCTYPE_NAME、DOCTYPE_REVISIONおよびpayloadなどが含まれます。
TO_PARTY、DOCTYPE_NAME、DOCTYPE_REVISIONなどのコールアウト出力パラメータは大/小文字が区別されます。Oracle B2B JMSアダプタでサポートされているパラメータでは、有効な出力パラメータが出力されます。
コールアウトをインバウンド・アグリーメントに添付します。
すべての同期リクエストは、次のURLに送信される必要があります。
http://host:port_number/b2b/syncreceiver
フローをテストします。
|
注意: アウトバウンド・アグリーメントをレスポンダ側にデプロイするには、ダミー・アウトバウンド・チャネルが必要ですが、Oracle B2Bではダミー・チャネルを使用せずに、インバウンド・リクエストを受信した接続と同じ接続で同期レスポンスを返信します。 |
|
注意: タイムアウトは、HTTPデリバリ・チャネルで追加のトランスポート・ヘッダーとして構成できます。例:timeout=123 |
同期フローの起動側では、次の問題に注意する必要があります。
Generic HTTP、AS2またはebmsチャネルでは、同期フローの起動側で追加トランスポート・ヘッダーの一部としてsyncresponse=trueを追加する必要があります。
AS2またはebmsチャネルでは、同期フローの起動側でack mode none/Asyncを設定する必要があります。
JMSヘッダーでA2A=trueを設定することにより、JMSキューを使用してインバウンド・メッセージとアウトバウンド・メッセージを相関させることができます。
メッセージID（MSG_ID）がバックエンド・アプリケーションから提供されている場合、MSG_IDがB2Bの出力でJMS相関IDに設定されます。それ以外の場合は、JMSメッセージIDがB2Bの出力でJMS相関IDに設定されます。
B2Bの重要な状況では、メッセージが失敗しないで送信先に配信され、遅れずに交換レベル確認応答または機能確認応答を受信することが重要です。
Oracle B2Bでは、チャネル・レベルとドキュメント・レベルでメッセージの配信を再試行できます。
チャネルの再試行はデリバリ・チャネルと関連付けられており、配信を確実に成功させるために使用されます。「再試行数」パラメータと「再試行間隔」パラメータで、再試行の回数と各再試行の間の間隔を構成できます。Oracle B2Bは、設定されている再試行回数に達するまでメッセージの正常な配信を再試行した後、エラーを書き込みます。チャネル再試行パラメータの詳細は、表5-4を参照してください。
確認応答のある交換プロトコル（AS2でのMDNや、ebMSでのAcknowledgementなど）の場合、チャネル再試行を使用してビジネス・メッセージが再試行され、メッセージはCOMPLETE状態になるか、または設定されている再試行回数に達するとERROR状態になります。一般交換の場合は、チャネル・レベルの再試行はトランスポート・エラーの場合にのみ使用されます。
特定のメッセージの残っている再試行回数および再試行間隔は、ビジネス・メッセージ・レポートで確認できます。
ドキュメント再試行はアグリーメントと関連付けられており、メッセージと受信側取引パートナの正常な統合を保証するために使用されます。この機能はタイムアウト値の設定で構成されており、この時間内にアウトバウンド・ビジネス・メッセージに値する機能確認を受信する必要があります。
この機能を有効にするには、次の図で示すように「ドキュメント再試行数」パラメータと「ドキュメント再試行間隔」パラメータを設定します。
ビジネス・メッセージが正常に送信された後、B2Bは指定されている時間だけ機能確認を待つ必要があります。再試行回数に達してもFAを受信しない場合、B2BはB2Bインバウンド・キューに対して例外メッセージを生成します。
特定のメッセージの残っている再試行回数および再試行間隔は、ビジネス・メッセージ・レポートで確認できます。
一般交換のシナリオ
一般交換の場合、ドキュメントの再試行はトランスポート確認を正常に受信したときにのみトリガーされ、標準ベースの交換（AS1/AS2など）の場合は、肯定確認を受信したときだけです。つまり、一般交換の場合はドキュメント再試行は送信の後でのみトリガーされますが、標準確認の場合の再試行は肯定確認を受信したときにだけトリガーされます。否定確認の場合、ドキュメントの再試行はトリガーされません。
チャネル・レベル再試行の相互運用性
チャネル・レベルの再試行は、ドキュメント・レベルの再試行によってはトリガーされません。
チャネル再試行パラメータが設定されていない場合、ドキュメント再試行間隔が経過するとドキュメント・レベルの再試行がトリガーされます。
図5-24に示すように、「パートナ」領域では、「アグリーメントの自動作成」アイコンを使用して、リモート取引パートナのアグリーメントを作成できます。
この機能では、選択したリモート取引パートナに関連付けられているドキュメント定義ごとに1つのアグリーメントが作成されます。アグリーメントは、「アグリーメント」タブを使用してさらにカスタマイズできます。「アグリーメント」タブの詳細は、第6章「取引パートナ・アグリーメントの作成およびデプロイ」を参照してください。
設計時データに使用可能な識別子は、取引パートナを参照するために使用します。識別子は、デプロイされているアクティブなアグリーメントの一部である必要はありません。参照には、適切なドキュメント識別子と交換識別子を使用します。次に例を示します。
AS2-1.1交換プロトコルには、AS2識別子を使用します。
EDI X12ドキュメント・プロトコルには、送信者グループIDと送信者交換IDを使用します。
取引パートナは、計画的な保守のためにオフラインに移行することが必要な場合があります。パートナに正しく通知され、停止時間終了後の配信用にメッセージがキューに格納されるよう、停止時間を構成できます。
取引パートナの停止時間のスケジュール設定と管理の詳細は、第12章「取引パートナ停止時間のスケジュール」を参照してください。
Oracle B2Bでは、複数の取引パートナに同じメッセージを送信できます。これにより、特定のビジネス・ニーズに固有の取引パートナの独自グループを柔軟に作成できます。バックエンド・アプリケーション・インタフェースがグループにメッセージを送信すると、Oracle B2Bはグループのすべてのメンバーにそのメッセージを送信します。
この機能の特徴は次のとおりです。
1. BPELは複数のファイルを送信しないため、BPEL-B2B上およびB2B内のトラフィックが減少します。
2. 取引パートナ・グループの概念がB2Bに導入され、それを使用してブロードキャストが行われます。グループはB2B固有のメタデータのため、BPELユーザーには取引パートナの詳細やグループのことはわかりません。
3. 様々な取引パートナに対する複数のメッセージを処理するためのイベント駆動アプローチが提供されます。
ブロードキャストを使用するには、actionName属性の一部としてグループ名を指定します。actionName属性は次のようになります。
actionName = Grouping:name_of_the_group
ブロードキャストを使用するには、パートナが割り当てられているグループを示す追加の識別子を取引パートナの構成に追加する必要があります。そのためには、新しいカスタム識別子を作成し、必要な取引パートナの名前を関連付けます。詳細は、第10.3項「カスタム取引パートナ・パラメータ・タイプの作成」を参照してください。
