Planifier pour créer des flux de travail (SharePoint Server 2010)

S’applique à : SharePoint Foundation 2010, SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

Un flux de travail se compose essentiellement de deux éléments : les formulaires utilisés pour interagir avec les utilisateurs et la logique définissant le comportement du flux de travail. Pour comprendre la façon dont les flux de travail sont créés, il faut connaître ces deux éléments.

Le flux de travail communique avec les utilisateurs via un navigateur Web, par conséquent, il dépend de Microsoft ASP.NET pour afficher ses formulaires. De ce fait, les formulaires sont définis en tant que pages ASPX. Un flux de travail peut éventuellement afficher ses propres formulaires à quatre stades de son cycle de vie :

• Association : lorsqu'un administrateur associe un modèle de flux de travail à une bibliothèque ou liste de documents particulière, il se peut qu'il puisse définir des options à appliquer à chaque instance de flux de travail créée à partir de cette association. Si un auteur de flux de travail choisit d'autoriser cette action, il doit fournir un formulaire permettant à l'administrateur de spécifier ces informations.

• Lancement : l'initiateur d'un flux de travail peut être autorisé à spécifier des options lorsqu'il démarre une instance d'exécution. Dans le scénario d'approbation décrit plus haut, par exemple, les options permettent notamment de spécifier la liste des participants du flux de travail et de définir le délai dont chacun d'eux dispose pour effectuer sa tâche. Si un flux de travail le permet, son auteur doit fournir un formulaire pour permettre à l'initiateur de définir ces options.

• Fin de tâche : l'instance du flux de travail en cours d'exécution doit afficher un formulaire aux participants du flux de travail pour leur permettre d'effectuer leur tâche. Il s'agit du formulaire ayant servi aux approbateurs du scénario antérieur pour faire des commentaires sur le document et d'indiquer leur approbation ou rejet.

• Modification : le créateur d'un flux de travail peut autoriser sa modification au cours de son exécution. Par exemple, un flux de travail peut permettre l'ajout de nouveaux participants une fois son exécution démarrée ou l'extension de l'échéance pour terminer les tâches. Si cette option est utilisée, le flux de travail doit afficher un formulaire à ce stade pour permettre à un participant de spécifier les modifications à apporter.

Les flux de travail créés à l'aide de Microsoft SharePoint Server 2010 peuvent utiliser des formulaires créés via InfoPath. Une logique de flux de travail est toujours définie en tant que groupe d'activités, de même que tout flux de travail reposant sur Windows Workflow Foundation (WF). Pour spécifier la logique et les formulaires d'un flux de travail, Microsoft fournit deux outils distincts, chacun ciblant un public différent. Les développeurs de logiciel peuvent utiliser la fonctionnalité Workflow Designer de Windows Workflow Foundation. Cet outil s'intègre à la version professionnelle de Visual Studio 2010 et fournit un environnement graphique pour organiser les activités dans les flux de travail. Des employés de l'information, constituant un groupe moins technique, peuvent utiliser Microsoft SharePoint Designer 2010 pour créer des flux de travail sans écrire de code. Les deux sections suivantes traitent de la création de flux de travail à l'aide de chacun de ces outils..

Création de flux de travail avec Visual Studio 2010 et WF Workflow Designer

Les flux de travail utilisant SharePoint Server peuvent utiliser les formulaires de flux de travail Microsoft InfoPath 2010 au lieu des formulaires aspx. Pour créer ces formulaires, l'auteur de flux de travail utilise Microsoft InfoPath. Cet outil fournit un éditeur graphique qui permet à un auteur de définir le contenu du formulaire. Les développeurs qui préfèrent effectuer tout leur travail dans l'environnement Visual Studio peuvent utiliser la version professionnelle de Visual Studio 2010.

Une fois créés, les formulaires de flux de travail InfoPath sont associés à un flux de travail via un fichier workflow.xml, exactement comme pour les formulaires ASP.NET. Cependant, contrairement aux formulaires ASP.NET, les développeurs n'ont pas besoin d'écrire du code personnalisé pour déplacer des informations entre les formulaires de flux de travail InfoPath et un flux de travail. Au lieu de cela, SharePoint Server et InfoPath fournissent ce lien, facilitant ainsi le travail des personnes qui créent des flux de travail.

