Azure Logic Apps でのシングルテナント、マルチテナント、統合サービス環境の比較

Azure Logic Apps は、アプリ、データ、サービス、およびシステムを統合する自動化された "ロジック アプリ ワークフロー" を作成および実行するためのクラウドベースのプラットフォームです。 このプラットフォームを使用すると、エンタープライズおよび企業間 (B2B) シナリオ向けのスケーラビリティの高い統合ソリューションを迅速に開発できます。 ロジック アプリを作成するには、ロジック アプリ (従量課金) またはロジック アプリ (Standard) のいずれかのリソースの種類を使用します。 従量課金のリソースの種類は、"マルチテナント" Azure Logic Apps または "統合サービス環境" で実行され、Standard のリソースの種類は "シングルテナント" Azure Logic Apps 環境で実行されます。

使用するリソースの種類を選択する前に、この記事を参照して、リソースの種類とサービス環境が相互にどのように比較されるかを確認してください。 次に、シナリオのニーズ、ソリューションの要件、およびワークフローをデプロイ、ホスト、実行する環境に基づいて、最適な種類を決定できます。

Azure Logic Apps を初めて使用する場合は、次のドキュメントを参照してください。

リソースの種類と環境

ロジック アプリ ワークフローを作成するには、シナリオ、ソリューションの要件、必要な機能、およびワークフローを実行する環境に基づいて、ロジック アプリのリソースの種類を選択します。

次の表は、ロジック アプリ (Standard)ロジック アプリ (従量課金) のリソースの種類の違いを簡単にまとめたものです。 ロジック アプリ ワークフローを展開、ホスト、実行する際の、シングルテナント 環境と、マルチテナント環境および統合サービス環境 (ISE) との違いも分かります。

リソースの種類 メリット リソースの共有と使用 価格と課金モデル 制限の管理
ロジック アプリ (従量課金)

ホスト環境: マルチテナント Azure Logic Apps
- 最も簡単に開始できる

- 従量課金制

- フル マネージド
1 つのロジック アプリではワークフローを "1 つだけ" 使用できます。

"複数の Azure Active Directory テナントにわたる" ロジック アプリで、同じ処理 (コンピューティング)、ストレージ、ネットワークなどが共有されます。

高可用性を実現するために、geo 冗長ストレージ (GRS) が有効になっています。
従量課金プラン (従量課金制) Azure Logic Apps でこれらの制限の既定値が管理されますが、特定の制限に対してオプションが存在する場合は、これらの値の一部を変更できます。
ロジック アプリ (従量課金)

ホスト環境:
統合サービス環境 (ISE)
- 大規模なワークロードに対応したエンタープライズ規模

- 仮想ネットワークに直接接続する 20 個以上の ISE 固有コネクタ

- 含まれる使用量と顧客管理型スケーリングによる予測可能な価格
1 つのロジック アプリではワークフローを "1 つだけ" 使用できます。

"同じ環境内" のロジック アプリでは、同じ処理 (コンピューティング)、ストレージ、ネットワークなどが共有されます。

データは ISE をデプロイしたのと同じリージョンに残ります。
ISE (固定) Azure Logic Apps でこれらの制限の既定値が管理されますが、特定の制限に対してオプションが存在する場合は、これらの値の一部を変更できます。
ロジック アプリ (Standard)

ホスト環境:
シングルテナントの Azure Logic Apps

: シナリオでコンテナーが必要な場合は、Azure Arc 対応 Logic Apps を使用してシングルテナント ベースのロジック アプリを作成します。 詳細については、「Azure Arc 対応 Logic Apps とは」を参照してください。
- シングルテナント Azure Logic Apps ランタイムを使用して実行します。 デプロイ スロットは現在サポートされていません。

- 大規模なスループット向上とコスト削減を実現するための追加の組み込みコネクタ

- ランタイムとパフォーマンスの設定に関する制御と微調整機能の強化

- 仮想ネットワークとプライベート エンドポイントに対する統合サポート。

- 独自の組み込みコネクタの作成。
1 つのロジック アプリに、複数の "ステートフル" と "ステートレス" のワークフローを含めることができます。

"1 つのロジック アプリとテナント" のワークフローでは、同じ処理 (コンピューティング)、ストレージ、ネットワークなどが共有されます。

データはロジック アプリをデプロイしたのと同じリージョンに残ります。
Standard (選択した価格レベルのホスティング プランに基づきます)

外部ストレージを使用する "ステートフル" ワークフローを実行する場合は、Azure Logic Apps ランタイムによって、Azure Storage 価格に従うストレージ トランザクションが行われます。
シナリオのニーズに応じて、多くの制限の既定値を変更できます。

