適用対象: 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 と統合できます。 接続文字列やキーなど、セキュリティで保護された文字列を直接参照できます。 デプロイ時に環境変数を定義できる ARM テンプレートと同様に、 ロジック アプリ ワークフロー定義内でアプリ設定を定義できます。 そうしておいて、接続エンドポイントやストレージ文字列などの動的に生成されるインフラストラクチャ値を取得できます。 ただし、アプリ設定にはサイズの制限があり、Azure Logic Apps の特定の領域からは参照できません。
Note
Azure Key Vault を使用する場合は、パスワード、資格情報、証明書などのシークレットのみを格納してください。 ワークフロー デザイナーが呼び出しを行う必要がある URL パスなどの非セキュリティ値を格納するために、ロジック アプリ ワークフローでキー コンテナーを使用しないでください。 デザイナーは、Azure Key Vault リソースを参照するアプリ設定を逆参照できないため、エラーと呼び出しが失敗します。 非セキュリティ値の場合は、アプリ設定に直接格納します。
デプロイ用にロジック アプリを設定する方法の詳細については、次のドキュメントを参照してください。
- Azure Logic Apps のワークフロー入力のためのクロス環境パラメーターを作成する
- シングルテナント ベースのロジック アプリ用の DevOps デプロイの概要
- シングルテナント ベースのロジック アプリ用の DevOps デプロイを設定する
Visual Studio Code プロジェクトの構造
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
プロジェクトのルート レベルには、他の項目と共に次のフォルダーとファイルがあります。
| Name | フォルダーまたはファイル | Description |
|---|---|---|
| .vscode | Folder | Visual Studio Code 関連の設定ファイル (extensions.json、launch.json、settings.json、tasks.json ファイルなど) が含まれています。 |
| Artifacts | Folder | 企業間 (B2B) シナリオをサポートするワークフローで定義および使用する統合アカウント成果物が含まれています。 たとえば、サンプル構造には、次のフォルダーが含まれています。 - Maps: XML 変換操作に使用するマップが含まれています。 - Schemas: XML 変換操作に使用するスキーマが含まれています。 - Rules: ルールベースのエンジンプロジェクト内のビジネス ルールの成果物。 |
| lib | Folder | ロジック アプリで使用または参照できるサポートされているアセンブリが含まれています。 これらのアセンブリは、Visual Studio Code でプロジェクトにアップロードできますが、プロジェクト内の特定のフォルダーに追加する必要があります。 たとえば、このフォルダーには、次のフォルダーが含まれています。 - builtinOperationSdks: Java および .NET Framework のアセンブリの JAR フォルダーと net472 フォルダーが含まれています。 - custom: .NET Framework カスタム アセンブリが含まれています。 サポートされているアセンブリの種類と、プロジェクト内のそれらを格納する場所の詳細については、プロジェクトへのアセンブリの追加に関する記事を参照してください。 |
| < WorkflowName> | Folder | ワークフローごとに、<WorkflowName> フォルダーに workflow.json ファイルがあり、ワークフローの基になる JSON 定義が含まれています。 |
| workflow-designtime | Folder | 開発環境関連の設定ファイルが含まれています。 |
| .funcignore | File | インストールされている Azure Functions Core Tools に関連する情報が含まれています。 |
| connections.json | File | ワークフローで使用されるマネージド接続と Azure 関数のメタデータ、エンドポイント、キーが含まれています。 重要: 環境ごとに異なる接続と関数を使用するには、必ずこの connections.json ファイルをパラメーター化し、エンドポイントを更新してください。 |
| host.json | File | ランタイム固有の構成設定と値が含まれます。たとえば、シングルテナント 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 | File | ローカルでの実行中にワークフローで使用されるアプリ設定、接続文字列、その他の設定が含まれています。 これらの設定と値は、ローカル開発環境でプロジェクトを実行する場合に "のみ" 適用されます。 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 の操作 - ローカル設定ファイル」を参照してください。
次の表では、ロジック アプリで使用されるアプリの設定について説明します。 ロジック アプリが正しく動作するためには、いくつかの設定が必要です。
| Setting | Required | Value | Description |
|---|---|---|---|
APP_KIND |
Yes | workflowApp |
Standard ロジック アプリ リソースのアプリの種類を設定するのに必要です。 この値は workflowApp に設定する必要があります。 注: 一部のシナリオでは、たとえば、Azure Resource Manager テンプレートを使用した自動化や、設定が含まれていないその他のシナリオにより、このアプリ設定が欠落している可能性があります。 JavaScript コードの実行アクションなどの特定のアクションが機能しないか、ワークフローが動作を停止する場合は、APP_KIND アプリ設定が存在していて、 workflowApp に設定されていることを確認してください。 |
AZURE_AUTHORITY_HOST |
No | None | OAuth 認証に使用する Standard ロジック アプリの既定のオーソリティを設定します。 |
AzureWebJobsStorage |
Yes | None | Azure ストレージ アカウントの接続文字列を設定するのに必要です。 詳細については、 AzureWebJobsStorage に関するページを参照してください。 |
FUNCTIONS_EXTENSION_VERSION |
Yes | ~4 |
Azure Functions のバージョンを設定するのに必要です。 詳細については、 FUNCTIONS_EXTENSION_VERSIONを参照してください。 |
FUNCTIONS_WORKER_RUNTIME |
Yes | dotnet |
ロジック アプリのリソースとワークフローの言語ワーカー ランタイムを設定するのに必要です。 注: この設定の値は以前は node に設定されていましたが、新しくデプロイされたすべての Standard ロジック アプリと既存の Standard ロジック アプリに必要な値が dotnet されるようになりました。 この変更はワークフローのランタイムには影響しないため、すべてが以前と同じように動作するはずです。 詳細については、「 FUNCTIONS_WORKER_RUNTIME」を参照してください。 |
ServiceProviders.Sftp.FileUploadBufferTimeForTrigger |
No | 00:00:20 (20 秒) |
最終変更のタイムスタンプが現在の時刻よりも後のファイルを無視するようにバッファー時間を設定します。 この設定は、大きなファイルの書き込みに時間がかかる場合に役に立ちます。また、部分的に書き込まれたファイルのデータのフェッチを回避することができます。 |
ServiceProviders.Sftp.OperationTimeout |
No | 00:02:00 (2 分) |
任意の操作に対して、タイムアウトするまでの待機時間を設定します。 |
ServiceProviders.Sftp.ServerAliveInterval |
No | 00:30:00 (30 分) |
指定した期間中にサーバーとのデータ交換が行われない場合、SSH 接続を維持するために キープ アライブ メッセージを送信します。 |
ServiceProviders.Sftp.SftpConnectionPoolSize |
No |
2 個の接続 |
各プロセッサがキャッシュできる接続数を設定します。 キャッシュできる接続の合計数は 、ProcessorCount に設定値を乗算した値です。 |
ServiceProviders.MaximumAllowedTriggerStateSizeInKB |
No |
10 KB (1,000 ファイル以下) |
トリガー状態エンティティのサイズをキロバイト単位で設定します。これは監視対象フォルダー内のファイル数に比例し、ファイルの検出に使われます。 ファイル数が 1,000 個を超える場合は、この値を増やします。 |
ServiceProviders.Sql.QueryTimeout |
No | 00:02:00 (2 分) |
SQL サービス プロバイダーの操作の要求タイムアウト値を設定します。 |
WEBSITE_CONTENTSHARE |
Yes | Dynamic | 関数アプリのコードと構成ファイルを格納するために Azure Functions が使用し、 WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGで使用されるファイル共有の名前を設定するために必要です。 既定値は、ランタイムによって生成される一意の文字列です。 詳細については、「 WEBSITE_CONTENTSHARE」を参照してください。 |
WEBSITE_LOAD_ROOT_CERTIFICATES |
No | None | 信頼するルート証明書のサムプリントを設定します。 |
WEBSITE_NODE_DEFAULT_VERSION |
Yes | ~ < バージョン> | Windows でロジック アプリ ワークフローを実行するときに Node.js バージョンを設定します。 チルダ (~) を使用して、Azure Logic Apps ランタイムがターゲット メジャー バージョンの利用可能な最新バージョンを使用するようにします。 たとえば、 ~18 に設定すると、Node.js 18 の最新バージョンが使用されます。 メジャー バージョンでチルダを使用する場合は、マイナー バージョンを手動で更新する必要はありません。 詳細については、「WEBSITE_NODE_DEFAULT_VERSION」 を参照してください。 |
Workflows.Connection.AuthenticationAudience |
No | None | マネージド (Azure ホステッド) 接続を認証するための対象ユーザーを設定します。 |
Workflows.CustomHostName |
No | None | ワークフロー URL と入力出力 URL に使用するホスト名 ( logic.contoso.comなど) を設定します。 カスタム DNS 名を構成する方法については、「Azure App Service で既存のカスタム ドメインを設定する」および「Azure App Service のカスタム ドメインに対して HTTPS を有効にする」を参照してください。 |
Workflows.<workflowName>.FlowState |
No | None | < workflowName>の状態を設定します。 |
Workflows.<workflowName>.RuntimeConfiguration.RetentionInDays |
No |
90 日 |
<
workflowName> の実行履歴を保持する時間を日数で設定します。 - 最小: 7 日 - 最大 365 日 |
Workflows.RuntimeConfiguration.RetentionInDays |
No |
90 日 |
実行の開始後、ワークフローの実行履歴を保持する期間を日数で設定します。 - 最小: 7 日 - 最大 365 日 |
Workflows.WebhookRedirectHostUri |
No | None | Webhook コールバック URL に使用するホスト名を設定します。 |
アプリ設定の管理 - local.settings.json
アプリ設定を追加、更新、または削除するには、Azure portal、Visual Studio Code、または Azure CLI の次のセクションを選択して確認します。 ロジック アプリに固有のアプリ設定については、「 アプリ設定のリファレンス - local.settings.json」を 参照してください。
ポータルのアプリ設定を見る
Azure portal の検索ボックスで、ロジック アプリを見つけて開きます。
サイドバー メニューの [設定] で、[ 環境変数] を選択します。
[ 環境変数 ] ページの [ アプリ設定 ] タブで、ロジック アプリのアプリ設定を確認します。
これらの設定の詳細については、「 アプリ設定のリファレンス - local.settings.json」を参照してください。
すべての値を表示するには、ページ ツール バーの [ 値の表示] を選択します。 または、1 つの値を表示するには、[ 値 ] 列で [ 値の表示 ] (目のアイコン) を選択します。
ポータルのアプリの設定を追加する
ホスト設定のリファレンス - host.json
Visual Studio Code では、ロジック アプリ プロジェクトのルート レベルで、 host.json メタデータ ファイルには、ローカルまたは Azure で実行されているかどうかにかかわらず、ロジック アプリ リソース 内のすべてのワークフロー に適用されるランタイム設定と既定値が含まれています。 これらの設定を表示および管理する方法については、「 ホスト設定の管理 - host.json」を参照してください。 また、関連する制限の情報については、Azure Logic Apps の制限と構成に関するドキュメントも参照してください。
ジョブ オーケストレーションのスループット
これらの設定は、シングルテナントの Azure Logic Apps でワークフロー操作を実行するためのスループットと容量に影響します。
| Setting | 既定値 | Description |
|---|---|---|
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
これらの設定は慎重に使用し、これらの操作を元に戻したり回復したりできないため、ロード テスト環境やパフォーマンス テスト環境などの非運用環境でのみ使用してください。
| Setting | 既定値 | Description |
|---|---|---|
Jobs.CleanupJobPartition |
None | 指定したワークフローのすべての実行ジョブを直ちに削除します。 |
Jobs.SuspendedJobPartition |
None | 指定したワークフローの実行ジョブを停止します。 |
SequencerJobs.SuspendedSequencerPartition |
None | 指定したワークフローのシーケンサー実行ジョブを停止します。 |
個々のワークフローを指定するには、次の構文を使用します。各ワークフロー ID の後にコロン (:) が続き、セミコロン (;) で区切られます。
"Jobs.CleanupJobPartition": "<workflow-ID-1>:;<workflow-ID-2>",
"Jobs.SuspendedJobPartition": "<workflow-ID-1>:;<workflow-ID-2>:",
"SequencerJobs.SuspendedSequencerPartition": "<workflow-ID-1>:;<workflow-ID-2>:"
特定の実行を取り消すには、ワークフロー ID に続く実行 ID を区切り記号として 2D で指定します。次に例を示します。
"Jobs.SuspendedJobPartition": "<workflow-ID-1>:2D<run-ID>;",
繰り返しベースのトリガー
| Setting | 既定値 | Description |
|---|---|---|
Microsoft.Azure.Workflows.ServiceProviders.MaximumAllowedTriggerStateSizeInKB |
1 KB |
組み込み SFTP トリガーなどの繰り返しベースのトリガーについて、トリガー状態の最大許容サイズを設定します。 トリガー状態により、サービス プロバイダーの複数の繰り返しベースのトリガーの間でデータが保持されます。 重要: ストレージ・サイズに基づいて、この値を高く設定しすぎると、ストレージとパフォーマンスに悪影響を及ぼす可能性があります。 |
並列処理をトリガーする
次のコンカレンシー設定は、 組み込みのサービス プロバイダー ベースのコネクタ の繰り返しベースのトリガーで始まり、同時に実行されるワークフローの数を制御するワークフローにのみ適用されます。
関数ベースのトリガーで始まるワークフローの場合で、サポートされている場合はバッチ処理を設定してみることをお勧めします。 ただし、バッチ処理が必ずしも適切な解決策であるとは限りません。 たとえば、Azure Service Bus トリガーでは、バッチでロック期間を超えてメッセージが保持される可能性があります。 その結果、そのようなメッセージに対する完了や破棄などのアクションは失敗します。
| Setting | 既定値 | Description |
|---|---|---|
Runtime.Trigger.MaximumRunConcurrency |
実行数 100 |
トリガーによって開始できる同時実行の最大数を設定します。 この値は、トリガーの同時実行の定義に表示されます。 |
Runtime.Trigger.MaximumWaitingRuns |
実行数 200 |
同時実行の最大数に達した後に待機できる実行の最大数を設定します。 この値は、トリガーの同時実行の定義に表示されます。 詳しくは、「実行待機の制限を変更する」をご参照ください。 |
実行継続時間および履歴保有
| Setting | 既定値 | Description |
|---|---|---|
Runtime.Backend.FlowRunTimeout |
90.00:00:00 (90 日) |
タイムアウトを強制するまでの、ワークフローの実行を継続できる時間。 この設定の最小値は 7 日です。 重要: この値が、 Workflows.RuntimeConfiguration.RetentionInDays という名前のアプリ設定の値以下であることを確認してください。 そうしないと、関連付けられているジョブが完了する前に実行履歴が削除される可能性があります。 |
Runtime.FlowMaintenanceJob.RetentionCooldownInterval |
7.00:00:00 (7 日間) |
保持する必要がなくなった実行履歴を確認してから削除するまでの間隔として、日数で期間を設定します。 |
アクションの実行
| Setting | 既定値 | Description |
|---|---|---|
Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout |
00:10:00 (10 分) |
タイムアウトして再試行する前に実行するワークフロー アクション ジョブの期間を設定します。 SAP などの組み込み操作の既定のタイムアウトを変更するには、 functionTimeout ホスト設定も設定します。 詳細については、次のエントリを参照してください。 |
functionTimeout |
00:30:00 (30 分) |
Azure Functions からの呼び出しと、関数呼び出しとして機能する一部の組み込み操作 (SAP など) のタイムアウト前に実行する時間を設定します。 標準ロジック アプリでは、関数アプリと同じ基になる設計が使用されます。 そのため、Azure Functions の functionTimeout ホスト設定は、関数呼び出しとして実行される組み込み操作にも影響します。 詳細については、 functionTimeout を参照してください。 注: host.json ファイルでは、 functionTimeout 設定は、Standard ロジック アプリのホスト設定が存在する extensions オブジェクトと同じレベルに存在します。 詳細については、「関数 ベースの組み込み操作のタイムアウト値を変更する」セクションの例を参照してください。 |
関数ベースの組み込み操作のタイムアウト値を変更する
Azure Functions で関数呼び出しとして実行される組み込み操作の場合は、次の例に示すように、Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeoutとfunctionTimeoutの両方のホスト設定をhost.jsonファイルに追加します。
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
"version": "[1.*, 2.0.0)"
},
"extensions": {
"workflow": {
"settings": {
"Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout": "01:00:00"
}
}
},
"functionTimeout": "01:00:00"
}
入力と出力
| Setting | 既定値 | Description |
|---|---|---|
Microsoft.Azure.Workflows.TemplateLimits.InputParametersLimit |
50 |
従量課金ロジック アプリをエクスポートして作成された標準ロジック アプリの場合、環境間ワークフロー パラメーターの既定の制限を最大 500 に変更します。 |
Runtime.ContentLink.MaximumContentSizeInBytes |
104857600 バイト |
単一のトリガーまたはアクションで入力または出力に含めることができる最大サイズをバイト数で設定します。 |
Runtime.FlowRunActionJob.MaximumActionResultSize |
209715200 バイト |
単一のアクションで保持できる入力と出力の組み合わせの最大サイズをバイト単位で設定します。 |
Pagination
| Setting | 既定値 | Description |
|---|---|---|
Runtime.FlowRunRetryableActionJobCallback.MaximumPageCount |
1000 ページ |
操作で改ページがサポートされ、有効になっている場合に、実行時に返すまたは処理するページの最大数を設定します。 |
Chunking
| Setting | 既定値 | Description |
|---|---|---|
Runtime.FlowRunRetryableActionJobCallback.MaximumContentLengthInBytesForPartialContent |
1073741824 バイト |
操作でチャンク処理がサポートされ、有効になっている場合に、ダウンロードまたはアップロードされるコンテンツの最大サイズをバイト単位で設定します。 |
Runtime.FlowRunRetryableActionJobCallback.MaxChunkSizeInBytes |
52428800 バイト |
操作に対してチャンク処理がサポートされ、有効になっている場合、各コンテンツ チャンクの最大サイズをバイト単位で設定します。 |
Runtime.FlowRunRetryableActionJobCallback.MaximumRequestCountForPartialContent |
1000 個の要求 |
操作でチャンク処理がサポートされ、有効になっている場合に、1 回のアクション実行でコンテンツをダウンロードするために行うことができる要求の最大数を設定します。 |
コンテンツをインラインで格納するか、BLOB を使用する
| Setting | 既定値 | Description |
|---|---|---|
Runtime.FlowRunEngine.ForeachMaximumItemsForContentInlining |
20 項目 |
For each ループの実行中、各項目の値は、他のメタデータと一緒にテーブル ストレージ内にインラインで、または BLOB ストレージに個別に格納されます。 他のメタデータと一緒にインラインで格納する項目の数を設定します。 |
Runtime.FlowRunRetryableActionJobCallback.MaximumPagesForContentInlining |
20 ページ |
BLOB ストレージに格納する前に、テーブル ストレージにインライン コンテンツとして格納するページの最大数を設定します。 |
Runtime.FlowTriggerSplitOnJob.MaximumItemsForContentInlining |
40 項目 |
デバッチ処理をサポートするトリガーで、分割または splitOn 設定が有効になっている場合、トリガーは配列の項目を複数のワークフロー インスタンスにデバッチ処理します。 各配列項目の値は、テーブル ストレージ内の他のメタデータと共にインラインで格納されるか、BLOB ストレージに個別に格納されます。 インラインで格納する項目の数を設定します。 |
Runtime.ScaleUnit.MaximumCharactersForContentInlining |
32384 文字 |
BLOB ストレージに格納する前に、テーブル ストレージにインラインで格納する操作の入力および出力文字数の最大数を設定します。 |
For each ループ
| Setting | 既定値 | Description |
|---|---|---|
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 ループ
| Setting | 既定値 | Description |
|---|---|---|
Runtime.Backend.MaximumUntilLimitCount |
5000 イテレーション |
ステートフル ワークフローの場合は、Count アクションのUntil プロパティに可能な最大数を設定します。 |
Runtime.Backend.Stateless.FlowRunTimeout |
00:05:00 (5 分) |
ステートレス ワークフロー内の Until ループの最大待機時間を設定します。 |
Runtime.Backend.Stateless.MaximumUntilLimitCount |
100 イテレーション |
ステートレス ワークフローの場合は、Count アクションのUntil プロパティに可能な最大数を設定します。 |
Variables
| Setting | 既定値 | Description |
|---|---|---|
Runtime.Backend.DefaultAppendArrayItemsLimit |
100000 配列項目 |
配列型の変数内の項目の最大数を設定します。 |
Runtime.Backend.VariableOperation.MaximumStatelessVariableSize |
ステートレス ワークフロー: 1024 文字 |
ステートレス ワークフローで使用した場合に、変数に格納できるコンテンツの最大サイズを文字数で設定します。 |
Runtime.Backend.VariableOperation.MaximumVariableSize |
ステートフル ワークフロー: 104857600 文字 |
ステートフル ワークフローで使用した場合に、変数に格納できるコンテンツの最大サイズを文字数で設定します。 |
組み込みの HTTP 操作
| Setting | 既定値 | Description |
|---|---|---|
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 操作
| Setting | 既定値 | Description |
|---|---|---|
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 操作
ブロブストレージ
| Setting | 既定値 | Description |
|---|---|---|
Microsoft.Azure.Workflows.ContentStorage.RequestOptionsThreadCount |
None | 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 要求のタイムアウト値を設定します。 |
テーブルおよびキュー ストレージ
| Setting | 既定値 | Description |
|---|---|---|
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 ランタイムからのテーブルおよびキュー ストレージ要求のタイムアウト値を設定します。 |
ファイル共有
| Setting | 既定値 | Description |
|---|---|---|
ServiceProviders.AzureFile.MaxFileSizeInBytes |
150000000 バイト |
Azure ファイル共有の最大ファイル サイズをバイト単位で設定します。 |
組み込みの Azure Functions 操作
| Setting | 既定値 | Description |
|---|---|---|
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 操作
| Setting | 既定値 | Description |
|---|---|---|
ServiceProviders.ServiceBus.MessageSenderOperationTimeout |
00:01:00 (1 分) |
組み込みの Service Bus 操作でメッセージを送信するときのタイムアウトを設定します。 |
Runtime.ServiceProviders.ServiceBus.MessageSenderPoolSizePerProcessorCount |
64 個のメッセージ送信元 |
メッセージ送信側プール内で使用するプロセッサ コアあたりの Azure Service Bus メッセージ送信元の数を設定します。 |
組み込みの SFTP 操作
| Setting | 既定値 | Description |
|---|---|---|
Runtime.ServiceProviders.Sftp.MaxFileSizeInBytes |
2147483648 バイト |
[ファイル コンテンツの取得 (V2)] アクションの最大ファイル サイズをバイト単位で設定します。 |
Runtime.ServiceProviders.Sftp.MaximumFileSizeToReadInBytes |
209715200 バイト |
[ファイル コンテンツの取得] アクションの最大ファイル サイズをバイト単位で設定します。 このアクションはメモリ内のファイル コンテンツを読み取るので、この値が参照可能なメモリ サイズを超えないようにしてください。 |
マネージド コネクタの操作
| Setting | 既定値 | Description |
|---|---|---|
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 トリガーとアクション ジョブの、既定のウェイクアップ間隔を設定します。 |
他のすべての操作の再試行ポリシー
| Setting | 既定値 | Description |
|---|---|---|
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 秒) |
ワークフロー操作の再試行ポリシー定義における最小間隔を設定します。 |
Limitations
最大コンテンツ サイズ:
既定では、HTTP または要求などの組み込みのトリガーは、「制約と構成の参考文献 - メッセージ」の中で説明されているメッセージ サイズに制限されます。 その制限を超えるファイルを処理するには、ご利用のコンテンツを BLOB として Azure Blob Storage にアップロードし、それから Azure Blob コネクタを使用してそのコンテンツを取得してみてください。
ホスト設定の管理 - host.json
ホスト設定を追加、更新、または削除できます。これは、"ローカルと Azure のどちらで実行される場合でも" そのロジック アプリ内の "すべてのワークフロー" に適用される、ランタイム構成の設定と値を指定するもので、例として、スループット、容量、データ サイズなどの既定値があります。 ロジック アプリに固有のホスト設定については、「 ホスト設定のリファレンス - host.json」を 参照してください。
Azure portal でシングルテナント ベースのロジック アプリのホスト設定を確認するには、次の手順に従います。
Azure portal の検索ボックスで、ロジック アプリを見つけて開きます。
リソース メニューの [開発ツール] で、[ 高度なツール] を選択します。
[高度なツール] ペインで、[移動] を選択します。これにより、ロジック アプリ用の Kudu 環境が開きます。
Kudu のツール バーで、[Debug console]\(デバッグ コンソール\) メニューを開き、[CMD] を選択します。
コンソール ウィンドウが開き、コマンド プロンプトを使用して wwwroot フォルダーを参照できます。 または、コンソール ウィンドウの上に表示されるディレクトリ構造を参照することもできます。
wwwroot フォルダーへの次のパスに沿って参照します:
...\home\site\wwwroot。コンソール ウィンドウの上のディレクトリ テーブルで、 host.json ファイルの横にある [編集] を選択します。
host.json ファイルが開いたら、ロジック アプリ用に以前に追加されたすべてのホスト設定を確認します。
ホスト設定の詳細については、「 ホスト設定のリファレンス - host.json」を 参照してください。
設定を追加するには、次の手順に従います。
設定を追加または編集する前に、Azure portal でロジック アプリを停止します。
リソース メニューで、[ 概要] を選択します。
[概要] ペインのツール バーで、[停止] を選択します。
host.json ファイルが既に開いている場合は、host.json ファイルに戻ります。 それ以外の場合は、前の手順に従って host.jsonファイルを 開きます。
extensionBundleオブジェクトに、extensionsオブジェクトを追加します。これには、workflowおよびsettingsオブジェクトが含まれます。次に例を示します。{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "settings": { } } } }settingsオブジェクトに、ワークフローがローカルまたは Azure のどちらで実行される場合でも、ロジック アプリ内のすべてのワークフローに使用するホスト設定を含むフラット リストを追加します。次に例を示します。{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "settings": { "Runtime.Trigger.MaximumWaitingRuns": "100" } } } }完了したら、忘れずに [保存] を選択します。
次に、ロジック アプリを再起動します。 ロジック アプリの [概要 ] ページに戻り、[再起動] を選択 します。