Azure portal を使用してサンプル Standard ロジック アプリ ワークフローを作成する

適用対象: Azure Logic Apps (Standard)

この攻略ガイドでは、受信 Web 要求を待機し、メール アカウントにメッセージを送信する自動化されたワークフローの例を作成する方法を示します。 具体的には、Standard ロジック アプリ リソースを作成します。これには、シングルテナントの Azure Logic Apps で実行される複数のステートフルおよびステートレス ワークフローを含めることができます。

• このRequest トリガーは、任意の呼び出し元からの受信要求を処理できる、呼び出し可能なエンドポイントを作成します。
• Office 365 Outlook コネクタでは、メールを送信するアクションが提供されます。

完了すると、ワークフローは次の大まかな例のようになります。

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

この例の操作は、ワークフローで使用できる 1,000 以上あるコネクタのうちの 2 つのコネクタから行います。 この例はクラウドベースですが、クラウド、オンプレミス、ハイブリッド環境で幅広いアプリ、データ、サービス、システムを統合するワークフローを作成できます。

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

一般的に使用されるパターンに従う事前構築済みテンプレートから Standard ロジック アプリ ワークフローを作成するには、「事前構築済みテンプレートから Standard ロジック アプリ ワークフローを作成する」を参照してください。

他のツールを使用して Standard ロジック アプリのワークフローを作成および管理するには、「Visual Studio Code を使って Standard ワークフローを作成する」を参照してください。 Visual Studio Code を使用すると、ローカルの開発環境でワークフローを開発、テスト、実行できます。

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

• シングルテナントとマルチテナント
• さまざまな環境を作成してデプロイする

前提条件

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

• Azure ストレージ アカウント。 お持ちでない場合は、事前に、またはロジック アプリの作成時にストレージ アカウントを作成できます。

  注意

  Standard ロジック アプリのリソースの種類は Azure Functions によって実行され、関数アプリに似たストレージ要件があります。 ステートフル ワークフローは、スケジュールでのキューの使用や、テーブルや BLOB へのワークフローの状態の格納など、ストレージ トランザクションを実行します。 これらのトランザクションには、ストレージの料金がかかります。 ステートフル ワークフローによって外部ストレージにデータが格納される方法の詳細については、「ステートフルとステートレスのワークフロー」を参照してください。

• Azure Logic Apps がサポートするメール プロバイダー (Office 365 Outlook、Outlook.com、Gmail など) のメール アカウント。 サポートされている他の電子メール プロバイダーについては、「Azure Logic Apps のコネクタ」をご覧ください。

  この例では、Office 365 Outlook と職場または学校アカウントを使用します。 別のメール アカウントを使う場合、おおよその手順は変わりませんが、ユーザー エクスペリエンスがやや異なることがあります。 Outlook.com を使用する場合は、代わりに個人用 Microsoft アカウントを使用してサインインします。

  Note

  Gmail コネクタの使用を希望する場合、ロジック アプリ ワークフローで制限なしにこのコネクタを使用できるのは、G-Suite ビジネス アカウントだけです。 Gmail コンシューマー アカウントを持っている場合は、Google によって承認された特定のサービスのみでこのコネクタを使用できるほか、認証に使用する Google クライアント アプリを Gmail コネクタで作成することができます。 詳細については、「Azure Logic Apps での Google コネクタのデータ セキュリティとプライバシー ポリシー」を参照してください。

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

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

  注意事項

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

• Standard ロジック アプリ リソースを App Service Environment v3 (ASEv3) - Windows プランのみにデプロイするには、まずこの環境リソースを作成する必要があります。 ロジック アプリを作成するときに、配置場所としてこの環境を選択できます。 詳細については、「リソースの種類と環境」と「App Service Environment を作成する」を参照してください。