重要: 一部の制限には、ハード上限があります。 Visual Studio Code では、ロジック アプリのプロジェクト構成ファイル内の既定の制限値に対して行った変更は、デザイナー エクスペリエンスには表示されません。 詳細については、シングルテナントの Azure Logic Apps におけるロジック アプリのアプリと環境設定の編集に関するページを参照してください。
ロジック アプリ (Standard)

ホスト環境:
App Service Environment v3 (ASEv3) - Windows プランのみ
シングル テナントと同じ機能に "加え"、以下のメリットがあります。

- ロジック アプリを完全に分離します。

- シングルテナント Azure Logic Apps の場合よりも多くのロジック アプリを作成して実行します。

- 作成して実行するロジック アプリの数に関係なく、ASE App Service プランに対してのみ支払います。

- 自動スケールを有効にしたり、より多くの仮想マシン インスタンスや別の App Service プランを使用して手動でスケーリングできます。

- 選択した ASEv3 からネットワーク設定を継承します。 たとえば、内部 ASE にデプロイすると、ワークフローは ASE に関連付けられている仮想ネットワーク内のリソースにアクセスし、内部アクセス ポイントを持つ可能性があります。

: 内部 ASE の外部からアクセスする場合は、ASE がアクションの入力と出力にアクセスできないという、ワークフローの履歴を実行します。
1 つのロジック アプリに、複数の "ステートフル" と "ステートレス" のワークフローを含めることができます。

"1 つのロジック アプリとテナント" のワークフローでは、同じ処理 (コンピューティング)、ストレージ、ネットワークなどが共有されます。

データはロジック アプリをデプロイしたのと同じリージョンに残ります。
App Service プラン シナリオのニーズに応じて、多くの制限の既定値を変更できます。

重要: 一部の制限には、ハード上限があります。 Visual Studio Code では、ロジック アプリのプロジェクト構成ファイル内の既定の制限値に対して行った変更は、デザイナー エクスペリエンスには表示されません。 詳細については、シングルテナントの Azure Logic Apps におけるロジック アプリのアプリと環境設定の編集に関するページを参照してください。

ロジック アプリ (Standard) リソース

ロジック アプリ (Standard) のリソースの種類では、再設計されたシングルテナント Azure Logic Apps ランタイムが使用されています。 このランタイムには Azure Functions 機能拡張モデルが使用されており、Azure Functions ランタイムの拡張機能としてホストされます。 この設計により、ロジック アプリ ワークフローの移植性、柔軟性、パフォーマンス向上に加え、Azure Functions プラットフォームと Azure App Service エコシステムから継承されたその他の機能と利点が提供されます。 たとえば、Azure App Service Environment v3 では、シングルテナント ベースのロジック アプリとそのワークフローを作成、デプロイ、および実行することができます (Windows プランのみ)。

Azure Functions アプリで複数の関数をホストできるのと同様に、Standard のリソースの種類では、複数のワークフローをホストできるリソース構造が導入されています。 1 対多のマッピングでは、同じロジック アプリとテナント内のワークフローによってコンピューティングと処理リソースが共有され、その近接性によってパフォーマンスが向上します。 この構造は、ロジック アプリのリソースとワークフローの間に 1 対 1 のマッピングがあるロジック アプリ (従量課金) のリソースとは異なります。

移植性、柔軟性、およびパフォーマンス向上の詳細については、引き続き次のセクションを参照してください。 または、シングルテナントの Azure Logic Apps ランタイムと Azure Functions の拡張性の詳細について、次のドキュメントを参照してください。

移植性と柔軟性

Logic App (Standard) リソースの種類を使用してロジック アプリを作成すると、Azure App Service Environment v3 などの他の環境でワークフローをデプロイおよび実行できます (Windows プランのみ)。 Visual Studio Code を Azure Logic Apps (Standard) 拡張機能と共に使用する場合、Azure にデプロイせずに、開発環境で "ローカルに" ワークフローを開発、ビルド、および実行できます。 シナリオでコンテナーが必要な場合は、Azure Arc 対応 Logic Apps を使用してシングルテナント ベースのロジック アプリを作成します。 詳細については、「Azure Arc 対応 Logic Apps とは」をご覧ください。

Azure 内で実行されている既存のりソースに対して開発を行う必要があるマルチテナント モデルと比較すると、これらの機能によって大幅な改善と大きなメリットを得ることができます。 また、ロジック アプリ (従量課金) のリソースのデプロイを自動化するためのマルチテナント モデルは、アプリとインフラストラクチャの両方のリソース プロビジョニングを結合して処理する Azure Resource Manager テンプレート (ARM テンプレート) に基づいています。

