機械翻訳について

基本契約の作成

この項では、契約の作成および管理について詳しく説明します。 特定のタイプのビジネス文書のみをその取引先との間で送受信するインテントで、B2B取引先に対して1つ以上の契約を定義します。

詳細な契約概念が提供されます。 「アグリーメント」を参照してください。

取引先「トランスポート&契約」タブからインバウンド契約およびアウトバウンド契約のリストを表示できます。

  1. プロジェクトに契約を作成します。
    1. ナビゲーション・ペインで、「プロジェクト」をクリックします。
    2. 契約を作成するプロジェクトをクリックします。
    3. B2B B2Bアイコンをクリックします。
    4. 「取引先」セクションで、アグリーメントを作成する取引先をクリックします。
  2. スタンドアロン環境でアグリーメントを作成します。
    1. ナビゲーション・ペインで、B2B「取引先」の順にクリックします。

      取引先ページが表示されます。


      trading_partners3.pngの説明は以下のとおりです
      図trading_partners3.pngの説明

    2. アグリーメントを作成する取引先をクリックします。
  3. 次の詳細に注意してください。
    • アクティブなアグリーメントを持つ取引パートナは削除できません。
    • 「表示」 「表示」アイコンをクリックして、取引先に関する特定の詳細(関連する取引先契約を含む)を表示します。
    • アグリーメントを作成する取引パートナの行で、「編集」 「編集」アイコンをクリックします。

インバウンドおよびアウトバウンド契約の定義

  1. 「トランスポート&契約」をクリックします。
  2. 「インバウンド契約」セクションで、「追加」 インストール・アイコンをクリックして新しい契約を追加します。
    1. 次の詳細を定義します。
      フィールド 説明
      名前 名前を入力します。

      これは参照専用です。 取引先に定義した契約名または構成詳細は表示されません。

      説明 オプションで説明を入力します。
      ドキュメントを選択します 受信するドキュメントのタイプを選択します。 既存のB2Bドキュメントを選択するか、新しいB2Bドキュメントを作成できます。 「カスタムB2Bドキュメント定義の作成」を参照してください。
      バックエンド統合を選択します B2B処理後にこのドキュメントをルーティングするバックエンド統合を選択します。 リストからいずれかを選択するか、バックエンド統合の識別子とバージョンがわかっている場合は、次の形式で入力します:
      INTEGRATION_IDENTIFIER|01.00.0000

      バックエンド統合の概念が提供されます。 「B2Bメッセージ処理に使用される統合」を参照してください。

      バックエンド統合が作成されていることを確認します。 「バックエンド統合の作成」を参照してください。

      統合のドロップダウン・リストはフィルタされ、B2Bアクションを使用する統合のみが表示されます。 現在、すべてのB2Bシステム統合も表示されます。 B2Bシステム統合を選択しないでください。 このタイプのドキュメントを処理するには、個別に作成したバックエンド統合を選択する必要があります。 バックエンド統合は、Oracle ERP Cloudなどのバックエンド・アプリケーションとインタフェースします。

      ノート: B2B for Oracle Integrationに固有の統合を表示するには、Integrationsページの検索フィールドにediadapterと入力します。

      検証の有効化 受信したEDIペイロードに対して構文検証を実行し、検証エラーが見つかった場合は拒否する場合に選択します。 「機能確認の生成」も有効になっている場合、取引先に戻される機能確認が、見つかった検証エラーを含め、受入または拒否を伝えます。

      構文検証チェックをスキップし、常にEDIペイロードを受け入れるには選択を解除します。

      「エラー・グループ」タブでエラー・グループを作成した場合は、次のリストが表示されます。

      • エラー・グループの受入れ
      • エラー・グループの拒否

      「EDI変換のエラー・ルールの構成」を参照してください。

      機能確認の生成 取引パートナに対して機能確認を生成して送信する場合に選択します。
      • EDI X12の場合、997ドキュメントが生成されます。
      • X12 HIPAAでは、999確認ドキュメントが生成されます。
      • EDIFACTの場合は、EDI変換の結果を解決するためにCONTRLドキュメントが生成されます。
      • RosettaNetの場合、受信確認が生成されます。

      生成された機能確認は、受信ドキュメントの受信元トランスポートにリンクされているメッセージを送信するために、B2B統合に自動的にルーティングされます。

      機能確認を生成または送信しない場合は、選択解除します。

      この設定では、会社と取引先が機能確認応答を使用するかどうかを相互に決定する必要があります。 問題は、あるパーティがこれらの確認を想定しているが、他のパーティが通知を送信しない場合です。

      重複する管理番号の確認の有効化 B2Bトランザクションのインバウンド契約でコントロール番号の重複をチェックする場合にオンにします。 これにより、コントロール番号が重複しているトランザクションの処理が回避されます。 たとえば、2つのトランザクションのコントロール番号間に重複がある場合は、番号が一意であるが、2番目のトランザクションが捕捉されて処理されないため、最初のメッセージは正常に処理されます。 トランザクション失敗は、トラッキングB2Bメッセージ・ページのトランザクションの「メッセージ・ログ」セクションに表示されます。 たとえば、次のメッセージは、捕捉されて処理されなかった重複コントロール番号のメッセージの一部です:
      This EDI transaction with 
      document type [850], version [4010] 
      was not translated because it was 
      determined to be a duplicate of a 
      transaction. 
    2. 「追加」をクリックします。
    3. 「アクション」「アクション」アイコンメニューから、「デプロイ」を選択します。
    4. プロンプトが表示されたら、「デプロイ」を再度選択します。

      インバウンド契約ステータスが「アクティブ」に変更されます。

    5. 契約をアンデプロイする必要がある場合は、「アクション」 「アクション」アイコンメニューから「アンデプロイ」を選択します。
    6. 「編集」 「編集」アイコンをクリックして更新します。
  3. 「アウトバウンド契約」セクションで、「追加」 インストール・アイコンをクリックして新しい契約を追加します。
    1. 次の詳細を定義します。
      フィールド 説明
      名前 名前を入力します。

      これは参照専用です。 取引先に定義した契約名または構成詳細は表示されません。

      説明 オプションで説明を入力します。
      ドキュメントを選択します 送信するドキュメントのタイプを選択します。 既存のB2Bドキュメントを選択するか、新しいB2Bドキュメントを作成できます。 「カスタムB2Bドキュメント定義の作成」を参照してください。
      識別子の選択 「EDI交換ID」DUNS (RosettaNetの場合)など、特定の必須およびオプションの識別子が、アウトバウンド変換中にEDIエンベロープ・セグメントに挿入されます。 エンベロープに挿入する識別子を選択します。 「ロール」識別子は、AS4メッセージのイニシエータ/レスポンダ・ロール・フィールドに移入するために使用されます。

      「B2B識別子の定義」「ホスト・プロファイルでの識別子の定義」を参照してください。

      • 取引先識別子の選択: 文書を受け取る取引先を識別します。 受け側の値として挿入する取引先識別子を選択します(たとえば、交換受け側ID、応答者ロールなど)。
      • ホスト識別子の選択: ドキュメントを送信するホストを指定します。 送信側の値として挿入するホスト識別子を選択します(たとえば、交換送信者ID、イニシエータ・ロールなど)。
      トランスポートの選択 トランスポートを選択して、現在のアウトバウンド契約で処理されたメッセージをそのトランスポートにルーティングし、最終的に外部の取引先に配信します。

      トランスポートを選択すると、メッセージ送信のためにバックエンド統合からB2B統合へのメッセージのルーティング方法を制御するルーティング・ルールが定義されます。

      アウトバウンド・メッセージのルーティング方法に関する詳細が提供されます。 「統合間のメッセージ・ルーティング」を参照してください。

      検証の有効化
      • アウトバウンドEDI変換中に標準XMLペイロードで構文検証を実行する場合に選択します。

        このステップで検証エラーが検出された場合、出力EDIは構文的に無効であり、取引先に送信されないことを意味します。 したがって、これは翻訳フェーズ中に拒否され、メッセージを送信するためにB2B統合にルーティングされません。

      • 構文検証チェックをスキップし、エラーがある場合でもEDIペイロードを取引先に送信する場合は選択を解除します。

      「エラー・グループ」タブでエラー・グループを作成した場合は、次のリストが表示されます。

      • エラー・グループの受入れ
      • エラー・グループの拒否

      「EDI変換のエラー・ルールの構成」を参照してください。

      機能確認が必要
      • 取引先が常に機能確認応答を送信することを要求(および予期)する場合に選択します。 確認が必要な場合、アウトバウンド・ビジネス・メッセージは送信後に「機能確認待ち」状態になり、確認の受信時にのみ「成功」または「失敗」としてマークされます。
      • 機能確認を必要としない(または期待する)場合は選択を解除します。 アウトバウンド・ビジネス・メッセージは、すぐに「成功」としてマークされます。

      この設定では、会社と取引先が機能確認応答を使用するかどうかを相互に決定する必要があります。 問題は、あるパーティがこれらの確認を想定しているが、他のパーティが通知を送信しない場合です。

    2. 「追加」をクリックします。
    3. 「アクション」「アクション」アイコンメニューから、「デプロイ」を選択します。
    4. プロンプトが表示されたら、「デプロイ」を再度選択します。 アウトバウンド契約ステータスが「アクティブ」に変更されます。
    5. 契約をアンデプロイする必要がある場合は、「アクション」 「アクション」アイコンメニューから「アンデプロイ」を選択します。
    6. 「編集」 「編集」アイコンをクリックして更新します。

