Créez des projets pour Azure Logic Apps Rules Engine en utilisant Visual Studio Code

S’applique à : Azure Logic Apps (Standard)

Quand vous voulez intégrer une logique métier à vos workflows Standard dans Azure Logic Apps, vous pouvez créer et générer un projet de moteur de règles Azure Logic Apps avec Visual Studio Code. Les règles gèrent la logique métier qui définit le fonctionnement des processus métier.

Pour exécuter vos règles à partir d’un workflow, utilisez une fonction locale personnalisée pour les ensembles de règles incluant des faits .NET. Pour les ensembles de règles qui utilisent uniquement des faits XML, vous pouvez utiliser l’action intégrée Exécuter le moteur de règles , qui est actuellement en aperçu.

Ce guide montre comment créer un projet de moteur de règles Azure Logic Apps :

Prérequis et configuration pour créer votre projet Azure Logic Apps Rules Engine, y compris la création des règles métier de votre projet en utilisant le Microsoft Rules Composer.
Exportez des règles existantes à partir de Microsoft BizTalk Server, le cas échéant.
Créez un projet Standard Logic Apps pour le moteur de règles Azure Logic Apps en utilisant Visual Studio Code.
Exécutez des ensembles de règles depuis votre flux de travail en utilisant soit une fonction locale personnalisée pour les faits .NET, soit l’action Exécuter le moteur de règles pour les faits XML uniquement.

Prérequis

Téléchargez et installez l’Éditeur de règles Microsoft, que vous utilisez pour créer des ensembles de règles, des règles métier et des vocabulaires.

Pour créer la logique métier de votre projet de moteur de règles, consultez la documentation suivante :
- Créer des règles avec l’Éditeur de règles Microsoft
- Gestion des décisions et intégration de la logique métier avec le moteur de règles Azure Logic Apps
Pour cette version, seul Visual Studio Code prend en charge l’expérience de développement d’un projet de moteur de règles Azure Logic Apps. Pour connaître les prérequis d’utilisation de Visual Studio Code, consultez Créer un workflow d’application logique Standard pour Azure Logic Apps monolocataire en utilisant Visual Studio Code.
Pour utiliser .NET facts, le moteur de règles Azure Logic Apps utilise la fonction de code personnalisé dans Visual Studio Code. Pour configurer les prérequis d’utilisation de cette fonctionnalité, consultez Créer et exécuter du code .NET Framework à partir de workflows Standard dans Azure Logic Apps.

Avant de créer votre projet

Pour garantir la réussite de votre projet de moteur de règles, passez en revue et exécutez les tâches générales et les bonnes pratiques suivantes :

Déterminer comment les règles métier s’intègrent dans vos processus métier.
Planifier comment incorporer des règles métier dans votre application.
Identifier la logique métier que vous voulez représenter par des règles dans votre application.

Le terme « logique métier » peut faire référence à de nombreuses choses. Par exemple, la logique métier peut être « Les commandes d’achat supérieures à 500 dollars nécessitent l’approbation du responsable ».
Identifier les sources de données de vos éléments de règle. Vous pouvez éventuellement définir des vocabulaires, c’est-à-dire une nomenclature propre à un domaine qui représente des liaisons sous-jacentes.
Définissez les règles à utiliser à partir des définitions de vocabulaire ou directement des liaisons de données. À partir de ces règles, créez un ensemble de règles qui représente votre logique métier.

Exporter des règles à partir de Microsoft BizTalk Server

Pour réutiliser les règles existantes de Microsoft BizTalk Server, vous pouvez les exporter. Toutefois, les faits de base de données ne sont actuellement pas pris en charge. Avant d’exporter vos règles, supprimez-les ou refactorisez-les en d’autres types de faits en utilisant l’Éditeur de règles Microsoft BizTalk.

