Introduction

Nous avions tous à une certaines époque des fermes SharePoint on-premise avec des flux de travail pour modéliser nos processus business d’approbation, de partage de document…

Ces processus étaient souvent construit en utilisant le bon vieux SharePoint Designer qui permettait de construire nos flux et les publier sur notre plateforme. Aujourd’hui le Cloud est la et un nouveau service est à notre disposition: Power Automate.

Le but de cet article est de vous guider dans la manière de gérer et planifier la migration de flux SharePoint 2010 ou 2013 dans Power Automate.

Les flux SharePoint 2010 & 2013

Commençons déjà par expliquer le fonctionnement des flux de travail SharePoint 2010 & 2013 afin de bien comprendre la différence avec Power Automate. Si vous maitrisez déjà cet aspect, vous pouvez passer au chapitre suivant.

Les flux SharePoint 2010 étaient publiés sur la plateforme SharePoint Server et exécutés par le runtime SharePoint flux de travail. Les flux SharePoint 2010 ne sont plus supportés par Office 365 depuis Novembre 2020 (SharePoint 2010 workflow retirement – Office Support (microsoft.com))

Les flux SharePoint 2013 étaient publiés sur la plateforme SharePoint Server et executés dans un processus dédié pour les flux de travail. Ces workflows ne sont plus supporté depuis Novembre 2020 sauf pour ceux qui ont été migrés sur O365 qui sont eux maintenus jusque janvier 2023.

Comme vous l’aurez compris ces 2 types de workflows sont vraiment dépendants de la plateforme SharePoint et nous avions à disposition des outils comme SharePoint 2010/2013 Designer pour développer ces workflows.

Un des points important à souligner également est que sur ce type de workflow, étant executé sur des fermes on-premise nous avions la possibilité de développer des custom activities et les déployer sur notre ferme. Des custom activities ne sont rien de plus que des actions de workflow que vous pouviez développer via une solution visual studio et ensuite déployer sur votre ferme afin de pouvoir les utiliser dans vos workflows. Bien évidemment, ce genre ne choses n’est possible que sur des fermes on-premise.

Et Power Automate alors ? c’est quoi la différence ?

Power Automate est un moteur de workflow totalement indépendant qui fait partie du service PowerPlateform dans Office 365.

Ce service n’est disponible que dans le cloud mais permet d’interagir avec des systèmes on-premise par le biais de solution comme la Data Gateway.

L’avantage de cette solution c’est que vu qu’elle est totalement indépendante, elle vous permet de construire des workflows pour pas mal d’application y compris sans interaction avec SharePoint. Contrairement aux flux de travail SharePoint qui eux ce limitait à des déclenchement à partir de données sur cette plateforme, power automate lui est capable de se déclencher à la reception d’un email dans une boite exchange par exemple.

Cette solution permet donc la modélisation de processus bien plus élargie que ce que nous connaissions avec SharePoint.

L’inconvénient est que cette différence ne permet pas de migrer de manière automatique les workflow SharePoint vers powerautomate. On parle alors plus de réécriture.

Réécriture dans Power Automate

Vous avez encore des workflow 2010 ou 2013 ? je vous conseil vivement donc de passer à la solution power automate si vous planifiez une migration O365 ou si vous êtes déjà sur O365. Si un partenaire dans le cadre d’un nouveau projet vous conseil le développement d’un workflow SharePoint 2013… c’est une erreur! Vous partirez déjà avec une dette technique et une deadline déjà communiquée par Microsoft sur le support de ces workflows.

Vu que nous parlons ici plus de réécriture que de migration, voici les quelques étapes que je considère nécessaire pour que cela se passe bien. Bien évidemment ce n’est pas exhaustif! Chaque projet/contexte est différent et particulier et donc nécessitera peut être des étapes supplémentaires.

Les pré-requis

Avant de faire du power automate, il faut avoir connaissance des pré-requis.

• Des licences Power Automate
• Avoir migré son site dans Office 365 ou installer une datagateway avec une version de SharePoint supportant le modèle Hybride
• Quelques connaissance sur power automate et son fonctionnement.
• Un compte de service propriétaire des flux et des connexions

L’inventaire

Tant qu’a réécrire des workflows, c’est le bon moment aussi pour se poser les bonnes questions:

• Mon workflow est-il toujours utilisé/nécessaire?
• Mon workflow est-il toujours en phase avec mon processus business?
• Mon workflow peut-il être amélioré par des tâches faisable dans powerautomate ?

L’idée est de dresser un inventaire de vos workflows en identifiant les informations suivantes:

• Type de trigger
• Listes dépendantes
• Colonnes dépendantes
• Tâches
• Usage de custom activities ?
• Dépendance avec une solution de ferme?

Une fois que vous avez l’ensemble de ces informations et que vous en avez profiter pour vous poser les bonnes questions sur vos workflows, vous pourrez ainsi définir votre périmètre de réécriture précis.

L’inventaire peut être sous le format qui vous convient le mieux, pour ma part, j’opte généralement pour un bon vieux fichier excel avec une sheet par workflow afin d’avoir un inventaire clair et complet.

L’optimisation

Power Automate offre d’autres possibilités que les workflow SharePoint. Cela peut vous permettre notamment de répondre à un besoin qui n’était pas faisable en standard ou nécessitait le développement d’une custom activities.

C’est le moment de prendre le périmètre de réécriture et de chercher à optimiser/améliorer vos workflows.

