Logic App Standard : appeler une Azure Function depuis un mapping XSLT

Aujourd’hui, dans le cadre d’un projet d’intégration, nous pouvons énumérer de nombreux scénarios nécessitant conversion, transcodification ou encore formatage ou calcul spécifique. Dans ce cas particulier, il se peut que ce genre de calcul s’effectue via du code encapsulé dans une map XSL.

Lorsque l’on opte pour ce type traitement, nous avons l’habitude de mutualiser son process pour le réutiliser. Pour ce faire, nous pouvons développer du code (par exemple une classe C# « Helper ») qui contient l’ensemble des calculs utilisés et auquel on fait référence au besoin. Cela évite de « réinventer la roue » à chaque fois.

Avec l’avènement des différents composants Azure et du Cloud en général, il est facile d’imaginer créer plusieurs Azure Functions pour des traitements déterminés et y faire ensuite appel chaque fois que cela est nécessaire. Dès lors, plus besoin d’avoir de classe C# à maintenir et à redéployer chaque fois qu’une nouvelle méthode est trouvée ou lorsqu’une correction de bug est effectuée. Tout est stocké au sein d’une même unité, et chaque modification une fois terminée est disponible très rapidement.

C’est dans cette optique que nous avons essayé de développer un moyen de pouvoir utiliser ce genre de structure afin de rendre les choses plus modulaires et plus facilement maintenables, en bénéficiant des avantages du Cloud sans les inconvénients du « On-premise ».

Dans cet article, nous allons faire la démonstration d’un appel d’une Azure Function depuis une map XSLT dans une Logic App Standard.

Pour illustrer notre propos, prenons l’exemple d’un développement BizTalk. Souvent, nous sommes confrontés à des calculs particuliers qui sont très compliqués, voire impossibles à effectuer en XSL. Deux choix s’offrent alors à nous : soit on écrit du code C# « inline » directement dans une map XSL, soit on opte pour le développement d’une classe « Helper » à laquelle nous allons faire référence.

Prenons ce dernier cas de figure précis. Dès le départ, nous sommes confrontés au problème suivant : la Logic App Standard se repose sur la dernière version stable du .NET Core. Or, le .NET Core est compatible avec les maps XSL mais pas avec le code encapsuler : il est donc impossible d’exécuter du code (quelle que soit la manière) dans une map XSL. De plus, pour pouvoir utiliser une DLL (Dynamic Link Library) au sein d’une map XSL, il est nécessaire que celle-ci soit GACer  (le GAC, « Global Assembly Cache », stocke les assemblys spécialement destinés à être partagés entre plusieurs applications sur l’ordinateur) pour pouvoir y faire référence.

Néanmoins, il existe une solution pour pouvoir exécuter du code : la méthode développée ci-dessous expose la marche à suivre.

Compatibilité avec le framework .NET 4.7.2

Premièrement, il est nécessaire de faire appel au framework .NET pour pouvoir exécuter du code C#. Pour rendre possible l’utilisation du framework dans la Logic App Standard, il suffit d’ajouter la clé de configuration comme ci-dessous. Elle permet de se reposer sur la version 4.7.2 uniquement. C’est une des limitations à laquelle nous sommes confrontés aujourd’hui.

Il faut donc nécessairement ajouter une clé dans la configuration de la Logic App Standard.

Pour cela, il suffit d’aller dans l’option « Configuration » :

Puis d’ajouter la clé comme suit :

C# : une DLL pour un appel générique

Après avoir développé une méthode C# « générique » permettant l’appel d’une Azure Function, nous avons récupéré et inclus la DLL  dans la Logic App Standard. Les lignes suivantes détaillent la marche à suivre :

Le code du helper

Ci-dessous le code du helper utilisé dans cet exercice :

Dans notre exemple, la méthode permet simplement d’appeler une Azure Function avec, en paramètres, son url et les paramètres nécessaires à son fonctionnement.

Notez que les paramètres de l’Azure Function vont être transmis dans le body en JSON.

Une fois le projet compilé, nous pouvons récupérer la DLL et la placer dans le dossier « site/wwwroot/lib/custom/net472 ».

Pour ce faire, il suffit d’utiliser l’utilitaire KUDU comme suit :

Etape 1 : lancer l’utilitaire KUDU

Etape 2 : lancer la console Debug -> CMD

Etape 3 : naviguer dans les dossiers et copier la DLL au bon endroit

Si le dossier « lib » n’existe pas, créez-le.

Si le dossier « custom » n’existe pas, créez-le.

Si le dossier « net472 » n’existe pas, créez-le.

Ensuite, il ne vous reste plus qu’à « drag’n’drop » votre DLL dans ce dossier comme ci-après :

Etape 4 : fonctionnalité en Preview, upload des DLL en utilisant le menu

A noter : depuis peu, une nouvelle façon d’uploader les DLLs à utiliser est disponible en preview.

Il suffit de cliquer sur « Assemblies ».

Puis de cliquer sur Add et de “drag’n’drop” la DLL.

La map XSLT

Nous avons ensuite compilé ce helper et utilisé sa DLL dans une map XSLT :

Pour rappel, les maps se stockent dans l’option « Maps » de la LogicApp.

Contexte et résultats

Contexte : la base CosmosDb

Pour les besoins de l’exercice, nous avons créé une base CosmosDB comportant quatre documents.

Ces documents sont des « Company » composées des attributs suivants : « id », « partitionKey », « name », « address ».

Exemple d’une row :

Contexte : L’Azure Function

Nous avons développé une Azure Function qui essaie d’obtenir la valeur de l’attribut « name » d’une « Company » grâce au couple « id » / « partitionKey » qu’on lui fournit.

Résultat : la LogicApp Standard

Nous avons développé un rapide workflow pour tester toute la chaine.

Elle se compose d’un http trigger puis d’un mapping.

Après exécution du workflow :

Designer :

Résultat de la map XSL :

Comme vous pouvez le voir, l’exécution de l’Azure Function s’est bien déroulée et nous avons bien obtenu la valeur attendue suivant les critères donnés.

Conclusion sur l’appel d’une Azure Function depuis une map XSLT.

Nous avons réussi à faire appel à une Azure Function permettant une transcodification au sein de notre map XSLT.

Bien entendu, il est possible de décliner ce type de process en multipliant le nombre d’Azure Functions ce qui permet une plus grande flexibilité et une maintenabilité plus aisée.

Plusieurs nouvelles fonctionnalités doivent voir le jour et devenir disponibles dans LogicApp Standard. En voici quelques exemples :

• Le XML extension directement dans le designer de la LogicApp
• Un « mapper » (ressemblant à celui de BizTalk) accessible depuis le designer de la LogicApp

Ces deux exemples permettront de faciliter la migration des développement BizTalk depuis du On-Premise vers du Cloud Azure.

Nous vous en parlerons plus tard dans un prochain  article sur ce blog.

Vous souhaitez en savoir plus ou être accompagnés dans vos projets autour du Cloud Azure ? Contactez-nous !