Dans Microsoft BizTalk Server, démarrez l’Assistant de Déploiement du moteur de règles métier.
Sur la page Bienvenue dans l’Assistant de déploiement du moteur de règles, sélectionnez Suivant.
Dans la page Tâche de déploiement, sélectionnez Exporter la stratégie/le vocabulaire dans un fichier à partir de la base de données, puis sélectionnez Suivant.
Dans la page Magasin de stratégies, dans la liste Nom du serveur SQL, sélectionnez votre serveur SQL. Dans la base de données de configuration de la liste de serveurs sélectionnée, sélectionnez BizTalkRuleEngineDb, puis sélectionnez Suivant.
Dans la page Exporter la stratégie/le vocabulaire, dans la liste Stratégie, sélectionnez la stratégie souhaitée. Pour rechercher et choisir le fichier de définition, sélectionnez Parcourir.
Ensuite, sélectionnez Suivant.
Vérifiez les informations concernant le serveur, la base de données, et la stratégie ou le vocabulaire, puis sélectionnez Suivant.
Une fois l’importation ou l’exportation terminée, sélectionnez Suivant.
Vérifiez l’état d’achèvement de l’importation ou de l’exportation, puis sélectionnez Terminer.

Créer un projet de moteur de règles Azure Logic Apps

Le modèle de projet crée un projet de fonctions et un projet d’application logique. Vous avez besoin du projet de fonctions et du code personnalisé uniquement lorsque votre système de règles inclut des faits .NET. Pour les ensembles de règles qui utilisent uniquement des faits XML, utilisez l’action intégrée Exécuter le moteur de règles dans votre flux de travail.

Dans Visual Studio Code, dans la barre d’activité, sélectionnez l’icône Azure. (Clavier : Maj+Alt+A)
Dans la fenêtre Azure qui s’ouvre, dans la barre d’outils de la section Espace de travail, à partir du menu Azure Logic Apps, sélectionnez Créer un espace de travail d’application logique.
Dans la zone Sélectionner un dossier, recherchez et sélectionnez le dossier local que vous avez créé pour votre projet.
Lorsque la zone d’invite Créer un nouvel espace de travail d’application logique s’affiche, indiquez un nom pour votre espace de travail :

Cet exemple continue avec MyLogicAppRulesWorkspace.
Lorsque la zone d’invite 'Sélectionner un modèle de projet pour l’espace de travail de votre application logique' s’affiche, sélectionnez Application logique avec un projet utilisant un moteur de règles.

Suivez les indications ci-dessous pour fournir des valeurs d'exemple :

Élément	Valeur d'exemple
Nom de fonction pour le projet de fonctions	RulesFunction
Nom de l’espace de noms pour le projet de fonctions	Contoso
Application logique :	Application logique
Modèle de workflow : - Workflow avec état - Workflow sans état	Workflow avec état
Nom du flux de travail	MyRulesWorkflow

Sélectionnez Ouvrir dans la fenêtre actuelle.

Une fois cette étape terminée, Visual Studio Code crée votre espace de travail, qui comprend par défaut un projet de fonctions et un projet de moteur de règles d’application logique, par exemple :

Nœud	Descriptif
*< nom de l’espace de travail>*	Contient à la fois votre projet de fonction et votre projet de flux de travail d’application logique.
Fonction	Contient les artéfacts de votre projet fonctionnel. Par exemple, le fichier *<function-name>.cs* est le fichier de code dans lequel vous pouvez créer votre code.
Application logique	Contient les artefacts de votre projet de moteur de règles d’application logique, y compris un workflow.

Écrivez le code de votre moteur de règles pour les faits .NET

Si votre ensemble de règles utilise uniquement des faits XML, passez cette section et utilisez l’action intégrée Exécuter le moteur de règles. Si votre ensemble de règles inclut des faits .NET, créez une fonction locale personnalisée comme décrit dans cette section.

Dans votre espace de travail, développez le nœud Fonctions , s’il n’est pas déjà développé.

Ouvrez le fichier <function-name>.cs, nommé RulesFunction.cs dans cet exemple.

Par défaut, ce fichier contient un exemple de code qui contient les éléments de code suivants, ainsi que les exemples de valeurs précédemment fournis, le cas échéant :

Nom de l’espace de noms
Nom de classe
Nom de la fonction
Paramètres de fonction
Type de retour
Type complexe

L’exemple suivant montre l’exemple de code complet pour la fonction nommée RulesFunction :

//------------------------------------------------------------
// Copyright (c) Microsoft Corporation. All rights reserved.
//------------------------------------------------------------

namespace Contoso
{
     using System;
     using System.Collections.Generic;
     using System.Threading.Tasks;
     using Microsoft.Azure.Functions.Extensions.Workflows;
     using Microsoft.Azure.WebJobs;
     using Microsoft.Azure.Workflows.RuleEngine;
     using Microsoft.Azure.Workflows.RuleEngine.Common;
     using Microsoft.Extensions.Logging;
     using System.Xml;
     using System.Text;

