Visual Studio Code を使用して標準ロジック アプリ ワークフローを作成する

適用対象: Azure Logic Apps (Standard)

このガイドでは、Visual Studio Code と Azure Logic Apps (Standard) 拡張機能を使用するときに、シングルテナントの Azure Logic Apps で実行できるサンプル の Standard ロジック アプリ ワークフローをローカルで作成する方法について説明します。

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

Standard ロジック アプリが提供する利点を次に示します。

• ローカルの Visual Studio Code 開発環境で、ワークフローをローカルで作成、デバッグ、実行、テストできます。 Azure portal と Visual Studio Code の両方に、Standard ロジック アプリのリソースとワークフローを構築、実行、デプロイする機能が用意されています。 ただし、Visual Studio Code では、これらのタスクをローカルで実行できます。

• Standard ロジック アプリ プロジェクトには、 ステートフル ワークフローとステートレス ワークフローの両方を含めることができます。

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

このガイドのワークフロー例は、最初は 要求 トリガーの後に Office 365 Outlook アクションが続きます。 要求トリガーは、ワークフローの呼び出し可能なエンドポイントを作成し、任意の呼び出し元からの受信 HTTPS 要求を待機します。 トリガーが要求を受信して起動すると、選択したトリガー出力と共に指定した受信者に電子メールを送信することで、次のアクションが実行されます。 後で、応答と処理されたデータを呼び出し元に返す 応答 アクションを追加できます。

このガイドの例はクラウドベースであり、いくつかの手順しかありませんが、 1,400 を超えるコネクタ からの操作を使用してワークフローを作成できます。これにより、クラウド、オンプレミス、ハイブリッド環境全体に広範なサービス、システム、アプリ、データを統合できます。

ガイドを進めていくと、次の大まかなタスクが完了します。

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

[前提条件]

アクセスと接続の要件

Azure Logic Apps (Standard) ランタイムでネイティブに実行される 組み込み操作のみを使用してワークフローをローカルで作成して実行する予定の場合は、このセクションのアクセスと接続の要件は必要ありません。 ただし、次のシナリオでは、これらの要件を満たす必要があります。

• Visual Studio Code からロジック アプリを Azure にデプロイします。
• グローバル Azure で実行される マネージド コネクタ操作 を使用するワークフローを構築します。
• Azure またはその他のデプロイされた Azure リソース内の既存の Standard ロジック アプリリソースとワークフローにアクセスします。

これらの要件には、次のものが含まれます。

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

• 必要な拡張機能をダウンロードし、Visual Studio Code から Azure アカウントに接続し、マネージド コネクタ操作を含むワークフローをテストし、Visual Studio Code から Azure にデプロイできるように、インターネットにアクセスします。

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

  Office 365 アカウントをお持ちでない場合は、電子メール アカウントからメッセージを送信できる他の使用可能なアクション (Outlook.com など) を使用できます。 別の電子メール コネクタ (Outlook.com など) を選択した場合でも、例に従うことができ、全般的な手順は同じです。 ただし、エクスペリエンスとオプションは、いくつかの方法で異なる場合があります。 たとえば、Outlook.com コネクタでは、個人用の Microsoft アカウントを使用してサインインします。

ツール

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

2. 次の手順に従って、 Visual Studio Code 用の Azure Logic Apps (Standard) 拡張機能 をダウンロードしてインストールします。

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

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

      拡張機能は、次のフレームワークに必要なすべての依存関係と正しいバージョンをダウンロードしてインストールします。

      • Azure Functions Core Tools (Azure ファンクションズ コア ツール)
      • .NET SDK
      • Node.js

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

      

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

   4. 拡張機能とすべての依存関係が正しくインストールされていることを確認するには、「拡張機能の インストールを確認する」を参照してください。

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

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

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

4. 標準ロジック アプリの Application Insights を使用して診断ログとトレースを有効にするには、ロジック アプリのデプロイ中またはデプロイ後にこのタスクを完了します。 Application Insights リソースが必要ですが、 このリソースは、事前、デプロイ中、またはデプロイ後に作成できます。

5. HTTP 要求を送信してサンプル ワークフローをテストできるツールをインストールまたは使用します。次に例を示します。

   • Visual Studio Code を Visual Studio Marketplace からの拡張機能と一緒に使用する
   • PowerShell Invoke-RestMethod
   • Microsoft Edge - ネットワーク コンソール ツール
   • ブルーノ
   • カール

   注意事項

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

拡張機能のインストールを確認する

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

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

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

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

   3. [ 自動更新 ] が選択され、[ 自動更新 ] が [すべての拡張機能] に設定されていることを確認します。

