| Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド 11g リリース1（11.1.1） B61381-01 |
|
 戻る |
 次へ |
図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は、各取引パートナにデフォルトの識別子タイプである名前を提供しています。値は取引パートナの名前です。
ホスト取引パートナとリモート取引パートナの両方の識別子タイプと値を追加します。 ここで追加するタイプの作成方法は、第9章「タイプの作成」を参照してください。
「パートナ」リンクをクリックします。
「プロファイル」タブをクリックします。
取引パートナを選択します。
図5-7に示すように、「識別子」領域で「追加」をクリックします。
「タイプ」リストから、識別子タイプを選択します。
識別子タイプの詳細は、表9-1「Oracle B2Bに定義されている識別子タイプ」を参照してください。
値を入力します。
「保存」をクリックします。
（オプション）取引パートナのコンタクト情報を追加する場合は、あらかじめシードされているタイプ（コンタクト名、電子メール、FAX、電話）を使用します。 「管理」 > 「タイプ」ページでコンタクト・タイプを作成することもできます。 詳細は、第9.2項「カスタム・コンタクト情報タイプの作成」を参照してください。
「パートナ」リンクをクリックします。
「プロファイル」タブをクリックします。
「コンタクト情報」領域で「追加」をクリックします。
図5-8に示すように、「タイプ」の下のリストから選択して値を入力します。
「保存」をクリックします。
（オプション）取引パートナ・パラメータと取引パートナの値を追加する場合は、事前に「管理」 > 「タイプ」ページで、パラメータを作成する必要があります （パラメータを作成していない場合、「追加」アイコンは表示されません）。 詳細は、第9章「タイプの作成」を参照してください。
「パートナ」リンクをクリックします。
「プロファイル」タブをクリックします。
図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管理コンソール: 「セキュリティ・レルム」
myrealm設定の「ユーザーとグループ」タブに、そのレルム内のすべてのユーザーを含むテーブルが表示されます。 「新規」をクリックし、図5-13に示すページでユーザーおよびユーザー・パスワードを追加します。
図5-13 Oracle WebLogic Server管理コンソール: 新しいユーザーの追加
デフォルトの管理者はユーザーを追加できます。 ホスト管理者およびリモート管理者は、デフォルトの管理者によって権限が付与されている場合は、ユーザー（各自のデータのみに対するリモート管理者）を追加できます。
デフォルトの管理者は、ユーザーにドキュメント・タイプを追加できます。 ホスト管理者およびリモート管理者は、デフォルトの管理者によって権限が付与されている場合は、ユーザー（各自のデータのみに対するリモート管理者）に対してドキュメント・タイプを追加できます。 ドキュメント・タイプをここで追加しなかった場合、ユーザーはすべてのドキュメント・タイプにアクセスできるようになります。
Oracle B2Bのホスト管理者は、すべてのドキュメント定義を作成します。作成したドキュメント定義はホスト取引パートナに自動的に割り当てられます。 ホスト管理者は、ドキュメント定義をリモート取引パートナに割り当てることができます。 ホスト取引パートナとリモート取引パートナの両方について、各ドキュメントの送信者と受信者を識別する必要があります。
ドキュメント定義を追加した後でその定義を更新する方法は、第7.9項「ドキュメントの詳細の変更」を参照してください。
|
注意: ホスト取引パートナに自動的に関連付けられているドキュメント定義を（「管理」 > 「ドキュメント」で）削除する場合は、その前に、ホスト取引パートナ・プロファイル（およびリモート取引パートナ・プロファイル）からその定義を削除する必要があります。 |
Acme（購入者）がGlobalChipsに発注を送信するシナリオを考えてみます。 Acmeでは、このトランザクションの一環としてGlobalChips（販売者）が発注を受信したことを示す確認を受信します。 したがって、このEDIFACTトランザクションでは、2つのドキュメント定義（発注のドキュメント定義と機能確認のドキュメント定義）が使用されます。 GlobalChipsは、発注を受信して確認を送信します。
取引パートナ・プロファイルに追加するために必要となるドキュメント定義の作成の詳細は、第4章「ドキュメント定義の作成」を参照してください。
ドキュメント定義を追加する手順は、次のとおりです。
ホスト取引パートナ・プロファイルとリモート取引パートナ・プロファイルの両方に、ドキュメント定義を追加します。 このページでは、リモート取引パートナのドキュメント・タイプ・パラメータやドキュメント・バージョン・パラメータを変更することもできます。 詳細は、第7章「ドキュメント・プロトコルの使用」を参照してください。
「バージョン・パラメータのオーバーライド」および「DocTypeパラメータのオーバーライド」パラメータの使用を含めた、リモート取引パートナに対するドキュメント・プロトコル・バージョンおよびドキュメント・タイプ・パラメータの変更方法は、第7.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接続に使用される静的ポート。 |
Generic FTP（オプション） |
|
データソース |
データベースのデータ・ソースのJNDI名。 |
Generic AQ（オプション） |
|
接続先名 |
JMS接続先名。 |
Generic JMS（オプション） |
|
接続先プロバイダ |
リモート・サーバーで使用可能なJMSキューまたはJMSトピックに、B2Bを接続できるようにします。 ターゲット・サーバーへの接続に必要なJNDIプロパティには、値が期待されます。 各キー/値のペアには、セパレータとして |
Generic JMS-1.0（オプション） |
|
電子メールID |
接続先電子メール。 |
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（オプション） |
|
エンコーディング |
ファイル転送に使用するエンコーディング。 |
Generic FTP（オプション） |
|
ファイル名フォーマット |
次のファイル名フォーマットを使用できます。 %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（オプション） |
|
フォルダ |
絶対ディレクトリ・パスを使用してください。 |
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（オプション） |
|
順序 |
受信HL7メッセージをバックエンド・アプリケーションに順番に配信する必要がある場合は、このプロパティを有効にします。 |
MLLP-1.0（オプション、リモート取引パートナのみ） |
|
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基本認証に使用されます。 |
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 FTP（オプション） AS2（オプション） ebMS-2.0（オプション） ebMS-1.0（オプション） Generic HTTP（オプション） RosettaNet-V02.00（オプション） RosettaNet-01.10（オプション） Generic SFTP（オプション） |
「保存」をクリックします。
タスク1で選択したチャネルとトランスポート・プロトコルに応じて、表5-4に記載されているように、チャネル属性を指定します。
表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バージョン11.1.1.3.0では使用されません。 |
- |
|
再試行数 |
Oracle 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（オプション） |
|
再試行間隔 |
B2Bがメッセージの再送信を試行する間隔（分単位）。 メッセージのステータスが「完了」でない場合、B2Bはメッセージの再送信を試みます。 再試行間隔を2分に設定した場合、最初の再試行は120秒（2分）間隔でない可能性があります。 これは、最初の再試行ではメッセージ送信時間の秒が考慮されないためです。 たとえば、送信タイムスタンプが3:42:58（3時42分58秒）の場合は、42分に2分が加算されて3:44:00に最初の再試行が実行されます。その後の再試行（必要な場合）は、3:46:00、3:48:00のように2分間隔になります。 確認を含むプロトコルの場合、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（オプション） |
|
トランスポート・コールアウト |
インバウンド・メッセージの場合、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に、交換プロトコル・パラメータ（アルファベット順にリスト）とそのパラメータが適用されるプロトコルを示します。
表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に記載されているように、セキュリティ・パラメータを指定します。
表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プロパティの一部として使用できるようになります。 詳細は、例12-1「CUSTOM_HEADERプロパティの設定と取得」を参照してください。
マルチスレッド・システムでは、最初に生成されたメッセージが最初に送信先に届くとはかぎらないため、メッセージを順番に交換することは難題です。 このビジネス要件がある企業のために、B2Bにはシーケンサとディスパッチャが用意されています。 シーケンサは、着信時刻に基づいてメッセージを順序付けします。 ディスパッチャは、順序付けされたメッセージをディスパッチします。 メッセージの順序付けは、アウトバウンド方向とインバウンド方向の両方に使用できます。
AQデリバリ・チャネルの場合にアウトバウンド・メッセージの順序付けを可能にするには、jca.aq.HeaderDocumentの割当て時にACTION_NAMEをTARGET:sequence_target_nameに設定することで、メッセージをエンキューします。 一方、b2b.jarに付属のENQUEUEユーティリティを使用している場合は、eventName（ACTION_NAMEではなく）をTARGET:sequence_target_nameに設定します（例: eventName=TARGET:sequence1）。 デフォルトのチャネルを使用している場合に順序付けを可能にするには、b2b.sequencingTarget = sequence_target_nameを使用します。
順序付けされたメッセージをディスパッチするには、図5-22に示すように、「アウトバウンド・ディスパッチャ数」パラメータを構成します。
デフォルトの値は0で、ディスパッチ（スタック）なしで順序付けする設定です。 メッセージ・ロードに応じて、「アウトバウンド・ディスパッチャ数」を適切な値に設定します。
インバウンド・メッセージの順序付けを可能にするには、図5-23に示すように、MLLPデリバリ・チャネルの「順序」フラグを選択します。
順序付けされたメッセージをディスパッチするには、図5-22に示すように、「インバウンド・ディスパッチャ数」パラメータを構成します。
通常、取引パートナ停止時間は、バックエンド・アプリケーションでのメッセージのスタックによって処理されます。この場合は、停止時間終了後にB2Bでメッセージ全体を処理する必要があります。 そのため、停止時間中はB2Bアプリケーションが十分に活用されない状態になり、取引パートナからメッセージが配信された際には過負荷状態になります。 メッセージ処理が急増するため、通常のメッセージ・フローにも影響を与えます。
取引パートナの配信失敗時は、対応するメッセージがディスパッチャによって取得されないようにマークされ、バックエンド・アプリケーションではなくB2Bにメッセージがスタックされることになります。 メッセージを処理するには、次のプロパティを設定します。
自動スタック・ハンドラ = true
自動スタック・ハンドラ間隔 = 間隔（秒単位）
「自動スタック・ハンドラ」および「自動スタック・ハンドラ間隔」パラメータは、図5-22に表示されています。 trueに設定すると、スタックされたメッセージは、ディスパッチャによって適切な間隔で配信できるようになります。 「自動スタック・ハンドラ間隔」には、変化する間隔をカンマ区切りの値で指定することもできます。
同期サポートはコールアウトを使用して提供されます。 同期サポートには、受信リクエストに同期方式で応答するプラットフォームが用意されています。
企業には、ビジネス・レスポンスを同期して送信する複数の要件が存在する可能性があります。 たとえば、受信ドキュメント270には、同期するドキュメント・レスポンス271が期待される場合があります。 企業では、HTTPプロトコル経由で選択した単純なカスタム・ドキュメントの同期サポートを設定する必要があります。
コールアウトは、同期レスポンスを可能にする重要なコンポーネントです。 このモデルでは、コールアウトは、受信リクエスト・メッセージをバックエンド・アプリケーションに配信し、バックエンド・アプリケーションから対応するビジネス・レスポンスを取得する役割を果たします。 バックエンド・アプリケーションの機能は企業によって異なる可能性があります。したがって、コールアウト実装者は、バックエンド・アプリケーションとの間でメッセージを送受信するために独自のアプローチを選択できます。
B2Bエンジンは、構成済のコールアウトへの入力としてインバウンド・メッセージを用意し、バックエンド・アプリケーションから受信したレスポンスを出力として提供するために、コールアウトを必要とします。 コールアウトの出力は、B2Bでアウトバウンド・メッセージとして処理され、同じ出力が同じHTTP接続のインバウンド・メッセージに対するレスポンスとして戻されます。
同期レスポンスを構成する手順は、次のとおりです。
インバウンドおよびアウトバウンド・アグリーメントを設定します。
インバウンド・リクエストを送信してバックエンド・アプリケーションからビジネス・レスポンスを受信する機能を備えたコールアウトを作成します。
コード・サンプルは、例12-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を設定する必要があります。
図5-24に示すように、「パートナ」領域では、「アグリーメントの自動作成」アイコンを使用して、リモート取引パートナのアグリーメントを作成できます。
この機能では、選択したリモート取引パートナに関連付けられているドキュメント定義ごとに1つのアグリーメントが作成されます。 アグリーメントは、「アグリーメント」タブを使用してさらにカスタマイズできます。 「アグリーメント」タブの詳細は、第6章「取引パートナ・アグリーメントの作成およびデプロイ」を参照してください。
設計時データに使用可能な識別子は、取引パートナを参照するために使用します。 識別子は、デプロイされているアクティブなアグリーメントの一部である必要はありません。 参照には、適切なドキュメント識別子と交換識別子を使用します。次に例を示します。
AS2-1.1交換プロトコルには、AS2識別子を使用します。
EDI X12ドキュメント・プロトコルには、送信者グループIDと送信者交換IDを使用します。
