次の方法で共有

Visual Studio Code を使ってシングルテナント Azure Logic Apps の Standard ロジック アプリ ワークフローを作成する

  • [アーティクル]

適用対象: Azure Logic Apps (Standard)

攻略ガイドでは、Azure Logic Apps (Standard) 拡張機能で Visual Studio Code を使用して、シングルテナント Azure Logic Apps で実行される統合ワークフローの例を作成する方法について説明します。 このワークフローを作成する前に、次の機能を提供する Standard ロジック アプリ リソースを作成します。

  • ロジック アプリには複数のステートフルおよびステートレスのワークフローを含めることができます。

  • 同じロジック アプリとテナントのワークフローは、Azure Logic Apps ランタイムと同じプロセスで実行されるため、同じリソースを共有し、パフォーマンスが向上します。

  • Visual Studio Code 開発環境を使用してローカルにワークフローを作成、実行、テストできます。

    準備ができたら、シングルテナントの Azure Logic Apps 環境または App Service Environment v3 (Windows ベースの App Service プランのみ) でワークフローを実行できる Azure にロジック アプリをデプロイできます。 また、Azure Logic Apps のコンテナー化されたランタイムにより、Azure、Azure Kubernetes Service、オンプレミス、その他のクラウド プロバイダーなど、Kubernetes を実行できる任意の場所にワークフローをデプロイして実行することもできます。

    Note

    Kubernetes クラスターへのロジック アプリのデプロイは、現在パブリック プレビュー段階です。

    シングルテナントの Azure Logic Apps の詳細については、「Azure Logic Apps でのシングルテナントとマルチテナント」を確認してください。

ワークフローの例はクラウドベースであり、ステップは 2 つだけですが、クラウド、オンプレミス、ハイブリッド環境全体でさまざまなアプリ、データ、サービス、システムを接続できる数百の操作からワークフローを作成できます。 このワークフローの例は、組み込みの要求トリガーから始まり、Office 365 Outlook アクションが続きます。 このトリガーは、ワークフローの呼び出し可能なエンドポイントを作成し、任意の呼び出し元からの受信 HTTPS 要求を待機します。 トリガーが要求を受信して起動すると、次のアクションは、トリガーから選択した出力と共に、指定したメール アドレスに電子メールを送信することで実行されます。

ヒント

Office 365 アカウントをお持ちでない場合は、電子メール アカウントからメッセージを送信できる他の使用可能なアクション (Outlook.com など) を使用できます。

代わりに Azure portal を使用してこのワークフローの例を作成するには、シングル テナントの Azure Logic Apps と Azure portal を使用して統合ワークフローを作成するに関するページの手順に従います。 どちらのオプションでも、同じ種類の環境でロジック アプリ ワークフローを開発、実行、デプロイする機能が提供されます。 ただし、Visual Studio Code を使用すると、ご使用の開発環境でワークフローを "ローカル" で開発、テスト、実行できます。

Visual Studio Code、ロジック アプリ プロジェクト、ワークフローを示すスクリーンショット。

作業を進めていくと、次の高レベルのタスクが完了します。

  • ロジッ ク アプリのプロジェクトと、空の "ステートフル" ワークフローを作成します。
  • トリガーとアクションを追加します。
  • ローカル環境で実行、テスト、デバッグを行い、実行履歴を確認します。
  • ファイアウォール アクセス用のドメイン名の詳細を検索します。
  • Azure にデプロイします。必要に応じて、Application Insights を有効にします。
  • Visual Studio Code と Azure portal で、デプロイされたロジック アプリを管理します。
  • ステートレス ワークフローの実行履歴を有効にします。
  • デプロイの後で、Application Insights を有効にするか開きます。

前提条件

アクセスと接続

  • Azure Logic Apps ランタイムでネイティブに実行される組み込みコネクタだけを使って、Standard ロジック アプリ プロジェクトをローカル環境でビルドして、ワークフローを実行することを計画している場合は、次の要件は必要ありません。 ただし、Visual Studio Code から Azure にプロジェクトを発行またはデプロイするため、グローバル Azure で実行されているマネージド コネクタを使うため、または Azure に既にデプロイされている Standard ロジック アプリのリソースとワークフローにアクセスするために、次の接続と Azure アカウント資格情報があることを確認してください。

    • 要件をダウンロードしたり、Visual Studio Code から Azure アカウントに接続したり、Visual Studio Code から Azure に発行したりするためのインターネットへのアクセス。

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

  • この記事のワークフローの例と同じものを作成するには、Microsoft の職場または学校アカウントを使用してサインインする Office 365 Outlook の電子メール アカウントが必要です。

    別の電子メール コネクタ (Outlook.com など) を選択した場合でも、例に従うことができ、全般的な手順は同じです。 ただし、オプションはいくつかの点で異なる場合があります。 たとえば、Outlook.com コネクタを使用する場合は、代わりに個人用 Microsoft アカウントを使用してサインインします。

ツール

  1. 無料の Visual Studio Code をダウンロードしてインストールします。

  2. Visual Studio Code のすべての Azure 拡張機能で Azure サインインとサブスクリプションのフィルター処理に単一の共通エクスペリエンスを使用できるよう、Visual Studio Code 用の Azure Account 拡張機能をダウンロードしてインストールします。 このハウツー ガイドでは、このエクスペリエンスの使用手順について説明します。

  3. いずれかの方法を使って、お使いの特定のオペレーティング システム用の次の Visual Studio Code 依存関係をダウンロードしてインストールします。

    すべての依存関係を自動的にインストールする

    バージョン 2.81.5 以降の、Visual Studio Code 用 Azure Logic Apps (Standard) 拡張機能には、必要なすべての依存関係を新しいバイナリ フォルダーに自動的にインストールし、既存の依存関係は変更しないでそのままにする、依存関係インストーラーが含まれています。 詳しくは、Visual Studio Code 用 Azure Logic Apps (Standard) 拡張機能を使用した、より簡単な作業の開始に関するページをご覧ください。

    この拡張機能には、次の依存関係が含まれています。

    依存関係 説明
    Visual Studio Code 用 C# F5 キーを使ってワークフローを実行する機能を有効にします。
    Azurite for Visual Studio Code ローカル開発環境でロジック アプリ プロジェクトの作業を行い、ワークフローを実行できるように、Visual Studio Code で使用するローカル データ ストアとエミュレーターを提供します。 Azurite を自動的に開始させたくない場合は、このオプションを無効にできます。

    1. [ファイル] メニューで、[ユーザー設定]>[設定] を選びます。

    2. [ユーザー] タブで、[拡張機能]>[Azure Logic Apps (Standard)] を選びます。

    3. [zure Logic Apps Standard: Auto Start Azurite] という名前の設定を見つけて、オンになっているチェック ボックスをオフにします。
    .NET SDK 6.x.x Azure Logic Apps (Standard) ランタイムの前提条件である .NET Runtime 6.x.x が含まれています。
    Azure Functions Core Tools - 4.x バージョン お使いのオペレーティング システムに基づくバージョンをインストールします (Windows、macOS、Linux)。

    これらのツールには、Azure Functions ランタイムで利用されるものと同じランタイムのバージョンが含まれており、それは Azure Logic Apps (Standard) 拡張機能によって Visual Studio Code で使用されます。
    Node.js バージョン 16.x.x (より新しいバージョンが既にインストールされていない場合) JavaScript を実行するインライン コード操作アクションを有効にするために必要です。

    インストーラーでは、次のタスクは実行されません。

    • 必要な依存関係が既に存在するかどうかを調べる。
    • 足りない依存関係のみをインストールする。
    • 既存の依存関係の以前のバージョンを更新する。

    1. Visual Studio Code 用の Azure Logic Apps (Standard) 拡張機能をダウンロードしてインストールします (バージョン 2.81.5 以降)。

    2. Visual Studio Code のアクティビティ バーで、[拡張機能] を選びます。 (キーボード: Ctrl + Shift + X キーを押します)

    3. [拡張機能] ペインで、省略記号 ([...]) メニューを開き、[VSIX からのインストール] を選びます。

    4. ダウンロードした VSIX ファイルを見つけて選びます。

      セットアップが完了すると、拡張機能は自動的にアクティブ化して、[依存関係バイナリの検証とインストール] コマンドを実行します。 プロセス ログを見るには、[出力] ウィンドウを開きます。

    5. 次のプロンプトが表示されたら、[はい (推奨)] を選んで、必要な依存関係を自動的にインストールすることを確認します。

      依存関係を自動的にインストールするためのプロンプトを示すスクリーンショット。

    6. 必要な場合は、Visual Studio Code を再度読み込みます。

    7. 次のフォルダーに依存関係が正しく表示されることを確認します。

      C:\Users\<<自分のユーザー名>>\.azurelogicapps\dependencies\<<依存関係の名前>>

    8. Visual Studio Code で次の拡張機能の設定を確認します。

      1. [ファイル] メニューで、[ユーザー設定]>[設定] を選びます。

      2. [ユーザー] タブで、[拡張機能]>[Azure Logic Apps (Standard)] を選びます。

      3. 以下の設定を確認します。

        拡張機能の設定 Value
        依存関係のパス C:\Users\<<ユーザー名>>\.azurelogicapps\dependencies
        依存関係のタイムアウト 60 秒
        Dotnet バイナリのパス C:\Users\<<ユーザー名>>\.azurelogicapps\dependencies\DotNetSDK\dotnet.exe
        Func Core Tools バイナリのパス C:\Users\<<ユーザー名>>\.azurelogicapps\dependencies\FuncCoreTools\func
        Node JS バイナリのパス C:\Users\<<ユーザー名>>\.azurelogicapps\dependencies\NodeJs\node
        Azurite の自動開始 Enabled
        デザイン時の自動開始 Enabled

    9. .vscode/tasks.json ファイルにカスタム定義タスクが格納されている既存のロジック アプリ プロジェクトがある場合は、プロジェクトを開く前に、tasks.json ファイルを必ず別の場所に保存してください。

      プロジェクトを開くと、必要な依存関係を使うように tasks.json ファイルを更新するよう求められます。 続行を選ぶと、拡張機能によって tasks.json ファイルが上書きされます。

    10. ロジック アプリ プロジェクトを開くと、次の通知が表示されます。

      通知 アクション
      起動時に常にバックグラウンドのデザイン時プロセスを開始しますか? ワークフロー デザイナーをより速く開くには、[はい (推奨)] を選びます。
      プロジェクトの起動時に自動開始するように Azurite を構成しますか? プロジェクトを開いたら Azurite ストレージが自動的に開始するようにするには、[自動開始を有効にする] を選びます。 Visual Studio Code の上部に表示されるコマンド ウィンドウで、Enter キーを押して既定のパスをそのまま使います。

      C\Users\<<ユーザー名>>\.azurelogicapps\.azurite

    プレビューでの既知の問題

    • .NET Core SDK のどのバージョンも含まれないコンピューターに、すべての依存関係を自動的にインストールすることを選んだ場合は、次のメッセージが表示されます。

      ".NET Core SDK が見つかりません: dotnet 実行中のエラー -- info: エラー: コマンドが失敗しました: dotnet --info 'dotnet' が、内部または外部コマンド、操作可能プログラム、またはバッチ ファイルとして認識されません。 'dotnet' が、内部または外部コマンド、操作可能プログラム、またはバッチ ファイルとして認識されません。 .NET Core のデバッグは有効になりません。 .NET Core SDK がインストールされ、パス上にあることを確認してください。"

      拡張機能がアクティブになる時点で .NET Core フレームワークがまだインストール中であるため、このメッセージが表示されます。 このメッセージは無効にしても問題ありません。

      既存のロジック アプリ プロジェクトを開くとき、または func host start のデバッグ タスク (tasks.json) を開始するときに問題が発生し、このメッセージが表示される場合は、次の手順のようにして問題を解決してください。

      1. dotnet バイナリのパスを環境変数 PATH に追加します。

        1. Windows タスク バーの検索ボックスに「環境変数」と入力し、[システム環境変数の編集] を選びます。

        2. [システムのプロパティ] ボックスの [詳細設定] タブで、[環境変数] を選びます。

        3. [環境変数] ボックスの [<ユーザー名> のユーザー変数] の一覧で [PATH] を選んでから、[編集] を選びます。

        4. 一覧に次の値が表示されない場合は、[新規] を選んで次の値を追加します。

          C:\Users\<ユーザー名>\.azurelogicapps\dependencies\DotNetSDK

        5. 終了したら、 [OK] を選択します。

      2. Visual Studio Code のすべてのウィンドウを閉じて、プロジェクトを開き直します。

    • バイナリ依存関係のインストールと検証に、次のような問題がある場合:

      • Linux のアクセス許可に関する問題
      • 次のエラーが発生します: <ファイルまたはパス> が存在しません
      • <依存関係名> で検証が停止します。

      次の手順のようにして、[バイナリ依存関係を検証してインストールする] コマンドをもう一度実行します。

      1. [表示] メニューで [コマンド パレット] を選択します。

      2. コマンド ウィンドウが表示されたら、[バイナリ依存関係を検証してインストールする] コマンドを入力して実行します。

    • .NET Core 7 以降のバージョンがインストールされていない場合に、Azure Functions プロジェクトを含む Azure Logic Apps ワークスペースを開くと、次のメッセージが表示されます。

      プロジェクト [関数名].csproj の読み込み中に問題が発生しました。 詳細については、ログを参照してください。

      この足りないコンポーネントは Azure Functions プロジェクトに影響しないため、このメッセージは無視しても問題ありません。

    各依存関係を個別にインストールする

    依存関係 説明
    .NET SDK 6.x.x Azure Logic Apps (Standard) ランタイムの前提条件である .NET Runtime 6.x.x が含まれています。
    Azure Functions Core Tools - 4.x バージョン - Windows: Microsoft インストーラー (MSI) バージョン (func-cli-X.X.XXXX-x*.msi) を使用。
    - macOS
    - Linux

    これらのツールには、Azure Functions ランタイムで利用されるものと同じランタイムのバージョンが含まれており、それは Azure Logic Apps (Standard) 拡張機能によって Visual Studio Code で使用されます。

    これらのバージョンより古いバージョンをインストールしている場合は、最初にそのバージョンをアンインストールするか、ダウンロードしてインストールしたバージョンが PATH 環境変数で参照されていることを確認します。
    Node.js バージョン 16.x.x (より新しいバージョンが既にインストールされていない場合) JavaScript を実行するインライン コード操作アクションを有効にするために必要です。

    注: Windows の場合は、MSI バージョンをダウンロードします。 代わりに ZIP バージョンを使用する場合は、オペレーティング システムの PATH 環境変数を使用して、手動で Node.js を使用できるようにする必要があります。

  4. すべての依存関係を自動的にインストールする Azure Logic Apps (Standard) 拡張機能のバージョンを既にインストールしている場合は (プレビュー)、このステップをスキップします。 そうでない場合は、Visual Studio Code 用の Azure Logic Apps (Standard) 拡張機能をダウンロードしてインストールします。

    1. Visual Studio Code の左側のツールバーで、 [拡張機能] を選択します。

    2. 拡張機能の検索ボックスに「azure logic apps standard」と入力します。 結果リストから、[Azure Logic Apps (Standard)] > [インストール] の順に選択します。

      インストールが完了すると、拡張機能は [拡張機能: インストール済み] リストに表示されます。

      Visual Studio Code (Standard) 拡張機能がインストールされた Azure Logic Apps を示すスクリーンショット。

      ヒント

      インストール済みの一覧に拡張機能が表示されない場合は、Visual Studio Code を再起動してみてください。

    現在は、従量課金 (マルチテナント) と Standard (シングルテナント) の両方の拡張機能を同時にインストールできます。 開発エクスペリエンスはいくつかの点で互いに異なっていますが、Azure サブスクリプションには Standard と従量課金の両方のロジック アプリの種類を含めることができます。 Visual Studio Code の Azure ウィンドウには、Azure サブスクリプション内の Azure にデプロイおよびホストされているロジック アプリがすべて表示されますが、アプリは次の方法で整理されています。

    • [ロジック アプリ (従量課金)] セクション: サブスクリプション内のすべての従量課金ロジック アプリ。

    • [リソース] セクション: サブスクリプション内のすべての Standard ロジック アプリ。 以前は、このロジック アプリは [Logic Apps (Standard)] (ロジック アプリ (Standard)) セクションに表示されていましたが、現在は [リソース] セクションに移動しています。

  5. 組み込みの HTTP Webhook トリガーなど、Webhook ベースのトリガーとアクションを Visual Studio Code でローカルに実行するには、コールバック URL への転送を設定する必要があります。

  6. Application Insights の使用をサポートする設定でロジック アプリ リソースを作成する場合は、必要に応じて、ロジック アプリ リソースの診断ログとトレースを有効にできます。 ロジック アプリを作成するとき、またはデプロイの後に、それを行うことができます。 Application Insights のインスタンスを用意する必要がありますが、このリソースは、事前に、ロジック アプリを作成するときに、またはデプロイの後で、作成することができます。

  7. HTTP 要求を送信してソリューションをテストできる次のようなツールをインストールまたは使用します。

    注意事項

    資格情報、シークレット、アクセス トークン、API キーなどの機密データがあるシナリオでは、必要なセキュリティ機能でデータを保護したうえで、ツールは必ずオフラインまたはローカルで動作し、データをクラウドに同期せず、オンライン アカウントにサインインする必要がないものを使用してください。 このようにすることで、機密データを一般に公開するリスクを軽減できます。

