Andrew May
Microsoft Corporation

S'applique à :
Microsoft Windows SharePoint Services (version 3)
Microsoft Office SharePoint Server 2007

Résumé : Vue d’ensemble de haut niveau de l'implémentation des fonctionnalités de workflow de Windows Workflow Foundation par Microsoft Windows SharePoint Services (version 3) et de l'extension de ces fonctionnalités par Microsoft Office SharePoint Server 2007 à l'aide de formulaires symétriques Microsoft Office InfoPath 2007. (28 pages imprimées)

Lire l'article en anglais  

Sur cette page

Introduction aux workflows
Architecture de workflow
Types de workflows
Composition d'un workflow
Balisage de workflow
Les workflows dans Windows SharePoint Services et SharePoint Server 2007
réation de workflows de type SharePoint
Création de workflows SharePoint dans Visual Studio 2005
Création des workflows SharePoint dans SharePoint Designer 2007
Comparaison de Visual Studio 2005 Designer for Windows Workflow Foundation à SharePoint Designer 2007
Structure de workflow dans Windows SharePoint Services
Utilisation d'un espace de noms de workflow
Conclusion
Ressources supplémentaires

Introduction aux workflows

Microsoft Windows SharePoint Services offre aux utilisateurs un environnement de travail robuste et personnalisable pour la création, la collaboration et le stockage d'informations métier utiles. À présent, à l'aide de Microsoft Windows SharePoint Services (version 3) et de Microsoft Office SharePoint Server 2007, vous pouvez associer des processus métier personnalisés à ces documents ou éléments de la liste.

Vous pouvez représenter ces processus métier personnalisés à l'aide de workflows. Un workflow est une solution permettant d'organiser et d'exécuter un ensemble d'unités de travail ou d'activités, dans le but d'établir une représentation exécutable d'un processus de travail. Ce processus peut contrôler la plupart des aspects d'un élément dans Windows SharePoint Services, y compris la durée de vie de cet élément. Le workflow est suffisamment flexible pour modéliser les fonctions du système et les actions humaines nécessaires à la réalisation du workflow.

Vous pouvez créer des workflows aussi simples ou complexes que vos processus métier le nécessitent. Vous pouvez créer des workflows que l'utilisateur lance ou des workflows que Windows SharePoint Services lance automatiquement en se basant sur un événement, tel que la création ou la modification d'un élément.

Supposons que vous deviez créer un workflow simple qui achemine un document vers un ensemble d'utilisateurs pour approbation ou commentaires. Ce workflow inclurait des actions que le système doit effectuer, et fournirait des interfaces permettant aux utilisateurs d'interagir avec le workflow comme indiqué. Par exemple, Windows SharePoint Services enverrait un courrier électronique aux utilisateurs sélectionnés lorsque le document serait prêt pour vérification. Ces utilisateurs pourraient ensuite notifier à Windows SharePoint Services le moment où ils auraient terminé leurs vérifications et, éventuellement, saisir des commentaires. L'environnement de workflow inclus dans Windows SharePoint Services V3 et développé dans SharePoint Server 2007 permet de modéliser des processus de travail complexes et de les présenter aux utilisateurs finaux de manière transparente et facilement compréhensible, de façon à les guider dans chaque étape du processus.

Cet article offre une vue d'ensemble de haut niveau des workflows tels qu'ils sont implémentés dans Windows SharePoint Services et développés dans SharePoint Server. Il détaille également les outils développeur disponibles pour la création de workflows dans les deux environnements ainsi que les capacités et avantages de ces outils.

Architecture de workflow

La fonctionnalité de workflow dans Windows SharePoint Services V3 est basée sur Windows Workflow Foundation (WF), un composant de plate-forme Microsoft Windows qui offre une infrastructure de programmation et des outils de développement et d'exécution des applications de workflow. WF simplifie le processus de programmation asynchrone pour créer des applications de workflow persistantes, longues et avec état. Le moteur d'exécution de WF gère l'exécution des workflows 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 workflow, 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 workflows et de la gestion de l'état actuel de tout workflow en cours d'exécution. WF permet à n'importe quel conteneur de processus ou de service d'application d'exécuter des workflows en hébergeant WF—en d'autres termes, 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 au moteur des implémentations personnalisées pour les services suivants : transaction, persistance, notifications, rôles, suivi et messagerie. Les développeurs peuvent ensuite créer des solutions de workflow s'exécutant sous Windows SharePoint Services.

La figure 1 présente l'architecture de workflow 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 workflow dans Windows SharePoint Services V3

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

SharePoint Server utilise la fonctionnalité de workflow dans Windows SharePoint Services (version 3) et développe cette fonctionnalité via l'intégration aux formulaires InfoPath et aux activités de workflow additionnelles. Pour plus de détails, reportez-vous à la section Création de workflows de type 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 Windows Workflow Foundation.

Après avoir brièvement décrit l'infrastructure de workflow fournie dans Windows SharePoint Services, examinons la composition interne et la structure d'un workflow WF. Nous étudierons ensuite les différents outils développeur proposés par Microsoft pour la création de solutions de workflow pour Windows SharePoint Services et SharePoint Server 2007.

Persistance de workflow

L'un des services les plus importants offerts par Windows SharePoint Services au moteur de workflow WF est le service de persistance. Les workflows impliquant des interactions humaines sont des processus à long terme par nature ; même dans des circonstances idéales, les êtres humains nécessitent une période de temps relativement longue pour effectuer une tâche, par rapport aux machines. Dans certains scénarios Microsoft Office, les workflows nécessitent généralement plusieurs jours, si ce n'est plus. Examinons l'exemple d'un workflow qui achemine des documents pour approbation. L'approbateur peut nécessiter plusieurs jours pour vérifier le document.

Visiblement, la conservation en mémoire de chaque workflow en cours pendant toute la durée de son exécution est impossible ; les ressources requises par des workflows collectés à long terme essouffleraient très vite le système.

En revanche, après qu'une instance de workflow a atteint le point auquel elle attend la saisie utilisateur, Windows SharePoint Services décharge cette instance de workflow depuis la mémoire et conserve ses données. Ensuite, lorsqu'un événement approprié tel que les données de saisie utilisateur nécessite le redémarrage de l'instance de workflow, Windows SharePoint Services crée de nouveau l'instance de workflow à l'aide des données persistantes, pour que l'instance de workflow puisse recevoir et gérer l'événement en fonction des besoins.

Bien que de nombreuses instances de workflow puissent s'exécuter à n'importe quel moment, seule une partie de ces workflows est susceptible de rester en mémoire et d'utiliser les ressources systèmes.

Types de workflows

Windows Workflow Foundation prend en charge deux principaux types de workflows :

• Workflows séquentiels Représente un workflow sous la forme d'une succession d'étapes qui s'exécutent dans l'ordre jusqu'à la dernière activité. Les workflows séquentiels ne sont toutefois pas purement séquentiels dans leur exécution. Étant donné qu'ils peuvent recevoir des événements externes et inclure des flux logiques parallèles, l'ordre exact de l'exécution des activités peut varier.

• Workflow de machine d'état Représente un ensemble d'états, de transitions et d'actions. Un état est désigné en tant qu'état de départ, puis en se basant sur un événement, une transition est effectuée vers un autre état. La machine d'état peut disposer d'un état final qui détermine la fin du workflow.

Vous pouvez créer des workflows de chaque type pour Windows SharePoint Services et SharePoint Server.

Workflows séquentiels