3. Azure Logic Apps Standard: Project Runtime の設定が正しいバージョンに設定されていることを確認します。

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

   2. Project Runtime がバージョン 4 に設定されていることを確認します。次に例を示します。

      

      注

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

Azure アカウントに接続する

Azure アカウントにまだ接続していない場合は、次の手順に従って接続します。

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

   

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

   

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

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

      

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

   2. 更新されたサブスクリプションの一覧が表示されたら、必要なサブスクリプションを選択し、[ OK] を選択していることを確認します。

ローカル ワークスペースを作成する

ロジック アプリ プロジェクトには常にワークスペースが必要です。 そのため、ロジック アプリを作成する前に、ロジック アプリ プロジェクトを保持する ワークスペース を作成する必要があります。 後でこのワークスペースとプロジェクトを使用して、Visual Studio Code からデプロイ環境にロジック アプリを管理、実行、デプロイします。 基になるプロジェクトは、Azure Functions プロジェクト (関数アプリ プロジェクトとも呼ばれます) に似ています。

1. コンピューターで、後でワークスペースとプロジェクトに使用する 空 のローカル フォルダーを作成します。

   この例では、 fabrikam-workflows という名前のフォルダーを作成します。

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

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

   

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

4. [ フォルダーの選択 ] ウィンドウで、フォルダーを作成した場所に移動し、フォルダーを選択して、[ 選択 ] を選択します (フォルダーをダブルクリックしないでください)。

   

   Visual Studio Code ツール バーに、ワークスペースに名前を付けるプロンプトが表示されます。

5. [ ワークスペース名を指定] に、使用するワークスペース名を入力します。

   この例では 、Fabrikam-Workflows を使用します。

   

次に、ロジック アプリ プロジェクトを作成します。

ロジック アプリ プロジェクトを作成する

必要なワークスペースを作成したら、プロンプトに従ってプロジェクトを作成します。

1. プロジェクト テンプレートの場合は、[ ロジック アプリ] を選択します。 使用するプロジェクト名を入力します。

   この例では 、Fabrikam-Workflows を使用します。

   

2. ワークフロー テンプレートでは、シナリオに基づいて ステートフル ワークフロー または ステートレス ワークフローを選択します。 使用するワークフロー名を入力します。

   次の使用例は、ワークフロー履歴、入力、出力を格納する ステートフル ワークフローを選択し、 名前として Stateful-Workflow を使用します。

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

   注

   エラー メッセージが表示された azureLogicAppsStandard.createNewProject という名前のエラーが発生した場合は、AzureFunctions.suppressProject が登録済みの構成ではないため、ワークスペース設定に書き込むことができません。Visual Studio Marketplace から直接、または Visual Studio Code 内から、Visual Studio Code 用の Azure Functions 拡張機能を再インストールしてみてください。

3. 次に、現在の Visual Studio Code ウィンドウでプロジェクトを開くか、新しいウィンドウで開くかを選択します。 設定に基づいて、[ 現在のウィンドウで開く ] または [ 新しいウィンドウで開く] を選択します。

   エクスプローラー ウィンドウが開き、ワークスペース、プロジェクト、および自動的に開かれた workflow.json ファイルが表示されます。 このファイルは Stateful-Workflow という名前のフォルダーに存在し、デザイナーでビルドするワークフローの基になる JSON 定義を格納します。 プロジェクト構造の詳細については、「 標準ロジック アプリのプロジェクト構造」を参照してください。

   また、マルチテナント Azure でホストされる "共有" コネクタを有効にするように求めるメッセージも表示されます。次に例を示します。

   

4. マルチテナント Azure で実行されるすべてのマネージド "共有" コネクタを有効にして、ワークフローで使用することを選択できるようにするには、 Azure から [コネクタの使用] を選択します。

   注

   このオプションを選択せず、後でワークフローの作成時にマネージド コネクタ操作を追加しようとすると、操作情報ウィンドウに停止しない回転円が表示されるため、続行できません。

5. Azure リソース グループの場合は、[ 新しいリソース グループの作成] を選択します。 使用するリソース グループ名を入力します。

   この例では、Fabrikam-Workflows-RG を使用します。

6. サブスクリプションの場合は、ロジック アプリ プロジェクトで使用する Azure サブスクリプションを選択します。

7. グループとリソースを作成する場所として、Azure リージョンを選択します。

   この例では、 [米国中西部] を使用します。