À de nombreux égards, un flux de travail s'apparente à un diagramme de flux. Il est donc logique de fournir un outil graphique qui permet aux développeurs de spécifier les actions d’un flux de travail. Cet outil fait partie des outils de SharePoint Workflow dans la version professionnelle de Visual Studio 2010, ce qui est un type de projet utilisant WF Workflow Designer et qui ajoute une prise en charge de déploiement et des formulaires. Les développeurs peuvent utiliser WF Workflow Designer pour définir graphiquement des activités d'un flux de travail et l'ordre dans lequel ces activités doivent être exécutées. L'écran ci-après affiche un simple exemple de ce à quoi cela ressemble dans Microsoft Visual Studio.

Collecter des flux de travail de commentaires

Les activités utilisables apparaissent dans la boîte à outils sur le côté gauche de l'écran. Un développeur peut faire glisser ces activités sur l'aire de conception pour définir les étapes d'un flux de travail. Les propriétés de chaque activité peuvent ensuite être définies dans la fenêtre Propriétés qui s'affiche dans le coin inférieur droit.

La bibliothèque BAL (Base Activity Library) de Windows Workflow fournit un ensemble d'activités essentielles, comme décrit précédemment. SharePoint Server offre également un jeu d'activités conçues expressément pour créer des flux de travail. Parmi les plus importantes, citons notamment les suivantes :

• OnWorkflowActivated : fournit un point de départ standard pour un flux de travail. Entre autres choses, cette activité peut accepter des informations fournies par un administrateur SharePoint à l'aide du formulaire Association, lorsque le flux de travail est associé à une bibliothèque, une liste, un type de contenu ou un site de documents. Elle peut également accepter des informations fournies par le formulaire d'initiation au démarrage du flux de travail. Tous les flux de travail doivent commencer par cette activité.

• CreateTask : crée une tâche affectée à un utilisateur particulier dans une liste de tâches. Par exemple, le flux de travail d'approbation dans le scénario décrit précédemment a utilisé cette activité pour ajouter une tâche à la liste des tâches utilisée par chacun des participants. Cette activité a également une propriété SendEmailNotification qui, lorsqu'elle a la valeur True, envoie automatiquement un courrier électronique à la personne pour laquelle cette tâche a été créée.

• OnTaskChanged : accepte des informations provenant du formulaire d'achèvement des tâches. Le flux de travail d'approbation dans le scénario antérieur a utilisé cette activité pour accepter l'entrée de chaque participant lorsque le document a été approuvé.

• CompleteTask : marque une tâche comme étant terminée.

• DeleteTask : retire une tâche d'une liste des tâches.

• OnWorkflowModified : accepte des informations du formulaire Modification, pouvant alors être utilisées pour modifier le comportement de cette instance du flux de travail. Si le créateur du flux de travail n'inclut pas d'instance de cette activité dans le flux de travail, ce flux de travail ne peut pas être modifié en cours d'exécution.

• SendEmail : envoie un courrier électronique à la personne ou groupe de personnes spécifié.

• LogToHistoryList : écrit des informations sur l'exécution du flux de travail dans une liste d'historique. Les informations de cette liste permettent aux utilisateurs de suivre la progression de l'exécution d'un flux de travail, d'examiner l'historique d'un flux de travail après son exécution, etc. Pour permettre ce type de contrôle, l'auteur du flux de travail doit écrire des informations dans une liste d'historique à des stades stratégiques de l'exécution du flux de travail. Étant donné qu'il fournit son propre mécanisme de suivi des flux de travail, SharePoint Server ne prend pas en charge le service de suivi standard de WF.

