De Promapp à la Power Platform, l’intégration que personne n’attendait.

 

Une API est une programme qui permet à des écosystèmes différents de communiquer et paratger des informations. Elles sont en très puissantes et facilitent la collaboration fluide de systèmes complètement différents les uns des autres. En exploitant les APIs et les capacités de Power Automate et Power Apps, nous avons lié Promapp et la Power Platform.

Dans cet article, nous vous présentons la démarche adoptée pour assurer une synchronistaion parfaite entre Promapp et la Power Platform (Power Apps, Power Automate, SharePoint) au moyens des APIs.

 

Contexte :

Il est question de gérer sur Power Apps, la matrice RACI des activités des processus de Promapp. Pour cela il faut :

1. Récupérer tous les processus (car les activités sont contenus dans les processus) de Promapp depuis Power Apps
2. Récupérer les rôles qui vont alimenter le RACI des activités, également depuis Power Apps
3. Ecrire dans les notes des activités sur Promapp pour sauvegarder le RACI défini, aussi depuis Power Apps

En somme, il faut récupérer les données de Promapp depuis Power Apps, puis les gérer et les retourner.

 

Technologies

Nintex Process Manager (Promapp)

Promapp est un produit Nintex qui permet de centraliser et gérer l’ensemble des processus d’une organisation. Cette plateforme offre une vue complète sur la hiérarchie des processus : des groupes de niveau supérieur jusqu’aux activités individuelles. Chaque processus peut contenir des sous-processus, des activités, et des notes associées, créant ainsi une structure arborescente riche et détaillée.

La force de Promapp réside dans sa capacité à structurer les processus métier de manière claire et accessible, tout en permettant une collaboration entre les équipes. Pour notre projet, l’enjeu était d’exploiter cette richesse de données et de la rendre accessible depuis un autre écosystème : la Power Platform.

 

Microsoft Power Platform (Power Automate, Power Apps, SharePoint)

La Power Platform de Microsoft est une suite d’outils low-code/no-code qui permet de créer des solutions business rapidement et efficacement. Pour ce projet, nous avons mobilisé trois composants clés :

• Power Automate : Pour orchestrer les appels APIs, transformer les données (XML/JSON), et assurer la synchronisation entre Promapp et SharePoint
• Power Apps : Pour créer l’interface utilisateur permettant de visualiser, naviguer et gérer les RACI des activités
• SharePoint : Pour stocker les données localement (processus, rôles, RACI) et servir de source de données pour Power Apps

Cette combinaison est très flexible pour créer des flux de données complexes sans développement lourd, tout en garantissant une expérience utilisateur fluide et intuitive.

 

Architecture de la solution

Promapp ⇔ APIs ⇔ Power Automate ⇔ Power Apps/SharePoint

Les APIs Promapp servent de pont entre les deux écosystèmes. Power Automate joue le rôle de chef d’orchestre : il appelle les APIs, traite les réponses, transforme les données, et alimente Power Apps et SharePoint. De son côté, Power Apps offre l’interface permettant aux utilisateurs de consulter et modifier les données, qui sont ensuite renvoyées vers Promapp via le même circuit.

Cette architecture bidirectionnelle garantit que les deux systèmes restent toujours synchronisés, sans intervention manuelle.

 

Step 1 : Récupération de tous les processus de Promapp

1️⃣ Récupération du Token :

Avant de pouvoir dialoguer avec Promapp, il faut d’abord obtenir l’autorisation.

Le token est votre clé d’entrée vers l’écosystème Promapp. Sans lui, impossible d’accéder aux données. Il s’agit d’un jeton d’authentification généré par Promapp qui permet de sécuriser tous les appels APIs suivants.

        

Type de requête : POST

Point de terminaison : https://{region}.promapp.com/{siteName}/oauth2/token

Authentification : Non applicable

Corps :

• type_autorisation : mot_de_passe
• nom d’utilisateur : {username}
• mot de passe : {password}
• durée : 60 000

Indications :