8. プロジェクトで開発用の他のセットアップが必要な場合や、ワークフローを構築するためのサポート成果物が必要な場合は、次のシナリオと関連タスクを参照してください。

   シナリオ	課題
   Webhook ベースのトリガーまたはアクションをローカルで実行します。	Webhook コールバック URL の転送を設定します。
   ステートレス ワークフロー実行履歴を設定します。	ステートレス ワークフローの実行履歴を有効にします。
   マップ、スキーマ、アセンブリなどの成果物と依存関係を追加します。	成果物と依存関係を追加します。
   NuGet ベース (.NET) プロジェクトを操作する	拡張機能ベースのバンドル (Node.js) プロジェクトを NuGet パッケージ ベース (.NET) プロジェクトに変換します。 注: アセンブリのサポートが存在する前に作成した拡張バンドル ベース (Node.js) プロジェクトを変換するには、「Lib フォルダー内のアセンブリを使用するように NuGet パッケージ ベースのプロジェクトを移行する」も参照してください。
   独自の組み込みコネクタを作成します。	1. 拡張バンドル ベース (Node.js) プロジェクトを NuGet パッケージ ベース (.NET) プロジェクトに変換 します。 2. 組み込みのコネクタ作成を有効にします。

次に、ワークフロー デザイナーを開きます。

ワークフロー デザイナーを開く

プロジェクトがエクスプローラー ウィンドウで開いたら、デザイナーを開いてワークフローをビルドできるようにします。

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

Visual Studio Code でワークフロー デザイナーが開き、[ トリガーの追加] プロンプトが表示されます。次に例を示します。

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

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

ワークフローを作成するには、トリガーを使用してワークフローを開始し、最初に 1 つのアクションを追加します。 そうすることで、次のアクションを追加する前にワークフローをテストできます。 このワークフロー例では、次のトリガーとアクションを使用します。これは、総称して 操作と呼ばれます。

要求トリガーを追加する

1. ワークフロー デザイナーで、[ トリガーの追加] を選択します (まだ選択されていない場合)。

   [ トリガーの追加] ウィンドウが開き、使用可能なコネクタと操作グループから選択できるギャラリーが表示されます。次に例を示します。

   

2. [トリガーの追加] ウィンドウで、次の一般的な手順に従って、HTTP 要求を受信したときにという名前の要求トリガーを追加します。

   次の例では、 組み込み トリガーのみが表示されるように、組み込みオプションを選択します。

   

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

   

   注

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

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

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

1. デザイナーの [要求] トリガーで、次の一般的な手順に従って、[電子メールの送信 (V2)] という名前の Office 365 Outlook アクションを追加します。

   アクションが最初の結果に表示されない場合は、コネクタ名の横にある [ 詳細を表示] を選択します。次に例を示します。

   

2. アクションの認証ウィンドウが表示されたら、[ サインイン ] を選択してメール アカウントへの接続を作成します。

   

3. 以降のプロンプトに従って、資格情報を認証し、アクセスを許可し、Visual Studio Code への戻りを許可します。

   注

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

   1. Microsoft 認証プロンプトが表示されたら、Office 365 Outlook のユーザー アカウントを選択します。 表示された確認が必要なページで、[ アクセスを許可する] を選択します。

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

      

   3. 拡張機能で Microsoft Azure Tools を開くよう求められたら、[ 開く] を選択します。

      

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

4. 開いた [ 電子メール情報の送信 ] ウィンドウの [ パラメーター ] タブで、アクションに必要な情報を指定します。

   注

   アクション情報ウィンドウが自動的に開かなかった場合は、デザイナーの [ 電子メールの送信 ] アクションを選択します。

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

   例えば次が挙げられます。

   

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

標準ロジック アプリ プロジェクトの構造

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

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

これらの種類に基づいて、プロジェクトには多少異なるフォルダーやファイルが含まれる場合があります。 たとえば、Nuget パッケージベースのプロジェクトには、パッケージやその他のライブラリ ファイルを含む .bin フォルダーがあります。 拡張機能バンドルベースのプロジェクトには、この .bin フォルダーは含まれません。

一部のシナリオでは、たとえば、カスタムの組み込み操作を開発して実行する場合などに、アプリを実行するために NuGet パッケージベースのプロジェクトが必要です。 NuGet を使用するようにプロジェクトを変換する方法の詳細については、「組み込みコネクタの作成を有効にする」を参照してください。

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

MyWorkspaceName
| MyBundleBasedLogicAppProjectName
  || .vscode
  || Artifacts
     ||| Maps 
         |||| MapName1
         |||| ...
     ||| Rules
     ||| Schemas
         |||| SchemaName1
         |||| ...
  || lib
     ||| builtinOperationSdks
         |||| JAR
         |||| net472
     ||| custom
  || WorkflowName1
     ||| workflow.json
     ||| ...
  || WorkflowName2
     ||| workflow.json
     ||| ...
  || workflow-designtime
     ||| host.json
     ||| local.settings.json
  || .funcignore
  || connections.json
  || host.json
  || local.settings.json

