シングルテナントの Azure Logic Apps で Standard ロジック アプリのホストとアプリの設定を編集する

  • [アーティクル]

適用対象: Azure Logic Apps (Standard)

"シングルテナント" の Azure Logic Apps では、Standard ロジック アプリの "アプリ設定" で、そのロジック アプリの "すべてのワークフロー" に影響を与えるグローバル構成オプションを指定します。 ただし、これらの設定は、このようなワークフローが "ローカル開発環境" で実行される場合に "のみ" 適用されます。 これらのアプリ設定は、ローカルで実行されているワークフローから "ローカル環境変数" としてアクセスでき、環境間で変わることが多い値に対して、ローカル開発ツールで使用されます。 たとえば、これらの値には接続文字列を含めることができます。 Azure にデプロイするとき、アプリ設定は無視され、デプロイには含まれません。

また、ロジック アプリには "ホスト設定" もあります。これは、"ローカルと Azure のどちらで実行される場合でも" そのロジック アプリ内の "すべてのワークフロー" に適用されるランタイム構成の設定と値を指定するもので、例として、スループット、容量、データ サイズなどの既定値があります。

アプリ設定、パラメーター、デプロイ

"マルチテナント" の Azure Logic Apps において、デプロイは Azure Resource Manager テンプレート (ARM テンプレート) に依存しており、それによってロジック アプリとインフラストラクチャの両方のリソース プロビジョニングが組み合わされて処理されます。 この設計では、さまざまな開発、テスト、運用環境でロジック アプリの環境変数を維持する必要がある場合に、課題が生じます。 ARM テンプレート内のすべては、デプロイ時に定義されます。 1 つの変数を変更するだけでよい場合も、すべてを再デプロイする必要があります。

"シングルテナント" の Azure Logic Apps の場合は、アプリとインフラストラクチャの間でリソースのプロビジョニングを分離できるため、デプロイが簡単になります。 "パラメーター" を使用して、環境間で変わる可能性のある値を抽象化できます。 ワークフローで使用するパラメーターを定義することで、まずワークフローの設計に集中し、後で環境固有の変数を挿入できます。 アプリ設定とパラメーターを使用して、実行時に環境変数を呼び出して参照できます。 そうすることで、頻繁に再デプロイする必要がなくなります。

アプリ設定は、Azure Key Vault と統合できます。 接続文字列やキーなど、セキュリティで保護された文字列を直接参照できます。 デプロイ時に環境変数を定義できる Azure Resource Manager テンプレート (ARM テンプレート) と同様に、ロジック アプリのワークフロー定義内にアプリ設定を定義できます。 そうしておいて、接続エンドポイントやストレージ文字列などの動的に生成されるインフラストラクチャ値を取得できます。 ただし、アプリ設定にはサイズの制限があり、Azure Logic Apps の特定の領域からは参照できません。

Note

Key Vault を使用する場合は、パスワード、資格情報、証明書などのシークレットのみを確実に格納してください。 ロジック アプリ ワークフロー内では、ワークフロー デザイナーが呼び出す必要のあるシークレット以外の値 (URL パスなど) を格納する目的で Key Vault を使用しないでください。 デザイナーは、Key Vault リソースの種類を参照するアプリ設定を逆参照できないため、エラーが発生し、呼び出しが失敗します。 シークレット以外の値の場合は、アプリ設定内に直接格納します。

デプロイ用にロジック アプリを設定する方法の詳細については、次のドキュメントを参照してください。

Visual Studio Code プロジェクトの構造

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 ファイルにはシークレットが含まれる場合があるため、必ずこのファイルもプロジェクトのソース管理から除外してください。

アプリ設定のリファレンス - local.settings.json

Visual Studio Code で、ロジック アプリ プロジェクトのルート レベルにある local.settings.json ファイルには、ローカル開発環境での実行中にそのロジック アプリ内の "すべてのワークフロー" に影響を与える、グローバル構成オプションが含まれています。 ワークフローがローカルで実行されている場合、これらの設定はローカル環境変数としてアクセスされます。それらの値は、多くの場合、ワークフローを実行するさまざまな環境間で変わる可能性があります。 これらの設定を表示および管理するには、「アプリ設定の管理 - local.settings.json」をご確認ください。

