Création de workflow avec SharePoint Designer 2007

Ici, nous allons créer un workflow que nous allons appeler « Circuit Facturation ».

Ce workflow « simplifié » va nous permettre de réceptionner les factures émises par nos clients, et dérouler tout le processus, jusqu'au paiement de la facture et à la journalisation de celle-ci.

Le workflow que nous allons mettre en oeuvre va utiliser 2 bibliothèques de documents, l'une pour réceptionner nos factures, et l'autre pour les « archiver » une fois qu'elles ont été réglées.

Avant de commencer la mise en ouvre de notre workflow, nous devons tout d'abord créer nos 2 doclibs ; en effet, souvenez-vous, lorsque nous créons nos workflows avec SharePoint Designer, ces derniers sont automatiquement attachés à une liste/doclib.

Etant donné que nous allons attacher notre workflow à la doclib réceptionnant les factures, il nous faudra au préalable créer cette dernière, ici intitulée « Factures Fournisseurs ».

Profitons-en également pour créer la 2^ème, « Factures Payées ».

Une fois ceci effectué, nous sommes parés pour la création de notre workflow dans SharePoint Designer.

Nous allons à présent nous lancer dans la modélisation de notre workflow.

Pour cela, nous allons lancer le workflow designer intégré à SharePoint Designer

Nous allons ensuite lui donner un nom, à savoir « Circuit Facturation », nous allons également l'attacher à notre doclib, et pour terminer, notre workflow ne doit s'exécuter qu'à la réception d'une facture, donc nous devons également sélectionner un démarrage automatique du workflow à la création de nouveaux éléments.

Nous allons ensuite passer à la 1^ère étape de notre flux.

Une étape va être une succession de conditions et d'actions permettant d'aboutir à une finalité.

Ici, nous allons créer une étape dans le but de valider que le document qui nous a été fourni correspond bien aux spécifications qui ont été établi au préalable.

Cette étape, intitulée « Request For validation », va uniquement contrôler que le document qui nous a été transmis respecte bien les critères de base, à savoir que le titre doit comporter le mot «  Facture » et il doit être au format PDF ; si ce n'est pas le cas, nous faisons un message au gestionnaire de l'entreprise, puis nous annulons le workflow en enregistrant un message d'erreur, puis nous allons créer une 2^nde étape.

Ainsi, si le document qui nous a été transmis ne correspond pas aux attentes, le workflow échouera ; si cependant, tout s'est bien passé, nous passerons à l'étape suivante.

Cette nouvelle étape, intitulée « Request For Approbation », va maintenant demander à la comptabilité d'approuver la facture, puis une fois approuvée, de respecter un délai de 30 jours avant de déclencher le paiement et de transférer le document dans la doclib « Factures Payées ».

Nous allons à présent passer à notre dernière étape qui va s'appeler « Finalize », et qui va uniquement journaliser.

Voila, notre workflow est complet.

Maintenant, il ne nous reste plus qu'à vérifier qu'il soit correct.

Tout en bas de la fenêtre du workflow designer, on a plusieurs boutons :

• « Vérifier le flux de travail, nous allons l'utiliser pour vérifier que notre flux ne contient aucune erreur.
• Initiation, ce bouton permet de définir des paramètres qui seront utilisés pour déclencher un workflow manuel ; à ce moment, SharePoint génère un formulaire en fonction des champs qui ont été défini et nous propose de les renseigner.
• Et les classiques suivant, précédent, terminer, annuler.

Une fois cliqué sur le bouton terminé, le workflow est généré, et une nouvelle doclib, contenant la définition de notre workflow, fait son apparition au niveau de mon site.

Cependant, cette doclib n'est visible qu'à partir de SharePoint Designer ; en effet, si on essaye d'accéder à son url, on tombe sur une page Erreur 404 ; d'autre part, si l'on regarde dans le dossier « Forms » de cette doclib, aucun formulaire n'est visible, contrairement aux autres doclibs ou l'on y retrouve les formulaires correspondant aux affichages disponibles ;

En regardant depuis la page « Tout le contenu du site », nous pouvons constater que la doclib « Flux de travail » n'apparait nulle part.

Une fois notre workflow achevé, nous allons pouvoir le démarrer en uploadant un document dans notre doclib « Factures Fournisseurs ».

Lorsque nous consultons le résultat dans la doclib Factures Fournisseurs, nous constatons que le workflow que nous avons défini a déjà été exécuté, sans aucune intervention.

En effet, nous avions paramétré notre workflow pour une exécution automatique, à chaque création.

De même, nous remarquons qu'une nouvelle colonne, portant le nom du workflow a été créée ; cette colonne nous donne des informations sur le déroulement de notre workflow.

Des taches sont également créées par notre workflow.