Un modèle classique de flux de travail simple commence par une activité OnWorkflowActivated, puis utilise une activité CreateTask pour affecter une tâche à un participant dans le flux de travail. L'activité While standard de la bibliothèque BAL peut être utilisée pour attendre l'achèvement de la tâche par l'utilisateur. Pour savoir quand cela s'est produit (il se peut que l'utilisateur effectue plusieurs modifications à la tâche, puis active une case dans le formulaire d'achèvement de la tâche une fois qu'il a terminé), une activité OnTaskChanged s'exécute dans l'activité While, extrayant les informations que l'utilisateur a entrées sur ce formulaire. Lorsque l'utilisateur a terminé la tâche, une activité CompleteTask peut peut-être s'exécuter, suivie d'une activité DeleteTask. Le flux de travail peut alors passer au participant suivant, en utilisant CreateTask pour lui affecter une tâche, etc. Évidemment, d'autres activités peuvent se produire, telles que l'envoi de courrier électronique, la consignation d'informations dans la liste d'historique ou même l'inclusion d'une activité de code de bibliothèque BAL, ce qui autorise l'exécution d'un code arbitraire.

Toutes les activités fournies par SharePoint Server prévoient le fonctionnement des flux de travail dans l'environnement SharePoint. La logique métier implémentée par un flux de travail relève entièrement du créateur de ce flux de travail. En fait, un développeur créant un flux de travail est libre de créer et d'utiliser ses propres activités personnalisées, il n'est pas tenu d'utiliser uniquement celles fournies par SharePoint Server et WF.

Comme décrit plus haut, Windows Workflow Foundation prend en charge des flux de travail séquentiels, parallèles et d'ordinateur d'état. Un flux de travail créé avec WF Workflow Designer peut également utiliser toutes ces options. Pour ce faire, SharePoint Server ajoute des types de projets dans Visual Studio, un exemplaire de chaque style de flux de travail.

Quel que soit le style choisi, le développeur ne doit pas définir uniquement la logique du flux de travail ; il doit également spécifier les formulaires .aspx ou InfoPath à utiliser. Pour cela, le développeur a recours à un fichier intitulé element.xml. Ce fichier fournit un modèle que le développeur remplit afin d'indiquer le formulaire, si nécessaire, à afficher aux quatre stades où le flux de travail est autorisé à procéder de la sorte.

Un développeur doit effectuer quelques manipulations avant de transférer des informations d'un flux de travail vers des formulaires .aspx. L'espace de noms Microsoft.Windows.SharePoint.Workflow expose un modèle d'objet pour les développeurs. En utilisant les types de cet espace de noms, le créateur d'un flux de travail peut faire passer des informations d'un fichier .aspx à un flux de travail et vice-versa.

Après avoir créé le flux de travail et ses formulaires, le développeur doit les assembler dans une fonctionnalité. Un administrateur SharePoint doit installer cette fonctionnalité, ce qui implique l'installation des assemblies du flux de travail dans le cache d'assembly global du système cible. L'administrateur peut désormais afficher le nouveau flux de travail en tant que modèle de flux de travail pouvant être associé à une bibliothèque, une liste ou un type de contenu ou un site de documents

Pour un développeur logiciel, la création d'un flux de travail à l'aide de Visual Studio et WF Workflow Designer n'est pas très difficile. Le développeur doit comprendre les spécificités de cet environnement, mais la plupart des activités lui sont familières. Cependant, les développeurs logiciels ne sont pas les seuls à vouloir créer des flux de travail. Comme décrit ci-après, les utilisateurs qui ne sont pas des développeurs professionnels peuvent également créer des flux de travail à l'aide de Microsoft SharePoint Designer 2010.

Création de flux de travail avec Microsoft SharePoint Designer 2010

Microsoft SharePoint Designer 2010 est une application autonome qui est disponible sous forme de téléchargement gratuit. Microsoft SharePoint Designer permet aux travailleurs de l'information et autres d'ajouter de la logique d'application (implémentée en tant que flux de travail) dans les sites SharePoint. Ceci est certainement un but utile, mais Microsoft SharePoint Designer traite également un autre problème important. Si un développeur crée un flux de travail en utilisant Visual Studio, ce flux doit être développé sur un serveur exécutant SharePoint Server comme toute autre fonctionnalité. Cependant, beaucoup d'administrateurs SharePoint n'autorisent pas le déploiement de code arbitraire sur leurs serveurs, car ils pensent que le risque d'endommager le système est trop grand. Il est très pratique de pouvoir créer de la logique métier claire, liée à des documents et des listes d'éléments. Toutefois, il s'agit d'une fonctionnalité dont bon nombre d'utilisateurs ont besoin. Outre l'autorisation pour des personnes moins techniques de créer des flux de travail, Microsoft SharePoint Designer traite également le problème en fournissant une méthode plus fiable pour définir et déployer de la logique métier sur des serveurs exécutant SharePoint Server.

Les scénarios de flux de travail que Microsoft SharePoint Designer doit traiter sont différents, d'une certaine manière, de ceux traités par Visual Studio et WF Workflow Designer. Tandis qu'il est certainement possible de créer des applications complexes, le but de Microsoft SharePoint Designer est de permettre aux utilisateurs d'ajouter de la logique métier à des sites SharePoint. Par exemple, supposons qu'un site contienne une liste qui permet à ses utilisateurs de soumettre des demandes de modification. Microsoft SharePoint Designer peut être utilisé pour créer un flux de travail qui informe automatiquement l'utilisateur demandeur lorsque sa demande de modification est acceptée ou rejetée. De même, un flux de travail personnalisé pourrait informer un groupe particulier d'utilisateurs lorsqu'un nouveau document est ajouté à une bibliothèque de documents particulière. L'exécution de ce type de notification personnalisé n'est pas difficile, la création des flux de travail est facile, mais cela se complique avec des versions antérieures de SharePoint Server à cause de la désapprobation des administrateurs de l'installation de codes écrits par des utilisateurs.

Une question évidente se pose : pourquoi la logique créée avec Microsoft SharePoint Designer doit-elle être traitée différemment ? Pourquoi les administrateurs de SharePoint sont-ils prêts à permettre que des flux de travail créés avec cet outil soient déployés sur des systèmes dont ils sont responsables ? La réponse est que les flux de travail créés avec Microsoft SharePoint Designer peuvent utiliser uniquement des activités de la liste contrôlée par l'administrateur. Outre les activités fournies par SharePoint Server, un administrateur de site peut choisir d'inclure des activités personnalisées créées par un développeur de cette liste. En définissant exactement les flux de travail qu'ils sont autorisés à créer, un administrateur SharePoint peut être plus sûr que le déploiement de logique créée à l'aide de Microsoft SharePoint Designer ne va pas déstabiliser son système.

Parce qu'il est destiné aux travailleurs de l'information plutôt qu'aux développeurs et il est centré sur les scénarios plus simples, Microsoft SharePoint Designer utilise un modèle pour créer des flux de travail autre que WF Workflow Designer hébergé par Visual Studio. Au lieu d'une approche graphique, Microsoft SharePoint Designer utilise une approche fondée sur des règles. Cela ressemble quelque peu à l'Assistant Règles de Microsoft Outlook, outil connu de beaucoup d'utilisateurs. L'écran ci-après illustre la façon dont un utilisateur de Microsoft SharePoint Designer définit une étape dans un flux de travail. Il est à noter que ce flux de travail exécute certaines actions en parallèle, d'autres en série. Les versions antérieures de SharePoint Server prenaient en charge l'exécution d'actions uniquement en série. Les actions ne s'exécutaient que consécutivement.

Flux de travail de commande de processus

Chaque étape peut avoir une condition et une action. La condition détermine si l'action de l'étape doit être exécutée, comme illustré dans la déclaration de If affiché plus haut. Les choix d'actions incluent des éléments, telles que l'attribution d'un comique pour un événement, la collecte d'approbation, etc. Chacune de ces actions est exécutée par une certaine activité de SharePoint Server et les activités utilisées ici sont les mêmes que dans Visual Studio et WF Workflow Designer. La liste d'action peut également inclure toute autre activité autorisée par l'administrateur SharePoint du site, y compris des activités personnalisées créées par des développeurs. Dans SharePoint Server, il existe également un ensemble particulier d'activités disponibles qui permettent aux utilisateurs de personnaliser l'approbation ou la collecte de postulat de commentaire commune de « créer un ensemble de tâches et d'attendre qu'elles s'achèvent » dans un concepteur spécial de Microsoft SharePoint Designer.

Bien que son interface utilisateur semble très différente de l'approche graphique utilisée par Visual Studio et WF Workflow Designer, Microsoft SharePoint Designer crée un flux de travail WF standard. En fait, le produit conçu est un flux de travail qui est séquentiel, parallèle ou les deux à la fois, avec des conditions exprimées à l'aide des règles du moteur de règles WF. Les flux de travail créés avec cet outil présentent toutefois certaines restrictions. Par exemple, ils ne peuvent pas être modifiés lorsqu'ils sont en cours d'exécution, contrairement à ceux créés à l'aide de Visual Studio et WF Workflow Designer, et seuls des flux de travail séquentiels et parallèles peuvent être créés ; les ordinateurs d'état ne sont pas pris en charge. De plus, les flux de travail créés avec cet outil peuvent être créés par rapport à une bibliothèque, une liste ou un site de documents spécifique, lorsqu'ils sont conçus. Les auteurs de flux de travail peuvent aussi créer un modèle de flux de travail général pouvant être associée ultérieurement à une bibliothèque, une liste ou type de contenu. Bien que cela entraîne des restrictions sur les possibilités d'utilisation d'un flux de travail, cela simplifie considérablement son déploiement. En fait, lorsqu'un utilisateur achève de créer un flux de travail avec Microsoft SharePoint Designer, l'outil fournit un déploiement par clic simple du flux de travail sur le site cible, ce qui inclut l'activation du flux de travail. Cela est considérablement moins complexe que le processus de déploiement à étapes multiples requis pour les flux de travail créés à l'aide de Visual Studio et WF Workflow Designer.

Les flux de travail créés à l'aide Microsoft SharePoint Designer peuvent aussi afficher des formulaires personnalisés. Au lieu de demander aux auteurs de flux de travail de créer des pages .aspx directement, l'outil génère ces pages. L'auteur spécifie les détails de l'apparence de pages générées, notamment le contenu des champs et Microsoft SharePoint Designer se charge du reste. Parmi les quatre stades du cycle de vie d'un flux de travail où les formulaires peuvent être utilisés, deux seulement sont utilisés avec des flux de travail créés à l'aide de Microsoft SharePoint Designer: Initiation et Achèvement de tâche. La raison pour cela étant que chaque flux de travail créé avec cet outil doit être associé à une bibliothèque, une liste, un type de contenu ou un site de documents particulier, il n'est nul besoin d'une étape d'association et par conséquent d'un formulaire d'association. En outre, ces flux de travail ne pouvant pas être modifiés en cours d’exécution, aucun formulaire Modification n’est nécessaire.

Microsoft SharePoint Designer fournit également la possibilité d'importer des flux de travail créés à l'aide de Microsoft Visio 2010. Cela permet aux responsables d'entreprise ou aux créateurs de flux de travail de créer de la logique de flux de travail en utilisant un environnement graphique bien connu. Un auteur de flux de travail peut alors importer la logique du flux dans Microsoft SharePoint Designer, la modifier si nécessaire, puis la publier sur un site SharePoint.

SharePoint Server fournit de nombreuses fonctionnalités pour la création de flux de travail axés sur les documents. Il constitue également une plate-forme de développement et d’exécution. Il ne fournit intrinsèquement aucune fonctionnalité de flux de travail directement utilisable par des utilisateurs finaux. Les flux de travail s'exécutant sur SharePoint Server possèdent également d'autres limitations, notamment l'impossibilité d'interagir avec des participants en utilisant le client Office.

Comparaison d'outils de création

Le tableau suivant affiche les différences importantes entre les outils que Microsoft prend en charge pour la création de flux de travail dans SharePoint Server en utilisant SharePoint Designer et WF Workflow Designer dans la version professionnelle de Visual Studio 2010.