Bien qu’il soit possible d’intégrer du code .NET dans un workflow Logic App Standard via Visual Studio Code, une autre option consiste à utiliser des scripts C#. Cette approche permet de tirer parti d’une action intégrée qui autorise le développement et l’exécution de code directement dans le workflow. Le code inline représente une amélioration par rapport aux solutions précédentes, car il permet de développer entièrement depuis le portail Azure, sans nécessiter l’utilisation d’un IDE externe.
L’implémentation de code inline dans un workflow repose sur l’action « Execute C# script code ». Cette action contient déjà une structure de base lorsqu’elle est ajoutée au workflow. Cette structure inclut des exemples montrant comment accéder aux sorties du trigger ou des actions précédentes, ainsi que comment envoyer des logs vers Application Insights. La méthode Run correspond à la méthode appelée lors de l’exécution du script.
Les scripts C# sont exécutés in-process, sans espaces de noms (namespace) ni classes englobantes. Ils sont compilés lorsqu’une instance est initialisée. Dans le contexte d’un workflow, cela signifie au moment où celui-ci est déclenché. Plusieurs assemblies sont déjà fournies par l’environnement d’hébergement Azure. D’autres peuvent être référencées au début du script. Il est également possible d’ajouter des packages NuGet à l’aide d’un fichier function.proj, placé à la racine du dossier du workflow. Enfin, d’autres fichiers de script présents au même emplacement peuvent également être référencés.
Comme dans du code .NET classique, il est possible d’envoyer des traces directement dans Application Insights à l’aide de la classe ILogger. Ces traces peuvent servir à journaliser des erreurs, des étapes intermédiaires de traitement ou toute autre information utile pour le débogage lors de l’exécution du script. De la même manière, il est possible de créer des métriques personnalisées via ce logger.
L’action peut également accéder aux sorties du déclencheur ou des actions précédentes en les référant par leur nom. Toutes les données renvoyées par la fonction deviennent ensuite accessibles aux actions qui suivent. La sortie est stockée dans la propriété body de l’action, laquelle peut être utilisée au travers des expressions de workflow.
Pour déployer via un pipeline CI/CD classique ou depuis un IDE, il est nécessaire de disposer du fichier de script lui-même. En effet, le script n’est pas intégré directement dans la définition du workflow. Il est simplement référencé comme un fichier externe. Lorsqu’il est développé depuis le Designer, le script est automatiquement enregistré dans le dossier racine du workflow.
Ce fichier est accessible via la console Kudu+ disponible dans les outils de développement avancés. Depuis la console de débogage, il faut naviguer vers le chemin site/wwwroot, puis vers le dossier du workflow afin de retrouver à la fois le fichier de script et le fichier du workflow. Une fois téléchargé, le script peut être déployé avec le workflow ainsi qu’avec les éventuels scripts externes référencés, que ce soit directement par le workflow ou par le script lui-même.
L’un des principaux avantages du code inline dans une Logic App Standard est que le développement peut être réalisé directement depuis le portail Azure, depuis un IDE, ou en combinant les deux approches. Cette solution offre davantage de flexibilité dans le développement des workflows grâce à l’utilisation de scripts C#. De plus, elle évite la nécessité de déployer un App Service supplémentaire.
Cependant, cette approche présente également certaines limitations liées à l’utilisation de scripts. Tout d’abord, aucune vérification des erreurs n’est effectuée lors du développement dans le portail. Les erreurs ne sont détectées qu’au moment où le workflow est déclenché et où le script est exécuté. Cela est dû au mode et au moment de compilation du script.
Par ailleurs, l’ajout de packages NuGet ou de scripts externes nécessite des manipulations via la console Kudu ou lors du déploiement. Le Designer ne permet pas d’ajouter directement un fichier function.proj ni d’autres scripts externes.
Enfin, les scripts restent locaux à chaque workflow. Cela signifie que lorsqu’un même script doit être utilisé par plusieurs workflows, il doit soit être placé dans un dossier partagé, soit être copié dans le dossier racine de chacun des workflows concernés.
L’action de code inline apporte une flexibilité supplémentaire aux Logic Apps Standard. Cela permet d’implémenter des traitements ou des transformations de données plus complexes. Elle permet un développement directement depuis le portail Azure tout en restant compatible avec les approches de déploiement CI/CD. Enfin, l’utilisation de scripts C# offre une expérience de développement légèrement simplifiée par rapport à un projet .NET classique.
