Création de workflow avec SharePoint Designer 2007

Cet article vous guide dans la création de workflow avec SharePoint Designer.

Article lu   fois.

L'auteur

Site personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

SharePoint Designer est L'Outil à destination des Web Designer souhaitant customiser au maximum les sites SharePoint.

En plus de pouvoir gérer les sites & pages, SharePoint Designer nous permet également de créer des workflows en réutilisant des taches prédéfinies. Ces workflows vont donc nous permettre d'exécuter tout un processus, pouvant inclure des acteurs externes, en réponse à un évènement particulier.

0. Tour d'horizon des workflow avec SharePoint Designer

Un flux de travail créé avec SharePoint Designer est toujours attaché à une liste ou une doclib.

Lorsqu'il est supprimé, uniquement l'association avec la liste et son état en mémoire le sont ; la définition du workflow cependant demeure dans la doclib dans laquelle il a été stocké.

Les workflow définis avec SharePoint Designer sont stockés au niveau de la doclib « Flux de travail » du site sur lequel ils sont déployés ; cette dernière est créée par SharePoint Designer.

I. Création de notre workflow

I-A. Définition de la problématique

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.

I-B. Création de nos doclibs

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 ».

image

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

I-C. 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

image

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.

image

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 2nde étape.

image

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 ».

image

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

image

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.
image

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.

image

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.

image

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

image

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.

image

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.

image

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.

II. Suppression de Workflow

Il nous est possible de supprimer nos workflows, depuis SharePoint Designer, mais également de les désactiver, depuis le navigateur web.

En désactivant notre workflow, il ne s'exécutera plus jusqu'à sa prochaine activation, et les fichiers le composant seront toujours stockés dans la doclib de workflow. Nous pourrons ensuite le réactiver ultérieurement.

En le supprimant, nous allons en fait supprimer tous les fichiers du serveur, et il ne sera plus disponible.

II-A. Désactivation de notre flux de travail

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.

image
image

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

II-B. Désinstallation de notre 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.

image

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

III. Points Supplémentaires

III-A. Workflow et Event Receiver Part 1

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.

III-B. Workflow et Event Receiver Part 2

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.

III-C. SharePoint Designer ou Visual Studio ?

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.

IV. Conclusion

Au travers de cet article, vous avez pu constater comment il est facile de créer nos workflows avec SharePoint Designer.

Dans cet article, nous nous sommes uniquement attachés à produire des workflows avec des taches prédéfinies ; nous aurions pu également créer nos propres tâches depuis Visual Studio, et les mettre à disposition via SharePoint Designer.

Ainsi le coté fonctionnel avec SharePoint Designer et le coté technique avec Visual Studio s'en trouvent séparés, et mieux que ca, cette séparation permet à nous différents acteurs, développeurs professionnels et Information Worker/Web Designer, de travailler de concert pour une productivité accrue.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2008 Dieudonné N'TAMACK. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.