Azure Logic Apps のアプリ設定は、Azure Functions または Azure Web Apps のアプリ設定と同様に機能します。 以前にこれらの他のサービスを使用したことがある場合は、既にアプリ設定に慣れていることもあるでしょう。 詳細については、「Azure Functions のアプリ設定のリファレンス」と「Azure Functions Core Tools の操作」の「ローカル設定ファイル」をご確認ください。

設定 既定値 説明
AzureWebJobsStorage なし Azure ストレージ アカウントの接続文字列を設定します。 詳細については、「AzureWebJobsStorage」を参照してください。
FUNCTIONS_WORKER_RUNTIME node ロジック アプリのリソースとワークフローとともに使うために言語ワーカー ランタイムを設定します。 ただし、複数言語のサポートが自動的に有効になっているため、この設定は不要になりました。

詳細については、「FUNCTIONS_WORKER_RUNTIME」を参照してください。
ServiceProviders.Sftp.FileUploadBufferTimeForTrigger 00:00:20
(20 秒)		 最終変更のタイムスタンプが現在の時刻よりも後のファイルを無視するようにバッファー時間を設定します。 この設定は、大きなファイルの書き込みに時間がかかる場合に役に立ちます。また、部分的に書き込まれたファイルのデータのフェッチを回避することができます。
ServiceProviders.Sftp.OperationTimeout 00:02:00
(2 分)		 任意の操作に対して、タイムアウトするまでの待機時間を設定します。
ServiceProviders.Sftp.ServerAliveInterval 00:30:00
(30 分)		 指定した期間内にサーバーとのデータ交換が発生しなかった場合に、SSH 接続をアクティブに保つために "キープ アライブ" メッセージを送信します。
ServiceProviders.Sftp.SftpConnectionPoolSize 2 個の接続 各プロセッサがキャッシュできる接続数を設定します。 キャッシュできる続数の総数は、ProcessorCount に設定値を掛けた値です。
ServiceProviders.MaximumAllowedTriggerStateSizeInKB 10 KB (1,000 ファイル以下) トリガー状態エンティティのサイズをキロバイト単位で設定します。これは監視対象フォルダー内のファイル数に比例し、ファイルの検出に使われます。 ファイル数が 1,000 個を超える場合は、この値を増やします。
ServiceProviders.Sql.QueryTimeout 00:02:00
(2 分)		 SQL サービス プロバイダーの操作の要求タイムアウト値を設定します。
WEBSITE_LOAD_ROOT_CERTIFICATES なし 信頼するルート証明書のサムプリントを設定します。
Workflows.Connection.AuthenticationAudience なし マネージド (Azure ホステッド) 接続を認証するための対象ユーザーを設定します。
Workflows.CustomHostName なし ワークフロー URL と入出力 URL に使用するホスト名 ("logic.contoso.com" など) を設定します。 カスタム DNS 名を構成する方法については、「既存のカスタム DNS 名を Azure App Service にマップする」および「Azure App Service で TLS/SSL バインドを使用してカスタム DNS 名をセキュリティで保護する」を参照してください。
Workflows.<workflowName>.FlowState なし <<> の状態を設定します。
Workflows.<workflowName>.RuntimeConfiguration.RetentionInDays なし <workflowName> の実行履歴を保持する期間を日数で設定します。
Workflows.RuntimeConfiguration.RetentionInDays 90 日 実行の開始後、ワークフローの実行履歴を保持する期間を日数で設定します。
Workflows.WebhookRedirectHostUri なし Webhook コールバック URL に使用するホスト名を設定します。

アプリ設定の管理 - local.settings.json

アプリ設定を追加、更新、または削除するには、Azure portal、Visual Studio Code、Azure CLI、または ARM (Bicep) の各テンプレートについて、以下のセクションを選択してご確認ください。 ロジック アプリ固有のアプリ設定については、「使用可能なアプリ設定のリファレンス ガイド - local.settings.json」をご確認ください。

