Accueil > Logic App Standard : appeler une Azure Function depuis un mapping XSLT
Valentin Houser
28 février 2023
Read this post in English

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

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 » :

Compatibilité avec le framework .NET 4.7.2

 

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

lancer la console Debug -> CMD

 

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

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

 

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

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

 

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

Si le dossier lib n'existe pas

 

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

Si le dossier « net472 » n’existe pas

 

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 :

drag’n’drop

 

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 ».

Assemblies DLL preview

 

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

 

drag and drop DLL Assembly

 

La map XSLT

 

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

Compilation helper et sa DLL dans une map XSLT

 

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

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.

la base CosmosDb

 

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

Exemple d’une row :

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.

L’Azure Function

 

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.

la LogicApp Standard

 

Après exécution du workflow :

Designer :

Après exécution du workflow

 

Résultat de la map XSL :

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 !

Nos autres articles
Commentaires
Laisser un commentaire

Restez au courant des dernières actualités !
Le meilleur de l’actualité sur le Cloud, le DevOps, l’IT directement dans votre boîte mail.