ロジック アプリ (Standard) のリソースの種類では、アプリのデプロイとインフラストラクチャのデプロイを分離できるため、デプロイが容易になります。 シングルテナント Azure Logic Apps ランタイムとワークフローをロジック アプリの一部としてまとめてパッケージ化できます。 ロジック アプリのリソースをビルド、アセンブル、圧縮して、すぐにデプロイできる状態の成果物を生成する一般的な手順またはタスクを使用できます。 インフラストラクチャをデプロイする場合も、ARM テンプレートを使用して、それらの目的で使用する他のプロセスやパイプラインと共に、それらのリソースを別々にプロビジョニングできます。

アプリをデプロイするには、成果物をホスト環境にコピーしてから、アプリを開始してワークフローを実行します。 または、既に使ったことのあるツールとプロセスを使用して、成果物をデプロイ パイプラインに統合します。 そうすることで、開発に使用するテクノロジ スタックに関係なく、独自に選択したツールを使用してデプロイできます。

標準的なビルドとデプロイのオプションを使用することにより、インフラストラクチャのデプロイから切り離して、アプリの開発に集中できます。 その結果、プロジェクト モデルはより汎用的になり、汎用アプリに使用する多くの類似したまたは同じデプロイ オプションを適用できます。 また、アプリのデプロイ パイプラインを構築するときや、運用環境に発行する前に必要なテストと検証を実行するときに、より一貫性のあるエクスペリエンスを利用できます。

パフォーマンス

ロジック アプリ (Standard) のリソースの種類を使用すると、同じシングル ロジック アプリとテナント内に複数のワークフローを作成して実行できます。 この 1 対多のマッピングにより、これらのワークフローではコンピューティング、処理、ストレージ、ネットワークなどのリソースが共有され、その近接性によってパフォーマンスが向上します。

ロジック アプリ (Standard) のリソースの種類とシングルテナント Azure Logic Apps ランタイムでは、より一般的なマネージド コネクタを組み込み操作として使用できるようにすることで、もう 1 つの大幅な改善が提供されます。 たとえば、Azure Service Bus、Azure Event Hubs、SQL などに対して組み込み操作を使用できます。 一方、マネージド コネクタのバージョンは現在も利用でき、引き続き機能します。

新しい組み込み操作を使用する場合は、"組み込み接続" または "サービス プロバイダー接続" と呼ばれる接続を作成します。 それに対応するマネージド接続は "API 接続" と呼ばれます。これは、Azure リソースとして別個に作成されて実行され、ARM テンプレートを使用してデプロイする必要があります。 組み込み操作とその接続は、ワークフローを実行するのと同じプロセスでローカルに実行されます。 どちらも、シングルテナント Azure Logic Apps ランタイムでホストされます。 その結果、組み込み操作とその接続では、ワークフローとの近接性によってパフォーマンスが向上します。 サービス プロバイダーの接続が同じビルド成果物にパッケージされるため、この設計はデプロイ パイプラインでも適切に機能します。

データの保存場所

Logic App (Standard) リソースの種類を使用して作成されたロジック アプリ リソースは、シングルテナントの Azure Logic Apps でホストされます。ここでは、これらのロジック アプリ リソースをデプロイしたリージョン以外へのデータの格納、処理、レプリケートは行われません。つまり、ロジック アプリ ワークフローのデータは、その親リソースを作成してデプロイしたのと同じリージョン内に留まります。

作成、ビルド、およびデプロイのオプション

目的の環境に基づいてロジック アプリを作成するには、複数のオプションがあります。次に例を示します。

シングルテナント環境

オプション リソースとツール 詳細情報
Azure portal ロジック アプリ (Standard) のリソースの種類 シングルテナント Logic Apps の統合ワークフローを作成する - Azure portal
Visual Studio Code Azure Logic Apps (Standard) の拡張機能 シングルテナント Logic Apps の統合ワークフローを作成する - Visual Studio Code
Azure CLI Logic Apps Azure CLI の拡張機能 az logicapp
Azure Resource Manager - Local
- DevOps
シングルテナントの Azure Logic Apps
Azure Arc 対応 Logic Apps Azure Arc - 有効化済み Logic Apps の例   -   Azure Arc 対応 Logic Apps とは

   - Azure Arc 対応 Logic Apps を使用してシングルテナント ベースのロジック アプリ ワークフローを作成してデプロイする (プレビュー)

マルチテナント環境