ポータルのアプリ設定を見る

  1. Azure portal の検索ボックスでロジック アプリを検索し、開きます。

  2. ロジック アプリのナビゲーション メニューにある [設定] で、[環境変数] を選択します。

  3. [環境変数] ページで、 [アプリケーション設定] タブで、ロジック アプリのアプリ設定を確認します。

    これらの設定の詳細については、「使用可能なアプリ設定のリファレンス ガイド - local.settings.json」をご確認ください。

  4. すべての値を表示するには、 [値を表示する] を選択します。 または、1 つの値を表示するには、[値] 列で、値の横にある [目] を選択します。

ポータルのアプリの設定を追加する

  1. [アプリの設定] タブの、リストの下部にある [名] 列に、新しい設定の キー または名前を入力します。

  2. [値] には、新しい設定の値を入力します。

  3. 新しい キーと値 のペアを作成する準備ができたら、[適用する] を選択します。

    アプリ設定ページと Standard ロジック アプリ リソースの値を含む Azure portal を示すスクリーンショット。

ホスト設定のリファレンス - host.json

Visual Studio Code で、ロジック アプリ プロジェクトのルート レベルにある host.json メタデータ ファイルには、ローカルと Azure のどちらで実行されている場合でもロジック アプリ リソース内の "すべてのワークフロー" に適用される、ランタイム設定と既定値が含まれています。 これらの設定を表示および管理するには、「ホスト設定の管理 - host.json」をご確認ください。 また、関連する制限の情報については、Azure Logic Apps の制限と構成に関するドキュメントも参照してください。

ジョブ オーケストレーションのスループット

これらの設定は、シングルテナントの Azure Logic Apps でワークフロー操作を実行するためのスループットと容量に影響します。

設定 既定値 説明
Jobs.BackgroundJobs.DispatchingWorkersPulseInterval 00:00:01
(1 秒)		 前のポーリングでジョブが返されなかった場合にジョブ ディスパッチャーでジョブ キューをポーリングする間隔を設定します。 ジョブ ディスパッチャーは、前のポーリングでジョブが返された直後にキューをポーリングします。
Jobs.BackgroundJobs.NumPartitionsInJobDefinitionsTable 4 個のジョブ パーティション ジョブ定義テーブル内のジョブ パーティションの数を設定します。 この値を使用して、パーティション ストレージの制限によって実行スループットがどれだけ影響を受けるかを制御します。
Jobs.BackgroundJobs.NumPartitionsInJobTriggersQueue 1 個のジョブ キュー ジョブで処理する、ジョブ ディスパッチャーによって監視されるジョブ キューの数を設定します。 この値は、ジョブ キューが存在するストレージ パーティションの数にも影響します。
Jobs.BackgroundJobs.NumWorkersPerProcessorCount 192 個のディスパッチャー ワーカー インスタンス プロセッサ コアあたりの "ディスパッチャー ワーカー インスタンス" または "ジョブ ディスパッチャー" の数を設定します。 この値は、コアあたりのワークフロー実行数に影響します。
Jobs.BackgroundJobs.StatelessNumWorkersPerProcessorCount 192 個のディスパッチャー ワーカー インスタンス プロセッサ コアあたり、ステートレス実行あたりの "ディスパッチャー worker インスタンス" または "ジョブ ディスパッチャー" の数を設定します。 この値は、1 回の実行あたりに処理される同時ワークフロー アクションの数に影響します。

次の両方の設定は、Standard ロジック アプリ内で指定されたワークフローを手動で停止して、直ちに削除するために使用されます。

Note

これらの設定は慎重に使用し、負荷およびパフォーマンス テスト環境などの非運用環境内でのみご使用ください。これらの操作を元に戻したり、復旧したりすることはできません。

設定 既定値 説明
Jobs.CleanupJobPartitionPrefixes なし 指定したワークフローのすべての実行ジョブを直ちに削除します。
Jobs.SuspendedJobPartitionPartitionPrefixes なし 指定したワークフローの実行ジョブを停止します。

次の例はこれらの設定の構文を示しており、各ワークフロー ID の後にコロン (:) が続き、セミコロン (;) で区切られています。

"Jobs.CleanupJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2:",
"Jobs.SuspendedJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2>:"

繰り返しベースのトリガー