Tout d’abord, concentrez vous sur les custom activities dont nous savons déjà que nous pourrons pas les récupérer. Identifiez ce que fait votre custom activities et intégrez cela à votre workflow. De quel manière je procède personnellement? Pendant l’inventaire, je fais un schéma draw.io me permettant de répertorier toutes les tâches de mon workflow, si je trouve des custom activities, j’intègre des actions power automate remplaçante à la place.

Exemple: Votre custom activities effectue un appel API et fait une mise à jour d’un élément dans SharePoint. ça tombe bien, une action powerautomate vous permet de faire un appel API. Remplacez donc cette custom activities par les étapes power automate qui vous permettrons de reproduire le flux d’origine.

Ensuite, on va rechercher l’optimisation. En effet, power automate permettant de faire pas mal de chose par le biais des conditions, contrôles et actions vous trouverez surement des améliorations à effectuer à votre workflow.

Personnellement je ne fais pas de travail en amont pour cette partie. Généralement je le fais au moment de la réécriture. Néanmoins si besoin, vous pouvez reprendre votre schéma et la liste des tâches power automate disponibles afin d’identifier des améliorations possibles et le prévoir dans votre réécriture.

La réécriture

Passons maintenant à la réécriture, pour cela il vous faut votre inventaire et vos schémas, si besoin vous pouvez garder SharePoint Designer ouvert avec les anciens workflow si ça peut vous aider. Normalement l’inventaire devrait suffire si vous avez mis l’ensemble des informations importantes dans celui ci.

Il vous suffit ensuite d’ouvrir power automate et de reproduire votre workflow, si ce dernier doit interagir avec des systèmes externes comme SharePoint, Exchange ou autre les tâches à disposition effectuerons la création de connecteur. Les connecteurs vous permettent d’avoir une meilleurs expérience power user lors de la construction de votre flux power automate. En effet, les connecteurs vous présente un panel de configuration et d’option adaptées pour la solution cible, derrière cela il ne s’agit que des appels à une API…

Attention, les connecteurs se configurent de basent avec votre identité utilisateur, veillez donc à bien disposer des droits.

Une fois votre flux réécrit, veillez à ne pas avoir d’erreur via le flux checker et effectuez un test via la fonction de test. (je ne vais pas m’étendre ici sur le fonctionnement de power automate, je ferais un article sur le sujet ultérieurement).

Une fois testé enregistrez le et validez le bon fonctionnement avec des utilisateurs.

La configuration

Comme indiqué dans le chapitre précédent, si vous avez utilisé votre compte pour les connecteurs utilisé de votre flux, cela va poser un problème. Mais pourquoi?

Imaginons, votre compte est désactivé ou supprimé. Le flux utilisent votre compte pour les différents connecteurs qu’il utilise mais pire, vous êtes le seul propriétaire du flux! (Bon ok les admin O365 y ont accès mais imaginons qu’ils sont en vacance 🙂 ), Votre flux va tout simplement tomber en erreur ce qui est tout à fait logique.

Mais alors, c’est quoi la bonne pratique?

Pour ma part, je vous conseil un compte de service pour l’exécution de vos flux.

Assignez les droits au site SharePoint ou autre à votre compte de service, puis définissez votre compte de service comme propriétaire du flux par la même occasion. Si besoin, changez les connexions de vos connecteurs pour utiliser l’identité du compte de service.

La supervision & le monitoring

De base si votre flux est en échec, les propriétaires reçoivent un mail pour prévenir de l’échec en mentionnant le nombre d’occurrence.

La power plateforme vous permet également d’avoir quelques dashboard au format Power BI des executions, du statut etc…

Vous pouvez au sein de powerautomate, consulter l’historique des executions mais aussi pour chaque execution consulter l’historique des tâches exécutées afin que si un échec est survenu, comprendre pourquoi, sur quelle tâche et avec quelles données en entrée et l’erreur retournée.

Il n’existe à ce jour malheureusement pas d’intégration avec Application Insight comme nous pouvons l’avoir avec les PowerApps, néanmoins les données de vos flux sont consultables via API et donc on peut imaginer intégrer votre outil de supervision préférer afin d’exécuter un PowerShell pour récupérer le statut des executions et provoquer une alerte si il y a des échecs.

La gouvernance

De manière générale, power automate & power apps sont des services cloud qui peuvent vite se transformer en Shadow IT. En effet, des power user qui auraient des droits pourrais très vite fabriquer des flux ou des apps indispensables au sein du SI sans que cela soit visible ou répertorié. Souvenez vous de la bonne époque des applications access indispensables au business…

Pour ce faire, Microsoft à mis à disposition un Kit COE: Kit Center of Excellence Microsoft Power Platform – Power Platform | Microsoft Docs

Je vous conseil grandement de le mettre en place au sein de votre organisation si vous comptez utiliser la powerplateform. Ce kit est composé d’une combinaisons de flux, apps et rapports vous permettant d’avoir une vision complète sur l’utilisation de la powerplateform au sein de votre tenant. Ce kit est bien évidemment customizable et peut donc être adapté en fonction de vos besoins. Je reviendrais sur ce sujet dans le cadre d’un autre article sur la mise en place de ce kit.

Conclusion

Power Automate est un composant formidable sur lequel il faudra investir rapidement surtout pour les entreprises disposants de flux SharePoint. Mais attention à l’opacité de la powerplateform de base! Voici ma manière d’aborder une réécriture de flux et comme spécifié, la manière d’aborder un problème dépend de la complexité et de son contexte, j’espère néanmoins vous donner des bases pour préparer vos réécriture au mieux 🙂