オプション リソースとツール 詳細情報
Azure portal ロジック アプリ (従量課金) のリソースの種類 クイックスタート: マルチテナント Azure Logic Apps で統合ワークフローを作成する - Azure portal
Visual Studio Code Azure Logic Apps (従量課金) の拡張機能 クイックスタート: マルチテナント Azure Logic Apps で統合ワークフローを作成する - Visual Studio Code
Azure CLI Logic Apps Azure CLI の拡張機能 - クイックスタート: マルチテナント Azure Logic Apps で統合ワークフローを作成して管理する - Azure CLI

- az logic

Azure Resource Manager ロジック アプリを作成する ARM テンプレート クイックスタート: マルチテナント Azure Logic Apps で統合ワークフローを作成してデプロイする - ARM テンプレート
Azure PowerShell Az.LogicApp モジュール Azure PowerShell の概要
Azure REST API Azure Logic Apps REST API Azure Rest API リファレンスの概要

統合サービス環境

オプション リソースとツール 詳細情報
Azure portal 既存の ISE リソースを含むロジック アプリ(従量課金) のリソースの種類 クイックスタート: マルチテナント Azure Logic Apps で統合ワークフローを作成する - Azure portal と同じですが、マルチテナント リージョンではなく、ISE を選択します。

従量課金Standard のどちらのロジック アプリ リソースを作成するかによって開発エクスペリエンスは異なりますが、デプロイされたすべてのロジック アプリは Azure サブスクリプションの下にありアクセスできます。

たとえば、Azure portal では、 [ロジック アプリ] ページには従量課金Standard の両方のロジック アプリ リソースの種類が表示されます。 Visual Studio Code では、デプロイされたロジック アプリは Azure サブスクリプションの下に表示されますが、使用された拡張機能、つまり Azure: ロジック アプリ (従量課金)Azure: ロジック アプリ (Standard) によってグループ化されています。

ステートフルおよびステートレス ワークフロー

ロジック アプリ (Standard) のリソースの種類では、同じロジック アプリ内にこれらのワークフローを作成できます。

  • ステートフル

    前のイベントのデータを保持、確認、または参照する必要がある場合は、ステートフル ワークフローを作成します。 これらのワークフローは、すべての操作の入力、出力、および状態を外部ストレージに保存します。 この情報により、各実行が完了した後に、ワークフローの実行の詳細と履歴を確認できます。 ステートフル ワークフローでは、サービス停止が発生した場合に高い回復性を実現できます。 サービスとシステムが復元された後に、中断された実行を保存済みの状態から再構築し、ワークフローを再実行して完了することができます。 ステートフル ワークフローは、ステートレス ワークフローよりもはるかに長い間実行を継続できます。

    既定では、マルチテナントとシングルテナントの両方の Azure Logic Apps のステートフル ワークフローが非同期に実行されます。 HTTP ベースのすべてのアクションは、標準的な非同期操作パターンに従います。 HTTP アクションがエンドポイント、サービス、システム、または API に対して要求を呼び出す、または送信した後、受信側が直ちに "202 ACCEPTED" 応答を返します。 このコードは、受信側が要求を受け入れたが、処理が完了していないことを確認します。 応答には、受信側が処理を停止して "200 OK" 成功応答またはその他の 202 以外の応答が返されるまで、呼び出し元が非同期要求の状態をポーリングまたは確認するために使用できる URI およびリフレッシュ ID を指定する location ヘッダーを含めることができます。 ただし、呼び出し元は要求の処理が完了するまで待機する必要はなく、次のアクションの実行を継続できます。 詳細については、マイクロサービスの非同期統合によるマイクロサービスの自律性の強制に関するページを参照してください。

  • ステートレス

    後で確認するために、各実行が完了した後に外部ストレージに前のイベントのデータを保持、確認、参照する必要がない場合は、ステートレス ワークフローを作成します。 これらのワークフローでは、各アクションとその状態の入出力を外部ストレージにではなく、"メモリ内にのみ" 保存します。 その結果、ステートレス ワークフローでは、実行時間が短縮され (通常は 5 分未満)、パフォーマンスが高速化されて応答時間が短くなり、スループットが向上し、実行コストが削減されます。これは、実行の詳細と履歴が外部ストレージに保存されないためです。 しかし、サービス停止が発生した場合、中断された実行は自動的には復元されないため、呼び出し元は中断された実行を手動で再送信する必要があります。

    ステートレス ワークフローは、"合計" サイズが 64 KB を超えないファイルなどのデータやコンテンツを処理する際に、最高のパフォーマンスを発揮します。 サイズの大きな添付ファイルが複数ある場合など、コンテンツのサイズが大きくなると、ワークフローのパフォーマンスが著しく低下し、メモリ不足の例外によってワークフローのクラッシュが引き起こされることもあります。 ワークフローでより大きなサイズのコンテンツを処理する必要がある場合は、代わりにステートフル ワークフローを使用してください。

    ステートレス ワークフローでは、"マネージド コネクタ アクション" は使用できますが、"マネージド コネクタ トリガー" は使用できません。 そのため、ワークフローを開始するには、代わりに組み込みトリガー (Request、Event Hubs、Service Bus などのトリガー) を選択します。 これらのトリガーは、Azure Logic Apps ランタイムでネイティブに実行されます。 Recurrence トリガーはステートレス ワークフローでは使用できず、ステートフル ワークフローでのみ使用できます。 制限付き、使用できない、またはサポートされていないトリガー、アクション、コネクタの詳細については、「変更された、制限付き、使用できない、またはサポートされていない機能」を参照してください。

    ステートレス ワークフローは同期的にのみ実行されるため、ステートフル ワークフローで使用される標準の非同期操作パターンは使用されません。 代わりに、"202 ACCEPTED" 応答を返す HTTP ベースのすべてのアクションは、ワークフロー実行の次のステップに進みます。 応答に location ヘッダーが含まれる場合、ステートレス ワークフローでは、指定された URI をポーリングして状態を確認することはありません。 標準の非同期操作パターンに従うには、代わりにステートフル ワークフローを使用します。

    デバッグをより容易にするために、ステートレス ワークフローの実行履歴を有効にし (この場合、パフォーマンスに何らかの影響があります)、その後、完了時に実行履歴を無効にすることができます。 詳細については、Visual Studio Code でのシングルテナント ベースのワークフローの作成または Azure portal でのシングルテナント ベースのワークフローの作成に関するページを参照してください。

