Azure portal を使用してシングルテナント Azure Logic Apps でサンプル Standard ワークフローを作成する

  • [アーティクル]

適用対象: Azure Logic Apps (Standard)

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

注意

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

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

Screenshot showing the Azure portal with the designer for Standard logic app workflow.

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

  • Standard ロジック アプリ リソースを作成し、空の "ステートフル" ワークフローを追加します。
  • トリガーとアクションを追加します。
  • ワークフローの実行をトリガーします。
  • ワークフローの実行履歴とトリガー履歴を表示します。
  • デプロイの後で、Application Insights を有効にするか開きます。
  • ステートレス ワークフローの実行履歴を有効にします。

シングル テナントの Azure Logic Apps では、同じロジック アプリ リソースとテナントのワークフローは、ランタイムと同じプロセスで実行されるため、同じリソースを共有し、パフォーマンスが向上します。 シングルテナント Azure Logic Apps の詳細については、「シングルテナントとマルチテナントおよび統合サービス環境」を参照してください。

前提条件

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

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

    注意

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

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

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

  • このガイドのワークフローの例をテストするには、Request トリガーによって作成されたエンドポイントに呼び出しを送信できるツールが必要です。 このようなツールがない場合は、Postman をダウンロードしてインストールし、使用することができます。

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

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

  • 2022 年 10 月中旬以降、Azure portal の新しい Standard ロジック アプリ ワークフローでは、Azure Functions v4 が自動的に使用されます。 2022 年 11 月を通して、Azure portal の既存の Standard ワークフローは Azure Functions v4 に自動的に移行されます。 Standard ロジック アプリを NuGet ベースのプロジェクトとしてデプロイしたり、特定のバンドル バージョンにロジック アプリをピン留めした場合を除き、このアップグレードは、ユーザーからのアクションを必要とせず、ランタイムへの影響も与えないように設計されています。 ただし、例外が適用される場合、または Azure Functions v4 のサポートの詳細については、「Azure Logic Apps Standard で Azure Functions v4 がサポートされるようになりました」を参照してください。

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

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

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

    Screenshot showing Azure portal search box with logic apps entered and logic apps group selected.

  3. [ロジック アプリ] ページで [追加] を選択します。

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

    プロパティ 必要 値 説明
    サブスクリプション はい <Azure サブスクリプション名> Azure サブスクリプション名。
    リソース グループ はい <Azure リソース グループ名>< ロジック アプリと関連リソースを作成する Azure リソース グループ。 この名前は、リージョン間で一意である必要があり、文字、数字、ハイフン (-)、アンダースコア (_)、かっこ (())、ピリオド (.) のみを含めることができます。

    この例では、Fabrikam-Workflows-RG という名前のリソース グループを作成します。
    ロジック アプリ名 はい <ロジック アプリ名> ロジック アプリ リソースの名前。リージョン間で一意である必要があり、文字、数字、ハイフン (-)、アンダースコア (_)、かっこ (())、およびピリオド (.) のみを含めることができます。

    注: ロジック アプリの名前には自動的にサフィックス .azurewebsites.net が付けられます。なぜなら Standard ロジック アプリ リソースは、Azure Functions の機能拡張モデルを使用し、Azure Functions ランタイムの拡張機能としてホストされているシングルテナント Azure Logic Apps ランタイムで実行されるためです。 Azure Functions では、同じアプリの名前付け規則が使用されます。

    この例では、Fabrikam-Workflows という名前のロジック アプリを作成します。

  5. 選択を続ける前に、[プラン] セクションに移動します。 [プランの種類] で [標準] を選んで、標準プランに基づくロジック アプリの種類に適用される設定だけが表示されるようにします。

    [プランの種類] プロパティでは、ロジック アプリに使用するホスティング プランと課金モデルを指定します。 詳細については、「ホスティング プランと価格レベル」を参照してください。

    プランの種類 説明
    Standard 既定では、このロジック アプリの種類が選択されています。 ワークフローは、シングルテナントの Azure Logic Apps で実行され、Standard 課金モデルを使用します。
    従量課金プラン このロジック アプリの種類とワークフローは、グローバルなマルチテナント Azure Logic Apps で実行され、従量課金モデルを使用します。
    プロパティ 必要 値 説明
    Windows プラン はい <plan-name> 使用するプラン名。 既存のプラン名を選択するか、新しいプランの名前を指定します。

    この例では、My-App-Service-Plan という名前を使用します。

    注: Windows ベースの App Service プランのみがサポートされています。 Linux ベースの App Service プランは使用しないでください。
    料金プラン はい <pricing-tier> ロジック アプリとワークフローに使用する価格レベル。 選択した内容は、ロジック アプリとワークフローで使用する料金、コンピューティング、メモリ、およびストレージに影響します。

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

  6. 以下の選択を続けます。

    プロパティ 必要 値 説明
    発行 はい Workflow このオプションは、[プランの種類] が [標準] ロジック アプリの種類に設定されている場合にのみ、表示されて適用されます。 既定では、このオプションは [ワークフロー] に設定され、最初のワークフローを追加する空のロジック アプリ リソースが作成されます。

    注: 現時点では、Docker コンテナー オプションを使用するには Azure Arc enabled Kubernetes クラスター上に "カスタムの場所" が必要です。これは、Azure Arc 対応 Logic Apps (Standard) で使用できます。 ロジック アプリのリソースの場所、カスタムの場所、クラスターはすべて同じである必要があります。
    [リージョン] はい <Azure リージョン>< アプリの情報の格納に使用する Azure データセンター リージョン。 この例では、サンプル ロジック アプリを Azure の米国西部リージョンにデプロイします。

    - 以前に [Docker コンテナー] を選んだ場合は、[リージョン] の一覧からカスタムの場所を選びます。

    - 既存の App Service Environment v3 リソースにアプリをデプロイする場合は、[リージョン] の一覧からその環境を選ぶことができます。

    Note

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

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

    Screenshot showing Azure portal and page named Create Logic App.

  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 仮想ネットワークにアクセスできません。
    "オフ" ロジック アプリにはパブリック エンドポイントはありませんが、代わりに Azure 仮想ネットワーク内の通信用のプライベート エンドポイントがあり、その仮想ネットワークに分離されています。 プライベート エンドポイントは仮想ネットワーク内のエンドポイントと通信できますが、そのネットワーク内のクライアントからのみです。 また、この構成は、ロジック アプリのトラフィックがネットワーク セキュリティ グループによって制御されるか、仮想ネットワーク ルートの影響を受ける可能性があることも意味します。

    ロジック アプリが仮想ネットワーク内のエンドポイントにアクセスできるようにするには、適切なオプションを選択してください。

    ネットワーク インジェクションを有効にする 動作
    オン ロジック アプリ ワークフローは、仮想ネットワーク内のエンドポイントとプライベートかつ安全に通信できます。
    "オフ" ロジック アプリ ワークフローは、仮想ネットワーク内のエンドポイントと通信できません。

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

    1. [監視] タブの [Application Insights] で、 [Application Insights を有効にする] を [はい] に設定します (まだ選択されていない場合)。

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

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

    Screenshot showing Azure portal and new logic app resource settings.

    Note

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

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

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

    Screenshot showing Azure portal and finished deployment.

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

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

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

    Screenshot showing logic app resource menu with Workflows selected, and on the toolbar, Add is selected.

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

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

    Screenshot showing new blank stateful workflow named Stateful-Workflow.

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

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

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

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