Il est recommandé de représenter les workflows séquentiels graphiquement sous la forme d'un organigramme d'actions, avec un début, une fin et une direction de flux séquentiel du début à la fin. Les workflows séquentiels peuvent incorporer des structures de flux telles que la répétition, le bouclage et les branches parallèles, mais évoluer au final de l'action initiale vers l'action finale.

Par exemple, supposons que vous devez planifier le simple workflow qui achemine un document dans Windows SharePoint Services pour approbation. Lorsque le workflow démarre, le système notifie au relecteur spécifié par courrier électronique qu'il ou elle a un document à contrôler. Le relecteur contrôle ensuite le document et notifie au système que la tâche a été accomplie et indique également s'il approuve ou refuse le document. En se basant sur la réponse du relecteur, le workflow exécute une des deux branches parallèles. Si le relecteur a approuvé le document, le système déplace le document vers une bibliothèque de documents SharePoint spécifique, puis envoie un courrier électronique à toute l'équipe lui notifiant le document approuvé. Si le relecteur refuse le document, le système le notifie à l'auteur du document. Dans les deux cas, le workflow atteint la fin du document et s'arrête. La figure 2 présente ce workflow.

Figure 2. Diagramme conceptuel d'un workflow séquentiel

Workflows de machine d'état

Contrairement aux workflows séquentiels, les workflows de machine d'état n'ont pas de flux d'exécution spécifié et n'ont pas besoin de fin. En revanche, les workflows de machine d'état définissent un nombre quelconque d'états susceptibles d'être occupés par les événements qui font transiter l'élément d'un état à un autre.

La figure 3 représente un processus simple de publication de document, modélisé sous la forme d'un workflow de machine d'état. Le workflow est lancé lorsqu'un document est créé et se termine lorsque l'état du document est défini sur terminé. Entre-temps, toutefois, le document ne transite pas via un chemin prédéterminé, mais d'un état à un autre lors de l'apparition d'événements.

Le workflow de machine d'état se compose d'activités d'état. Chaque activité d'état représente un état de l'élément. Chaque activité d'état peut éventuellement contenir une initialisation d'état, une finalisation d'état et un ou plusieurs gestionnaires d'événements. Chaque activité du gestionnaire d'événements peut gérer un événement. En réponse à l'événement géré, un traitement peut être effectué ainsi qu'une transition vers un autre état.

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

Le fractionnement des deux types de workflows en un ensemble d'actions discrètes—celles effectuées par le système et celles réalisées par les utilisateurs— constitue une caractéristique des workflows séquentiels et des workflows de machine d'état . Ces actions peuvent être considérées comme les blocs constitutifs des workflows. Dans les workflows WF, ces actions sont appelées activités.

Composition d'un workflow

Nous avons précédemment défini le workflow comme étant une solution permettant d'organiser et d'exécuter un ensemble d'unités de travail ou d'activités, dans le but d'établir une représentation exécutable d'un processus de travail. Par conséquent, chaque workflow WF se compose d'un ensemble d'activités liées. Une activité est l'unité élémentaire de la modélisation, programmabilité, réutilisation et exécution dans Windows Workflow Foundation. Une activité peut être réalisée par le système ou par un utilisateur. Par exemple, le système peut envoyer un courrier électronique à une personne sous la forme d'une alerte ; ou une personne peut approuver un document pour distribution.

D'un point de vue conceptuel, notre exemple de workflow séquentiel inclut cinq activités :

• Envoi de courriers électroniques pour notification de l'approbateur

• Approbation ou refus de document

• Déplacement d'un document vers la bibliothèque de documents « approuvés »

• Envoi de courriers électroniques pour notification de l'équipe

• Envoi de courriers électroniques pour notification de l'auteur du document.

Les activités peuvent également représenter des structures de contrôle logique qui définissent la portée et dirigent le flux d'exécution du workflow, tout comme le font les contrôles logiques de code, tels que les boucles If Then et Do While, qui contrôlent le flux de programme dans le code.

Les activités peuvent inclure des propriétés, des méthodes et des événements. Les activités simples effectuent une seule unité de travail, telle que « retard d'un jour » ou « appel d'un service Web ». Les activités composites contiennent d'autres activités, telles qu'une activité conditionnelle à deux branches. Vous pouvez également associer aux activités des gestionnaires d'erreurs ou de compensation,, notamment. Ces associations sont particulièrement recommandées pour les activités composites.

Par nature, le workflow en lui-même est une activité composite qui contient toutes les autres activités de ce workflow.

Par conséquent, le workflow peut être considéré comme un ensemble d'activités stockées sous la forme d'un 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 du système. Un workflow permet de décrire l'ordre d'exécution et les relations dépendantes entre les parties d'un travail à court terme ou à long terme.

Windows Workflow Foundation inclut plusieurs activités prédéfinies que vous pouvez utiliser dans vos workflows. Vous pouvez également créer vos propres activités personnalisées. Le pack de modèles de projet de workflow Windows SharePoint Services contient de nombreuses activités destinées explicitement à une utilisation dans l'environnement de Windows SharePoint Services. Le pack de modèles contient également les références nécessaires au programme par rapport au modèle d'objet Windows SharePoint Services. De même, le pack de modèles de projet SharePoint Server est personnalisé pour une utilisation dans l'environnement de SharePoint Server. Pour plus d'informations, reportez-vous à la section Création de workflows de type SharePoint dans Visual Studio 2005.

Balisage de workflow

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

• Un fichier XML ou fichier de balisage, qui inclut les métadonnées déclaratives du workflow

• Le fichier de balisage, en combinaison avec un fichier code-behind qui contient un code personnalisé représentant les propriétés et le comportement du workflow

• Un fichier (ou des fichiers) de code qui inclut la logique déclarative et le comportement du workflow

Le fichier de balisage est écrit en XAML (Extensible Application Markup Language) et dispose d'un schéma publié que le fichier doit respecter, il porte également l'extension de fichier .xoml.

Étant donné que XAML dispose d'un schéma publié, vous pouvez créer des fichiers XAML à l'aide d'un quelconque éditeur de texte ou XML. Cependant, les deux outils de création de workflow présentés dans cet article, Visual Studio 2005 Designer for Windows Workflow Foundation et Microsoft Office SharePoint Designer 2007, offrent aux développeurs une interface graphique dans laquelle il est possible de créer des workflows et générer automatiquement le fichier de balisage approprié.

Les développeurs peuvent choisir d'intégrer ou de séparer leurs métadonnées déclaratives de la logique métier incluse dans le workflow. D'un point de vue conceptuel, le paradigme de « séparation de code » utilisé par les workflows WF est identique à celui utilisé dans Microsoft ASP.NET : les métadonnées déclaratives sont séparées du fichier qui contient votre logique métier. Bien que le fichier de balisage contienne les métadonnées des activités incluses dans le workflow, les propriétés et comportements de ces activités sont détaillés dans un fichier séparé.

Pour les workflows créés à l'aide de la séparation de code, les informations sont conservées dans le fichier de balisage, comme décrit précédemment, et dans l'un des deux types de fichiers suivants :

• Un fichier code-beside, qui contient le code englobant votre logique métier. Ce fichier peut être écrit sous Microsoft Visual C# ou Microsoft Visual Basic .NET.

• Un fichier de règles de workflow, qui encapsule votre logique métier sous la forme de règles déclaratives plutôt que sous la forme de code.