Visual Studio Code を設定する

  1. すべての拡張機能が正しくインストールされていることを確認するには、Visual Studio Code を再読み込みまたは再起動します。

  2. すべての拡張機能が最新の更新プログラムを取得できるように、Visual Studio Code によって拡張機能の更新プログラムが自動的に検出されてインストールされるようになっていることを確認します。 このようにしないと、古いバージョンのアンインストールと最新バージョンのインストールを、手動で行う必要があります。

    1. [ファイル] メニューで、[基本設定] > [設定] の順に選択します。

    2. [ユーザー] タブで、[機能] > [拡張機能] の順に選択します。

    3. [更新プログラムの自動チェック]が選ばれていること、および [自動更新] が [すべての拡張機能] に設定されていることを確認します。

  3. Azure Logic Apps (Standard) 拡張機能の Azure Logic Apps Standard: プロジェクト ランタイム設定が、バージョン 4 以下に設定されていることを確認します。

    注意

    インライン コード操作アクションを使用するには、このバージョンが必要です。

    1. [ファイル] メニューで、[基本設定] > [設定] の順に選択します。

    2. [ユーザー] タブ > [拡張機能] > [Azure Logic Apps (Standard)] の順に選択します。

      たとえば、ここで [Azure Logic Apps Standard: Project Runtime](Azure Logic Apps Standard: プロジェクト ランタイム) の設定を見つけることも、検索ボックスを使用して他の設定を見つけることもできます。

      Azure Logic Apps (Standard) 拡張機能の Visual Studio Code 設定を示すスクリーンショット。

Azure アカウントに接続する

  1. Visual Studio Code のアクティビティ バーで、Azure アイコンを選択します。

    Visual Studio Code のアクティビティ バーと、選択された Azure アイコンを示すスクリーンショット。

  2. Azure ウィンドウで [リソース] の [Sign in to Azure] (Azure にサインインする) を選びます。 Visual Studio Code 認証ページが表示されたら、Azure アカウントでサインインします。

    Azure ウィンドウと、選択された Azure へのサインイン リンクを示すスクリーンショット。

    サインインすると、Azure ウィンドウには Azure アカウントに関連付けられた Azure サブスクリプションが表示されます。 期待されるサブスクリプションが表示されない場合、または特定のサブスクリプションのみが表示されるようにする場合は、次の手順を実行します。

    1. サブスクリプションの一覧で、最初のサブスクリプションの横にあるポインターを、 [サブスクリプションの選択] ボタン (フィルター アイコン) が表示されるまで移動します。 フィルター アイコンを選択します。

      サブスクリプションが表示された Azure ウィンドウと、選択されたフィルター アイコンを示すスクリーンショット。

      または、Visual Studio Code のステータス バーで Azure アカウントを選択します。

    2. 別のサブスクリプションの一覧が表示されたら、目的のサブスクリプションを選択し、 [OK] を必ず選択してください。

ローカル プロジェクトを作成する

ロジック アプリを作成する前に、Visual Studio Code からロジック アプリを管理、実行、およびデプロイできるように、ローカル プロジェクトを作成します。 基になるプロジェクトは、Azure Functions プロジェクト (関数アプリ プロジェクトとも呼ばれます) に似ています。 ただし、これらの種類のプロジェクトは相互に分離されているので、ロジック アプリと関数アプリを同じプロジェクトで使用することはできません。

  1. コンピューター上に、Visual Studio Code で後で作成するプロジェクトに使用する "空の" ローカル フォルダーを作成します。

  2. Visual Studio Code で、開いているすべてのフォルダーを閉じます。

  3. Azure ウィンドウの ワークスペース セクション ツール バーの Azure Logic Apps メニューから、新しいプロジェクトの作成 を選択します。

    スクリーンショットには、[新規プロジェクトの作成] が選択された状態で、Azure ウィンドウと ワークスペースツール バー、およびAzure Logic Appsメニューが表示されます。

  4. Windows Defender ファイアウォールによって Code.exe (Visual Studio Code) および func.exe (Azure Functions Core Tools) にネットワーク アクセスを許可するように求められた場合は、[プライベート ネットワーク (ホーム ネットワークや社内ネットワークなど)] > [アクセスを許可] の順に選択します。

  5. プロジェクト フォルダーを作成した場所を参照し、そのフォルダーを選択して続行します。

    [フォルダーの選択] ボックスと、[選択] ボタンが選択された新しいプロジェクト フォルダーを示すスクリーンショット。

  6. 表示されたテンプレートの一覧で、 [ステートフル ワークフロー] または [ステートレス ワークフロー] を選択します。 この例では [ステートフル ワークフロー] を選択します。

    [ステートフル ワークフロー] が選択されたワークフロー テンプレート一覧を示すスクリーンショット。

  7. ワークフローの名前を指定して、Enter キーを押します。 この例では、名前として Stateful-Workflow を使っています。

    [新しいステートフル ワークフローの作成 (3/4)] ボックスと

    注意

    エラー メッセージ "Unable to write to Workspace Settings because azureFunctions.suppressProject is not a registered configuration (azureFunctions.suppressProject は登録済みの構成ではないため、ワークスペース設定に書き込むことができません)" というエラー メッセージが表示される azureLogicAppsStandard.createNewProject という名前のエラーが発生する場合があります。 その場合は、Visual Studio Marketplace から直接、または Visual Studio Code 内から Visual Studio Code 用 Azure Functions 拡張機能をインストールしてみてください。

  8. Visual Studio Code で現在の Visual Studio Code または新しい Visual Studio Code ウィンドウでプロジェクトを開くように求められた場合は、[Open in current window] (現在のウィンドウで開く) を選びます。 それ以外の場合は、[新しいウィンドウで開く] を選びます。

    Visual Studio Code によってプロジェクトの作成が完了します。

  9. Visual Studio のアクティビティ バーで、[エクスプローラー] ペインを開きます (まだ開いていない場合)。

    [エクスプローラー] ペインにプロジェクトが表示されます。そこには、自動的に生成されたプロジェクト ファイルが含まれています。 たとえば、プロジェクトには、ワークフローの名前を示すフォルダーがあります。 このフォルダーにある workflow.json ファイルには、ワークフローの基になる JSON 定義が含まれています。

    プロジェクト フォルダー、ワークフロー フォルダー、

    Visual Studio Code では、ロジック アプリ プロジェクトには次のいずれかの種類があります。

    • 拡張バンドルベース (Node.js) (既定の種類)
    • NuGet パッケージベース (.NET) (既定の種類から変換できます)

    これらの種類に基づき、プロジェクトにはわずかに異なるフォルダーとファイルが含まれています。 NuGet ベースのプロジェクトには、パッケージや他のライブラリ ファイルが入った .bin フォルダーが含まれています。 バンドルベースのプロジェクトには、.bin フォルダーと他のファイルは含まれていません。 シナリオによっては、カスタムの組み込み操作を開発して実行する場合などに、アプリを実行するために NuGet ベースのプロジェクトが必要です。 NuGet を使用するようにプロジェクトを変換する方法の詳細については、「組み込みコネクタの作成を有効にする」を参照してください。

    既定のバンドルベースのプロジェクトの場合、プロジェクトのフォルダーとファイルの構造は次の例のようになります。

    MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
  || Maps 
     ||| MapName1
     ||| ...
  || Schemas
     ||| SchemaName1
     ||| ...