プロジェクトのルート レベルには、他の項目と共に次のフォルダーとファイルがあります。

その他の開発セットアップ タスク

プロジェクトを作成した後も、Visual Studio Code を使用した Standard ロジック アプリのビルド、実行、およびデプロイに関する特定のローカル開発シナリオをサポートする他のセットアップ タスクが残っている可能性があります。 次のセクションでは、これらのシナリオのタスクについて説明します。

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

Webhook 操作は、操作を実行する前にイベントが発生するのを待機するワークフロー トリガーまたはアクションです。 具体的には、Webhook 操作は、HTTPS 要求が呼び出し元サービスまたはワークフローから到着するまで待機してから、操作を続行できます。 たとえば、Webhook には、 要求 トリガーや HTTP + Webhook トリガーなどの操作が含まれます。

Azure portal では、Azure Logic Apps ランタイムによって Webhook が呼び出し元サービスまたはワークフローに自動的にサブスクライブされます。 ランタイムは、Webhook のコールバック URL を呼び出し元サービスまたはワークフローに登録します。 Webhook は、呼び出し元がコールバック URL を使用して要求を送信するのを待機します。

ただし、Visual Studio Code では、Webhook 操作が正常に動作するようにいくつかのセットアップ タスクを完了する必要があります。 このシナリオでは、コールバック URL は localhost サーバー (http://localhost:7071/...) を使用するため、呼び出し元はインターネット経由でこの URL に直接要求を送信できません。

ローカルで実行されているワークフローでの Webhook 操作の場合は、 localhost サーバーを公開し、呼び出し元からの呼び出しをコールバック 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 アカウントに接続します。

   ngrok authtoken <your-authentication-token>

   詳細については、「手順 2: アカウントを接続する」を参照してください。

6. 次のコマンドを実行して、localhost ポート 7071 への HTTP トンネルを開きます。

   ngrok http 7071

   詳細については、「手順 3: 起動する」を参照してください。

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

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

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

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

1. Visual Studio Code のデザイナー上で、ワークフローで使用する Webhook 操作を追加してください。

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

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

   注

   プロンプトを無視すると、転送 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",
         <...>
      }
   }
   

   これらのアプリ設定の詳細については、「 標準ロジック アプリのアプリ設定とホスト設定の編集」を参照してください。

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

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

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

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

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

2. Workflows.<workflow-name>.operationOptions プロパティを追加し、値を WithStatelessRunHistory に設定します。次に例を示します。

   ウィンドウズ

   {
      "IsEncrypted": false,
      "Values": {
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "FUNCTIONS_WORKER_RUNTIME": "dotnet",
         "Workflows.<workflow-name>.OperationOptions": "WithStatelessRunHistory"
      }
   }
   

   macOS または Linux

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

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

4. 完了したら、実行履歴を無効にするには、 Workflows.<workflow-name>.OperationOptions プロパティを None に設定するか、プロパティとその値を削除します。

成果物と依存関係をプロジェクトに追加する

特定のシナリオでは、アセンブリなどの依存関係や、マップ、スキーマ、ルールなどの成果物を必要とする操作がワークフローに含まれる場合があります。 Visual Studio Code では、次のような項目をプロジェクト内の対応するフォルダーに追加できます。

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

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

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

   

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

"lib" フォルダー内のアセンブリを使用するように 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>

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

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

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

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

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

ワークフローをローカルで実行、デバッグ、テストする

次のセクションでは、ブレークポイントを設定し、デバッグ セッションを開始して、ワークフローをローカルで実行およびテストする方法を示します。

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

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

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

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

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

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

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

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

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

   注

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

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

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

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

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

ワークフローをデバッグしてテストする

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

1. ステートレス ワークフローがある場合は、ワークフロー の実行履歴を有効 にしてデバッグを容易にします。

2. [ 実行 ] メニューの [ デバッグの開始] (F5) を選択します。

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

   注

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

3. 次に、 要求 トリガーによって作成されたエンドポイントのコールバック URL を見つけます。

   1. [エクスプローラー] ウィンドウをもう一度開き、プロジェクトを表示します。

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

      

   3. コールバック URL をコピーして保存します。この例では、HTTP 要求が受信されたときトリガーの 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>

      

4. コールバック 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>

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

   