• Standard ロジック アプリのワークフローから Premium 統合アカウントのプライベート エンドポイントへの通信を有効にするには、既存の Azure 仮想ネットワークが必要です。 ロジック アプリ、仮想ネットワーク、統合アカウントはすべて同じ Azure リージョンを使用する必要があります。 ロジック アプリと統合アカウントは、いずれも同じ仮想ネットワーク内に存在する必要があります。 詳細については、「仮想ネットワークの作成」をご覧ください。

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

ベスト プラクティスと推奨事項

デザイナーの応答性とパフォーマンスを最適なものにするには、次のガイドラインを確認してそのようにしてください。

• ワークフローごとに使用するアクションの数を 50 以下にします。 アクションの数がこれを超えると、デザイナーのパフォーマンスが低下する可能性があります。

• 必要に応じて、ビジネス ロジックを複数のワークフローに分割することを検討します。

• ロジック アプリ リソースあたりのワークフローの数を、10 から 15 個以下にします。

ロジック アプリのワークフローが多いほど、読み込み時間が長くなるリスクが高くなり、パフォーマンスに悪影響が及びます。 ダウンタイムなしのデプロイを必要とするミッション クリティカルなロジック アプリがある場合は、デプロイ スロットの設定を検討してください。

標準のロジック アプリ リソースを作成する

1. Azure portal で、Azure アカウントを使ってサインインします。

2. Azure portal の検索ボックスに「ロジック アプリ」と入力し、[ロジック アプリ] を選びます。

   

3. [ロジック アプリ] ページのツール バーで [追加] を選びます。

   [ロジック アプリの作成] ページが表示され、次のオプションが表示されます。

   プラン	説明
   従量課金プラン	マルチテナント Azure Logic Apps で実行され、課金に従量課金モデルを使用するワークフローを 1 つだけサポートするロジック アプリ リソースを作成します。
   Standard	複数のワークフローをサポートするロジック アプリ リソースを作成します。 次のオプションがあります。 - ワークフロー サービス プラン: ワークフローはシングルテナントの Azure Logic Apps で実行され、課金に Standard モデルを使用します。 - App Service Environment V3: ワークフローはシングルテナントの Azure Logic Apps で実行され、課金に App Service Environment プランを使用します。 - ハイブリッド (プレビュー): Kubernetes イベント ドリブン自動スケーリング (KEDA) を使用して、オンプレミスおよび複数のクラウドでワークフローが実行されます。 詳細については、「ハイブリッド デプロイの Standard ワークフローを作成する」を参照してください。

4. [ロジック アプリの作成] ページで、Standard (ワークフロー サービス プラン) を選択します。

   プランの種類	説明
   Standard	既定では、このロジック アプリの種類が選択されています。 ワークフローは、シングルテナントの Azure Logic Apps で実行され、Standard 価格モデルを使用します。
   従量課金プラン	このロジック アプリの種類とワークフローは、グローバルなマルチテナント Azure Logic Apps で実行され、従量課金価格モデルを使います。

