この章では、取引パートナの構成方法について説明します。取引パートナの構成には、取引パートナ・プロファイルの作成(識別子、連絡先情報、取引パートナ・パラメータおよびキー・ストア情報の値の指定)、取引パートナ・ユーザーの追加、ドキュメント定義の追加および送信者ロールと受信者ロールの割当て、およびセキュリティなどのチャネル詳細の構成が含まれます。
図5-1に示すように、Oracle B2Bプロセス・フローの第3手順は、取引パートナの構成です。
この章には次のトピックが含まれます:
Oracle B2Bでは、ホスト取引パートナとリモート取引パートナという2つの取引パートナがトランザクションに関与します。通常、ホスト取引パートナとは、Oracle B2Bがインストールされている組織です。リモート取引パートナとは、ホスト取引パートナがE-Businessトランザクションを実行する相手の組織です。取引パートナは、ホスト(バックエンド)アプリケーション、データベースまたは顧客をトランザクションに含めることができます。トランザクションの起案者または応答者のいずれかが、ホスト取引パートナまたはリモート取引パートナになることができます。
すべての取引パートナ(ホストおよびリモート)は、ホスト取引パートナ組織によって構成されます。リモート・パートナは、ホスト取引パートナがリモート取引パートナごとに作成した取引パートナ・ユーザーを使用して、Oracle B2Bの独自のデータにアクセスできます。図5-2に、取引パートナを構成する手順を示します。
Oracle B2Bでは、デフォルトのホスト取引パートナ名がMyCompanyに設定されますが、この名前は企業にあわせて更新できます。1つ以上のリモート取引パートナを作成した後は、クローニング機能を使用して、類似のトランザクションに参加する新規の取引パートナを作成します。取引パートナのドキュメント定義とデリバリ・チャネル(MLLPチャネルを除く)は、クローニングによってコピーされますが、識別子、連絡先およびユーザーはコピーされません。新規に作成した取引パートナのデリバリ・チャネルは、名前を変更することをお薦めします。
取引パートナを作成して構成した後、その情報は取引パートナ・プロファイルとしてOracleメタデータ・リポジトリに保存されます。パートナ・データは、「プロファイル」タブの「エクスポート」ボタンを使用して、ZIPファイルにエクスポートできます。
取引パートナ・プロファイルを作成するには、次を行います:
このタスクは、初めてOracle B2Bを設定するときに実行します。
「パートナ」リンクをクリックします。
MyCompanyをクリックします。
図5-3に示すように、「編集」をクリックします。
ホスト取引パートナ名およびボタン・ファイル(オプション)を指定して、「OK」をクリックします。
オプションのボタン・ファイルは、16 x 16ピクセルのPNGファイルである必要があります。
ホスト取引パートナ名が「パートナ」リストに表示されます。
「パートナ」リンクをクリックします。
図5-4に示すように、「追加」をクリックします。
パートナ名を指定し、「OK」をクリックします。
リモート取引パートナ名が「パートナ」リストに表示されます。
(オプション)図5-5に示すように、「編集」をクリックして、16 x 16ピクセルの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を使用する場合は、取引パートナとのメッセージ交換時にSSL関連の問題が発生するのを防ぐために、B2BおよびOracle WebLogic Serverの両方のSSL構成で同じキー・ストアを使用することをお薦めします。
「パートナ」リンクをクリックします。
「プロファイル」タブをクリックします。
ホスト取引パートナを選択します。
図5-11に示すように、「キー・ストア」セクションで、パスワードと場所を指定します。
「保存」をクリックします。
注意: 前回誤って入力したキー・ストア・パスワードを再入力した場合は(キー・ストアへの接続の試行時にエラーが発生するため)、正しいパスワードを入力した後にサーバーを再起動する必要があります。 |
ホスト取引パートナの管理者(デフォルトのログイン・ユーザー名とパスワードの組合せ)は、ホストおよびリモートの取引パートナ・ユーザーを追加できます。これらのユーザーは、Oracle B2Bにログインして、ユーザー自身の取引パートナ・データにのみアクセスできます。
次のロールを使用できます。
管理者ロールのユーザーは、ユーザー自身の取引パートナ・データについてのみ、すべてのB2B機能にアクセスできます。他の取引パートナのデータは表示されません。監視ロールのユーザーは、ユーザー自身の取引パートナ・データについてのみ、レポート機能にアクセスできます。他のリンク、および他の取引パートナのデータは表示されません。また、Oracle B2Bでは、ドキュメント・タイプに基づいたアクセス制限がサポートされます。詳細は、第1.4.2項 ドキュメント・タイプへのアクセス制限を参照してください。
ユーザーを追加するには、次を行います:
ユーザーをOracle B2Bに設定するには、そのユーザーがアイデンティティ・ストアにすでに存在している必要があります。ユーザーの作成に使用できるツールはいくつかありますが、図5-12に示すように、Oracle WebLogic Server管理コンソールのセキュリティ・レルム機能を使用する方法もあります。
図5-12 Oracle WebLogic Server管理コンソール: セキュリティ・レルム
注意: Oracle B2Bを管理対象サーバーで実行している場合は、デフォルトのファイルベースのポリシー・ストアがサポートされないため、LDAPベースのポリシー・ストアを使用することをお薦めします。 |
myrealm設定に進むと、「ユーザーおよびグループ」タブにレルム内のすべてのユーザーが表に表示されます。「新規」をクリックし、図5-13に示すページで、ユーザーおよびユーザー・パスワードを追加します。
デフォルト管理者は、ユーザーを追加できます。ホスト管理者およびリモート管理者は、デフォルト管理者によって権限を付与されている場合、ユーザーを追加できます(リモート管理者は各自のデータについてのみ)。
デフォルト管理者は、ユーザーのドキュメント・タイプを追加できます。ホスト管理者およびリモート管理者は、デフォルト管理者によって権限を付与されている場合、ユーザーのドキュメント・タイプを追加できます(リモート管理者は各自のデータについてのみ)。ここでドキュメント・タイプを追加しない場合、ユーザーはすべてのドキュメント・タイプにアクセスできます。
Oracle B2Bホスト管理者はすべてのドキュメント定義を作成します。作成したドキュメント定義はホスト取引パートナに自動的に割り当てられます。また、ホスト管理者は任意のドキュメント定義をリモート取引パートナに割り当てることができます。ホスト取引パートナおよびリモート取引パートナの両方について、各ドキュメントの送信者と受信者が識別されている必要があります。
追加した後でドキュメント定義を更新する方法は、第8.9項 ドキュメント詳細の変更を参照してください。
注意: 「管理」→「ドキュメント」を使用してドキュメント定義を削除するには、その前に、ホスト取引パートナに自動的に割り当てられたドキュメント定義をホスト取引パートナ・プロファイル(およびリモート取引パートナ・プロファイル)から削除する必要があります。 |
Acme社(購入者)が発注をGlobalChips社に送信するシナリオを考えてみます。このトランザクションの中で、Acme社は、GlobalChips社(販売者)が発注を受信した旨の確認を受信します。したがって、このEDIFACTトランザクションでは、発注用と機能確認用の2つのドキュメント定義が使用されます。GlobalChips社は発注を受信し、次に確認を送信します。
取引パートナ・プロファイルに追加するために必要となるドキュメント定義の作成の詳細は、第4章 ドキュメント定義の作成を参照してください。
ドキュメント定義を追加するには、次を行います:
ホストおよびリモートの両方の取引パートナ・プロファイルにドキュメント定義を追加します。このページでは、リモート取引パートナのドキュメント・タイプ・パラメータおよびドキュメント・バージョン・パラメータを変更することもできます。詳細は、第8章 ドキュメント・プロトコルの使用を参照してください。
リモート取引パートナのドキュメント・プロトコル・バージョンおよびドキュメント・タイプ・パラメータを変更する方法は(「バージョン・パラメータのオーバーライド」および「DocTypeパラメータのオーバーライド」パラメータの使用など)、第8.9項 ドキュメント詳細の変更を参照してください。
メッセージの配信方法は、チャネルによって定義されます。それは、取引パートナのセキュリティ特性、トランスポート・プロトコル、交換プロトコルおよび交換プロトコルのオーバーライド要素を指定します。さらに、定義してある場合は、デジタル・エンベロープ、暗号化資格証明、デジタル署名、署名資格証明および検証に対するサポートを指定します。
ホスト取引パートナに対して外部デリバリ・チャネルを構成した場合、そのチャネルは、アグリーメントの作成時にすべてのリモート取引パートナに対して使用できます。これによって、デリバリ・チャネルを複数回(各リモート取引パートナの後に)作成する必要がなくなります。リモート取引パートナに対して外部デリバリ・チャネルを構成した場合、そのチャネルは、アグリーメントの作成時にそのリモート取引パートナに対してのみ使用できます。ホスト取引パートナに対して内部デリバリ・チャネルを構成した場合(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トランスポート・プロトコル)は、リモート取引パートナでのみ使用できます。また、HL7またはカスタムのドキュメントで使用されます。MLLPを使用すると、同じチャネルを使用してメッセージを送受信でき、チャネルをサーバーまたはクライアントとして構成できます。 MLLP接続は、永続接続または一時接続の場合があります。 永続接続の特徴は次のとおりです。
一時接続の特徴は次のとおりです。
詳細は、第5.5.2項 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暗号化および大きなドキュメントに対する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では、 |
内部/外部 |
|
Webサーバーとの間でメッセージを送受信するトランスポート。 |
外部 |
|
電子メール・サーバーとの間でメッセージを送受信するトランスポート。 |
外部 |
|
Generic TCP |
開始ブロック、終了ブロック、ヘッダー長、メッセージ長索引およびヘッダーの保持など、カスタマイズされた交換プロトコル・パラメータをサポートするトランスポート。 |
外部 |
Generic MFT-1.0 |
リモートMFTサーバーにあるファイルとの間でメッセージを送受信するトランスポート。 |
外部 |
図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チャネルには適用されません。
取引パートナのチャネルを構成するには、次を行います:
「トランスポート・プロトコル・パラメータ」タブをクリックします。
表5-3に示すように、タスク1で選択したチャネル/トランスポート・プロトコルに応じて、トランスポート・プロトコル・パラメータを指定します。
表5-3では、トランスポート・プロトコル・パラメータ(アルファベット順に表示されています)およびパラメータが適用されるプロトコルについて説明します。
表5-3 トランスポート・プロトコル・パラメータ
パラメータ | 説明 | 使用するプロトコル |
---|---|---|
追加トランスポート・ヘッダー |
メッセージを取引パートナに送信するために使用するカスタムHTTPヘッダー。 同期レスポンス処理の場合は、追加トランスポート・ヘッダーを設定する必要があります。送信者がレスポンスをインバウンド・メッセージとして処理するため、追加トランスポート・ヘッダーの一部として |
AS2 (オプション) 汎用HTTP (オプション) |
アーカイブ・ディレクトリ |
B2Bチャネルにより、処理済ファイルはこのディレクトリに移動されます。デフォルトでは、この処理は破壊的読取りです(処理済ファイルはエンドポイントから削除されます)。この場合、ファイルは指定されたパスに移動されます。 |
Generic File-1.0 (オプション) Generic FTP-1.0 (オプション) Generic SFTP-1.0 (オプション) |
キャッシュ接続 |
有効にすると、ファイルの一覧表示や処理は同じセッションで実行されます(これに対して、デフォルトでは、一覧表示や処理は異なるセッションで実行されます)。 |
Generic FTP-1.0 (オプション) |
チャネル・マスク |
FTPに対してSSLを有効にするには、次のいずれかを入力します。
デフォルトは「なし」(SSLなし)です。 |
汎用FTP (オプション) |
暗号スイート |
暗号化に優先暗号化を指定します。 |
汎用FTP (オプション) |
接続ファクトリ |
接続ファクトリのJNDIロケーションまたはJavaクラス名を |
汎用JMS (オプション) |
接続モード |
「クライアント」または「サーバー」から選択します。 |
MLLP-1.0 (必須、リモート取引パートナの場合のみ) Generic TCP (必須) |
コンシューマ |
メッセージを受信するクライアント。 |
汎用AQ (オプション) |
コンテンツ・タイプ |
電子メールで送信されるペイロードのコンテンツ・タイプ。デフォルトのコンテンツ・タイプは |
AS1 (オプション) 汎用電子メール(オプション) |
制御ポート |
FTPはデフォルト・ポート21で稼働します。このポート番号は表示されません。値を指定して、デフォルトのFTPポート値(21)を変更します。 |
汎用FTP (オプション) |
データ・ポート |
有効なFTP接続では、このオプションを使用してFTPサーバーの静的/固定データ・ポートを構成します。 |
汎用FTP (オプション) |
データソース |
AQキューにアクセスするためのJDBCデータソースのJNDI名。 |
汎用AQ (オプション) |
接続先名 |
JMS接続先名。 |
汎用JMS (オプション) |
接続先プロバイダ |
B2Bが、リモート・サーバーで使用可能なJMSキューまたはJMSトピックに接続できるようにします。値には、ターゲット・サーバーへの接続に必要なJNDIプロパティを指定します。キー/値の各ペアのセパレータには、 |
Generic JMS-1.0 (オプション) |
ディレクトリ名フォーマット |
受信するディレクトリ名フォーマット |
汎用FTP (オプション) |
電子メールID |
メッセージ配信先の電子メール・アドレス(AQまたはJMSでのファイル・チャネルやキューのパスの指定と同じ)。 |
AS1 (必須) 汎用電子メール(必須) |
電子メール・サーバー |
「IMAP」または「POP3」を選択します。 |
AS1 (必須) 汎用電子メール(必須) |
CCCの有効化 |
SSLセッションでの認証をB2Bで有効にし、プレーン・ソケット上で残りのファイル転送コマンドを実行します。 |
Generic FTP-1.0 (オプション) |
マーカーの有効化 |
有効にすると、読取りまたは書込みの完了を示す、ソースと同じ名前の0バイトのファイルが作成されます。このファイルはソースと同じ名前ですが、拡張子は |
Generic File-1.0 (オプション) Generic FTP-1.0 (オプション) Generic SFTP-1.0 (オプション) |
エンコーディング |
インバウンド・ファイルのコンテンツの変換のためにB2Bで使用するエンコーディング。 |
汎用FTP (オプション) |
ファイル名フォーマット脚注1 |
次のファイル名フォーマットを使用できます。 %FROM_PARTY% %TO_PARTY% %DOCTYPE_NAME% %DOCTYPE_REVISION% %MSG_ID% %TIMESTAMP% 次のファイル名フォーマットはebMSドキュメントでのみ使用できます。 %ACTIONNAME% これらのファイル名フォーマットは、次の例に示すように、組み合せて使用できます。 %TO_PARTY%_%DOCTYPE_NAME%_%DOCTYPE_REVISION%.dat これによって、 後述の脚注を参照してください。 |
汎用ファイル(オプション) 汎用FTP (オプション) 汎用SFTP (オプション) |
ファイル名セパレータ |
キーを分割するファイル名フォーマット・セパレータ。_ (下線)以外の文字を使用する場合は、ファイル名セパレータ・フィールドに値を指定します。 「ファイル名セパレータ」パラメータは「ファイル名フォーマット」パラメータと連携するため、「ファイル名フォーマット」パラメータと「ファイル名セパレータ」パラメータで同じセパレータ値を使用する必要があります。 たとえば、「ファイル名フォーマット」に 文字$および^は、ファイル名セパレータとして使用することはできません。 デフォルト値は_ (下線)です |
汎用ファイル(オプション) 汎用FTP (オプション) 汎用SFTP (オプション) |
フォルダ |
絶対ディレクトリ・パスをお薦めします。 |
AS1 (オプション) 汎用電子メール(オプション) |
フォルダ名 |
絶対ディレクトリ・パスをお薦めします。 |
汎用ファイル(必須) 汎用FTP (必須) |
ホスト名 |
メッセージを交換する、取引パートナのトランスポートまたは電子メール・サーバー。 MLLP 1.0プロトコルでは、接続モードが「サーバー」に設定されている場合は、ホスト名をB2Bサーバーにする必要があります。接続モードが「クライアント」に設定されている場合は、ホスト名をリモートB2Bサーバー(MLLPサーバー)にする必要があります。 |
AS1 (必須) 汎用AQ (オプション) 汎用FTP (必須) MLLP-1.0 (必須、リモート取引パートナの場合のみ) 汎用SFTP (必須) 汎用電子メール(必須) Generic TCP (必須) |
ペイロードのみマップ |
JMSマップ・メッセージにペイロードのみ含めることを示します。 |
汎用JMS (オプション) |
トピック |
JMSがトピック(キューではなく)と通信することを示す場合に選択します。 |
汎用JMS (オプション) |
VANメールボックス |
有効にすると、B2BではエンドポイントをVANメールボックスとして処理し、それに応じた処理を行います。 |
Generic FTP-1.0 (オプション) |
メッセージ・タイプ |
JMSメッセージ・タイプとして、BYTES、TEXTまたはMAPを選択します。 |
汎用JMS (オプション) |
最小経過時間 |
エンドポイントに送信されるファイルは、入力された時間(ミリ秒単位)の経過後に処理されます。 |
Generic File-1.0 (オプション) Generic FTP-1.0 (オプション) Generic SFTP-1.0 (オプション) |
パスフレーズおよびパスフレーズの確認 |
秘密鍵ファイルの場所を入力し、その秘密鍵ファイルをパスフレーズで保護する場合は、パスフレーズを入力します。 |
汎用SFTP (オプション) |
パスワードおよびパスワードの確認 |
パスワード認証を使用するには、HTTP基本認証で使用するキー・ストアのパスワードを指定します。 |
AS1 (オプション) AS2 (オプション) 汎用AQ (オプション) ebMS-2.0 (オプション) ebMS-1.0 (オプション) 汎用FTP (オプション) 汎用HTTP (オプション) 汎用SFTP (オプション) 汎用JMS (オプション) 汎用電子メール(オプション) RosettaNet-V02.00 (オプション) RosettaNet-01.10 (オプション) |
パス |
メッセージを送受信する絶対ディレクトリ・パス。 |
汎用SFTP (必須) |
永続接続 |
「false」(デフォルト値)に設定すると、メッセージは新規接続で送信され、確認を受信すると接続がクローズします。メッセージの受信者側では、確認が取引パートナに返信されると接続がクローズします。「true」に設定すると、キャッシュされた接続を使用してすべてのメッセージが交換されます。 |
MLLP-1.0 (オプション、リモート取引パートナの場合のみ) Generic TCP (オプション) |
ポーリング間隔 |
Oracle B2Bがインバウンド・メッセージについてサーバーをポーリングする間隔(秒単位)。 |
AS1 (オプション) 汎用ファイル(使用不可) 汎用AQ (オプション) 汎用FTP (使用不可) MLLP-1.0 (オプション、リモート取引パートナの場合のみ) 汎用SFTP (使用不可) 汎用JMS (オプション) 汎用電子メール(使用不可) Generic TCP (オプション) |
ポート番号(またはポート) |
AQはデフォルト・ポート1521で稼働します。 SFTPはデフォルト・ポート22で稼働しますが、別のポートに変更することもできます。 MLLP 1.0プロトコルでは、接続モードが「サーバー」に設定されている場合、ポート番号は有効なTCPポート番号である必要があります。接続モードが「クライアント」に設定されている場合、ポート番号はMLLPサーバーで使用するポートと同じである必要があります。 |
汎用AQ (オプション) MLLP-1.0 (必須、リモート取引パートナの場合のみ) 汎用SFTP (必須) Generic TCP (必須) |
ファイル名の保持 |
ファイル名が保持されます。 |
Generic File-1.0 (オプション) Generic FTP-1.0 (オプション) Generic SFTP-1.0 (オプション) |
秘密鍵 |
公開鍵認証を使用するには、秘密鍵ファイルの場所を指定します。秘密鍵ファイルがパスフレーズで保護されている場合は、パスフレーズも指定する必要があります。 |
汎用SFTP (オプション) |
キュー名 |
AQキュー名。 |
汎用AQ (オプション) |
受信者 |
AQキューへのメッセージの配信時に使用する値。たとえば、受信者を |
汎用AQ (オプション) |
添付ファイルとして送信 |
有効にすると、ペイロードがメッセージ本文である通常の配信ではなく、メッセージ(ペイロード)が電子メール添付ファイルとして送信されます。 |
AS1 (オプション) 汎用電子メール(オプション) |
シーケンス (順序付け) |
着信のEDI、HL7またはカスタム・メッセージをバックエンド・アプリケーションに順番に配信する必要がある場合に、このプロパティを有効にします。 詳細は、第5.5.4項 メッセージの順序付けを参照してください。 |
MLLP-1.0 (オプション、リモート取引パートナの場合のみ) Generic File-1.0 (オプション) Generic FTP-1.0 (オプション) 汎用SFTP (オプション) Generic TCP (オプション) |
SID |
Oracleデータベースを識別するためのシステムID。 |
汎用AQ (オプション) |
件名 |
電子メール・メッセージの件名ヘッダー。 |
AS1 (オプション) 汎用電子メール(オプション) |
サブスクライバID |
JMSサブスクライバIDは、JMSがトピックと通信する場合に必要です。 |
汎用JMS |
タイムアウト |
確認メッセージ用に一時MLLP接続がソケットをオープンしている時間を定義します。デフォルトのタイムアウト値は300秒です。このパラメータは一時MLLP接続にのみ適用され、永続接続には適用されません。 タイムアウトは、HTTPデリバリ・チャネルで追加のトランスポート・ヘッダーとして構成できます。 値の例: |
MLLP-1.0 (オプション、リモート取引パートナの場合のみ) Generic TCP (オプション) |
タイムスタンプ・フォーマット タイムスタンプ・フォーマット、タイムスタンプ・オフセットおよびタイムスタンプ・ソースのパラメータについて パラメータ・レシーバ・ファイルの最小経過時間に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 (必須) 汎用HTTP (必須) RosettaNet-V02.00 (必須) RosettaNet-01.10 (必須) |
JMS IDの使用 |
B2BメッセージIDにJMSメッセージIDを使用します。その結果、JMSレベルで相関が容易になります。 |
Generic JMS-1.0 (オプション) |
ユーザー名 |
ターゲット・サーバーに接続するときに使用するユーザー名(ログイン名)。HTTP基本認証で使用されます。B2Bは構成済のJNDIデータソースを使用してキューに接続できるため、AQとJMSの場合、この値はオプションです。 |
AS1 (オプション) AS2 (オプション) 汎用AQ (オプション) ebMS-2.0 (オプション) ebMS-1.0 (オプション) 汎用FTP (必須) 汎用HTTP (オプション) 汎用SFTP (必須) 汎用JMS (オプション) 汎用電子メール(オプション) RosettaNet-V02.00 (オプション) RosettaNet-01.10 (オプション) |
プロキシの使用 |
プロキシ・サーバーを選択します(使用する場合)。 |
AS2 (オプション) ebMS-2.0 (オプション) ebMS-1.0 (オプション) 汎用FTP (オプション) 汎用HTTP (オプション) 汎用SFTP (オプション) RosettaNet-V02.00 (オプション) RosettaNet-01.10 (オプション) |
脚注1ファイル・チャネルまたはFTPチャネルでは、filename format
が設定されている場合、directory name format
は無視されます。
「保存」をクリックします。
表5-4に示すように、タスク1で選択したチャネル/トランスポート・プロトコルに応じて、チャネル属性を指定します。
表5-4 チャネル属性
パラメータ | 説明 | 使用するプロトコル |
---|---|---|
確認モード |
取引パートナがメッセージを受信するモードとして、SYNC、ASYNCまたは「NONE」を選択します。すべての汎用交換に対して「なし」を選択します。 MLLP交換の場合、一時接続にはSYNCまたはASYNCを選択します。永続接続には「NONE」を選択します。 |
AS1 (オプション) AS2 (オプション) ebMS-2.0 (オプション) ebMS-1.0 (オプション) MLLP-1.0 (必須、リモート取引パートナの場合のみ) RosettaNet-V02.00 (オプション) RosettaNet-01.10 (オプション) |
圧縮済 |
メッセージの圧縮を選択します。 |
AS1 (オプション) AS2 (オプション) このパラメータは、その他のプロトコルのB2Bインタフェースで表示されることもありますが、AS1およびAS2でのみ使用できます。 |
説明 |
説明(オプション)を入力します。 |
AS1 (オプション) AS2 (オプション) ebMS-2.0 (オプション) ebMS-1.0 (オプション) MLLP-1.0 (オプション、リモート取引パートナの場合のみ) 汎用ファイル(オプション) 汎用AQ (オプション) 汎用FTP (オプション) 汎用HTTP (オプション) RosettaNet-V02.00 (オプション) RosettaNet-01.10 (オプション) 汎用SFTP (オプション) 汎用JMS (オプション) 汎用電子メール(オプション) Generic TCP (オプション) |
チャネルの有効化/チャネルの無効化 |
チャネルとは、ホスト取引パートナのホスト・アプリケーションとそのインストール間の通信インタフェースです。 |
MLLP-1.0 (必須、リモート取引パートナの場合のみ) Generic TCP (必須) |
内部 注意: 「内部」を選択した場合、B2Bインタフェースでは無効なプロトコルでも選択可能になりますが、汎用プロトコル以外は選択しないでください。 |
このオプションは、ホスト取引パートナの企業に対してチャネルが内部の場合に選択します。 |
このオプションを選択した場合は、汎用プロトコルのみが有効になります。 汎用ファイル(オプション) 汎用AQ (オプション) 汎用FTP (オプション) 汎用HTTP (オプション) 汎用SFTP (オプション) 汎用JMS (オプション) 汎用電子メール(オプション) このオプションを選択しない場合は、すべてのプロトコルが有効になります。 AS1 (オプション) AS2 (オプション) ebMS-2.0 (オプション) ebMS-1.0 (オプション) 汎用ファイル(オプション) 汎用AQ (オプション) 汎用FTP (オプション) 汎用HTTP (オプション) RosettaNet-V02.00 (オプション) RosettaNet-01.10 (オプション) 汎用SFTP (オプション) 汎用JMS (オプション) 汎用電子メール(オプション) |
再試行数 |
Oracle B2Bがメッセージの送信を再試行する回数。 詳細は、第5.5.7項 配信再試行オプションの構成を参照してください。 |
AS1 (オプション) AS2 (オプション) ebMS-2.0 (オプション) ebMS-1.0 (オプション) 汎用ファイル(オプション) 汎用AQ (オプション) 汎用FTP (オプション) 汎用HTTP (オプション) MLLP-1.0 (オプション、リモート取引パートナの場合のみ) RosettaNet-V02.00 (オプション) RosettaNet-01.10 (オプション) 汎用SFTP (オプション) 汎用JMS (オプション) 汎用電子メール(オプション) Generic TCP (オプション) |
再試行間隔 |
B2Bでメッセージを再送信するときの間隔(分で指定)。メッセージのステータスが「完了」でない場合、B2Bはメッセージの再送信を試みます。 確認のプロトコルの場合、B2Bは確認を待ちます(以前は確認所要時間パラメータと呼ばれていました)。確認を受信しなかった場合、B2Bでは、再試行間隔の設定によって再試行が実行されます。 詳細は、第5.5.7項 配信再試行オプションの構成を参照してください。 |
AS1 (オプション) AS2 (オプション) ebMS-2.0 (オプション) ebMS-1.0 (オプション) 汎用ファイル(オプション) 汎用AQ (オプション) 汎用FTP (オプション) 汎用HTTP (オプション) MLLP-1.0 (オプション、リモート取引パートナの場合のみ) RosettaNet-V02.00 (オプション) RosettaNet-01.10 (オプション) 汎用SFTP (オプション) 汎用JMS (オプション) 汎用電子メール(オプション) Generic TCP (オプション) |
トランスポート・コールアウト |
インバウンド・メッセージの場合、B2Bは、トランスポートからメッセージを受信した直後にトランスポート・コールアウトを呼び出します。アウトバウンド・メッセージの場合、B2Bは、トランスポートにメッセージを送信する直前にトランスポート・コールアウトを呼び出します。 |
AS1 (オプション) AS2 (オプション) ebMS-2.0 (オプション) ebMS-1.0 (オプション) 汎用ファイル(オプション) 汎用AQ (オプション) 汎用FTP (オプション) 汎用HTTP (オプション) MLLP-1.0 (オプション、リモート取引パートナの場合のみ) RosettaNet-V02.00 (オプション) RosettaNet-01.10 (オプション) 汎用SFTP (オプション) 汎用JMS (オプション) 汎用電子メール(オプション) Generic TCP (オプション) |
「保存」をクリックします。
「交換プロトコル・パラメータ」タブをクリックします。
表5-5に示すように、タスク1で選択したチャネル/トランスポート・プロトコルに応じて、交換プロトコル・パラメータを指定します。
表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 (オプション) |
終了ブロック |
このプロパティの値には文字列を指定できます。このプロパティは、メッセージの終了を示すために使用されます。通常、終了ブロックは取引パートナにメッセージが送信された後で送信されます。 |
Generic TCP (オプション) |
終了ブロック文字 |
この値は1文字のみです。終了ブロック文字はワイヤ・メッセージ・ペイロードには表示されません。デフォルト値は0x1C (16進数)です。 |
MLLP-1.0 (オプション、リモート取引パートナの場合のみ) |
ヘッダー長 |
このプロパティは、ヘッダー・サイズを定義します。実際のデータの前に付けられます(これには、開始ブロック、メッセージ長、埋め込まれたヘッダーが含まれます)。 |
Generic TCP (オプション) |
TPをデリバリ・チャネルにより識別 |
デリバリ・チャネルを使用して取引パートナが識別されます。 リモート取引パートナ用に構成されたデリバリ・チャネルによって(MLLP IDの使用によってではなく)着信メッセージを識別するには、このパラメータを有効にします。送信者の識別が重要でない場合、この機能は匿名取引パートナとしての役割を果たします。このパラメータがチェックされない場合、MLLP交換にMLLP ID (または、アグリーメントを識別するためのHL7メッセージ・アプリケーションIDやHL7メッセージ機能IDなどの一部のドキュメント・レベルの識別子)が必要となります。 |
MLLP-1.0 (オプション、リモート取引パートナの場合のみ) |
即時確認 注意: 着信ビジネス・メッセージ(たとえば、管理番号1017)のMLLP即時確認では、A1017のように管理番号の前にAが付けられます。これは、それがACK管理番号であることを取引パートナに示します。前に付けられる文字列が許容される長さを超える場合は(たとえば、受信側で検証ルールに違反する場合など)、「確認制御IDのマップ」パラメータを使用します。 |
即時確認は、ドキュメント・レイヤーではなくTCPトランスポート・レイヤーで生成されて伝送されます。即時確認は機能確認の代替方法です。即時確認は、機能確認で変換エラーや検証エラーが検出されたため機能確認の応答時間が長くなる場合に使用できます(たとえば、ビジネスに不可欠なヘルス・ケア・アプリケーションの場合)。 Oracle B2Bでは、即時確認を次のモードで送信できます。
|
MLLP-1.0 (オプション、リモート取引パートナの場合のみ) |
確認制御IDのマップ |
ビジネス・メッセージのMSH.10メッセージ・ヘッダーから即時確認のMSH.10メッセージ・ヘッダーへのマッピングを有効にする場合に選択します。 |
MLLP-1.0 (オプション、リモート取引パートナの場合のみ) |
トリガー・イベントのマップ |
トリガー・イベントとともに即時確認を送信します。 |
MLLP-1.0 (オプション、リモート取引パートナの場合のみ) |
メッセージ順序セマンティック |
CPP/CPAのプレースホルダ。実行時は対象外です。 |
ebMS-2.0 (オプション) |
メッセージ長索引 |
このプロパティは、ヘッダーで使用可能なデータ・サイズを示します。開始索引から終了索引まで、メッセージ・サイズを定義します。 |
Generic TCP (オプション) |
期間の保持 |
CPP/CPAのプレースホルダ。実行時は対象外です。 |
ebMS-2.0 (オプション) |
HL7確認の永続化 |
ACKペイロードが永続化されているかどうかを示します。これは、即時確認および確認の破棄の場合にのみ適用されます。 |
MLLP 1.0 (オプション) |
受信配信オプション |
このパラメータは、非同期モードの場合にMDNが返信するURLを構成するために使用します。 |
AS2 (オプション) |
ヘッダーの保持 |
取引パートナ(アウトバウンド・メッセージの場合)またはOracle B2B (インバウンド・メッセージの場合)にメッセージを送信する間にヘッダーを保持するには、このプロパティを選択します。 ヘッダーを保持すると、B2Bはカスタム・ヘッダーを処理しません。カスタム・ヘッダーはトランスポート・コールアウトを使用して処理します。 |
Generic TCP (オプション) |
パーティタイプと値の送信 |
有効にすると、メッセージ・ヘッダーのパーティ・タイプと値がバックエンド・アプリケーションに送信されます。 |
ebMS-2.0 (オプション) ebMS-1.0 (オプション) |
署名および圧縮済 |
選択した場合、メッセージは最初に署名され、その後、圧縮されます。選択しない場合には、メッセージは最初に圧縮され、その後、署名されます。 |
AS1 (オプション) AS2 (オプション) |
開始ブロック |
この値には文字列を指定できます。 |
Generic TCP (オプション) |
開始ブロック文字 |
この値は1文字のみです。開始ブロック文字はワイヤ・メッセージ・ペイロードには表示されません。デフォルト値は0X08 (16進数)です。 |
MLLP-1.0 (オプション、リモート取引パートナの場合のみ) |
「保存」をクリックします。
「セキュリティ」タブをクリックします。
表5-6に示すように、タスク1で選択したチャネル/トランスポート・プロトコルに応じて、セキュリティ・パラメータを指定します。
注意: ホスト取引パートナ用のキー・ストアの場所が指定されている場合は、「デジタル署名」および「暗号化」リストに使用可能な証明書が移入されます。詳細は、タスク6、「ホスト取引パートナのキー・ストア情報の指定」を参照してください。 |
表5-6 セキュリティ・パラメータ
パラメータ | 説明 | 使用するプロトコル |
---|---|---|
確認署名済 |
応答者が必ずメッセージの受信を確認するようにするには、このオプションを選択します。何も指定する必要はありません。 |
AS1 (オプション) AS2 (オプション) ebMS-2.0 (オプション) ebMS-1.0 (オプション) RosettaNet-V02.00 (オプション) RosettaNet-01.10 (オプション) |
デジタル署名 |
デジタル署名証明書を使用するには、キー・ストアに対応する秘密鍵が必要です。 「メッセージ署名済」を選択した場合は、AS1に対して次を選択します。 SMIME 3.0 with SHA1 - RSA 「メッセージ署名済」を選択した場合は、AS2に対して次のいずれかを選択します。 SMIME 3.0 with MD5 - RSA SMIME 3.0 with SHA1 - RSA 「メッセージ署名済」を選択した場合は、ebMS-2.0およびebMS-1.0に対して次のいずれかを選択します。 XMLDSIG with SHA1 - RSA XMLDSIG with SHA1 - DSA 「メッセージ署名済」を選択した場合は、RosettaNet-V02.00に対して次のいずれかを選択します。 SMIME 3.0 with MD5 - RSA SMIME 3.0 with SHA1 - RSA SMIME 2.0 with MD5 - RSA SMIME 2.0 with SHA1 - RSA XMLDSIG with SHA1 - RSA XMLDSIG with SHA1 - DSA 「メッセージ署名済」を選択した場合は、RosettaNet-01.10に対して次のいずれかを選択します。 SMIME 3.0 with MD5 - RSA SMIME 3.0 with SHA1 - RSA SMIME 2.0 with MD5 - RSA SMIME 2.0 with SHA1 - RSA |
AS1 AS2 ebMS - 2.0 ebMS-1.0 RosettaNet-V02.00 RosettaNet-01.10 |
暗号化 |
暗号化証明書を使用する場合、秘密鍵の入力は必要ありません。 「メッセージ暗号化済」を選択した場合は、AS1およびAS2に対して次のいずれかを選択します。 SMIME 3.0 with DES SMIME 3.0 with 3DES SMIME 3.0 with RC2-40 SMIME 3.0 with RC2-64 SMIME 3.0 with RC2-128 「メッセージ暗号化済」を選択した場合は、ebMS-2.0およびebMS-1.0に対して次のいずれかを選択します。 XMLENC with 3DES-RSA-v1.5 XMLENC with AES-128 RSA-OAEP XMLENC with AES-192 RSA-OAEP XMLENC with 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の場合、B2Bでは署名にSHA1のみがサポートされます。AS1の署名にMD5はサポートされません。 |
場合によっては、通常のXML/テキスト・ファイルではなく、バイナリ・コンテンツを転送できます。ビジネス・ニーズに応じて、PDF、XLS、ZIPおよびGIFなどのバイナリ・ファイルもOracle B2Bを使用して転送できます。
バイナリ・コンテンツは、インバウンドまたはアウトバウンドに転送できます。
Oracle B2Bのアウトバウンド・バイナリ・ファイル転送は、Generic/AS2交換プロトコルでカスタム・ドキュメントに対して使用されます。バイナリ・ファイル転送には、File、FTP、SFTPまたはJMSの各内部リスニング・チャネルを使用できます。File、FTPまたはSFTPの各チャネルの場合、ファイル名フォーマットまたはディレクトリ名フォーマットで、ドキュメント・タイプとドキュメント・バージョンおよびFrom Party
とTo Party
の情報が指定されている必要があります。
JMS内部リスニング・チャネルの場合、イベント名でBINARYPAYLOAD
プロパティにtrue
が設定されている必要があります。
eventName=BINARYPAYLOAD:true
前述のプロパティを設定した後、JMSメッセージ本文でバイナリ・ペイロードを(バイト・メッセージの形式で)指定する必要があります。
message.setBody(binarypayload);
Oracle B2Bは、構成されている送信元、宛先、ドキュメント・タイプおよびリビジョンに基づいてアグリーメントを識別し、取引パートナに送信します。
注意: アウトバウンド・バイナリ転送の場合、アグリーメント・レベルでドキュメントの検証を無効にする必要があります。 |
Oracle B2Bのインバウンド・バイナリ・ファイル転送は、Generic/AS2交換プロトコルでカスタム・ドキュメントに対して使用されます。File、FTPまたはSFTPの各取引パートナ・リスニング・チャネルの場合、送信元、宛先、ドキュメント・タイプおよびドキュメント・リビジョンの情報でファイル名フォーマットを構成する必要があります。Oracle B2Bは、ファイル名フォーマットに基づいてアグリーメントを識別し、バックエンド・アプリケーションに送信します。
Generic HTTP/AS2の場合、Oracle B2Bは、DOCTYPE_NAME
およびDOCTYPE_REVISION
などのHTTPヘッダーに基づいてアグリーメントを識別し、バックエンド・アプリケーションに送信します。
次に、インバウンド・リスニング・チャネルのファイル名フォーマットのサンプルを示します。
%FROM_PARTY%_%DOCTYPE_NAME%_%DOCTYPE_REVISION%_%TIMESTAMP%.dat
このフォーマットに従ったファイル名のサンプルを次に示します。
GlobalChips_ORDERS_1.0.123333333.dat
MLLPデリバリ・チャネルは、サーバーとクライアント間の双方向ハンドシェイクによって確立されます。その他のトランスポートとは異なり常に双方向であるため、メッセージの送信と受信の両方に使用されます。MLLPデリバリ・チャネルはリモート取引パートナに対してのみ構成され、サーバー・ソケットまたはクライアント・ソケットとして構成されます。サーバー・ソケットとしては、このチャネルでは指定したポートでの接続が承認されます。クライアント・ソケットとしては、このチャネルでは指定したIPアドレスおよびポートでの接続が確立されます。いずれのソケット・タイプの場合も、永続または一時の接続タイプを指定します。確立後の永続接続はキャッシュされ、エンドポイントのライフサイクル全体を通して、メッセージ交換のチャネルとして機能します。一時接続は、ビジネス・メッセージとその確認で構成される1セットのメッセージを交換するためだけのチャネルとして機能します。第5.5.2.1項 接続モードのオーバーライドを参照してください。
送信者にはMLLPクライアント・デリバリ・チャネルを構成し、受信者にはMLLPサーバー・チャネルを構成することをお薦めします。たとえば、Acme社からGlobalChips社にHL7メッセージ、カスタム・メッセージまたは位置指定フラット・ファイル・メッセージを送信する場合、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のように表示されます。チャネルを作成した後は、MLLP固有パラメータと汎用TCP固有パラメータがグループ化された2つのサブタブが表示されます。 |
これらのパラメータの説明については、表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機能は、デリバリ・チャネルと関連付けられたエンドポイントを動的に変更できる柔軟性を提供します。これは、デリバリ・チャネルのIPアドレスをメッセージ・エンキュー・ヘッダーのactionName
/eventName
属性でオーバーライドすることで行われます。
例:
eventName=DynamicIP:GlobalChips:IP_address:port_number
または
actionName=DynamicIP:GlobalChips:IP_address:port_number
この機能は、次の構文を使用して、B2Bコンポジットでも(SOAサービス・コンポーネント・アーキテクチャ(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プロパティの設定と取得を参照してください。
ebMSの場合、Oracle B2Bは、アクション、サービスおよびサービス・タイプの複数チャネルを提供します。Oracle B2Bは、複数チャネルから特定のアクション、サービスおよびサービス・タイプに関連付けられているアウトバウンド・チャネルを識別し、そのチャネルを使用して取引パートナと通信します。
この機能を使用して、ebMSチャネルの次のパラメータをオーバーライドできます。
URL
再試行数
再試行間隔
重複削除
確認署名済
確認要
アクション、サービスおよびサービス・タイプ、およびオプションの開始ロールおよび終了ロールの各パラメータに応じて、該当するデリバリ・チャネルが、取引パートナとの通信および関連する確認に使用されます。
マルチスレッド・システムでは、最初に作成されたメッセージが必ずしも最初に接続先に到着するわけではないため、メッセージを順序どおりに交換することが困難な場合があります。このビジネス要件がある企業では、Oracle B2Bのシーケンサおよびディスパッチャを利用できます。シーケンサでは、到着時刻に基づいてメッセージに順序が付けられます。ディスパッチャでは、順序が付けられたメッセージが送信されます。メッセージの順序付けは、アウトバウンドおよびインバウンドの方向に使用できます。
メッセージの順序付けでは、MLLP交換(TCPトランスポート)や一般交換(FILE、FTP、SFTP、JMS、AQおよびHTTPトランスポート)などのプロトコルがサポートされています。
注意: メッセージの順序付けはすべてのドキュメントで使用できますが、認定されているのは、EDI、HL7およびカスタムのドキュメント・プロトコルのみです。 一時モードのMLLP接続では、順序付けはサポートされません。 EDIバッチ処理では、メッセージの順序付けはサポートされません。メッセージの順序付けがバッチの一部として有効になっている場合、エラーが発生して一部のメッセージが処理されない可能性があります。順序付けされたメッセージではEDIバッチ処理を使用しないでください。 FunctionalAck (FA)および確認(ACK/MDN)は順序付けされません。 順序付けはデリバリ・チャネルの再試行機能をサポートしていません。配信に失敗したドキュメントの配信を再試行する場合は、デリバリ・チャネルの再試行設定を使用するのではなく、「順序付け」機能の「自動スタック・ハンドラ」を使用します。ドキュメントに順序が付けられた場合は、そのドキュメントで使用されるデリバリ・チャネルで再試行設定の使用を回避する必要があります。 |
AQおよびJMSデリバリ・チャネルに対するアウトバウンド・メッセージの順序付け
アウトバウンド・メッセージの順序付けを有効にするには、例5-1に示すように、AQまたはJMSデリバリ・チャネルの場合、ACTION_NAME
プロパティをTARGET:
sequence_target_name
に設定し、メッセージをエンキューします。
b2b.jar
のENQUEUEユーティリティを使用する場合は、ACTION_NAME
ではなく、eventName
を、TARGET:
sequence_target_name
に設定します。たとえば、eventName=TARGET:sequence1
のように設定します。
デフォルト・チャネル使用時に順序付けを有効にする場合は、b2b.sequencingTarget
=
sequence_target_name
を使用します。
自分で作成したAQエンキュー・ユーティリティを使用する場合、使用するAQヘッダーはACTION_NAME
です。eventName
は、B2Bのb2b.jar
で提供されるエンキュー・ユーティリティを使用する場合に使用します。
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で/b2b/sequenceReceiver
というURIが公開されます。このエンドポイントに到着したリクエストは順番に処理されます。複数の順序付けターゲットを使用する場合は、リクエストにHTTPヘッダーSEQUENCE_TARGET
を追加します。
SEQUENCE_TARGET
をヘッダーとしてアウトバウンドHTTPメッセージに追加するには、デリバリ・チャネルの「追加トランスポート・ヘッダー」パラメータを使用します。詳細は、表5-3を参照してください。
受信メッセージのHTTPヘッダーに、ヘッダーとしてSEQUENCE_TARGET
が含まれている場合、この値が順序付けのターゲットして使用されます。SEQUENCE_TARGET
がなく、FROM
というHTTPヘッダーが含まれている場合、これが順序付けのターゲットとして使用されます。FROM
がない場合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
同期フローをテストします。
注意: アウトバウンド・アグリーメントを応答側にデプロイするために、1つのダミー・アウトバウンド・チャネルが必要です。ただし、このダミー・チャネルはOracle B2Bでは使用されず、同期レスポンスは、インバウンド・リクエストが受信されたときと同じ接続で返されます。 |
注意: タイムアウトは、HTTPデリバリ・チャネルの追加トランスポート・ヘッダーとして構成できます。例: |
同期フローのイニシエータは、次の問題に注意する必要があります。
同期フローのイニシエータは、汎用HTTP、AS2またはebmsチャネルの追加トランスポート・ヘッダーの一部としてsyncresponse=true
を追加する必要があります。
同期フローのイニシエータは、AS2またはebmsチャネルでack mode none/Async
を設定する必要があります。
JMSヘッダーにA2A=true
を設定すると、インバウンドとアウトバウンドのメッセージをJMSキューを使用して相互に関連付けすることができます。
バックエンド・アプリケーションからメッセージID (MSG_ID
)が提供される場合、B2B出力のJMS相関IDにそのMSG_ID
が設定されます。提供されない場合は、B2B出力のJMS相関IDにJMSメッセージIDが設定されます。
B2Bのクリティカルな状況では、メッセージが失敗しないで送信先に配信され、遅れずに交換レベル確認応答または機能確認応答を受信することが重要です。
Oracle B2Bでは、チャネル・レベルとドキュメント・レベルでメッセージの配信を再試行できます。
チャネルの再試行はデリバリ・チャネルと関連付けられており、配信を確実に成功させるために使用されます。「再試行数」パラメータと「再試行間隔」パラメータで、再試行の回数と各再試行の間の間隔を構成できます。Oracle B2Bは、設定されている再試行回数に達するまでメッセージの正常な配信を再試行した後、エラーを書き込みます。チャネル再試行パラメータの詳細は、表5-4を参照してください。
確認応答のある交換プロトコル(AS2でのMDNや、ebMSでの確認など)の場合、チャネル再試行を使用してビジネス・メッセージが再試行され、メッセージは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項 カスタム取引パートナ・パラメータ・タイプの作成を参照してください。
この機能を使用すると、署名付きインバウンド・メッセージの処理で証明書検証が実行されます。
インバウンド・メッセージ処理で証明書を検証するには次の構成が必要になります。
CertificateAliasという名前の新しい識別子を追加します。
必要なエイリアスを取引パートナ・プロファイルにCertificateAliasという名前で設定します。
Enterprise Managerコンソールでb2b.validateMessageCertificate
プロパティをtrue
に設定し、この機能を有効にします。このプロパティを有効にすると、すべてのメッセージで証明書に対する検証が実行されます。