重要

作成時に実装するワークフローの種類 (ステートフルまたはステートレス) を決定する必要があります。 作成後にワークフローの種類を変更すると、実行時エラーが発生します。

ステートフル ワークフローとステートレス ワークフローの違いのまとめ

ステートレス ステートレス
実行履歴、入力、出力を保存する 既定では実行履歴、入力、または出力を保存しない
マネージド コネクタのトリガーは使用可能で、許可されている マネージド コネクタのトリガーは使用できないか、許可されていない
チャンクをサポート チャンクのサポートなし
非同期操作をサポート 非同期操作のサポートなし
ホスト構成で既定の最長実行期間を編集する 最長期間が 5 分未満のワークフローに最適
大きいメッセージを処理 サイズの小さいメッセージ (64 KB 未満) の処理に最適

ステートフルおよびステートレス ワークフローの入れ子になった動作の違い

Request トリガーHTTP Webhook トリガー、または ApiConnectionWebhook 型であり HTTPS 要求を受信できるマネージド コネクタ トリガーを使用することによって、同じロジック アプリ (Standard) リソースに存在する他のワークフローからワークフローを呼び出せるようにすることができます。

次の一覧では、親ワークフローで子ワークフローが呼び出された後、入れ子になったワークフローで従うことができる動作パターンを示します。

  • 非同期ポーリング パターン

    親ワークフローは、最初の呼び出しに対する子ワークフローからの応答を待ちません。 ただし、子が実行を完了するまで、親は継続的に子の実行履歴を確認します。 既定では、ステートフルなワークフローはこのパターンに従います。これは、要求タイムアウト制限を超える可能性がある、長時間実行される子ワークフローに適しています。

  • 同期パターン ("ファイア アンド フォーゲット")

    子ワークフローは、すぐに 202 ACCEPTED 応答を返すことで、親ワークフローの呼び出しに対して受信確認します。 ただし、親は子から結果が返されるのを待ちません。 代わりに、親はワークフロー内の次のアクションに進み、子が実行を完了したときに結果を受け取ります。 応答アクションを含まない子ステートフル ワークフローは、常に同期パターンに従い、確認用に実行履歴を提供します。

    この動作を有効にするには、ワークフローの JSON 定義で、operationOptions プロパティを DisableAsyncPattern に設定します。 詳細については、トリガーとアクションの種類 (操作オプション) に関するページを参照してください。

  • トリガーと待機

    ステートレス ワークフローはメモリ内で実行されます。 そのため、親ワークフローが子ステートレス ワークフローを呼び出すと、親は子からの結果を返す応答を待機します。 このパターンは、組み込みの HTTP トリガーまたはアクションを使用して子ワークフローを呼び出す場合と同様に機能します。 応答アクションを含まないステートレスな子ワークフローは直ちに 202 ACCEPTED 応答を返しますが、親は次のアクションに進む前に子が終了するまで待機します。 これらの動作は、ステートレスな子ワークフローにのみ適用されます。

