Modifier les paramètres de l’hôte et de l’application pour les applications logiques Standard dans Azure Logic Apps monolocataire
S’applique à : Azure Logic Apps (Standard)
Dans Azure Logic Apps locataire unique, les paramètres d’application pour une application logique standard spécifient les options de configuration globale qui affectent tous les workflows de cette application logique. Toutefois, ces paramètres s’appliquent uniquement lorsque ces workflows s’exécutent dans votre environnement de développement local. Les workflows qui s’exécutent localement peuvent accéder à ces paramètres d’application en tant que variables d’environnement locales, qui sont utilisées par les outils de développement locaux pour des valeurs qui peuvent souvent changer d’un environnement à l’autre. Par exemple, ces valeurs peuvent contenir des chaînes de connexion. Lorsque vous déployez dans Azure, les paramètres de l’application sont ignorés et ne sont pas inclus dans votre déploiement.
Votre application logique a également des paramètres d’hôte qui spécifient les paramètres de configuration du runtime et les valeurs qui s’appliquent à tous les workflows de cette application logique, par exemple, les valeurs par défaut pour le débit, la capacité, la taille des données, etc., qu’elle s’exécute localement ou dans Azure.
Paramètres de l’application, paramètres et déploiement
Dans Azure Logic Apps multi-tenant, le déploiement dépend des modèles Azure Resource Manager (modèles ARM) qui combinent et gèrent l’approvisionnement de ressources pour les applications logiques et l’infrastructure. Cette conception pose un défi lorsque vous devez gérer des variables d’environnement pour des applications logiques dans différents environnements de développement, de test et de production. Tout ce qui se trouve dans un modèle ARM est défini lors du déploiement. Si vous ne devez modifier ne serait-ce qu’une seule variable, vous devez tout redéployer.
Dans Azure Logic Apps monolocataire, le déploiement devient plus facile, car vous pouvez séparer l’approvisionnement des ressources entre les applications et l’infrastructure. Vous pouvez utiliser des paramètres pour extraire les valeurs qui peuvent changer d’un environnement à l’autre. En définissant des paramètres à utiliser dans vos workflows, vous pouvez d’abord vous concentrer sur la conception de vos workflows, puis insérer ultérieurement vos variables spécifiques à l’environnement. Vous pouvez appeler et référencer vos variables d’environnement au moment de l’exécution à l’aide des paramètres d’application et des paramètres. De cette façon, vous n’avez pas besoin de redéployer aussi souvent.
Les paramètres d’application s’intègrent à Azure Key Vault. Vous pouvez référencer directement des chaînes sécurisées, telles que des chaînes de connexion et des clés. Comme pour les modèles Azure Resource Manager (modèles ARM), où vous pouvez définir des variables d’environnement au moment du déploiement, vous pouvez définir des paramètres d’application dans la définition de workflow de votre application logique. Vous pouvez ensuite capturer des valeurs d’infrastructure générées dynamiquement, comme des points de terminaison de connexion, des chaînes de stockage, etc. Toutefois, les paramètres d’application ont des limitations de taille et ne peuvent pas être référencés à partir de certaines zones dans Azure Logic Apps.
Remarque
Si vous utilisez Key Vault, veillez à stocker uniquement des secrets, tels que des mots de passe, des informations d’identification et des certificats. Dans un workflow d’application logique, veuillez ne pas utiliser Key Vault pour le stockage de valeurs non secrètes, comme des chemin d’accès d’URL, nécessaires au concepteur de workflow pour effectuer des appels. Le concepteur ne peut pas déréférencer un paramètre d’application qui référence un type de ressource Key Vault, ce qui entraîne une erreur et un échec d’appel. Pour les valeurs non secrètes, stockez-les directement dans les paramètres d’application.
Pour plus d’informations sur la configuration de vos applications logiques pour le déploiement, consultez la documentation suivante :
- Créer des paramètres pour les valeurs qui changent dans les workflows entre les environnements pour Azure Logic Apps monolocataire
- Présentation du déploiement DevOps pour les applications logiques basées monolocataires
- Configurer le déploiement DevOps pour les applications logiques monolocataires
Structure de projet Visual Studio Code
Dans Visual Studio Code, votre projet d’application logique a l’un des types suivants :
- Extension basée sur un bundle (Node.js), qui est le type par défaut
- NuGet basé sur un package (.NET), que vous pouvez convertir à partir du type par défaut
En fonction de ces types, votre projet comprend des dossiers et des fichiers légèrement différents. Un projet NuGet inclut un dossier .bin qui contient des packages et d’autres fichiers de bibliothèque. Un projet basé sur un bundle n’inclut pas le dossier .bin ni d’autres fichiers. Certains scénarios exigent un projet NuGet pour que votre application s’exécute, par exemple quand vous voulez développer et exécuter des opérations intégrées personnalisées. Pour plus d’informations sur la conversion de votre projet pour utiliser NuGet, consultez Activer la création de connecteurs intégrés.
Pour le projet basé sur un bundle par défaut, votre projet a une structure de dossiers et de fichiers similaire à celle de l’exemple suivant :
MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
|| Maps
||| MapName1
||| ...
|| Schemas
||| SchemaName1
||| ...
| WorkflowName1
|| workflow.json
|| ...
| WorkflowName2
|| workflow.json
|| ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json
Au niveau racine de votre projet se trouvent les fichiers et dossiers suivants avec d’autres éléments :
Nom | Fichier ou dossier | Description |
---|---|---|
.vscode | Dossier | Contient les fichiers de paramètres liés à Visual Studio Code, comme les fichiers extensions.json, launch.json, settings.json et tasks.json. |
Artefacts | Dossier | Contient les artefacts de compte d’intégration que vous définissez et utilisez dans des workflows qui prennent en charge les scénarios interentreprises (B2B, Business-to-Business). Par exemple, l’exemple de structure comprend des mappages et des schémas pour les opérations de transformation et de validation XML. |
<WorkflowName> | Dossier | Pour chaque workflow, le dossier <WorkflowName> inclut un fichier workflow.json, qui contient la définition JSON sous-jacente de ce workflow. |
workflow-designtime | Dossier | Contient les fichiers de paramètres liés à l’environnement de développement. |
.funcignore | Fichier | Contient des informations relatives à votre ensemble d’outils Azure Functions Core Tools installé. |
connections.json | Fichier | Contient les métadonnées, les points de terminaison et les clés de toutes les connexions managées et fonctions Azure utilisées par vos workflows. Important : Pour utiliser des connexions et des fonctions différentes pour chaque environnement, veillez à paramétrer ce fichier connections.json et mettre à jour les points de terminaison. |
host.json | Fichier | Contient des paramètres de configuration et des valeurs spécifiques au runtime, par exemple les limites par défaut pour la plateforme, les applications logiques, les workflows, les déclencheurs et les actions Azure Logic Apps à locataire unique. Au niveau racine de votre projet d’application logique, le fichier de métadonnées host.json contient les paramètres de configuration et les valeurs par défaut que tous les workflows d’une même application logique utilisent lors de l’exécution, que ce soit localement ou dans Azure. Remarque : Quand vous créez votre application logique, Visual Studio Code crée un fichier host.snapshot.*.json de sauvegarde dans votre conteneur de stockage. Si vous supprimez votre application logique, ce fichier de sauvegarde n’est pas supprimé. Si vous créez une autre application logique portant le même nom, un autre fichier d’instantané est créé. Vous pouvez avoir jusqu’à 10 instantanés pour la même application logique. Si vous dépassez cette limite, vous obtenez l’erreur suivante : Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host)) Pour résoudre cette erreur, supprimez les fichiers d’instantanés supplémentaires de votre conteneur de stockage. |
local.settings.json | Fichier | Contient les paramètres d’application, les chaînes de connexion et d’autres paramètres utilisés par vos workflows lors d’une exécution locale. En d’autres termes, ces paramètres et valeurs s’appliquent uniquement quand vous exécutez vos projets dans votre environnement de développement local. Lors d’un déploiement sur Azure, le fichier et les paramètres sont ignorés et ne sont pas inclus dans votre déploiement. Ce fichier stocke les paramètres et les valeurs sous la forme de variables d’environnement local utilisées par vos outils de développement locaux comme valeurs appSettings . Vous pouvez appeler et référencer ces variables d’environnement au moment de l’exécution et au moment du déploiement à l’aide des paramètres d’application et des configurations. Important : Le fichier local.settings.json peut contenir des secrets. Par conséquent, veillez à exclure également ce fichier du contrôle de code source de votre projet. |
Informations de référence sur les paramètres d’application - local.settings.json
Dans Visual Studio Code, au niveau de la racine de votre projet d’application logique, le fichier local.settings.json contient des options de configuration globale qui affectent tous les workflows de cette application logique en cours d’exécution dans votre environnement de développement local. Lorsque vos workflows s’exécutent localement, ces paramètres sont accessibles en tant que variables d’environnement locales et leurs valeurs peuvent souvent changer entre les différents environnements dans lesquels vous exécutez vos workflows. Pour afficher et gérer ces paramètres, consultez Gérer les paramètres d’application - local.settings.json.
Les paramètres de l’application dans Azure Logic Apps fonctionnent de la même façon que les paramètres de l’application dans Azure Functions ou Azure Web Apps. Si vous avez déjà utilisé ces autres services, vous connaissez peut-être déjà les paramètres d’application. Pour plus d’informations, consultez Référence des paramètres d’application pour Azure Functions et Utiliser Azure Functions Core Tools - Fichier de paramètres local.
Pour que votre workflow fonctionne correctement, certains paramètres d’application sont obligatoires.
Paramètre | Requis | Value | Description |
---|---|---|---|
APP_KIND |
Oui | workflowApp |
Obligatoire pour définir le type d’application pour la ressource d’application logique Standard. La valeur doit être définie sur workflowApp . Remarque : dans certains scénarios, ce paramètre d’application peut-être absent, par exemple en raison de l’automatisation à l’aide de modèles Azure Resource Manager ou d’autres scénarios dans lesquels le paramètre n’est pas inclus. Si certaines actions ne fonctionnent pas, comme l’action Exécuter le code JavaScript, ou si le workflow cesse de fonctionner, vérifiez que le paramètre d’application APP_KIND existe et qu’il est défini sur workflowApp . |
AZURE_AUTHORITY_HOST |
Non | Aucun(e) | Définit l’autorité par défaut de l’application logique Standard à utiliser pour l’authentification OAuth. |
AzureWebJobsStorage |
Oui | Aucune | Obligatoire pour définir la chaîne de connexion pour un compte de stockage Azure. Pour plus d’informations, consultez AzureWebJobsStorage. |
FUNCTIONS_EXTENSION_VERSION |
Oui | ~4 |
Obligatoire pour définir la version Azure Functions. Pour découvrir plus d’informations, consultez FUNCTIONS_EXTENSION_VERSION. |
FUNCTIONS_WORKER_RUNTIME |
Oui | dotnet |
Obligatoire pour définir le runtime du Worker de langage pour votre ressource et vos workflows d’application logique. Remarque : la valeur de ce paramètre a été précédemment définie sur node , mais la valeur requise est dotnet pour toutes les applications logiques Standard déployées, nouvelles et existantes. Cette modification ne doit pas affecter le runtime de votre flux de travail. Tout doit donc fonctionner de la même manière qu’auparavant. Pour plus d’informations, consultez FUNCTIONS_WORKER_RUNTIME. |
ServiceProviders.Sftp.FileUploadBufferTimeForTrigger |
Non | 00:00:20 (20 secondes) |
Définit le temps de mémoire tampon pour ignorer les fichiers dont l’horodatage de la dernière modification est supérieur à l’heure actuelle. Ce paramètre est utile lorsque les écritures de fichiers volumineux prennent beaucoup de temps et évite d’extraire des données pour un fichier partiellement écrit. |
ServiceProviders.Sftp.OperationTimeout |
Non | 00:02:00 (2 minutes) |
Définit le temps d’attente avant d’expirer sur une opération. |
ServiceProviders.Sftp.ServerAliveInterval |
Non | 00:30:00 (30 min) |
Permet d’envoyer un message « connexion persistante » pour maintenir la connexion SSH active si aucun échange de données avec le serveur n’a lieu pendant la période spécifiée. |
ServiceProviders.Sftp.SftpConnectionPoolSize |
Non | 2 connexions |
Définit le nombre de connexions que chaque processeur peut mettre en cache. Le nombre total de connexions que vous pouvez mettre en cache est ProcessorCount multiplié par la valeur de paramètre. |
ServiceProviders.MaximumAllowedTriggerStateSizeInKB |
Non | 10 Ko, soit environ 1 000 fichiers |
Définit la taille de l’entité d’état du déclencheur en kilo-octets, qui est proportionnelle au nombre de fichiers dans le dossier surveillé et utilisée pour détecter les fichiers. Si le nombre de fichiers dépasse 1 000, augmentez cette valeur. |
ServiceProviders.Sql.QueryTimeout |
Non | 00:02:00 (2 minutes) |
Définit la valeur du délai d’expiration de la requête pour les opérations du fournisseur de services SQL. |
WEBSITE_CONTENTSHARE |
Oui | Dynamique | Obligatoire pour définir le nom du partage de fichiers qu’Azure Functions utilise pour stocker le code d’application de fonction et les fichiers config et est utilisé avec WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. La valeur par défaut est une chaîne unique générée par le runtime. Pour découvrir plus d’informations, consultez WEBSITE_CONTENTSHARE. |
WEBSITE_LOAD_ROOT_CERTIFICATES |
Non | Aucune | Définit les empreintes pour que les certificats racines soient approuvés. |
Workflows.Connection.AuthenticationAudience |
Non | Aucune | Définit l’audience pour l’authentification d’une connexion managée (hébergée sur Azure). |
Workflows.CustomHostName |
Non | Aucune | Définit le nom d’hôte à utiliser pour les URL de flux de travail et de sortie d’entrée, par exemple « logic.contoso.com ». Pour plus d’informations sur la configuration d’un nom DNS personnalisé, consultez Mapper un nom DNS personnalisé existant à Azure App Service et Sécuriser un nom DNS personnalisé avec une liaison TLS/SSL dans Azure App Service. |
Workflows.<workflowName>.FlowState |
Non | Aucune | Définit l’état pour <workflowName>. |
Workflows.<workflowName>.RuntimeConfiguration.RetentionInDays |
Non | 90 jours |
Définit la durée en jours pour conserver l’historique des exécutions pour <workflowName>. – Minimum : 7 jours – Maximum : 365 jours |
Workflows.RuntimeConfiguration.RetentionInDays |
Non | 90 jours |
Définit la durée en jours de conservation de l’historique des exécutions du workflow après le démarrage d’une exécution. – Minimum : 7 jours – Maximum : 365 jours |
Workflows.WebhookRedirectHostUri |
Non | Aucune | Définit le nom d’hôte à utiliser pour les URL de rappel de webhook. |
Gérer les paramètres d’application - local.settings.js
Pour ajouter, mettre à jour ou supprimer des paramètres d’application, sélectionnez et consultez les sections suivantes selon que vous utilisez le Portail Azure, Visual Studio Code, Azure CLI ou un modèle ARM (Bicep). Pour les paramètres d’application spécifiques à Logic Apps, consultez le Guide de référence des paramètres d’application disponibles - local.settings.json.
Afficher les paramètres d’application dans le portail
Dans la zone de recherche du portail Azure, recherchez et ouvrez votre application logique.
Dans votre menu d’application logique, sous Paramètres, sélectionnez Variables d'environnement.
Dans la page Variables d’environnement, sous l’onglet Paramètres d’application, passez en revue les paramètres de votre application logique.
Pour plus d’informations sur ces paramètres, consultez le Guide de référence des paramètres d’application disponibles - local.settings.json.
Pour afficher toutes les valeurs, sélectionnez Afficher les valeurs. Ou, pour afficher une seule valeur, dans la colonne Valeur, à côté de la valeur, sélectionnez l’« œil ».
Ajouter un paramètre d’application dans le portail
Référence pour les paramètres de l’hôte - host.json
Dans Visual Studio Code, au niveau de la racine de votre projet d’application logique, le fichier de métadonnées host.json contient les paramètres d’exécution et les valeurs par défaut qui s’appliquent à tous les workflows d’une ressource d’application logique, qu’ils s’exécutent localement ou dans Azure. Pour afficher et gérer ces paramètres, consultez Gérer les paramètres de l’hôte - host.json. Vous trouverez également des informations sur les limites associées dans la documentation Limites et configuration d’Azure Logic Apps.
Débit de l’orchestration de travail
Ces paramètres affectent le débit et la capacité d’Azure Logic Apps monolocataire à exécuter des opérations de workflow.
Paramètre | Valeur par défaut | Description |
---|---|---|
Jobs.BackgroundJobs.DispatchingWorkersPulseInterval |
00:00:01 (1 s) |
Définit l’intervalle d’interrogation des répartiteurs de travaux pour la file d’attente des travaux lorsque l’interrogation précédente ne retourne aucun travail. Les répartiteurs de travaux interrogent la file d’attente immédiatement lorsque l’interrogation précédente retourne un travail. |
Jobs.BackgroundJobs.NumPartitionsInJobDefinitionsTable |
4 partitions de travail |
Définit le nombre de partitions de travail dans la table de définition du travail. Cette valeur contrôle la quantité du débit d’exécution qui est affectée par les limites de stockage des partitions. |
Jobs.BackgroundJobs.NumPartitionsInJobTriggersQueue |
1 file d’attente de travaux |
Définit le nombre de files d’attente de travaux surveillées par les répartiteurs de travail pour les travaux à traiter. Cette valeur affecte également le nombre de partitions de stockage pour lesquelles des files d’attente de travaux existent. |
Jobs.BackgroundJobs.NumWorkersPerProcessorCount |
192 instances de worker répartiteur |
Définit le nombre d’instances de worker répartiteur ou de répartiteurs de travail à avoir par cœur de processeur. Cette valeur affecte le nombre d’exécutions de workflow par cœur. |
Jobs.BackgroundJobs.StatelessNumWorkersPerProcessorCount |
192 instances de worker répartiteur |
Définit le nombre d’instances de Worker répartiteur ou de répartiteurs de travail à avoir par cœur de processeur et par exécution sans état. Cette valeur affecte le nombre d’actions de workflow simultanées traitées par exécution. |
Vous utilisez les deux paramètres suivants pour arrêter manuellement et immédiatement supprimer les workflows spécifiés dans l’application logique Standard.
Remarque
Utilisez ces paramètres avec prudence et uniquement dans des environnements hors production, tels que des environnements de test de performances ou de charges, car vous ne pouvez pas annuler ou récupérer après ces opérations.
Paramètre | Valeur par défaut | Description |
---|---|---|
Jobs.CleanupJobPartitionPrefixes |
None | Permet de supprimer immédiatement tous les travaux d’exécution pour les workflows spécifiés. |
Jobs.SuspendedJobPartitionPartitionPrefixes |
Aucun | Permet d’arrêter les travaux d’exécution pour les workflows spécifiés. |
L’exemple suivant illustre la syntaxe pour ces paramètres dans lesquels l’ID de workflow est suivi des deux-points (:) et séparé par un point-virgule (;) :
"Jobs.CleanupJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2:",
"Jobs.SuspendedJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2>:"
Déclencheurs basés sur la récurrence
Paramètre | Valeur par défaut | Description |
---|---|---|
Microsoft.Azure.Workflows.ServiceProviders.MaximumAllowedTriggerStateSizeInKB |
1 ko |
Définit la taille maximale autorisée de l’état du déclencheur pour les déclencheurs basés sur la récurrence, tels que le déclencheur SFTP intégré. L’état du déclencheur conserve les données entre les déclencheurs basés sur la récurrence de plusieurs fournisseurs de services. Important : Selon la taille de votre stockage, évitez de définir une valeur trop élevée, ce qui peut nuire au stockage et aux performances. |
Déclencheur simultané
Les paramètres suivants fonctionnent uniquement pour les flux de travail qui commencent par un déclencheur basé sur la périodicité pour les connecteurs intégrés basés sur le fournisseur de services. Pour un flux de travail qui commence par un déclencheur basé sur une fonction, vous pouvez essayer de configurer le traitement par lots là où il est pris en charge. Toutefois, le traitement par lots n’est pas toujours la bonne solution. Par exemple, un lot peut conserver des messages au-delà de la durée du verrouillage avec les déclencheurs Azure Service Bus. Par conséquent, toute action, comme l’achèvement ou l’abandon, échoue sur ces messages.
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.Trigger.MaximumRunConcurrency |
100 exécutions |
Définit le nombre maximal d’exécutions simultanées qu’un déclencheur peut démarrer. Cette valeur s’affiche dans la définition de concurrence du déclencheur. |
Runtime.Trigger.MaximumWaitingRuns |
200 exécutions |
Définit le nombre maximal d’exécutions qui peuvent être en attente une fois que les exécutions simultanées ont atteint la valeur maximale. Cette valeur s’affiche dans la définition de concurrence du déclencheur. Pour obtenir plus d’informations, consultez Modifier la limite d’exécutions en attente. |
Durée d’exécution et historique de rétention
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.Backend.FlowRunTimeout |
90.00:00:00 (90 jours) |
Définit la durée pendant laquelle un workflow peut continuer à s’exécuter avant de forcer un délai d’expiration. La valeur minimale de ce paramètre est de 7 jours. Important: vérifiez que cette valeur est inférieure ou égale à la valeur du paramètre d’application nommé Workflows.RuntimeConfiguration.RetentionInDays . Sinon, les historiques des exécutions peuvent être supprimés avant la fin des travaux associés. |
Runtime.FlowMaintenanceJob.RetentionCooldownInterval |
7.00:00:00 (7 jours) |
Définit la durée en jours comme intervalle entre le moment où vérifier et supprimer l’historique des exécutions que vous ne souhaitez plus conserver. |
Actions d’exécution
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout |
00:10:00 (10 minutes) |
Définit la durée d’exécution d’un travail d’action de workflow avant expiration et nouvelle tentative. |
Entrées et sorties
Paramètre | Valeur par défaut | Description |
---|---|---|
Microsoft.Azure.Workflows.TemplateLimits.InputParametersLimit |
50 |
Modifiez la limite par défaut des paramètres de flux de travail inter-environnements jusqu’à 500 pour les applications logiques Standard créées en exportant les applications logiques consommation. |
Runtime.ContentLink.MaximumContentSizeInBytes |
104857600 octets |
Définit la taille maximale possible en octets d’une entrée ou d’une sortie dans un déclencheur ou une action unique. |
Runtime.FlowRunActionJob.MaximumActionResultSize |
209715200 octets |
Définit la taille maximale possible en octets des entrées et sorties combinées dans une action unique. |
Pagination
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.FlowRunRetryableActionJobCallback.MaximumPageCount |
1000 pages |
Lorsque la pagination est prise en charge et activée sur une opération, définit le nombre maximal de pages à retourner ou à traiter au moment de l’exécution. |
Segmentation
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.FlowRunRetryableActionJobCallback.MaximumContentLengthInBytesForPartialContent |
1073741824 octets |
Lorsque la segmentation est prise en charge et activée sur une opération, définit la taille maximale en octets pour le contenu téléchargé ou chargé. |
Runtime.FlowRunRetryableActionJobCallback.MaxChunkSizeInBytes |
52428800 octets |
Lorsque la segmentation est prise en charge et activée sur une opération, définit la taille maximale en octets pour chaque bloc. |
Runtime.FlowRunRetryableActionJobCallback.MaximumRequestCountForPartialContent |
1000 requêtes |
Lorsque la segmentation est prise en charge et activée sur une opération, définit le nombre maximal de requêtes qu’une exécution d’action peut effectuer pour télécharger du contenu. |
Stocker du contenu inline ou utiliser des objets blob
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.FlowRunEngine.ForeachMaximumItemsForContentInlining |
20 éléments |
Lorsqu’une boucle For each est en cours d’exécution, la valeur de chaque élément est stockée inline avec d’autres métadonnées dans le stockage de table ou séparément dans le stockage d’objets blob. Définit le nombre d’éléments à stocker inline avec d’autres métadonnées. |
Runtime.FlowRunRetryableActionJobCallback.MaximumPagesForContentInlining |
20 pages |
Définit le nombre maximal de pages à stocker en tant que contenu inline dans le stockage de table avant d’être stocké dans le stockage d’objets blob. |
Runtime.FlowTriggerSplitOnJob.MaximumItemsForContentInlining |
40 éléments |
Lorsque le paramètre SplitOn dégroupe des éléments de tableau en plusieurs instances de workflow, la valeur de chaque élément est stockée inline avec d’autres métadonnées dans le stockage de table ou séparément dans le stockage d’objets blob. Définit le nombre d’éléments à stocker inline. |
Runtime.ScaleUnit.MaximumCharactersForContentInlining |
8192 caractères |
Définit le nombre maximal de caractères d’entrée et de sortie d’opération à stocker inline dans le stockage de table avant de les stocker dans le stockage d’objets blob. |
Boucles Foreach
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.Backend.FlowDefaultForeachItemsLimit |
100000 éléments de tableau |
Pour un workflow avec état, définit le nombre maximal d’éléments de tableau à traiter dans une boucle For each . |
Runtime.Backend.FlowDefaultSplitOnItemsLimit |
100000 éléments de tableau |
Définit le nombre maximal d’éléments de tableau à décomposer ou à fractionner en plusieurs instances de workflow en fonction du paramètre SplitOn . |
Runtime.Backend.ForeachDefaultDegreeOfParallelism |
20 itérations |
Définit le nombre par défaut d’itérations simultanées, ou degrés de parallélisme, dans une boucle For each . Pour une exécution séquentielle, définissez la valeur sur 1 . |
Runtime.Backend.Stateless.FlowDefaultForeachItemsLimit |
100 éléments |
Pour un workflow sans état, définit le nombre maximal d’éléments de tableau à traiter dans une boucle For each . |
Boucles until
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.Backend.MaximumUntilLimitCount |
5000 itérations |
Pour un workflow avec état, définit le nombre maximal possible de la propriété Count dans une action Until . |
Runtime.Backend.Stateless.FlowRunTimeout |
00:05:00 (5 min) |
Définit le délai d’attente maximal pour une boucle Until dans un workflow sans état. |
Runtime.Backend.Stateless.MaximumUntilLimitCount |
100 itérations |
Pour un workflow sans état, définit le nombre maximal possible de la propriété Count dans une action Until . |
Variables
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.Backend.DefaultAppendArrayItemsLimit |
100000 éléments de tableau |
Définit le nombre maximal d’éléments dans une variable avec le type tableau. |
Runtime.Backend.VariableOperation.MaximumStatelessVariableSize |
Workflow sans état : 1024 caractères |
Définit la taille maximale, en caractères, du contenu qu’une variable peut stocker quand elle est utilisée dans un flux de travail sans état. |
Runtime.Backend.VariableOperation.MaximumVariableSize |
Workflow avec état : 104857600 caractères |
Définit la taille maximale, en caractères, du contenu qu’une variable peut stocker quand elle est utilisée dans un flux de travail avec état. |
Opérations HTTP intégrées
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.Backend.HttpOperation.DefaultRetryCount |
4 nouvelles tentatives |
Définit le nombre de nouvelles tentatives par défaut pour les déclencheurs et les actions HTTP. |
Runtime.Backend.HttpOperation.DefaultRetryInterval |
00:00:07 (7 s) |
Définit l’intervalle avant nouvelle tentative par défaut pour les déclencheurs et les actions HTTP. |
Runtime.Backend.HttpOperation.DefaultRetryMaximumInterval |
01:00:00 (1 heure) |
Définit l’intervalle maximal avant nouvelle tentative pour les déclencheurs et les actions HTTP. |
Runtime.Backend.HttpOperation.DefaultRetryMinimumInterval |
00:00:05 (5 s) |
Définit l’intervalle minimal avant nouvelle tentative pour les déclencheurs et les actions HTTP. |
Runtime.Backend.HttpOperation.MaxContentSize |
104857600 octets |
Permet de définir la taille maximale de requête, en octets, pour des actions HTTP uniquement, non pour des déclencheurs. Pour plus d’informations, consultez Limitations. |
Runtime.Backend.HttpOperation.RequestTimeout |
00:03:45 (3 min et 45 s) Remarque : la valeur par défaut est également la valeur maximale. |
Définit la valeur du délai d’expiration de la requête pour les déclencheurs et les actions HTTP. |
Opérations de webhook HTTP intégrées
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.Backend.HttpWebhookOperation.DefaultRetryCount |
4 nouvelles tentatives |
Définit le nombre de nouvelles tentatives par défaut pour les déclencheurs de webhook et les actions HTTP. |
Runtime.Backend.HttpWebhookOperation.DefaultRetryInterval |
00:00:07 (7 s) |
Définit l’intervalle de nouvelle tentative par défaut pour les déclencheurs de webhook et les actions HTTP. |
Runtime.Backend.HttpWebhookOperation.DefaultRetryMaximumInterval |
01:00:00 (1 heure) |
Définit l’intervalle de nouvelle tentative maximal pour les déclencheurs de webhook et les actions HTTP. |
Runtime.Backend.HttpWebhookOperation.DefaultRetryMinimumInterval |
00:00:05 (5 s) |
Définit l’intervalle de nouvelle tentative minimal pour les déclencheurs de webhook et les actions HTTP. |
Runtime.Backend.HttpWebhookOperation.DefaultWakeUpInterval |
01:00:00 (1 heure) |
Définit l’intervalle de réveil par défaut pour les travaux d’action et de déclencheur de webhook HTTP. |
Runtime.Backend.HttpWebhookOperation.MaxContentSize |
104857600 octets |
Permet de définir la taille maximale de requête, en octets, pour des actions de webhook HTTP uniquement, non pour des déclencheurs. Pour plus d’informations, consultez Limitations. |
Runtime.Backend.HttpWebhookOperation.RequestTimeout |
00:02:00 (2 minutes) |
Définit la valeur du délai d’expiration de la requête pour les déclencheurs de webhook et les actions HTTP. |
Opérations de stockage Azure intégrées
Stockage d'objets blob
Paramètre | Valeur par défaut | Description |
---|---|---|
Microsoft.Azure.Workflows.ContentStorage.RequestOptionsThreadCount |
None | Définit le nombre de threads pour les opérations de chargement et de téléchargement d’objets blob. Vous pouvez utiliser ce paramètre pour forcer le runtime Azure Logic Apps à utiliser plusieurs threads lors du chargement et du téléchargement de contenu à partir d’entrées et de sorties d’action. |
Runtime.ContentStorage.RequestOptionsDeltaBackoff |
00:00:02 (2 s) |
Définit l’intervalle de backoff entre les nouvelles tentatives envoyées au stockage d’objets blob. |
Runtime.ContentStorage.RequestOptionsMaximumAttempts |
4 nouvelles tentatives |
Définit le nombre maximal de nouvelles tentatives envoyées au stockage de table et de file d’attente. |
Runtime.ContentStorage.RequestOptionsMaximumExecutionTime |
00:02:00 (2 minutes) |
Définit la valeur du délai d’expiration de l’opération, y compris les nouvelles tentatives, pour les requêtes blob à partir du runtime Azure Logic Apps. |
Runtime.ContentStorage.RequestOptionsServerTimeout |
00:00:30 (30 s) |
Définit la valeur du délai d’attente pour les requêtes d’objet blob à partir du runtime Azure Logic Apps. |
Stockage Table et File d’attente
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.DataStorage.RequestOptionsDeltaBackoff |
00:00:02 (2 s) |
Définit l’intervalle d’interruption entre les nouvelles tentatives envoyées au stockage de table et de file d’attente. |
Runtime.DataStorage.RequestOptionsMaximumAttempts |
4 nouvelles tentatives |
Définit le nombre maximal de nouvelles tentatives envoyées au stockage de table et de file d’attente. |
Runtime.DataStorage.RequestOptionsMaximumExecutionTime |
00:00:45 (45 s) |
Définit la valeur du délai d’attente de l’opération, y compris les nouvelles tentatives, pour les demandes de stockage de file d’attente et de table à partir du runtime Azure Logic Apps. |
Runtime.DataStorage.RequestOptionsServerTimeout |
00:00:16 (16 s) |
Définit la valeur du délai d’attente pour les demandes de stockage de table et de file d’attente à partir du runtime Azure Logic Apps. |
Partage de fichiers
Paramètre | Valeur par défaut | Description |
---|---|---|
ServiceProviders.AzureFile.MaxFileSizeInBytes |
150000000 octets |
Définit la taille de fichier maximale en octets pour un partage de fichiers Azure. |
Opérations Azure Functions intégrées
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.Backend.FunctionOperation.RequestTimeout |
00:03:45 (3 min et 45 s) |
Définit la valeur du délai d’expiration de la requête pour les actions Azure Functions. |
Runtime.Backend.FunctionOperation.MaxContentSize |
104857600 octets |
Définit la taille maximale de la requête en octets pour les actions Azure Functions. Pour plus d’informations, consultez Limitations. |
Runtime.Backend.FunctionOperation.DefaultRetryCount |
4 nouvelles tentatives |
Définit le nombre de nouvelles tentatives par défaut pour les actions Azure Functions. |
Runtime.Backend.FunctionOperation.DefaultRetryInterval |
00:00:07 (7 s) |
Définit l’intervalle avant nouvelle tentative par défaut pour les actions Azure Functions. |
Runtime.Backend.FunctionOperation.DefaultRetryMaximumInterval |
01:00:00 (1 heure) |
Définit l’intervalle avant nouvelle tentative maximal pour les actions Azure Functions. |
Runtime.Backend.FunctionOperation.DefaultRetryMinimumInterval |
00:00:05 (5 s) |
Définit l’intervalle avant nouvelle tentative minimal pour les actions Azure Functions. |
Opérations Azure Service Bus intégrées
Paramètre | Valeur par défaut | Description |
---|---|---|
ServiceProviders.ServiceBus.MessageSenderOperationTimeout |
00:01:00 (1 min) |
Définit le délai d’attente pour l’envoi de messages avec l’opération Service Bus intégrée. |
Runtime.ServiceProviders.ServiceBus.MessageSenderPoolSizePerProcessorCount |
64 expéditeurs de messages |
Définit le nombre d’expéditeurs de messages Azure Service Bus par cœur de processeur à utiliser dans le pool d’expéditeurs de messages. |
Opérations SFTP intégrées
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.ServiceProviders.Sftp.MaxFileSizeInBytes |
2147483648 octets |
Définit la taille de fichier maximale en octets pour l’action Obtenir le contenu du fichier (V2). |
Runtime.ServiceProviders.Sftp.MaximumFileSizeToReadInBytes |
209715200 octets |
Définit la taille de fichier maximale en octets pour l’action Obtenir le contenu du fichier . Assurez-vous que cette valeur ne dépasse pas la taille de mémoire pouvant être référencée, car cette action lit le contenu du fichier en mémoire. |
Opérations du connecteur managé
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.Backend.ApiConnectionOperation.RequestTimeout |
00:02:00 (2 minutes) |
Définit la valeur du délai d’expiration de la requête pour les déclencheurs et les actions du connecteur d’API géré. |
Runtime.Backend.ApiConnectionOperation.MaxContentSize |
104857600 octets |
Définit la taille maximale de la requête, en octets, pour les déclencheurs et les actions du connecteur d’API géré. Pour plus d’informations, consultez Limitations. |
Runtime.Backend.ApiConnectionOperation.DefaultRetryCount |
4 nouvelles tentatives |
Définit le nombre de nouvelles tentatives par défaut pour les déclencheurs et les actions du connecteur d’API géré. |
Runtime.Backend.ApiConnectionOperation.DefaultRetryInterval |
00:00:07 (7 s) |
Définit l’intervalle avant nouvelle tentative par défaut pour les déclencheurs et les actions du connecteur d’API géré. |
Runtime.Backend.ApiWebhookOperation.DefaultRetryMaximumInterval |
01:00:00 (1 jour) |
Définit l’intervalle maximal avant nouvelle tentative pour les déclencheurs de webhook et actions du connecteur d’API géré. |
Runtime.Backend.ApiConnectionOperation.DefaultRetryMinimumInterval |
00:00:05 (5 s) |
Définit l’intervalle minimal avant nouvelle tentative pour les déclencheurs et les actions du connecteur d’API géré. |
Runtime.Backend.ApiWebhookOperation.DefaultWakeUpInterval |
01:00:00 (1 jour) |
Définit l’intervalle de réveil par défaut pour les travaux de déclencheur de webhook et actions du connecteur d’API managé. |
Stratégie de nouvelle tentative pour toutes les autres opérations
Paramètre | Valeur par défaut | Description |
---|---|---|
Runtime.ScaleMonitor.MaxPollingLatency |
00:00:30 (30 s) |
Définit la latence d’interrogation maximale pour la mise à l’échelle du runtime. |
Runtime.Backend.Operation.MaximumRetryCount |
90 nouvelles tentatives |
Définit le nombre maximal de nouvelles tentatives dans la définition de stratégie de nouvelle tentative pour une opération de workflow. |
Runtime.Backend.Operation.MaximumRetryInterval |
01:00:00:01 (1 jour et 1 seconde) |
Définit l’intervalle maximal dans la définition de stratégie de nouvelle tentative pour une opération de workflow. |
Runtime.Backend.Operation.MinimumRetryInterval |
00:00:05 (5 s) |
Définit l’intervalle minimal dans la définition de stratégie de nouvelle tentative pour une opération de workflow. |
Limites
Taille maximale du contenu
Les déclencheurs intégrés, tels que HTTP ou Requête, sont par défaut limités à la taille de message décrite dans Référence de configuration et limites – Messages. Pour gérer des fichiers de taille supérieure à la limite, essayez de télécharger votre contenu en tant que blob dans Stockage Blob Azure, puis obtenez votre contenu en utilisant le connecteur Blob Azure.
Gérer les paramètres de l’hôte - host.json
Vous pouvez ajouter, mettre à jour ou supprimer des paramètres d’hôte, qui spécifient les paramètres de configuration du runtime et les valeurs qui s’appliquent à tous les workflows de cette application logique, comme les valeurs par défaut pour le débit, la capacité, la taille des données, etc., qu’elles s’exécutent localement ou dans Azure. Pour les paramètres d’hôte spécifiques à Logic Apps, consultez le Guide de référence pour les paramètres de déploiement et d’exécution disponibles - host.json.
Portail Azure - host.json
Pour passer en revue les paramètres d’hôte pour votre application logique basée sur un seul locataire dans le portail Azure, procédez comme suit :
Dans la zone de recherche du portail Azure, recherchez et ouvrez votre application logique.
Dans le menu de ressources, sous Outils de développement, sélectionnez Outils Avancés.
Dans le volet Outils avancés, sélectionnez Accéder, ce qui ouvre l’environnement Kudu pour votre application logique.
Dans la barre d’outils Kudu, ouvrez le menu Console de débogage, puis sélectionnez CMD.
Une fenêtre de console s’ouvre pour vous permettre d’accéder au dossier wwwroot à l’aide de l’invite de commandes. Sinon, vous pouvez parcourir la structure des répertoires qui s’affiche au-dessus de la fenêtre de console.
Suivez le chemin menant au dossier wwwroot :
...\home\site\wwwroot
.Au-dessus de la fenêtre de la console, dans la table des répertoires, en regard du fichier host.json, sélectionnez Modifier.
Une fois que le fichier host.json s’ouvre, passez en revue tous les paramètres de l’hôte qui ont été ajoutés précédemment pour votre application logique.
Pour plus d’informations sur les paramètres de l’hôte, consultez le Guide de référence des paramètres d’hôte disponibles - host.json.
Pour ajouter un paramètre, effectuez les étapes suivantes :
Avant d’ajouter ou de modifier des paramètres, arrêtez votre application logique dans le portail Azure.
Dans le menu des ressources, sélectionnez Vue d’ensemble.
Dans la barre d’outils du volet Vue d’ensemble, sélectionnez Arrêter.
Si le fichier host.json est déjà ouvert, revenez au fichier host.json. Dans le cas contraire, suivez les étapes précédentes pour ouvrir le fichier host.json.
Sous l’objet
extensionBundle
, ajoutez l’objetextensions
, qui comprend les objetsworkflow
etsettings
, par exemple :{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "settings": { } } } }
Dans l’objet
settings
, ajoutez une liste plate avec les paramètres d’hôte que vous souhaitez utiliser pour tous les workflows de votre application logique, que ces workflows s’exécutent localement ou dans Azure, par exemple :{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "settings": { "Runtime.Trigger.MaximumWaitingRuns": "100" } } } }
Lorsque vous avez terminé, n’oubliez pas de sélectionner Enregistrer.
À présent, redémarrez votre application logique. Revenez à la page Vue d’ensemble de votre application logique, puis sélectionnez Redémarrer.
Visual Studio Code - host.json
Pour passer en revue les paramètres d’hôte de votre application logique dans Visual Studio Code, procédez comme suit :
Dans votre projet d’application logique, au niveau du projet racine, recherchez et ouvrez le fichier host.json.
Dans l’objet
extensions
, sousworkflows
etsettings
, examinez tous les paramètres d’hôte qui ont été précédemment ajoutés pour votre application logique. Sinon, l’objetextensions
n’apparaîtra pas dans le fichier.Pour plus d’informations sur les paramètres de l’hôte, consultez le Guide de référence des paramètres d’hôte disponibles - host.json.
Pour ajouter un paramètre d’hôte, effectuez les étapes suivantes :
Dans le fichier host.json, sous l’objet
extensionBundle
, ajoutez l’objetextensions
, qui comprend les objetsworkflow
etsettings
, par exemple :{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "settings": { } } } }
Dans l’objet
settings
, ajoutez une liste plate avec les paramètres d’hôte que vous souhaitez utiliser pour tous les workflows de votre application logique, que ces workflows s’exécutent localement ou dans Azure, par exemple :{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "settings": { "Runtime.Trigger.MaximumWaitingRuns": "100" } } } }