• Vous devez utiliser le type de données x-www-form-urlencoded .
• Définissez votre région en fonction de l’emplacement d’hébergement de votre instance.
• {siteName} correspond au nom de votre instance Process Manager.
• Le {username} et {password} utilisés ici sont ceux de votre compte Process Manager . Nous vous recommandons d’utiliser un compte Promaster disposant des droits d’accès à toutes les données de processus.

 

2️⃣ Récupérations des groupes des processus

On a déjà la clé donc on peut  pénéter dans Promapp. Les données dans Promapp constituent un véritable arbre génialogique ! Ainsi avant d’atteindre les processus, nous devons passer par les éléments parents, en l’occurrence les groupes. Cette étape permet de récupérer les IDs de tous les groupes de Promapp et pour chaque groupe sa structure.

Type de requête : GET

Point de terminaison : https://{region}.promapp.com/{siteName}/Process/View/GetChildProcessGroupTreeItems

Authentification : Bearer {token} (Jeton d’accès de l’étape 1)

Résultat : On obtient tous les groupes avec pour chacun sa structure : nombre d’éléments enfants, id, uniqueid etc.

 

3️⃣ Retourner le XML des processus

On a la clé, on a les groupes, on fonce chercher les processus ! Cette étape permet de remonter le XML de tous les processus de tous les groupes. Il est important de les remonter car c’est là que sont stockées les activités dont il faut gérer le RACI. Trust the Process :

 

Explication :

Get the XML of each group : On boucle sur le JSON des groupes récupérés précédemment les étapes suivantes :

Analyse JSON : C’est une sous étape qui permet d’analyser le JSON des groupes récupérer afin d’accéder facilement aux champs de ces derniers.

Group UniqueId : A cette sous étape, on stocke le champ UniqueId du groupe dans une variable {groupID}

Get Process XML : On récupère ensuite tous les processus d’un groupe donné.

Type de requête : GET

Point de terminaison : https://{region}.promapp.com/{siteName}/Process/ImportExport/ExportProcessGroup?ProcessGroupUniqueId={groupID}&Format=Xml&RecursionLevel=Full&altUrls=true

Authentification : Bearer {token}

Concatenate XML : A chaque fois qu’on récupère les processus d’un groupe, on les stocke dans une varaible préalablement déclarée. A la fin de la boucle on a une variable contenant tous les groupes avec leurs processus.

Sortie :

 

4️⃣ Conversion des données en XML et en JSON

Les données stockées dans la variale XML ne sont pas encore au format XML. En effet, Power Automate les voit comme du texte même si à vue d’oeil elles ont bien la structure d’un XML. C’est pourquoi, il faudra d’abord les convertir au format XML. Pour cela on utilise la fonction xml() avec en paramètre la variable XML.

 

Ensuite, elles devront être converties au format JSON afin que Power Apps puisse les exploiter efficacement.

Convert each group to JSON : On boucle sur les données XML précédemment converties (tous les groupes), les étapes suivantes :

EachProcessGroup JSON :  Ici, on convertit (en JSON) un par un chaque groupe (et tous ses éléments bien évidemment). On utilise de ce fait la fonction  json() avec en paramètre la sortie du step précédent : items (‘Convert_each_group_to_JSON‘)

Concatenate ProcessGroupArray : A chaque fois qu’on a converti un groupe en JSON, on le stocke dans un tableau préalablement déclaré.

Sortie :

A la fin de la boucle, on obtient un tableau contenant le JSON de tous les groupes. 💫

 

5️⃣ Répondre à Power Apps

Ce flux est un Instant Cloud Flow déclenché manuellement depuis Power Apps. Il est donc plus que normal que nous répondions à Power Apps. La réponse est le JSON que nous avons précédemment stocké dans un tableau. Il sera envoyé sous forme de chaine de caractère à Power Apps.

 

On a récupérer toutes les données de Promapp, puis nous les avons transformé afin qu’elles soient facilement exploitable. Quel exploit !

Cependant, nous n’avons récupérer que les activités, pourtant pour gérer le RACI de ces dernières, il faut également récupérer les rôles qui vont aider à le faire. Prochain défi, remonter de Promapp les rôles qui vont aider à alimenter le RACI des activités.

 

Step 2 : Récupération des rôles de Promapp

1️⃣ Récupération de l’utilisateur de Promapp