| WorkflowName1
  || workflow.json
  || ...
| WorkflowName2
  || workflow.json
  || ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json

    プロジェクトのルート レベルでは、他の項目を含む次のファイルとフォルダーを確認できます。

    Name フォルダーまたはファイル Description
    .vscode Folder Visual Studio Code 関連の設定ファイル (extensions.json、launch.json、settings.json、tasks.json ファイルなど) が含まれています。
    アイテム Folder 企業間 (B2B) シナリオをサポートするワークフローで定義および使用する統合アカウント成果物が含まれています。 たとえば、この構造の例には、XML 変換と検証の操作のマップとスキーマが含まれます。
    <WorkflowName> フォルダー ワークフローごとに、<<> フォルダーに、ワークフローの基礎になっている JSON 定義が入った > ファイルが含まれています。
    workflow-designtime Folder 開発環境関連の設定ファイルが含まれています。
    .funcignore ファイル インストールされている Azure Functions Core Tools に関連する情報が含まれています。
    connections.json ファイル ワークフローで使用されるマネージド接続と Azure 関数のメタデータ、エンドポイント、キーが含まれています。

    重要: 環境ごとに異なる接続と関数を使用するには、必ずこの connections.json ファイルをパラメーター化し、エンドポイントを更新してください。
    host.json ファイル ランタイム固有の構成設定と値が含まれます。たとえば、シングルテナント Azure Logic Apps プラットフォーム、ロジック アプリ、ワークフロー、トリガー、アクションの既定の制限などです。 ロジック アプリ プロジェクトのルート レベルでは、host.json メタデータ ファイルに、同じロジック アプリ内の "すべてのワークフロー" で実行中 (ローカルか Azure 内かを問わず) に使用される構成設定と既定値が含まれています。

    注: ロジック アプリを作成すると、Visual Studio Code コンテナーによってストレージ コンテナーにバックアップ host.snapshot.*.json ファイルが作成されます。 ロジック アプリを削除した場合、このバックアップ ファイルは削除されません。 同じ名前の別のロジック アプリを作成すると、別のスナップショット ファイルが作成されます。 同じロジック アプリに対して作成できるスナップショットは最大 10 件です。 この制限を超えると、次のエラーが表示されます。

    Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))

    このエラーを解決するには、ストレージ コンテナーから追加のスナップショット ファイルを削除します。
    local.settings.json ファイル ローカルでの実行中にワークフローで使用されるアプリ設定、接続文字列、その他の設定が含まれています。 つまり、これらの設定と値は、ローカル開発環境でプロジェクトを実行する場合に "のみ" 適用されます。 Azure へのデプロイ中は、このファイルと設定は無視され、デプロイには含まれません。

    このファイルには、設定と値が、ローカル開発ツールによって appSettings 値として使用される "ローカル環境変数" として格納されます。 これらの環境変数は、実行時とデプロイ時の両方で、"アプリ設定" と "パラメーター" を使用して呼び出して参照できます。

    重要: local.settings.json ファイルにはシークレットが含まれる場合があるため、必ずこのファイルもプロジェクトのソース管理から除外してください。

    Note

    FUNCTIONS_WORKER_RUNTIME アプリの設定は Standard ロジック アプリに必須であり、値は以前は node に設定されていました。 しかし、すべての新規および既存の展開済み Standard ロジック アプリに対して、必要な値は dotnet になりました。 この値の変更はワークフローのランタイムには影響しないため、すべてが以前と同じように動作するはずです。 詳細については、FUNCTIONS_WORKER_RUNTIME アプリの設定を参照してください。

    APP_KIND アプリの設定は Standard ロジック アプリに必須であり、値は workflowApp である必要があります。 しかし、Azure Resource Manager テンプレートを使用した自動化や、この設定が含まれていないその他のシナリオなどが原因で、一部のシナリオにはこのアプリ設定が欠落していることがあります。 JavaScript コードの実行アクションなどの特定のアクションが機能しないか、ワークフローが動作を停止する場合は、APP_KIND アプリ設定が存在していて、workflowApp に設定されていることを確認してください。 詳細については、APP_KIND アプリ設定に関するページを参照してください。

プロジェクトを NuGet パッケージ ベース (.NET) に変換する

既定で、Visual Studio Code では、NuGet パッケージ ベース (.NET) ではなく、拡張バンドル ベース (Node.js) のロジック アプリ プロジェクトが作成されます。 たとえば、組み込みコネクタの作成を可能にするため、NuGet パッケージ ベース (.NET) のロジック アプリ プロジェクトが必要な場合は、プロジェクトを拡張バンドル ベース (Node.js) から NuGet パッケージベース (.NET) に変換する必要があります。

重要

この操作は一方向の操作であり、元に戻すことはできません。

  1. [エクスプローラー] ペインのプロジェクトのルートで、他のすべてのファイルとフォルダーの下にある空白の領域の上にマウス ポインターを移動し、ショートカット メニューを開いて、[NuGet ベースのロジック アプリ プロジェクトに変換] を選びます。

    プロジェクト ウィンドウの空白の領域からプロジェクト ショートカット メニューを開いた [エクスプローラー] ペインを示すスクリーンショット。

  2. プロンプトが表示されたら、プロジェクトの変換を確認します。

組み込みコネクタの作成を有効にする

シングルテナント Azure Logic Apps 機能拡張フレームワークを使用して、必要なサービス用の独自の組み込みコネクタを作成できます。 Azure Service Bus や SQL Server などの組み込みコネクタと同様に、これらのコネクタは、より高いスループット、短い待機時間、ローカル接続を実現し、シングルテナントの Azure Logic Apps ランタイムと同じプロセスでネイティブに実行されます。

作成機能は現在 Visual Studio Code でのみ使用できますが、既定では有効になっていません。 これらのコネクタを作成するには、次の手順に従います。

  1. まだプロジェクトを拡張バンドル ベース (Node.js) から NuGet パッケージ ベース (.NET) に変換していない場合は、変換します。

  2. 記事「あらゆる場所で実行される Azure Logic Apps - 組み込みコネクタの拡張性」の手順を確認して実行してください。

カスタム成果物をプロジェクトに追加する

ロジック アプリ ワークフローでは、一部のコネクタは、マップ、スキーマ、アセンブリなどの成果物に依存しています。 Visual Studio Code では、これらの成果物をロジック アプリ プロジェクトにアップロードできます。これは、Azure portal で [成果物] の下にあるロジック アプリ リソース メニューを使用して、これらの成果物をアップロードする方法と同様です。次に例を示します。

[成果物] セクションがハイライトされた Azure portal と Standard ロジック アプリ リソース メニューのスクリーンショット。

プロジェクトにマップを追加する

プロジェクトにマップを追加するには、プロジェクト階層で [成果物]>[マップ] を展開します。これは、マップを配置できるフォルダーです。

[成果物] フォルダーと [マップ] フォルダーが展開された Visual Studio Code プロジェクト階層のスクリーンショット。

プロジェクトにスキーマを追加する

プロジェクトにスキーマを追加するには、プロジェクト階層で [成果物]>[スキーマ] を展開します。これは、スキーマを配置できるフォルダーです。

[成果物] フォルダーと [スキーマ] フォルダーが展開された Visual Studio Code プロジェクト階層のスクリーンショット。

プロジェクトにアセンブリを追加する

Standard ロジック アプリでは、Visual Studio Code でプロジェクトにアップロードできる、特定の種類のアセンブリを使用または参照できます。 ただし、それらをプロジェクトの特定のフォルダーに追加する必要があります。 次の表に、各アセンブリの種類と、それらをプロジェクトに配置するための正確な場所について詳しく説明します。

アセンブリの種類 説明
クライアント/SDK アセンブリ (.NET Framework) このアセンブリの種類では、.NET Framework 用のクライアント SDK とカスタム SDK のストレージとデプロイが提供されます。 たとえば、SAP 組み込みコネクタでは、これらのアセンブリを使用して、SAP NCo 非再頒布可能 DLL ファイルが読み込まれます。

これらのアセンブリは次のフォルダーに追加してください。\lib\builtinOperationSdks\net472
クライアント/SDK アセンブリ (Java) このアセンブリの種類では、Java 用のカスタム SDK のストレージとデプロイが提供されます。 たとえば、JDBC 組み込みコネクタは、これらの JAR ファイルを使用して、カスタム リレーショナル データベース (RDB) 用の JDBC ドライバーを見つけます。

これらのアセンブリは次のフォルダーに追加してください。\lib\builtinOperationSdks\JAR
カスタム アセンブリ (.NET Framework) このアセンブリの種類では、カスタム DLL のストレージとデプロイが提供されます。 たとえば、XML 変換操作は、XML 変換中に必要なカスタム変換関数のためにこれらのアセンブリを使用します。

これらのアセンブリは次のフォルダーに追加してください。\lib\custom\net472

次の図は、プロジェクト内で各種類のアセンブリを配置する場所を示しています。

Visual Studio Code、ロジック アプリ プロジェクト、アセンブリをアップロードする場所のスクリーンショット。

Azure portal でロジック アプリ リソースにアセンブリをアップロードする方法の詳細については、「参照先アセンブリを追加する」を参照してください。

"lib\*" アセンブリを使用するために NuGet ベースのプロジェクトを移行する

重要

このタスクは、NuGet ベースのロジック アプリ プロジェクトにのみ必要です。

Standard ロジック アプリ ワークフローでアセンブリ サポートが利用できなかったときにロジック アプリ プロジェクトを作成した場合は、<project-name>.csproj ファイルに次の行を追加して、アセンブリを使用するプロジェクトを操作できます。

  <ItemGroup>
    <LibDirectory Include="$(MSBuildProjectDirectory)\lib\**\*"/>
  </ItemGroup>
  <Target Name="CopyDynamicLibraries" AfterTargets="_GenerateFunctionsExtensionsMetadataPostPublish">
    <Copy SourceFiles="@(LibDirectory)" DestinationFiles="@(LibDirectory->'$(MSBuildProjectDirectory)\$(PublishUrl)\lib\%(RecursiveDir)%(Filename)%(Extension)')"/>
  </Target>

重要

Linux または MacOS で実行されるプロジェクトの場合は、必ずディレクトリ区切り記号を変更してください。 例として、<project-name>.csproj ファイルに追加された前のコードを示す次の図を参照してください。

移行されたアセンブリと CSPROJ ファイルに追加されたコードのスクリーンショット。

