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

ステップ	説明
1	送信されたメッセージ、または取引先からFTPのロケーションにドロップされたファイルがアダプタ・エンドポイント(AS2またはFTP)に到着します。メッセージを受信して解凍します。
2	メッセージはEDIから正規XML形式に変換され、Oracle Integration永続ストアに保持されます。一意のIDが割り当てられます。
3	現在のメッセージ・タイプおよび取引先に定義されているインバウンド契約に基づいて、適切なインバウンド・バックエンド統合がトリガーされます。メッセージIDが渡されます。
4	バックエンド統合インスタンスが起動し、RESTトリガー・エンドポイントでメッセージIDを受け取ります。
5	バックエンド統合(メッセージIDを指定)は、Oracle Integration永続ストアから翻訳済の正規XMLメッセージを取得します。 B2Bフェッチ・メッセージ操作を使用して取得します。
6	標準XMLは、さらにバックエンド・アプリケーション・メッセージに変換されます。
7	アプリケーション・アダプタを使用すると、バックエンド・アプリケーション・メッセージがバックエンド・アプリケーションに送信されます。
8	バックエンド・アプリケーションが、取引先から送信されたビジネス・トランザクションを使用できるようになりました。以降の処理が実行されます。

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

インバウンド・バックエンド統合は、ローカル統合起動(統合のコール)アクションを使用してメッセージを受信するために、B2B統合によって自動的にトリガーされます。正しくトリガーするには、バックエンド統合は次の必要なAPI契約に準拠している必要があります:

統合には、OAuth 2.0用に構成されたRESTアダプタ・トリガーが必要です。
RESTアダプタ・トリガーは、リソースURI (ルート・リソースURI)として/を使用する必要があります。
REST Adapterトリガーは、ステップ1(e)に示されている特定のリクエスト・ペイロード・スキーマを使用する必要があります。
RESTアダプタ・トリガーはレスポンスを返すことはできません。非同期である必要があります。これにより、バックエンド統合の処理に時間がかかる場合でも、メッセージを受信するB2B統合が迅速にブロック解除され、処理を続行できます。

このバックエンド統合には、繰返しのb2b-message-reference要素の形式でメッセージIDのコレクションが与えられます。取引先がバッチ・メッセージを送信する場合は、コレクションが必要です(つまり、1つのメッセージまたはファイルに複数のビジネス文書がある場合があります)。メッセージを受信するためのB2B統合は、メッセージを複数のドキュメントに自動的に分割し、各ドキュメントに対して1つのb2b-message-reference要素を返します。バックエンド統合に一度に200レコードの最大チャンクが提供されます。インバウンド・メッセージのドキュメント数が多い場合、バックエンド統合は200のチャンクで複数回コールできます。

統合を作成し、RESTアダプタ・トリガーを構成します。
1. アプリケーション主導のオーケストレーション統合パターンを選択します。名前は任意にします。この例では、 Backend - Inbound Purchase Ordersが使用されています)。
2. サンプルRESTエンドポイント・インタフェース(またはOAuth 2.0または基本認証セキュリティ・ポリシーを使用する他のRESTアダプタ・トリガー接続)を使用して、RESTアダプタ・トリガーを追加します。
3. トリガー接続の名前としてReceive-B2B-Msg (またはその他の名前)を入力します。
4. 「リソース構成」ページで、リソースURIとして/を入力し、POSTアクションを選択して、「このエンドポイントのリクエスト・ペイロードを構成」チェック・ボックスを選択します。
5. 「リクエスト・パラメータ」ページで、「JSONサンプル」を選択し、次に示すJSONをインライン・サンプルとして貼り付けます。
```
{
  "type": "MSG",
  "id": "12345",
  "direction": "INBOUND",
  "trading-partner": "ACME",
  "document-definition": "PO_850",
  "message": [
    {
      "b2b-message-reference": "biz:0AC400D117503A8246000000347849EB"
    },
    {
      "b2b-message-reference": "biz:0AC400D117503A8246000000347849EA"
    }
  ]
}
```
  ノート:
  前述のJSONサンプルでは、構造が重要です。値はプレースホルダーまたは代表値のみです。