     /// <summary>
     /// Represents the RulesFunction flow invoked function.
     /// </summary>
     public class RulesFunction
     {
         private readonly ILogger<RulesFunction> logger;

         private FileStoreRuleExplorer ruleExplorer;

         public RulesFunction(ILoggerFactory loggerFactory)
         {
             logger = loggerFactory.CreateLogger<RulesFunction>();
             this.ruleExplorer = new FileStoreRuleExplorer(loggerFactory); 
         }

         /// <summary>
         /// Executes the logic app workflow.
         /// </summary>
         /// <param name="ruleSetName">The rule set name.</param>
         /// <param name="documentType">document type of input xml.</param>
         /// <param name="inputXml">input xml type fact</param>
         /// <param name="purchaseAmount">purchase amount, value used to create .NET fact </param>
         /// <param name="zipCode">zip code value used to create .NET fact .</param>
         [FunctionName("RulesFunction")]
         public Task<RuleExecutionResult> RunRules(
             [WorkflowActionTrigger] string ruleSetName, 
             string documentType, 
             string inputXml, 
             int purchaseAmount, 
             string zipCode)
         {
         /***** Summary of steps below *****
              * 1. Get the rule set to Execute 
              * 2. Check if the rule set was retrieved successfully
              * 3. create the rule engine object
              * 4. Create TypedXmlDocument facts for all xml document facts
              * 5. Initialize .NET facts
              * 6. Execute rule engine
              * 7. Retrieve relevant updates facts and send them back
         */

             try
             {
                 var ruleSet = this.ruleExplorer.GetRuleSet(ruleSetName);

                 // Check if ruleset exists
                 if(ruleSet == null)
                 {
                     // Log an error in finding the rule set
                     this.logger.LogCritical($"RuleSet instance for '{ruleSetName}' was not found(null)");
                     throw new Exception($"RuleSet instance for '{ruleSetName}' was not found.");
                 }             

                 // Create rule engine instance
                 var ruleEngine = new RuleEngine(ruleSet: ruleSet);

                 // Create a typedXml Fact(s) from input xml(s)
                 XmlDocument doc = new XmlDocument();
                 doc.LoadXml(inputXml);
                 var typedXmlDocument = new TypedXmlDocument(documentType, doc);

                 // Initialize .NET facts
                 var currentPurchase = new ContosoNamespace.ContosoPurchase(purchaseAmount, zipCode);

                 // Provide facts to rule engine and run it
                 ruleEngine.Execute(new object[] { typedXmlDocument, currentPurchase });

                 // Send the relevant results(facts) back
                 var updatedDoc = typedXmlDocument.Document as XmlDocument;
                 var ruleExectionOutput = new RuleExecutionResult()
                 {
                     XmlDoc = updatedDoc.OuterXml,
                     PurchaseAmountPostTax = currentPurchase.PurchaseAmount + currentPurchase.GetSalesTax()
                 };

                 return Task.FromResult(ruleExectionOutput);
             }
             catch(RuleEngineException ruleEngineException)
             {
                 // Log any rule engine exceptions
                 this.logger.LogCritical(ruleEngineException.ToString());
                 throw;
             }
             catch(XmlException xmlException)
             {
                 // Log any xml exceptions
                 this.logger.LogCritical("Encountered exception while handling xml. " + xmlException.ToString());
                 throw;
             }
             catch(Exception ex)
             {
                 // Log any other exceptions
                 this.logger.LogCritical(ex.ToString());
                 throw;
             }
         }

         /// <summary>
         /// Results of the rule execution
         /// </summary>
         public class RuleExecutionResult
         {
             /// <summary>
             /// rules updated xml document
             /// </summary>
             public string XmlDoc { get; set;}

             /// <summary>
             /// Purchase amount post tax
             /// </summary>
             public int PurchaseAmountPostTax { get; set;}
         }
     }
}

La définition de fonction de RulesFunction comprend une méthode RunRules par défaut que vous pouvez utiliser pour commencer. Cet exemple de méthode RunRules montre comment passer des paramètres au moteur de règles Azure Logic Apps. Dans cet exemple, la méthode passe le nom de l’ensemble de règles, le type de document d’entrée, un fait XML et d’autres valeurs pour traitement ultérieur.