トリガーの追加

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

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

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

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

    Screenshot showing the workflow designer and trigger information pane.

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

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

アクションを追加する

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

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

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

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

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

    Screenshot showing the designer, the pane named Send an email (V2) with Sign in button.

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

    注意

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

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

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

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

    Screenshot that shows the designer and the

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

    Note

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

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

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

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

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

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

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

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

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

    Screenshot that shows a selected item on designer with the opened information pane plus the selected ellipses button and

    ヒント

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

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

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

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

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

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

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

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

    Screenshot that shows the Azure portal and logic app menu with the

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

    Screenshot that shows the Azure portal and API Connection pane with

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

    Screenshot showing the selected property value named connectionRuntimeUrl.

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

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

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

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

  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*>

    Screenshot that shows the designer with the Request trigger and endpoint URL in the

    この例では、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 は、ロジックアプリの [概要] ペインの [Workflow URL](ワークフロー URL) プロパティで確認することもできます。

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

  3. 要求を送信して URL をテストするには、Postman を開くか、要求を作成して送信するための任意のツールを開きます。

    この例では、Postman を使用して続行します。 詳細については、Postman の概要に関するページを参照してください。

    1. Postman のツールバーで、 [新規] を選択します。

      Screenshot that shows Postman with New button selected

    2. [新規作成] ウィンドウの [構成要素] で、 [要求] を選択します。

    3. [要求の保存] ウィンドウの [要求名] で、要求の名前を指定します。たとえば、Test workflow trigger のように指定します。

    4. [保存先のコレクションまたはフォルダーの選択] で、 [コレクションの作成] を選択します。

    5. [すべてのコレクション] で、要求を整理するために作成するコレクションの名前を指定して Enter キーを押し、[<コレクション名> に保存] を選びます。 この例では、Logic Apps requests をコレクション名として使用します。

      Postman アプリの要求ペインが開き、Request トリガーのエンドポイント URL に要求を送信できるようになります。

      Screenshot that shows Postman with the opened request pane

    6. 要求ペインで、既定の要求メソッドとして現在は [GET] が表示されている、メソッド一覧の横にあるアドレス ボックスに、先ほどコピーした URL を貼り付けて、 [送信] を選択します。

      Screenshot that shows Postman and endpoint URL in the address box with Send button selected

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

      Screenshot that shows Outlook email as described in the example

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

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

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

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

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

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

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

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

Screenshot shows run details view with the status for each step in the workflow.

Screenshot shows inputs and outputs in the selected action named Send an email.

トリガー履歴を確認する

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

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

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

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

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

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

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

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

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

    Workflows.{yourWorkflowName}.OperationOptions

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

    Screenshot showing Standard logic app and pane named Add/Edit application setting with Workflows.{yourWorkflowName}.OperationOptions set to 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 が使用されている場合、これらの操作がデザイナーに表示されないことがあります。

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

注意

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

  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 でロジック アプリの [概要] ページに戻り、 [再起動] を選択します。

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

次のステップ