5. [ロジック アプリの作成] ページの [基本] タブで、ロジック アプリに関する次の基本情報を指定します。

   プロパティ	必要	値	説明
   サブスクリプション	はい	<Azure サブスクリプション名>	Azure サブスクリプション名。 この例では、従量課金制を使用します。
   リソース グループ	はい	<Azure リソース グループ名><	ロジック アプリと関連リソースを作成する Azure リソース グループ。 この名前は、リージョン間で一意である必要があり、文字、数字、ハイフン (-)、アンダースコア (_)、かっこ (())、ピリオド (.) のみを含めることができます。 この例では、Fabrikam-Workflows-RG という名前のリソース グループを作成します。
   ロジック アプリ名	はい	<ロジック アプリ名>	ロジック アプリ リソースの名前。リージョン間で一意である必要があり、文字、数字、ハイフン (-)、アンダースコア (_)、かっこ (())、およびピリオド (.) のみを含めることができます。 注: ロジック アプリの名前には自動的にサフィックス .azurewebsites.net が付けられます。なぜなら Standard ロジック アプリ リソースは、Azure Functions の機能拡張モデルを使用し、Azure Functions ランタイムの拡張機能としてホストされているシングルテナント Azure Logic Apps ランタイムで実行されるためです。 Azure Functions では、同じアプリの名前付け規則が使用されます。 この例では、Fabrikam-Workflows という名前のロジック アプリ リソースを作成します。
   リージョン	はい	<Azure-region>	ロジック アプリの Azure データセンター リージョン。 この例では米国西部を使用します。
   Windows プラン	はい	<plan-name>	使用するプラン名。 既存のプラン名を選択するか、新しいプランの名前を指定します。 この例では、My-App-Service-Plan という名前を使用します。 注: Linux ベースの App Service プランは使用しないでください。 Windows ベースの App Service プランのみがサポートされています。
   料金プラン	はい	<pricing-tier>	ロジック アプリとワークフローに使用する価格レベル。 選択した内容は、ロジック アプリとワークフローで使用する料金、コンピューティング、メモリ、およびストレージに影響します。 詳細については、「ホスティング プランと価格レベル」を参照してください。

   Note

   可用性ゾーンの冗長性をサポートする Azure リージョンを選択した場合は、[ゾーン冗長性] セクションが有効になります。 このセクションには、ロジック アプリで可用性ゾーンの冗長性を有効にする選択肢があります。 ただし、現在サポートされている Azure リージョンには米国西部は含まれていないため、この例ではこのセクションを無視できます。 詳細については、「ゾーン冗長性と可用性ゾーンを使用してリージョンの障害からロジック アプリを保護する」を参照してください。

   完了すると、設定は次の例のようになります。

   

   Note

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

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

6. 終了したら、[次: ストレージ] を選択します。

7. [ストレージ] タブで、ロジック アプリに使用するストレージ ソリューションとホスティング プランに関する情報を指定します。

   プロパティ	必要	値	説明
   ストレージの種類	はい	- Azure ストレージ - SQL と Azure Storage	ワークフロー関連の成果物およびデータに使用するストレージの種類。 - Azure のみにデプロイする場合は、 [Azure Storage] を選択します。 - プライマリ ストレージとして SQL を使用し、セカンダリ ストレージとして Azure Storage を使用するには、 [SQL と Azure Storage] を選び、「シングルテナント Azure Logic Apps で Standard ロジック アプリの SQL データベース ストレージを設定する」を参照してください。 注: Azure リージョンにデプロイする場合は、引き続き Azure Storage アカウントが必要です。これは、Azure Logic Apps プラットフォームでロジック アプリの構成の 1 回限りのホスティングを完了するために使用されます。 ワークフローの状態、実行履歴、およびその他のランタイム成果物は、SQL データベースに格納されます。 Azure Arc クラスターでホストされているカスタムの場所へのデプロイでは、ストレージ プロバイダーとして SQL のみが必要です。
   ストレージ アカウント	はい	<Azure-storage-account-name>	ストレージ トランザクションに使用する Azure ストレージ アカウント。 このリソース名は、リージョン間で一意であり、数字と小文字のみを含む 3 から 24 文字である必要があります。 既存のアカウントを選択するか、新しいアカウントを作成します。 この例では、mystorageacct という名前のストレージ アカウントを作成します。