設定 既定値 説明
Microsoft.Azure.Workflows.ServiceProviders.MaximumAllowedTriggerStateSizeInKB 1 KB 組み込み SFTP トリガーなどの繰り返しベースのトリガーについて、トリガー状態の最大許容サイズを設定します。 トリガー状態により、サービス プロバイダーの複数の繰り返しベースのトリガーの間でデータが保持されます。

重要: ストレージのサイズに基づき、この値の設定が高くなりすぎないようにしてください。ストレージとパフォーマンスに悪影響を及ぼす可能性があります。

トリガーのコンカレンシー

次の設定は、組み込みのサービス プロバイダー ベースのコネクタの繰り返しベースのトリガーで始まるワークフローでのみ機能します。 関数ベースのトリガーで始まるワークフローの場合で、サポートされている場合はバッチ処理を設定してみることをお勧めします。 ただし、バッチ処理が必ずしも適切な解決策であるとは限りません。 たとえば、Azure Service Bus トリガーでは、バッチがロック期間を超えてメッセージを保持する可能性があります。 その結果、そのようなメッセージに対する完了や破棄などのアクションは失敗します。

設定 既定値 説明
Runtime.Trigger.MaximumRunConcurrency 実行数 100 トリガーによって開始できる同時実行の最大数を設定します。 この値は、トリガーの同時実行の定義に表示されます。
Runtime.Trigger.MaximumWaitingRuns 実行数 200 同時実行の最大数に達した後に待機できる実行の最大数を設定します。 この値は、トリガーの同時実行の定義に表示されます。 詳しくは、「実行待機の制限を変更する」をご参照ください。

実行継続時間および履歴保有

設定 既定値 説明
Runtime.Backend.FlowRunTimeout 90.00:00:00
(90 日)		 タイムアウトを強制するまでの、ワークフローの実行を継続できる時間。 この設定の最小値は 7 日です。

重要: この値は必ず Workflows.RuntimeConfiguration.RetentionInDays という名前のアプリ設定の値と等しいかそれより小さくする必要があります。 そうしないと、関連付けられているジョブが完了する前に実行履歴が削除される可能性があります。
Runtime.FlowMaintenanceJob.RetentionCooldownInterval 7.00:00:00
(7 日)		 保持する必要がなくなった実行履歴を確認してから削除するまでの間隔として、日数で期間を設定します。

実行アクション

設定 既定値 説明
Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout 00:10:00
(10 分)		 実行するワークフロー アクション ジョブがタイムアウトして再試行するまでの時間を設定します。

入力と出力

設定 既定値 説明
Microsoft.Azure.Workflows.TemplateLimits.InputParametersLimit 50 従量課金ロジック アプリをエクスポートすることによって作成された Standard ロジック アプリについて、クロス環境ワークフロー パラメーターの既定の制限を最大 500 まで変更します。
Runtime.ContentLink.MaximumContentSizeInBytes 104857600 バイト 単一のトリガーまたはアクションで入力または出力に含めることができる最大サイズをバイト数で設定します。
Runtime.FlowRunActionJob.MaximumActionResultSize 209715200 バイト 単一のアクションで保持できる入力と出力の組み合わせの最大サイズをバイト単位で設定します。

改ページ位置の自動修正

設定 既定値 説明
Runtime.FlowRunRetryableActionJobCallback.MaximumPageCount 1000 ページ 操作で改ページがサポートされ、有効になっている場合に、実行時に返すまたは処理するページの最大数を設定します。

チャンキング

設定 既定値 説明
Runtime.FlowRunRetryableActionJobCallback.MaximumContentLengthInBytesForPartialContent 1073741824 バイト 操作でチャンク処理がサポートされ、有効になっている場合に、ダウンロードまたはアップロードされるコンテンツの最大サイズをバイト単位で設定します。
Runtime.FlowRunRetryableActionJobCallback.MaxChunkSizeInBytes 52428800 バイト 操作に対してチャンク処理がサポートされ、有効になっている場合、各コンテンツ チャンクの最大サイズをバイト単位で設定します。
Runtime.FlowRunRetryableActionJobCallback.MaximumRequestCountForPartialContent 1000 個の要求 操作でチャンク処理がサポートされ、有効になっている場合に、1 回のアクション実行でコンテンツをダウンロードするために行うことができる要求の最大数を設定します。

