Power Platform et l’approche du développement de fusion

Qu’est-ce que le développement de fusion ? 

L’approche du développement de fusion consiste à associer le travail d’un Citizen Developer avec celui d’un développeur professionnel mais aussi d’utilisateurs finaux, afin de créer des équipes de fusion numérique et ainsi de mener à bien les projets à réaliser sur Power Apps dans Power Platform.  

Power Platform est une solution conçue par Microsoft pour permettre de centraliser les données d’une entreprise dans un environnement afin d’effectuer trois actions distinctes :  

• Manipuler les données avec Power Apps ; 

• Automatiser avec Power Automate ; 

• Et analyser avec Power BI. 

L’approche du développement de fusion s’applique généralement avec Power Apps, mais aussi avec Power Automate et Power BI. 

Dans cet article, nous allons découvrir plusieurs cas qui prouvent la nécessité de constituer une équipe de fusion numérique dans des projets à réaliser sur Power Platform. 

Cycle de travail d’une équipe de fusion numérique 

Dans une équipe de fusion numérique, chacun à son rôle à jouer durant la réalisation d’un projet dans Power Platform. 

Dans un premier temps, le Citizen Developer réalise une application sur Power Apps selon des besoins métiers spécifiques.  

Si les tâches s’avèrent trop compliquées, il pourra faire appel à un développeur professionnel qui s’occupera alors de ces tâches plus complexes. 

 

Figure 1 : Cycle de travail d'une équipe de fusion numérique

Par exemple, le développeur professionnel se chargera de la création d’API Web et de leur implémentation dans Power Platform avec des connecteurs personnalisés qui récupéreront les données métier. Il sera également amené à mettre en place une approche plus algorithmique dans la création de flux automatisés. Et avec ses connaissances en programmation, il pourra intégrer des scripts Python dans des rapport Power BI. 

Les utilisateurs finaux eux, auront la responsabilité de tester l’application et de remonter des feedbacks directement au Citizen Developer. 

 

Création des connecteurs personnalisés 

Il existe, dans Power Platform, des composants appelés connecteurs et permettant de centraliser les données métiers dans un environnement. Actuellement, il en existe plus de 300, mais il est possible que certains ne répondent pas aux besoins métiers du Citizen Developer. 

La tâche du développeur professionnel sera donc de créer un connecteur personnalisé de différentes façons :  

• A partir de zéro, 

• A partir du service Azure,  

• Avec un document OPEN API, 

• Avec une collection Postman, 

• A partir de Git hub. 

 

Création de connecteurs personnalisés à partir de zéro : 

Figure 2 : Interface de création d'un connecteur personnalisé à partir from scratch

Dans cet exemple, les développeurs professionnels ont implémenté un connecteur personnalisé à partir de zéro qui récupère, via une API Web, les données météorologiques du site https://openweathermap.org. 

Power Fx, utilisé principalement dans les applications canevas Power Apps, est un langage similaire aux formules utilisées dans Excel.  

Dans l’exemple ci-dessous, le Citizen Developer fait appel au connecteur personnalisé pour récupérer les données de l’API Web OpenWeatherMap. 

 

Figure 3 : Récupération de données via un connecteur personnalisé dans une application Canevas Power Apps

 

SwaggerHub pour générer une documentation OPEN API 

Il est aussi possible de créer un connecteur personnalisé avec la plateforme de développement SwaggerHub. Cet outil permet de créer, documenter, gérer et déployer des API Web.  

La documentation OPEN API est nécessaire à la création d’un connecteur personnalisé dans Power Platform. Il s’agit soit d’un fichier YAML ou JSON contenant les informations principales de l’API Web. 

Figure 4 : Exemple de fichier OPEN API au format YAML

Dans cet exemple, le document OPEN API est directement importé dans l’environnement Power Platform :  

 

 

Figure 5 : Importation d'un document OPEN API dans Power Platform pour la création d’un connecteur personnalité

Lors de l’importation, les paramètres de l’API Web sont automatiquement remplis ainsi que les différentes méthodes de requête : La requête searchInventory permettra à l’utilisateur de rechercher un article dans l’inventaire (GET) et la requête addInventory pour ajouter un article (POST) 

Figure 6 : Interface de paramétrage d'un connecteur personnalisé avec OPEN API

 

Figure 7 : Utilisation d'un connecteur personnalisé dans un flux Power Automate

De leur côté, les Citizens Developers n’auront plus qu’à utiliser le connecteur personnalisé dans Power Automate ou Power Apps. Par exemple, pour rechercher un article ou en ajouter un dans l’inventaire.  

 

Les approches algorithmiques dans Power Automate. 

Power Automate est l’outil permettant d’automatiser les tâches dans le but d’améliorer la productivité d’une organisation.  

Dans un flux, le Citizen Developer définira un déclencheur. Ce déclencheur récupèrera des données métier et ajoutera ensuite des étapes qui effectueront des actions telles que l’envoi d’un e-mail ou bien l’ajout d’un évènement dans un calendrier Outlook :  

Bien que l’outil soit facile d’utilisation, il se cache quelques techniques que seuls les développeurs professionnels connaissent :  

Les éta de type Control regroupent plusieurs actions :  

 

 

Figure 8 : Insertion d'une étape de type Control

 

• Des conditions, 

• Des boucles : Appliquer à chacun, 

• Des Switch : Basculer,  

• Des boucles : Exécuter jusqu’à, 

• Des portées. 

 

Intégration d’une clause Try Catch dans un flux 

