アウトバウンド・メッセージ処理

アウトバウンドB2Bメッセージの処理に関連する高レベルのステップは、次のとおりです。

ステップ	説明
1	バックエンド・アプリケーションには、外部取引先にビジネス・トランザクションを送信する必要があります。通知メッセージを送信することで、アウトバウンド・バックエンド統合をトリガーします。
2	バックエンド統合インスタンスは、アプリケーション・メッセージを含む通知をバックエンド・アプリケーション・メッセージ形式で受け取ります。
3	マッパーを使用すると、バックエンド・アプリケーション・メッセージはB2B正規XML形式に変換されます。
4	標準XMLメッセージは、アウトバウンド翻訳(前述のEDI-Generateという名前のアクション)のB2Bアクションに対して提供されます。取引先は、B2Bアクションへの入力として指定されます。 B2Bアクションは、正規XMLメッセージをネイティブEDI形式(X12またはEDIFACT)に変換し、Oracle Integration永続ストアに永続化します。一意のIDが割り当てられます。
5	ターゲット取引先、現在の文書タイプおよび取引先に定義されたアウトバウンド契約に基づいて、メッセージ送信のための適切なB2B統合がトリガーされます。メッセージIDが渡されます。
6	メッセージ・インスタンスを送信するためのB2B統合が起動し、REST Adapterトリガー・エンドポイントでメッセージIDを受信します。
7	メッセージ・インスタンスを送信するためのB2B統合では、アダプタ(AS2またはFTP)を使用してメッセージをパックし、AS2またはFTPプロトコルを介して外部取引先に送信します。

アウトバウンド・バックエンド統合の設計

アウトバウンド・バックエンド統合は、バックエンド・アプリケーションによってトリガーされます。外部取引先にメッセージを送信する場合、この統合では、メッセージの宛先である取引先を正確に把握する必要があります。これは、2つの方法のいずれかでバックエンド・アプリケーションによって直接または間接的に指定されます:

取引先識別子が指定されています。これは、B2Bで新しい取引先を作成したときに入力した識別子と同じで、「基本情報」ページに表示されます。
or
アプリケーション・パートナIDが指定されています。これは、取引先に追加できるB2B識別子です。

アプリケーション・パートナIDの背後にある考えは、次のとおりです: バックエンド・アプリケーションとB2Bシステムの両方が、取引先の概念をモデル化します。バックエンド・アプリケーションでは、このようなビジネス・エンティティをサプライヤ、ベンダー、購入者などの特定のロールで処理できます。ビジネス・エンティティには、バックエンド・アプリケーションで一意のIDが割り当てられます。ただし、B2Bでは、メッセージ交換の目的でこのエンティティを再度B2B取引先として登録します。サプライヤ、ベンダー、購入はすべて同じものとして扱われます: (B2B取引先)。バックエンド・アプリケーションとB2B間の受渡しポイントで、これらのシステムの1つは、バックエンド・アプリケーション・エンティティIDとB2Bシステムの取引先IDの間にマッピングする必要があります。アプリケーション・パートナIDはこの目的のため、バックエンド・アプリケーション・エンティティIDをB2Bシステムに追加できます。

これを実行するには、アプリケーション・パートナIDをB2B識別子タイプとしてすべての取引先に追加します。値は、バックエンド・アプリケーションで定義された一意の識別です。これらを定義すると、アプリケーション・パートナIDの値に基づいて、B2Bシステムによって取引先の検索方法が認識されます。

ステップ3では、TranslateInputスキーマのアプリケーション・パートナID要素のマップ方法を指定します。

統合を作成し、トリガー接続を構成します。
バックエンド・アプリケーションからの通知の送信方法に応じて、適切なアプリケーション・アダプタまたはテクノロジ・アダプタを使用してトリガー接続を構成します。

この例では、単純なRESTアダプタ・トリガーが使用されています。 Oracle ERP Cloudアダプタ、Oracle NetSuiteアダプタまたは別のアダプタに置き換えます。
アウトバウンド変換操作を含むB2Bアクションを配置します。
1. 統合にB2Bアクションを追加します。 B2Bアクションは、パレットの「アクション」 > 「データ」の下に表示されます。
2. 名前を入力します(この例ではEDI-Generateが追加されます)。「次へ」をクリックします。
3. 方向として「アウトバウンド」を選択し、操作として「変換」を選択します。「次へ」をクリックします
4. 「データ・フォーマットの選択」ページで、処理するこのバックエンド統合のドロップダウン・リストからドキュメント定義を選択します。選択後、「次」をクリックします。
  既存のB2Bドキュメントが選択のためにドロップダウン・リストに表示されます。または、「検索」をクリックして、ドキュメントの標準、バージョンおよびタイプでB2Bドキュメントを選択します。
5. サマリー・ページで、選択内容を確認し、「完了」をクリックします。
  統合は次のようになります。