8. [ネットワーク] タブでは既定のオプションのままにして、次の例を実行できます。 ただし、実際のシナリオについては、次の適切なオプションを確認して選択してください。 ロジック アプリ リソースをデプロイした後で、この構成を変更することもできます。 詳細については、「プライベート エンドポイントを使って Standard ロジック アプリと Azure 仮想ネットワーク間のトラフィックをセキュリティで保護する」を参照してください。

   次の [パブリック アクセスの有効化] 設定は、ロジック アプリのエンドポイントに適用されます。これは、ロジック アプリが同じ仮想ネットワーク内の Azure リソース (たとえば、プライベート エンドポイントを持つ Premium 統合アカウント) と通信できるかどうかには影響しません。 このような Azure リソースにアクセスするには、ロジック アプリがこれらのリソースと同じ仮想ネットワークに存在する必要があります。

   パブリック アクセスを有効にする	動作
   オン	ロジック アプリには、インターネットに公開されている受信アドレスを持つパブリック エンドポイントがあります。 Azure 仮想ネットワークの外部にあるクライアントの場合、このエンドポイントを使用してロジック アプリにアクセスできますが、仮想ネットワークにはできません。
   "オフ"	ロジック アプリにはパブリック エンドポイントはありませんが、代わりに Azure 仮想ネットワーク内の通信用のプライベート エンドポイントがあり、その仮想ネットワーク内で分離されています。 プライベート エンドポイントは仮想ネットワーク内のエンドポイントと通信できますが、そのネットワーク内のクライアントからのみです。 また、この構成は、ロジック アプリのトラフィックがネットワーク セキュリティ グループによって制御されるか、仮想ネットワーク ルートの影響を受ける可能性があることも意味します。

   次の設定を使用して、仮想ネットワーク内のエンドポイントへの Standard ロジック アプリのアクセスを制御できます。

   ネットワーク インジェクションを有効にする	動作
   オン	ロジック アプリ ワークフローは、仮想ネットワーク内のエンドポイントとプライベートかつ安全に通信できます。 Premium 統合アカウントでロジック アプリとプライベート エンドポイント間の通信を有効にするには、このオプションを選択します。こうすることで、[仮想ネットワーク] セクションも使用できるようになります。 [仮想ネットワーク] の場合は、使用する Azure 仮想ネットワークを選択します。 この選択により、[受信アクセス] セクションと [送信アクセス] セクションを使用できるようになります。
   "オフ"	ロジック アプリ ワークフローは、仮想ネットワーク内のエンドポイントと通信できません。

   [ネットワーク インジェクションを有効にする] が [オン] に設定されている場合、仮想ネットワークを選択すると、次のセクションが表示されます。

   受信アクセス

   • プライベート エンドポイントの有効化: Standard ロジック アプリのプライベート エンドポイントに適用され、[パブリック アクセスの有効化] が [オフ] に設定されている場合にのみ使用できます。

   送信アクセス

   • VNet 統合を有効にする: Standard ロジック アプリと Premium 統合アカウントのプライベート エンドポイント間の通信を有効にするには、[オン] と、使用するサブネットを選択します。

9. 作成とデプロイの設定で Application Insights の使用がサポートされている場合は、必要な場合は次の手順に従って、ロジック アプリ ワークフローの診断ログとトレースを有効にすることができます。

   1. [監視] タブの [Application Insights] で、[Application Insights を有効にする] を [はい] に設定します。

   2. Application Insights の設定で、Application Insights の既存のインスタンスを選択するか、新しいインスタンスを作成する場合は、 [新規作成] を選択して、使用する名前を指定します。

10. Azure によってロジック アプリの設定が検証されたら、[確認および作成] タブで、[作成] を選択します。次に例を示します。

    

    Note

    この手順中に検証エラーが発生した場合は、エラーの詳細を開いて確認します。 たとえば、選択したリージョンが、作成しようとしているリソースのクォータに達する場合、別のリージョンの試行が必要になることがあります。

    Azure でデプロイが完了すると、ロジック アプリ リソースは自動的に有効になり、リソースが空で、まだワークフローを追加していないため、何も実行されません。

11. デプロイ完了ページで [リソースに移動] を選択して、空のワークフローを追加できるようにします。

    

空のワークフローを追加する

空のロジック アプリ リソースを作成したら、最初のワークフローを追加する必要があります。

1. Azure でリソースが開かれたら、ロジック アプリのメニューの [ワークフロー] で、[ワークフロー] を選択します。 [ワークフロー] ツール バーで、 [追加] を選択します。

   

2. [新しいワークフロー] ペインが開いたら、ワークフローの名前を指定し、[ステートフル] または [ステートレス] いずれかの状態の種類を選択します。 完了したら、[作成] を選択します。

   この例では、Stateful-Workflow という名前の空のステートフル ワークフローを追加します。 ワークフローは既定で有効になりますが、トリガーとアクションを追加するまでは何も行われません。

   