5. Visual Studio Code で、ワークフローの [概要] ページに戻ります。 [ 実行履歴] で、ワークフロー実行の状態を確認します。

   ヒント

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

   

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

   実行の状態	説明
   中止	外部に問題が発生したため、実行が停止したか、または完了しませんでした。たとえば、システムの停止や Azure サブスクリプションの中断などです。
   取り消された	実行がトリガーされ、開始されましたが、キャンセル要求を受け取りました。
   失敗	実行中に少なくとも 1 つのアクションが失敗しました。 ワークフローの後続のアクションは、エラーを処理するように設定されていません。
   実行中の	実行がトリガーされ、進行中です。ただし、この状態は、アクション制限または現在の料金プランによって制限されている実行に対しても表示されます。 ヒント:診断ログを設定すると、発生するスロットル イベントに関する情報を取得することができます。
   成功しました	実行は成功しました。 いずれかのアクションが失敗した場合、ワークフロー内の後続のアクションによってそのエラーが処理されます。
   タイムアウト	現在の継続時間が実行継続時間の制限を超えたため、実行がタイムアウトしました。これは、[実行履歴の保持期間 (日数)] という名前の設定によって制御されます。 実行の継続時間は、実行の開始時刻とその開始時刻での実行継続時間の制限を使用して計算されます。 注: 実行の継続時間が現在の "実行履歴の保持期間の制限" も超えている場合は、毎日のクリーンアップ ジョブによって実行履歴から実行が消去されます。これも、[実行履歴の保持期間 (日数)] 設定によって制御されます。 実行がタイムアウトしたか完了したかにかかわらず、保持期間は常に、実行の開始時刻と "現在の" 保持期間の制限を使用して計算されます。 そのため、処理中の実行の継続時間制限を短くすると、実行はタイムアウトします。ただし、実行が実行履歴に残るか消去されるかは、実行の継続時間が保持期間の制限を超えているかどうかに基づいて決まります。
   待機中	たとえば、その前のワークフロー インスタンスがまだ実行中である等の理由で、実行が開始されていないか、または一時停止しています。

6. 特定のワークフロー実行の各ステップの状態、入力、出力を表示するには、次のいずれかのステップを選択します。

   • [ 識別子 ] 列で、ワークフロー実行 ID を選択します。

   • [期間] 列の横にある、ワークフロー実行の省略記号 (...) メニューを開き、[実行を表示] を選択します。例:

     

   Visual Studio Code で実行の詳細ビューが開き、ワークフロー実行の各ステップの状態が表示されます。

   

   注

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

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

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

7. 各ステップの入力と出力を表示するには、目的のステップを選択します。次に例を示します。

   

   生の入力と出力を表示するには、[ 未加工の入力を表示 ] または [未加工の出力を表示] を選択します。

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

応答を返す

HTTP 要求の受信時トリガーで始まるワークフローがある場合、ワークフローは、Response という名前の要求アクションを使用して、最初の要求を送信した呼び出し元に応答を返すことができます。

1. ワークフロー デザイナーの [電子メールの送信] アクションで、次の一般的な手順に従って、[応答] という名前の要求アクションを追加します。

   

2. 応答アクションの情報ペインの [パラメーター] タブで、呼び出し元への応答に必要な情報を指定します。

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

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

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

      

      完了すると、 Response アクションの Body プロパティが [ 電子メールの送信 ] アクションの [本文 ] 出力値に設定されるようになりました。次に例を示します。

      

3. ワークフローを保存します。

ワークフローを再テストする

更新プログラムをテストするには、デバッガーを再実行し、「 ワークフローをローカルで実行、デバッグ、テストする」の手順と同様に、ワークフローをトリガーする別の要求を送信できます。

1. Visual Studio Code ツール バーの [実行 ] メニューから、[ デバッグの開始] (F5 キー) を選択します。

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

3. ワークフローの概要ページの [ 実行履歴] で、最新の実行の状態を確認し、実行の詳細ビューを開きます。

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

   

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

展開の準備をする

Azure portal に Standard ロジック アプリをデプロイする前に、このセクションで準備が必要な場合は、このセクションを確認してください。

ファイアウォール アクセスを設定する

環境にトラフィックを制限する厳密なネットワーク要件またはファイアウォールがある場合は、 Azure マネージド コネクタ、ホストコネクタ、共有コネクタによって作成され、 ワークフローで使用されるすべての接続に対するアクセス許可を設定する必要があります。

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

1. ロジック アプリ プロジェクトで、 local.settings.json ファイルを開きます。

