機械翻訳について

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

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

アウトバウンド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つの方法のいずれかでバックエンド・アプリケーションによって直接または間接的に指定されます:

  1. 取引先識別子が指定されています。 これは、B2Bで新しい取引先を作成したときに入力した識別子と同じで、「基本情報」ページに表示されます。

    または

  2. アプリケーション・パートナIDが指定されています。 これは、取引先に追加できるB2B識別子です。

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

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

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

  1. 統合を作成し、トリガー接続を構成します。

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

    この例では、単純なRESTアダプタ・トリガーが使用されています。 Oracle ERP Cloudアダプタ、Oracle NetSuiteアダプタまたは別のアダプタに置き換えます。

  2. アウトバウンド変換操作を含むB2Bアクションを配置します。
    1. 統合にB2Bアクションを追加します。 B2Bアクションは、パレットの「アクション」の下に表示されます。
    2. 名前を入力します(この例ではEDI-Generateが追加されます)。 「続行」をクリックします。
    3. 方向として「アウトバウンド」を選択し、操作として「変換」を選択します。 「Continue」をクリックします。
    4. 「データ・フォーマットの選択」ページで、処理するこのバックエンド統合のドロップダウン・リストからドキュメント定義を選択します。 選択後、「続行」をクリックします。

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

    5. サマリー・ページで、選択内容を確認し、「終了」をクリックします。
  3. アプリケーション・メッセージをB2B標準形式に変換するようにマッパーを構成します。
    このマッピングは複雑である可能性があります。 それを2つの部分に分けて下さい。
    • 最初の部分で、要素を「B2B取引先ID」または「アプリケーション・パートナID」にマップします。 これらの要素は、送信する取引先を指定するために使用されます。 この概念を以前に説明した。 この例では、「B2B取引先ID」のみがマップされています。

      また、オプションで「アプリケーション・メッセージID」をマップします。 これは、バックエンド・アプリケーションによって割り当てられるメッセージIDです(ある場合)。 これがマップされている場合は、アウトバウンド・メッセージの詳細パネルに「モニタリング」 > 「B2Bトラッキング」 > 「ビジネス・メッセージ」の値が表示されます。 この値は処理中に使われませんが、保存されて参照専用で表示されます。

    • マップの2番目の部分はedi-xml-document用です。これは、マップの右側に表示されるEDIドキュメントのB2B標準XML形式です。 左側には、ビジネス・ドキュメントのバックエンド・アプリケーション・スキーマがあります。 このスキーマはバックエンド・アプリケーションに非常に固有であるため、バックエンド・アプリケーション・スキーマからB2B正規XMLへのマッピングを一般化できません。
  4. EDI変換を正常に行うためのチェックを追加します。
    1. B2B変換(EDI-Generate)アクションの後にスイッチ・アクションを配置します。 このアクションは、EDI変換が成功したか失敗したかを検出するための翻訳ステータスのチェックです。
    2. 「翻訳に成功しました」というルートを追加して、次の式を構成します:

      ノート:

      このシナリオに対してのみこのルートを追加し、onlyはtranslation-statusをSuccessおよびWarningステータスに設定します。 
      translation-status = "Success" or translation-status = "Warning"
    3. アウトバウンド・アグリーメントのバッチ処理を有効にし、変換が成功した場合、translation-statusはPending_Batchに設定されます。 このステータスは、翻訳が成功している間、ワイヤー・メッセージIDが作成されていないことを示します。 したがって、ステップまたはロガー・メッセージなしでtranslation-status = "Pending_Batch"を使用して、スイッチ・アクションに別のルートを追加します。
    4. 停止時間がスケジュールされ、変換が成功したときにアウトバウンド統合が正常に処理されるように、translation-statusはTRANSMISSION_PENDING_TP_DOWNに設定されます。 このステータスは、変換が成功し、ビジネス・メッセージおよびワイヤー・メッセージがステータス「送信待ちTPDown」に設定されていることを示します。 したがって、ステップなし、ロガー・メッセージまたは単純なリターンのいずれかを指定したtranslation-status = “TRANSMISSION_PENDING_TP_DOWN”を使用して、スイッチ・アクションに別のルートを追加します。
  5. 翻訳が成功した場合は、取引先に文書を送付する準備をしてください。
    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に指定された統合をコールします。
  6. 成功のための復帰アクションとエラーの障害を追加します。
    1. 「翻訳に成功しました」ルートに対する正常なレスポンスおよび「それ以外」ルートの障害戻りを返すように、統合のリターン・アクションを追加します。

      このステップは、REST Adapterトリガーで選択された例に固有です。 実際の結果は異なる場合があります。 バックエンド・アプリケーションによっては、成功または失敗した変換の結果をバックエンド・アプリケーションに戻すメカニズムがある場合とない場合があります。

  7. 統合トラッキングのB2Bビジネス識別子を追加します。
    1. 統合トラッキングを行うために、入力スキーマからフィールドを選択します。 これは、主にバックエンド・アプリケーション・スキーマに固有です。
    2. バックエンド統合を保存してアクティブ化します。

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

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

インバウンド・バックエンド統合と同様に、統合にスイッチ・アクションを追加し、各ドキュメント定義または取引先とその独自のマップおよびB2B変換アクションに特定のルートを追加して、複数のドキュメント・タイプを処理する単一の統合を設計できます。