Avec ses connaissances en programmation, le développeur professionnel peu intégrer une clause Try Catch dans un Flux Power Automate. 

Lorsqu’un flux s’exécute, si l’une des actions est en erreur, alors les autres actions qui la suivent ne s’exécuteront pas. 

Admettons que le besoin initial vise à récupérer les propriétés d’un fichier et de les envoyer par e-mail. 

Si les propriétés du fichier ne sont pas récupérées, alors il faudrait envoyer un e-mail alertant le destinataire que le fichier n’est pas à disposition, dans le cas contraire, le corps du message sera composé du nom du fichier. 

 

Figure 9 : Exécution d'un flux en erreur

Dans cet exemple, les propriétés du fichier n’ont pas été récupérées : l’action « Obtenir les propriétés du fichier » a généré une erreur et l’action « Envoyer un e-mail (v2) » ne s’est donc pas exécutée. 

Nous souhaitons tout de même envoyer un mail en informant le destinataire, même si les propriétés du fichier n’ont pas été récupérées. 

Il existe, dans Power Automate, une méthode permettant d’exécuter une action même si la précédente à générer une erreur. 

Figure 10 : Paramétrage de l'exécution d'une étape selon l'état de la précédente

L’action « Envoyer un e-mail (V2) » s’exécutera même si l’action « Obtenir les propriétés du fichier » génère une erreur. 

En sélectionnant le pictogramme et en cliquant sur : « configurer la propriété exécuter après », on peut décider de l’exécution d’une action selon l’état de la précédente :  

• Réussie, 

• Echouée, 

• Ignorée 

• Expirée.  

 

Ici, le flux s’est exécuté dans sa totalité et on remarque que l’action « Obtenir les priorités du fichier » génère toujours une erreur. Pourtant, l’exécution des autres actions n’est pas impactée. 

Seulement, la logiquement métier n’est pas bonne : le corps du mail indique que le fichier est à disposition. Or, ce dernier n’a pas été récupéré puisque l’action qui le récupère a généré une erreur. 

Figure 11 : Exécution d'un flux où la troisième étape est exécutée bien que la précédente soit en erreur

C’est là qu’intervient la clause Try Catch qui peut être utile pour respecter la logique métier. 

En algorithme, le clause Try catch fonctionne de cette façon :  

• Dans le bloc Try : on ajoute le code à exécuter. 

• Dans le bloc Catch, le code à exécuter si le code dans le bloc Try à générer une erreur. 

Dans Power Automate, il est possible de faire la même chose en utilisant l’action Etendue. Cette action permettra d’ajouter plusieurs sous-actions dans cette dernière.  

 

Lors de l’exécution du flux, le bloc Try ayant échoué, il passe directement au bloc Catch afin de récupérer le message indiquant que le fichier n’est pas à disposition. Le développeur professionnel a reproduit exactement la même méthode Try Catch comme s’il l’avait codée dans un IDE.  

Figure 12 : Exécution d'un flux où l'e-mail est envoyé sans les propriétés d'un fichier

 

A l’inverse, si les propriétés du fichier ont été récupérées, alors l’action Catch est ignorée et le corps du message indique que le fichier a bien été récupéré. 

On remarque que l’action Try ayant réussi, l’action Catch a été ignorée.  

Le corps du message contient le nom du fichier et s’est bien envoyé. 

Figure 13 : Exécution d'un flux où l'e-mail est envoyé avec les propriétés d'un fichier

Les Scripts Python dans Power BI 

Power BI est une solution développée pour la création et le partage de rapports et tableaux de bord. 

Elle comporte trois principaux composants :  

• Power BI Desktop, l’application Bureau permettant de créer des rapports, 

• Power BI Service permettant publier et partager des rapports dans l’organisation, 

• Les applications accessibles sur les équipements de type tablette et mobile. 

Dans le même principe que Power Apps et Power Automate, Power BI utilise des connecteurs pour centraliser les données métiers dans un modèle et ainsi permettre de créer des rapports. 

Peuvent s’ajouter à l’équipe de fusion numérique, des Data Analystes ou autres métiers travaillant directement dans l’informatique décisionnelle.  

Power Query est un outil de transformation de données directement intégré dans Power BI Desktop. Il permet entre autres de nettoyer les données métiers qui ont été importées dans le modèle. 

Les data analystes de l’équipe de fusion numérique ont les compétences de créer des visualisations dans des rapports Power BI Desktop. Elles sont la représentation visuelle des données métiers importés. 

Cependant, selon leur besoin, ils peuvent faire appel aux développeurs professionnels pour créer des visuels plus complexes à l’aide de scripts Python. 

Figure 14 : Création d'un visuel avec un script Python dans Power BI Desktop

Conclusion 

Souvent, lorsque l’on positionne un développeur de métier sur un projet Power Platform, il peut se retrouver parfois déçu du manque de technique dû au concept du Low code / No Code. Les Citizen Developers, quant à eux, risquent de se sentir dépassés par la complexité de la demande. C’est pourquoi il est important de constituer une équipe de fusion numérique regroupant différents profils aussi bien techniques que métiers. 

Les Citizen Developers, idéalement, devront être à cheval entre la partie technique et la partie métier pour la conception d’applications Power Apps et de flux Power Automate. Les développeurs professionnels interviendront uniquement en cas de tâches trop complexes. Dans ce dispositif, n’oublions pas les Utilisateurs finaux ! Ces derniers sont voués à tester les applications et à communiquer leurs retours aux Citizen Developers dans un objectif d’amélioration des applications.