コンテンツをインラインで格納するか、BLOB を使用する

設定 既定値 説明
Runtime.FlowRunEngine.ForeachMaximumItemsForContentInlining 20 項目 For each ループの実行中、各項目の値は、他のメタデータと一緒にテーブル ストレージ内にインラインで、または BLOB ストレージに個別に格納されます。 他のメタデータと一緒にインラインで格納する項目の数を設定します。
Runtime.FlowRunRetryableActionJobCallback.MaximumPagesForContentInlining 20 ページ BLOB ストレージに格納する前に、テーブル ストレージにインライン コンテンツとして格納するページの最大数を設定します。
Runtime.FlowTriggerSplitOnJob.MaximumItemsForContentInlining 40 項目 SplitOn 設定で配列項目が複数のワークフロー インスタンスに分割される場合、各項目の値は、他のメタデータと一緒にテーブル ストレージ内にインラインで、または BLOB ストレージに個別に格納されます。 インラインで格納する項目の数を設定します。
Runtime.ScaleUnit.MaximumCharactersForContentInlining 8192 文字 BLOB ストレージに格納する前に、テーブル ストレージにインラインで格納する操作の入力および出力文字数の最大数を設定します。

For each ループ

設定 既定値 説明
Runtime.Backend.FlowDefaultForeachItemsLimit 100000 配列項目 "ステートフル ワークフロー" に対して、For each ループ内で処理する配列項目の最大数を設定します。
Runtime.Backend.FlowDefaultSplitOnItemsLimit 100000 配列項目 SplitOn の設定に基づいて、バッチ解除つまり複数のワークフロー インスタンスへの分割を行う配列項目の最大数を設定します。
Runtime.Backend.ForeachDefaultDegreeOfParallelism 20 イテレーション For each ループ内のコンカレント イテレーション (並列処理の次数) の既定の数を設定します。 順次実行するには、値を 1 に設定します。
Runtime.Backend.Stateless.FlowDefaultForeachItemsLimit 100 項目 "ステートレス ワークフロー" に対して、For each ループ内で処理する配列項目の最大数を設定します。

Until ループ

設定 既定値 説明
Runtime.Backend.MaximumUntilLimitCount 5000 イテレーション "ステートフル ワークフロー" の場合は、Until アクションの Count プロパティの可能な最大数を設定します。
Runtime.Backend.Stateless.FlowRunTimeout 00:05:00
(5 分)		 ステートレス ワークフロー内の Until ループの最大待機時間を設定します。
Runtime.Backend.Stateless.MaximumUntilLimitCount 100 イテレーション "ステートレス ワークフロー" の場合は、Until アクションの Count プロパティの可能な最大数を設定します。

変数

設定 既定値 説明
Runtime.Backend.DefaultAppendArrayItemsLimit 100000 配列項目 配列型の変数内の項目の最大数を設定します。
Runtime.Backend.VariableOperation.MaximumStatelessVariableSize ステートレス ワークフロー: 1024 文字 ステートレス ワークフローで使用した場合に、変数に格納できるコンテンツの最大サイズを文字数で設定します。
Runtime.Backend.VariableOperation.MaximumVariableSize ステートフル ワークフロー: 104857600 文字 ステートフル ワークフローで使用した場合に、変数に格納できるコンテンツの最大サイズを文字数で設定します。

組み込みの HTTP 操作

設定 既定値 説明
Runtime.Backend.HttpOperation.DefaultRetryCount 再試行回数 4 HTTP トリガーとアクションの既定の再試行回数を設定します。
Runtime.Backend.HttpOperation.DefaultRetryInterval 00:00:07
(7 秒)		 HTTP トリガーとアクションの既定の再試行間隔を設定します。
Runtime.Backend.HttpOperation.DefaultRetryMaximumInterval 01:00:00
(1 時間)		 HTTP トリガーとアクションの最大再試行間隔を設定します。
Runtime.Backend.HttpOperation.DefaultRetryMinimumInterval 00:00:05
(5 秒)		 HTTP トリガーとアクションの最小再試行間隔を設定します。
Runtime.Backend.HttpOperation.MaxContentSize 104857600 バイト トリガーではなく、HTTP アクションのみの最大要求サイズを、バイト単位で設定します。 詳細については、制限に関するページを参照してください。
Runtime.Backend.HttpOperation.RequestTimeout 00:03:45
(3 分 45 秒)