2. 作成した接続ごとに、次の構文を使用する <connection-name>-ConnectionRuntimeUrl という名前のプロパティを見つけます。

   "<connection-name>-ConnectionRuntimeUrl": <connection-runtime-URL>

   たとえば、Office 365 接続と AS2 接続という接続を含 むサンプルlocal.settings.json ファイルがあるとします。 これらの接続では、 <connection-name>-ConnectionRuntimeUrl プロパティに次のそれぞれのサンプル値が使用されます。

   • Office 365: "office365-ConnectionRuntimeUrl": https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/office365/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1"

   • AS2: "as2-ConnectionRuntimeUrl": https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/as2/b1b1b1b1-cccc-dddd-eeee-f2f2f2f2f2f2

   サンプルlocal.settings.json ファイルは、次のバージョンのようになります。

   {
      "IsEncrypted": false,
      "Values": {
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "FUNCTIONS_WORKER_RUNTIME": "node",
         "APP_KIND": "workflowapp",
         "ProjectDirectoryPath": "c:\\Users\\<local-username>\\Desktop\\Visual Studio Code projects\\Azure Logic Apps\fabrikam-workflows\\Fabrikam-Workflows\\Fabrikam-Workflows",
         "WORKFLOWS_TENANT_ID": "<Microsoft-Entra-tenant-ID>",
         "WORKFLOWS_SUBSCRIPTION_ID": "<Azure-subscription-ID>",
         "WORKFLOWS_RESOURCE_GROUP_NAME": "Fabrikam-Workflows-RG",
         "WORKFLOWS_LOCATION_NAME": "westcentralus",
         "WORKFLOWS_MANAGEMENT_BASE_URI": "https://management.azure.com/",
         "as2-connectionKey": "<connection-key>",
         "as2-ConnectionRuntimeUrl": "https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/as2/b1b1b1b1-cccc-dddd-eeee-f2f2f2f2f2f2",
         "office365-connectionKey": "<connection-key>",
         "office365-ConnectionRuntimeUrl": "https://A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u.00.common.logic-<Azure-region>.azure-apihub.net/apim/office365/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1",
      }
   }
   

3. この情報を使用してファイアウォールを設定できるように、これらの接続ランタイム URL を安全な場所にコピーして保存します。

4. 準備ができたら、保存した URL を使用してファイアウォールを設定します。 詳しくは、次のドキュメントをご覧ください。

   • Azure Firewall Manager ポリシーの概要
   • Azure portal (クラシック) を使用して Azure Firewall をデプロイして構成します。

Azure にデプロイする

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

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

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

1. エクスプローラー ウィンドウで、プロジェクトのフォルダーとファイルの下にある空白領域の上にマウス ポインターを移動し、ショートカット メニューを開き、[ ロジック アプリに配置] を選択します。

   展開するためにファイルを開く必要はありませんが、展開する予定のすべてのファイルが保存されていることを確認してください。

   

   移動先の Standard ロジック アプリ リソースに対して、次のオプションが表示されます。 新しい Standard ロジック アプリを作成するか、Azure にデプロイされている既存の Standard ロジック アプリを選択できます。

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