3. ワークフローの一覧から、空のステートフル ワークフローを選択します。

4. ワークフローのメニューの [開発者] で、 [デザイナー] を選択します。

   デザイナー サーフェスには、トリガー操作を選択するためのプロンプトが表示されます。 既定では、プロンプトは既に選択されているため、使用可能なトリガーを含むペインが既に開いているように見えます。

ここで、ワークフローを開始するトリガーを追加します。

トリガーの追加

このワークフローの例は、HTTP 要求の受信時という名前の組み込みの要求トリガーで始まります。 このトリガーは、他のサービスまたはロジック アプリ ワークフローが呼び出すことができるエンドポイントを作成し、それらの受信呼び出しまたは要求が到着するまで待機します。 組み込み操作は、Azure Logic Apps ランタイム内でネイティブかつ直接実行されます。

1. ワークフロー デザイナーで、空のワークフローが開いていること、およびデザイナー画面で [トリガーの追加] プロンプトが選択されていることを確認します。

2. 要求を検索用語として使用し、次の手順に従って、HTTP 要求の受信時という名前の組み込みの要求トリガーをワークフローに追加します。

   トリガーがデザイナーに表示されると、トリガーの情報ウィンドウが開き、トリガーのプロパティ、設定、およびその他のアクションが表示されます。

   

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

   ワークフローを初めて保存すると、そのワークフローが要求トリガーで開始されるときに、Azure Logic Apps によって、要求トリガーによって作成されるエンドポイントの URL が自動的に生成されます。 後でワークフローをテストするときに、この URL に要求を送信すると、トリガーが起動され、ワークフローの実行が開始されます。

アクションを追加する

このワークフローの例では、[メールを送信] という名前の Office 365 Outlook マネージド コネクタ アクションに続きます。 マネージド コネクタの操作は、Azure で実行され、ネイティブにかつ直接 Azure Logic Apps ランタイムで実行されます。

1. デザイナーで、追加したトリガーの下のプラス記号 (+) >+ を選びます。

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

2. 「office send an email」を検索用語として使用して、次の手順に従って、ワークフローに [メールの送信 (V2)] という名前の Office 365 Outlook アクションを追加します。

3. アクションの情報ペインの [接続の作成] タブで [サインイン] を選択して、メール アカウントへの接続を作成できるようにします。

   

4. メール アカウントへのアクセスを求めるダイアログが表示されたら、アカウントの資格情報でサインインします。

   注意

   "Failed with error: 'The browser is closed.'. Please sign in again" (エラーで失敗しました: ブラウザーは閉じられています。もう一度サインインしてください。) というエラーメッセージの場合、ブラウザーがサードパーティの Cookie をブロックしているかどうかを確認してください。 これらの Cookie がブロックされている場合は、Cookie を使用できるサイトの一覧に https://portal.azure.com を追加してみてください。 Incognito モードを使用している場合は、そのモードでの作業中に、サードパーティの Cookie がブロックされないことを確認します。

   必要な場合は、ページを再度読み込み、ワークフローを開き、もう一度メール アクションを追加してから、接続を作成してみてください。

   Azure によって接続が作成されると、 [メールの送信] アクションがデザイナーに表示され、既定で選択されます。 アクションが選択されていない場合は、アクションを選択して、その情報ペインも開きます。

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

   

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

   Note

   情報ペインの [設定]、[静的な結果]、または [実行までの期間] タブで変更を行うときは、タブを切り替えたり、デザイナーにフォーカスを変更したりする前に、必ず [完了] を選択して変更をコミットします。 そうしないと、デザイナーでの変更が保持されません。

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