Tout comme le flux précédent, ce flux est un Instant Cloud Flow, déclenché par Power Apps.

Les rôles que nous souhaitons remontés sont liés à un utilisateur précis dans Promapp. Il faudra d’abord stocker l’email de cet utilisateur dans une variable.

Ensuite on récupère le processus proprement dit.

Type de requête : GET

Point de terminaison : https://api.promapp.com/api/scim/users?filter=username eq « {email} »

Authentification : Bearer {token}

Note :

{token} est un jeton SCIM générer depuis l’interface de Promapp par un utilisateur qui a les droits d’un Process Master. Il permet de sécuriser l’appel de l’API SCIM.

Sortie : Le résultat de cet appel est un JSON contenant toutes les informations de notre utilisateur.

 

2️⃣ Extraction et sauvegarde des rôles

Ces données nous montre qu’ un utilisateur est caractérisé par plusieurs champs : email, nom, rôle. Ce qui nous intéresse ce sont les rôles. Il est donc question  d’analyser et de parcourir ces données afin d’extraire uniquement la table des rôles.

Tout d’abord, on anlyse la sortie de la requête HTTP précédente à l’aide de l’action parse json avec un schema précis. Les informations que nous recherchons se trouvent dans le tableau Ressources[ ] comme vue sur l’image des données remontées. Ainsi le schema a utiliser ici est celui obtenu à partir de ces données là.

 

Ensuite, on parcours les informations analysées (Tableau Ressources[ ]) à l’aide d’une boucle for each. Dans la boucle Loop on informations, on va localiser les roles et on va également boucler dessus. Dans la boucle Loop on roles , on va aller récupérer les éléments de notre liste SharePoint à l’aide de Get items, afin de la mettre à jour avec les rôles que nous sommes allés chercher dans Promapp. C’est cette liste que Power Apps utilise pour alimenter les RACI des activités.

Toujours dans la boucle Loop on roles, juste après l’action Get items suit une condition. Cette condition est basée sur la taille des éléments retournés par Get items : length(outputs(‘Get_items’)?[‘body/value’]) is greather than 0. C’es-à-dire : Taille des éléments de Get items est supérieure à 0.

Si OUI : On met à jour les éléments existant à jour

SI NON : On crée de nouveaux éléments.

 

Récapitulons. On a remonter tous les processus par la même occasion toutes les activités. Nous sommes également allés chercher tous les rôles qui vont alimenter les RACI des activités. Parfait !

A présent, il est question de retourner à Promapp le RACI de chaque activité. Le RACI envoyé par Power Apps sera sauvegardé dans les notes des activités sur Promapp. En clair, depuis Power Apps on doit pouvoir écrire dans les notes des activités dans Promapp. Allons y !

 

Step 3 : Ecrire dans les notes des activités dans Promapp depuis Power Apps

Nous sommes parvenue au dernier niveau d’intégration de Promapp et la Platform. En effet, le RACI gérer dans la Power Platform doit être renvoyer à Promapp où il sera stocké au niveau des notes des activités. Cette intégration est sans doute, la plus intérressante et la plus délicate parce qu’elle implique l’utilisation de plusieurs APIs à appeler dans l’ordre pour avoir un bon résultat. Le

t’s go !

1️⃣ Déclenchement du flux

Le flux est un Instant Cloud Flow et le déclencheur c’est Power Apps. Vue que les données que l’on souhaite envoyé à Promapp sont gérer dans Power Apps, il est plus que évident qu’on doit avoir des paramètres en entrée. A cet effet, comme entrées on a : l’ID du processus dont on souhaite modifier les activités, l’ID de l’activité dont on souhaite mettre à jour les notes et enfin les champs R, A, C, I de l’activité en question.

Ces paramètres sont indispensables car ils vont servir à construire le JSON à envoyé à Promapp.

2️⃣ Récupération du jeton d’authentification

Toujous s’authentifier avant de faire quoi que ce soit dans Proamapp. Ici, on récupère le token qu’on va utiliser pour les appels suivants. Il va permettre de sécuriser les appels des autres APIs.

Type de requête : POST

Point de terminaison : https://{region}.promapp.com/{siteName}/oauth2/token