次の表では、親と子がステートフル、ステートレス、または混合のどのワークフロー型であるかに基づいて、子ワークフローの動作を示します。 表の後の一覧

親ワークフロー 子ワークフロー 子の動作
ステートレス ステートレス "operationOptions": "DisableAsyncPattern" 設定を使用した非同期または同期
ステートレス ステートレス トリガーと待機
ステートレス ステートレス Synchronous
ステートレス ステートレス トリガーと待機

その他のシングルテナント モデルの機能

シングルテナント モデルとロジック アプリ (Standard) のリソースの種類には、次のような現行と新規の機能が多数含まれています。

  • サービスとしてのソフトウェア (SaaS) およびサービスとしてのプラットフォーム (PaaS) のアプリとサービス用の何百ものマネージド コネクタや、オンプレミス システム用のコネクタから、ロジック アプリとそのワークフローを作成します。

    • さらに多くのマネージド コネクタが、Standard ロジック アプリ ワークフローの組み込みコネクタとして使用できるようになりました。 組み込みバージョンは、シングルテナント Azure Logic Apps ランタイムでネイティブに実行されます。 一部の組み込みコネクタは "サービス プロバイダー" コネクタとも呼ばれています。 一覧については、従量課金と Standard の組み込みコネクタに関する記事を参照してください。

    • シングルテナント Azure Logic Apps 機能拡張フレームワークを使用して、必要なサービス用の独自のカスタム組み込みコネクタを作成できます。 Azure Service Bus や SQL Server などの組み込みコネクタと同様に、これらのカスタムの組み込みコネクタは、より高いスループット、短い待機時間、ローカル接続を実現しますが、これはシングルテナントのランタイムと同じプロセスでネイティブに実行されるためです。 ただし、カスタムの組み込みコネクタは、現在サポートされていない カスタム マネージド コネクタと似ています。 詳細については、「カスタム コネクタの概要」および「シングルテナントの Azure Logic Apps で Standard ロジック アプリ用のカスタム組み込みコネクタを作成する」を確認してください。

    • 統合アカウントを使わずに、Liquid 操作と XML 操作に以下のアクションを使用できます。 実行できる操作には次のアクションが含まれます。

      • XML: XML の変換XML の検証

      • Liquid: JSON から JSON への変換JSON からテキストへの変換XML から JSON への変換XML からテキストへの変換

      注意

      シングルテナント Azure Logic Apps (Standard) でこれらのアクションを使用するには、Liquid マップ、XML マップ、または XML スキーマが必要です。 これらの成果物は Azure portal で、ロジック アプリのリソース メニューの [成果物] ( [スキーマ] セクションと [マップ] セクションが含まれます) からアップロードできます。 または、Visual Studio Code プロジェクトの [成果物] フォルダーで [マップ] フォルダーと [スキーマ] フォルダーをそれぞれ使用して、これらの成果物を追加することもできます。 その後、"同じロジック アプリ リソース" 内の複数のワークフローで、これらの成果物を使用できます。

    • Azure Logic Apps によって、ロジック アプリでクラウド接続ランタイム エンドポイントに要求を送信するために使用できる Shared Access Signature (SAS) 接続文字列が生成されるため、ロジック アプリ (Standard) リソースはどこでも実行できます。 Azure Logic Apps サービスによって、これらの接続文字列が他のアプリケーション設定とともに保存されるため、Azure にデプロイするときにこれらの値を Azure Key Vault に簡単に格納できます。

    • Logic App (Standard) リソースの種類では、システム割り当てマネージド ID および複数のユーザー割り当てマネージド ID を同時に有効にすることができますが、いつでも使用できる ID は 1 つしか選択できません。

      注意

      既定では、実行時に接続を認証するために、システム割り当て ID は既に有効になっています。 この ID は、接続の作成時に使用する認証資格情報または接続文字列とは異なります。 この ID を無効にした場合、接続は実行時に機能しません。 この設定を表示するには、ロジック アプリのメニューの [設定] で、 [ID] を選択します。

  • Visual Studio Code 開発環境でローカルにロジック アプリとそのワークフローを実行、テスト、デバッグできます。

    ロジック アプリを実行してテストする前に、ワークフローの workflow.json ファイル内にブレークポイントを追加して使用することで、デバッグをより簡単に行うことができます。 しかし、ブレークポイントは、現時点ではトリガーではなく、アクションに対してのみサポートされます。 詳細については、Visual Studio Code でのシングルテナント ベースのワークフローの作成に関するページを参照してください。

  • ロジック アプリとそのワークフローを Visual Studio Code から、Azure や Azure Arc 対応 Logic Apps などのさまざまなホスティング環境に直接発行またはデプロイします。

  • Azure サブスクリプションとロジック アプリの設定でサポートされている場合は、Application Insights を使用してロジック アプリに対して診断ログとトレース機能を有効にします。

  • Azure Functions Premium プランを使用して、ロジック アプリを作成してデプロイする場合の Azure Functions と同様に、Azure 仮想ネットワークとのプライベートな接続や統合などのネットワーク機能にアクセスします。 詳細については、次のドキュメントを確認してください。

  • ロジック アプリ (Standard) リソースの個々のワークフローで使用されるマネージド接続のアクセス キーを再生成します。 このタスクでは、ロジック アプリのリソース レベルではなく、個々のワークフロー レベルで、ロジック アプリ (従量課金) リソースに対して同じ手順を実行します

