Choisir un outil de création de flux de travail (SharePoint Foundation)

S’applique à : SharePoint Foundation 2010

Dernière rubrique modifiée : 2015-03-09

Qu’est-ce qu’un flux de travail ? Il se compose essentiellement de deux éléments : les formulaires qu’un flux de travail utilise pour interagir avec ses utilisateurs et la logique qui définit le comportement du flux de travail. Pour comprendre comment les flux de travail sont créés, il faut connaître ces deux éléments.

Comme il communique avec les utilisateurs par l’intermédiaire d’un navigateur Web, un flux de travail repose sur ASP.NET pour afficher ses formulaires. Par conséquent, ces formulaires sont définis en tant que pages .aspx. Un flux de travail peut éventuellement afficher ses propres formulaires à quatre stades dans 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 pourrait être en mesure de définir des options qui s’appliqueront à chaque instance de flux de travail créée à partir de cette association. Si un auteur de flux de travail choisit de l’autoriser, il doit fournir un formulaire qui permet à 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 venant d’être décrit, par exemple, les options permettent notamment de spécifier la liste des participants du flux de travail et de définir de combien de temps 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. Ce formulaire a autorisé les approbateurs du scénario antérieur à apporter des commentaires sur le document et à indiquer leur approbation ou leur rejet.

• Modification : le créateur d’un flux de travail peut permettre qu’il soit modifié en cours d’exécution. Par exemple, un flux de travail peut autoriser l’ajout de nouveaux participants après le début de son exécution ou l’extension de sa date d’échéance pour l’exécution des 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 reposant uniquement sur Microsoft SharePoint Foundation 2010 définissent leurs formulaires en tant que pages .aspx. La logique d’un flux de travail est toujours définie comme un groupe d’activités, comme avec tout flux de travail basé sur Windows Workflow Foundation (WF). Pour spécifier la logique et les formulaires d’un flux de travail, Microsoft fournit deux outils spécifiques, chacun ciblant un public différent. Les développeurs de logiciels peuvent utiliser la fonctionnalité Workflow Designer de Windows Workflow Foundation. Cet outil s’intègre dans Visual Studio 2010 Professional Edition et fournit un environnement graphique pour organiser les activités en flux de travail. Les travailleurs de l’information, formant 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 examinent comment des flux de travail peuvent être créés à l’aide de chacun de ces outils.

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

À 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. Il s’agit des outils de flux de travail SharePoint dans Visual Studio 2010 Professional, type de projet qui utilise Windows Workflow Foundation (WF) Designer et ajoute la prise en charge du déploiement et des formulaires pour les flux de travail SharePoint. Les développeurs peuvent utiliser WF Workflow Designer pour définir graphiquement les activités d’un flux de travail et leur ordre d’exécution. L’écran ci-dessous en présente l’aspect général dans Microsoft Visual Studio.

Flux de travail Recueillir les 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 Foundation fournit un groupe d’activités fondamentales, comme décrit plus haut. Microsoft SharePoint Foundation fournit également un ensemble d’activités expressément conçues pour créer des flux de travail. Parmi les plus importantes, citons notamment celles-ci :

• 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 d’association lorsque le flux de travail est associé à une bibliothèque de documents, une liste, un type de contenu ou un site. Elle peut également accepter des informations fournies par le formulaire de lancement au démarrage du flux de travail. Chaque flux de travail doit 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 message é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 dans cette liste permettent aux utilisateurs de voir où en est 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 points stratégiques de l’exécution du flux de travail. Comme il fournit son propre mécanisme de suivi des flux de travail, Microsoft SharePoint Foundation ne prend pas en charge le service de suivi standard de WF.