デザイナーでワークフロー定義ファイルを開く

  1. ワークフローのプロジェクト フォルダー (この例では Stateful-Workflow という名前) を展開し、workflow.json ファイルを開きます。

  2. workflow.json ファイルのショートカット メニューを開き、[デザイナーを開く] を選びます。

    [エクスプローラー] ペイン、workflow.json ファイルのショートカット メニュー、選択された [デザイナーを開く] を示すスクリーンショット。

  3. [Enable connectors in Azure] (Azure でコネクタを有効にする) リストが開いたら、[Use connectors from Azure] (Azure のコネクタを使用する) を選びます。これは、Azure でホストされ、実行されるすべてのマネージド (つまり "共有") コネクタに適用されます。これに対し、組み込みまたはネイティブの (つまり "アプリ内") コネクタは、Azure Logic Apps ランタイムで直接実行されます。

    [エクスプローラー] ペインのスクリーンショット。[Enable connectors in Azure] (Azure でコネクタを有効にする) という一覧が開き、[Use connectors from Azure] (Azure のコネクタを使用する) オプションが選択されています。

    Note

    現在、ステートレス ワークフローでは、トリガーではなくマネージド コネクタからの "アクション" のみをサポートしています。 ステートレスなワークフローにおいて Azure のコネクタを有効にすることもできますが、デザイナーには選択できるマネージド コネクタ トリガーは表示されません。

  4. [サブスクリプションの選択] リストが開いたら、ロジック アプリ プロジェクトに使う Azure サブスクリプションを選びます。

    [サブスクリプションの選択] という一覧が表示され、サブスクリプションが選択されている [エクスプローラー] ペインを示すスクリーンショット。

  5. リソース グループ一覧が開いたら、[新しいリソース グループの作成] を選びます。

    リソース グループ一覧が表示され、[新しいリソース グループの作成] オプションが選択されている [エクスプローラー] ペインを示すスクリーンショット。

  6. リソース グループの名前を指定し、Enter キーを押します。 この例では、Fabrikam-Workflows-RG を使用します。

    [エクスプローラー] ペインとリソース グループ名のボックスを示すスクリーンショット。

  7. 場所の一覧で、リソース グループとリソースの作成に使用する Azure リージョンを選択します。 この例では、 [米国中西部] を使用します。

    エクスプローラー ウィンドウと場所の一覧が表示され、[米国中西部] が選択されているスクリーンショット。

    このステップを実行すると、Visual Studio Code のワークフロー デザイナーが開きます。

    注意

    Visual Studio Code でワークフロー デザイン時 API が開始されると、起動に数秒かかる場合があるというメッセージが表示されことがあります。 このメッセージは無視することも [OK] を選択することもできます。

    デザイナーが開かれない場合は、トラブルシューティングのセクションの「デザイナーが開けない」を確認してください。

    デザイナーが表示されると、デザイナーに [トリガーの追加] プロンプトが表示されます。

  8. デザイナーで [トリガーの追加] を選ぶと、[トリガーの追加] ペインと、選択できるトリガーがあるすべてのコネクタを示すギャラリーが開きます。

    ワークフロー デザイナー、選択された [トリガーの追加] というプロンプト、トリガーがあるコネクタのギャラリーを示すスクリーンショット。

  9. 次に、ワークフローにトリガーとアクションを追加します。

トリガーとアクションを追加する

デザイナーで空のワークフローを開くと、[トリガーの追加] プロンプトがデザイナーに表示されます。 トリガーとアクションを追加して、ワークフローの作成を開始できるようになりました。

重要

Webhook ベースのトリガーまたはアクションを使用するワークフローをローカル環境で実行するには (組み込みの HTTP Webhook トリガーやアクションなど)、Webhook のコールバック URL への転送を設定することで、この機能を有効にする必要があります。

この例のワークフローでは、次のトリガーとアクションを使います。

要求トリガーを追加する

  1. ワークフロー デザイナーの [トリガーの追加] ペインで、[ランタイム] ラストを開き、[アプリ内] を選びます。これで、使用できる組み込みコネクタ トリガーのみが表示されます。

  2. 検索ボックスを使って [HTTP 要求の受信時] という要求トリガーを検索し、そのトリガーをワークフローに追加します。 詳細については、トリガーとアクションを使ったワークフローの構築に関する記事を参照してください。

    ワークフロー デザイナー、[トリガーの追加] ペインを示すスクリーンショット。[HTTP 要求の受信時] というトリガーが選択されています。

    トリガーがデザイナーに表示されると、トリガーの情報ペインが開き、トリガーのパラメーター、設定などの関連するタスクが表示されます。

    [HTTP 要求の受信時] というトリガーの情報ペインを示すスクリーンショット。

    ヒント

    情報ウィンドウが表示されない場合は、デザイナーでトリガーが選択されていることを確認します。

  3. ワークフローを保存します。 デザイナーのツール バーで、 [保存] を選択します。

デザイナーから項目を削除する必要がある場合は、デザイナーからの項目の削除に関するこちらの手順のようにします。

Office 365 Outlook アクションを追加する

  1. デザイナーの [要求] トリガーで、プラス記号 (+) >[アクションの追加] を選びます。

  2. 開いた [アクションの追加] ペインの [ランタイム] リストから [共有] を選びます。これで、使用できるマネージド コネクタ アクションのみが表示されます。

  3. 検索ボックスを使って [メールの送信 (V2)] という Office 365 Outlook マネージド コネクタ アクションを検索し、そのアクションをワークフローに追加します。 詳細については、トリガーとアクションを使ったワークフローの構築に関する記事を参照してください。

    ワークフロー デザイナーと [アクションの追加] ペインを示すスクリーンショット。[メールの送信] という Office 365 Outlook アクションが選択されています。

  4. アクションの認証ペインが開いたら、[サインイン] を選んでメール アカウントへの接続を作成します。

    [メールの送信 (V2)] というアクションを示すスクリーンショット。[サインイン] ボタンが選択されています。

  5. 後続のプロンプトに従ってアカウントを選び、アクセスを許可して、Visual Studio Code に戻ることを許可します。

    Note

    プロンプトを完了するまでの時間が長すぎると、認証プロセスがタイムアウトして失敗します。 この場合は、デザイナーに戻り、サインインし直して接続を作成します。

    1. Microsoft のプロンプトが表示されたら、Office 365 Outlook のユーザー アカウントを選び、[アクセスを許可する] を選びます。

    2. Azure Logic Apps で Visual Studio Code リンクを開くように求められたら、[開く] を選びます。

      Visual Studio Code のリンクを開くプロンプトを示すスクリーンショット。

    3. Visual Studio Code で Microsoft Azure Tools を開くように求められたら、[開く] を選びます。

      Microsoft Azure Tools を開くプロンプトを示すスクリーンショット。

    ヒント

    関連付けられたプロンプトが表示されたときに、このようなプロンプトをスキップするには、次のオプションを選びます。

    • Visual Studio Code のリンクを開くアクセス許可: [Always allow logic-apis-westcentralus.consent.azure-apim.net to open links of this type in the associated app] (関連付けられたアプリでこの種類のリンクを開くときに logic-apis-westcentralus.consent.azure-apim.net を常に許可する) を選びます。 このドメインは、ロジック アプリ リソースに選んだ Azure リージョンに応じて変わります。

    • Microsoft Azure Tools を開くアクセス許可: [Don't ask again for this extension] (この拡張機能については今後このメッセージを表示しない) を選びます。

    Visual Studio Code で接続が作成されると、一部のコネクタでは、接続は {n} 日間のみ有効ですというメッセージが表示されます。 この制限時間は、Visual Studio Code でロジック アプリ ワークフローを作成している期間にのみ適用されます。 デプロイ後は、自動的に有効にされるシステム割り当てマネージド ID を使って実行時にワークフローを認証できるため、この制限は適用されなくなります。 このマネージド ID は、接続の作成時に使用する認証資格情報または接続文字列とは異なります。 このシステム割り当てマネージド ID を無効にした場合、接続は実行時に機能しません。

  6. デザイナーで [メールの送信] アクションが選択されていない場合は、そのアクションを選択します。

  7. アクション情報ペインの [パラメーター] タブで、アクションに必要な情報を指定します。次に例を示します。

    [メールの送信] という Office 365 Outlook アクションの情報を示すスクリーンショット。

    プロパティ 必要 値 説明
    To はい <your-email-address> 電子メールの受信者。テストのためにご自分のメール アドレスを指定できます。 この例では、架空のメール アドレス sophia.owen@fabrikam.com を使用しています。
    件名 はい サンプル ワークフローからの電子メール メールの件名
    本文 はい サンプル ワークフローからの挨拶 メールの本文の内容

    Note

    [テスト] タブで何か変更を加えた場合は、タブを切り替えたりデザイナーにフォーカスを移したりする前に、[保存] を選んでその変更をコミットしてください。 それ以外の場合、Visual Studio Code では変更が保持されません。

  8. ワークフローを保存します。 デザイナーで、 [保存] を選択します。

ローカルで実行されている Webhook を有効にする

Azure で実行されているロジック アプリ ワークフローで HTTP Webhook などの Webhook ベースのトリガーまたはアクションを使用するときは、Azure Logic Apps ランタイムにより、コールバック URL が生成されてサービス エンドポイントに登録されることにより、そのエンドポイントがサブスクライブされます。 その後、トリガーまたはアクションは、サービス エンドポイントで URL が呼び出されるまで待機します。 ただし、Visual Studio Code で作業している場合は、生成されたコールバック URL は http://localhost:7071/... で開始します。 この URL は localhost サーバー用であり、サービス エンドポイントでこの URL を呼び出すことができないようにプライベートです。

Visual Studio Code で Webhook ベースのトリガーとアクションをローカルに実行するには、localhost サーバーを公開し、サービス エンドポイントからの呼び出しを Webhook コールバック URL に安全に転送するパブリック URL を、設定する必要があります。 転送サービスと、localhost ポートへの HTTP トンネルが開かれる ngrok などのツールを使用することも、または独自の同等のツールを使用することもできます。

ngrok を使用して呼び出しの転送を設定する

  1. ngrok の Web サイトに移動します。 新しいアカウントにサインアップするか、アカウントが既にある場合はそれにサインインします。

  2. 個人用の認証トークンを取得します。これは、ngrok クライアントから、お使いのアカウントに接続してアクセスの認証を行う場合に必要です。

    1. 認証トークン ページを見つけるには、アカウントのダッシュボード メニューで、[認証] を展開して、[自分の認証トークン] を選びます。

    2. [Your Authtoken](自分の認証トークン) ボックスから安全な場所にトークンをコピーします。

  3. ngrok のダウンロード ページまたは自分のアカウントのダッシュボードから、目的の ngrok のバージョンをダウンロードし、.zip ファイルを抽出します。 詳細については、「手順 1: 解凍してインストールする」を参照してください。

  4. 自分のコンピューターで、コマンド プロンプト ツールを開きます。 ngrok.exe ファイルがある場所に移動します。

  5. 次のコマンドを実行して、ngrok クライアントを自分の ngrok アカウントに接続します。 詳細については、「手順 2: アカウントを接続する」を参照してください。

    ngrok authtoken <your_auth_token>

  6. 次のコマンドを実行して、localhost のポート 7071 への HTTP トンネルを開きます。 詳細については、「手順 3: 起動する」を参照してください。

    ngrok http 7071

  7. 出力から、次の行を見つけます。

    http://<domain>.ngrok.io -> http://localhost:7071

  8. http://<domain>.ngrok.io という形式になっている URL をコピーして保存します

アプリの設定で転送 URL を設定する

  1. Visual Studio Code のデザイナーで、使用する Webhook ベースのトリガーまたはアクションを追加します。

    この例では、HTTP + Webhook のトリガーを使用して続行します。

  2. ホスト エンドポイントの場所についてのプロンプトが表示されたら、前に作成した転送 (リダイレクト) URL を入力します。

    Note

    プロンプトを無視すると、転送 URL を指定する必要があることを示す警告が表示されます。その場合は、 [構成] を選択し、URL を入力します。 この手順を完了すると、後で追加する Webhook トリガーまたはアクションに対してプロンプトが表示されなくなります。

    プロンプトが表示されるようにするには、プロジェクトのルート レベルで local.settings.json ファイルのショートカット メニューを開き、[Configure Webhook Redirect Endpoint] (Webhook リダイレクト エンドポイントの構成) を選択します。 これでプロンプトが表示されるので、転送 URL を指定できるようになります。

    Visual Studio Code によって、転送 URL がプロジェクトのルート フォルダー内の local.settings.json ファイルに追加されます。 Values オブジェクトに Workflows.WebhookRedirectHostUri という名前のプロパティが表示されるようになり、転送 URL に設定されます。たとえば、次のようになります。

    {
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "FUNCTIONS_V2_COMPATIBILITY_MODE": "true",
      <...>
      "Workflows.WebhookRedirectHostUri": "http://xxxXXXXxxxXXX.ngrok.io",
      <...>
   }
}

    Note

    以前は、FUNCTIONS_WORKER_RUNTIME 設定の既定値は node でした。 現在、dotnet は、異なる値を持つアプリの場合でも、すべての新規および既存のデプロイ済み Standard ロジック アプリの既定値になります。 この変更はワークフローのランタイムには影響せず、すべてが以前と同じように動作するはずです。 詳細については、FUNCTIONS_WORKER_RUNTIME アプリの設定に関するページを参照してください。