Maintenant que nous avons vu toutes les étapes de la création de notre workflow, il ne nous reste plus qu'à voir comment le supprimer.

Pour désactiver notre workflow, il nous suffit d'aller dans les paramètres de notre doclib, puis choisir paramètres de flux de travail dans la colonne « Autorisation et Gestion »

Nous sommes ensuite redirigés vers cet écran où nous pouvons choisir de « supprimer » (plutôt désactiver) notre workflow.

Plus tard, nous pourrons à nouveau l'activer en choisisant « Ajouter un flux de travail ».

La désinstallation ou suppression définitive de notre flux de travail n'est possible qu'à partir de SharePoint Designer.

Pour cela, il nous suffit de cliquer droit sur notre doclib Workflows, et ensuite de sélectionner supprimer.

De cette façon, tous les workflows que contient cette doclib seront définitivement supprimés de notre serveur.

Une question qui revient assez fréquemment est le choix entre mettre en oeuvre un workflow et mettre en oeuvre un Event Receiver.

Bien qu'il n'existe pas de réponse absolue, je pense que la réponse se trouve dans la définition du besoin à satisfaire.

Selon moi, vous devriez mettre en oeuvre un workflow si :

• Vous faites intervenir des acteurs humains dans le cadre par exemple de validation,
• Vous avez besoin d'exécuter une action longue,
• Votre action doit prendre en compte les contraintes de la machine ; en effet, même un reboot de la machine ne viendrait pas à bout de votre workflow !
• Vous avez besoin de modéliser un processus.

Et vous devrez mettre en ouvre un item event receiver si :

• Votre action ne fait intervenir aucun acteur extérieur et tout est automatisé,
• Votre action est de courte durée,
• Vous souhaitez exécuter une action particulière, comme annuler toute modification/insertion ou vérifier que le contenu ajouté est valide.

D'autre cas de figure peuvent influencer votre décision, mais je pense que cette (courte) liste est déjà un bon début.

En plus de vous poser des problèmes quant au choix de l'un des 2, ils vont également vous poser des problèmes si jamais vous décidez de mettre en ouvre les 2 !

Comme nous l'avons vu, lorsque vous mettez en ouvre des workflows sur une doclib, une nouvelle colonne est rajoutée au niveau de la liste ; or que se passe-t-il si vous avez implémentez un SPListEventReceiver et que vous avez overridé la méthode FieldAdding en empêchant toute modification du schéma de votre liste ?

Vous devriez être redirigé vers une belle page d'erreur ! Or ce n'est pas le cas. Votre workflow cesse tout simplement de s'exécuter, et la colonne correspondant au statut de votre workflow n'apparait pas. Il semblerait donc que le workflow soit désactivé, cependant, si vous regardez les paramètres du workflow de votre liste, ce dernier est bien présent ! Bref, un dysfonctionnement total.

Alors attention à bien planifier vos actions utilisant les workflows et les Event Receiver.

Nous venons de voir que nous pouvons créer nos workflows depuis SharePoint Designer, mais vous devez surement savoir qu'il nous est aussi possible de passer directement par Visual Studio ; alors la question est quand doit-on choisir entre l'un et l'autre ?

La réponse est tout simplement, tout dépend de votre besoin.

Préférez SharePoint Designer quand :

• Vous devez développer un workflow spécifique à 1 site
• Vous n'avez pas besoin d'exécuter le workflow dans le contexte d'un autre utilisateur (par exemple en utilisant un compte ayant les droits d'administration)
• Un développeur vous a mis à disposition toutes les actions dont vous avez besoin pour concevoir votre workflow (pour savoir comment étendre la liste d'actions disponible dans SharePoint Designer, lisez cet article de Stéphane)

Et n'oubliez pas que si vous utilisez SharePoint Designer, il n'y a pas de migration possible de votre environnement de dev/test vers votre environnement de production ; donc soit vous préparez une maquette, et dans ce cas, vous travaillez sur votre serveur de dev/test, soit vous développez un workflow pour la production, et dans ce cas, vous travaillez directement sur votre site de production.

Le point positif reste quand meme qu'il n'y a pas besoin de compétences de développement particulières pour créer vos workflows aves SharePoint Designer, mais aussi que le développement/déboggage s'en trouvent accélérés.

Préférez Visual Studio quand :

• Vous souhaitez étendre la liste d'actions disponible avec SharePoint Designer
• Vous avez besoin de modéliser des workflows plus complexes
• Vous souhaitez déployer vos workflows de manière plus conventionnelle.

Notez néanmoins que dans ce cas, une bonne connaissance de la couche WF, en plus du fonctionnement de SharePoint s'impose, et que le temps de développement s'en trouve également largement augmenté.

Pour en savoir un peu plus sur le développement de workflows avec Visual Studio, je vous redirige vers cet article de Stéphane.