Le fichier <function-name>.cs inclut également l’interface ILogger, qui fournit la prise en charge de la journalisation des événements dans une ressource Application Insights. Vous pouvez envoyer des informations de suivi à Application Insights et stocker ces informations en même temps que les informations de trace de vos flux de travail. Le fichier <function-name>.cs inclut également l’objet FileStoreRuleExplorer qui accède au jeu de règles. Comme vous pouvez l’observer, le constructeur de FileStoreRuleExplorer utilise loggerFactory pour envoyer également des informations de télémétrie à Application Insights.

private readonly ILogger<RulesFunction> logger;

private FileStoreRuleExplorer ruleExplorer;

public RulesFunction(ILoggerFactory loggerFactory)
     {
         logger = loggerFactory.CreateLogger<RulesFunction>();
         this.ruleExplorer = new FileStoreRuleExplorer(loggerFactory); 
     }

    <...>

Le moteur de règles Azure Logic Apps fonctionne comme décrit dans les étapes suivantes :

Le moteur utilise l’objet FileStoreRuleExplorer pour accéder à l’ensemble de règles. Le fichier d’ensemble de règles est stocké dans le répertoire Règles de votre application logique Standard.

Pour cet exemple, le fichier d’ensemble de règles est appelé SampleRuleSet.xml, qui a été créé avec l’Éditeur de règles Microsoft ou exporté avec Microsoft BizTalk Server.

var ruleSet = this.ruleExplorer.GetRuleSet(ruleSetName);

// Check if ruleset exists
if(ruleSet == null)
{
// Log an error in finding the rule set
  this.logger.LogCritical($"RuleSet instance for '{ruleSetName}' was not found(null)");
  throw new Exception($"RuleSet instance for '{ruleSetName}' was not found.");
}

Important

Les ensembles de règles contiennent des références à leurs faits. L’Éditeur de règles Microsoft recherche les assemblies des faits pour valider l’ensemble de règles à des fins de modification. Pour ouvrir des ensembles de règles comme SampleRuleSet.xml dans l’Éditeur de règles Microsoft, il est nécessaire de les placer avec les assemblies de faits .NET correspondantes. Sinon, vous obtenez une exception.

Le moteur utilise l’objet ruleSet pour créer une instance de l’objet RuleEngine.
L’objet RuleEngine reçoit les faits de la règle en utilisant la méthode Execute.

Dans cet exemple, la méthode Execute reçoit deux faits : un fait XML nommé typedXmlDocument et un fait .NET nommé currentPurchase.

Une fois le moteur exécuté, les valeurs des faits sont remplacées par celles résultant de l’exécution du moteur :

// Create rule engine instance
var ruleEngine = new RuleEngine(ruleSet: ruleSet);
// Create a typedXml Fact(s) from input xml(s)
XmlDocument doc = new XmlDocument();
doc.LoadXml(inputXml);
var typedXmlDocument = new TypedXmlDocument(documentType, doc);
// Initialize .NET facts
var currentPurchase = new ContosoNamespace.ContosoPurchase(purchaseAmount, zipCode);
// Provide facts to rule engine and run it
ruleEngine.Execute(new object[] { typedXmlDocument, currentPurchase });
// Send the relevant results(facts) back
   var updatedDoc = typedXmlDocument.Document as XmlDocument;

Le moteur utilise la classe personnalisée RuleExecutionResult pour renvoyer les valeurs à la méthode RunRules :

var ruleExectionOutput = new RuleExecutionResult()
             {
                 XmlDoc = updatedDoc.OuterXml,
                 PurchaseAmountPostTax = currentPurchase.PurchaseAmount + currentPurchase.GetSalesTax()
             };

             return Task.FromResult(ruleExectionOutput);

Remplacez l’exemple de code de fonction par votre propre et modifiez la méthode RunRules par défaut pour vos propres scénarios.

Cet exemple continue d’utiliser l’exemple de code sans aucun changement.

Compilez et générez votre code pour les notions de base de .NET

Si votre ensemble de règles utilise uniquement des faits XML et que vous prévoyez d’utiliser l’action intégrée Exécuter le moteur de règles , passez cette section. Si votre système de règles inclut des faits .NET, une fois que vous avez fini d’écrire votre code, compilez pour vous assurer qu’aucune erreur de compilation n’existe. Votre projet de fonction inclut automatiquement les tâches de build, qui compilent puis ajoutent toutes les bibliothèques de code personnalisées, y compris vos assemblies facts .NET, dans le dossier lib\custom de votre projet Logic App où les workflows recherchent des fonctions personnalisées à exécuter. Ces tâches placent les assemblys dans le dossier lib\custom\net472.

