De nos jours nous avons l’opportunité de créer des workflows devant répondre à des besoins spécifiques.
L’une des galères que rencontre le développeur SharePoint est de devoir modifier les notifications de ses workflows, en générale cela implique de modifier sa définition, de le re-publier et recommencer les tests fonctionnel afin de s’assurer que les modifications n’entraînent pas de dysfonctionnement du système implémenté.
Bien évidement pour répondre à ce besoin, nous avons plusieurs choix techniques d’implémentation de workflow, via SharePoint designer, Visual Studio 2010-2013 ou par une application tiers (K2, Nintex, …).
Ici nous externaliserons nos emails à l’aide de Nintex qui, pour ma part, aide dans la majorité des cas.
Pour plus d’information sur Nintex, je vous invite à visiter leur site : http://www.nintex.com/en-US/Products/Pages/NintexWorkflow.aspx
Etude de cas
Vous avez un workflow d’approbation multi-niveaux du type « state machine » comportant un certain nombre d’envoi d’email aux travers des activités suivantes:
- Send notifiation
- Assign Flexi task
- Assign to-do task
- Request approval
- Request data
- Request review
(Ressemblant à celui ci dessous, par exemple) 
A tout moment, un « power user » doit pouvoir avoir la possibilité de changer le contenu d’une notificaton sans à republier le(s) workflow(s).
Il doit être également possible d’utiliser les propriétés dynamiques que nous offre Nintex (Workflow, Variables, Champs).
Dernier prérequis, la solution choisie doit être réutilisable dans plusieurs workflow Nintex et sans développement spécifique (Farm Solution, Sandbox solution).
Solution
La solution proposé ici, est de créer une activité personnalisée du type « User defined action » (UDA) qui aura pour objectif de mapper des templates html enregistrés dans une liste personnalisée et de renvoyer le résultat de la transcription dans des variables du workflow hôte. 
Comment faire?
Etape 1 : Créer la liste des modèles de notification
Comme tout bon utilisateur finale 😉 vous allez créer une liste du type « Liste Personnalisée » (Custom list) que vous nomerez de la façcon dont vous souhaitez cependant celle-ci devra au minimum comporter les champs suivants.
- Template name (Title)
- Subject – Multiple line of text (
Rich text) - Body – Multiple line of text (
Rich text)
Bien évidemment le tout peut être traduit en Français pour les récalcitrants.
Etape 2 : Créer l’UDA Nintex
- Ouvrir la page d’administration des UDA de Nintex. Site Actions > Nintex Workflow 2010 > Manage User Defined Actions
- Cliquer sur le bouton « Create » dans le ruban sous l’onglet « Manage User Defined Actions »
- Ouvrir la popup de configuration des paramètres de l’UDA.
- Ajouter les paramètres d’entrées/sortie comme ci-dessous.
Name Type Options I/O Body Text Multi line Output Suject Text Multi line Output Template name Text Single line Input 
- Ajouter une activité « Query List » qui servira à récupérer le modèle HTML.
- Configurer la query list comme indiqué ci-dessous.
- Ajouter 2 « Build string » respectivement pour le sujet et le corps du message qui auront la lourde tâche de transcrire les variables dynamiques. Puis les configurer de la manière suivante:
Attention: Assurez vous que la case « Parse for tokens twice » est bien coché, c’est elle qui fera tout le travail pour nous. - Vous devriez obtenir quelque chose de la sorte:
- Pour terminer, publiez l’UDA sous le nom que vous souhaiterez.
Etape 3: Utilisation
Ajout de l’activité dans un workflow
Une fois l’UDA publié, Nintex vous le proposera dans l’interface de design des workflows. 
Par la suite, il ne vous restera plus qu’a définir les variables qui recevront le sujet et le corps du message basé sur votre modèle. 
Configuration d’un modèle
Pour cela, il vous faudra aller dans votre liste et ajouter les modèles dont vous aurez besoin. Exemple:
Limitations
L’utilisation de ce mécanisme à ses avantages:
- Centraliser l’ensemble des modèles de notification email pour tout vos workflows,
- Faire des modifications à la volé sans redéployer quoi que ce soit,
- Utiliser le versionning pour garder une trace de vos modèles,
- Déléguer la gestion des emails aux utilisateurs avancés
Mais aussi un inconvénient:
Il sera Impossible d’utiliser les tokens dynamiques des activités du type « Task », car l’UDA fait un « parse token twice » pour les remplacer par les valeurs attendues et ne peut être effectué dans celles-ci puisque cette fonctionnalité n’est pas disponible (ce qui à l’avenir, j’espère, sera implémenté). Exemple de tokens non fonctionnel:
- Approval URL ({Common:ApprovalUrl}) ,
- Approver Name ({Common:ApproverName}),
- Approver’s Manager ({Common:ApproversManager})
Conclusion
Cette solution à mettre en place est assez simple et donne beaucoup d’effet si on y passe un peut de temps, autrement en terme de temps pour mettre au point le système fonctionnellement parlant, il faut compter environs 2 heures (sans tuto).
Ayant déjà effectué cette exercice sous Visual Studio pour un Workflow de newsletter, en terme de maintenabilité, de compatibilité (sur des versions ultérieurs de SharePoint) et de temps, vous serez gagnant sur tous les aspects.
En y passant jusqu’à une journée vous pourrez être inventif afin de rendre accessible les modifications et visualisations des modèles, voici un exemple récemment fait:
@ Bientôt.
Vladimir Herrlein - Blog Microsoft 
Laisser un commentaire