初めてローカル デバッグ セッションを開始するとき、またはデバッグなしでワークフローを実行するときに、Azure Logic Apps ランタイムによってワークフローがサービス エンドポイントに登録され、そのエンドポイントで Webhook 操作の通知がサブスクライブされます。 次にワークフローが実行されるときには、サブスクリプションの登録がローカル ストレージに既に存在するため、ランタイムで登録または再登録は行われません。

ローカルに実行される Webhook ベースのトリガーまたはアクションを使用するワークフロー実行のデバッグ セッションを停止しても、既存のサブスクリプション登録は削除されません。 登録を解除するには、サブスクリプション登録を手動で除去または削除する必要があります。

Note

ワークフローの実行が開始された後、ターミナル ウィンドウに次の例のようなエラーが表示されることがあります。

message='Http request failed with unhandled exception of type 'InvalidOperationException' and message: 'System.InvalidOperationException: Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.'

この場合は、プロジェクトのルート フォルダーにある local.settings.json ファイルを開き、プロパティが true に設定されていることを確認します。

"FUNCTIONS_V2_COMPATIBILITY_MODE": "true"

デバッグ用のブレークポイントを管理する

デバッグ セッションを開始してロジック アプリのワークフローを実行およびテストする前に、各ワークフローの workflow.json ファイル内にブレークポイントを設定できます。 他の設定は必要ありません。

現時点では、ブレークポイントはアクションについてのみサポートされており、トリガーではサポートされていません。 各アクション定義には、次のブレークポイントの場所があります。

  • アクションの名前が記述されている行に、開始ブレークポイントを設定します。 デバッグ セッションの間にこのブレークポイントにヒットすると、アクションの入力を評価前に確認できます。

  • アクションの終了中かっこ ( } ) が記述されている行に、終了ブレークポイントを設定します。 デバッグ セッションの間にこのブレークポイントにヒットすると、アクションの実行が完了する前に、アクションの結果を確認できます。

ブレークポイントを追加するには、次の手順のようにします。

  1. デバッグするワークフローの workflow.json ファイルを開きます。

  2. ブレークポイントを設定する行で、左側の列の内側を選択します。 ブレークポイントを削除するには、そのブレークポイントを選択します。

    デバッグ セッションを開始すると、コード ウィンドウの左側に [実行] ビューが表示され、上部の近くに [デバッグ] ツール バーが表示されます。

    Note

    [実行] ビューが自動的に表示されない場合は、Ctrl + Shift + D キーを押します。

  3. ブレークポイントにヒットしたときに使用可能な情報を確認するには、[実行] ビューで、 [変数] ペインを調べます。

  4. ワークフローの実行を続けるには、[デバッグ] ツール バーの [続行] (再生ボタン) を選択します。

ブレークポイントは、ワークフローの実行中いつでも追加および削除できます。 ただし、実行の開始後に workflow.json ファイルを更新した場合、ブレークポイントは自動的に更新されません。 ブレークポイントを更新するには、ロジック アプリを再起動します。

一般的な情報については、Visual Studio Code のブレークポイントに関するページを参照してください。

ローカル環境で実行、テスト、デバッグする

ロジック アプリ ワークフローをテストするには、次の手順のようにして、デバッグ セッションを開始し、要求トリガーによって作成されたエンドポイントの URL を検索します。 この URL は、後でそのエンドポイントに要求を送信できるようにするために必要です。

  1. ステートレス ワークフローをより簡単にデバッグするには、そのワークフローの実行履歴を有効にすることができます。

  2. Azurite エミュレーターが既に動いている場合は、次のステップに進みます。 そうでない場合は、ワークフローを実行する前に必ずエミュレーターを開始してください。

    1. Visual Studio Code の [表示] メニューから [コマンド パレット] を選びます。

    2. コマンド パレットが表示されたら、「Azurite: Start」と入力します。

    Azurite のコマンドについて詳しくは、Visual Studio Code の Azurite 拡張機能のドキュメントをご覧ください。

  3. Visual Studio Code のアクティビティ バーで [実行] メニューを開き、 [デバッグの開始] (F5) を選択します。

    [ターミナル] ウィンドウが開き、デバッグ セッションを確認できます。

    Note

    "Error exists after running preLaunchTask 'generateDebugSymbols' (preLaunchTask 'generateDebugSymbols' の実行後にエラーがあります)" というエラーが発生する場合は、トラブルシューティング セクションの「デバッグ セッションが開始できない」を参照してください。

  4. 次に、要求トリガーでエンドポイントのコールバック URL を検索します。

    1. エクスプローラー ウィンドウを再度開き、プロジェクトを表示できるようにします。

    2. workflow.json ファイルのショートカット メニューから、 [概要] を選択します。

      [エクスプローラー] ペイン、workflow.json ファイルの [概要] オプションが選択されたショートカット メニューを示すスクリーンショット。

    3. [コールバック URL] の値を探します。これは、次の例の要求トリガーの URL のようになります。

      http://localhost:7071/api/<workflow-name>/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<shared-access-signature>

      コールバック URL が表示されたワークフローの概要ページを示すスクリーンショット。

    4. コールバック URL のプロパティ値をコピーして保存します。

  5. コールバック URL をテストしてワークフローをトリガーするには、HTTP 要求ツールとその手順を使用して、要求トリガーが想定するメソッドを含む HTTP 要求を URL に送信します。

    この例では、コピーした URL と共に GET メソッドを使用します。これは次のサンプルのようになります。

    GET http://localhost:7071/api/Stateful-Workflow/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<shared-access-signature>

    トリガーが発生すると、例のワークフローが実行され、次の例のようなメールが送信されます。

    例に記載されている Outlook のメールを示すスクリーンショット。

  6. Visual Studio Code で、ワークフローの [概要] ページに戻ります。

    ステートフルなワークフローを作成した場合、送信した要求がワークフローをトリガーすると、[概要] ページにワークフローの実行の状態と履歴が表示されます。

    ヒント

    実行の状態が表示されない場合は、 [更新] を選択して [概要] ページを更新してみてください。 条件が満たされなかったか、データが見つからなかったためにスキップされたトリガーに対しては、実行は行われません。

    ワークフローの [概要] ページに実行の状態と履歴が表示されているスクリーンショット

    次の表は、各ワークフローの実行で実行可能な最終的な状態を示し、Visual Studio Code に表示します。

    実行の状態 説明
    Aborted 外部に問題が発生したため、実行が停止したか、または完了しませんでした。たとえば、システムの停止や Azure サブスクリプションの中断などです。
    取り消し済み 実行がトリガーされ、開始されましたが、キャンセル要求を受け取りました。
    Failed 実行中に少なくとも 1 つのアクションが失敗しました。 ワークフローの後続のアクションは、エラーを処理するように設定されていません。
    実行中 実行がトリガーされ、進行中です。ただし、この状態は、アクション制限または現在の料金プランによって制限されている実行に対しても表示されます。

    ヒント:診断ログを設定すると、発生するスロットル イベントに関する情報を取得することができます。
    Succeeded 実行は成功しました。 いずれかのアクションが失敗した場合、ワークフロー内の後続のアクションによってそのエラーが処理されます。
    タイムアウト 現在の継続時間が実行継続時間の制限を超えたため、実行がタイムアウトしました。これは、[実行履歴の保持期間 (日数)] 設定によって制御されます。 実行の継続時間は、実行の開始時刻とその開始時刻での実行継続時間の制限を使用して計算されます。

    注:実行の継続時間が現在の "実行履歴の保持期間の制限" も超えている場合は、毎日のクリーンアップ ジョブによって実行履歴から実行が消去されます。これも、[実行履歴の保持期間 (日数)] 設定によって制御されます。 実行がタイムアウトしたか完了したかにかかわらず、保持期間は常に、実行の開始時刻と "現在の" 保持期間の制限を使用して計算されます。 そのため、処理中の実行の継続時間制限を短くすると、実行はタイムアウトします。ただし、実行が実行履歴に残るか消去されるかは、実行の継続時間が保持期間の制限を超えているかどうかに基づいて決まります。
    待機中 たとえば、その前のワークフロー インスタンスがまだ実行中である等の理由で、実行が開始されていないか、または一時停止しています。

  7. 特定の実行の各ステップの状態とそのステップの入出力を確認するには、その実行の省略記号 (...) ボタンを選び、[実行の表示] を選びます。

    ワークフローの実行履歴行に省略記号ボタンが表示され、[実行の表示] が選択されているスクリーンショット。

    Visual Studio Code で [モニター] ビューが開き、実行の各ステップの状態が表示されます。

    ワークフロー実行の各ステップとその状態を示すスクリーンショット。

    注意

    実行が失敗し、監視ビューのステップに 400 Bad Request エラーが表示される場合、この問題は、トリガー名かアクション名が長すぎて、基になる URI (Uniform Resource Identifier) が既定の文字制限を超えたことが原因の場合があります。 詳細については、「400 無効な要求です」を参照してください。

    次の表は、各ワークフロー アクションで実行可能な状態を示し、Visual Studio Code に表示します。

    アクションの状態 説明
    Aborted 外部に問題が発生したため、アクションが停止したか、または完了しませんでした。たとえば、システムの停止や Azure サブスクリプションの中断などです。
    取り消し済み アクションは実行中でしたが、取り消す要求を受け取りました。
    失敗 アクションに失敗しました。
    実行中 アクションは現在実行中です。
    Skipped 直前のアクションが失敗したため、アクションはスキップされました。 アクションには、現在のアクションを実行する前に、前のアクションが正常に完了している必要がある runAfter 条件が含まれています。
    Succeeded アクションに成功しました。
    再試行により成功 アクションは成功しましたが、1 回以上の再試行が行われました。 再試行履歴を確認するには、実行履歴の詳細ビューでその操作を選択し、入力と出力を表示します。
    タイムアウト アクションの設定によって指定されたタイムアウト制限により、アクションが停止しました。
    待機中 呼び出し元からの受信要求を待機している Webhook アクションに適用されます。

  8. 各ステップの入出力を確認するには、検査するステップを選択します。 そのステップの未加工の入出力をさらに確認するには、 [未加工入力の表示] または [未加工出力の表示] を選択します。

    ワークフローの各ステップの状態と、[メールの送信] という展開されたアクションの入力と出力を示すスクリーンショット。

  9. デバッグ セッションを停止するには、 [実行] メニューで、 [デバッグの停止] (Shift + F5) を選択します。

応答を返す