注: 既定値も最大値です。		 HTTP トリガーとアクションの要求タイムアウト値を設定します。

組み込みの HTTP Webhook 操作

設定 既定値 説明
Runtime.Backend.HttpWebhookOperation.DefaultRetryCount 再試行回数 4 HTTP Webhook トリガーとアクションの既定の再試行回数を設定します。
Runtime.Backend.HttpWebhookOperation.DefaultRetryInterval 00:00:07
(7 秒)		 HTTP Webhook トリガーとアクションの既定の再試行間隔を設定します。
Runtime.Backend.HttpWebhookOperation.DefaultRetryMaximumInterval 01:00:00
(1 時間)		 HTTP Webhook トリガーとアクションの最大再試行間隔を設定します。
Runtime.Backend.HttpWebhookOperation.DefaultRetryMinimumInterval 00:00:05
(5 秒)		 HTTP Webhook トリガーとアクションの最小再試行間隔を設定します。
Runtime.Backend.HttpWebhookOperation.DefaultWakeUpInterval 01:00:00
(1 時間)		 HTTP Webhook トリガーとアクション ジョブの既定のウェイクアップ間隔を設定します。
Runtime.Backend.HttpWebhookOperation.MaxContentSize 104857600 バイト トリガーではなく、HTTP Webhook アクションのみの最大要求サイズを、バイト単位で設定します。 詳細については、制限に関するページを参照してください。
Runtime.Backend.HttpWebhookOperation.RequestTimeout 00:02:00
(2 分)		 HTTP Webhook トリガーとアクションの要求タイムアウト値を設定します。

組み込みの Azure Storage 操作

BLOB ストレージ

設定 既定値 説明
Microsoft.Azure.Workflows.ContentStorage.RequestOptionsThreadCount なし BLOB のアップロードとダウンロード操作のためのスレッド数を設定します。 この設定を使うと、アクションの入力と出力からコンテンツをアップロードおよびダウンロードするときに複数のスレッドを使うよう、Azure Logic Apps ランタイムに強制できます。
Runtime.ContentStorage.RequestOptionsDeltaBackoff 00:00:02
(2 秒)		 BLOB ストレージに送信される再試行のバックオフ間隔を設定します。
Runtime.ContentStorage.RequestOptionsMaximumAttempts 再試行回数 4 テーブルおよびキュー ストレージに送信される再試行の最大数を設定します。
Runtime.ContentStorage.RequestOptionsMaximumExecutionTime 00:02:00
(2 分)		 Azure Logic Apps ランタイムからの BLOB 要求の、再試行を含む操作タイムアウト値を設定します。
Runtime.ContentStorage.RequestOptionsServerTimeout 00:00:30
(30 秒)		 Azure Logic Apps ランタイムからの BLOB 要求のタイムアウト値を設定します。

テーブルおよびキュー ストレージ

設定 既定値 説明
Runtime.DataStorage.RequestOptionsDeltaBackoff 00:00:02
(2 秒)		 テーブルおよびキュー ストレージに送信される再試行のバックオフ間隔を設定します。
Runtime.DataStorage.RequestOptionsMaximumAttempts 再試行回数 4 テーブルおよびキュー ストレージに送信される再試行の最大数を設定します。
Runtime.DataStorage.RequestOptionsMaximumExecutionTime 00:00:45
(45 秒)		 Azure Logic Apps ランタイムからのテーブルおよびキュー ストレージ要求について、再試行を含む操作タイムアウト値を設定します。
Runtime.DataStorage.RequestOptionsServerTimeout 00:00:16
(16 秒)		 Azure Logic Apps ランタイムからのテーブルおよびキュー ストレージ要求のタイムアウト値を設定します。

ファイル共有

設定 既定値 説明
ServiceProviders.AzureFile.MaxFileSizeInBytes 150000000 バイト Azure ファイル共有の最大ファイル サイズをバイト単位で設定します。