Un modèle classique de flux de travail relativement 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 pourrait alors être utilisée pour attendre l’achèvement de la tâche par l’utilisateur. Pour savoir quand cela s’est produit (l’utilisateur effectue éventuellement 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 éventuellement entrées sur ce formulaire. Lorsque l’utilisateur a terminé la tâche, une activité CompleteTask pourrait 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 d’un 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 Foundation 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 ne doit pas nécessairement utiliser celles fournies par SharePoint Foundation et WF.

Comme il a été précisé plus haut, Windows Workflow Foundation prend en charge les flux de travail séquentiels, parallèles et de machine à état. Un flux de travail créé avec WF Workflow Designer peut également utiliser n’importe laquelle de ces options. Pour le permettre, SharePoint Foundation ajoute des types de projets à Visual Studio, un pour chacun de ces styles de flux de travail.

Quel que soit le style choisi, le développeur ne doit pas simplement définir la logique du flux de travail ; il doit également spécifier le formulaire .aspx qu’il doit utiliser. Pour cela, le développeur s’appuie sur un fichier nommé element.xml. Ce fichier fournit un modèle que le développeur remplit pour spécifier quel formulaire, le cas échéant, doit être affiché à chacun des quatre points auxquels un flux de travail est autorisé à le faire.

Un développeur doit effectuer un travail pour passer des informations entre un flux de travail et les formulaires .aspx qu’il utilise. L’espace de noms Microsoft.Windows.SharePoint.Workflow expose un modèle objet pour les développeurs. À l’aide des types dans cet espace de noms, le créateur d’un flux de travail Windows SharePoint Services peut passer des informations d’un formulaire .aspx au flux de travail et vice-versa.

Une fois qu’un flux de travail et ses formulaires ont été créés, le développeur doit les conditionner en une entité appelée composant fonctionnel. Un administrateur SharePoint doit alors installer ce composant fonctionnel, ce qui implique l’installation des assemblys du flux de travail dans le Global Assembly Cache du système cible. Le nouveau flux de travail sera alors visible par l’administrateur comme un modèle de flux de travail pouvant être associé à une bibliothèque de documents, une liste, un type de contenu ou un site.

Pour un développeur de logiciels, la création d’un flux de travail à l’aide de Visual Studio et de WF Workflow Designer n’est pas particulièrement difficile. Le développeur doit comprendre les spécificités d’un travail dans cet environnement, mais la plupart des activités lui sont déjà familières. Mais les développeurs de logiciels ne seront pas les seuls à souhaiter créer des flux de travail. Comme nous le précisons ci-dessous, même les personnes n’étant pas des développeurs professionnels peuvent 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 distincte que vous pouvez télécharger gratuitement. Microsoft SharePoint Designer permet aux travailleurs de l’information et à d’autres personnes d’ajouter une logique d’application (implémentée sous forme de flux de travail) à des sites SharePoint. Cela constitue en soi un objectif très utile, mais Microsoft SharePoint Designer résout également un autre problème important. Si un développeur crée un flux de travail à l’aide de Visual Studio, ce flux de travail doit être déployé sur un serveur exécutant SharePoint Foundation comme toute autre fonctionnalité. Mais de nombreux administrateurs SharePoint n’autoriseront pas le déploiement d’un code arbitraire sur leurs serveurs, estimant que le risque de déstabilisation du système est trop grand. Cependant, la possibilité de créer une logique métier relativement simple liée à des documents et à des éléments de liste reste très utile, et c’est ce que recherchent de nombreux utilisateurs de SharePoint. En plus de permettre à des individus sans compétence technique de créer des flux de travail, Microsoft SharePoint Designer répond à ce problème en fournissant une méthode sécurisée pour définir et déployer une logique métier sur des serveurs exécutant SharePoint Foundation.

Les scénarios de flux de travail que Microsoft SharePoint Designer est destiné à gérer sont relativement différents de ceux traités par Visual Studio et WF Workflow Designer. Bien qu’il soit possible de créer des applications complexes, Microsoft SharePoint Designer permet surtout aux utilisateurs d’ajouter une 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 pourrait être utilisé pour créer un flux de travail qui informe automatiquement l’émetteur lorsque sa demande de modification est acceptée ou refusé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ée n’est pas compliquée (la création de flux de travail est facile), mais cela constitue quand même un défi avec les versions antérieures de SharePoint Foundation en raison de la résistance de l’administrateur à installer du code écrit par l’utilisateur.

Une question évidente : pourquoi une logique créée avec Microsoft SharePoint Designer est-elle traitée différemment ? Pourquoi les administrateurs SharePoint accepteront-ils de déployer sur les systèmes dont ils sont responsables des flux de travail construits avec cet outil ? La réponse est que les flux de travail construits avec Microsoft SharePoint Designer peuvent uniquement utiliser des activités provenant d’une liste contrôlée par un administrateur. En plus des activités fournies par SharePoint Foundation, un administrateur de sites peut décider s’il convient d’inclure dans cette liste des activités personnalisées créées par un développeur. En définissant exactement ce que les flux de travail sont autorisés à faire, un administrateur SharePoint craindra moins que le déploiement d’une logique créée à l’aide de Microsoft SharePoint Designer ne déstabilise son système.

Comme il est destiné aux travailleurs de l’information et non aux développeurs et puisqu’il implique des scénarios plus simples, Microsoft SharePoint Designer utilise un modèle différent pour la création de flux de travail que celui de WF Workflow Designer, hébergé dans Visual Studio. Au lieu d’une approche graphique, Microsoft SharePoint Designer utilise une approche basée sur des règles. Il s’apparente à l’Assistant Règles dans Microsoft Outlook, outil bien connu par de nombreuses personnes. L’écran ci-dessous illustre la définition d’une étape d’un flux de travail par un utilisateur de Microsoft SharePoint Designer. Comme vous pouvez le constater, ce flux de travail exécute certaines actions en parallèle, d’autres en série. Les versions antérieures de SharePoint Foundation prenaient en charge l’exécution des actions uniquement en série ; les actions étaient uniquement exécutées les unes après les autres.

Flux de travail Traiter la commande

Chaque étape peut avoir une condition et une action. La condition détermine si l’action de cette étape doit être exécutée, comme dans l’instruction If présentée ci-dessus. Les choix d’actions incluent notamment l’affectation d’un animateur à un événement, la collecte d’une approbation, etc. Chacune de ces actions est exécutée par une activité SharePoint Foundation et les activités utilisées ici sont les mêmes qu’avec Visual Studio et WF Workflow Designer. La liste d’actions peut également inclure toute autre activité autorisée par l’administrateur SharePoint pour ce site, notamment des activités personnalisées créées par des développeurs.

Bien que son interface utilisateur soit assez différente de l’approche graphique employée avec Visual Studio et WF Workflow Designer, Microsoft SharePoint Designer crée un flux de travail WF standard. Cela produit en fait un flux de travail séquentiel et/ou parallèle avec des conditions exprimées à l’aide 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 en cours d’exécution, contrairement à ceux construits à 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 flux de travail de machine à état ne sont pas pris en charge. En outre, les flux de travail construits avec cet outil peuvent être créés par rapport à une bibliothèque de documents, une liste ou un site spécifique lors de leur conception. Les créateurs de flux de travail peuvent également créer un modèle de flux de travail général pouvant être ultérieurement associé à toute bibliothèque, toute liste ou tout 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 termine la création d’un flux de travail avec Microsoft SharePoint Designer, l’outil permet de déployer le flux de travail sur le site cible d’un simple clic, 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 de Microsoft SharePoint Designer peuvent également afficher des formulaires personnalisés. Toutefois, au lieu d’imposer aux auteurs la création de pages .aspx directement, l’outil génère ces pages. L’auteur spécifie l’aspect détaillé des pages générées, par exemple le contenu des différents champs, et Microsoft SharePoint Designer se charge du reste. Parmi les quatre points du cycle de vie d’un flux de travail où des formulaires peuvent être utilisés, seulement deux sont toutefois utilisés avec les flux de travail créés à l’aide de Microsoft SharePoint Designer : Lancement et Achèvement de tâche. Comme chaque flux de travail créé avec cet outil doit être associé à une bibliothèque de documents, une liste, un type de contenu ou un site spécifique, aucune étape d’association n’est donc nécessaire, ni aucun formulaire d’association. Et comme ces flux de travail ne peuvent pas être modifiés en cours d’exécution aucun formulaire Modification n’est nécessaire.

Microsoft SharePoint Designer offre également la possibilité d’importer les flux de travail créés à l’aide de Microsoft Visio 2010. Cela permet aux business managers ou aux auteurs de flux de travail de créer la logique du flux de travail à l’aide d’un environnement graphique familier. Un auteur de flux de travail peut ensuite importer la logique du flux de travail dans Microsoft SharePoint Designer, la modifier au besoin, puis la publier sur un site SharePoint.

SharePoint Foundation fournit beaucoup de fonctionnalités pour la création de flux de travail orientés documents. Il constitue également une plateforme 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 exécutés sur SharePoint Foundation présentent également d’autres restrictions, comme l’incapacité d’interagir avec des participants à l’aide d’applications clientes Office.

Comparaison des outils de création

Le tableau suivant montre les différences importantes entre les outils que Microsoft prend en charge pour la création de flux de travail dans SharePoint Foundation à l’aide de SharePoint Designer et WF Workflow Designer dans Visual Studio 2010 Professional Edition.