要求トリガーで始まるワークフローがある場合、応答という要求組み込みアクションを使うことで、ワークフローに要求を送った呼び出し元に応答を返すことができます。

  1. ワークフロー デザイナーの [メールの送信] アクションで、プラス記号 (+) >[アクションの追加] を選びます。

    [アクションの追加] ペインが開き、次のアクションを選択できます。

  2. [アクションの追加] ペインで [ランタイム] リストから [アプリ内] を選びます。 [応答] アクションを見つけて追加します。

    [応答] アクションがデザイナーに表示されると、アクションの詳細ウィンドウが自動的に開きます。

    ワークフロー デザイナーと [応答] 情報ペインを示すスクリーンショット。

  3. [パラメーター] タブで、呼び出す関数に必要な情報を指定します。

    この例では、Body パラメーター値を返します。これは [メールの送信] アクションからの出力です。

    1. Body パラメーターについては、編集ボックス内を選び、稲妻アイコンを選ぶと、動的コンテンツ一覧が表示されます。 この一覧には、ワークフロー内の前のトリガーとアクションから使用できる出力値が表示されます。

    2. 動的コンテンツ リストの [メールの送信] から [本文] を選択します。

      開いた動的コンテンツ一覧を示すスクリーンショット。[メールの送信] ヘッダーで Body の出力値が選択されています。

      完了すると、[応答] アクションの [本文] プロパティが、 [メールの送信] アクションの [本文] 出力値に設定されます。

      ワークフロー デザイナー、[応答] 情報ペインを示すスクリーンショット。[メールの送信] というアクションの Body パラメーターが Body 値に設定されています。

  4. デザイナーで、 [保存] を選択します。

ロジック アプリを再テストする

ロジック アプリを更新した後、Visual Studio でデバッガーを再実行し、更新したロジック アプリをトリガーする別の要求を送信することで、別のテストを実行できます。手順は「ローカル環境で実行、テスト、デバッグする」と同じです。

  1. Visual Studio Code のアクティビティ バーで [実行] メニューを開き、 [デバッグの開始] (F5) を選択します。

  2. Postman またはツールで要求を作成して送信するには、別の要求を送信してワークフローをトリガーします。

  3. ステートフルなワークフローを作成した場合は、ワークフローの [概要] ページで最新の実行の状態を確認します。 その実行の各ステップの状態、入力、出力を表示するには、その実行の省略記号 (...) ボタンを選び、[実行の表示] を選びます。

    例として、サンプル ワークフローが [応答] アクションを使用して更新された後の実行のステップ バイ ステップの状態を次に示します。

    更新されたワークフローの各ステップの状態と、展開された [応答] アクションの入力と出力を示すスクリーンショット。

  4. デバッグ セッションを停止するには、 [実行] メニューで、 [デバッグの停止] (Shift + F5) を選択します。

ファイアウォール アクセス用のドメイン名を検索する

ロジック アプリのワークフローをデプロイして Azure portal で実行する前に、環境内にトラフィックを制限する厳しいネットワーク要件またはファイアウォールがある場合は、ワークフロー内に存在するすべてのトリガーまたはアクション接続に対するアクセス許可を設定する必要があります。

これらの接続の完全修飾ドメイン名 (FQDN) を検索するには、次の手順を実行します。

  1. ロジック アプリ プロジェクトで、connections.js ファイル (最初の接続ベースのトリガーまたはアクションをワークフローに追加した後に作成されます) を開いて、managedApiConnections オブジェクトを検索します。

  2. 作成した接続ごとに、connectionRuntimeUrl プロパティ値をコピーし、安全な場所に保存して、この情報を使用してファイアウォールを設定できるようにします。

    この例の connections.js ファイルには、これらの connectionRuntimeUrl 値を含む 2 つの接続 (AS2 接続と Office 365 接続) が含まれています。

    • AS2: "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/as2/11d3fec26c87435a80737460c85f42ba

    • Office 365: "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/office365/668073340efe481192096ac27e7d467f

    {
   "managedApiConnections": {
      "as2": {
         "api": {
            "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/as2"
         },
         "connection": {
            "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group}/providers/Microsoft.Web/connections/{connection-resource-name}"
         },
         "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/as2/11d3fec26c87435a80737460c85f42ba,
         "authentication": {
            "type":"ManagedServiceIdentity"
         }
      },
      "office365": {
         "api": {
            "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region}/managedApis/office365"
         },
         "connection": {
            "id": "/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group}/providers/Microsoft.Web/connections/{connection-resource-name}"
         },
         "connectionRuntimeUrl": https://9d51d1ffc9f77572.00.common.logic-{Azure-region}.azure-apihub.net/apim/office365/668073340efe481192096ac27e7d467f,
         "authentication": {
            "type":"ManagedServiceIdentity"
         }
      }
   }
}

Azure にデプロイ

Visual Studio Code から、プロジェクトを Azure に直接発行して、Standard ロジック アプリ リソースをデプロイできます。 ロジック アプリは新しいリソースとして発行できます。これにより、関数アプリの要件と同様に、Azure ストレージ アカウントなど、必要なリソースが自動的に作成されます。 または、以前にデプロイされた Standard ロジック アプリ リソースにロジック アプリを発行することもできます。これにより、そのロジック アプリは上書きされます。

Standard ロジック アプリ リソースのデプロイには、ホスティング プランと価格レベルが必要です。これらはデプロイ時に選びます。 詳細については、「ホスティング プランと価格レベル」を参照してください。

新しい Standard ロジック アプリ リソースに発行する

  1. Visual Studio Code のアクティビティ バーで、Azure アイコンを選んで Azure ウィンドウを開きます。

  2. Azure ウィンドウの ワークスペース セクション ツール バーの [Azure Logic Apps] メニューから、[新しいプロジェクトのデプロイ] を選択します。

    ワークスペースツールバーが表示されたAzure ウィンドウと、 [Deploy to Logic App] が選択された状態のAzure Logic Appsショートカットメニューのスクリーンショット。

  3. プロンプトが表示される場合は、ロジック アプリのデプロイに使用する Azure サブスクリプションを選択します。

  4. Visual Studio Code で開いたリストで、次のオプションから選択します。

    • Azure で新しい Logic App (Standard) を作成する (クイック)
    • Azure Advanced で新しい Logic App (Standard) を作成する
    • 以前にデプロイされた Logic App (Standard) リソース (存在する場合)

    この例では、 [Azure Advanced で新しい Logic App (Standard) を作成する] を選択して続行します。

    デプロイ オプション一覧を示すスクリーンショット。オプション [Azure Advanced で新しい Logic App (Standard) を作成する] が選択されています。

  5. 新しい Standard ロジック アプリ リソースを作成するには、次の手順に従います。

    1. 新しいロジック アプリのグローバルに一意の名前を指定します。これは、Logic App (Standard) リソースに使用する名前です。 この例では、Fabrikam-Workflows-App を使用します。

      作成する新しいロジック アプリの名前を指定するプロンプトを示すスクリーンショット。

    2. 新しいロジック アプリのホスティング プランを選択します。 プランの名前を作成するか、既存のプラン (Windows ベースの App Service プランのみ) を選択します。 この例では、 [新しい App Service プランを作成する] を選択します。

      [Logic Apps (Standard)] ウィンドウと、[新しい App Service プランを作成する] または既存の App Service プランを選ぶように求めるプロンプトを示すスクリーンショット。

    3. ホスティング プランの名前を入力して、選択したプランの価格レベルを選択します。

      詳細については、「ホスティング プランと価格レベル」を参照してください。

    4. 最適なパフォーマンスを得るには、デプロイ用のプロジェクトと同じリソース グループを選択します。

      注意

      別のリソース グループを作成したり、使用したりすることはできますが、パフォーマンスに影響を与える可能性があります。 別のリソース グループを作成または選択した場合、確認プロンプトが表示された後にキャンセルすると、デプロイも取り消されます。

    5. ステートフルなワークフローの場合は、 [新しいストレージ アカウントを作成する] または既存のストレージ アカウントを選択します。

      [Logic Apps (Standard)] ウィンドウと、ストレージ アカウントを作成または選ぶように求めるプロンプトを示すスクリーンショット。

    6. ロジック アプリの作成とデプロイの設定で Application Insights の使用がサポートされている場合は、必要に応じて、ロジック アプリの診断ログとトレースを有効にすることができます。 ロジック アプリを Visual Studio Code からデプロイするとき、またはデプロイした後で、それを行うことができます。 Application Insights インスタンスを用意する必要がありますが、このリソースは、事前に、ロジック アプリをデプロイするときに、またはデプロイ後に、作成することができます。

      ここでログとトレースを有効にするには、次の手順のようにします。

      1. 既存の Application Insights リソースを選択するか、新しい Application Insights リソースを作成します。

      2. Azure portal で、お使いの Application Insights リソースに移動します。

      3. リソース メニューで [概要] を選択します。 [インストルメンテーション キー] の値を見つけてコピーします。

      4. Visual Studio Code で、プロジェクトのルート フォルダーにある local.settings.json ファイルを開きます。

      5. Values オブジェクトで APPINSIGHTS_INSTRUMENTATIONKEY プロパティを追加し、値にインストルメンテーション キーを設定します。次に例を示します。

        {
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "APPINSIGHTS_INSTRUMENTATIONKEY": <instrumentation-key>
   }
}

        ヒント

        トリガーとアクションの名前が Application Insights インスタンスに正しく表示されているかどうかを確認できます。

        1. Azure portal で、お使いの Application Insights リソースに移動します。

        2. リソース メニューの [調査] で、[アプリケーション マップ] を選択します。

        3. マップに表示される操作の名前を確認します。

        組み込みトリガーからの一部の受信要求は、アプリケーション マップに重複して表示される場合があります。 これらの重複の場合、WorkflowName.ActionName 形式ではなく、ワークフロー名が操作名として使用され、Azure Functions ホストから生成されます。

      6. 次に、ロジック アプリによって収集されて Application Insights インスタンスに送信されるトレース データの重大度レベルを、必要に応じて調整できます。

        ワークフローがトリガーされたときや、アクションが実行されたときなど、ワークフロー関連のイベントが発生するたびに、ランタイムによってさまざまなトレースが出力されます。 これらのトレースによってワークフローの有効期間がカバーされ、次のイベントの種類が含まれます (これらだけではありません)。

        • サービスのサービス (開始、停止、エラーなど)。
        • ジョブとディスパッチャーのアクティビティ。
        • ワークフローのアクティビティ (トリガー、アクション、実行など)。
        • ストレージ要求のアクティビティ (成功や失敗など)。
        • HTTP 要求のアクティビティ (受信、送信、成功、失敗など)。
        • すべての開発トレース (デバッグ メッセージなど)。

        各イベントの種類は、重大度レベルに割り当てられています。 たとえば、Trace レベルでは最も詳細なメッセージがキャプチャされる一方、Information レベルでは、ロジック アプリ、ワークフロー、トリガー、アクションが開始および停止したときなど、ワークフローの一般的なアクティビティがキャプチャされます。 次の表では、重大度レベルとそのトレースの種類について説明します。

        重大度レベル トレースの種類
        Critical ロジック アプリで回復不能なエラーを示すログ。
        デバッグ 開発中の調査に使用できるログ。たとえば、受信と送信の HTTP 呼び出し。
        エラー ワークフローの実行の失敗だが、ロジック アプリでの一般的なエラーではないものを示すログ。
        情報 ロジック アプリまたはワークフローでの一般的なアクティビティを追跡するログ。次のようなもの。

        - トリガー、アクション、または実行が開始および終了したとき。
        - ロジック アプリが開始または終了したとき。
        Trace 最も詳細なメッセージが含まれるログ。たとえば、ストレージ要求やディスパッチャーのアクティビティに加えて、ワークフロー実行アクティビティに関連するすべてのメッセージ。
        警告 ロジック アプリでの異常な状態だが、実行を妨げはしないものを強調して示すログ。

        重大度レベルを設定するには、プロジェクトのルート レベルで host.json ファイルを開き、logging オブジェクトを見つけます。 このオブジェクトにより、ロジック アプリ内のすべてのワークフローのログ フィルター処理が制御され、ログの種類のフィルター処理に対する ASP.NET Core のレイアウトに従います。

        {
   "version": "2.0",
   "logging": {
      "applicationInsights": {
         "samplingExcludedTypes": "Request",
         "samplingSettings": {
            "isEnabled": true
         }
      }
   }
}

        logging オブジェクトに、Host.Triggers.Workflow プロパティを含む logLevel オブジェクトが含まれていない場合は、それらの項目を追加します。 プロパティを、必要なトレースの種類の重大度レベルに設定します。次に例を示します。

        {
   "version": "2.0",
   "logging": {
      "applicationInsights": {
         "samplingExcludedTypes": "Request",
         "samplingSettings": {
            "isEnabled": true
         }
      },
      "logLevel": {
         "Host.Triggers.Workflow": "Information"
      }
   }
}

    デプロイ手順を完了すると、Visual Studio Code によりロジック アプリの発行に必要なリソースの作成とデプロイが開始されます。

  6. デプロイ プロセスを確認および監視するには、 [表示] メニューで [出力] を選択します。 [出力] ウィンドウのツールバーの一覧で、 [Azure Logic Apps] を選択します。

    ツールバーの一覧で [Azure Logic Apps] が選択された [出力] ウィンドウと、デプロイの進行状況と状態を示すスクリーンショット。

    Visual Studio Code による Azure へのロジック アプリのデプロイが完了すると、次のメッセージが表示されます。

    Azure へのデプロイが正常に完了したというメッセージを示すスクリーンショット。

    これで、ロジック アプリが Azure で稼働し、既定で有効になりました。

