機械翻訳について

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

この項では、インバウンドB2Bメッセージの処理に関連する高レベルのステップについて説明します。


この図は、すぐ下の表に記載されています。

ステップ 説明
1 送信されたメッセージ、または取引先からFTPのロケーションにドロップされたファイルがアダプタ・エンドポイント(AS2またはFTP)に到着します。 メッセージを受信して解凍します。
2

メッセージはEDIから正規XML形式に変換され、Oracle Integration永続ストアに保持されます。 一意のIDが割り当てられます。

メッセージに不明なフォーマットまたはバイナリ・タイプのペイロードが含まれている場合(つまり、インバウンド・アグリーメントで不透明標準のドキュメントを使用する)、base64がエンコードされ、Oracle Integration永続ストアに保持されます。 一意のIDが割り当てられます。

3 現在のメッセージ・タイプおよび取引先に定義されているインバウンド契約に基づいて、適切なインバウンド・バックエンド統合がトリガーされます。 メッセージIDが渡されます。
4 バックエンド統合インスタンスが起動し、RESTトリガー・エンドポイントでメッセージIDを受け取ります。
5 メッセージIDを指定したバックエンド統合は、変換された標準XMLメッセージまたはbase64エンコードされたメッセージをOracle Integration永続ストアから取得します。 B2Bフェッチ・メッセージ操作を使用して取得します。
6 正規のXMLまたはbase64エンコード・メッセージは、さらにバックエンド・アプリケーション・メッセージに変換されます。
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のチャンクで複数回コールできます。

  1. 統合を作成し、RESTアダプタ・トリガーを構成します。
    1. アプリケーション・パターンを選択します。 名前は任意にします。 この例では、 Backend - Inbound Purchase Ordersが使用されています)。
    2. OAuth 2.0またはBasic認証セキュリティ・ポリシーを使用する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. 「続行」をクリックしてサマリー・ページにアクセスし、選択内容を確認し、「終了」をクリックします。
  2. RESTアダプタ・トリガーの後にfor-eachアクションを配置します。
  3. 「繰返し要素」としてrequest-wrapper > messageを選択し、「現在の要素名」値としてCurrent-Msgと入力します。
  4. for-eachアクション内にスコープを追加し、名前を付けます(この例では、Handle-One-Messageという名前)。
  5. スコープ内にメッセージのフェッチ操作で構成されたB2Bアクションを追加します。 B2Bアクションは、パレットの「アクション」の下に表示されます。
    1. 名前(この例ではFetch-Message)を入力し、「B2B取引パートナ・モード」を選択して、「続行」をクリックします。
    2. 方向として「インバウンド」を選択し、操作として「メッセージのフェッチ」を選択します。 「Continue」をクリックします。
    3. 「データ・フォーマットの選択」ページで、このバックエンド統合が処理されるドロップダウン・リストからドキュメント定義を選択します。

      既存のB2Bドキュメントが選択のためにドロップダウン・リストに表示されます。 または、「検索」をクリックして、ドキュメントの標準、バージョンおよびタイプでB2Bドキュメントを選択します。

    4. 選択したら、「続行」をクリックします。
    5. サマリー・ページで、選択内容を確認し、「終了」をクリックします。
    6. マッパーをFetch-Messageに構成します。

      Current-Msgを展開し、「B2bメッセージ参照」をFetchMessageInputの「B2Bメッセージ・リファレンス」にマップします。

    7. マッパーに変更をクローズして適用します。
  6. スコープ・レベルの障害ハンドラを追加します。

    このハンドラは、バックエンド・アプリケーションでメッセージの処理に失敗した場合に、対応するトランザクションが(「成功」ではなく)「B2Bトラッキング」 > 「ビジネス・メッセージ」ビューで「失敗」としてマークされるように追加されます。

    1. スコープの「フォルト・ハンドラ」 > 「デフォルトのハンドラ」をクリックします。 最初は空です。
    2. B2Bアクションをフォルト・ハンドラ内に配置し、名前を付けます(この例では、Mark-As-Error)。 「続行」をクリックします。
    3. 方向として「インバウンド」を選択し、操作として「エラーとしてマーク」を選択します。 「Continue」をクリックします。
    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. フォルト・ハンドラを終了します。
  7. バックエンド・アプリケーションを呼び出すアクションを追加します。

    スコープ内に1つ以上のアクションを追加して、ビジネス・メッセージをバックエンド・アプリケーションに送信します。

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

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

    バックエンドの起動前にメッセージを準備するために、データ・マッピングを設計する必要があります。 これは複雑なタスクです。 左側には、edi-xml-documentで表されるB2B標準XML形式があります。 右側(下記には示されていません)は、ビジネス・ドキュメントのバックエンド・アプリケーション・スキーマです。 左側の要素(B2B標準XML)と右側(バックエンド・アプリケーション・スキーマ)のマッピングを作成する必要があります。 右側がターゲット・バックエンド・アプリケーションに固有であるため、マッピングを一般化できません。

  8. 統合トラッキングの識別子を追加します。

    統合トラッキングを行うために、入力スキーマからフィールドを選択します。

  9. バックエンド統合を保存してアクティブ化します。

複数のタイプの文書を処理するためのバックエンド統合の設計

詳細なステップは、処理するドキュメント定義ごとに1つのバックエンド統合を作成することを前提としています。 基本パターンが同じであるため、他のドキュメント・タイプの統合をクローニングできます。

複数の文書タイプを処理する単一の統合を設計する場合は、統合にスイッチ処理を追加し、各文書定義または取引先に特定のルートを追加します。

各ルートには、独自のB2Bメッセージのフェッチ操作、データ・マッピングおよびバックエンド・アプリケーションへの呼出しがあります。 この設計パターンは、開発と運用が容易な間のトレードオフです。 たとえば、購買オーダー文書のマッピングを修正する必要がある場合は、次を実行する必要があります:
  • 購買オーダー文書を処理するバックエンド統合を非アクティブ化します。
  • マッピングを修正します。
  • 統合を再アクティブ化します。

ドキュメント・タイプごとに個別のバックエンド統合がある場合、その影響は1つの特定の統合に分離されます。 一方、すべてが1つの統合に組み込まれている場合、本番デプロイメントには様々な影響があります。