Chaque workflow créé de cette manière est de type Microsoft .NET unique, généré à partir de deux classes partielles, représentées par XOML et par un fichier code-behind ou un fichier de règles. Lorsque le projet de workflow est compilé, ces deux classes partielles sont combinées dans un assembly .NET. Il s'agit de l'approche mise en place lors de la création de workflows pour Windows SharePoint Services ou SharePoint Server à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation.

Les workflows uniquement composés de fichiers de code suivent le même processus de compilation général—en d'autres termes, les fichiers de code sont compilés dans un type .NET.

De plus, vous pouvez compiler les workflows 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 workflows de balisage compilés. Il s'agit de l'approche mise en place lors de la création de workflows pour Windows SharePoint Services ou SharePoint Server à l'aide de SharePoint Designer 2007.

Les workflows dans Windows SharePoint Services et SharePoint Server 2007

Jusqu'à présent, nous avons présenté les attributs de workflow des applications qui implémentent Windows Workflow Foundation. À présent, examinons de plus près les workflows tels qu'ils sont implémentés de manière spécifique dans Windows SharePoint Services et étudions les aspects importants de cette implémentation.

Instances et modèles de workflow

Dans Windows SharePoint Services, les workflows disponible sur un site ou sur une liste sont appelés modèles de workflow ; un workflow en cours d'exécution sur un élément spécifique SharePoint est appelé une instance de workflow. Ainsi, sur une liste donnée, plusieurs instances du même modèle de workflow peuvent être exécutées simultanément, chacune sur un élément SharePoint différent. Plusieurs workflows peuvent être exécutés sur un élément SharePoint donné à la fois.

Vous pouvez exécuter des workflows sur des documents ou des éléments de liste. Vous pouvez mettre un modèle de workflow à disposition sur un site via un processus appelé association, décrit ultérieurement dans cet article.

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

Bien que vous puissiez utiliser des workflows Windows SharePoint Services pour modéliser un nombre quelconque de processus métier uniques, il existe plusieurs étapes via lesquelles l'utilisateur peut interagir avec le modèle ou l'instance de workflow.

Pour que l'utilisateur puisse transférer les informations vers le workflow, le développeur doit fournir une interface à cette interaction à l'aide d'un formulaire. L'ajout de formulaires aux workflows vous permet de dynamiser et de flexibiliser vos workflows. Les formulaires vous permettent de rassembler des informations à partir d'utilisateurs à des périodes prédéfinies dans la vie d'un workflow, et permettent également aux utilisateurs d'interagir avec les tâches de ce workflow.

D'un point de vue technique, vous pouvez utiliser n'importe quelle technologie de formulaire avec les workflows WF, aussi longtemps que vos formulaires sont capables d'effectuer les opérations suivantes :

• Appel du modèle d'objet Windows SharePoint Services

• Génération des données nécessaires à l'envoi du modèle d'objet Windows SharePoint Services

• Réception et analyse des données nécessaires à partir du modèle d'objet Windows SharePoint Services

Toute information transmise vers le formulaire en chargement est formatée sous la forme d'une chaîne, comme le sont les données que le formulaire doit transmettre au modèle d'objet Windows SharePoint Services V3 lorsque l'utilisateur soumet le formulaire. Bien que cette chaîne soit généralement de type XML, vous pouvez utiliser n'importe quel format de données pouvant être formaté sous forme de chaîne, aussi longtemps que votre formulaire est capable de générer des chaînes dans ce format et d'analyser les chaînes qu'il reçoit.

Windows SharePoint Services prend en charge l'utilisation des formulaires ASP.NET 2.0. La façon dont ces formulaires sont implémentés dépend de l'outil de création de workflow utilisé par le développeur : Visual Studio 2005 Designer for Windows Workflow Foundation ou SharePoint Designer 2007. De plus, SharePoint Server 2007 permet aux développeurs d'intégrer les formulaires Microsoft Office InfoPath à leurs workflows. Ces formulaires InfoPath peuvent être hébergés dans les applications client Microsoft Office, telles que Microsoft Office Word, Microsoft Office PowerPoint, Microsoft Office Excel et InfoPath, ainsi que dans le navigateur client, et fournissent un environnement client plus complet. Pour plus d'informations sur la manière dont chaque outil de création de workflow implémente des formulaires de workflow, reportez-vous aux sections Formulaires ASP.NET dans les worflows Windows SharePoint Services, Formulaires InfoPath dans les workflows SharePoint Server et Formulaires ASP.NET dans les workflows SharePoint Designer.

Quel que soit le type de technologie utilisé par les formulaires, leur concept de fonctionnement est identique. Windows SharePoint Services montre le formulaire à l'utilisateur au moment approprié dans le workflow. L'utilisateur entre les informations, et soumet le formulaire.

En tant que développeur de workflow, vous êtes chargé de programmer les événements qui se produisent lorsque l'utilisateur soumet un formulaire. Dans la plupart des cas, votre formulaire appelle le modèle d'objet Windows SharePoint Services et la méthode appropriée pour transmettre les informations contenues dans le formulaire à l'instance de workflow correcte.

La chaîne d'informations peut se présenter sous n'importe quel format, à condition que le formulaire et l'activité de workflow soient programmés pour analyser la chaîne. Dans la plupart des cas, il est probable que les développeurs choisissent d'utiliser XML.

Windows SharePoint Services transmet les informations de la chaîne au moteur d'exécution de WF, à l'instance de workflow, et enfin à l'activité correcte dans l'instance de workflow. L'activité recevant les informations peut ensuite répondre, conformément à ce qui a été programmé. La figure 4 montre comment un formulaire s'intègre avec le workflow.

Figure 4. Intégration du formulaire avec le workflow

Les workflows Windows SharePoint Services utilisent trois types de formulaires :

• Formulaires d'association et d'initialisation Ces formulaires s'affichent pour que les utilisateurs les remplissent avant tout démarrage effectif du workflow. Vous pouvez utiliser ces formulaires pour permettre aux utilisateurs de définir des paramètres et d'autres informations relatives au workflow avant le démarrage de ce dernier.

• Formulaires de modification Les modifications sont des options permettant aux utilisateurs de modifier le workflow lors de son exécution sur un élément. Vous pouvez ensuite créer des formulaires de modification permettant aux utilisateurs de spécifier les paramètres de la modification.

• Formulaires de tâches Vous pouvez également spécifier des formulaires personnalisés pour les tâches de votre workflow, en fonction du type de tâche de workflow. Un type de contenu est affecté à chaque type de tâche de workflow 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 workflow donné.

Ces trois types de formulaires représentent les étapes prédéfinies auxquelles les utilisateurs peuvent interagir avec le workflow. Ces étapes seront abordées ultérieurement.

Points d'interaction de l'utilisateur avec les workflows

Examinons de plus près les différentes étapes auxquelles les utilisateurs peuvent interagir avec les workflows dans Windows SharePoint Services et SharePoint Server.

Association

L'association se produit lorsqu'un administrateur de site met à disposition le modèle de workflow sur une bibliothèque de documents, une liste ou un type de contenu spécifiques. À cette étape, l'administrateur du site personnalise le workflow pour cette bibliothèque de documents, cette liste ou ce type de contenu spécifiques en indiquant les informations sur les paramètres suivants :

• Un nom unique pour le workflow

• Méthode d'application du workflow à un élément donné : automatique, lorsque l'élément est créé ou modifié, ou manuelle ; et quels rôles (Administrateur ou Contributeur, par exemple) peuvent démarrer un workflow

• La liste des tâches, dans laquelle le workflow peut créer des tâches

• Le liste chronologique, dans laquelle le workflow peut stocker les événements de l'historique, conformément à ce qui a été défini par le workflow

Le développeur de workflow peut en outre permettre une personnalisation plus poussée du workflow via l'administration du site en définissant des paramètres spécifiques au workflow particulier. L'administrateur peut être amené à spécifier des paramètres, des valeurs par défaut et d'autres informations pour le workflow, car il s'applique à des éléments de la liste, de la bibliothèque ou du type de contenu avec lesquels l'administrateur les associe.

L'association d'un workflow se produit en réalité en dehors du workflow ; aucune instance du workflow n'est réellement démarrée lors de l'association. Windows SharePoint Services stocke plutôt les informations d'association dans une table d'association de workflows interne spéciale. Lorsque l'instance de workflow est effectivement démarrée, Windows SharePoint Services utilise les données d'association (et les données de lancement, le cas échéant) pour définir les paramètres de la nouvelle instance de workflow.

Lancement

Alors que l'association concerne le workflow, car elle s'applique à une liste, une bibliothèque ou un type de contenu spécifiques, le lancement concerne le workflow, car il s'applique à un élément SharePoint spécifique.

Le lancement se produit lorsqu'un utilisateur démarre effectivement une instance de workflow sur un élément spécifique. L'utilisateur fournit des informations personnalisées sur cet élément à ce workflow spécifique, si nécessaire, puis démarre le workflow.

Les développeurs de workflow peuvent utiliser le lancement pour permettre aux utilisateurs de remplacer ou d'ajouter les paramètres d'association définis par des administrateurs, ou de spécifier des paramètres ou des informations supplémentaires sur le workflow, car il s'applique à l'élément SharePoint donné. Tous les workflows ne nécessitent pas de lancement. En fait, un workflow défini pour démarrer automatiquement ne peut pas posséder de paramètres de lancement.

Le projet de workflow Windows SharePoint Services de Visual Studio 2005 Designer for Windows Workflow Foundation inclut une activité qui agit comme gestionnaire d'événements lorsque le workflow est lancé. Cette activité est la première de tout workflow Windows SharePoint Services.

Modification

Les modifications permettent aux utilisateurs de modifier les paramètres ou le flux d'une instance de workflow lors de son exécution. En tant que développeur, vous souhaiterez peut-être autoriser, à certains stades de votre workflow, les utilisateurs à modifier le workflow lors de son exécution. Par exemple, vous souhaiterez peut-être autoriser un utilisateur à affecter une tâche à une autre personne, voire ajouter une tâche spécifique au workflow. Les modifications sont des options permettant aux utilisateurs de modifier le workflow lors de son exécution sur un élément.

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

Tâches

Les activités de workflow effectuées par des personnes sont représentées sous formes de tâches dans les workflows Windows SharePoint Services.

En tant que créateur de workflows, vous pouvez spécifier le schéma des tâches. Par exemple, la liste des tâches pourrait inclure :

• Le titre de la tâche

• Le nom de la personne chargée de la tâche

• Le statut de la tâche

• La priorité de la tâche

• La date d'échéance de la tâche

• Un lien vers l'élément référencé

L'utilisateur peut ensuite modifier la tâche selon ses besoins. L'instance de workflow reçoit la notification de modifications apportées aux tâches de workflow et peut choisir d'y répondre conformément à ce qui a été spécifié dans le workflow.

Le projet de workflow Windows SharePoint Services de Visual Studio 2005 Designer for Windows Workflow Foundation inclut des activités qui créent, suppriment et mettent à jour des tâches, ainsi que des activités qui agissent comme gestionnaires d'événements lors de la création, la mise à jour ou la suppression de tâches.

réation de workflows de type SharePoint

Microsoft fournit deux éléments de développement pour la création de workflows pour Windows SharePoint Services : Visual Studio 2005 Designer for Windows Workflow Foundation et Office SharePoint Designer 2007. Étant donné que chaque outil de création génère des workflows avec des attributs et des fonctionnalités différents, il peut s'avérer utile d'examiner de plus près chacun de ces outils.

La figure 5 montre les différentes étapes à réaliser pour créer, déployer, associer et exécuter un workflow avec chacun des outils de création. De manière générale, les principales différences entre les deux outils sont les suivantes :

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

• La création de workflows dans SharePoint Designer est probablement effectuée par une personne autre qu'un développeur professionnel, un concepteur Web ou travailleur de connaissances, par exemple, qui souhaite créer un workflow pour une liste ou une bibliothèque de documents spécifique. Dans ce cas, le concepteur est limité aux activités de workflow sur la liste des contrôles fiables, et le workflow ne peut pas inclure de code personnalisé. Le créateur de workflows déploie le modèle de workflow directement vers la liste ou la bibliothèque de documents dans le cadre du processus de création de workflows.

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

Figure 5. Création de workflows, déploiement et processus de lancement

Création de workflows SharePoint dans Visual Studio 2005

Visual Studio 2005 Designer for Windows Workflow Foundation est un complément pour Visual Studio 2005. Il permet de développer rapidement des workflows grâce à une interface graphique qui exploite les connaissances de développeur de l'environnement de développement Visual Studio.

Visual Studio 2005 Designer for Windows Workflow Foundation est un outil permettant de créer le workflow rapidement et de façon intégrée au développement du code encapsulant vos processus métier. Pour ce faire, Visual Studio 2005 Designer for Windows Workflow Foundation fournit une interface graphique dotée de commandes intuitives, hébergée dans l'environnement de développement familier de Visual Studio. Il comporte les fonctionnalités suivantes :

• Une surface de conception par glisser-déplacer qui vous permet d'assembler des workflows personnalisés à partir d'activités de workflow prédéfinies que vous faites glisser depuis la Boîte à outils

• Une interface permettant de travailler sur votre balisage de workflow à l'aide d'outils graphiques intuitifs

• Intégration avec la fenêtre Propriétés pour permettre aux développeurs de configurer les propriétés d'activités de workflow via l'interface graphique ou directement dans le fichier code-beside, et synchronisation des deux

• Débogage de vos workflows par association avec le processus Windows SharePoint Services, avec définition de points d'arrêt dans votre workflow

• Possibilité d'associer des gestionnaires d'erreurs, de compensation et d'événements à des activités, et de « commenter » graphiquement les activités

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 vous aider davantage dans le développement de workflows, Microsoft fournit deux packs de modèles de projets Visual Studio à utiliser avec Visual Studio 2005 Designer for Windows Workflow Foundation : un pack dédié au workflows Windows SharePoint Services, l'autre dédié aux workflows pour SharePoint Server.

Le modèle de projet de workflow Windows SharePoint Services contient une référence à l'espace de noms Windows SharePoint et inclut des activités de workflow conçues spécifiquement pour l'environnement Windows SharePoint Services. Ces activités personnalisées vous permettent de réaliser des fonctions communes à 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 courrier électronique et la possibilité de modifier le workflow.

Le projet de workflow SharePoint Server contient l'intégralité du modèle de projet de workflow Windows SharePoint Services, ainsi qu'une référence à l'espace de noms SharePoint Server, et une fonctionnalité supplémentaire de gestion de tâches workflow dans l'environnement de travail SharePoint Server.

Le processus de développement de workflows dans Visual Studio

Lorsque vous développez des workflows pour Windows SharePoint Services ou Office SharePoint Server avec Visual Studio 2005 Designer for Windows Workflow Foundation, vous suivez généralement les étapes de base suivantes :

