Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
S’applique à : Azure Logic Apps (Standard)
Ce guide explique comment gérer les paramètres d’exécution et d’environnement pour les applications logiques Standard dans Azure Logic Apps monolocataire.
Les paramètres d’application d’une application logique Standard spécifient les options de configuration globales qui affectent tous les flux de travail de cette application logique. Toutefois, ces paramètres s’appliquent uniquement lorsque ces flux de travail 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 et les valeurs d’exécution qui s’appliquent à tous les flux de travail de cette application logique, par exemple, les valeurs par défaut pour le débit, la capacité, la taille des données, et ainsi de suite, qu’ils s’exécutent localement ou dans Azure.
Les paramètres sont des paires clé-valeur qui définissent le nom et la valeur du paramètre.
Paramètres de l’application, paramètres et déploiement
Dans les Azure Logic Apps multilocataires, le déploiement dépend des modèles ARM (Azure Resource Manager), qui combinent et gèrent le provisionnement 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 à locataire unique , 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 des valeurs susceptibles de changer entre les environnements. 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 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.
Note
Si vous utilisez Azure Key Vault, veillez à stocker uniquement les secrets, tels que les mots de passe, les informations d’identification et les certificats. N’utilisez pas de coffre de clés dans un flux de travail d'application logique pour stocker des valeurs non sensibles, telles que des chemins d’URL, dont le concepteur de flux de travail a besoin pour effectuer des appels. Le concepteur ne peut pas déréférencer un paramètre d’application qui fait référence à une ressource Azure Key Vault, ce qui entraîne une erreur et un appel ayant échoué. Pour les valeurs non-secret, stockez-les directement dans les paramètres de l’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 inter-environnements pour les entrées de workflow dans Azure Logic Apps
- Présentation du déploiement DevOps pour les applications logiques 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 peut inclure des dossiers ou des fichiers légèrement différents. Par exemple, un projet nuget basé sur des packages a un dossier .bin qui contient des packages et d’autres fichiers de bibliothèque. Un projet basé sur un bundle d’extensions n’inclut pas ce dossier .bin .
Certains scénarios nécessitent l’exécution d’un projet basé sur un package NuGet pour que votre application s’exécute, par exemple lorsque vous souhaitez 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.
Le projet basé sur l’extension par défaut a un dossier et une structure de fichiers semblable à l’exemple suivant :
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
Au niveau racine de votre projet, vous trouverez les dossiers et fichiers suivants, ainsi que d’autres éléments :
| Name | Fichier ou dossier | Description |
|---|---|---|
| .vscode | Folder | Contient les fichiers de paramètres liés à Visual Studio Code, comme les fichiers extensions.json, launch.json, settings.json et tasks.json. |
| Artifacts | Folder | 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 inclut les dossiers suivants : - Cartes : contient des mappages à utiliser pour les opérations de transformation XML. - Schémas : contient des schémas à utiliser pour les opérations de validation XML. - Règles : Artefacts pour les règles d’entreprise dans les projets de moteur basés sur des règles. |
| lib | Folder | Contient des assemblages pris en charge que votre application logique est capable d'utiliser ou de référencer. Vous pouvez charger ces assemblys dans votre projet dans Visual Studio Code, mais vous devez les ajouter à des dossiers spécifiques dans votre projet. Par exemple, ce dossier inclut les dossiers suivants : - builtinOperationSdks : contient les dossiers JAR et net472 pour les assemblys Java et .NET Framework, respectivement. - custom : contient des assemblys personnalisés .NET Framework. Pour plus d’informations sur les types d’assemblys pris en charge et sur l’emplacement où les placer dans votre projet, consultez Ajouter des assemblys à votre projet. |
| < WorkflowName> | Folder | Pour chaque workflow, le dossier <WorkflowName> inclut un fichier workflow.json, qui contient la définition JSON sous-jacente de ce workflow. |
| workflow-designtime | Folder | Contient les fichiers de paramètres liés à l’environnement de développement. |
| .funcignore | File | Contient des informations relatives à votre ensemble d’outils Azure Functions Core Tools installé. |
| connections.json | File | 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 | File | 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. Pour obtenir des informations de référence, consultez Modifier les paramètres de l’application et les paramètres de l’hôte. 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 | File | 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. Ces paramètres et valeurs s’appliquent uniquement lorsque 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 en tant que variables d’environnement locales que vos outils de développement locaux utilisent pour les appSettings valeurs. 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. Ce fichier contient également les paramètres d’application dont votre application logique a besoin pour fonctionner correctement. Pour obtenir des informations de référence, consultez Modifier les paramètres de l’application et les paramètres de l’hôte. |
Informations de référence sur les paramètres d’application - local.settings.json
Dans Visual Studio Code, au niveau racine de votre projet d’application logique, le fichier local.settings.json contient des options de configuration globales qui affectent tous les flux de travail de cette application logique lors de l’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 savoir comment afficher et gérer ces paramètres, consultez Gérer les paramètres de l’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 la référence des paramètres d’application pour Azure Functions et Travailler avec Azure Functions Core Tools - Fichier de paramètres locaux.
Le tableau suivant décrit les paramètres d’application que votre application logique utilise. Certains paramètres sont requis pour que votre application logique fonctionne correctement :
| Setting | Required | Value | Description |
|---|---|---|---|
APP_KIND |
Yes | workflowApp |
Obligatoire pour définir le type d’application pour la ressource d’application logique Standard. Elle doit avoir la valeur workflowApp. Remarque : Dans certains scénarios, ce paramètre d’application peut être manquant, par exemple en raison de l’automatisation à l’aide de modèles Azure Resource Manager ou d’autres scénarios où le paramètre n’est pas inclus. Si certaines actions ne fonctionnent pas, comme l’action Exécuter du code JavaScript, ou si le flux de travail 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 |
No | None | Définit l’autorité par défaut de l’application logique Standard à utiliser pour l’authentification OAuth. |
AzureWebJobsStorage |
Yes | None | Obligatoire pour définir la chaîne de connexion pour un compte de stockage Azure. Pour plus d’informations, consultez AzureWebJobsStorage. |
FUNCTIONS_EXTENSION_VERSION |
Yes | ~4 |
Obligatoire pour définir la version Azure Functions. Pour plus d’informations, consultez FUNCTIONS_EXTENSION_VERSION. |
FUNCTIONS_WORKER_RUNTIME |
Yes | 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 désormais, la valeur requise est dotnet pour toutes les applications logiques standard déployées, qu'elles soient nouvelles ou 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 |
No | 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 |
No | 00:02:00 (2 minutes) |
Définit le temps d’attente avant d’expirer sur une opération. |
ServiceProviders.Sftp.ServerAliveInterval |
No | 00:30:00 (30 min) |
Envoie un message de maintien en vie pour conserver la connexion SSH active si aucun échange de données avec le serveur ne se produit pendant la période spécifiée. |
ServiceProviders.Sftp.SftpConnectionPoolSize |
No |
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 |
No |
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 |
No | 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 |
Yes | Dynamic | Obligatoire pour définir le nom du partage de fichiers utilisé par Azure Functions pour stocker le code de l’application de fonction et les fichiers de configuration et est utilisé avec WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. La valeur par défaut est une chaîne unique générée par le runtime. Pour plus d’informations, consultez WEBSITE_CONTENTSHARE. |
WEBSITE_LOAD_ROOT_CERTIFICATES |
No | None | Définit les empreintes pour que les certificats racines soient approuvés. |
WEBSITE_NODE_DEFAULT_VERSION |
Yes | ~ < Version> | Définit la version de Node.js lors de l'exécution des flux de travail de l'application logique sur Windows. Utilisez un tilde (~) pour que le runtime Azure Logic Apps utilise la dernière version disponible de la version principale ciblée. Par exemple, si la valeur est ~18, la dernière version de Node.js 18 est utilisée. Quand vous utilisez un tilde avec une version majeure, vous n’avez pas besoin de mettre à jour manuellement la version mineure. Pour plus d’informations, consultez WEBSITE_NODE_DEFAULT_VERSION. |
Workflows.Connection.AuthenticationAudience |
No | None | Définit l’audience pour l’authentification d’une connexion managée (hébergée sur Azure). |
Workflows.CustomHostName |
No | None | 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 Configurer un domaine personnalisé existant dans Azure App Service et activer HTTPS pour un domaine personnalisé dans Azure App Service. |
Workflows.<workflowName>.FlowState |
No | None | Définit l’état de <workflowName>. |
Workflows.<workflowName>.RuntimeConfiguration.RetentionInDays |
No |
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 |
No |
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 |
No | None | 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 passez en revue les sections suivantes pour le portail Azure, Visual Studio Code ou Azure CLI. Pour connaître les paramètres d’application spécifiques aux applications logiques, consultez Informations de référence sur les paramètres de l’application - 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 le menu de la barre latérale, sous Paramètres, sélectionnez Variables d’environnement.
Dans la page Variables d’environnement , sous l’onglet Paramètres de l’application, passez en revue les paramètres de l’application pour votre application logique.
Pour plus d’informations sur ces paramètres, consultez Référence pour les paramètres d’application - local.settings.json.
Pour afficher toutes les valeurs, dans la barre d’outils de la page, sélectionnez Afficher les valeurs. Ou, pour afficher une valeur unique, dans la colonne Valeur , sélectionnez Afficher la valeur (icône d’œil).
Ajouter un paramètre d’application dans le portail
Sous l’onglet Paramètres de l’application , dans la barre d’outils, sélectionnez Ajouter.
Dans le volet Ajouter/modifier le paramètre d’application, pour Nom, entrez la clé ou le nom de votre nouveau paramètre.
Pour Valeur, entrez la valeur de votre nouveau paramètre.
Une fois que vous avez terminé, sélectionnez Appliquer.
Référence pour les paramètres de l’hôte - host.json
Dans Visual Studio Code, au niveau 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 flux de travail d’une ressource d’application logique, qu’ils s’exécutent localement ou dans Azure. Pour savoir comment 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.
| Setting | Valeur par défaut | Description |
|---|---|---|
Jobs.BackgroundJobs.DispatchingWorkersPulseInterval |
00:00:01 (1 seconde) |
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. |
Les paramètres suivants sont utilisés pour arrêter et supprimer immédiatement les flux de travail spécifiés dans l’application logique Standard.
Note
Utilisez ces paramètres avec prudence et uniquement dans les environnements hors production, tels que les environnements de charge ou de test de performances, car vous ne pouvez pas annuler ou récupérer à partir de ces opérations.
| Setting | Valeur par défaut | Description |
|---|---|---|
Jobs.CleanupJobPartition |
None | Permet de supprimer immédiatement tous les travaux d’exécution pour les workflows spécifiés. |
Jobs.SuspendedJobPartition |
None | Permet d’arrêter les travaux d’exécution pour les workflows spécifiés. |
SequencerJobs.SuspendedSequencerPartition |
None | Arrête les travaux d’exécution du séquenceur pour les flux de travail spécifiés. |
Pour spécifier des flux de travail individuels, utilisez la syntaxe suivante où chaque ID de flux de travail est suivi d’un signe deux-points (:) et est séparé par un point-virgule (;) :
"Jobs.CleanupJobPartition": "<workflow-ID-1>:;<workflow-ID-2>",
"Jobs.SuspendedJobPartition": "<workflow-ID-1>:;<workflow-ID-2>:",
"SequencerJobs.SuspendedSequencerPartition": "<workflow-ID-1>:;<workflow-ID-2>:"
Pour annuler une exécution spécifique, fournissez l’ID d’exécution suivant l’ID de workflow avec 2D comme séparateur, par exemple :
"Jobs.SuspendedJobPartition": "<workflow-ID-1>:2D<run-ID>;",
Déclencheurs basés sur la périodicité
| Setting | 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 : en fonction de votre taille de stockage, évitez de définir cette valeur trop élevée, ce qui peut affecter négativement le stockage et les performances. |
Déclencher la concurrence
Les paramètres d’accès concurrentiel suivants s’appliquent uniquement aux flux de travail qui commencent par un déclencheur basé sur la périodicité pour les connecteurs intégrés, basés sur un fournisseur de services et contrôlent le nombre de flux de travail qui s’exécutent simultanément, ou en même temps.
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.
| Setting | 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 rétention de l’historique
| Setting | 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. |
Exécuter des actions
| Setting | 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. Pour modifier le délai d’expiration par défaut d’une opération intégrée telle que SAP, définissez également le functionTimeout paramètre hôte. Pour plus d’informations, consultez l’entrée suivante. |
functionTimeout |
00:30:00 (30 minutes) |
Définit la durée à exécuter avant l’expiration du délai d’attente pour les appels à partir d’Azure Functions et certaines opérations intégrées, telles que le protocole SAP, qui fonctionnent en tant qu’appels de fonction. Les applications logiques standard utilisent la même conception sous-jacente que les applications de fonction. Par conséquent, le functionTimeout paramètre hôte dans Azure Functions affecte également les opérations intégrées qui s’exécutent en tant qu’appels de fonction. Pour plus d’informations, consultez functionTimeout. Remarque : Dans le fichier host.json , le functionTimeout paramètre existe au même niveau que l’objet extensions où les paramètres d’hôte existent pour une application logique standard. Pour plus d’informations, consultez l’exemple de cette section : Modifier la valeur du délai d’expiration pour les opérations intégrées basées sur les fonctions. |
Modifier la valeur du délai d’expiration pour les opérations intégrées basées sur les fonctions
Pour les opérations intégrées qui s’exécutent en tant qu’appels de fonction dans Azure Functions, ajoutez à la fois les paramètres Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout et functionTimeout d’hôte à votre fichier host.json, comme indiqué dans l’exemple suivant :
{
"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"
}
Entrées et sorties
| Setting | Valeur par défaut | Description |
|---|---|---|
Microsoft.Azure.Workflows.TemplateLimits.InputParametersLimit |
50 |
Modifie la limite par défaut des paramètres de flux de travail multi-environnements à 500 pour les applications logiques standard créées en exportant des applications logiques de 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
| Setting | 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. |
Chunking
| Setting | 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
| Setting | 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 |
Lorsqu’un déclencheur qui prend en charge le fractionnement a le paramètre Activé sur ou splitOn activé, le déclencheur divise les éléments du tableau en plusieurs instances de processus de travail. La valeur de chaque élément de tableau est stockée en ligne avec d'autres métadonnées dans le stockage de tableaux ou bien séparément dans le stockage blob. Définit le nombre d’éléments à stocker inline. |
Runtime.ScaleUnit.MaximumCharactersForContentInlining |
32384 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
| Setting | Valeur par défaut | Description |
|---|---|---|
Runtime.Backend.FlowDefaultForeachItemsLimit |
100000 éléments de tableau |
Pour un flux de travail avec état, définit le nombre maximal d’éléments de tableau à traiter dans une For each boucle. |
Runtime.Backend.FlowDefaultSplitOnItemsLimit |
100000 éléments de tableau |
Définit le nombre maximal d'éléments dans un tableau à désassembler ou à fractionner en plusieurs instances de workflow, en fonction de la propriété 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 flux de travail sans état, définit le nombre maximal d’éléments de tableau à traiter dans une For each boucle. |
Boucles until
| Setting | Valeur par défaut | Description |
|---|---|---|
Runtime.Backend.MaximumUntilLimitCount |
5000 itérations |
Pour un flux de travail avec état, définit le nombre maximal possible pour la Count propriété dans une Until action. |
Runtime.Backend.Stateless.FlowRunTimeout |
00:05:00 (5 minutes) |
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 flux de travail sans état, définit le nombre maximal possible pour la Count propriété dans une Until action. |
Variables
| Setting | 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
| Setting | 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 secondes) |
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 secondes) |
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
| Setting | 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 secondes) |
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 secondes) |
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
| Setting | 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 secondes) |
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 secondes) |
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
| Setting | Valeur par défaut | Description |
|---|---|---|
Runtime.DataStorage.RequestOptionsDeltaBackoff |
00:00:02 (2 secondes) |
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 secondes) |
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 secondes) |
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
| Setting | 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
| Setting | 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 secondes) |
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 secondes) |
Définit l’intervalle avant nouvelle tentative minimal pour les actions Azure Functions. |
Opérations Azure Service Bus intégrées
| Setting | 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
| Setting | 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é
| Setting | 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 secondes) |
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 secondes) |
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
| Setting | Valeur par défaut | Description |
|---|---|---|
Runtime.ScaleMonitor.MaxPollingLatency |
00:00:30 (30 secondes) |
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 secondes) |
Définit l’intervalle minimal dans la définition de stratégie de nouvelle tentative pour une opération de workflow. |
Limitations
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 connaître les paramètres d’hôte spécifiques aux applications logiques, consultez Informations de référence sur les paramètres de l’hôte - 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 des 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 afin que vous puissiez 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.
Parcourez le chemin d’accès suivant au dossier wwwroot :
...\home\site\wwwroot.Au-dessus de la fenêtre de console, dans la table de répertoires, en regard du fichier host.json , sélectionnez Modifier.
Une fois le fichier host.json ouvert, passez en revue les paramètres d’hôte qui ont été précédemment ajoutés pour votre application logique.
Pour plus d’informations sur les paramètres de l’hôte, consultez Informations de référence sur les paramètres de l’hôte - 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 objetsworkflowetSettings, 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.