組み込みの Azure Functions 操作

設定 既定値 説明
Runtime.Backend.FunctionOperation.RequestTimeout 00:03:45
(3 分 45 秒)		 Azure Functions アクションの要求タイムアウト値を設定します。
Runtime.Backend.FunctionOperation.MaxContentSize 104857600 バイト Azure Functions アクションの最大要求サイズをバイト単位で設定します。 詳細については、制限に関するページを参照してください。
Runtime.Backend.FunctionOperation.DefaultRetryCount 再試行回数 4 Azure Functions アクションの既定の再試行回数を設定します。
Runtime.Backend.FunctionOperation.DefaultRetryInterval 00:00:07
(7 秒)		 Azure Functions アクションの既定の再試行間隔を設定します。
Runtime.Backend.FunctionOperation.DefaultRetryMaximumInterval 01:00:00
(1 時間)		 Azure Functions アクションの最大再試行間隔を設定します。
Runtime.Backend.FunctionOperation.DefaultRetryMinimumInterval 00:00:05
(5 秒)		 Azure Functions アクションの最小再試行間隔を設定します。

組み込みの Azure Service Bus 操作

設定 既定値 説明
ServiceProviders.ServiceBus.MessageSenderOperationTimeout 00:01:00
(1 分)		 組み込みの Service Bus 操作でメッセージを送信するときのタイムアウトを設定します。
Runtime.ServiceProviders.ServiceBus.MessageSenderPoolSizePerProcessorCount 64 個のメッセージ送信元 メッセージ送信側プール内で使用するプロセッサ コアあたりの Azure Service Bus メッセージ送信元の数を設定します。

組み込みの SFTP 操作

設定 既定値 説明
Runtime.ServiceProviders.Sftp.MaxFileSizeInBytes 2147483648 バイト [ファイル コンテンツの取得 (V2)] アクションの最大ファイル サイズをバイト単位で設定します。
Runtime.ServiceProviders.Sftp.MaximumFileSizeToReadInBytes 209715200 バイト [ファイル コンテンツの取得] アクションの最大ファイル サイズをバイト単位で設定します。 このアクションはメモリ内のファイル コンテンツを読み取るので、この値が参照可能なメモリ サイズを超えないようにしてください。

マネージド コネクタの操作

設定 既定値 説明
Runtime.Backend.ApiConnectionOperation.RequestTimeout 00:02:00
(2 分)		 マネージド API コネクタのトリガーとアクションの要求タイムアウト値を設定します。
Runtime.Backend.ApiConnectionOperation.MaxContentSize 104857600 バイト マネージド API コネクタのトリガーとアクションの最大要求サイズをバイト単位で設定します。 詳細については、制限に関するページを参照してください。
Runtime.Backend.ApiConnectionOperation.DefaultRetryCount 再試行回数 4 マネージド API コネクタのトリガーとアクションの既定の再試行回数を設定します。
Runtime.Backend.ApiConnectionOperation.DefaultRetryInterval 00:00:07
(7 秒)		 マネージド API コネクタのトリガーとアクションの既定の再試行間隔を設定します。
Runtime.Backend.ApiWebhookOperation.DefaultRetryMaximumInterval 01:00:00
(1 日)		 マネージド API コネクタの Webhook トリガーとアクションの最大再試行間隔を設定します。
Runtime.Backend.ApiConnectionOperation.DefaultRetryMinimumInterval 00:00:05
(5 秒)		 マネージド API コネクタのトリガーとアクションの最小再試行間隔を設定します。
Runtime.Backend.ApiWebhookOperation.DefaultWakeUpInterval 01:00:00
(1 日)		 マネージド API コネクタの Webhook トリガーとアクション ジョブの、既定のウェイクアップ間隔を設定します。

他のすべての操作の再試行ポリシー