アプリケーション・メッセージをB2B標準形式に変換するようにマッパーを構成します。
このマッピングは複雑である可能性があります。それを2つの部分に分けて下さい。
- 最初の部分で、要素を「B2B取引先ID」または「アプリケーション・パートナID」にマップします。これらの要素は、送信する取引先を指定するために使用されます。この概念を以前に説明した。この例では、「B2B取引先ID」のみがマップされています。
  また、オプションで「アプリケーション・メッセージID」をマップします。これは、バックエンド・アプリケーションによって割り当てられるメッセージIDです(ある場合)。これがマップされている場合は、アウトバウンド・メッセージの詳細パネルに「モニタリング」 > 「B2Bトラッキング」 > 「ビジネス・メッセージ」の値が表示されます。この値は処理中に使われませんが、保存されて参照専用で表示されます。
- マップの2番目の部分はedi-xml-document用です。これは、マップの右側に表示されるEDIドキュメントのB2B標準XML形式です。左側には、ビジネス・ドキュメントのバックエンド・アプリケーション・スキーマがあります。このスキーマはバックエンド・アプリケーションに非常に固有であるため、バックエンド・アプリケーション・スキーマからB2B正規XMLへのマッピングを一般化できません。
  次の例では、カスタム構造(AcmePurchaseOrder)をedi-xml-documentにマップします。これはEDI X12、850、オーダーの標準書式を表します。
EDI変換を正常に行うためのチェックを追加します。
1. B2B変換(EDI-Generate)アクションの後にスイッチ・アクションを配置します。このアクションは、EDI変換が成功したか失敗したかを検出するための翻訳ステータスのチェックです。
2. 「翻訳に成功しました」というルートを追加して、次の式を構成します:
```
translation-status = "Success" or translation-status = "Warning"
```
翻訳が成功した場合は、取引先に文書を送付する準備をしてください。
1. 「翻訳に成功しました」ルートにローカル統合起動(統合のコール)アクションを追加します。
2. 「統合の選択」ページで、メッセージ送信に使用可能なB2B統合を選択します(このような統合の正確な名前は変化しますが、名前は常に「AS2送信」または「FTP送信」で終了します)。次の例では、選択した統合「外部TP FTP送信(1.0)」は、メッセージを送信するためのB2B統合です。選択は、特定のAPI契約のためにメッセージを送信するためのB2B統合である必要がありますが、この選択はステップcの説明に従ってマッパーから上書きされるため、どの特定の取引先であるかは関係ありません。
3. 「次」を複数回クリックし、「完了」をクリックします。翻訳に成功しましたルートは次のようになります:
4. ローカル統合の起動前に、次のようにマッパーを構成します(つまり、Send-To-Partnerにマップします):
  - ソースTranslateOutput > 「B2Bメッセージ・リファレンス」をターゲットcomponents.schemas.request-wrapper > messages > b2b-message-referenceにマップします。
  - ソースTranslateOutput > 「取引先名」をターゲットcomponents.schemas.request-wrapper > trading-partnerにマップします。
  - ソースTranslateOutput > connectivity-properties-codeをターゲットConnectivityProperties > LocalIntegration > codeにマップします。
  - ソースTranslateOutput > connectivity-properties-versionをターゲットConnectivityProperties > LocalIntegration > versionにマップします。
  ConnectivityProperties > LocalIntegration > codeおよびversionのマッピングは、ステップ5(b)での統合の選択をオーバーライドします。
  ルーティングの動作は次のとおりです:
  - B2Bアクションは、取引先アウトバウンド契約をチェックし、ステップ2(d)で選択したB2Bドキュメントと一致する契約を検索します。
  - アウトバウンド契約にリンクされたトランスポートが見つかりました。
  - トランスポートが判明すると、トランスポートにリンクされたメッセージを送信するためのB2B統合も認識されます。これは、取引先に文書を配信するための統合です。 B2Bアクションは、connectivity-properties-codeおよびconnectivity-properties-versionにその統合識別子およびバージョンを移入します。
  - フィールドが正しくマップされている場合、ローカル統合起動(つまり統合をコール)アクションはマッパー・オーバーライドを受け入れ、ステップ5(b)で選択したものではなく、connectivity-properties-codeおよびconnectivity-properties-versionに指定された統合をコールします。
成功のための復帰アクションとエラーの障害を追加します。
1. 「翻訳に成功しました」ルートに対する正常なレスポンスおよび「それ以外」ルートの障害戻りを返すように、統合のリターン・アクションを追加します。
  このステップは、REST Adapterトリガーで選択された例に固有です。実際の結果は異なる場合があります。バックエンド・アプリケーションによっては、成功または失敗した変換の結果をバックエンド・アプリケーションに戻すメカニズムがある場合とない場合があります。
  
  完了したアウトバウンド統合は次のようになります。
統合トラッキングのB2Bビジネス識別子を追加します。
1. インテグレーション・トラッキングを行うために、入力スキーマからフィールドを選択します。これは、主にバックエンド・アプリケーション・スキーマに固有です。この例の統合のトラッキング構成は次のとおりですが、統合の外観は異なります。
2. バックエンド統合を保存してアクティブ化します。