次に、以下のタスクを実行する方法を学習できます。

空のワークフローをプロジェクトに追加する

ロジック アプリ プロジェクトには、複数のワークフローを含めることができます。 空のワークフローをプロジェクトに追加するには、次の手順のようにします。

  1. Visual Studio Code のアクティビティ バーで、Azure アイコンを選択します。

  2. Azure ウィンドウの ワークスペース セクション ツール バーの [Azure Logic Apps] メニューから、[ワークフローの作成] を選択します。

  3. 追加するワークフローの種類として、 [ステートフル] または [ステートレス] を選択します

  4. ワークフローの名前を指定します。

終わると、新しいワークフロー フォルダーとワークフロー定義の workflow.json ファイルが、プロジェクトに表示されます。

デプロイされたロジック アプリを Visual Studio Code で管理する

Visual Studio Code では、従量課金であるか Standard であるかに関係なく、Azure サブスクリプション内のすべてのデプロイ済みロジック アプリを表示できます。また、これらのロジック アプリの管理に役立つタスクを選択できます。 ただし、両方のリソースの種類にアクセスするには、Visual Studio Code 用の Azure Logic Apps (従量課金) と Azure Logic Apps (Standard) の両方の拡張機能が必要です。

  1. Visual Studio Code のアクティビティ バーで、Azure アイコンを選択します。 [リソース] のサブスクリプションを展開し、[ロジック アプリ] を展開すると、そのサブスクリプションの Azure にデプロイされたすべてのロジック アプリが表示されます。

  2. 管理するロジック アプリを開きます。 ロジック アプリのショートカット メニューで、実行するタスクを選択します。

    たとえば、デプロイしたロジック アプリの停止、開始、再起動、削除などのタスクを選択できます。 Azure portal を使用してワークフローを無効または有効にすることができます。

    注意

    ロジック アプリの停止とロジック アプリの削除の操作は、さまざまな方法でワークフロー インスタンスに影響を与えます。 詳細については、「ロジック アプリの停止に関する考慮事項」と「ロジック アプリの削除に関する考慮事項」をご覧ください。

    Visual Studio Code と [リソース] セクションを示すスクリーンショット。ロジック アプリ リソースがデプロイされています。

  3. ロジック アプリのすべてのワークフローを表示するには、ロジック アプリを展開した後、 [ワークフロー] ノードを展開します。

  4. 特定のワークフローを表示するには、ワークフローのショートカット メニューを開き、 [デザイナーで開く] を選択します。これにより、ワークフローが読み取り専用モードで開きます。

    ワークフローを編集するには、次のオプションがあります。

    • Visual Studio Code のワークフロー デザイナーでプロジェクトの workflow.json ファイルを開き、編集を行って、ロジック アプリを Azure に再デプロイします。

    • Azure portal 上でロジック アプリを開きます。 その後、ワークフローを開き、編集し、保存できます。

  5. デプロイされたロジック アプリを Azure portal で開くには、ロジック アプリのショートカット メニューを開き、 [ポータルで開く] を選択します。

    ブラウザーで Azure portal が開き、Visual Studio Code にサインインしている場合はポータルに自動的にサインインし、ロジック アプリが表示されます。

    Visual Studio Code でのロジック アプリのための Azure portal ページを示すスクリーンショット。

    Azure portal に個別にサインインし、ポータルの検索ボックスを使用してロジック アプリを検索し、結果の一覧からロジック アプリを選択することもできます。

    Azure portal と、デプロイされているロジック アプリの検索結果が表示された検索バーを示すスクリーンショット。選択された状態で表示されています。

ロジック アプリの停止に関する考慮事項

ロジック アプリを停止すると、ワークフロー インスタンスに次のような影響が生じます。

  • Azure Logic Apps は、進行中および保留中のすべての実行を直ちに取り消します。

  • Azure Logic Apps は、新しいワークフロー インスタンスを作成することも実行することもありません。

  • トリガーは、次にその条件が満たされたときに起動されません。 ただし、トリガーの状態には、ロジック アプリが停止したポイントが記憶されます。 そのため、ロジック アプリを再起動すると、前回の実行以降のすべての未処理の項目に対してトリガーが起動されます。

    前回の実行以降の未処理の項目に対してトリガーが起動しないようにするには、ロジック アプリを再起動にする前に、トリガーの状態をクリアします。

    1. Visual Studio Code のアクティビティ バーで、Azure アイコンを選んで Azure ウィンドウを開きます。

    2. [リソース] セクションのサブスクリプションを展開します。これにより、そのサブスクリプションにデプロイされているすべてのロジック アプリが表示されます。

    3. ロジック アプリを展開し、 [ワークフロー] という名前のノードを展開します。

    4. ワークフローを開き、そのワークフローのトリガーの任意の部分を編集します。

    5. 変更を保存します。 この手順により、トリガーの現在の状態がリセットされます。

    6. 各ワークフローに対してこの手順を繰り返します。

    7. 完了したら、ロジック アプリを再起動します。

ロジック アプリの削除に関する考慮事項

ロジック アプリを削除すると、ワークフロー インスタンスに次のような影響が生じます。

  • Azure Logic Apps サービスは、進行中および保留中の実行を直ちに取り消しますが、アプリによって使用されているストレージ上でクリーンアップ タスクは実行されません。

  • Azure Logic Apps は、新しいワークフロー インスタンスを作成することも実行することもありません。

  • ワークフローを削除してから同じワークフローを再作成しても、再作成されたワークフローに、削除したワークフローと同じメタデータが割り当てられることはありません。 メタデータを最新の情報に更新するために、削除したワークフローの呼び出し元となったワークフローを再保存する必要があります。 これにより、呼び出し元は、再作成されたワークフローの正しい情報を取得します。 それ以外の場合、再作成したワークフローの呼び出しは、Unauthorized エラーで失敗します。 この動作は、統合アカウントのアーティファクトを使用するワークフローや、Azure 関数を呼び出すワークフローにも当てはまります。

デプロイされたロジック アプリをポータルで管理する

ロジック アプリを Visual Studio Code から Azure portal にデプロイした後、従量課金または Standard いずれのロジック アプリ リソースであるかに関係なく、Azure サブスクリプションにあるすべてのデプロイ済みロジック アプリを表示できます。 現時点では、各リソースの種類は Azure で個別のカテゴリとして編成および管理されています。 Standard ロジック アプリを見つけるには、次の手順に従います。

  1. Azure portal の検索ボックスに「ロジック アプリ」と入力します。 結果の一覧が表示されたら、 [サービス] で、 [ロジック アプリ] を選択します。

    Azure portal 検索ボックスを示すスクリーンショット。検索テキストとしてロジック アプリが表示されています。

  2. [ロジック アプリ] ペインで、Visual Studio Code からデプロイしたロジック アプリを選択します。

    Azure portal と、Azure にデプロイされた Standard ロジック アプリ リソースを示すスクリーンショット。

    Azure portal で、選択したロジック アプリの個別のリソース ページが開きます。

    Azure portal と、ロジック アプリ リソース ページを示すスクリーンショット。

  3. このロジック アプリのワークフローを表示するには、ロジック アプリのメニューで [ワークフロー] を選択します。

    [ワークフロー] ウィンドウには、現在のロジック アプリのすべてのワークフローが表示されます。 この例では、Visual Studio Code で作成したワークフローを示しています。

    ロジック アプリ リソース ページを示すスクリーンショット。開いた [ワークフロー] ペインとワークフローが表示されています。

  4. ワークフローを表示するには、 [ワークフロー] ウィンドウで、そのワークフローを選択します。

    [ワークフロー] ウィンドウが開き、詳細情報とそのワークフローに対して実行できるタスクが表示されます。

    たとえば、ワークフローのステップを表示するには、 [デザイナー] を選択します。

    選択されたワークフローの [概要] ペインを示すスクリーンショット。[ワークフロー] メニューには、選択した [デザイナー] コマンドが表示されています。

    ワークフロー デザイナーが開き、Visual Studio Code で作成したワークフローが表示されます。 これで、Azure portal でこのワークフローに変更を加えることができます。

    Visual Studio Code からデプロイされたワークフロー デザイナーとワークフローを示すスクリーンショット。

ポータルで別のワークフローを追加する

Azure portal を使うと、Visual Studio Code からデプロイした Standard ロジック アプリ リソースに空のワークフローを追加し、それらのワークフローを Azure portal でビルドできます。

  1. Azure portal で、デプロイされた Standard ロジック アプリ リソースを選びます。

  2. ロジック アプリのリソース メニューで、[ワークフロー] を選びます。 [ワークフロー] ウィンドウで、 [追加] を選択します。

    選択されたロジック アプリの [ワークフロー] ペインと、[追加] コマンドが選択されたツール バーを示すスクリーンショット。

  3. [新しいワークフロー] ウィンドウで、ワークフローの名前を指定します。 [ステートフル] または [ステートレス] > [作成] の順に選択します。

    Azure で新しいワークフローがデプロイされた後、それが [ワークフロー] ペインに表示されたら、そのワークフローを選択し、デザイナーやコード ビューを開くなどして、他のタスクを管理および実行できます。

    選択されたワークフローと、管理と確認のオプションを示すスクリーンショット。

    たとえば、新しいワークフローのデザイナーを開くと、空のキャンバスが表示されます。 このワークフローを Azure portal でビルドできるようになりました。

    ワークフロー デザイナーと空のワークフローを示すスクリーンショット。

ステートレス ワークフローの実行履歴を有効にする