Authentification : Non applicable

Corps :

• type_autorisation : mot_de_passe
• nom d’utilisateur : {username}
• mot de passe : {password}
• durée : 60 000

Indications :

• Vous devez utiliser le type de données x-www-form-urlencoded .
• Définissez votre région en fonction de l’emplacement d’hébergement de votre instance.
• {siteName} correspond au nom de votre instance Process Manager.
• Le {username} et {password} utilisés ici sont ceux de votre compte Process Manager . Nous vous recommandons d’utiliser un compte Promaster disposant des droits d’accès à toutes les données de processus.

Après avoir générer le token, il faudra analyse le résultat et extraire le Token et le stocker dans une variable.

 

3️⃣ Authentification du compte sur Promapp et extraction des informations de la session

Après avoir générer le Token, il faudra s’authenfier à Promapp avec son login. En effet, Promapp souhaiterait se rassurer de l’identité de l’utilisateur qui veut accéder à lui. Cette étape est importante car nous allons y extraire des éléments qui vont servir pour la suite. Il s’agit donc d’une page de connexion.

Type de requête : POST

Point de terminaison : https://{region}.promapp.com/{siteName}/Login.aspx

Authentification : Non applicable

Corps :

application/x-www-form-urlencoded&ImpersonationEnabled=False&IsSingleSignOnEnabled=False&Login=Login&&ResetPasswordEnabled=True&ReturnUrl=

Indications :

• Vous devez utiliser le type de données x-www-form-urlencoded .
• Définissez votre région en fonction de l’emplacement d’hébergement de votre instance.
• {siteName} correspond au nom de votre instance Process Manager.

 

Il faut maintenant analyser la sortie de la requête et extraire les informations de la session, en l’occurrence, l’ID de la session, et un élément qui permettra de valider le token générer nommé RequestVerificationToken. Ils se trouvent dans les cookies de la page de connexion.

 

Action : Parse JSON

Content : Headers de la requête HTTP Login RequestVerificationToken.

Schema : copier la sortie (header) de la requête HTTP, ensuite cliquer sur Generate from sample, puis coller le contenu et valider.

 

Extract SessionId : action entrée avec comme entrée :  split(split(body(‘Analyse_Login_RequestVerificationToken’)?[‘Set-Cookie’], ‘ASP.NET_SessionId=’)[1], ‘;’)[0]

SessionId : Initialisation de la varianle SessionId, de type chaine de caractères avec la sortie de Extract SessionId

 

Extract RequestVerificationToken : Action Compose avec comme entrée : split(split(body(‘Analyse_Login_RequestVerificationToken’)?[‘Set-Cookie’], ‘__RequestVerificationToken=’)[1], ‘;’)[0]

RequestVerificationToken : Initialisation de la varianle RequestVerificationToken, de type chaine de caractères avec la sortie de Extract RequestVerificationToken

 

4️⃣ Récupération du processus dont on souhaite mettre à jour ses activités

Il faut à présent récupérer le processus dont on souhaite modifier les ou l’activité(s). Vous vous demander surement pourquoi on récupère d’abord un élément avant de le modifier, eh bien on le fait pour se rassurer qu’un même processus ne soit pas modifié par plusieurs personnes au même moment. En effet, lors de la récupération du processus, il y a un élément qui stocke la version du processus. Ceci permet d’éviter ce genre d’incident.

Type de requête : GET

Point de terminaison : https://{region}.promapp.com/{siteName}/Api/v1/Processes/{processUniqueId}

Authentification : Bearer {access token}

Entête :

x-requested-with : XMLHttpRequest

Cookie : ASP.NET_SessionId={sessionId}; _RequestVerificationToken={RequestVerificationToken}

Indications :

• Vous devez utiliser le type de données application/json
• Définissez votre région en fonction de l’emplacement d’hébergement de votre instance.
• {siteName} correspond au nom de votre instance Process Manager.
• {processUniqueId} représente l’ID du processu que l’on souhaite récupérer, c’est à dire celui aui a été passé en paramètre au niveau du déclencheur.
• {sessionId}, {RequestVerificationToken} représentent les éléments extraits après le login à Promapp
• {access token} est le jeton d’authentification généré plus haut.