6. 「次」をクリックしてサマリー・ページにアクセスし、選択内容を確認し、「完了」をクリックします。
RESTアダプタ・トリガーの後にfor-eachアクションを配置します。
「繰返し要素」としてrequest-wrapper > messageを選択し、「現在の要素名」値としてCurrent-Msgと入力します。
for-eachアクション内にスコープを追加し、名前を付けます(この例では、Handle-One-Messageという名前)。
スコープ内にメッセージのフェッチ操作で構成されたB2Bアクションを追加します。パレットの「アクション」 > 「データ」の下にB2Bアクションが表示されます。
1. 名前(この例ではFetch-Message)を入力し、「B2B取引パートナ・モード」を選択して、「次」をクリックします。
2. 方向として「インバウンド」を選択し、操作として「メッセージのフェッチ」を選択します。「次へ」をクリックします
3. 「データ・フォーマットの選択」ページで、このバックエンド統合が処理されるドロップダウン・リストからドキュメント定義を選択します。
  既存のB2Bドキュメントが選択のためにドロップダウン・リストに表示されます。または、「検索」をクリックして、ドキュメントの標準、バージョンおよびタイプでB2Bドキュメントを選択します。
4. 選択したら、「次」をクリックします。
5. サマリー・ページで、選択内容を確認し、「完了」をクリックします。
  統合は次のようになります。
6. マッパーをFetch-Messageに構成します。
  Current-Msgを展開し、「B 2bメッセージ・リファレンス」をFetchMessageInputの「B2Bメッセージ・リファレンス」にマップします。
7. マッパーに変更をクローズして適用します。
スコープ・レベルの障害ハンドラを追加します。
このハンドラは、バックエンド・アプリケーションでメッセージの処理に失敗した場合に、対応するトランザクションが(「成功」ではなく)「B2Bトラッキング」 > 「ビジネス・メッセージ」ビューで「失敗」としてマークされるように追加されます。
1. スコープの「障害ハンダ」 > 「デフォルトのハンドラ」をクリックします。最初は、次のように空です。
2. B2Bアクションをフォルト・ハンドラ内に配置し、名前を付けます(この例では、Mark-As-Error)。「次へ」をクリックします。
3. 方向として「インバウンド」を選択し、操作として「エラーとしてマーク」を選択します。「次へ」をクリックします
4. 要約ページで選択内容を確認し、「完了」をクリックします。
  障害ハンドラは次のようになります。
5. 次の要素をマッピングして、マッパーをMark-As-Errorに構成します:
  - ソースCurrent-Msg > Message > 「B 2bメッセージ・リファレンス」からターゲットMarkAsErrorInput > 「B2Bメッセージ・リファレンス」。
  - ソースHandle-One-MessageFaultObject > errorCodeからターゲットMarkAsErrorInput > 「エラー・コード」。
  - ソースHandle-One-MessageFaultObject > reasonからターゲットMarkAsErrorInput > 「エラーの理由」、および式ビルダーで、次のように入力します:
```
concat('Failed to send the message to the backend application, cause: ', $Handle-One-MessageFaultObject/nsmpr0:fault/nsmpr0:reason)
```
  - ソースHandle-One-MessageFaultObject >詳細をターゲットMarkAsErrorInput > 「エラーの詳細」にします。
6. マッピングを保存して適用します。
7. をクリックして、障害ハンドラを終了します。
バックエンド・アプリケーションを呼び出すアクションを追加します。
スコープ内に1つ以上のアクションを追加して、ビジネス・メッセージをバックエンド・アプリケーションに送信します。

前述の例では、RESTアダプタの起動接続によって、メッセージがバックエンド・アプリケーションに送信されます。特定のバックエンド・アプリケーションで使用するために、Oracle Integrationには、一般的な複数のバックエンド・アプリケーションとインタフェースできる多くのアプリケーション・アダプタが用意されています。 REST、SOAP、JMS、AQ、ファイルなどのテクノロジ・アダプタを使用することもできます。

「フェッチ・メッセージ・レスポンス」 (EDI翻訳アダプタ)には、マップ元となるB2B正規XMLが用意されています。 edi-xml-documentは、インバウンドEDIドキュメントの正規形を含むキー要素です。「インバウンドEDIのスキーマ要素」を参照してください。

バックエンドの起動前にメッセージを準備するために、データ・マッピングを設計する必要があります。これは複雑なタスクです。左側には、edi-xml-documentで表されるB2B標準XML形式があります。右側(下記には示されていません)は、ビジネス・ドキュメントのバックエンド・アプリケーション・スキーマです。左側の要素(B2B標準XML)と右側(バックエンド・アプリケーション・スキーマ)のマッピングを作成する必要があります。右側がターゲット・バックエンド・アプリケーションに固有であるため、マッピングを一般化できません。
統合トラッキングの識別子を追加します。
統合を完了するために、統合トラッキングの入力スキーマからフィールドを選択します。
バックエンド統合を保存してアクティブ化します。