• Création du workflow, avec le fichier code-beside, si nécessaire, dans Visual Studio 2005 Designer for Windows Workflow Foundation.

• Conception et publication des formulaires que vous souhaitez utiliser avec votre workflow.

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

• Compilation des fichiers de workflow en un assembly .NET.

• Regroupement en package de l'assembly de workflow et de la définition de workflow et déploiement de ceux-ci à l'aide des fonctionnalités de Windows SharePoint Services.

• Débogage de l'assembly de workflow live avec Visual Studio 2005 Designer for Windows Workflow Foundation.

• Recompilation et déploiement de l'assembly de workflow selon les besoins pour corriger les bogues détectés.

Les sections ci-dessous présentent chacune de ces étapes de développement.

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

Lorsque vous sélectionnez un nouveau projet de workflow 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 permettant d'assembler des workflows par glisser-déposer de diverses activités de la Boîte à outils.

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

Lorsque vous faites glisser une activité spécifique sur votre workflow, Visual Studio 2005 Designer for Windows Workflow Foundation affiche les emplacements valides pour cette activité dans le workflow. Vous ne pouvez pas placer d'activité à un emplacement où elle ne serait pas valide. Par exemple, vous ne pouvez pas positionner d'activité Envoyer comme première activité dans une branche d'activités Ecouter. Comme le montre la figure 7, Visual Studio 2005 Designer for Windows Workflow Foundation affiche des icônes en forme de signe plus vert pour indiquer les positions valides de l'activité spécifique.

Figure 7. Positions valides pour une activité de workflow

Lors de la conception graphique de votre workflow, Visual Studio 2005 Designer for Windows Workflow Foundation génère en réalité un balisage correspondant.

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

Définition des propriétés du workflow

Après avoir ajouté l'activité au workflow, vous devez définir ses propriétés pour qu'elle soit valide dans le workflow. Pour ce faire, utilisez la fenêtre standard Propriétés de Visual Studio. Le type de données que vous pouvez spécifier doit être accepté par la propriété : valeurs littérales, variables ou noms de méthodes.

Si vous souhaitez spécifier une variable pour la propriété, vous pouvez entrer le nom de la variable dans la fenêtre Propriétés. Visual Studio 2005 Designer for Windows Workflow Foundation déclare alors automatiquement la variable dans le fichier code-behind, ou déclare la variable dans le fichier code-behind, puis la sélectionne dans la fenêtre Propriétés.

Certaines propriétés d'activité sont essentiellement des références à des méthodes dans le fichier code-beside conformes à une signature spécifique. Comme pour la plupart des noms de variables, vous pouvez entrer le nom de la méthode dans la fenêtre 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 la sélectionner dans la fenêtre Propriétés.

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

Activités du gestionnaire

Un workflow peut comporter plusieurs points de défaillance potentiels. Il est important de suivre l'état d'un workflow et de signaler les erreurs lorsqu'elles se produisent, afin que vous puissiez résoudre les problèmes de manière précise et avec un minimum d'efforts. Il est aussi important qu'un workflow conserve l'intégrité d'un ensemble d'actions étroitement liées, afin que l'intégralité de l'opération puisse être annulée si seule une partie de l'opération se déroule. Vous pouvez utiliser les activités FaultHandlerActivity, TransactionScopeActivity, CompensationHandlerActivity et CancellationHandlersActivity pour gérer les erreurs, conserver l'état d'un workflow et résoudre les problèmes qui se présentent.

Une activité FaultHandlersActivity peut être considérée comme un bloc try en langage C auquel vous pouvez associer un ensemble ordonné d'activités FaultHandlerActivity qui agissent comme des gestionnaires d'exceptions. Ces exceptions peuvent être considérées comme des blocs catch en 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é.

Des activités EventHandlersActivity peuvent également répondre à des événements si des gestionnaires d'événements sont ajoutés à une activité EventHandlerScopeActivity. D'un point de vue 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 avec succès.

Formulaires ASP.NET dans les workflows Windows SharePoint Services

Comme mentionné précédemment, vous pouvez utiliser ASP.NET pour créer les formulaires utilisés avec votre workflow Windows SharePoint Services. Ces formulaires s'affichent ensuite dans l'interface utilisateur Windows SharePoint Services aux étapes appropriées du workflow.

Les formulaires de workflow sont liés tardivement à l'assembly de workflow via les informations fournies dans le fichier XML de définition du modèle de workflow. Le schéma de définition du modèle de workflow contient des éléments pour indiquer l'URL des différents types de formulaires utilisables avec les workflows Windows SharePoint Services. Cela permet de créer des éléments pour les formulaires pour toute modification de workflow personnalisé, ainsi que des formulaires pour les différents types de tâches SharePoint utilisées dans le workflow.

L'assembly de workflow ne contient généralement aucune information ou lien avec les formulaires de workflow. Les développeurs peuvent modifier les formulaires de workflow à utiliser en éditant simplement le fichier XML de définition de workflow, sans qu'il soit nécessaire de recompiler l'assembly de workflow. La seule exception concerne les modifications de workflow ; chaque activité permettant une modification de workflow doit contenir le GUID du formulaire pour cette modification de workflow.

Formulaires InfoPath dans les workflows SharePoint Server

Même si vous pouvez utiliser des formulaires de workflow ASP.NET dans les workflows SharePoint Server, SharePoint Server vous permet d'étendre vos formulaires de workflow et de les afficher dans des applications client Microsoft Office.

Vous pouvez utiliser les formulaires InfoPath avec vos workflows. InfoPath vous permet de créer des formulaires symétriques ; c'est-à-dire des formulaires dont l'apparence et le fonctionnement sont identiques s'ils s'affichent dans l'interface Web SharePoint Server ou dans une application client Microsoft Office telle que Word, Excel ou PowerPoint. L'expérience, qui s'avère plus riche en termes d'interaction, permet à l'utilisateur d'interagir avec le workflow directement dans l'application client, plutôt que de devoir quitter le client et passer à l'interface Web SharePoint Server. Et en tant que développeur, vous n'êtes pas obligé de créer deux formulaires distincts, l'un à utiliser sur le serveur et l'autre sur le client, pour fournir à l'utilisateur cette intégration d'application client.

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

SharePoint Server utilise Office Forms Services, un environnement d'exécution serveur pour les formulaires InfoPath, pour héberger des formulaires de workflow. Office Forms Services utilise les formulaires créés dans l'application client InfoPath et les affiche dans une infrastructure ASP.NET, qui fait office d'environnement d'exécution pour le formulaire. Cet environnement est idéal pour la modification de formulaires, car il correspond à l'application client InfoPath.

Pour plus d'informations sur Office Forms Services, reportez-vous au Kit de développement de logiciels Microsoft Office SharePoint Server 2007.

Remarque Étant donné que les applications client Office 2007 telles que Word, PowerPoint et Excel incluent des fonctionnalités d'hébergement de formulaires InfoPath, l'utilisateur ne doit pas obligatoirement disposer de l'application client InfoPath sur son ordinateur pour tirer profit de cette intégration complète.

Affichage de formulaires de workflow InfoPath

SharePoint Server emploie la même technique de base pour afficher tous les formulaires de workflow InfoPath personnalisés, y compris les formulaires relatifs aux tâches d'association, de lancement de modification ou d'édition.

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

Les pages ASPX qui contiennent le composant Web Part de Office Forms Services sont incluses dans SharePoint Server.

Définition de formulaires de workflow InfoPath

Une nouvelle fois, les formulaires personnalisés que vous souhaitez utiliser doivent être utilisés dans la définition de modèle de workflow plutôt que dans le workflow. Dans la plupart des cas, elle implique le paramétrage de deux éléments. Vous définissez d'abord l'URL du formulaire relative au processus de ce workflow (association, lancement, édition, etc) à la page d'hébergement ASPX appropriée incluse dans SharePoint Server. Ensuite, vous ajoutez un élément spécifiant l'URN du formulaire InfoPath personnalisé pour ce type de processus de workflow.

Envoi d'informations à l'aide de formulaires de workflow InfoPath

Pour que la page ASPX d'hébergement reçoive des données provenant du formulaire hébergé, le développeur ajoute un bouton Envoyer au formulaire InfoPath. Ce bouton utilise une règle de soumission de données via une connexion de données à l'environnement d'hébergement. Cette connexion renvoie automatiquement les données à la page ASPX d'hébergement lorsque l'utilisateur clique sur le bouton Envoyer. La page ASPX d'hébergement gère ensuite l'analyse des données et les renvoie à la bibliothèque de workflows ou de documents, selon le cas.

Déploiement de workflows

Lorsque vous avez terminé la définition du workflow, vous pouvez choisir de le compiler comme workflow ou activité.

À la fin de la compilation, vous pouvez utiliser la fonctionnalité SharePoint pour packager et déployer l'assembly de workflow et les fichiers nécessaires.

Le packaging de fonctionnalités est un moyen d'encapsuler les solutions et les fonctionnalités Windows SharePoint Services pour faciliter le déploiement. Vous obtenez ainsi un mécanisme permettant aux développeurs de packager les fichiers nécessaires à une solution, tels que des workflows, des composants WebPart, des listes et des définitions de site, afin de faciliter la distribution et le déploiement. Les développeurs compilent les fichiers nécessaires en un seul fichier .wsp, qui est essentiellement un fichier .cab contenant un manifeste répertoriant son contenu. Pour plus d'informations sur les fonctionnalités SharePoint, reportez-vous au Kit de développement Microsoft Windows SharePoint Services V3 (SDK).

Chaque modèle de workflow que vous déployez doit contenir un fichier de définition de modèle de workflow. Une définition de modèle de workflow est un fichier XML qui contient les informations que Windows SharePoint Services nécessite pour instancier et exécuter le workflow, telles que :

• Le nom, le GUID et la description du modèle de workflow

• L'assembly

• Les URL (ou les URN pour les formulaires IP) de tout formulaire personnalisé utilisé avec ce modèle de workflow

• Éventuellement, les noms du workflow, du moteur de workflow et des assemblys de services d'hôte à utiliser lors de l'exécution du workflow

• Éventuellement, les classes correctes comprises dans ces assemblys à appeler

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

Après le déploiement vers un site, le workflow est disponible sous la forme de modèle de workflow, que les administrateurs SharePoint peuvent associer aux bibliothèques de documents et aux listes sur ce site.

Débogage de workflows

Après avoir déployé votre assembly de workflow, vous pouvez procéder au débogage du workflow en ouvrant le projet correspondant et en le joignant au processus Windows SharePoint Service w3wp.

Étant donné que Visual Studio 2005 Designer for Windows Workflow Foundation est hébergé par Visual Studio, vous pouvez tirer avantage de toutes les fonctions de débogage de Visual Studio. Vous pouvez insérer des points d'arrêt à la fois dans le code que vous écrivez dans le fichier code-beside et sur les activités de workflow dans la surface de conception.

Remarque Pour faciliter le débogage, nous vous recommandons fortement de développer vos modèles de workflow sur le serveur vers lequel vous souhaitez les déployer.

Visual Studio 2005 Designer for Windows Workflow Foundation ne prend pas seulement en charge les fonctionnalités de débogage de Visual Studio standard, telles que les fenêtres des points d'arrêt et de la pile d'appels, mais inclut également une plage d'indicateurs visuels qui fournissent des informations au cours du processus de débogage. Vous pouvez également ajouter des points d'arrêt à une activité de workflow lors du débogage de l'assembly.

Vous pouvez procéder aux opérations pas à pas détaillé, pas à pas sortant et pas à pas principal pour parcourir le code de workflow.

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

• Débogage juste-à-temps des exceptions runtime dans le processus d'hébergement

• Débogage juste-à-temps par la sélection d'un processus dans le Gestionnaire de tâches

Pour plus d'informations sur le débogage à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation, reportez-vous au Kit de développement de logiciels Windows Workflow Foundation (SDK).

Remarque Le Kit de développement de logiciels 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 des workflows SharePoint dans SharePoint Designer 2007

Lorsque vous créez un workflow dans Office SharePoint Designer 2007, vous créez directement ce workflow par rapport à une liste spécifique ou une bibliothèque de documents dans Windows SharePoint Services, et effectuez une liaison de données à celles-ci. Vous employez une liste prédéfinie d'activités de workflow sans utiliser de code. Le workflow que vous concevez n'est pas compilé sous la forme d'assembly, mais enregistré en tant que fichiers source jusqu'à ce que Windows SharePoint Services le compile à sa première exécution.

Ce type d'approche présente plusieurs avantages :

• Les workflows peuvent être développés et testés rapidement.

• Puisque le workflow est spécifique à une liste donnée, son processus de déploiement est beaucoup moins compliqué.

• Et pour la même raison, les problèmes de sécurité sont moins complexes.

• Puisqu'ils ne sont pas compilés en assemblys, les workflows créés dans SharePoint Designer peuvent être déployés vers des serveurs sur lesquels la stratégie de sécurité administrative interdit les assemblys de code personnalisés.

Remarque Les workflows créés dans SharePoint Designer sont assemblés à partir d'une « liste saine » d'activités prédéfinies, a priori approuvées par les administrateurs pour exécuter les serveurs.

• Les workflows 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 workflows créés dans SharePoint Designer diffèrent de ceux créés à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation sur plusieurs points :

• Un workflow créé dans SharePoint Designer ne peut pas être déployé dans plusieurs listes. Il est valide uniquement pour la liste qui lui est destinée.

• Puisque vous créez le workflow directement par rapport à une liste, il est associé à cette liste au moment de la conception. Par conséquent, les workflows créés dans SharePoint Designer ne passent pas par une étape d'association.

• Des modifications de workflow ne sont possibles que pour les workflows créés dans SharePoint Designer.

• Vous ne pouvez pas créer de workflow par rapport au 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 à SharePoint Designer 2007.

Exécution de workflows créés dans SharePoint Designer 2007

Étant qu'ils ne contiennent pas de code personnalisé, les workflows créés dans Office SharePoint Designer ne sont pas compilés, ni déployés en tant qu'assemblys. À la place, ils sont enregistrés comme leurs fichiers sources dans Windows SharePoint Services, puis compilés dans une mémoire uniquement en cas de besoin.

Pour chaque site, les workflows de ce type sont stockés dans une bibliothèque de documents distincte. Cette bibliothèque de documents contient un dossier pour chaque workflow créé dans SharePoint Designer. Le dossier contient tous les fichiers source nécessaires au workflow, y compris :

• Le fichier de balisage de workflow

• Le fichier de règles de workflow

• Les formulaires ASPX pour tous les formulaires de workflow personnalisés nécessaires

Windows SharePoint Services inclut un compilateur juste-à-temps pour compiler les fichiers source dans un workflow à sa première exécution sur un élément. Windows SharePoint Services conserve le workflow compilé en mémoire en cas de rappel, de la même manière que les serveurs conservent des pages .aspx compilées en mémoire pour accélérer les performances d'exécution au prochain rappel d'une page.

À chaque démarrage d'un workflow sur un élément, Windows SharePoint Services détermine s'il a été développé en tant qu'assembly ou en tant que fichiers source. Si un assembly de workflow existe, Windows SharePoint Services l'appelle pour créer l'instance de workflow. Si le workflow a été déployé en tant que fichiers source, Windows SharePoint Services détermine s'il possède déjà un workflow compilé à partir de ces fichiers source en mémoire. Dans ce cas, Windows SharePoint Services appelle le workflow compilé conservé en mémoire pour créer l'instance de workflow. Dans le cas contraire, Windows SharePoint Services utilise son compilateur juste-à-temps pour compiler les fichiers source dans un workflow en mémoire, qu'il appelle ensuite pour créer l'instance de workflow.

Processus de développement du workflow dans SharePoint Designer 2007

Pour améliorer la rapidité de conception et de déploiement de workflows, le processus de développement de SharePoint Designer est simplifié par rapport à Visual Studio.

De manière générale, lorsque vous développez des workflows pour Windows SharePoint Services ou SharePoint Server à l'aide de Visual Studio 2005 Designer for Windows Workflow Foundation, vous suivez les étapes de base suivantes :

• Création du workflow par l'assemblage et la configuration des activités et conditions prédéfinies disponibles dans SharePoint Designer.

• Génération automatique par SharePoint Designer de formulaires ASP.NET à des fins de lancement de workflow et de tâches personnalisées SharePoint, si nécessaire.

• Personnalisation des formulaires de workflow, si nécessaire.

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

Les sections ci-dessous présentent chacune de ces étapes de développement.

Création de workflows à l'aide de SharePoint Designer 2007

SharePoint Designer utilise une interface guidée par un assistant qui permet aux utilisateurs d'assembler des séquences de workflow provenant d'activités prédéfinies. Les utilisateurs sélectionnent les activités dans une liste prédéterminée et les configurent à l'aide de l'interface SharePoint Designer. Ces activités peuvent être identiques aux activités contenues dans Visual Studio 2005 Designer for Windows Workflow Foundation ; il n'existe aucune différence entre les deux outils.

Dans SharePoint Designer, cependant, chaque activité apparaît en tant qu'action, représentée par une phrase qui contient des variables que l'utilisateur peut configurer à l'aide des menus déroulants et des boîtes de dialogue de recherche Les utilisateurs peuvent également sélectionner les conditions, qui sont des clauses conditionnelles configurables qui dirigent le flux du workflow.

Lorsque l'utilisateur sélectionne et configure les conditions et les actions dans l'interface de workflow, SharePoint Designer génère les deux fichiers qui représentent effectivement la classe de workflow :

• Le fichier de balisage de workflow, qui contient le balisage décrivant les activités incluses dans le workflow

• Le fichier de règles de workflow, qui contient la logique métier du workflow dans le formulaire de règles déclaratives, plutôt que dans le code

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

Comme décrit précédemment, les concepteurs de workflow de SharePoint Designer ne peuvent pas créer d'activité utilisable dans leurs workflows. À la place, ils sont limités aux activités et aux conditions mises à disposition sur la liste des contrôles fiables (a priori approuvée pour un administrateur serveur) qui apparaît dans SharePoint Designer.

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

Les développeurs peuvent créer des activités et des conditions et les mettre à disposition sur une liste fiable. Pour ce faire, les développeurs doivent :

• Créer l'activité ou la condition, la compiler en tant qu'assembly avec nom fort, puis la déployer dans le cache de l'assembly global.

• Ajouter l'activité ou la condition à la liste des actions fiables dans le fichier web.config.

• Dans le fichier WSS.Actions, situé dans le dossier de workflow, ajouter des règles et des paramètres pour la phrase qui représente l'activité ou la condition dans l'interface utilisateur de SharePoint Designer. Ce balisage spécifie la manière dont l'activité ou la condition apparaît et s'exécute dans l'interface, car ces informations ne sont pas contenues dans l'assembly de l'activité ou de la condition.

Pour plus d'informations sur le déploiement personnalisé des activités et des conditions, reportez-vous à l'aide de SharePoint Designer.

Formulaires ASP.NET dans les workflows SharePoint Designer

Vous pouvez créer une étape de lancement de votre workflow dans SharePoint Designer. Dans ce cas, SharePoint Designer génère automatiquement un formulaire de lancement à l'aide de ASP.NET, selon les spécifications de votre lancement

De même, vous pouvez créer des tâches SharePoint personnalisées pour votre workflow. Une fois encore, 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 de SharePoint avec les fichiers source de workflow. Vous pouvez les ouvrir et les personnaliser comme n'importe quel formulaire aspx.

Remarque SharePoint Designer 2007 ne propose pas l'intégration avec les formulaires InfoPath.

Déploiement de workflows avec SharePoint Designer 2007

Étant donné que vous créez des workflows par rapport à une liste spécifique, le déploiement de workflows créés dans Office SharePoint Designer constitue un processus beaucoup plus simple que pour les workflows créés dans Visual Studio 2005 Designer for Windows Workflow Foundation. SharePoint Designer gère le déploiement du workflow par rapport à la liste spécifiée.

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

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

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

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

Le tableau suivant présente une comparaison entre les fonctionnalités offertes par Visual Studio 2005 Designer for Windows Workflow Foundation et Office SharePoint Designer 2007, ainsi que les workflows que vous pouvez créer.

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

Visual Studio 2005 Designer for Windows Workflow Foundation	SharePoint Designer 2007
Possibilité d'écrire des workflows pour Windows SharePoint Services ou SharePoint Server	Possibilité d'écrire des workflows pour Windows SharePoint Services ou SharePoint Server
Le fichier code-behind permet aux développeurs d'écrire du code Visual C# ou Visual Basic .NET personnalisé pour exprimer une logique métier	Aucun fichier code-behind ; le fichier de règles de workflow encapsule de manière déclarative la logique métier
Génère un fichier de balisage de workflow	Génère un fichier de balisage de workflow
Le workflow est créé comme modèle, qui peut être associé à plusieurs sites et listes	Le workflow est créé et lié aux données pour la liste spécifique au moment du design
Le fichier de balisage de workflow, ou le balisage et les fichiers code-behind, sont compilés dans un assembly de workflow	Le balisage de workflow, les règles de workflow et le fichier de prise en charge sont enregistrés, non compilés, dans une bibliothèque de documents spécifique sur le site
Le modèle de workflow doit être associé à chaque liste sur laquelle il doit être disponible	Une association se produit lorsque le workflow est autorisé sur la liste spécifique ; aucune association supplémentaire n'est nécessaire ou possible
Peut utiliser toute technologie de formulaire. Par exemple, les formulaires ASP pour les workflows Windows SharePoint Services ou pour les formulaires InfoPath pour les workflows SharePoint Server	Génère automatiquement des formulaires ASP.NET, que vous pouvez ensuite personnaliser
Peut inclure des modifications de workflow	Les modifications de workflow ne sont pas disponibles
Peut utiliser des formulaires InfoPath symétriques personnalisés, qui permettent l'intégration de client Office de formulaires de workflow personnalisés	Intégration de formulaires InfoPath non disponible
Peut générer des activités personnalisées à des fins d'inclusion dans les workflows	Doit utiliser les activités fournies
Regroupe l'assembly de workflow et la définition de workflow dans une fonctionnalité SharePoint, et effectue le déploiement sur le site	Gère automatiquement le déploiement dans une liste spécifique
Peut utiliser le formulaire de lancement pour collecter les informations provenant de l'utilisateur au démarrage du workflow	Peut utiliser le formulaire de lancement pour collecter les informations provenant de l'utilisateur au démarrage du workflow
Peut utiliser les formulaires personnalisés afin que les utilisateurs interagissent avec les tâches SharePoint	Peut utiliser les formulaires personnalisés afin que les utilisateurs interagissent avec les tâches SharePoint
Débogage de Visual Studio disponible	Pas de débogage pas-à-pas disponible
Peut générer des workflows d'état et des workflows séquentiels	Peut générer des workflows séquentiels uniquement

Structure de workflow dans Windows SharePoint Services

La figure 8 montre comment les différents éléments de la structure de workflow de Windows SharePoint Services sont joints après qu'un modèle de workflow a été créé, déployé et associé au type de contenu spécifique, à une liste ou à une bibliothèque de documents.

Lorsque vous associez un modèle de workflow à un type de contenu donné, une liste ou une bibliothèque de documents, Windows SharePoint Services écrit les informations de paramètres d'association définis par l'administrateur dans une table d'association de workflow au niveau de la batterie de serveurs. L'entrée dans cette table d'association établit une liaison entre le type de contenu spécifique, la liste ou la bibliothèque de documents et la définition du modèle de workflow du workflow associé. Les informations contenues dans la définition du modèle de workflow, quant à elles, comprennent les références à l'assembly de workflow, ainsi que des formulaires personnalisés utilisés dans le workflow.

Pour les workflows autorisés dans SharePoint Designer 2007, le Concepteur écrit automatiquement les informations relatives aux paramètres d'association dans la table d'association de workflow, puis génère et installe la définition du modèle de workflow. De même, le workflow est enregistré dans une bibliothèque de documents de workflow au niveau du site, non pas en tant qu'assembly compilé, mais en tant que fichiers sources de balisage et de règles de workflow.

Figure 8. Structure de composant de workflow dans Windows SharePoint Services

Utilisation d'un espace de noms de workflow

Une fois le déploiement de votre solution de workflow terminé, vous pouvez utiliser le modèle d'objet Windows SharePoint Services pour demander des processus de workflow et effectuer par programmation des actions de workflow, telles que l'ajout d'un workflow à une liste ou le démarrage d'un workflow pour un élément.

Objets Microsoft.Windows.SharePoint.Workflow principaux

L'espace de nom Microsoft.Windows.SharePoint.Workflow représente la fonctionnalité de workflow contenue dans Windows SharePoint Services.

L'objet SPWorkflowTemplateCollection représente les modèles de workflow en cours de déploiement sur un site. Chaque objet SPWorkflowTemplate représente un modèle de workflow et contient des propriétés permettant d'obtenir ou de définir des informations concernant le modèle, telles que les données d'instanciation, ainsi que l'historique et la liste des tâches relatifs au modèle.

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

• Le nom ou l'ID du modèle de workflow

• Le nom que vous souhaitez donner au workflow

• Le nom ou l'ID de la liste de tâches que vous souhaitez utiliser avec ce workflow

• L'historique du workflow

À l'instar d'un ajout de workflow via l'interface utilisateur, cette méthode ajoute à la liste une colonne d'état relative au workflow. Utilisez la méthode SPList.RemoveWorkflowAssociation pour supprimer un modèle de workflow de la liste.

L'objet SPWorkflowAssociationCollection représente la table d'association de workflow interne pour un site. En d'autres termes, il représente les workflows actuellement associés sur les listes sur un ensemble de sites, ainsi que les informations d'association correspondantes. Chaque objet SPWorkflowAssociation représente un modèle de workflow associé à une liste spécifique et contient les propriétés qui renvoient des informations personnalisées relatives à l'association, indiquant si le workflow est activé, si le workflow a été modifié et désignant la liste à laquelle le workflow a été associé, ainsi qu'une référence à l'objet SPWorkflowTemplate qui sert de base pour cet objet SPWorkflowAssociation.

La propriété SPWorkflowAssociation.IsDeclarative renvoie la valeur True pour les workflows qui ont été enregistrés en tant que fichiers non compilés, tels que les workflows autorisés dans SharePoint Designer.

L'objet SPWorkflowCollection représente les instances de workflow exécutées ou en cours d'exécution sur un élément spécifique de la liste. Chaque objet SPWorkflow contient des propriétés qui renvoient des informations relatives à l'instance de workflow, indiquant si le workflow est terminé et spécifiant son état interne et le modèle de workflow sur lequel il se base. De plus, chaque workflow contient un ensemble de tâches pour le workflow, appelé SPWorkflowTaskCollection.

Utilisez la propriété SPListItem.Workflows pour renvoyer un objet SPWorkflowCollection qui représente les workflows en cours d'exécution pour cet élément de liste.

Gestion par programmation des instances de workflow en cours d'exécution

Les utilisateurs interagissent avec les workflows en cours d'exécution individuellement sur des éléments via l'interface utilisateur Windows SharePoint Services. Cependant, Windows SharePoint Services offre des fonctionnalités permettant de contrôler de manière centralisée les instances en cours d'exécution des workflows sur l'ensemble de la batterie de serveurs via le modèle d'objet. Utilisez l'objet SPWorkflowManager pour gérer les instances en cours d'exécution des workflows sur l'ensemble de la batterie 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 gérer l'instance de workflows en cours d'exécution sur l'ensemble de la batterie de serveurs. Utilisez l'objet SPWorkflowManager pour :

• Démarrer, exécuter ou annuler un workflow.

• Renvoyer tous les workflows en cours d'exécution sur un élément spécifique.

• Annuler toutes les instances de workflow en fonction d'un modèle de workflow spécifique dans une liste.

• Effectuer d'autres opérations de gestion de workflow.

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

La figure 9 illustre 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 V3 héberge Windows Workflow Foundation, ce qui vous permet de joindre des processus métier personnalisés, mis en œuvre en tant que workflow de machine d'état ou que workflow séquentiel pour les éléments SharePoint. Cette mise en œuvre inclut la possibilité de créer des workflows personnalisés, complétés par l'intégration de formulaires pour l'interaction de l'utilisateur. SharePoint Server 2007 étend ces fonctionnalités de workflow en offrant une intégration dans des formulaires InfoPath symétriques qui peuvent être hébergés dans des applications client Office, telles que Word, PowerPoint, Excel et InfoPath.

Microsoft offre deux outils puissants permettant d'autoriser des workflows pour Windows SharePoint Services. Visual Studio 2005 Designer for Windows Workflow Foundation est un complément de Visual Studio 2005 qui offre la possibilité de développer des modèles de workflow, complétés avec un code personnalisé que vous pouvez déployer vers plusieurs sites et listes. Vous pouvez également utiliser SharePoint Designer pour développer et déployer rapidement des workflows spécifiques à la liste depuis une liste prédéfinie d'activités de workflow.

Dans chacun des cas, une fois le déploiement de votre solution de workflow terminé, vous pouvez utiliser le modèle d'objet Windows SharePoint Services pour demander des processus de workflow et exécuter des actions de workflow par programmation.

Ressources supplémentaires

• Microsoft Office Developer Center (en anglais)

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