Créer un projet de moteur de règles Azure Logic Apps avec Visual Studio Code (préversion)

Article
01/27/2025

S’applique à : Azure Logic Apps (Standard)

Important

Cette fonctionnalité est en préversion et est soumise aux conditions d’utilisation supplémentaires des préversions de Microsoft Azure.

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.

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

Prérequis et configuration pour la création de votre projet de moteur de règles Azure Logic Apps, notamment la création des règles métier de votre projet avec l’Éditeur de règles Microsoft.
Exportez des règles existantes à partir de Microsoft BizTalk Server, le cas échéant.
Créez un projet d’applications logiques Standard pour le moteur de règles Azure Logic Apps avec Visual Studio Code.

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.
Le moteur de règles Azure Logic Apps utilise la fonctionnalité de fonction de code personnalisée 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 Déploiement du moteur de règles métier.
Dans la page Bienvenue dans l'Assistant 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

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.
Quand la zone d’invite Sélectionner un modèle de projet pour votre espace de travail d’application logique s’affiche, sélectionnez Application logique avec un projet de moteur de règles (préversion).

Suivez les invites suivantes pour fournir les valeurs d’exemple suivantes :

Article	Valeur d'exemple
Nom de fonction pour le projet de fonctions	RulesFunction
Nom de l’espace de noms pour le projet de fonctions	Contoso.Enterprise
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	Description
*<workspace-name>*	Contient à la fois votre projet de fonction et votre projet de flux de travail d’application logique.
Fonction	Contient les artefacts de votre projet de fonction. 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.

Écrire le code de votre moteur de règles

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.Enterprise
{
    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.Extensions.Logging;
    using System.Xml;

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

        public RulesFunction(ILoggerFactory loggerFactory)
        {
            logger = loggerFactory.CreateLogger<RulesFunction>();
        }

        /// <summary>
        /// Execute the logic app workflow.
        /// </summary>
        /// <param name="ruleSetName">The ruleset name.</param>
        /// <param name="documentType">The document type for the input XML.</param>
        /// <param name="inputXml">The input XML type fact.</param>
        /// <param name="purchaseAmount">The purchase amount value used to create a .NET fact.</param>
        /// <param name="zipCode">The zip code value used to create a .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 ruleset to execute.
            * 2. Check if the ruleset was successfully retrieved.
            * 3. Create the rules engine object.
            * 4. Create TypedXmlDocument facts for all XML document facts.
            * 5. Initialize .NET facts.
            * 6. Execute rules engine.
            * 7. Retrieve relevant updates facts and send them back.
            */

            try
            {
                // Get the ruleset based on the ruleset name.
                 var ruleExplorer = new FileStoreRuleExplorer();
                 var ruleSet = ruleExplorer.GetRuleSet(ruleSetName);

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

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

                // Create one or more typedXmlDocument facts from one or more input XML documents.
                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 and run the rules engine.
                ruleEngine.Execute(new object[] { typedXmlDocument, currentPurchase });

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

                return Task.FromResult(ruleExecutionOutput);
            }
            catch(RuleEngineException ruleEngineException)
            {
                // Log any rules engine exceptions.
                this.logger.LogCritical(ruleEngineException.ToString());
                throw;
            }
        }

        /// <summary>
        /// Results from rules execution
        /// </summary>
        public class RuleExecutionResult
        {
            /// <summary>
            /// Rules updated XML document
            /// </summary>
            public string XmlDoc { get; set;}

            /// <summary>
            /// Purchase amount after 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 aux côtés des informations de trace de vos flux de travail, par exemple :

private readonly ILogger<RulesFunction> logger;

    public RulesFunction(ILoggerFactory loggerFactory)
    {
        logger = loggerFactory.CreateLogger<RulesFunction>();
    }
    <...>

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 ruleExplorer = new FileStoreRuleExplorer();
var ruleSet = ruleExplorer.GetRuleSet(ruleSetName);

// Check if the ruleset exists.
if(ruleSet == null)
{
    // Log an error if the ruleset isn't found.
    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 assemblys des faits pour valider l’ensemble de règles à modifier. Pour ouvrir des ensembles de règles comme SampleRuleSet.xml dans l’Éditeur de règles Microsoft, vous devez les placer avec les assemblys de faits .NET correspondants. 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 les valeurs résultant de l’exécution du moteur :

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

// Create one or more typedXml facts from one or more input XML documents.
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 and run the rules engine.
ruleEngine.Execute(new object[] { typedXmlDocument, currentPurchase });

// Send back the relevant results (facts).
var updatedDoc = typedXmlDocument.Document as XmlDocument;

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

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

return Task.FromResult(ruleExecutionOutput);

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.

Compiler et générer votre code

Une fois que vous avez terminé d’écrire votre code, compilez pour vous assurer qu’aucune erreur de build n’existe. Votre projet de fonction inclut automatiquement des tâches de génération, qui compilent puis ajoutent toutes vos bibliothèques de code personnalisées, y compris vos assemblys de faits .NET, au dossier lib\custom de votre projet d’application logique où les workflows recherchent les 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 la génération 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

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 :
- Le Déclencheur de demande intégré nommé Quand 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.

Déboguer votre code et votre 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
- Azure Queue Service
- Service 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é.
Dans la liste Exécuter et déboguer, sélectionnez Attacher à des fonctions .NET (Fonctions), puis Sélectionnez Lire (flèche verte).
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.