契約のライフ・サイクル処理

行の「アクション」 「アクション」アイコンをクリックして、使用可能なアクションを表示します。

契約のライフサイクル処理は、次のとおりです:
  • 基本契約の作成: 設計時のみの定義を追加します(ただし、デプロイしないかぎり、新しい契約は実行時に強制されません)。
  • 契約のデプロイ: 契約を実行時処理に表示し、即時に強制します。
  • 契約の再デプロイ: メッセージ処理を中断することなく、実行時に構成の変更をオンザフライに適用します。
  • 契約のアンデプロイ: 実行時に処理から契約が非表示になり、すぐに開始して無効になります。
  • 契約の削除: 設計時に削除します。

ランタイムの値の更新および変更の適用

既存の契約設定はいつでも更新できます。 ただし、契約が再デプロイされるまで、変更は実行時処理には適用されません。

再デプロイメントは、契約に使用できるライフサイクル処理です。 メッセージ処理を中断することなく、実行時に変更を適用します。

識別子値の変更

契約設定を直接変更しない場合でも、識別子の値を変更すると、契約が間接的に変更されます。 「取引先」「B2B識別子」または「ホスト・プロファイル」「識別子」の順に選択します。

間接的な変更を適用するには、契約を再デプロイします。

インバウンド契約には、B2B識別子が暗黙的にインバウンド契約で使用されるため、特別なケースが1つあります:
  • 取引先識別子を追加、更新または削除する場合は、任意の契約を再デプロイして、識別子の変更をランタイムに適用します。

詳細は、ビデオをご覧ください: