Présentation aux développeurs des flux de travail pour Windows SharePoint Services 3.0 et SharePoint Server 2007

Paru le 27 mars 2007

Résumé : Faites-vous une idée précise de la manière dont Microsoft SharePoint Services 3.0 implémente les fonctionnalités de flux de travail de Windows Workflow Foundation et de la manière dont Microsoft Office SharePoint Server 2007 étend fonctionnalités avec des formulaires Microsoft Office InfoPath 2007 symétriques. (28 pages imprimées)

Andrew May, Microsoft Corporation

Mai 2006

S'applique à : Microsoft Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007

Developer Overview: Workflows for Windows SharePoint Services 3.0 and SharePoint Server 2007 

Sur cette page

Présentation des flux de travail
Architecture des flux de travail
Types de flux de travail
Composition des flux de travail
Balisage des flux de travail
Flux de travail dans Windows SharePoint Services et SharePoint Server 2007
Création de flux de travail SharePoint
Création de flux de travail SharePoint dans Visual Studio 2005
Création de flux de travail SharePoint dans SharePoint Designer 2007
Comparaison de Visual Studio 2005 Designer for Windows Workflow Foundation et SharePoint Designer 2007
Structure des flux de travail dans Windows SharePoint Services
Utilisation de l'espace de noms du flux de travail
Conclusion
Ressources supplémentaires

Présentation des flux de travail

Microsoft Windows SharePoint Services propose un environnement de travail robuste et personnalisable permettant aux utilisateurs de créer, collaborer et enregistrer les informations importantes de l'entreprise. Grâce à Microsoft Windows SharePoint Services 3.0 et Microsoft Office SharePoint Server 2007, vous pouvez désormais joindre des processus métier personnalisés à ces documents ou éléments de liste.

Vous pouvez représenter ces processus métier personnalisés à l'aide de flux de travail. Un flux de travail est une façon naturelle d'organiser et exécuter une série d'unités de travail ou d'activités pour former une représentation exécutable d'un processus de travail. Ce processus peut contrôler presque tous les aspects d'un élément dans Windows SharePoint Services, y compris le cycle vie de cet élément. Le flux de travail est suffisamment flexible pour modéliser les fonctions de système et les actions humaines nécessaires à la réalisation du flux de travail.

Vous pouvez créer des flux de travail simples ou complexes en fonction des besoins de vos processus métier. Vous pouvez créer des flux de travail qui sont initiés par l'utilisateur ou qui sont automatiquement initiés par Windows SharePoint Services en fonction d'un événement, tel que la création ou la modification d'un élément.

Supposons que vous devez créer un flux de travail simple qui envoie un document à une série d'utilisateurs pour approbation ou commentaires. Ce flux de travail inclut des actions que le système doit exécuter et fournit les interfaces nécessaires pour l'interaction des utilisateurs avec le flux de travail, comme indiqué. Par exemple, Windows SharePoint Services envoie un message électronique aux utilisateurs sélectionnés lorsque le document est prêt à la révision. Ces utilisateurs doivent ensuite pouvoir notifier Windows SharePoint Services de la fin de leur révision et entrer des commentaires le cas échéant. L'infrastructure de flux de travail comprise dans Windows SharePoint Services 3.0 puis étendue dans SharePoint Server 2007 vous permet de modéliser ces processus de travail complexes et de les présenter aux utilisateurs finaux dans un contexte simple et rapide à comprendre qui les guide pas à pas.

Cet article fournit une vue d'ensemble de haut niveau des flux de travail, tels qu'ils sont implémentés dans Windows SharePoint Services et étendus dans SharePoint Server. Il inclut une discussion sur les outils de développement disponibles pour créer des flux de travail dans les deux environnements, ainsi que les capacités et les avantages respectifs de ces outils.

Architecture des flux de travail

La fonctionnalité de flux de travail dans Windows SharePoint Services 3.0 est basée sur Windows Workflow Foundation (WF), un composant de plate-forme Microsoft Windows proposant une infrastructure de programmation et des outils de développement et exécution d'applications basées sur les flux de travail. Le composant WF simplifie le processus de programmation asynchrone pour créer des applications de flux de travail à long terme, durables et persistantes. Le moteur d'exécution de WF gère l'exécution des flux de travail et leur permet de rester actifs à long terme et de résister à un redémarrage de l'ordinateur. Les services d'exécution proposent des fonctions de transaction et de persistance pour la gestion correcte des erreurs.

Le moteur d'exécution de WF propose les services nécessaires à toute application de flux de travail, tels que le séquencement, la gestion de l'état, le suivi des opérations et la prise en charge des transactions. Le moteur d'exécution WF joue le rôle d'une machine d’état responsable du chargement et du déchargement des flux de travail et de la gestion de l'état actuel de tout flux de travail en cours d'exécution. Le composant WF permet à n'importe quel processus d'application ou conteneur de service d'exécuter des flux de travail en hébergeant WF, c'est-à-dire, en chargeant WF dans son processus.

Windows SharePoint Services héberge le moteur d'exécution de WF. À la place des services enfichables inclus avec WF, Windows SharePoint Services fournit des implémentations personnalisées des services suivants pour le moteur : transaction, persistance, notifications, rôles, suivi et messagerie. Les développeurs peuvent ensuite créer des solutions de flux de travail qui s'exécutent dans Windows SharePoint Services.

La figure 1 montre l'architecture du flux de travail dans Windows SharePoint Services. Windows SharePoint Services héberge le moteur d'exécution de WF dans son processus et fournit des implémentations personnalisées des services nécessaires. Le fonctionnement du moteur d'exécution de WF, ainsi que la fonctionnalité d'hébergement proposée par Windows SharePoint Services, sont décrits via le modèle d'objet de Windows SharePoint Services.

Figure 1. Architecture de flux de travail dans Windows SharePoint Services 3.0

Windows Workflow Foundation propose également Visual Studio 2005 Designer for Windows Workflow Foundation, un complément hébergé dans le système de développement Microsoft Visual Studio 2005 qui permet aux développeurs de créer leurs propres flux de travail et activités de flux de travail personnalisés. Pour plus d'informations, reportez-vous à la section Création de flux de travail SharePoint dans Visual Studio 2005.

SharePoint Server utilise la fonctionnalité de flux de travail dans Windows SharePoint Services 3.0 et étend cette fonctionnalité par intégration avec des formulaires InfoPath et d'autres activités de flux de travail. Ce sujet est traité plus en détail dans la section Création de flux de travail SharePoint dans SharePoint Designer 2007.

Le moteur d'exécution de Windows Workflow Foundation est disponible en téléchargement en tant que composant de Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 et Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2 sur le site Web du Centre de téléchargement Microsoft. Ce téléchargement contient également Visual Studio 2005 Designer for Windows Workflow Foundation ainsi que le kit de développement logiciel (SDK) Windows Workflow Foundation.

Maintenant que nous avons décrit brièvement l'infrastructure du flux de travail fourni dans Windows SharePoint Services, examinons la composition et la structure internes d'un flux de travail WF. Nous examinerons ensuite les divers outils de développement fournis par Microsoft pour la création de solutions de flux de travail pour Windows SharePoint Services et SharePoint Server 2007.

Persistance de flux de travail

L'un des services les plus importants offerts par Windows SharePoint Services au moteur de flux de travail WF est le service de persistance. Les flux de travail qui incluent l'interaction humaine sont, par nature, de longue durée ; même dans les meilleures conditions, les êtres humains mettent généralement plus de temps que les machines à réaliser une tâche. Dans de nombreux scénarios Microsoft Office, les flux de travail requièrent en général plusieurs jours. Prenez, par exemple, le flux de travail de routage de documents pour l'approbation. L'approbateur peut passer plusieurs jours à réviser le document.

Il n'est pas pratique de conserver en mémoire chaque flux de travail en cours d'exécution, car la quantité de ressources requises par l'accumulation des flux de travail entraînerait l'arrêt du système.

À la place, lorsqu'une instance de flux de travail a atteint un point auquel il a besoin de l'interaction utilisateur, Windows SharePoint Services décharge cette instance de flux de travail de la mémoire et conserve ses données. Ensuite, lorsqu'un événement approprié tel que l'interaction utilisateur requiert le démarrage de l'instance de flux de travail, Windows SharePoint Services recrée l'instance de flux de travail à l'aide des données conservées afin que cette instance puisse recevoir et gérer l'événement selon le cas.

Bien que de nombreuses instances de flux de travail puissent s'exécuter à un moment donné, il est probable que seule une fraction de ces flux de travail soit en mémoire et utilise des ressources système.

Types de flux de travail

Windows Workflow Foundation prend en charge deux styles de base de flux de travail :

• Flux de travail séquentiels Représentent un flux de travail sous forme d'une série d'étapes qui exécutent les activités dans un ordre défini. Toutefois, l'exécution des flux de travail séquentiels n'est pas purement séquentielle. L'ordre exact de leur exécution peut varier car ils peuvent recevoir des événements externes et inclure des flux logiques parallèles.

• Flux de travail de machine d'état Représentent un ensemble d'états, de transitions et d'actions. Un état est désigné comme l'état de démarrage, puis, en fonction d'un événement, une transition peut s'effectuer vers un autre état. La machine d'état peut avoir un état final qui détermine la fin du flux de travail.

Vous pouvez créer des flux de travail des deux types pour Windows SharePoint Services et SharePoint Server.

Flux de travail séquentiels

Les flux de travail séquentiels sont mieux représentés graphiquement sous forme d'un organigramme d'actions, avec un début, une fin et un sens de flux séquentiel du début à la fin. Les flux de travail séquentiels peuvent incorporer des structures de flux (répétition, boucle et branches parallèles) mais doivent finalement évoluer de l'action initiale vers l'action finale.

Par exemple, supposez que vous traciez le graphique du flux de travail de routage d'un document dans Windows SharePoint Services pour l'approbation. Au démarrage du flux de travail, le système notifie le réviseur spécifié, par message électronique, du document à réviser. Le réviseur révise le document et informe le système de l'accomplissement de la tâche ainsi que de l'approbation ou du rejet du document. Selon la réponse du réviseur, le flux de travail exécute l'une de deux branches parallèles. Si le réviseur a approuvé le document, le système transfère le document approuvé vers une bibliothèque de documents SharePoint spécifique, puis envoie un message électronique à l'équipe entière pour lui signaler que le document a été approuvé. Si le réviseur rejette le document, le système notifie l'auteur du document. Dans les deux cas, le flux de travail atteint sa fin et se termine. La figure 2 montre ce flux de travail.

Figure 2. Diagramme conceptuel d'un flux de travail séquentiel

Flux de travail de machine d'état

Contrairement aux flux de travail séquentiels, les flux de travail de machine d'état n'ont pas un flux d'exécution prescrit et ne requièrent pas une fin. À la place, les flux de travail de machine d'état définissent un nombre quelconque d'états qu'un élément peut habiter et les événements qui font passer l'élément d'un état à un autre.

La figure 3 représente un processus de publication de document simple, modélisé comme un flux de travail de machine d'état. Le flux de travail est établi à la création un document et se termine lorsque l'état de document est défini comme étant terminé. Entre temps, toutefois, le document ne suit pas un chemin prédéfini mais passe d'un état à un autre à mesure que les événements surviennent.

Le flux de travail de machine d'état est composé d'activités d'état. Chaque activité d'état représente un état de l'élément. Chaque activité d'état peut contenir un état facultatif d'initialisation, de finalisation et un ou plusieurs gestionnaires d'événements. Chaque activité de gestionnaire d'événements peut gérer un événement. En réponse à l'événement géré, un certain degré de traitement peut être effectué, et une transition vers un autre état accomplie.

Figure 3. Diagramme conceptuel d'un flux de travail de machine d'état

Une caractéristique des flux de travail séquentiel et de machine d'état consiste à décomposer chaque type de séquence de flux de travail en un ensemble d'actions discrètes, celles exécutées par le système, et celles prises par les utilisateurs. Vous pouvez considérer ces actions comme les blocs de construction des flux de travail. Dans les flux de travail WF, ces actions sont appelées activités.

Composition des flux de travail

Plus haut, nous avons défini un flux de travail comme une façon d'organiser et exécuter une série d'unités de travail ou d'activités pour former une représentation exécutable d'un processus de travail. Chaque flux de travail WF consiste donc en une série d'activités associées. Une activité est l'unité élémentaire de modelage, programmabilité, réutilisation et exécution dans Windows Workflow Foundation. Une activité peut être exécutée par le système ou par un utilisateur. Par exemple, le système peut envoyer un message électronique en tant qu'alerte ; ou une personne peut approuver un document pour la distribution.

Sur le plan conceptuel, notre exemple de flux de travail séquentiel inclut cinq activités :

• envoi d'un message électronique pour notifier l'approbateur ;

• approbation ou rejet du document ;

• transfert du document vers la bibliothèque de documents « approuvés » ;

• envoi d'un message électronique pour notifier l'équipe ;

• envoi d'un message électronique pour notifier l'auteur du document.

Les activités peuvent également représenter des structures de contrôle logiques qui définissent l'étendue et dirigent le flux d'exécution du flux de travail, de la même manière que les contrôles logiques de code, tels que If Then et les boucles Do While, contrôlent le flux de programme dans le code.

Les activités peuvent présenter des propriétés, des méthodes et des événements. Les activités simples exécutent une seule unité de travail, telle que « retenir pendant 1 jour » ou « invoquer le service Web ». Les activités composites contiennent d'autres activités ; par exemple, une unité conditionnelle avec deux branches. Vous pouvez également rattacher des gestionnaires, tels que des gestionnaires d'erreurs ou de compensation, aux activités. Cela est notamment recommandé pour les activités composites.

Essentiellement, le flux de travail lui-même est simplement une activité composite qui contient toutes les autres activités de ce flux de travail.

Par conséquent, le flux de travail peut apparaître comme un ensemble d'activités enregistrées sous forme de modèle qui décrit un processus réel. Le travail passe par le modèle du début à la fin, et les activités peuvent être exécutées par des personnes ou par des fonctions système. Le flux de travail propose une manière de décrire l'ordre d'exécution et les relations dépendantes entre des éléments de travail de courte durée ou de longue durée.

Windows Workflow Foundation inclut plusieurs activités prédéfinies que vous pouvez utiliser dans vos flux de travail ; vous pouvez également créer des activités personnalisées. Le pack de modèle de projet de flux de travail Windows SharePoint Services contient de nombreuses activités conçues explicitement pour l'utilisation dans l'environnement Windows SharePoint Services. Le pack de modèle contient également les références nécessaires à la programmation sur le modèle d'objet Windows SharePoint Services. De même, le pack de modèle de projet SharePoint Server est personnalisé pour l'utilisation dans l'environnement SharePoint Server. Pour plus d'informations, reportez-vous à la section Création de flux de travail SharePoint dans Visual Studio 2005.

Balisage des flux de travail

Chaque flux de travail WF peut être représenté par les combinaisons de fichiers suivantes :

• un fichier XML ou un fichier de balisage qui inclut les métadonnées déclaratives du flux de travail ;

• le fichier de balisage, combiné à un fichier code-behind qui contient le code personnalisé représentant les propriétés et le comportement du flux de travail ;

• un fichier de code (ou plusieurs) qui inclut la logique déclarative et le comportement du flux de travail.

Le fichier de balisage est écrit en XAML (Extensible Application Markup Language), avec un schéma publié auquel le fichier doit adhérer, et avec une extension de fichier .xoml.

Etant donné que le XAML a un schéma publié, vous pouvez créer des fichiers XAML à l'aide de tout éditeur de texte ou XML. Cependant, les deux outils de création de flux de travail abordés dans cet article, Visual Studio 2005 Designer for Windows Workflow Foundation et Microsoft Office SharePoint Designer 2007, proposent aux développeurs une interface graphique dans laquelle ils peuvent créer des flux de travail et générer automatiquement le fichier de balisage approprié.

Les développeurs peuvent choisir d'intégrer ou séparer leur métadonnées déclaratives de la logique métier comprise dans le flux de travail. Sur le plan conceptuel, le paradigme de « séparation de code » que les flux de travail WF utilisent est similaire à celui qui est utilisé dans Microsoft ASP.NET : les métadonnées déclaratives sont séparées du fichier qui encapsule votre logique métier. Même si le fichier de balisage contient les métadonnées pour les activités dans le flux de travail, les propriétés et les comportements de ces activités sont détaillés dans un fichier séparé.

Pour les flux de travail créés à l'aide de la séparation de code, les informations sont enregistrées dans le fichier de balisage, comme indiqué précédemment, ainsi que dans l'un des deux types de fichiers suivants :

• Un fichier code-beside contenant le code qui encapsule votre logique métier. Ce fichier peut être écrit en Microsoft Visual C# ou Microsoft Visual Basic .NET.

• Un fichier de règles de flux de travail qui encapsule votre logique métier dans des règles déclaratives, au lieu de code.

Chaque flux de travail créé de cette manière est en fait un type Microsoft .NET unique, construit à partir de deux classes partielles qui sont représentées par le XOML et un fichier code-behind ou de règles. Lorsque le projet de flux de travail est compilé, ces deux classes partielles sont combinées en un assembly .NET. Telle est l'approche que vous prenez lors de la création de flux de travail pour Windows SharePoint Services ou SharePoint Server à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation.

Les flux de travail composés uniquement de fichiers de code suivent le même processus général de compilation : les fichiers de code sont compilés en type .NET.

De plus, vous pouvez compiler des flux de travail composés uniquement de fichiers de balisage. Cependant, ce processus n'est pas nécessaire; le moteur d'exécution WF peut charger et exécuter des flux de travail de balisage compilés. Vous décidez de cette approche lors de la création de flux de travail pour Windows SharePoint Services ou SharePoint Server à l'aide de SharePoint Designer 2007.

Flux de travail dans Windows SharePoint Services et SharePoint Server 2007

Jusqu'à présent, nous avons abordé les attributs de flux de travail pour toute application qui implémente Windows Workflow Foundation. Observons à présent de plus près les flux de travail tels qu'ils sont implémentés dans Windows SharePoint Services en particulier et abordons les aspects importants de cette implémentation.

Modèles et instances de flux de travail

Dans Windows SharePoint Services, les flux de travail disponibles sur un site ou une liste sont appelés modèles de flux de travail ; un flux de travail en cours d'exécution sur un élément SharePoint spécifique est appelé une instance de flux de travail . Ainsi, sur une liste donnée, plusieurs instances d'un même modèle de flux de travail peuvent s'exécuter en même temps, chacune sur un différent élément SharePoint. Plusieurs flux de travail peuvent s'exécuter en même temps sur un élément SharePoint donné.

Vous pouvez exécuter des flux de travail sur des documents ou des éléments de liste. Vous rendez un modèle de flux de travail disponible sur un site par un processus appelé association, abordé plus loin dans cet article.

Utilisation de formulaires pour activer l'interaction utilisateur avec Windows SharePoint Services

Bien que vous puissiez utiliser les flux de travail Windows SharePoint Services pour modéliser un nombre quelconque de processus métier uniques, il existe plusieurs étapes courantes au niveau desquelles l'utilisateur peut interagir avec le modèle ou l'instance de flux de travail.

Afin que l'utilisateur puisse transmettre des informations au flux de travail, le développeur doit fournir une interface pour cette interaction via un formulaire. L'ajout de formulaires aux flux de travail vous permet de rendre vos flux de travail plus dynamiques et flexibles. Les formulaires vous permettent de réunir des informations des utilisateurs à des moments prédéfinis dans la vie d'un flux de travail et permettent également aux utilisateurs d'interagir avec les tâches de ce flux de travail.

Techniquement, vous pouvez employer toute technologie de formulaire avec les flux de travail WF, tant que vos formulaires sont capables de réaliser les tâches suivantes :

• invoquer le modèle d'objet Windows SharePoint Services ;

• générer les données nécessaires à envoyer au modèle d'objet Windows SharePoint Services ;

• recevoir et analyser les données requises du modèle d'objet Windows SharePoint Services.

Toutes les informations transmises au formulaire au moment du chargement prennent la forme d'une chaîne, comme les données que le formulaire doit renvoyer au modèle d'objet Windows SharePoint Services 3.0 lorsque l'utilisateur soumet le formulaire. Cette chaîne est généralement au format XML, mais vous pouvez utiliser un autre format de données pouvant prendre une forme de chaîne, à condition que votre formulaire puisse générer des chaînes dans ce format et analyser les chaînes qu'il reçoit.

Windows SharePoint Services prend en charge l'utilisation de formulaires ASP.NET 2.0. La méthode d'implémentation de ces formulaires dépend de l'utilisation de Visual Studio 2005 Designer for Windows Workflow Foundation ou de SharePoint Designer 2007 par le développeur comme outil de création de flux de travail. De plus, SharePoint Server 2007 offre aux développeurs la capacité d'intégrer des formulaires Microsoft Office InfoPath à leurs flux de travail. Ces formulaires InfoPath peuvent être hébergés dans les applications clientes Microsoft Office, telles que Microsoft Office Word, Microsoft Office PowerPoint, Microsoft Office Excel et InfoPath, ainsi que le navigateur client, et fournir une expérience client plus riche. Pour plus d'informations sur la méthode d'implémentation des formulaires de flux de travail par les différents outils de création de flux de travail, reportez-vous aux sections Formulaires ASP.NET dans les flux de travail Windows SharePoint Services, Formulaires InfoPath dans les flux de travail SharePoint Server et Formulaires ASP.NET dans les flux de travail SharePoint Designer.

Quelle que soit la technologie de formulaire utilisée, l'opération conceptuelle de chaque formulaire est la même. Windows SharePoint Services affiche le formulaire à l'utilisateur au moment approprié dans le flux de travail. L'utilisateur entre des informations, puis soumet le formulaire.

En tant que développeur de flux de travail, vous devez décider de ce qui se produit lorsque l'utilisateur soumet un formulaire. Dans la plupart des cas, votre formulaire appelle le modèle d'objet Windows SharePoint Services et invoque la méthode appropriée pour la transmission des informations du formulaire à l'instance de flux de travail correcte.

La chaîne d'information peut être dans n'importe quel format, à condition que le formulaire et l'activité de flux de travail puissent analyser la chaîne. Dans la plupart des cas, les développeurs choisissent le format XML.

Windows SharePoint Services transmet les informations de la chaîne au moteur d'exécution de WF, à l'instance de flux de travail, et enfin à l'activité correcte dans l'instance de flux de travail. L'activité recevant les informations peut alors répondre selon sa programmation. La figure 4 montre comment un formulaire est intégré à un flux de travail.

Figure 4. Intégration d'un formulaire au flux de travail

Trois types de formulaires sont utilisés dans les flux de travail Windows SharePoint Services :

• Formulaires d'association et d'initialisation Les formulaires d'association et d'initialisation sont affichés et doivent être remplis par les utilisateurs avant le démarrage d'un flux de travail. Vous pouvez utiliser ces formulaires pour permettre aux utilisateurs de définir des paramètres et d'autres informations concernant le flux de travail avant son démarrage.

• Formulaires de modification Les modifications sont des options que vous présentez aux utilisateurs pour modifier le flux de travail au cours de son exécution sur un élément. Vous pouvez ensuite créer des formulaires de modification qui permettent aux utilisateurs de spécifier les paramètres de la modification.

• Formulaires de tâche Vous pouvez également spécifier des formulaires personnalisés pour les tâches dans votre flux de travail, selon le type de tâche du flux de travail. Un type de contenu est affecté à chaque type de tâche de flux de travail dans Windows SharePoint Services ; la définition du type de contenu détermine si un formulaire personnalisé est spécifié pour un type de tâche de flux de travail donné.

Ces trois types de formulaires représentent les étapes prédéfinies au niveau desquelles les utilisateurs peuvent interagir avec le flux de travail. Nous allons, à présent, aborder ces étapes.

Points d'interaction utilisateur avec les flux de travail

Regardons de plus près les différentes étapes au niveau desquelles les utilisateurs peuvent interagir avec les flux de travail dans SharePoint Services et SharePoint Server.

Association

L'association survient lorsqu'un administrateur de site rend disponible le modèle de flux de travail sur une bibliothèque de documents, une liste ou un type de contenu spécifiques. À cette étape, l'administrateur de site personnalise le flux de travail pour cette bibliothèque de documents, cette liste ou ce type de contenu précis en indiquant les informations de paramètre suivantes :

• un nom unique pour le flux de travail ;

• la méthode d'application du flux de travail à un élément donné : automatiquement lors de la création ou modification de l'élément, ou manuellement ; et les rôles, tels qu'Administrateur ou Collaborateur, qui peuvent démarrer un flux de travail.

• la liste de tâches dans laquelle le flux de travail peut créer des tâches ;

• l'historique dans lequel le flux de travail peut enregistrer des événements, comme défini par le flux de travail.

De plus, le développeur du flux de travail peut activer l'administration de site pour personnaliser encore davantage le flux de travail en définissant les informations de paramètre spécifiques au flux de travail. L'administrateur devra spécifier des paramètres, des valeurs par défaut ainsi que d'autres informations pour le flux de travail selon les éléments sur la liste, la bibliothèque ou le type de contenu correspondant.

L'association d'un flux de travail survient hors du flux de travail ; aucune instance de flux de travail ne démarre pendant l'association. À la place, Windows SharePoint Services enregistre les informations d'association dans un tableau d'association de flux de travail interne spécial. Ensuite, lorsque l'instance de flux de travail est démarrée, Windows SharePoint Services utilise les données d'association (ainsi que les données de lancement, le cas échéant) pour définir les paramètres de la nouvelle instance de flux de travail.

Initiation

Alors que l'association traite le flux de travail tel qu'il s'applique à une liste, une bibliothèque ou un type de contenu spécifiques, l'initiation traite le flux de travail tel qu'il s'applique à un élément SharePoint spécifique.

L'initiation survient lorsqu'un utilisateur démarre une instance de flux de travail sur un élément spécifique. L'utilisateur fournit des informations appartenant à ce flux de travail spécifique sur cet élément, le cas échéant, puis démarre le flux de travail.

Les développeurs de flux de travail peuvent utiliser l'initiation pour permettre aux utilisateurs de remplacer ou d'ajouter les paramètres d'association définis par les administrateurs, ou de spécifier des paramètres ou informations supplémentaires sur le flux de travail tel qu'il s'applique à l'élément SharePoint donné. Les flux de travail ne requièrent pas tous d'initiation. En réalité, un flux de travail devant démarrer automatiquement ne peut pas comporter de paramètres d'initiation.

Le projet de flux de travail SharePoint Services pour Visual Studio 2005 Designer for Windows Workflow Foundation inclut une activité qui sert de gestionnaire d'événements lors de l'initiation du flux de travail. Cette activité est la première dans tout flux de travail Windows SharePoint Services.

Modification

Les utilisateurs peuvent modifier les paramètres ou le flux d'un flux de travail pendant son exécution. En tant que développeur, vous voudrez identifier certains points de modification pour les utilisateurs pendant l'exécution d'un flux de travail sur un élément. Par exemple, vous voudrez permettre à un utilisateur d'affecter une tâche à une autre personne ou d'ajouter une tâche spécifique au flux de travail. Les options que vous présentez aux utilisateurs pour modifier le flux de travail au cours de son exécution sur un élément sont des modifications.

Le projet de flux de travail Windows SharePoint Services pour Visual Studio 2005 Designer for Windows Workflow Foundation inclut une activité permettant une modification de flux de travail, ainsi qu'une activité servant de gestionnaire d'événements lorsqu'une modification de flux de travail est activée.

Tâches

Les activités de flux de travail effectuées par des personnes sont représentées comme des tâches dans les flux de travail Windows SharePoint Services.

En tant qu'auteur de flux de travail, vous pouvez spécifier le schéma de tâches. Par exemple, la liste de tâches peut inclure les éléments suivants :

• Titre de la tâche

• Nom de la personne à laquelle la tâche est affectée

• État de la tâche

• Priorité de la tâche

• Date d'achèvement de la tâche

• Lien vers l'élément référencé

L'utilisateur peut ensuite modifier la tâche le cas échéant. L'instance de flux de travail est notifiée des modifications apportées aux tâches du flux de travail et peut choisir d'y répondre comme spécifié dans le flux de travail.

Le projet de flux de travail Windows SharePoint Services pour Visual Studio 2005 Designer for Windows Workflow Foundation inclut des activités de création, suppression et mise à jour de tâches, ainsi que des activités agissant comme des gestionnaires d'événements lorsque les tâches sont créées, mises à jour ou supprimées.

Création de flux de travail SharePoint

Microsoft propose deux outils de développement pour la création de flux de travail pour Windows SharePoint Services : Visual Studio 2005 Designer for Windows Workflow Foundation et Office SharePoint Designer 2007. Ces outils de création génèrent des flux de travail avec des attributs et des capacités différents. Il est donc judicieux d'examiner ces deux outils en détail.

La figure 5 montre les différentes étapes à effectuer pour créer, déployer, associer et exécuter un flux de travail avec chaque outil. En général, les plus grandes différences entre les deux outils sont les suivantes :

• La création de flux de travail dans Visual Studio 2005 Designer for Windows Workflow Foundation est effectuée par un développeur professionnel qui crée un modèle de flux de travail pouvant être déployé sur plusieurs sites et qui contient du code et des activités personnalisés. Le développeur transmet ensuite le modèle de flux de travail à un administrateur serveur pour le déploiement et l'association.

• La création de flux de travail dans SharePoint Designer est effectuée très probablement par quelqu'un d'autre qu'un développeur professionnel, par exemple, par un concepteur de sites Web ou un « gestionnaire de connaissances » qui veut créer un flux de travail pour une liste ou une bibliothèque de documents spécifiques. Dans ce cas, le concepteur est limité aux activités de flux de travail sur la liste de contrôles sécurisée, et le flux de travail ne peut pas inclure un code personnalisé. L'auteur du flux de travail déploie le modèle de flux de travail directement vers la liste ou la bibliothèque de documents comme partie du processus de création du flux de travail.

Pour une comparaison détaillée des capacités des deux outils, reportez-vous à la section Comparaison de Visual Studio 2005 Designer for Windows Workflow Foundation et SharePoint Designer 2007.

Figure 5. Création, déploiement et processus d'initiation de flux de travail

Création de flux de travail SharePoint dans Visual Studio 2005

Visual Studio 2005 Designer for Windows Workflow Foundation est un complément pour Visual Studio 2005. Il fournit un moyen de développer rapidement des flux de travail à l'aide d'une interface graphique qui utilise les connaissances d'un développeur d'environnement de développement Visual Studio.

Visual Studio 2005 Designer for Windows Workflow Foundation est un outil vous permettant de créer rapidement le flux de travail d'une manière intégrée au développement du code encapsulant vos processus métier. Pour cela, Visual Studio 2005 Designer for Windows Workflow Foundation fournit une interface graphique dotée de contrôles intuitifs, hébergée dans l'environnement de développement Visual Studio habituel. Les fonctionnalités suivantes sont présentes :

• Une surface de conception par glisser-déposer vous permettant d'assembler des flux de travail personnalisés à partir d'activités de flux de travail prédéfinis que vous tirez de la boîte à outils.

• Une interface vous permettant de travailler sur votre balisage de flux de travail à l'aide d'outils graphiques intuitifs.

• Intégration avec la fenêtre Propriétés, permettant aux développeurs de configurer des propriétés d'activités de flux de travail par l'interface graphique ou directement dans le fichier code-beside, et de toujours conserver la synchronisation des deux supports.

• Débogage de vos flux de travail en vous connectant au processus Windows SharePoint Services et en insérant des points d'arrêt dans le flux de travail.

• Capacité d'ajouter des gestionnaires d'erreur, de compensation et d'événements aux activités et de placer des activités graphiquement en commentaire.

Visual Studio 2005 Designer for Windows Workflow Foundation est disponible en téléchargement en tant que composant de Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 et Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2 sur le site Web du Centre de téléchargement Microsoft. Ce téléchargement contient également le moteur d'exécution Windows Workflow Foundation, ainsi que le Kit de développement de logiciels Windows Workflow Foundation.

Pour mieux vous aider à développer votre de flux de travail, Microsoft propose deux packs de modèles de projet Visual Studio que vous pouvez utiliser avec Visual Studio 2005 Designer for Windows Workflow Foundation : l'un est spécifique aux flux de travail Windows SharePoint Services et l'autre est personnalisé pour la création de flux de travail SharePoint Server.

Le modèle de projet de flux de travail Windows SharePoint Services contient une référence à l'espace de noms Windows SharePoint et inclut des activités de flux de travail personnalisées conçues spécifiquement pour l'environnement Windows SharePoint Services. Ces activités personnalisées vous permettent d'exécuter des fonctions courantes dans l'environnement Windows SharePoint Services, telles que la création, la mise à jour, la réalisation et la suppression de tâches SharePoint, l'envoi de messages électroniques et l'activation des modifications dans le flux de travail.

Le projet de flux de travail SharePoint Server contient tous les éléments du modèle de projet de flux de travail Windows SharePoint Services, ainsi qu'une référence à l'espace de noms SharePoint Server et une fonctionnalité supplémentaire pour gérer des tâches de flux de travail dans l'environnement de travail SharePoint Server.

Processus de développement de flux de travail dans Visual Studio

En général, lorsque vous développez des flux de travail Windows SharePoint Services ou Office SharePoint Server à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation, vous effectuez les étapes de base suivantes :

• Création de votre flux de travail, y compris le fichier code-beside le cas échéant, dans Visual Studio 2005 Designer for Windows Workflow Foundation.

• Conception et publication de formulaires à utiliser avec votre flux de travail.

• Création du fichier de définition de la fonctionnalité et du modèle de flux de travail, qui contient des informations sur l'assembly du flux de travail et lie les formulaires à l'assembly du flux de travail.

• Compilation des fichiers de flux de travail en un assembly .NET.

• Empaquetage de l'assembly du flux de travail et de la définition du flux de travail, et déploiement à l'aide des fonctionnalités dans Windows SharePoint Services.

• Débogage en temps réel de l'assembly du flux de travail à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation.

• Recompilation et déploiement de l'assembly du flux de travail pour corriger les erreurs détectées.

Les sections suivantes fournissent un aperçu général de chacune de ces étapes de développement.

Création de flux de travail à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation

Lors de la sélection d'un nouveau projet de flux de travail Windows SharePoint Services ou Office SharePoint Server, Visual Studio affiche la surface de conception Visual Studio 2005 Designer for Windows Workflow Foundation (figure 6). Cette surface de conception présente une interface graphique, dans laquelle vous pouvez assembler des flux de travail en tirant (par glisser-déposer) diverses activités de la Boîte à outils .

Figure 6. Interface Visual Studio 2005 Designer for Windows Workflow Foundation

Lorsque vous faites glisser une activité spécifique vers votre flux de travail, Visual Studio 2005 Designer for Windows Workflow Foundation vous indique les emplacements valides pour cette activité dans le flux de travail. Vous ne pouvez pas placer une activité à un emplacement où elle ne serait pas considérée comme valide. Par exemple, vous ne pouvez pas placer une activité d'envoi comme première activité dans une branche d'activité Listen. Comme indiqué à la figure 7, Visual Studio 2005 Designer for Windows Workflow Foundation affiche des icônes vertes avec le signe + (Plus) pour indiquer les emplacements qui sont valides pour une activité spécifique.

Figure 7. Emplacements valides pour une activité de flux de travail

À mesure que vous concevez graphiquement votre flux de travail, Visual Studio 2005 Designer for Windows Workflow Foundation génère le balisage correspondant.

De plus, si vous travaillez avec la séparation de code, votre projet de flux de travail contient un fichier code-behind, dans lequel vous programmez la logique métier de votre flux de travail. Vous pouvez basculer entre la surface de conception de flux de travail et le fichier code-beside à tout moment.

Définition de propriétés de flux de travail

Une fois l'activité ajoutée au flux de travail, vous devez définir les propriétés de l'activité pour qu'elle soit valide dans le flux de travail. Vous pouvez définir ces propriétés dans la fenêtre standard des propriétés Visual Studio. Le type de données que vous pouvez spécifier dépend du type de données acceptées par la propriété : valeurs littérales, variables ou noms de méthodes.

Si vous voulez spécifier une variable pour la propriété, vous pouvez soit entrer le nom de la variable dans la fenêtre des propriétés, auquel cas Visual Studio 2005 Designer for Windows Workflow Foundation déclare automatiquement la variable dans le fichier code-behind, soit déclarer la variable dans le fichier code-behind, puis la sélectionner dans la fenêtre des propriétés.

Certaines propriétés d'activité sont essentiellement des références aux méthodes dans le fichier code-beside qui est conforme à une signature spécifique. Tout comme avec les noms de variables, vous pouvez entrer le nom de méthode dans la fenêtre des propriétés et laisser Visual Studio 2005 Designer for Windows Workflow Foundation ajouter la signature de méthode au fichier code-behind, ou vous pouvez créer la méthode dans le fichier code-behind, puis sélectionner la méthode dans la fenêtre des propriétés.

Vous pouvez également lier une propriété à la propriété d'une autre activité.

Activités de gestionnaire

Un flux de travail peut comporter plusieurs points d'échec. Il est important de suivre l'état d'un flux de travail et de signaler les erreurs à mesure qu'elles surviennent, afin de résoudre les problèmes correctement et avec un minimum d'effort. Il est également important pour un flux de travail de maintenir l'intégrité d'un ensemble d'actions étroitement associées, afin de pouvoir annuler l'opération entière lorsqu'une seule une partie de l'opération a lieu. Vous pouvez utiliser les activités FaultHandlerActivity, TransactionScopeActivity, CompensationHandlerActivity et CancellationHandlersActivity pour gérer les erreurs, maintenir l'état d'un flux de travail et corriger les problèmes à mesure qu'ils se produisent.

Vous pouvez considérer une activité FaultHandlersActivity comme un bloc try de langage C, auquel vous pouvez rattacher un ensemble trié d'activités FaultHandlerActivity qui jouent le rôle de gestionnaires d'exception. Ces gestionnaires d'exception peuvent être considérés comme des blocs catch de langage C. Si une exception est générée lors de l'exécution d'une activité composite, le moteur d'exécution de WF fait correspondre l'exception avec les types d'exceptions gérés par les activités FaultHandlerActivity. Si le moteur d'exécution ne trouve aucun gestionnaire d'exceptions correspondant, il communique l'exception à l'activité composite supérieure suivante où le processus se répète, et ainsi de suite jusqu'à ce qu'un gestionnaire approprié soit trouvé.

Vous pouvez également avoir des activités EventHandlersActivity qui répondent à des événements en ajoutant des gestionnaires d'événements à une activité EventHandlerScopeActivity. Sur le plan conceptuel, ces gestionnaires d'événements sont très similaires à ceux des langages C ou Visual Basic .NET. Pour créer un gestionnaire d'événements, vous devez utiliser des activités EventDrivenActivity.

Les activités CompensationHandlerActivity contiennent du code qui compense ou annule les opérations d'une activité composite si elle ne s'exécute pas correctement.

Formulaires ASP.NET dans les flux de travail Windows SharePoint Services

Comme mentionné plus haut, vous pouvez utiliser ASP.NET pour créer les formulaires à utiliser avec votre flux de travail Windows SharePoint Services. Ces formulaires sont ensuite affichés dans l'interface utilisateur Windows SharePoint Services aux étapes appropriées dans le flux de travail.

Les formulaires de flux de travail sont liés tardivement à l'assembly du flux de travail grâce aux informations que vous fournissez dans le fichier XML de définition de modèle de flux de travail. Le schéma de définition de modèle de flux de travail contient des éléments indiquant l'URL des divers types de formulaires que vous pouvez utiliser avec les flux de travail Windows SharePoint Services. Vous pouvez ainsi créer des éléments de formulaire pour les modifications de flux de travail personnalisés ainsi que des formulaires pour les divers types de tâches SharePoint utilisées dans le flux de travail.

Dans la plupart des cas, l'assembly du flux de travail ne contient pas d'informations sur les formulaires de flux de travail ou de liens. Les développeurs peuvent modifier les formulaires de flux de travail à utiliser en modifiant tout simplement le fichier XML de définition de flux de travail, sans devoir recompiler l'assembly du flux de travail. Les modifications de flux de travail sont l'exception ; chaque activité permettant une modification de flux de travail doit contenir le GUID du formulaire pour cette modification de flux de travail.

Formulaires InfoPath dans les flux de travail SharePoint Server

Bien que vous puissiez utiliser également des formulaires de flux de travail ASP.NET dans les flux de travail SharePoint Server, SharePoint Server vous permet d'étendre vos formulaires de flux de travail et de les afficher dans les applications clientes Microsoft Office.

Vous pouvez utiliser des formulaires InfoPath dans vos flux de travail. InfoPath vous permet de créer des formulaires symétriques, c'est-à-dire des formulaires dont l'aspect et le fonctionnement sont toujours les mêmes que vous les affichiez dans l'interface Web de SharePoint Server ou dans une application cliente Microsoft Office, telle que Word, Excel ou PowerPoint. Vous obtenez ainsi une expérience d'interaction plus riche dans laquelle l'utilisateur peut interagir avec le flux de travail directement dans l'application cliente, au lieu d'avoir à quitter l'application et passer à l'interface Web de SharePoint Server. En outre, en tant que développeur, vous ne devez pas créer deux formulaires séparés, l'un pour l'utilisation sur le serveur et l'autre pour l'utilisation dans l'application cliente, pour fournir à l'utilisateur cette intégration d'application cliente.

Pour plus d'informations sur la création de formulaires symétriques en général, consultez l'aide au client Microsoft Office InfoPath 2007 ou Office Online.

SharePoint Server utilise Office Forms Services, un environnement d'exécution sur serveur pour les formulaires InfoPath, pour héberger les formulaires de flux de travail. Office Forms Services utilise les formulaires créés dans l'application cliente InfoPath et les affiche dans une structure ASP.NET, qui agit comme un environnement d'exécution pour le formulaire. Cet environnement présente une expérience de modification de formulaire qui correspond à l'application cliente InfoPath.

Pour plus d'informations sur Office Forms Services, consultez le SDK de Microsoft Office SharePoint Server 2007.

Remarque
Les applications clientes Office 2007, telles que Word, PowerPoint et Excel incluent une fonctionnalité d'hébergement des formulaires InfoPath, de sorte que l'utilisateur n'a pas besoin de disposer de l'application cliente InfoPath installée sur son ordinateur pour profiter de cette riche intégration.

Affichage des formulaires de flux de travail InfoPath

SharePoint Server utilise la même technique de base pour afficher tous les formulaires de flux de travail InfoPath personnalisés, y compris les formulaires d'association, initiation, modification et d'édition de tâches.

Lorsque l'utilisateur clique sur un lien pour afficher un formulaire de flux de travail dans l'interface SharePoint Server, SharePoint Server charge une page ASPX contenant un composant Office Forms Services Web. Ce composant WebPart convertit ensuite le formulaire InfoPath approprié en ASP.NET et le charge. Lorsque l'utilisateur soumet ce formulaire, le composant WebPart reçoit les données du formulaire et les gère en conséquence.

Les pages ASPX contenant le composant Office Forms Services Web sont comprises dans SharePoint Server.

Spécification de flux de travail InfoPath

Vous spécifiez les formulaires personnalisés que vous voulez utiliser dans la définition de modèle de flux de travail, au lieu du flux de travail lui-même. Dans la plupart des cas, vous devez définir deux éléments. Tout d'abord, vous définissez l'URL de formulaire pour ce processus de flux de travail (association, initiation, modification, et ainsi de suite) sur la page d'hébergement ASPX appropriée dans SharePoint Server. Ensuite, vous ajoutez un élément spécifiant l'URN pour le formulaire InfoPath personnalisé correspondant à ce type de processus de flux de travail.

Envoi des informations à l'aide de formulaires de flux de travail InfoPath

Afin que la page d'hébergement ASPX puisse recevoir des données du formulaire hébergé, le développeur ajoute un bouton d'envoi dans le formulaire InfoPath. Ce bouton utilise une règle d'envoi de données à l'aide de la connexion de données à l'environnement d'hébergement. Cette connexion renvoie les données à la page d'hébergement ASPX automatiquement lorsque l'utilisateur clique sur le bouton d'envoi. La page d'hébergement ASPX gère ensuite l'analyse et le renvoi des données au flux de travail ou à la bibliothèque de documents, le cas échéant.

Déploiement des flux de travail

Lorsque vous avez terminé la spécification de votre flux de travail, vous pouvez décider de compiler votre flux de travail en tant que flux de travail ou en tant qu'activité.

Une fois le flux de travail compilé, vous pouvez utiliser les fonctionnalités SharePoint pour empaqueter et déployer l'assembly de flux de travail et les fichiers de support nécessaires.

L'empaquetage des fonctionnalités est une méthode d'encapsulation des solutions et fonctionnalités Windows SharePoint Services pour un déploiement plus facile. Il fournit un mécanisme permettant aux développeurs d'empaqueter les fichiers nécessaires pour une solution, telle que les flux de travail, les composants WebPart, les listes et les définitions de site, pour faciliter la distribution et le déploiement. Les développeurs réunissent les fichiers nécessaires dans un fichier .wsp, essentiellement un fichier .cab, contenant un manifeste qui répertorie son contenu. Pour plus d'informations sur les fonctionnalités SharePoint, consultez le kit SDK de Microsoft Windows SharePoint Services 3.0.

Chaque modèle de flux de travail que vous déployez doit contenir un fichier de définition de modèle de flux de travail. Une définition de modèle de flux de travail est un fichier XML contenant les informations requises par Windows SharePoint Services pour instancier et exécuter le flux de travail, comme suit :

• Nom, GUID et description du modèle de flux de travail

• Assembly

• URL (ou URN pour les formulaires IP) de formulaires personnalisés utilisés avec ce modèle de flux de travail

• En option, nom du flux de travail, du moteur de flux de travail et des assemblys de service d'hôte à utiliser lors de l'exécution du flux de travail

• En option, les classes correctes à appeler dans ces assemblys

L'assembly de flux de travail doit être déployé sur le cache de l'assembly global.

Une fois déployé sur un site, le flux de travail est disponible comme modèle de flux de travail que les administrateurs SharePoint peuvent associer aux bibliothèques de documents et aux listes sur ce site.

Débogage des flux de travail

Après le déploiement de votre assembly de flux de travail, vous pouvez le déboguer en ouvrant votre projet de flux de travail et en vous connectant au processus w3wp de Windows SharePoint Service.

Visual Studio 2005 Designer for Windows Workflow Foundation est hébergé dans Visual Studio. Vous pouvez ainsi profiter des fonctions de débogage de Visual Studio. Vous pouvez définir des points d'arrêt dans le code que vous écrivez dans votre fichier code-beside, ainsi que sur les activités de flux de travail dans la surface de conception.

Remarque
Pour faciliter le débogage, il est judicieux de développer vos modèles de flux de travail sur le serveur sur lequel vous envisagez de déployer.

Visual Studio 2005 Designer for Windows Workflow Foundation prend en charge non seulement les fonctionnalités de débogage standard de Visual Studio telles que les fenêtres de points d'arrêt et de pile d'appel mais il inclut également une plage d'indicateurs visuels qui fournissent des informations pendant le processus de débogage. Vous pouvez également ajouter des points d'arrêt à une activité de flux de travail à mesure que vous déboguez l'assembly.

Vous pouvez effectuer des opérations d'entrée, de sortie et de continuation pour vous déplacer dans le code de flux de travail.

Les types de débogage suivants ne sont pas pris en charge par Visual Studio 2005 Designer for Windows Workflow Foundation :

• le débogage juste-à-temps (JIT, Just-in-time) des exceptions d'exécution dans le processus d'hébergement ;

• le débogage juste-à-temps (JIT, Just-in-time) par sélection d'un processus dans le gestionnaire des tâches.

Pour plus d'informations sur le débogage à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation, consultez le SDK de Windows Workflow Foundation.

Remarque
Le SDK de Windows Workflow Foundation est disponible en téléchargement en tant que composant de Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 et Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2 sur le site Web du Centre de téléchargement Microsoft. Ce téléchargement contient également Visual Studio 2005 Designer for Windows Workflow Foundation, ainsi que le moteur d'exécution Windows Workflow Foundation.

Création de flux de travail SharePoint dans SharePoint Designer 2007

Lorsque vous créez un flux de travail Office SharePoint Designer 2007, vous créez ce flux de travail directement sur une liste ou une bibliothèque de documents spécifiques dans Windows SharePoint Services, et vous liez les données. Vous utilisez une liste prédéfinie d'activités de flux de travail sans utiliser de code. Le flux de travail que vous concevez n'est pas compilé en tant qu'assembly ; il est enregistré en tant que fichiers source jusqu'à ce que Windows SharePoint Services le compile lors de sa première exécution.

Cette approche présente plusieurs avantages :

• Les flux de travail peuvent être développés et testés rapidement.

• Le flux de travail étant spécifique à une liste donnée, le processus de déploiement est simplifié.

• Les problèmes de sécurité sont bien moins compliqués par la même occasion.

• Étant donné qu'ils ne sont pas compilés dans des assemblys, les flux de travail créés dans SharePoint Designer peuvent être déployés sur les serveurs sur lesquels la stratégie administrative interdit les assemblys de code personnalisés.

  Remarque
  Les flux de travail créés dans SharePoint Designer sont assemblés à partir d'une « liste sécurisée » d'activités prédéfinies qui sont vraisemblablement approuvées par les administrateurs pour leur exécution sur les serveurs.

• Les flux de travail peuvent être créés par des utilisateurs disposant d'une expérience en développement moins importante, comme les concepteurs de sites Web ou les travailleurs de connaissances.

Cette approche signifie également que les flux de travail créés dans SharePoint Designer sont différents de ceux créés à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation à plusieurs niveaux importants :

• Un flux de travail créé dans SharePoint Designer ne peut pas être déployé vers plusieurs listes. Il n'est valide que pour la liste pour laquelle il a été créé.

• Étant donné que vous créez le flux de travail directement sur une liste, le flux de travail est associé à la liste au moment de la conception. Ainsi, les flux de travail créés dans SharePoint Designer ne disposent pas d'étape d'association.

• Les modifications de flux de travail ne sont pas disponibles dans les flux de travail créés dans SharePoint Designer.

• Vous ne pouvez pas créer de flux sur un type de contenu dans SharePoint Designer.

Pour une comparaison détaillée, reportez-vous à la section Comparaison de Visual Studio 2005 Designer for Windows Workflow Foundation et SharePoint Designer 2007.

Exécution de flux de travail créés dans SharePoint Designer 2007

Étant donné qu'ils ne contiennent pas de code personnalisé, les flux de travail créés dans Office SharePoint Designer ne sont pas compilés et déployés comme des assemblys. Ils sont enregistrés comme leurs fichiers source dans Windows SharePoint Services et compilés en mémoire seulement lorsque cela est nécessaire.

Pour chaque site, les flux de travail de ce type sont enregistrés dans une bibliothèque de documents séparée. Cette bibliothèque de documents contient un dossier pour chaque flux de travail créé dans SharePoint Designer. Le dossier contient tous les fichiers source requis par le flux de travail, notamment :

• le fichier de balisage du flux de travail ;

• le fichier de règles du flux de travail ;

• les formulaires ASPX pour les formulaires de flux de travail personnalisés requis.

Windows SharePoint Services inclut un compilateur JIT (just-in-time) servant à compiler les fichiers source dans un flux de travail la première fois que le flux de travail est démarré sur un élément. Windows SharePoint Services conserve le flux de travail compilé en mémoire jusqu'à son prochain appel, tout comme les serveurs conservent les pages .aspx compilées en mémoire pour accélérer les performances d'exécution au prochain appel d'une page.

Chaque fois qu'un flux de travail est lancé sur un élément, Windows SharePoint Services détermine si le flux de travail a été déployé comme assembly ou comme des fichiers source. S'il existe un assembly de flux de travail, Windows SharePoint Services fait appel à cet assembly pour créer l'instance de flux de travail. Si le flux de travail a été déployé comme des fichiers source, Windows SharePoint Services détermine s'il dispose déjà d'un flux de travail compilé à partir de ces fichiers source en mémoire. Le cas échéant, Windows SharePoint Services fait appel au flux de travail compilé en mémoire pour créer l'instance de flux de travail. Dans le cas contraire, Windows SharePoint Services utilise son compilateur JIT (just-in-time) pour compiler les fichiers source dans un flux de travail en mémoire, auquel il fait ensuite appel pour créer l'instance de flux de travail.

Processus de développement de flux de travail dans SharePoint Designer 2007

Pour une conception et un déploiement rapides de flux de travail, le processus de développement dans SharePoint Designer est beaucoup plus simple que dans Visual Studio.

En général, lorsque vous développez des flux de travail Windows SharePoint Services ou SharePoint Server à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation, vous effectuez les étapes de base suivantes :

• Création de votre flux de travail en assemblant et configurant les activités prédéfinies et les conditions disponibles dans SharePoint Designer.

• Génération automatique par SharePoint Designer de formulaires ASP.NET pour l'initiation de flux de travail et de tâches SharePoint personnalisées, si nécessaire.

• Personnalisation des formulaires de flux de travail, le cas échéant.

SharePoint Designer génère automatiquement le modèle de définition de flux de travail et gère le déploiement du flux de travail sur la liste spécifiée.

Les sections suivantes fournissent un aperçu général de chacune de ces étapes de développement.

Création de flux de travail à l'aide de SharePoint Designer 2007

SharePoint Designer utilise une interface pilotée par un assistant qui permet aux utilisateurs d'assembler des flux de travail séquentiels à partir d'activités prédéfinies. Les utilisateurs sélectionnent des activités à partir d'une liste prédéterminée et les configurent à l'aide de l'interface SharePoint Designer. Ces activités peuvent être les mêmes que dans Visual Studio 2005 Designer for Windows Workflow Foundation ; les activités ne sont pas différentes dans ces deux outils.

Toutefois, dans SharePoint Designer, chaque activité apparaît comme une action représentée par une phrase contenant des variables que l'utilisateur peut configurer à l'aide de menus déroulants et de boîtes de dialogue de recherche. Les utilisateurs peuvent également sélectionner des conditions, c'est-à-dire des clauses conditionnelles configurables dirigeant le flux du flux de travail.

Pendant que l'utilisateur sélectionne et configure des conditions et des actions dans l'interface de flux de travail, SharePoint Designer génère les deux fichiers qui représentent la classe de flux de travail :

• le fichier de balisage de flux de travail, contenant le balisage de description des activités dans le flux de travail ;

• le fichier de règles de flux de travail, contenant la logique métier du flux de travail sous forme de règles déclaratives, au lieu de code.

Ajout d'activités et de conditions personnalisées

Comme indiqué, les concepteurs de flux de travail dans SharePoint Designer ne peuvent pas créer d'activités personnalisées pour l'utilisation dans leurs flux de travail. Ils sont limités aux activités et conditions mises à leur disposition dans la liste de contrôles sécurisés (vraisemblablement approuvée par un administrateur serveur) qui apparaît dans SharePoint Designer.

Une condition est tout simplement un assembly personnalisé avec une méthode statique qui évalue une condition et renvoie une valeur booléenne lorsqu'elle est appelée.

Les développeurs peuvent créer des activités et des conditions personnalisées et les rendre disponibles sur la liste sécurisée. Pour cela, les développeurs doivent :

• Créer l'activité ou la condition, la compiler comme un assembly à nom fort et la déployer vers le cache de l'assembly global.

• Ajouter l'activité ou la condition à la liste d'actions sécurisées dans le fichier web.config.

• Dans le fichier WSS.Actions situé dans le dossier de flux de travail, ajouter des règles et des paramètres pour la phrase qui représente l'activité ou la condition dans l'interface utilisateur SharePoint Designer. C'est ce balisage qui spécifie comment l'activité ou la condition apparaît et s'exécute dans l'interface, car ces informations ne sont pas présentes dans l'assembly d'activité ou de condition.

Formulaires ASP.NET dans les flux de travail SharePoint Designer

Vous pouvez créer une étape d'initiation pour votre flux de travail dans SharePoint Designer. Le cas échéant, SharePoint Designer génère automatiquement un formulaire d'initiation à l'aide d'ASP.NET, selon vos spécifications d'initiation.

De même, vous pouvez créer des tâches SharePoint personnalisées pour votre flux de travail. Encore un fois, SharePoint Designer génère automatiquement un formulaire ASP.NET pour la tâche, selon vos spécifications.

Ces formulaires aspx sont stockés sur le site SharePoint avec les fichiers source de flux de travail. Vous pouvez les ouvrir et les personnaliser comme vous le faites avec les autres formulaires aspx.

Remarque
SharePoint Designer 2007 n'offre pas d'intégration avec les formulaires InfoPath.

Déploiement de flux de travail avec SharePoint Designer 2007

Etant donné que vous créez des flux à partir d'une liste spécifique, le déploiement de flux de travail créés dans Office SharePoint Designer est un processus beaucoup plus simple que pour les flux de travail créés dans Visual Studio 2005 Designer for Windows Workflow Foundation. SharePoint Designer gère le déploiement du flux de travail vers la liste spécifiée.

SharePoint Designer n'offre pas de fonctionnalité de débogage personnalisé.

La suppression d'un flux de travail créé dans SharePoint Designer d'une liste ne supprime pas les fichiers source réels utilisés pour compiler ce flux de travail dans la mémoire. À la place, le flux de travail n'est plus associé à la liste, mais les fichiers source restent enregistrés dans la bibliothèque de documents de flux de travail sur le site.

Dans le modèle d'objet Windows SharePoint Services, les flux de travail créés dans SharePoint Designer ne se distinguent pas des flux de travail créés dans Visual Studio 2005 Designer for Windows Workflow Foundation.

Comparaison de Visual Studio 2005 Designer for Windows Workflow Foundation et SharePoint Designer 2007

Le tableau suivant offre une comparaison détaillée des capacités offertes par Visual Studio 2005 Designer for Windows Workflow Foundation et Office SharePoint Designer 2007, ainsi que des flux de travail que vous pouvez créer dans chacun d'eux.

Tableau 1. Comparaison détaillée des capacités

Visual Studio 2005 Designer for Windows Workflow Foundation	SharePoint Designer 2007
Peut écrire des flux de travail pour Windows SharePoint Services ou SharePoint Server.	Peut écrire des flux de travail pour Windows SharePoint Services ou SharePoint Server.
Le fichier code-behind permet au développeur d'écrire du code Visual C# ou Visual Basic .NET personnalisé pour exprimer la logique métier.	Aucun fichier code-behind ; le fichier de règles de flux de travail encapsule de manière déclarative la logique métier.
Génère un fichier de balisage de flux de travail.	Génère un fichier de balisage de flux de travail.
Le flux de travail est créé comme un modèle qui peut être associé à plusieurs sites et listes.	Le flux de travail est créé sur une liste spécifique, et les données sont liées au moment de la conception.
Le fichier de balisage de flux de travail ou les fichiers de balisage et code-behind sont compilés dans un assembly de flux de travail.	Le balisage de flux de travail, les règles de flux de travail et le fichier de prise en charge sont enregistrés, à l'état non compilés, dans une bibliothèque de documents spécifique sur le site
Le modèle de flux de travail doit être associé à chaque liste sur laquelle il doit être disponible.	L'association se produit lorsque le flux de travail est créé sur la liste spécifique ; aucune association ultérieure n'est nécessaire ou possible.
Peut utiliser toute technologie de formulaire. Par exemple, les formulaires ASP pour les flux de travail Windows SharePoint Services ou les formulaires InfoPath pour les flux de travail SharePoint Server.	Génère automatiquement des formulaires ASP.NET, que vous pouvez ensuite personnaliser.
Peut inclure des modifications de flux de travail.	Les modifications de flux de travail ne sont pas disponibles.
Peut utiliser des formulaires InfoPath symétriques personnalisés, qui permettent l'intégration cliente Office de formulaires de flux de travail personnalisés.	L'intégration de formulaires InfoPath n'est pas disponible.
Peut créer des activités personnalisées pour inclusion dans les flux de travail.	Doit utiliser les activités fournies.
Peut empaqueter l'assembly de flux de travail et la définition de flux de travail en tant que fonctionnalité SharePoint et déployer vers le site.	Gère automatiquement le déploiement vers une liste spécifique.
Peut utiliser le formulaire d'initiation pour rassembler des informations de l'utilisateur au démarrage du flux de travail.	Peut utiliser le formulaire d'initiation pour rassembler des informations de l'utilisateur au démarrage du flux de travail.
Peut utiliser des formulaires personnalisés pour l'interaction des utilisateurs avec les tâches SharePoint.	Peut utiliser des formulaires personnalisés pour l'interaction des utilisateurs avec les tâches SharePoint.
Le débogage Visual Studio est disponible.	Le débogage pas à pas n'est pas disponible.
Peut créer des flux de travail séquentiels et d'état.	Peut créer seulement des flux de travail séquentiels.

Structure des flux de travail dans Windows SharePoint Services

La figure 8 montre comment les divers éléments de la structure de flux de travail Windows SharePoint Services sont joints après la création d'un modèle de flux de travail, son déploiement et son association à un type de contenu, une liste ou une bibliothèque de documents spécifiques.

Lorsque vous associez un modèle de flux de travail à un type de contenu, une liste ou une bibliothèque de documents donnés, Windows SharePoint Services écrit les informations de paramètres d'association définis par l'administrateur dans un tableau d'association de flux de travail de groupe. L'entrée dans ce tableau d'association lie le type de contenu, la liste ou la bibliothèque de documents spécifiques à la définition de modèle de flux de travail du flux de travail associé. Les informations de la définition de modèle de flux de travail, à leur tour, incluent des références à l'assembly de flux de travail lui-même ainsi qu'aux formulaires de flux de travail personnalisés éventuellement utilisés dans le flux de travail.

Dans le cas des flux de travail créés dans SharePoint Designer 2007, Designer écrit automatiquement les informations de paramètres d'association dans le tableau d'association de flux de travail et génère et installe la définition de modèle de flux de travail. De plus, le flux de travail est stocké dans une bibliothèque de documents de flux de travail sur le site, non pas comme un assembly compilé, mais comme les fichiers source de balisage et de règles de flux de travail.

Figure 8. Structure de composant de flux de travail dans Windows SharePoint Services

Utilisation de l'espace de noms du flux de travail

Après le déploiement de votre solution de flux de travail, vous pouvez utiliser le modèle d'objet Windows SharePoint Services pour interroger les processus de flux de travail et exécuter des actions de flux de travail par programmation, telles que l'ajout d'un flux de travail à une liste ou le démarrage d'un flux de travail pour un élément.

Objets Microsoft.Windows.SharePoint.Workflow principaux

L'espace de noms Microsoft.Windows.SharePoint.Workflow représente la fonctionnalité de flux de travail dans Windows SharePoint Services.

L'objet SPWorkflowTemplateCollection représente les modèles de flux de travail actuellement déployés sur un site. Chaque objet SPWorkflowTemplate représente un modèle de flux de travail et contient des propriétés que vous pouvez utiliser pour obtenir ou définir des informations sur le modèle, par exemple, les données d'instanciation et les listes d'historique et de tâches pour le modèle.

Pour associer un flux de travail à une liste ou à une bibliothèque de documents, utilisez la méthode SPList.AddWorkflowAssociation. Cette méthode surchargée requiert quatre paramètres :

• le nom du modèle de flux de travail ou l'ID ;

• le nom que vous souhaitez attribuer au flux de travail ;

• le nom de la liste de tâches ou l'ID pour la liste de tâches que vous souhaitez utiliser avec ce flux de travail ;

• l'historique du flux de travail.

Comme pour l'ajout d'un flux de travail par l'interface utilisateur, cette méthode ajoute une colonne d'état pour le flux de travail à la liste. Utilisez la méthode SPList.RemoveWorkflowAssociation pour supprimer un modèle de flux de travail d'une liste.

L'objet SPWorkflowAssociationCollection représente le tableau d'associations de flux de travail internes d'un site, c'est-à-dire, qu'il représente les flux de travail actuellement associés sur des listes dans un ensemble de sites, avec les informations d'association correspondantes. Chaque objet SPWorkflowAssociation représente un modèle de flux de travail qui a été associé à une liste spécifique et contient des propriétés qui renvoient des informations personnalisées sur l'association, par exemple, si le flux de travail est activé ou s'il a été modifié, la liste à laquelle le flux de travail a été associé, ainsi qu'une référence à l'objet SPWorkflowTemplate qui sert de base à cet objet SPWorkflowAssociation.

La propriété SPWorkflowAssociation.IsDeclarative renvoie True (vrai) pour les flux de travail qui sont enregistrés comme des fichiers, non compilés, tels que ceux créés dans SharePoint Designer.

SPWorkflowCollection représente les instances de flux de travail qui ont été exécutées ou qui s'exécutent actuellement sur un élément de liste donné. Chaque objet SPWorkflow contient des propriétés qui renvoient des informations sur l'instance de flux de travail, par exemple, si le flux de travail s'est terminé, son état interne et le modèle de flux de travail sur lequel il est basé. De plus, chaque flux de travail contient un ensemble de tâches pour le flux de travail, SPWorkflowTaskCollection.

Utilisez la propriété SPListItem.Workflows pour renvoyer un objet SPWorkflowCollection représentant les flux de travail s'exécutant actuellement pour cet élément de liste.

Gestion par programmation d'instances de flux de travail en cours d'exécution

Les utilisateurs interagissent avec les flux de travail s'exécutant individuellement sur des éléments par l'interface utilisateur Windows SharePoint Services. Toutefois, Windows SharePoint Services fournit une fonctionnalité vous permettant de contrôler de manière centralisée les instances de flux de travail s'exécutant dans votre groupe entier de serveurs via le modèle objet. Utilisez l'objet SPWorkflowManager pour gérer les instances de flux de travail s'exécutant dans votre groupe entier de serveurs. L'objet SPWorkflowManager n'a pas d'équivalent dans l'interface utilisateur. Bien que l'objet soit accessible via l'objet SPSite, vous pouvez l'utiliser pour administrer les instances de flux de travail s'exécutant dans votre groupe entier. Utilisez l'objet SPWorkflowManager pour les tâches suivantes :

• démarrage, exécution ou annulation de flux de travail ;

• renvoi de tous les flux de travail s'exécutant actuellement sur un élément spécifique ;

• annulation de toutes les instances de flux de travail basées sur un modèle de flux de travail spécifique dans une liste ;

• exécution d'autres opérations d'administration de flux de travail.

Pour démarrer manuellement le flux de travail spécifique d'un élément (par exemple, un flux de travail qui n'est pas configuré pour le démarrage automatique), utilisez la méthode SPSite.WorkflowManager.StartWorkflow. Cette méthode requiert trois paramètres : le nom de l'élément de liste, le nom du modèle de flux de travail et l'événement de démarrage.

La figure 9 montre une vue hiérarchique de l'objet SPWorkflowManager et des objets qu'il contient.

Figure 9. Hiérarchie de l'objet SPWorkflowManager

Conclusion

Windows SharePoint Services 3.0 héberge Windows Workflow Foundation qui vous permet de rattacher des processus métier personnalisés, implémentés comme flux de travail séquentiels ou de machine d'état, aux éléments SharePoint. Cette implémentation inclut la capacité de créer des flux de travail personnalisés avec intégration de formulaires pour l'interaction utilisateur. SharePoint Server 2007 étend ces capacités de flux de travail en offrant l'intégration avec des formulaires InfoPath symétriques qui peuvent être hébergés dans des applications clientes Office, telles que Word, PowerPoint, Excel et InfoPath.

Microsoft fournit deux outils puissants de création de flux de travail pour Windows SharePoint Services. Visual Studio 2005 Designer for Windows Workflow Foundation est un complément de Visual Studio 2005 vous permettant de développer des modèles de flux de travail, avec code personnalisé, que vous pouvez déployer sur plusieurs sites et listes. Vous pouvez également utiliser SharePoint Designer pour développer et déployer rapidement les flux de travail de liste à partir d'une liste prédéfinie d'activités de flux de travail.

Dans les deux cas, après le déploiement de votre solution de flux de travail, vous pouvez utiliser le modèle d'objet Windows SharePoint Services pour interroger les processus de flux de travail et exécuter des actions de flux de travail par programmation.

Ressources supplémentaires

• Centre de développement Microsoft Office

• Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 et Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2