7. トラフィックを制限する厳しいネットワーク要件またはファイアウォールが環境内にある場合は、ワークフロー内に存在するすべてのトリガーまたはアクション接続に対してアクセス許可を設定する必要があります。 完全修飾ドメイン名を検索するには、「ファイアウォール アクセス用のドメイン名を検索する」を参照してください。

   そうでない場合、ワークフローをテストするには、手動で実行をトリガーします。

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

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

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

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

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

  

  ヒント

  省略記号メニューが表示されない場合は、右上隅にある省略記号 [...] ボタンが情報ペインに表示されるよう、ブラウザーのウィンドウを十分に広げます。

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

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

ロジック アプリとワークフローで使用される受信および送信 IP アドレスを検索するには、次の手順を実行します。

1. ロジック アプリのメニューの [設定] で、 [ネットワーク] を選択します。

2. [ネットワーク] ページで、 [Inbound Traffic](受信トラフィック) と [Outbound Traffic](送信トラフィック) のセクションを見つけて確認します。

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

1. ロジック アプリのメニューの [ワークフロー] で、 [接続] を選択します。 [API 接続] タブで、接続のリソース名を選択します。ここに例を示します。

   

2. ブラウザーの右上隅に [JSON ビュー] が表示されるようにブラウザーの幅を広げて、 [JSON ビュー] を選択します。

   

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

   

4. 各接続について、関連する手順を繰り返します。

ワークフローをトリガーする

この例では、受信要求が要求トリガーによって受信されるとワークフローが実行され、トリガーによって作成されたエンドポイントの URL に受信要求が送信されます。 この URL は、ワークフローを初めて保存するときに、Azure Logic Apps によって自動的に生成されます。 そのため、この要求を送信してワークフローをトリガーする前に、この URL を見つけておく必要があります。

1. ワークフロー デザイナーで、HTTP 要求の受信時 という名前の要求トリガーを選択します。

2. 情報ペインが開いたら、[パラメーター] タブで、[HTTP POST の URL] プロパティを見つけます。 生成された URL をコピーするには、 [URL のコピー] (ファイルのコピー アイコン) を選択し、今のところは URL をどこかに保存しておきます。 URL は次の形式になっています。

   https://<*logic-app-name*>.azurewebsites.net:443/api/<*workflow-name*>/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<*shared-access-signature*>

   

   この例では、URL は次のようになります。

   https://fabrikam-workflows.azurewebsites.net:443/api/Fabrikam-Stateful-Workflow/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=xxxxxXXXXxxxxxXXXXxxxXXXXxxxxXXXX

   ヒント

   エンドポイント URL は、ロジックアプリの [概要] ページの [ワークフロー URL] プロパティで確認することもできます。

   1. リソース メニューで [概要] を選択します。
   2. [概要] ペインで、 [Workflow URL](ワークフロー URL) プロパティを見つけます。
   3. エンドポイント URL をコピーするには、エンドポイント URL のテキストの末尾までポインターを移動し、 [クリップボードにコピー] (ファイルのコピー アイコン) を選択します。

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

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

   GET https://fabrikam-workflows.azurewebsites.net:443/api/Fabrikam-Stateful-Workflow/triggers/manual/invoke?api-version=2020-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=xxxxxXXXXxxxxxXXXXxxxXXXXxxxxXXXX

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

   

ワークフロー実行履歴を確認する

ステートフル ワークフローを実行した後、実行全体、トリガー、各アクションの状態とそれらの入力と出力を含む、ワークフロー実行履歴を表示することができます。 Azure portal では、ワークフロー実行履歴とトリガー履歴が、ロジック アプリ リソース レベルではなくワークフロー レベルで表示されます。 詳細については、「ワークフロー実行履歴を確認する」と「トリガー履歴を確認する」を参照してください。

このワークフローの例では、ワークフロー実行履歴は次のサンプルのようになります。

トリガー履歴を確認する

ステートフル ワークフローの場合は、ワークフロー実行履歴とは別に、実行ごとのトリガー履歴を確認できます。これには、トリガーの状態と入力および出力が含まれます。 Azure portal では、トリガー履歴と実行履歴が、ロジック アプリ レベルではなくワークフロー レベルで表示されます。 詳細については、「トリガー履歴を確認する」を参照してください。