ステートレス ワークフローをさらに簡単にデバッグするには、そのワークフローの実行履歴を有効にした後、完了したら実行履歴を無効にすることができます。 Visual Studio Code の場合は、こちらの手順のようにします。Azure portal で作業している場合は、Azure portal でシングルテナント ベースのワークフローを作成するに関するセクションを参照してください。

  1. Visual Studio Code プロジェクトのルート フォルダー レベルで、local.settings.json ファイルを開きます。

  2. Workflows.{yourWorkflowName}.operationOptions プロパティを追加し、値を WithStatelessRunHistory に設定します。次に例を示します。

    Windows

    {
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "Workflows.{yourWorkflowName}.OperationOptions": "WithStatelessRunHistory"
   }
}

    macOS または Linux

    {
   "IsEncrypted": false,
   "Values": {
      "AzureWebJobsStorage": "DefaultEndpointsProtocol=https;AccountName=fabrikamstorageacct; \
          AccountKey=<access-key>;EndpointSuffix=core.windows.net",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet",
      "Workflows.{yourWorkflowName}.OperationOptions": "WithStatelessRunHistory"
   }
}

  3. workflow-designtime という名前のプロジェクト フォルダーで、local.settings.json ファイルを開き、同じように変更します。

  4. 完了時に実行履歴を無効にするには、Workflows.{yourWorkflowName}.OperationOptions プロパティを None に設定するか、プロパティとその値を削除します。

Azure portal で監視ビューを有効にする

Visual Studio Code から Azure に Logic App (Standard) リソースをデプロイすると、Azure portal とそのワークフローの [監視] エクスペリエンスを使用して、そのリソース内のワークフローの利用可能な実行履歴と詳細を確認できます。 ただし、最初に、そのロジック アプリ リソースで監視ビュー機能を有効にする必要があります。

  1. Azure portal で、Standard ロジック アプリ リソースを開きます。

  2. ロジック アプリ リソース メニューの [API] で、[CORS] を選びます。

  3. [CORS] ウィンドウの [許可されたオリジン] で、ワイルドカード文字 (*) を追加します。

  4. 操作が完了したら、 [CORS] のツールバーで、 [保存] を選択します。

    Standard ロジック アプリ リソースがデプロイされた Azure portal を示すスクリーンショット。[リソース] メニューでは [CORS] が選択され、[許可されたオリジン] の新しいエントリにワイルドカードワイルドカード * 文字が設定されています。

デプロイの後で Application Insights を有効にするか開く

ワークフローの実行中に、ロジック アプリによって他のイベントと共にテレメトリが出力されます。 このテレメトリを使用して、ワークフローの実行状況や、Logic Apps ランタイムのさまざまな方法での動作を、より明確に把握することができます。 Application Insights を使用してワークフローを監視でき、ほぼリアルタイムのテレメトリ (ライブ メトリック) が提供されます。 この機能を使用すると、このデータを使用して問題の診断、アラートの設定、グラフの作成を行うときに、エラーやパフォーマンスの問題をより簡単に調査できます。

ロジック アプリの作成とデプロイの設定で Application Insights の使用がサポートされている場合は、必要に応じて、ロジック アプリの診断ログとトレースを有効にすることができます。 ロジック アプリを Visual Studio Code からデプロイするとき、またはデプロイした後で、それを行うことができます。 Application Insights インスタンスを用意する必要がありますが、このリソースは、事前に、ロジック アプリをデプロイするときに、またはデプロイ後に、作成することができます。

デプロイされたロジック アプリで Application Insights を有効にするには、または既に有効になっている場合に Application Insights データを確認するには、次の手順のようにします。

  1. Azure portal で、デプロイされたロジック アプリを見つけます。

  2. ロジック アプリのメニューの [設定] で、 [Application Insights] を選択します。

  3. Application Insights が有効になっていない場合は、 [Application Insights] ペインで、 [Application Insights を有効にする] を選択します。 ペインが更新されたら、下部にある [適用] を選択します。

    Application Insights が有効になっている場合は、 [Application Insights] ペインで、 [Application Insights データの表示] を選択します。

Application Insights が開いたら、ロジック アプリのさまざまなメトリックを確認できます。 詳細については、次のトピックをご覧ください。

デザイナーから項目を削除する

デザイナーからワークフロー内の項目を削除するには、次のいずれかの手順のようにします。

  • 項目を選択し、項目のショートカット メニューを開いて (Shift + F10)、 [削除] を選択します。 [OK] を選択して確認します。

  • 項目を選択して、Delete キーを押します。 [OK] を選択して確認します。

  • 項目を選択すると、その項目の詳細ペインが開きます。 ペインの右上隅で、省略記号 [...] メニューを開き、 [削除] を選択します。 [OK] を選択して確認します。

    デザイナーで選択されている項目と開いた情報ペインを示すスクリーンショット。省略記号ボタンと [削除] コマンドが選択されています。

    ヒント

    省略記号メニューが表示されない場合は、右上隅にある省略記号 [...] ボタンが詳細ペインに表示されるように、Visual Studio Code のウィンドウを十分に広く展開します。

エラーと問題のトラブルシューティング

デザイナーが開けない

デザイナーを開こうとすると、 "Workflow design time could not be started (ワークフロー デザイン時を開始できませんでした)" というエラーが発生します。 以前にデザイナーを開こうとした後、プロジェクトを中止または削除した場合、拡張機能のバンドルがダウンロードされない可能性があります この理由が問題になっているかどうかを確認するには、次の手順に従います。

  1. Visual Studio Code で、[出力] ウィンドウを開きます。 [表示] メニューの [出力] を選択します。

  2. [出力] ウィンドウのタイトル バーの一覧から [Azure Logic Apps (Standard)] を選択して、拡張機能からの出力を確認できるようにします。次に例を示します。

    [Azure Logic Apps] が選択されている [出力] ウィンドウを示すスクリーンショット。

  3. 出力を確認し、次のエラー メッセージが表示されているかどうかを調べます。

    A host error has occurred during startup operation '{operationID}'.
System.Private.CoreLib: The file 'C:\Users\{userName}\AppData\Local\Temp\Functions\
ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows\1.1.7\bin\
DurableTask.AzureStorage.dll' already exists.
Value cannot be null. (Parameter 'provider')
Application is shutting down...
Initialization cancellation requested by runtime.
Stopping host...
Host shutdown completed.

このエラーを解決するには、...\Users{your-username}\AppData\Local\Temp\Functions\ExtensionBundles の位置にある ExtensionBundles フォルダーを削除し、デザイナーで workflow.json ファイルをもう一度開いてみてください。

前に作成したワークフローのデザイナー ピッカーに新しいトリガーとアクションがない

シングルテナントの Azure Logic Apps では、Azure 関数の操作、Liquid の操作、XML の操作 ( [XML の検証] や [XML の変換] など) に対する組み込みアクションがサポートされています。 ただし、以前に作成したロジック アプリでは、Visual Studio Code で古いバージョンの拡張機能バンドル Microsoft.Azure.Functions.ExtensionBundle.Workflows が使用されている場合、これらの操作がデザイナー ピッカーに表示されないことがあります。

また、ロジック アプリを作成するときに [Use connectors from Azure](Azure からのコネクタを使用する) を有効にするか、選択していない限り、 [Azure Function Operations](Azure 関数操作) コネクタとアクションはデザイナー ピッカーに表示されません。 アプリの作成時に Azure によってデプロイされるコネクタを有効にしなかった場合は、Visual Studio Code でプロジェクトからそれらを有効にすることができます。 workflow.json のショートカット メニューを開き、 [Use Connectors from Azure](Azure からのコネクタを使用する) を選択します。

古くなったバンドルを修正するには、次の手順に従って古いバンドルを削除します。そうすると、Visual Studio Code により拡張機能バンドルが最新バージョンに自動的に更新されます。

Note

この解決方法は、Visual Studio Code と Azure Logic Apps (Standard) 拡張機能を使用して作成およびデプロイしたロジック アプリにのみ適用され、Azure portal を使用して作成したロジック アプリには適用されません。 サポートされているトリガーとアクションが Azure portal のデザイナーに表示されない場合に関するページを参照してください。

  1. 失いたくない作業をすべて保存し、Visual Studio を閉じます。

  2. コンピューターで、次のフォルダーに移動します。このフォルダーには、既存のバンドルのバージョン管理されたフォルダーが含まれています。

    ...\Users\{your-username}\.azure-functions-core-tools\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows

  3. 以前のバンドルのバージョン フォルダーを削除します。たとえば、バージョン 1.1.3 のフォルダーがある場合は、そのフォルダーを削除します。

  4. 次に、必要な NuGet パッケージのバージョン管理されたフォルダーが含まれる次のフォルダーを参照します。

    ...\Users\{your-username}\.nuget\packages\microsoft.azure.workflows.webjobs.extension

  5. 以前のパッケージのバージョン フォルダーを削除します。

  6. Visual Studio Code とプロジェクト、およびデザイナーで workflow.json ファイルを、再度開きます。

不足していたトリガーとアクションが、デザイナーに表示されるようになります。

"400 要求が正しくありません" がトリガーまたはアクションで表示される

実行が失敗し、モニター ビューで実行を検査すると、このエラーが長い名前のトリガーまたはアクションで表示されることがあります。これが原因で、基になる URI (Uniform Resource Identifier) が既定の文字制限を超えてしまいます。

この問題を解決し、長い URI に合わせて調整するには、次の手順に従って、コンピューターの UrlSegmentMaxCount と UrlSegmentMaxLength のレジストリ キーを編集します。 これらのキーの既定値については、「Windows 用のレジストリ設定の Http.sys」のトピックに記載されています。

重要

開始する前に、作業内容が保存されていることを確認してください。 この解決策では、変更を有効にするために対処後にコンピューターを再起動する必要があります。

  1. コンピューターで、[ファイル名を指定して実行] ウィンドウを開き、regedit コマンドを実行します。これにより、レジストリ エディターが開きます。

  2. [ユーザー アカウント制御] ボックスで、 [はい] を選択して、コンピューターへの変更を許可します。

  3. 左側のウィンドウで、 [コンピューター] の下のパス HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\HTTP\Parameters に沿ってノードを展開し、 [Parameters] を選択します。

  4. 右側のペインで、UrlSegmentMaxCount と UrlSegmentMaxLength のレジストリ キーを見つけます。

  5. 使用する名前が URI に収容されるように、これらのキーの値を十分に増やします。 これらのキーが存在しない場合は、次の手順に従って Parameters フォルダーに追加します。

    1. [Parameters] のショートカット メニューから、[新規]>[DWORD (32 ビット) 値] を選択します。

    2. 表示された編集ボックスに、新しいキー名として UrlSegmentMaxCount を入力します。

    3. 新しいキーのショートカット メニューを開き、 [修正] を選択します。

    4. 表示された [文字列の編集] ボックスで、 [値のデータ] に 16 進数形式または 10 進数形式のキー値を入力します。 たとえば、16 進数の 400 は 10 進数の 1024 に相当します。

    5. UrlSegmentMaxLength のキー値を追加するには、これらの手順を繰り返します。

    これらのキー値を増やすか、追加すると、レジストリ エディターは次の例のようになります。

    レジストリ エディターを示すスクリーンショット。

  6. 準備ができたら、コンピューターを再起動して変更を有効にします。

デバッグ セッションが開始できない

デバッグ セッションを開始しようとすると、 "Error exists after running preLaunchTask 'generateDebugSymbols' (preLaunchTask 'generateDebugSymbols' の実行後にエラーがあります)" というエラーが発生します。 この問題を解決するには、プロジェクト内の tasks.json ファイルを編集して、シンボルの生成をスキップします。

  1. プロジェクト内で、 .vscode という名前のフォルダーを展開し、tasks.json ファイルを開きます。

  2. 次のタスクで、"dependsOn: "generateDebugSymbols" という行と、前の行の末尾のコンマを削除し、次のようにします。

    次の処理の前

     {
   "type": "func",
   "command": "host start",
   "problemMatcher": "$func-watch",
   "isBackground": true,
   "dependsOn": "generateDebugSymbols"
 }

    次の処理の後

     {
   "type": "func",
   "command": "host start",
   "problemMatcher": "$func-watch",
   "isBackground": true
 }

次のステップ

Azure Logic Apps (Standard) 拡張機能でのエクスペリエンスについて、ご意見をお聞かせください。