Bonjour à tous,
Comme vous pouvez le voir, j’ai changé le design pour mieux correspondre au sujet principal de mon blog: SharePoint.
Les couleurs avec une « Metro Touch » pour une navigation plus agréable.
N’hésitez pas à laisser vos commentaires et vos suggestions!
Vous utilisez Azure Devops pour vos projets et justement vous développez actuellement une application type client lourd pour vos postes utilisateurs ?
Vous avez constaté comme moi qu’Azure Devops ne dispose pas d’extension pour le déploiement automatisé dans SCCM?
Voila pourquoi je me suis lancé dans le développement d’une extension Azure Devops pour répondre à ce besoin!
L’extension est disponible sur le marketplace Visual Studio: SCCM Task for Azure DevOps Pipelines – Visual Studio Marketplace
Mais comment ça marche?
Il vous suffit une fois l’extension installée, de créer un service connection avec les infos de votre serveur SCCM.
Une fois fait, ajoutez et configurez la tâche SCCM Deploy dans votre multipipeline ou votre pipeline de release en utilisant ce service connection et le tour est joué!
La tâche ouvre un remote powershell pour vous à partir de l’agent vers le serveur SCCM puis execute les différentes commandes de publication dans SCCM.
Inutile donc de vous dire que si votre SCCM n’est pas accessible sur le web ce qui serait tout à fait normal, vous aurez besoin de votre propre agent azure devops.
C’est une première version de la tâche qui ne supporte pour l’instant que le déploiement des APPX, le déploiement des MSI sera rendu possible également par la suite avec des améliorations sur la configuration SCCM via la tâche.
Vous avez un soucis ou vous voulez contribuer ? le projet c’est par ici: ioxFR/azure-devops-sccm-task: Azure DevOps Pipeline Task to deploy package to SCCM (github.com)
A bientôt pour un prochain article!
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.
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.
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.
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.
Avant de faire du power automate, il faut avoir connaissance des pré-requis.
Tant qu’a réécrire des workflows, c’est le bon moment aussi pour se poser les bonnes questions:
L’idée est de dresser un inventaire de vos workflows en identifiant les informations suivantes:
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.
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.
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.
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.
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.
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.
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 🙂
Reading Time: < 1 minute
Bonjour à vous,
Microsoft à enfin compris qu’en 2016 du responsive est indispensable. Par le biais du blog office, Microsoft annonce donc la mise à disposition d’un pack Responsive UI pour SharePoint 2013/2016.
Ci dessous un apercu de la vue PC et Mobile:
Le pack est donc disponible ici:Â https://github.com/OfficeDev/PnP-Tools/tree/master/Solutions/SharePoint.UI.Responsive
Et si vous voulez en savoir plus c’est la:Â http://dev.office.com/blogs/announcing-responsive-ui-package-for-sharepoint-on-premises-2013-2016
En espérant que vous profiterez bien de ce pack dans vos projets SharePoint,
En attendant un autre post, SharePointez bien 😉
février 3, 2013 @ 4:18 pm
Super ton nouveau design Valentin !!!
février 3, 2013 @ 4:25 pm
Merci 🙂