次の方法で共有

Azure Logic Apps でワークフローを使用して X12 メッセージを交換する

  • [アーティクル]

適用対象: Azure Logic Apps (従量課金プラン + Standard)

Azure Logic Apps を使用して作成したワークフローで X12 メッセージを送受信するには、X12 通信をサポートおよび管理する操作を提供する X12 コネクタを使用します。

このハウツー ガイドでは、X12 エンコードおよびデコード アクションを既存のロジック アプリ ワークフローに追加する方法について説明します。 X12 コネクタにはトリガーが含まれていないため、任意のトリガーを使用してワークフローを開始できます。 このガイドの例では、要求トリガーを使用します。

コネクタに関するテクニカル リファレンス

X12 コネクタには、マルチテナント Azure Logic Apps およびシングルテナント Azure Logic Apps のワークフロー全体で 1 つのバージョンがあります。 X12 コネクタに関する技術情報については、次のドキュメントを参照してください。

前提条件

  • Azure アカウントとサブスクリプション。 Azure サブスクリプションがない場合は、無料の Azure アカウントにサインアップしてください。

  • エンタープライズ統合および B2B ワークフローで使用する成果物 (取引先、契約、証明書など) を定義して保存する統合アカウント リソース。 このリソースでは、次の要件が満たされている必要があります。

    • 統合アカウントとロジック アプリ リソースの両方が、同じ Azure サブスクリプションと Azure リージョンに存在する必要があります。

    • ワークフローで使用される X12 操作に参加する少なくとも 2 つの取引先を定義します。 両方の取引先の定義では、同じ X12 ビジネス ID 修飾子を使用する必要があります。

    • ワークフローに参加する取引先間の X12 契約を定義します。 契約には、ホスト パートナーとゲスト パートナーが必要です。 他の取引先との間のメッセージの内容が、契約の種類と一致している必要があります。 メッセージの送受信時に使用する契約設定については、「X12 メッセージ設定」を参照してください。

      重要

      医療保険の携行性と責任に関する法律 (HIPAA) スキーマを操作する場合は、契約に schemaReferences セクションを追加する必要があります。 詳細については、「HIPAA スキーマとメッセージ型」を参照してください。

    • XML 検証に使用するスキーマを定義します。

      重要

      Health Insurance Portability and Accountability Act (HIPAA) スキーマを使用している場合は、「HIPAA スキーマとメッセージ型」を参照してください。

  • 従量課金 または Standard のいずれのロジック アプリ ワークフローで作業しているかに基づいて、ロジック アプリ リソースが統合アカウントのリンクを必要な場合があります：

    ロジック アプリワークフロー リンクが必要ですか?
    従量課金プラン 接続と統合アカウントへのリンクが必要です。 X12 操作をワークフローに追加するときに接続を作成できます。
    Standard 統合アカウントへの接続は必要ですが、リンクは必要ありません。 X12 操作をワークフローに追加するときに接続を作成できます。

  • X12 操作を使用するロジック アプリ リソースとワークフロー。

    詳しくは、次のドキュメントをご覧ください。

X12 メッセージをエンコードする

X12 メッセージへのエンコード操作は、次のタスクを実行します。

  • 送信者と受信者のコンテキスト プロパティを照合することで契約を解決する。
  • XML エンコード メッセージをインターチェンジ内の EDI トランザクション セットに変換して、EDI インターチェンジをシリアル化する。
  • トランザクション セット ヘッダーおよびトレーラー セグメントを適用する。
  • 各送信インターチェンジのインターチェンジ制御番号、グループ制御番号、およびトランザクション セット制御番号を生成する。
  • ペイロード データの区切り記号を置換する。
  • EDI およびパートナー固有のプロパティを検証する。
    • メッセージ スキーマと照らし合わせたトランザクション セット データ要素のスキーマ検証。
    • トランザクション セット データ要素に対する EDI 検証。
    • トランザクション セット データ要素に対する拡張検証。
  • 技術確認および機能確認を要求する (構成されている場合)。
    • ヘッダー検証の結果として技術確認を生成する。 技術確認は、アドレス受信者によるインターチェンジ ヘッダーとトレーラーの処理の状態を報告します。
    • 本体検証の結果として機能確認を生成する。 機能確認は、受信したドキュメントの処理中に発生した各エラーを報告します。

  1. Azure portal のデザイナーで、ロジック アプリ リソースとワークフローを開きます。

  2. デザイナーで、次の一般的な手順に従って、契約名によって X12 メッセージにエンコードするという名前の X12 アクションをワークフローに追加します。

    Note

    代わりに ID アクションによる X12 メッセージへのエンコードを使用する場合は、X12 契約で指定されている送信者識別子や受信者識別子など、後で別の値を指定する必要があります。 また、"エンコードする XML メッセージ" を指定する必要もあります。これは、トリガーまたは前のアクションからの出力です。

  3. プロンプトが表示されたら、統合アカウントの次の接続情報を入力します:

    プロパティ Required 説明
    接続名 はい 接続の名前
    統合アカウント はい 使用可能な統合アカウントの一覧から、使用するアカウントを選択します。

    次に例を示します。

    契約名による X12 メッセージへのエンコードという名前のアクションの従量課金ワークフローと接続情報を示すスクリーンショット。

  4. 完了したら [作成] を選択します。

  5. [X12 アクション情報] ボックスに、次のプロパティ値を入力します。

    プロパティ Required 説明
    X12 契約の名前 はい 使用する X12 契約。
    エンコードする XML メッセージ はい エンコードする XML メッセージ
    その他のパラメーター いいえ この操作には、次の他のパラメーターが含まれます。

    - データ要素区切り記号
    - コンポーネントの区切り記号
    - 置換文字
    - セグメント終端記号
    - セグメント終端記号のサフィックス
    - 制御バージョン番号
    - アプリケーション送信者識別子/コード GS02
    - アプリケーション受信者識別子/コード GS03

    詳細については、X12 メッセージの設定に関する記事を参照してください。

    たとえば、Request トリガーから出力された Body コンテンツを XML メッセージ ペイロードとして使用できます。

    従量課金ワークフロー、契約名による X12 メッセージへのエンコードという名前のアクション、アクションのプロパティを示すスクリーンショット。