2. デプロイ オプションでは、既存のターゲット ロジック アプリ リソースを作成するか、使用するかを選択します。

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

   

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

   1. 宛先ロジック アプリのグローバルに一意の名前を入力します。

      この例では、Fabrikam-Workflows-App を使用します。

      

   2. デプロイする場所として、Azure リージョンを選択します。

      この例では、 [米国中西部] を使用します。

   3. ホスティング プランの場合は、次のオプションから選択します。

      ホスティング プラン	説明
      ワークフロー標準	シングルテナントの Azure Logic Apps でホストされる新しい Standard ロジック アプリ リソースとしてデプロイします。
      ハイブリッド	独自のインフラストラクチャでホストされている Standard ロジック アプリとしてデプロイします。 注: このオプションを選択する前に、必要なインフラストラクチャを設定していることを確認してください。 詳細については、「 ハイブリッド展開を使用して標準ロジック アプリ用の独自のインフラストラクチャを設定する」を参照してください。

   4. Windows App Service プランの場合は、次のいずれかのオプションを選択します。

      • 新しい App Service プランを作成する
      • 選択した Azure リージョンの既存の App Service プラン (Windows ベースのプランのみ) から選択します (存在する場合)。

      この例では、[ 新しい App Service プランの作成] を選択します。

   5. 新しいプランでは、グローバルに一意の名前を指定し、価格レベルを選択します。

      この例では 、Fabrikam-Workflows-App-Service-Plan を使用し、 WS1 Workflow Standard レベルを選択します。

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

   6. ターゲットの Azure リソース グループで、最適なパフォーマンスを得るためのプロジェクトと同じリソース グループを選択します。

      この例では、 Fabrikam-Workflows-RG という名前の同じ以前に作成されたグループを使用します。

      注

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

   7. 実行履歴情報の保存を有効にするワークフローで Azure ストレージ アカウントを使用するには、次のオプションから選択します。

      • 新しいストレージ アカウントを作成する
      • 既存の Azure ストレージ アカウント (存在する場合) から選択します。

      この例では、[ 新しいストレージ アカウントの作成] を選択します。

   8. ストレージ アカウントのグローバルに一意の名前を入力します。 小文字と数字のみを使用できます。

      この例では 、fabrikamstorageaccount<number> を使用します。

   9. この例で SQL ストレージを使用するオプションについては、[いいえ] を選択 します。

      Standard ロジック アプリ ワークフロー用の SQL データベース ストレージの設定に関する手順に従って、ストレージに使用する SQL データベースを既に設定している場合は、[はい] を選択できます。

   10. ロジック アプリの診断ログとトレースを有効にする Application Insights リソースの場合は、次のオプションから選択します。

       • 新しい Application Insights リソースを作成する
       • ここではスキップします。 デプロイ後に Application Insights を設定できます。
       • 既存の Application Insights リソース (存在する場合) を選択します。

       次の使用例は、[ スキップ] を選択します。

       注

       • 使用する Application Insights リソースがある場合は、そのリソースを選択できます。

       • 診断ログとトレースを有効にできるように、現時点で新しい Application Insights リソースを作成するには、「 デプロイ時に Application Insights を有効にする」を参照してください。

       Application Insights の詳細については、次のドキュメントを参照してください。

       • Application Insights の概要
       • Application Insights リソースの作成と構成

       [今すぐスキップ] または既存の Application Insights リソースを選択すると、Visual Studio Code にデプロイを開始するための確認メッセージが表示されます。 また、このメッセージでは、パフォーマンスを最大限に高めるには、マネージド操作用の接続リソースをロジック アプリのリソースとワークフローと同じリソース グループに配置することをお勧めします。 Azure Logic Apps では、マネージド操作接続は個々の Azure リソースとして存在します。

       

4. デプロイの準備ができたら、確認メッセージで [デプロイ] を選択 します。

   Visual Studio Code では、ロジック アプリを Azure に発行するために必要なリソースの作成とデプロイが開始されます。

5. デプロイ プロセスを表示および監視するには、[ 表示 ] メニューの [ 出力] を選択します。

6. [出力] ウィンドウのツール バーで、スコープの一覧から Azure Logic Apps (Standard) を選択します。

   

   Visual Studio Code でロジック アプリの Azure へのデプロイが完了すると、ロジック アプリの作成が正常に完了したことを示すメッセージが表示されます。次に例を示します。

   

   ロジック アプリのリソースとワークフローが Azure でライブ、有効、実行されるようになりました。

デプロイ中に Application Insights を有効にする

ロジック アプリのデプロイ中に Application Insights で診断ログとトレースを有効にするには、次の手順に従います。

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

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

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

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

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

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

   2. ワークフロー トリガーとアクション名が Application Insights インスタンスに正しく表示されるかどうかを確認します。

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

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

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

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

   3. 必要に応じて、ロジック アプリが収集して Application Insights インスタンスに送信するトレース データの重大度レベルを調整します。

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

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

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

      次の表では、重大度レベルとそのトレースの種類について説明します。

      重大度レベル	トレースの種類
      重大	ロジック アプリ ワークフローの回復不能なエラーを示すログ。
      デバッグ	開発中の調査に使用できるログ。たとえば、受信と送信の HTTP 呼び出し。
      エラー	ワークフローの実行の失敗だが、ロジック アプリでの一般的なエラーではないものを示すログ。
      情報	ロジック アプリまたはワークフローでの一般的なアクティビティを追跡するログ。次のようなもの。 - トリガー、アクション、または実行が開始および終了したとき。 - ロジック アプリが開始または終了したとき。
      トレース	最も詳細なメッセージが含まれるログ。たとえば、ストレージ要求やディスパッチャーのアクティビティに加えて、ワークフロー実行アクティビティに関連するすべてのメッセージ。
      警告	ロジック アプリでの異常な状態だが、実行を妨げはしないものを強調して示すログ。

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

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

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

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

デプロイ後のタスク

次のセクションでは、ロジック アプリのデプロイが完了した後に実行するタスクについて説明します。

Azure portal でのデプロイの確認