Standard 用の組み込みコネクタ

Standard ロジック アプリ ワークフローには、従量課金プラン ロジック アプリ ワークフローと同じ組み込みコネクタが多くありますが、すべてではありません。 その逆に、Standard ロジック アプリ ワークフローには、従量課金プラン ロジック アプリ ワークフローでは使用できない多数の組み込みコネクタがあります。

たとえば、Standard ロジック アプリ ワークフローでは、Azure BLOB、Azure Cosmos DB、Azure Event Hubs、Azure Service Bus、DB2、FTP、MQ、SFTP、SQL Server などのためのマネージド コネクタと組み込みコネクタの両方が提供されます。 従量課金プラン ロジック アプリ ワークフローには、これらの同じ組み込みコネクタ バージョンはありませんが、Azure API Management、Azure App Services、Batch などの他の組み込みコネクタを使用できます。

シングルテナント Azure Logic Apps では、特定の属性を持つ組み込みコネクタは、非公式に "サービス プロバイダー" と呼ばれます 組み込みコネクタによっては、基盤となるサービスへの接続を認証する単一の方法のみがサポートされています。 接続文字列、Azure Active Directory (Azure AD)、マネージド ID の使用など、選択肢が提供される組み込みコネクタもあります。 すべての組み込みコネクタは、再設計された Azure Logic Apps ランタイムと同じプロセスで実行されます。 詳細については、Standard ロジック アプリ ワークフローの組み込みコネクタの一覧を確認してください。

変更された、制限付き、使用できない、またはサポートされていない機能