同じ入力を使ってワークフロー実行を再送信する

既存のステートフル ワークフロー実行の場合は、その実行に以前に使った入力と同じものを使用して、ワークフロー全体を再実行できます。 詳細については、「同じ入力を使ってワークフローを再実行する」を参照してください。

ストレージ アカウントへのマネージド ID アクセスを設定する

Standard ロジック アプリの既定では、接続文字列を使用して Azure Storage アカウントへのアクセスを認証します。 ただし、代わりに、アクセスを認証するようにユーザー割り当てマネージド ID を設定することができます。

1. Azure portal で、次の手順に従ってユーザー割り当てマネージド ID を作成します。

2. ユーザー割り当て ID からリソース ID を取得します。

   1. ユーザー割り当てマネージド ID メニューの [設定] で、[プロパティ] を選択します。

   2. Id プロパティからリソース ID をコピーして保存します。

3. ストレージ アカウントから、BLOB、Queue、Table の各サービスの URI を取得します。

   1. ストレージ アカウント メニューの [設定] で、[エンドポイント] を選択します。

   2. BLOB service、Queue サービス、Table サービスの URI をコピーして保存します。

4. お使いのストレージ アカウントに、ユーザー割り当て ID に必要なロールの割り当てを追加します。

   1. ストレージ アカウント メニューで、[アクセス制御 (IAM)] を選択します。

   2. [アクセス制御 (IAM)] ページのツール バーで、[追加] メニューから [ロールの割り当ての追加] を選択します。

   3. [職務権限ロール] タブで、次の各ロールをユーザー割り当て ID に追加します。

      • Storage Account Contributor
      • ストレージ BLOB データ所有者
      • ストレージ キュー データ共同作成者共同作成者
      • ストレージ テーブル データ共同作成者

   詳細については、「Azure portal を使用して Azure ロールを割り当てる」とロールの割り当ての概要に関する記事を参照してください。

5. 次の手順に従って、ユーザー割り当てマネージド ID を Standard ロジック アプリのリソースに追加します。

6. Standard ロジック アプリで "Workflow Service Plan" という名前のホスティング オプションを使用している場合は、ランタイム スケールの監視を有効にします。

   Note

   ロジック アプリで App Service Environment (ASE) v3 ホスティング オプションを使用している場合、ASE でランタイム スケール監視はサポートされていないため、この機能に関する手順はスキップしてください。

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

   2. [ワークフロー ランタイムの設定] タブの [ランタイム スケールの監視] で [オン] を選択します。

   3. [構成] ツール バーの [保存] を選択します。

7. Standard ロジック アプリで、リソース ID とサービス URI を設定します。

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

   2. [概要] ページのツール バーで、 [停止] を選択します。

   3. ロジック アプリ メニューの [設定] で、[環境変数] を選択します。

   4. [アプリ設定] タブで [追加] を選択して、次のアプリ設定と値を追加します。

      アプリ設定	値
      AzureWebJobsStorage__managedIdentityResourceId	ユーザー割り当てマネージド ID のリソース ID
      AzureWebJobsStorage__blobServiceUri	ストレージ アカウントの Blob service URI
      AzureWebJobsStorage__queueServiceUri	ストレージ アカウントの Queue サービス URI
      AzureWebJobsStorage__tableServiceUri	ストレージ アカウントの Table サービス URI
      AzureWebJobsStorage__credential	managedIdentity

   5. [アプリ設定] タブで、ストレージ アカウントに関連付けられた接続文字列に設定されている AzureWebJobsStorage というアプリ設定を削除します。

   6. 完了したら、[適用] を選択します。これにより、変更が保存され、ロジック アプリが再起動されます。

      変更が反映されるまでにしばらく時間がかかる場合があります。 必要に応じて、ロジック アプリのメニューの [概要] を選択し、ツール バーの [更新] を選択します。

      次のメッセージが表示される場合がありますが、これはエラーではなく、ロジック アプリには影響がありません。

      "AzureWebjobsStorage" アプリ設定が存在しません。

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

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

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

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