Dans Visual Studio Code, sélectionnez le menu Terminal, puis sélectionnez Nouveau terminal.
Dans la liste des répertoires de travail qui s’affiche, sélectionnez Fonctions comme répertoire de travail actuel pour le nouveau terminal.

Visual Studio Code ouvre une fenêtre de terminal avec une invite de commandes.
Dans la fenêtre Terminal, à l’invite de commandes, entrez dotnet restore .\RulesFunction.csproj.
Quand l’invite de commandes s’affiche de nouveau, entrez dotnet build .\RulesFunction.csproj.

Si votre build réussit, la fenêtre Terminal signale que le build a réussi.
Vérifiez que les éléments suivants existent dans votre projet d’application logique :
- Dans votre espace de travail, développez les dossiers suivants : LogicApp>lib\custom>net472. Vérifiez que le sous-dossier nommé net472 contient les multiples assemblys nécessaires pour exécuter votre code, y compris un fichier nommé <function-name>.dll.
- Dans votre espace de travail, développez les dossiers suivants : LogicApp>lib\custom><function-name>. Vérifiez que le sous-dossier nommé <function-name> contient un fichier function.json, qui inclut les métadonnées relatives au code de fonction que vous avez écrit. Le concepteur de flux de travail utilise ce fichier pour déterminer les entrées et sorties nécessaires lors de l’appel de votre code.
L’exemple suivant montre des exemples d’assemblys et d’autres fichiers générés dans le projet d’application logique :

Appeler vos règles à partir d’un workflow

Appelez des données .NET avec des fonctions personnalisées locales

Pour les ensembles de règles incluant des faits .NET, utilisez une fonction personnalisée locale. Après avoir confirmé que votre code est compilé et que votre projet de moteur de règles d’application logique a les fichiers nécessaires pour l’exécution de votre code, ouvrez le workflow par défaut inclus dans votre projet d’application logique.

Dans votre espace de travail, sous LogicApp, développez le nœud <workflow-name>, ouvrez le menu contextuel pour workflow.json, puis sélectionnez Ouvrir Designer.

Dans le concepteur de flux de travail qui s’ouvre, le workflow par défaut, inclus dans votre projet d’application logique, s’affiche avec le déclencheur et les actions suivants :
- Déclencheur de requête intégré nommé Lorsqu’une requête HTTP est reçue.
- L’action intégrée nommée Appeler une fonction de règles locale dans cette application logique.
- L’Action de réponse intégrée nommée Réponse, que vous utilisez pour répondre à l’appelant uniquement quand vous utilisez le Déclencheur de demande.
Sélectionnez l’action nommée Appeler une fonction de règles locale dans cette application logique.

Le volet d’informations de l’action s’ouvre à droite.
Vérifiez que la valeur du paramètre Nom de la fonction est définie sur la fonction de règles que vous souhaitez exécuter. Passez en revue ou modifiez toutes les autres valeurs de paramètre que votre fonction utilise.

Appelez les faits XML en utilisant l’action Exécuter le moteur de règles

Pour les ensembles de règles qui utilisent uniquement des faits XML, utilisez l’action intégrée Exécuter le moteur de règles . Vous n’êtes pas obligé d’écrire, de compiler ou d’appeler une fonction locale personnalisée.

Important

L’action Exécuter le moteur de règles est en aperçu et ne prend en charge que les faits XML. Pour utiliser .NET facts, appelez une fonction personnalisée locale.

Dans votre espace de travail, sous LogicApp, développez le nœud <workflow-name>, ouvrez le menu contextuel pour workflow.json, puis sélectionnez Ouvrir Designer.
Sur le concepteur de workflow, sous le déclencheur ou l’action où vous souhaitez exécuter votre ensemble de règles, ajoutez l’action nommée Execute Rules Engine en suivant les étapes générales pour ajouter une action à votre workflow.
Dans le volet d’informations d’action, depuis la liste des Ensembles de règles , sélectionnez le jeu de règles que vous souhaitez exécuter. Cet exemple sélectionne Validation.
Ouvrez la liste des paramètres avancés .

