Lorsqu’on utilise des Logic Apps Standard dans Azure, il arrive parfois que les actions disponibles ne suffisent pas pour gérer ou transformer les données d’un workflow. Le traitement peut nécessiter une logique métier plus fine ou des transformations spécifiques.
Dans ces cas, il devient intéressant de pouvoir intégrer du code .NET directement dans un workflow Logic App.
Historiquement, les solutions consistaient à faire des appels HTTP vers une Function App contenant la logique personnalisée, ou à développer un Custom Connector pour exécuter du code. Ces approches fonctionnent, mais elles nécessitent un développement supplémentaire et engendrent des coûts additionnels.
Aujourd’hui, il est possible d’intégrer du code directement via une action dédiée qui permet de référencer des fonctions personnalisées déjà déployées.
Le développement de code intégré dans une Logic App Standard est actuellement possible uniquement depuis Visual Studio Code.
Avec la dernière version de Logic Apps (Standard), le modèle de projet fournit une structure prête à l’emploi pour démarrer rapidement.
L’espace de travail doit contenir deux projets :
Dans le projet de code, vous pouvez développer vos fonctions à utiliser dans la Logic App. Vous pouvez également inclure des classes utilitaires, des helpers ou tout autre code nécessaire.
Les fonctions utilisent un déclencheur spécifique : WorkflowActionTrigger.
À l’intérieur de la fonction, vous pouvez effectuer des transformations, appliquer une logique métier personnalisée, valider et parser des données, voire appeler des composants externes pour récupérer des informations supplémentaires.
Il est aussi possible de tester et déboguer le code directement depuis Visual Studio Code, sans avoir besoin de déployer sur Azure.
Cela implique d’abord de compiler et construire le projet.
Depuis l’explorateur de fichiers, un simple clic droit permet de lancer la commande Build Project. Cela génère automatiquement certains fichiers dans le projet Logic App : les .dll nécessaires à l’exécution et un fichier function.json.
Ensuite, dans le workflow designer, vous pouvez utiliser l’action Call a local function in this logic app, entrer le nom de la fonction et ses paramètres d’entrée.
Le reste du workflow peut être ajusté avec d’autres actions, ou simplifié pour tester uniquement le code.
Pour exécuter le workflow, il faut activer l’émulateur Azurite (blobs, queues, tables).
Une fois activé, vous pouvez attacher le débogueur aux deux projets via l’option Run/debug logic app with local function.
Depuis la vue d’ensemble du workflow, vous pouvez ensuite déclencher l’exécution.
Si vous utilisez un déclencheur HTTP, vous pouvez aussi appeler directement l’URL générée via un outil comme Thunder Client, Bruno ou Postman.
Pour déployer le code intégré, deux options sont possibles :
Dans les deux cas, il faut s’assurer que le code est bien compilé et que les assemblies (.dll) sont placées dans le bon dossier.
Pour un déploiement direct, il suffit de faire un clic droit sur le projet Logic App et de sélectionner Deploy to Logic App.
Attention : il faut sélectionner le dossier du projet Logic App (celui contenant à la fois les assemblies et le workflow).
En dehors de ce point, le déploiement est identique à celui d’une Logic App classique.
Comme mentionné précédemment, le développement de code intégré n’est possible que via l’extension Logic Apps Standard dans Visual Studio Code sous Windows.
Cependant, après déploiement depuis VS Code, il reste possible d’ajouter l’action de workflow appelant la fonction depuis le portail Azure.
Bien que ces fonctions puissent exécuter des traitements complexes — limités uniquement par les capacités de .NET — elles présentent certaines restrictions :
L’utilisation de code intégré dans les Logic Apps Standard est une excellente solution pour implémenter des logiques ou transformations complexes au sein même du framework Logic App.
Elle permet de bénéficier de toute la puissance de .NET, tout en restant dans un environnement d’intégration maîtrisé.
Bien que cela nécessite Visual Studio Code, cette approche offre la possibilité de tester et déboguer localement, sans déploiement préalable — un atout considérable pour les développeurs.