Sortie :

Après cette étape, vous pourrez analyser le corps de la requête à l’aide d’une action Parse JSON afin d’avoir la main mise sur les différentes propriétés.

5️⃣ Mettre à jour les notes des activités du processus remonté

Tout d’abord, il faut déclarer les variables pour stocker les activtés, les notes et le RACI

 

Ensuite, on met à jour les notes des activités. On va pour cela, parcourir toutes les activités du processus qu’on a remonté et vérifier pour chaque activité si elle correspond à celle qu’on veut mettre à jour, c’est à dire si elle correspond à celle qu’on a pris en entrée au niveau du déclencheur.

Si elle correspond :

On met à jour l’activité du processus et on concataine le tout dans le tableau précédement déclaré. Le JSON suivant est construit en copiant le JSON de l’objet Activity dans le JSON du processus récupérer plus haut.

Au niveau du champ Note, on va mettre le tableau des notes précédemment initialisé avec le RACI pris en paramètre au niveau du déclencheur. Quant aux autres champs, ils restent intactent.

 

Si elle ne correspond pas : On maintient l’activité telle quelle.

 

6️⃣ Construction du JSON du processus et envoie à Promapp

Maintenant qu’on a modifier les activités, il faut envoyé le processus à jour à Promapp.

Nous allons d’abord construire le JSON a envoyé. On va utiliser pour ce fait une action Compose avec pour entée : setProperty(body(‘Parse_Process_JSON’)?[‘processJson’], ‘ProcessProcedures’, setProperty(body(‘Parse_Process_JSON’)?[‘processJson’]?[‘ProcessProcedures’], ‘Activity’, variables(‘ModifiedActivities’))).

Cette expression met à jour le JSON du processus remonté en remplaçant la valeur Activity à l’intérieur de ProcessProcedures par une nouvelle liste d’activités stockée dans la variable ModifiedActivities.

A présent on va envoyé le JSON du processus à Promapp en remplaçant processJSON avec le processJSON qu’on a construit.

Type de requête : PUT

Point de terminaison : https://{region}.promapp.com/{siteName}/Api/v1/Processes/{processUniqueId}

Authentification : Bearer {access token}

Entête :

x-requested-with : XMLHttpRequest

Cookie : ASP.NET_SessionId={sessionId} ;  _RequestVerificationToken={RequestVerificationToken}

Corps :

{

« ProcessJson »: « @{outputs(‘Build_Updated_ProcessJson’)}« ,
« ChangeDescription »: « Ajout note RACI depuis Power Apps »,
« DoSubmitForApproval »: false,
« DoPublish »: false,
« SuppressChangeNotification »: false,
« SharedActivityCollectionEditModel »: {
« ActivitiesToDelete »: [],
« ActivitiesToShare »: [],
« ActivitiesToUnlink »: []
},
« VariantConnectionChangeStates »: []

}

Indications :

• Vous devez utiliser le type de données application/json
• Définissez votre région en fonction de l’emplacement d’hébergement de votre instance.
• {siteName} correspond au nom de votre instance Process Manager.
• {processUniqueId} représente l’ID du processu que l’on souhaite mettre à jour, c’est à dire celui aui a été passé en paramètre au niveau du déclencheur.
• {sessionId}, {RequestVerificationToken} représentent les éléments extraits après le login à Promapp
• {access token} est le jeton d’authentification généré plus haut.

8️⃣ Répondre à Power Apps

Pour s’assurer que tout s’est bien passé, Power Apps aura en sortie un message. Un message status fixé à sucess si tout se passe bien. Ainsi si le résultat est différent, alors on saura qu’il y a une erreur.

 

 

Conclusion

Rappelons le contexte. Il question de concevoir une solution Power Platform permettant de gérer le RACI des activités des processus de Promapp. Pour cela il fallait faire travailler Promapp et la Power Platform main dans la main afin de garantir une synchronisation efficace entre les deux. Pour mener à bien notre mission, nous avons exploité les APIs puisssantes et diversifiées dont Promapp dispose. A la fin de ces actions, nous obtenons une liason efficace et transparente de ces technologies.