ロジック アプリ (Standard) リソースでは、これらの機能は変更されているか、現在制限されているか、使用できないか、またはサポートされていません。

  • トリガーとアクション: 組み込みのトリガーとアクションは、Azure Logic Apps でネイティブに実行されますが、マネージド コネクタは Azure 内でホストされて実行されます。 Standard ワークフローでは、スライディング ウィンドウ、Batch、Azure App Service、Azure API Management などの一部の組み込みトリガーとアクションは現在使用できません。 ステートフルまたはステートレス ワークフローを開始するには、組み込みトリガー (Recurrence、Request、Event Hubs、Service Bus などのトリガー) を使用します。 Recurrence トリガーはステートフル ワークフローでは使用できますが、ステートレス ワークフローでは使用できません。 デザイナーでは、組み込みのトリガーとアクションは [組み込み] タブに表示されますが、マネージド コネクタのトリガーとアクション[Azure] タブに表示されます。

    "ステートレス" ワークフローでは、"マネージド コネクタ アクション" は使用できますが、"マネージド コネクタ トリガー" は使用できません。 そのため、[Azure] タブは、マネージド コネクタ アクションを選択できる場合にのみ表示されます。 マネージド コネクタをステートレス ワークフローに対して有効にすることはできますが、デザイナーには、追加できるマネージド コネクタのトリガーは表示されません。

    注意

    Visual Studio Code でローカルに実行するには、Webhook ベースのトリガーとアクションに追加の設定が必要です。 詳細については、Visual Studio Code でのシングルテナント ベースのワークフローの作成に関するページを参照してください。

    • これらのトリガーとアクションは、変更されたか、現在制限されているか、サポートされていないか、使用できません。

      • オンプレミス データ ゲートウェイの "トリガー" は使用できませんが、ゲートウェイのアクションは使用 "できます"。

      • 組み込みアクションである [Azure Functions] - [Azure 関数を選択する] は、 [Azure Function Operations - Call an Azure function]([Azure 関数の操作] - [Azure 関数を呼び出す]) になりました。 このアクションは、現在、HTTP トリガー テンプレートから作成された関数に対してのみ機能します。

        Azure portal では、ユーザー エクスペリエンスを通じて接続を作成することによってアクセスできる HTTP トリガー関数を選択できます。 Visual Studio Code を使用してコード ビューまたは workflow.json ファイルで関数アクションの JSON 定義を調べる場合、アクションでは connectionName 参照を使用して関数が参照されます。 このバージョンでは関数の情報は接続として抽象化されます。これは、Visual Studio Code で接続を作成した後に使用できるようになる、ロジック アプリ プロジェクトの connections.json ファイルで確認できます。

        注意

        シングルテナント モデルの場合、関数アクションではクエリ文字列認証のみがサポートされます。 Azure Logic Apps では、接続を行っているときに関数から既定のキーが取得されます。そのキーはアプリの設定に格納され、関数を呼び出す際の認証に使用されます。

        マルチテナント モードと同様に、(たとえば、ポータルの Azure Functions エクスペリエンスを通じて) このキーを更新すると、無効なキーが原因で関数アクションは機能しなくなります。 この問題を解決するには、呼び出す関数への接続を再作成するか、新しいキーを使用してアプリの設定を更新する必要があります。

      • 組み込みアクションのインライン コードは、インライン コード操作に名前が変更され、統合アカウントは不要になり、制限が更新されました。

      • 組み込みアクションである [Azure Logic Apps - Choose a Logic App workflow]([Azure Logic Apps] - [ロジック アプリ ワークフローを選択する]) は、 [Workflow Operations - Invoke a workflow in this workflow app]([ワークフロー操作] - [このワークフロー アプリでワークフローを呼び出す]) になりました。

      • AS2 (V2) アクション、RosettaNet アクションなどの一部の統合アカウント用トリガーとアクションは使用できません。

      • Gmail コネクタは現在サポートされていません。

      • 現在、カスタムのマネージド コネクタはサポートされていません。 ただし、Visual Studio Code を使用する場合は、"カスタムの組み込み操作" を作成できます。 詳細については、Visual Studio Code を使用したシングルテナント ベースのワークフローの作成に関するページを参照してください。

  • 認証: 現在、次の認証の種類は、ロジック アプリ (Standard) のリソースの種類では使用できません。

    • 要求トリガーや HTTP Webhook トリガーなど、要求ベースのトリガーへの受信呼び出しに対する Azure Active Directory Open Authorization (Azure AD OAuth)。

    • ユーザー割り当てマネージド ID。 現時点では、システム割り当てマネージド ID のみが使用でき、自動的に有効になります。

  • XML 変換: マップからのアセンブリ参照のサポートは現在使用できません。 また、現在は XSLT 1.0 のみがサポートされています。

  • Visual Studio Code でのデバッグのブレークポイント: ワークフローの workflow.json ファイル内にブレークポイントを追加して使用することはできますが、ブレークポイントは現時点ではトリガーではなく、アクションに対してのみサポートされます。 詳細については、Visual Studio Code でのシングルテナント ベースのワークフローの作成に関するページを参照してください。

  • トリガー履歴と実行履歴: ロジック アプリ (Standard) のリソースの種類の場合、Azure portal のトリガー履歴と実行履歴は、ロジック アプリ レベルではなくワークフロー レベルで表示されます。 詳細については、Azure portal を使用したシングルテナント ベースのワークフローの作成に関するページを参照してください。

  • ズーム コントロール: 現在、デザイナーでズーム コントロールは使用できません。

  • デプロイ ターゲット: ロジック アプリ (Standard) のリソースの種類は、統合サービス環境 (ISE) にも Azure デプロイ スロットにもデプロイできません。

  • Azure API Management: 現在、ロジック アプリ (Standard) のリソースの種類を Azure API Management にインポートすることはできません。 ただし、ロジックアプリ (従量課金) のリソースの種類はインポートできます。

厳格なネットワークとファイアウォール トラフィックのアクセス許可

お使いの環境に、トラフィックを制限する厳しいネットワーク要件またはファイアウォールがある場合、お使いのワークフローですべてのトリガーまたはアクション接続にアクセスを許可する必要があります。 必要に応じて、サービス タグからのトラフィックを許可し、Azure App Service と同じレベルの制限またはポリシーを使用できます。 また、接続用の完全修飾ドメイン名 (FQDN) を見つけて使用する必要もあります。 詳しくは、次のドキュメントの対応するセクションをご確認ください。

次の手順

また、シングルテナント Azure Logic Apps でのエクスペリエンスについてご意見をお聞かせください。