Visual Studio Code から Azure portal にロジック アプリをデプロイした後、ロジック アプリがポータルに表示されることを確認します。 Azure リソースは、リソースの種類に基づいてポータルで整理およびグループ化されます。 Standard ロジック アプリを見つけるには、次の手順に従います。

1. Azure アカウントで Azure Portal にサインインします。

2. Azure タイトルの検索ボックスに、ロジック アプリ名を入力します。これは、[ リソース ] セクションに結果として表示されます。 ロジック アプリを選択してリソースを開きます。

   

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

4. [ ワークフロー ] ページで、ワークフローを選択します。

5. ワークフローのメニューの [ツール] で、[デザイナー] を選択します。 ワークフローが期待どおりに表示されることを確認します。

   

   これで、Azure portal でこのワークフローに変更を加えることができます。

6. ワークフローの実行履歴、入力、出力、その他の関連情報を表示できるように、 デプロイされたロジック アプリの監視エクスペリエンスを有効に してください。

デプロイされたロジック アプリの監視エクスペリエンスを有効にする

Azure portal で監視エクスペリエンスを使用して、デプロイされた Standard ロジック アプリ リソースのワークフロー実行履歴、入力、出力、関連情報を確認するには、まずロジック アプリ リソースでそのエクスペリエンスを有効にする必要があります。

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

2. リソース メニューの [API] で、[ CORS] を選択します。

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

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

   

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

ワークフローの実行中に、ロジック アプリ ワークフローは他のイベントと共にテレメトリを出力します。 このテレメトリを使用すると、ワークフローの実行状況と Azure Logic Apps ランタイムのしくみをより適切に把握できます。 Application Insights には、ほぼリアルタイムのテレメトリ (ライブ メトリック) を使用して、ロジック アプリの診断ログ、トレース、監視を有効にする機能が用意されています。 この機能は、テレメトリ データを使用して問題の診断、アラートの設定、グラフの作成を行うときに、エラーとパフォーマンスの問題をより簡単に調査するのに役立ちます。

• Application Insights をまだ設定していない場合は、Visual Studio Code からロジック アプリをデプロイした後、Azure portal でこの機能を有効にすることができます。 Azure には Application Insights リソースが必要ですが、事前に、またはデプロイ後にこの機能を有効にするときに、このリソースを 個別に 作成できます。

• Visual Studio Code からのデプロイ時に Application Insights を以前に設定した場合は、Azure portal でロジック アプリから Application Insights リソースを開くだけで済みます。

デプロイされたロジック アプリに対して Application Insights を有効にする

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

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

3. [Application Insights] ページで、[Application Insights を有効にする] を選択します。

4. Application Insights ページが更新されたら、[リソースの変更] セクションで、次のオプションから選択します。

   • 新しいリソースを作成する

     Azure は、現在のサブスクリプションとリソース グループを使用して、Application Insights と Log Analytics ワークスペースのリソースを作成します。 別のサブスクリプションとリソース グループを使用する場合は、「 新しい Application Insights リソースを作成する」を参照して、このページに戻ります。

     プロパティ	説明
     新しいリソース名	生成された名前を受け入れるか、別の名前を指定します。
     場所	Azure のリージョンを選択します。
     Log Analytics ワークスペース	既存のワークスペース (存在する場合) を選択します。 それ以外の場合は、既定のワークスペースが自動的に作成されます。 詳細については、「Log Analytics ワークスペースの概要」を参照してください。

   • 既存のリソースを選択します。

     1. Application Insights リソースの Azure サブスクリプションを選択します。

     2. Application Insights リソースを選択します。

5. 完了したら、ページ下部の [ 適用] を選択します。

ロジック アプリから Application Insights を開く

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

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

3. Application Insights ページで、Application Insights リソースのリンクを選択します。

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

• あらゆる場所で実行される Azure Logic Apps - Application Insights で監視する - パート 1
• あらゆる場所で実行される Azure Logic Apps - Application Insights で監視する - パート 2

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

デザイナーが開けない

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

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

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

   

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

   A host error has occurred during startup operation '<operation-ID>'.
   System.Private.CoreLib: The file 'C:\Users\<user-name>\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.
   

このエラーを解決するには、この場所 にある < フォルダーを削除し、デザイナーで > ファイルを開いて再試行します。

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

シングルテナントの 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 により拡張機能バンドルが最新バージョンに自動的に更新されます。

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

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

   ...\Users\<user-name>\.azure-functions-core-tools\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows

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

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

   ...\Users\<user-name>\.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 でのシングルテナントとマルチテナント
• Visual Studio Code でロジック アプリを管理する