X12 メッセージをデコードする

X12 メッセージのデコード操作は、次のタスクを実行します。

  • 取引先契約と照らし合わせてエンベロープを検証する。

  • EDI およびパートナー固有のプロパティを検証する。

    • EDI 構造検証、および拡張スキーマ検証
    • インターチェンジ エンベロープ構造検証
    • 制御スキーマと照らし合わせたエンベロープのスキーマ検証
    • メッセージ スキーマと照らし合わせたトランザクション セット データ要素のスキーマ検証
    • トランザクション セット データ要素に対する EDI 検証

  • インターチェンジ、グループ、およびトランザクション セットの制御番号が重複していないことを検証する。

    • 以前に受信したインターチェンジと照らし合わせて、インターチェンジ制御番号を確認する。
    • インターチェンジ内の他のグループ制御番号と照らし合わせて、グループ制御番号を確認する。
    • グループ内の他のトランザクション セット制御番号と照らし合わせて、トランザクション セット制御番号を確認する。

  • インターチェンジをトランザクション セットに分割するか、インターチェンジ全体を保持する。

    • 交換をトランザクション セットに分割するか、エラー時にトランザクション セットを一時停止する。各トランザクション セットを解析する。 X12 デコード アクションは、検証が失敗したトランザクション セットのみを badMessages に出力し、残りのトランザクション セットを goodMessages に出力します。

    • インターチェンジをトランザクション セットに分割するか、エラー時にインターチェンジを一時停止します。各トランザクション セットを解析します。 インターチェンジの 1 つ以上のトランザクション セットが検証に失敗した場合、X12 でコード アクションはそのインターチェンジのすべてのトランザクション セットを badMessages に出力します。

    • [インターチェンジの保存またはエラー発生時にトランザクション セットを中断]: インターチェンジを保持し、バッチ インターチェンジ全体を処理します。 X12 デコード アクションは、検証が失敗したトランザクション セットのみを badMessages に出力し、残りのトランザクション セットを goodMessages に出力します。

    • [インターチェンジの保存またはエラー発生時にインターチェンジを中断]: インターチェンジを保持し、バッチ インターチェンジ全体を処理します。 インターチェンジの 1 つ以上のトランザクション セットが検証に失敗した場合、X12 でコード アクションはそのインターチェンジのすべてのトランザクション セットを badMessages に出力します。

  • 技術確認および機能確認を生成する (構成されている場合)。

    • ヘッダー検証の結果として技術確認を生成する。 技術確認は、アドレス受信者によるインターチェンジ ヘッダーとトレーラーの処理の状態を報告します。
    • 本体検証の結果として機能確認を生成する。 機能確認は、受信したドキュメントの処理中に発生した各エラーを報告します。

  1. Azure portal のデザイナーで、ロジック アプリ リソースとワークフローを開きます。

  2. デザイナーで、次の一般的な手順に従って、X12 メッセージのデコード という名前の X12 アクションをワークフローに追加します。

  3. プロンプトが表示されたら、統合アカウントの次の接続情報を入力します。

    プロパティ Required 説明
    接続名 はい 接続の名前
    統合アカウント はい 使用可能な統合アカウントの一覧から、使用するアカウントを選択します。

    次に例を示します。

    X12 メッセージのデコードという名前のアクションの従量課金ワークフローと接続情報を示すスクリーンショット。

  4. 完了したら [作成] を選択します。

  5. [X12 アクション情報] ボックスに、次のプロパティ値を入力します。

    プロパティ Required 説明
    エンコードする X12 フラット ファイル メッセージ はい デコードするフラット ファイル形式の X12 メッセージ

    注: XML メッセージ ペイロードまたはメッセージ配列のコンテンツは、良いか悪いかにかかわらず、base64 でエンコードされます。 そのため、このコンテンツを処理する式を使用する必要があります。 たとえば、次の式はメッセージ コンテンツを XML として処理します。

    xml(base64ToBinary(item()?['Body']))
    その他のパラメーター いいえ この操作には、次の他のパラメーターが含まれます。

    - インターチェンジの保存
    - エラー発生時にインターチェンジを中断

    詳細については、X12 メッセージの設定に関する記事を参照してください。

    たとえば、Request トリガーから出力された Body コンテンツを XML メッセージ ペイロードとして使用できますが、最初に次の式を使用してこのコンテンツを前処理する必要があります。

    従量課金ワークフロー、Decode X12 メッセージという名前のアクション、アクションのプロパティを示すスクリーンショット。

次のステップ