取引先モードの概念
この項では、B2B for Oracle Integrationの取引先モードの概念について説明します。
ホスト会社
B2B for Oracle Integrationには、ドキュメント交換に関連するパーティが2つあります: 会社(ホスト会社)および外部取引先。
Oracle Integrationで、左側のナビゲーション・メニューからB2B > 「ホスト・プロファイル」を選択すると、会社のかわりに完了する必要がある構成ページが表示されます。
B2B識別子は、ホスト・プロファイルにのみ入力する必要があります。 EDI交換アイデンティティやAS2識別子などの会社アイデンティティ情報を入力します。 企業の証明書の署名など、その他の構成タイプは後で入力します。
外部取引パートナに電子ドキュメントを送信すると、ホスト・プロファイルに入力するB2B識別子の一部がメッセージに挿入されます。 これにより、受信者担当者は、メッセージの送信者として会社を識別できます。
「ホスト・プロファイルの定義」を参照してください。
取引パートナ
取引先は、企業が対話して、オーダーや請求書などのビジネス文書を電子フォームで送受信する外部ビジネス・エンティティです。
左側のナビゲーション・メニューからB2B > 「取引パートナ」を選択してページにアクセスし、外部のすべての取引先を登録し、かわりに情報を入力します。 取引先は、Oracle Integrationインスタンスのこれらのページにアクセスできません。 したがって、B2Bシステム管理者として、外部取引先から情報をオフラインで収集し、これらのページに情報を入力します。
Oracle IntegrationのB2Bと同様に、外部取引パートナには独自のB2Bアプリケーションがあります。 取引パートナは、会社に関する情報をオフラインで収集し、直接アクセスできないB2Bアプリケーションに入力します。
設定が完了し、両端でテストされると、2つのパーティ(会社と外部取引先)が文書を送受信する準備が整います。
- 基本情報
- 連絡先
- B2B識別子
- トランスポート&契約
「取引パートナの作成」を参照してください。
B2Bメッセージ処理に使用される統合
B2Bメッセージの実際の処理は統合で行われます。 B2B for Oracle Integrationでは、2つの統合設計パターンを使用してモジュール性を向上させます。
インバウンド・メッセージ
外部取引先から受信したB2Bメッセージは、インバウンド・メッセージと呼ばれます。 次の図は、2つのインテグレーションによるインバウンド・メッセージの処理方法を示しています。
- 取引先からメッセージを受信し、次のような様々な妥当性チェックを実行します:
- メッセージは既知(登録済の)取引パートナから受信されていますか。 認証資格証明、SSL証明書、HTTPヘッダーなどに基づいてこれを確認します。
- メッセージは署名されているか、暗号化されていますか? その場合は、シグネチャを検証してメッセージを復号化します。 このステップはパッケージングと呼ばれ、パッケージングからオブジェクトを削除する場合と同様です。
- 取引先から依頼された場合、取引先にトランスポート・レベル確認通知を返送します。
- ペイロードのタイプを検出します。 翻訳が必要なペイロード(EDIメッセージなど)の場合は、メッセージを解析して変換します。
- トランスレータ・レベルの確認を送信します(構成されている場合)。
- バックエンド統合は、メッセージをバックエンド・アプリケーション(ERPなど)が直接消費できる形式(XML、JSON、CSVなど)に変換し、そのメッセージをバックエンド・システムに転送して処理を続行します。
アウトバウンド・メッセージ
外部取引先に送信されたB2Bメッセージは、アウトバウンド・メッセージと呼ばれます。
次の図は、2つのインテグレーションによるアウトバウンド・メッセージの処理方法を示しています。
- 外部取引先に送信する必要があるビジネス文書のERPなどのバックエンド・アプリケーションからイベントを受け取ります。
- 業界標準のB2B形式(Electronic Data Interchange (EDI)形式など)にメッセージを変換します。
- 必要な構成に従って、ヘッダーの追加、暗号化、署名および圧縮を行います。 このステップはパッケージングと呼ばれ、オブジェクトをエンベロープにラップし、配信準備に似ています。
- 外部取引先エンドポイントにメッセージを転送します。
- 取引先がトランスポート・レベルの確認で応答すると、それに応じて送信済メッセージのステータスが更新されます。
次の表に、B2Bメッセージ処理の2つの統合パターンをまとめます:
| 概念 | メッセージの受信と送信のためのB2B統合 | バックエンド統合 |
|---|---|---|
| 目的 | B2Bレイヤー確認を含む外部取引先との低レベルの技術的対話を処理します。 これはOracleによって提供されます。 | ERPなどのバックエンド・アプリケーションとの完全な対話と、B2B標準形式とバックエンド・アプリケーション形式のメッセージ変換を処理します。 これは会社によって開発され、通常はバックエンド・アプリケーションに固有です。 特定のバックエンド・アプリケーション用にレシピやアクセラレータが用意されている場合があります。
「Oracle Integration Generation 2の開始」の「統合アクセラレータおよびレシピの開始」を参照してください。 |
| 作成 |
これらの統合は、テンプレートから取引先ごとに自動的に作成されます。 統合の自動作成方法に関する詳細が提供されます。 「受入および送信用のB2B統合の作成」を参照してください。 |
この統合を手動で作成し、使用可能なアプリケーション・アダプタを使用してバックエンド・アプリケーションとインタフェースします。 このインテグレーションの作成方法に関する詳細が提供されます。 「バックエンド統合の作成」を参照してください。 |
| また、その処理の内容について説明します |
インバウンド・メッセージの場合、メッセージを受信するためのB2B統合によってもメッセージ(EDIからXMLなど)が変換されます。 インバウンド・メッセージにバッチ化されたトランザクションが含まれている場合、それらのトランザクションは、バックエンド統合に渡す前に個別に分割されます。 ただし、アウトバウンド・メッセージの場合、メッセージ送信のためにB2B統合で翻訳は実行されません。 (バックエンド統合で実行されます。) |
インバウンド側とアウトバウンド側の両方について、ERPなどのバックエンド・アプリケーションとのインタフェースを処理します。 インバウンド・メッセージの場合、バックエンド統合は、すでに正規フォーマットに変換されているB2Bメッセージを取得します。 それをさらに変換してバックエンド・アプリケーションに転送する必要があります。 アウトバウンド・メッセージの場合、バックエンド統合は、バックエンド・アプリケーションからのイベント通知によってこの統合がトリガーされ、B2B形式(XMLからEDIなど)への変換が実行され、メッセージ送信のためにB2B統合がコールされるエントリ・ポイントです。 |
| 統合はいくつ必要ですか? |
B2B取引パートナおよびトランスポートごとに1組の統合が必要です。 たとえば、10のB2B取引先があり、それぞれ1つのトランスポートを持つ場合、20の統合が必要です(メッセージの受信と送信に1つずつ)。 これらの統合は自動的に作成されます。 「取引先モードの概念」を参照してください。 |
1組の統合は、ビジネス文書タイプごとに必要です。 たとえば、3つのタイプのビジネス文書(オーダーと請求書、出荷通知)がある場合、取引先の数に関係なく、6つの統合(インバウンド側に3つ、アウトバウンド側に3つ)が必要です。 通常、これらの統合は、同じ文書形式を使用しているかぎり、多数の取引先間で共有します。 一部のタイプのビジネス文書が1方向でのみ使用される場合、実際には6つ以下の統合が必要になることがあります。 たとえば、オーダーの受信のみであるが、送信されない場合、インバウンド・オーダーにはバックエンド統合が1つのみ必要で、アウトバウンド・オーダーには必要ありません。 また、複数のドキュメント・タイプを処理するためにインテグレーションを設計する場合も、必要な統合が少なくて済みます。 これは、最も単純なケースでは、1つのバックエンド統合が1つのタイプのビジネス文書のみを処理することを前提としています。 これらの統合を手動で作成する必要があります。 「バックエンド統合の作成」を参照してください。 |
統合間のメッセージ・ルーティング
B2B統合とバックエンド統合は互いにハード・ワイヤリングされません。 かわりに、宣言的に追加するルーティング・ルールに従って動的に結合されます。 この項では、インバウンド契約とアウトバウンド契約の概念を使用してルーティング・ルールがどのように機能するかを説明します。
インバウンド
取引パートナの1人が複数のタイプの文書を送信しているとします: オーダーと請求書。 この取引先の場合、1つのB2B統合がメッセージを受信し、両方のタイプの文書を受け取ります。 ルーティング・ルールを定義するには、この取引先に2つのインバウンド契約を追加します。 インバウンド契約を追加する場合は、1つのB2Bドキュメントと1つのバックエンド統合を選択する必要があります。
- オーダー・タイプ文書の選択およびXと呼ばれるバックエンド統合のためのインバウンド契約1。
- 請求書タイプ文書およびYと呼ばれるバックエンド統合を選択するためのインバウンド契約2です。
- この取引先からオーダー・タイプ文書を受信すると、バックエンド統合Xにルーティングされます。
- 請求書タイプ文書がこの取引先から受信されると、バックエンド統合Yにルーティングされます。
インバウンド契約はルーティングよりも多いですが、ルーティングはプライマリ概念です。 メッセージを受信するためのB2B統合は、実行時にルーティング・ルールを優先し、次に示すように、識別されたドキュメント・タイプに応じてバックエンド統合XまたはYを動的に起動します。
ノート:
十分な共通性がありメンテナンスが容易であると考えた場合、複数タイプのドキュメントを処理する単一の汎用バックエンド統合を作成できます。 この場合、2つのインバウンド契約で同じバックエンド統合を選択します。アウトバウンド
2つの取引先があり、これらの取引先のいずれかに購買オーダー文書をルーティングするとします。 この場合、バックエンド統合は、2つの統合間でメッセージを送信するための正しいB2B統合を選択するためのルーティング選択を行う必要があります。
アウトバウンドの場合、バックエンド統合内で、メッセージを配信する取引先を指定する必要があります。 これは、取引先IDまたはアプリケーション・パートナIDを指定することで指定されます。 「アウトバウンド・バックエンド統合の設計」を参照してください。
ルーティング・ルールを定義するには、2つのアウトバウンド契約(取引先ごとに1つ)を追加します。 アウトバウンド契約を追加する場合は、1つのB2B文書と1つのトランスポートを選択する必要があります。 「通信のトランスポート」を参照してください。 特定の取引先に対してメッセージを受信および送信するために、トランスポートがB2B統合にマップされることに注意してください。
- 購買オーダー・タイプ文書を選択するためのアウトバウンド契約1、取引先XのトランスポートX。
- 取引先Yの購買オーダー・タイプ文書およびトランスポートYを選択するためのアウトバウンド契約2。
これらの2つの契約は、購買オーダー・タイプ文書が取引先Xに送信されると、それをメッセージXを送信するためにB2B統合にルーティングするというシステムのインテントを表しています。 文書が取引先Yに送信されると、メッセージYを送信するためにB2B統合にルーティングします。
アウトバウンド契約はルーティングよりも多く実行されますが、このセクションはルーティングの側面にのみ焦点を当てます。
契約に関するその他の概念が提供されます。 「アグリーメント」を参照してください。
契約を作成するための詳細が提供されます。 「基本契約の作成」を参照してください。
ノート:
アウトバウンド・ケースでも、設計プリファレンスである場合、複数のタイプのドキュメントを処理する共通のバックエンド統合を作成できます。通信のトランスポート
トランスポートとは、AS2やFTPなどの特定のプロトコルを使用して取引先への具体的な通信チャネルを表す構成オブジェクトです。 取引先に1つ以上のトランスポートを追加して、パートナからビジネス文書を送受信します。
AS2およびFTP (SFTPを含む)は、B2B取引先モードで現在サポートされているプロトコルです。 B2B for Oracle Integrationで別のプロトコル・アダプタを使用する場合は、スタンドアロン・モードのみを使用できます。
B2B取引パートナのトランスポートは、B2B > 「取引パートナ」 > 「トランスポート&契約」タブから定義します。 次の例は、1つのAS2トランスポートと1つのFTPトランスポートを持つ取引先を示しています。
- 外部取引先エンドポイントを指すように作成および構成する接続。 この構成の一部として、取引先が提供するホスト名、ポート、URL、ユーザー名/パスワード資格証明およびその他の詳細を指定します。
- 追加の構成(FTPのディレクトリ・パスやAS2の暗号化アルゴリズムなど)。
- メッセージを受信するための統合と、メッセージを送信するための統合のペアです。 これらの統合は自動的に作成されます。 「B2B処理に使用される統合」を参照してください。
トランスポートを定義する場合は、次の構成詳細を入力します(この例ではAS2)。
「
図transport_ui.pngの説明」
- トランスポートの作成: トランスポートの定義を追加します。 B2B統合のペアが自動的に作成され、このトランスポートに永続的にリンクされます。
- トランスポートのデプロイ: トランスポートを実行時処理に表示し、B2B統合もアクティブ化します。 このトランスポートは、メッセージを受信および送信できます。
- トランスポートの再デプロイ: メッセージ処理を中断することなく、ランタイムのオンザフライに構成変更を適用します(制限あり)。
- トランスポートのアンデプロイ: ランタイム処理からトランスポートを非表示にし、B2B統合も非アクティブ化します。 このトランスポートは、メッセージを受信および送信できなくなります。
- トランスポートの削除: 定義を削除し、B2B統合も削除します。
「トランスポートの定義」を参照してください。
AS2
適用文2 (AS2)は、B2B用に設計されたHTTPベースのプロトコルで、データの機密性、データの整合性/認証および非改定に関する包括的なデータ・セキュリティ機能セットを追加します。
AS2指定については、RFC 4130を参照してください。 B2B for Oracle Integrationは、AS2バージョン1.0および1.1をサポートしています。
AS2トランスポートは、AS2接続および証明書管理ユーザー・インタフェースと連携して動作するAS2固有の構成オプションを提供します。
- 「設定」 > 「証明書」の証明書をアップロードして、Oracle Integration証明書管理機能を使用します。
- AS2トランスポートで選択したAS2アダプタ接続に署名証明書および暗号化証明書の別名を入力します。
- AS2トランスポート構成で暗号化および署名アルゴリズムを選択します。
最も単純なAS2通信では、暗号化、署名および圧縮は使用されません。 AS2について学習している場合は、簡単を起動し、後でセキュリティ・レイヤーを追加できます。
電子読取り入金の概念は、正式にメッセージ処理通知(MDN)と呼ばれるAS2にあります。 これは、他のパーティが自分のメッセージをそのまま受信したことを確認するために使用されるトランスポート・レベルの確認です。 B2B for Oracle Integrationは、MDNメッセージ(有効な場合)を生成および消費し、元の送信に関連付けます。 「B2Bメッセージの追跡」ページでは、後で説明するAS2メッセージおよびMDN確認を表示できます。
AS2トランスポートの詳細は次のとおりです。 「トランスポートの定義」を参照してください。
FTP
通常、ファイル転送プロトコル(FTP)およびセキュア・ファイル転送プロトコル(SFTP)はB2B通信に使用されます。 FTPトランスポートもFTPアダプタ接続と連動します。
FTPアダプタ接続では、ホスト名、ポート、資格証明およびその他のセキュリティ構成を指定します。 FTPトランスポートでは、入力および出力ディレクトリ、ファイル名パターンおよびその他の詳細を入力します。
FTPトランスポートの重要な側面の1つは、受信側が時間ベースのスケジュールで入力ディレクトリをポーリングすることです。 スケジュールを設定するには、FTPトランスポートのアクション・メニューの「スケジュールを受領」オプションを選択します。
FTPトランスポートの詳細が記載されています。 「トランスポートの定義」を参照してください。
基本契約
特定のタイプのビジネス文書のみをその取引先との間で送受信するインテントで、B2B取引先に対して1つ以上の契約を定義します。 合意は、会社と外部取引相手が特定のビジネス文書交換の条件に正式に同意することを意味します。
- B2Bは、特定の取引先から予想される文書に関する知識に基づいており、同意したドキュメントのいずれかのみを受け入れます。 予期しない文書タイプは、その取引先からの受入中または取引先への送信中に拒否されます。
- 交換される文書のデータ書式を定義します。 たとえば、EDIドキュメントの場合、構文の検証および解析は、契約で選択したB2Bドキュメントに基づいて実行されます。 会社と外部取引先の両方とも、相互運用性を活かすために使用するデータ形式を事前に決定する必要があります。 パーティの1つは、通常、データ・フォーマット定義を含む実装ガイドを共有し、他のパーティがそれに付随して同等のデータ・フォーマット定義を作成します。
- メッセージ処理の動作を定義します。 たとえば、データ形式の構文検証は、他の設定の中でも、合意でオンまたはオフにできます。
- 文書のルーティングのルールを定義します。 たとえば、ドキュメントを受信する場合、インバウンド契約は、ドキュメントのタイプに基づいてドキュメントのルーティング先となるバックエンド統合を定義します。 文書の送信中に、アウトバウンド契約では、特定の文書に連携を送信して取引先に配信するB2Bを定義します。
- 基本契約の作成: 設計時のみの定義を追加します(ただし、デプロイしないかぎり、新しい契約は実行時に強制されません)。
- 契約のデプロイおよび再デプロイ: 契約を実行時処理に表示し、即時に強制します。
- 契約のアンデプロイ: 実行時に処理から契約が非表示になり、すぐに開始して無効になります。
- 契約の削除: 設計時から除去します。
- インバウンド契約:
- アウトバウンド契約:
「基本契約の作成」を参照してください。
B2Bドキュメントおよびスキーマ
B2Bドキュメントは、データ形式とデータ形式に関する追加構成を指定する契約に必要な必須オブジェクトです。 データ形式は、次のプロパティを使用して指定します。
- 文書標準: X12およびEDIFACT EDI標準は現在サポートされています。
- 文書バージョン: 標準本文で定義されたバージョン。
- ドキュメント・タイプ: 標準本文で定義されているタイプです。
- ドキュメント・スキーマ: B2Bスキーマ・オブジェクトで定義されている標準またはカスタマイズされたバリアント。 標準とは、標準本文によって公開されたデータ・ディクショナリに定義されている初期スキーマです。
追加の構成により、B2Bランタイムの1つ以上のビジネス識別子を抽出して「B2Bメッセージのトラッキング」ページに表示できます。 このページは、左側のナビゲーション・ペインで「モニタリング」 > 「B2Bトラッキング」 > 「ビジネス・メッセージ」からアクセスできます。
B2Bスキーマは、いずれかの標準スキーマのカスタマイズされたバリアントを表すオプションのオブジェクトです。
B2BドキュメントおよびB2Bスキーマに関する詳細が提供されます。 「B2Bドキュメントおよびスキーマ」を参照してください。
契約に関する追加詳細が提供されます。 「基本契約の作成」を参照してください。
メッセージ永続性およびトラッキング
メッセージは、メッセージを受信および送信するためにB2B統合を経由するため、通常の統合インスタンス・トラッキングに加えて、各インバウンドおよびアウトバウンド・メッセージは別々に保持されます。
永続的なB2Bメッセージは、左側のナビゲーション・メニューからアクセスできる特殊な「B2Bメッセージのトラッキング」ページから「モニタリング」 > 「B2Bトラッキング」から表示できます。
ビジネス・メッセージ
このビューでは、B2Bメッセージが個々のビジネス・トランザクションとして表示されます。 
とマークされた行は機能確認を示します。 バッチ処理済トランザクションを含むインバウンド・メッセージを受信するとします。 このビューには、そのバッチ内の各トランザクションの個別の行が表示されます。
ワイヤ・メッセージ
ワイヤー・メッセージには、B2Bメッセージの代替の低レベルの技術ビューが用意されています。 このビューでは、取引先との間で送受信されるメッセージの形式で表示されます。 このビューは、メッセージが取引先に配信できなかった場合や、受信したメッセージのシグネチャ検証に失敗した場合のトラブルシューティングに役立ちます。 
でマークされた行は、AS2 MDN(電子返却入金)を示します。
バッチ処理済トランザクションを含むインバウンド・メッセージを受信した場合、受信した実際のバッチ・メッセージに対応する1行のみが表示されます。
B2Bトラッキングの詳細がさらに提供されます。 「B2Bトラッキング」を参照してください。