設定 既定値 説明
Runtime.ScaleMonitor.MaxPollingLatency 00:00:30
(30 秒)		 実行時のスケーリングの最大ポーリング待機時間を設定します。
Runtime.Backend.Operation.MaximumRetryCount 再試行回数 90 ワークフロー操作の再試行ポリシー定義における最大再試行回数を設定します。
Runtime.Backend.Operation.MaximumRetryInterval 01:00:00:01
(1 日と 1 秒)		 ワークフロー操作の再試行ポリシー定義における最大間隔を設定します。
Runtime.Backend.Operation.MinimumRetryInterval 00:00:05
(5 秒)		 ワークフロー操作の再試行ポリシー定義における最小間隔を設定します。

制限事項

  • 最大コンテンツ サイズ

    既定では、HTTP または要求などの組み込みのトリガーは、「制約と構成の参考文献 - メッセージ」の中で説明されているメッセージ サイズに制限されます。 その制限を超えるファイルを処理するには、ご利用のコンテンツを BLOB として Azure Blob Storage にアップロードし、それから Azure Blob コネクタを使用してそのコンテンツを取得してみてください。

ホスト設定の管理 - host.json

ホスト設定を追加、更新、または削除できます。これは、"ローカルと Azure のどちらで実行される場合でも" そのロジック アプリ内の "すべてのワークフロー" に適用される、ランタイム構成の設定と値を指定するもので、例として、スループット、容量、データ サイズなどの既定値があります。 ロジック アプリ固有のホスト設定については、「使用可能なランタイムおよびデプロイ設定 - host.json」をご確認ください。

Azure portal - host.json

Azure portal でシングルテナント ベースのロジック アプリのホスト設定を確認するには、次の手順に従います。

  1. Azure portal の検索ボックスでロジック アプリを検索し、開きます。

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

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

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

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

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

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

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

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

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

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

  9. wwwroot フォルダーへの次のパスを参照します: ...\home\site\wwwroot。

  10. コンソール ウィンドウの上にあるディレクトリ テーブルで、host.json ファイルの横にある [編集] を選択します。

  11. host.json ファイルが開いた後、ロジック アプリに以前に追加されたホスト設定があれば確認します。

    ホスト設定の詳細については、「使用可能なホスト設定のリファレンス ガイド - host.json」をご確認ください。

設定を追加するには、次の手順に従います。

  1. 設定を追加または編集する前に、Azure portal でロジック アプリを停止します。

    1. ロジック アプリのメニューで、 [概要] を選択します。
    2. [概要] ペインのツール バーで、 [停止] を選択します。

  2. host.json ファイルに戻ります。 extensionBundle オブジェクトに、extensions オブジェクトを追加します。これには、workflow および settings オブジェクトが含まれます。次に例を示します。

    {
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "workflow": {
         "settings": {
         }
      }
   }
}

  3. settings オブジェクトに、ワークフローがローカルまたは Azure のどちらで実行される場合でも、ロジック アプリ内のすべてのワークフローに使用するホスト設定を含むフラット リストを追加します。次に例を示します。

    {
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "workflow": {
         "settings": {
            "Runtime.Trigger.MaximumWaitingRuns": "100"
         }
      }
   }
}

  4. 完了したら、忘れずに [保存] を選択してください。

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

Visual Studio Code - host.json

Visual Studio Code でロジック アプリのホスト設定を確認するには、次の手順に従います。

  1. ロジック アプリ プロジェクトのルート プロジェクト レベルで、host.json ファイルを見つけて開きます。

  2. extensions オブジェクトの workflows および settings で、ロジック アプリに以前に追加されたホスト設定があれば確認します。 そうでなければ、extensions オブジェクトはファイル内に表示されません。

    ホスト設定の詳細については、「使用可能なホスト設定のリファレンス ガイド - host.json」をご確認ください。

ホスト設定を追加するには、次の手順に従います。

  1. host.json ファイル内で、extensionBundle オブジェクトに extensions オブジェクトを追加します。これには、workflow および settings オブジェクトが含まれます。次に例を示します。

    {
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "workflow": {
         "settings": {
         }
      }
   }
}

  2. settings オブジェクトに、ワークフローがローカルまたは Azure のどちらで実行される場合でも、ロジック アプリ内のすべてのワークフローに使用するホスト設定を含むフラット リストを追加します。次に例を示します。

    {
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "workflow": {
         "settings": {
            "Runtime.Trigger.MaximumWaitingRuns": "100"
         }
      }
   }
}

次の手順