3. [アプリケーションの設定] タブで、 [新しいアプリケーション設定] を選択します。

4. [アプリケーション設定の追加/編集] ウィンドウで、 [名前] ボックスに次の操作オプションの名前を入力します。

   Workflows.{yourWorkflowName}.OperationOptions

5. [値] ボックスに、「WithStatelessRunHistory」と入力します。

   

6. このタスクを完了するには、 [OK] を選択します。 [構成] ペインのツール バーで、 [保存] を選択します。

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

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

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

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

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

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

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

3. [Application Insights] ペインで、[Application Insights をオンにする] を選択します。

4. ペインが更新されたら、下部で [適用]>[はい] を選択します。

5. [Application Insights] ペインで、[Application Insights データの表示] を選択します。

   Application Insights ダッシュボードが開いたら、ロジック アプリ ワークフローのメトリックまたはログを確認できます。 たとえば、データをグラフ化またはクエリするには、Application Insights リソース メニューの [監視] で、[メトリック] または [ログ] を選択します。

Application Insights を開く

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

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

3. [Application Insights] ペインで、[Application Insights データの表示] を選択します。

   Application Insights ダッシュボードが開いたら、ロジック アプリ ワークフローのメトリックまたはログを確認できます。 たとえば、データをグラフ化またはクエリするには、Application Insights リソース メニューの [監視] で、[メトリック] または [ログ] を選択します。

接続の表示

Microsoft によって管理されるコネクタを使用してワークフローで接続を作成する場合、これらの接続は独自のリソース定義で Azure リソースを分離し、グローバルなマルチテナント Azure でホストされます。 標準のロジック アプリ ワークフローでは、ネイティブに実行され、シングルテナントの Azure Logic Apps ランタイムを利用する組み込みのサービス プロバイダー コネクタを使用することもできます。 これらの接続を表示および管理するには、「接続の表示」を参照してください。

ロジック アプリ リソースを停止または開始する

ロジック アプリの無効化または有効化に関する記事の手順に従います。

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

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

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

この問題を解決するには、次の手順に従って古いバージョンを削除し、拡張機能バンドルを最新バージョンに自動的に更新できるようにします。

1. Azure portal でロジック アプリを停止します。

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

   2. [概要] ペインのツール バーで、 [停止] を選択します。

2. ロジック アプリのメニューの [開発ツール] で、 [高度なツール] を選択します。

3. [高度なツール] ペインで、 [移動] を選択します。これにより、ロジック アプリ用の Kudu 環境が開きます。

4. Kudu のツール バーで、 [Debug console](デバッグ コンソール) メニューを開き、 [CMD] を選択します。

   コンソール ウィンドウが開き、コマンド プロンプトを使用してバンドル フォルダーを参照できるようになります。 または、コンソール ウィンドウの上に表示されるディレクトリ構造を参照することもできます。

5. 次のフォルダーを参照します。そこには、既存のバンドルのバージョン管理されたフォルダーが含まれています。

   ...\home\data\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows

6. 既存のバンドルのバージョン フォルダーを削除します。 コンソール ウィンドウで、次のコマンドを実行します。{bundle-version} を既存のバージョンに置き換えます。

   rm -rf {bundle-version}

   例: rm -rf 1.1.3

   ヒント

   "アクセス許可が拒否されました" や "ファイルが使用されています" などのエラーが発生する場合は、ブラウザーでページを更新し、フォルダーが削除されるまで前の手順をもう一度試してください。

7. Azure portal でロジック アプリの [概要] ページに戻り、[再起動] を選択します。

   ポータルにより、最新のバンドルが自動的に取得されて使用されます。

次のステップ

• Azure Logic Apps でワークフロー実行状態の監視、トリガー実行履歴とワークフロー実行履歴の確認、アラートの設定を行う方法