Pour chaque fait XML que l’ensemble de règles sélectionné attend, la liste contient un paramètre commençant par le préfixe Fact :. Cet exemple sélectionne Information : Backend.
Sélectionnez chaque paramètre de fait que vous souhaitez fournir.
Pour chaque paramètre de fait, fournissez le document XML correspondant.

Vous pouvez entrer XML ou sélectionner la sortie XML d’une opération de workflow antérieure. Cet exemple utilise la sortie Body XML d’un Compose XML précédent avec action de schéma.

Lorsque l’action s’exécute, le moteur de règles applique l’ensemble de règles sélectionné aux faits XML. Vous pouvez utiliser la sortie d’action dans les opérations de workflow suivantes. Dans cet exemple, le workflow utilise Parse XML avec schéma pour traiter le XML résultant.

Déboguer votre code et votre workflow

Les étapes suivantes s’appliquent lorsque vous utilisez une fonction personnalisée locale pour des ensembles de règles incluant des faits .NET. Pour un ensemble de règles uniquement XML utilisant l’action intégrée Exécuter le moteur de règles , débogez le workflow et examinez les entrées et sorties d’actions dans l’historique d’exécution du workflow.

Répétez les étapes suivantes pour démarrer l’émulateur de stockage Azurite trois fois : une fois chacune pour les services de stockage Azure suivants :
- Service Blob Azure
- Service file d’attente Azure
- Service de Table Azure
1. Dans Visual Studio Code, dans le menu Affichage, sélectionnez Palette de commandes.
2. À l’invite qui s’affiche, recherchez et sélectionnez Azurite : Démarrer le service Blob.
3. Dans la liste des répertoires de travail qui s’affiche, sélectionnez LogicApp.
4. Répétez ces étapes pour Azurite : Démarrer le service file d’attente et Azurite : Démarrer le service table.
Vous réussissez lorsque la barre des tâches de Visual Studio Code en bas de l’écran montre les trois services de stockage en cours d’exécution, par exemple :
Dans la barre d’activités de Visual Studio Code, sélectionnez Exécuter et déboguer. (Clavier : Ctrl+Maj+D)
Dans la liste Exécuter et déboguer, sélectionnez Attacher à une application logique (LogicApp) si ce n’est pas déjà sélectionné, puis sélectionnez Lire (flèche verte).

La fenêtre Terminal s’ouvre et affiche le processus de débogage démarré. La fenêtre Console de débogage s’affiche et affiche les états de débogage. En bas de Visual Studio Code, la barre des tâches devient orange, ce qui indique que le débogueur .NET est chargé.
Pour définir des points d’arrêt, dans votre définition de fonction (<function-name>.cs) ou votre définition de workflow (workflow.json), recherchez le numéro de ligne où vous voulez le point d’arrêt, puis sélectionnez la colonne à gauche, par exemple :
Pour exécuter manuellement le déclencheur de demande dans votre flux de travail, ouvrez la page Vue d’ensemble du flux de travail.
1. Dans votre projet d’application logique, ouvrez le menu contextuel du fichier workflow.json, puis sélectionnez Vue d’ensemble.
  
  Dans la page Vue d’ensemble du flux de travail, le bouton Exécuter le déclencheur est disponible lorsque vous souhaitez démarrer manuellement le flux de travail. Sous Propriétés du workflow, la valeur URL de rappel correspond à l’URL d’un point de terminaison pouvant être appelé créé par le Déclencheur de demande dans votre workflow. Vous pouvez envoyer des requêtes à cette URL pour déclencher votre flux de travail à partir d’autres applications, y compris d’autres workflows d’application logique.
Dans la barre d’outils du volet Vue d’ensemble, sélectionnez Exécuter le déclencheur.

Une fois que votre workflow a commencé à s’exécuter, le débogueur active votre premier point d’arrêt.
Dans le menu Exécuter ou la barre d’outils du débogueur, sélectionnez une action de débogage.

Une fois l’exécution du flux de travail terminée, la page Vue d’ensemble affiche l’exécution terminée et les détails de base sur cette exécution.
Pour passer en revue plus d’informations sur l’exécution du flux de travail, sélectionnez l’exécution terminée. Ou, dans la liste en regard de la colonne Durée, sélectionnez Afficher l’exécution.
Pour déployer vos applications logiques avec le projet Moteur de règles sur Azure Logic Apps, suivez les étapes de préparation au déploiement.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-09-16