Principes de base du flux de travail SharePoint
Offre une vue d'ensemble de l'infrastructure de flux de travail dans SharePoint, notamment une présentation de l'architecture de la plateforme et du pont d'interopérabilité de flux de travail.
Remarque
Le flux de travail SharePoint 2013 est déconseillé depuis avril 2023 et sera désactivé pour les nouveaux locataires à compter du 2 avril 2024. Il sera supprimé des locataires existants et sera entièrement mis hors service à compter du 2 avril 2026. Si vous utilisez un flux de travail SharePoint 2013, nous vous recommandons de migrer vers Power Automate ou d’autres solutions prises en charge. Pour plus d’informations, voir Mise hors service de flux de travail SharePoint 2013 dans Microsoft 365. Les flux de travail SharePoint 2010 ont été retirés depuis le 1er août 2020 pour les nouveaux locataires et retirés des locataires existants le 1er novembre 2020. Si vous utilisez des flux de travail SharePoint 2010, nous vous recommandons de migrer vers Power Automate ou d'autres solutions prises en charge. Pour plus d'informations, voir la retraite du flux de travail SharePoint 2010.
Vue d’ensemble des flux de travail dans SharePoint
Les flux de travail SharePoint sont alimentés par Windows Workflow Foundation 4, considérablement remodelé par rapport aux versions antérieures. Windows Workflow Foundation (WF), à son tour, repose sur la fonctionnalité de messagerie fournie par Windows Communication Foundation (WCF).
Au niveau conceptuel, les flux de travail modélisent des processus d'entreprise structurés. Par conséquent, les flux de travail Windows Workflow Foundation 4 constituent un ensemble structuré d'activités de flux de travail et chacune d'elles représente un composant fonctionnel d'un processus d'entreprise.
La plateforme de flux de travail dans SharePoint utilise le modèle d'activité Windows Workflow Foundation 4 pour représenter un processus d'entreprise basé sur SharePoint. En outre, SharePoint introduit un modèle par étape de niveau supérieur sur lequel créer des flux de travail.
Il convient de signaler la relation entre les activités de flux de travail et lesactions SharePoint. Les activités de flux de travail représentent les objets gérés sous-jacents dont les méthodes induisent le comportement de flux de travail. En revanche, les actions de flux de travail sont des wrappers qui encapsulent les activités sous-jacentes et les présentent dans un formulaire convivial dans SharePoint Designer. Les auteurs de flux de travail interagissent avec les actions de flux de travail, tandis que le moteur d'exécution de flux de travail agit sur les activités correspondantes.
Les activités, qui sont des implémentations de classes d'activités, sont mises en oeuvre de façon déclarative à l'aide de XAML.
Les activités de flux de travail sont appelées à l'aide de services web faiblement couplés qui utilisent des API de messagerie pour communiquer avec SharePoint. Ces API reposent sur la fonctionnalité de messagerie fournie par Windows Communication Foundation (WCF).
L'infrastructure de messagerie est très souple et prend en charge quasiment tous les modèles de messagerie nécessaires. Notez que sur une batterie de serveurs SharePoint, Windows Workflow Foundation et WCF sont hébergés dans Workflow Manager Client 1.0.
Workflow Manager Client 1.0, SharePoint et SharePoint Designer 2013 fournissent chacun des parties significatives de la nouvelle infrastructure :
Gestionnaire de flux de travail Client 1.0 fournit la gestion des définitions de flux de travail. Il héberge également les processus d’exécution pour les instances de workflow.
SharePoint fournit l'infrastructure des flux de travail SharePoint, qui modélisent les processus d'entreprise basés sur SharePoint impliquant des tâches, des listes, des utilisateurs et des documents SharePoint. En outre, les flux de travail SharePoint, les associations, les activités et autres métadonnées de flux de travail sont stockées et gérées dans SharePoint.
SharePoint Designer 2013 constitue le principal outil utilisateur d'entreprise pour la création et la publication de définitions de flux de travail, comme dans les versions précédentes. Il peut également être utilisé pour mettre en package une définition de flux de travail avec ou sans composants SharePoint associés.
Architecture de la plateforme
La figure 1 présente une vue d'ensemble de l'infrastructure de flux de travail SharePoint. Notez, tout d'abord, que la nouvelle infrastructure de flux de travail présente Workflow Manager Client 1.0 comme le nouvel hôte d'exécution de flux de travail. Contrairement aux versions précédentes, dans SharePoint, l'exécution de flux de travail n'est plus hébergée dans SharePoint. Workflow Manager Client 1.0 est externe à SharePoint et communique à l'aide de protocoles communs sur le bus des services Microsoft Azure, via OAuth. Par ailleurs, SharePoint comprend les fonctionnalités prévues : éléments de contenu, événements, applications, etc. Il existe également une implémentation de l'hôte de flux de travail SharePoint 2010 (en d'autres termes, le moteur Windows Workflow Foundation 3) pour la compatibilité descendante. Pour plus d’informations à ce sujet, consultez Utiliser l’interopérabilité de flux de travail pour SharePoint.
Figure 1. Architecture de niveau supérieur de l’infrastructure de flux de travail
Workflow Manager Client 1.0 est représenté dans SharePoint sous forme de proxy d'application de service Workflow Manager Client 1.0. Ce composant permet à SharePoint de communiquer et d'interagir avec le serveur Workflow Manager Client 1.0. L'authentification de serveur à serveur est fournie par OAuth.
Les événements SharePoint pour lesquels un flux de travail est à l'écoute, comme itemCreated, itemUpdated, etc., sont routés vers Workflow Manager Client 1.0 à l'aide du bus des services Microsoft Azure. Pour le retour, la plateforme utilise l'API REST SharePoint pour effectuer un appel dans SharePoint.
Le modèle objet de flux de travail SharePoint a subi des ajouts, rassemblés dans le gestionnaire des services de flux de travail, qui vous permettent de gérer et de contrôler vos flux de travail et leur exécution. Les zones principales d'interaction du gestionnaire de services sont le déploiement, la messagerie, le contrôle d'instance et (pour la compatibilité descendante) l'interopérabilité avec les flux de travail SharePoint 2010.
Enfin, il existe le composant de création de flux de travail. SharePoint Designer peut désormais créer et déployer les flux de travail de SharePoint 2010 et SharePoint. Visual Studio 2012 ne fournit pas seulement un espace de conception pour la création de flux de travail déclaratifs, mais peut aussi créer des Compléments SharePoint et des solutions qui intègrent pleinement la fonctionnalité Workflow Manager Client 1.0.
Abonnements et associations de flux de travail
Étant donné que la modification la plus importante apportée aux flux de travail SharePoint est le déplacement du traitement des flux de travail vers des hôtes de flux de travail externes comme Microsoft Azure, il était essentiel que les messages et événements SharePoint se connectent à l’infrastructure de flux de travail dans Microsoft Azure. En outre, microsoft Azure devait connecter l’infrastructure aux données client. Les associations de flux de travail (basées sur le concept d’abonnements WF) sont les éléments d’infrastructure SharePoint qui prennent en charge ces exigences.
Service de publication/d'abonnement Microsoft Azure
Pour pouvoir aborder les abonnements et les associations de flux de travail, vous devez consulter le service de publication/d'abonnementMicrosoft Azure, connu sous le nom de pub/sub ou simplementPubSub. PubSub est une infrastructure de messagerie asynchrone. Les expéditeurs de messages (éditeurs) n'envoient pas de messages directement aux récepteurs (abonnés). Au lieu de cela, les messages sont affichés en tant que classes par les éditeurs sans connaissance des abonnés. Les abonnés utilisent ensuite les messages publiés en identifiant les messages d'intérêt, quel que soit l'éditeur, en fonction des abonnements qu'ils ont créés.
Ce découplage entre la création de messages et la consommation de messages offre scalabilité et flexibilité. Il active la messagerie multidiffusion côté éditeur et pour la consommation de messages promiscuous côté abonné.
Remarque
La fonctionnalité PubSub fait partie de Microsoft Azure Service Bus, qui propose des options de connectivité pour WCF et d’autres points de terminaison de service, notamment les points de terminaison REST, qui peuvent se situer derrière les limites de traduction d’adresses réseau (NAT) ou être liés à des adresses IP affectées dynamiquement et modifiées fréquemment, ou les deux. Pour plus d’informations sur la Azure Service Bus, consultez Service Bus.
Associations de flux de travail et étendue des associations
Les associations de flux de travail lient les définitions de flux de travail à une étendue SharePoint spécifique, avec des valeurs par défaut données. Les associations elles-mêmes représentent un ensemble de règles d'abonnement stockées dans le service de publication/d'abonnement Azure qui traite les messages entrants afin de s'assurer qu'ils sont consommés par des instances de flux de travail appropriées (c'est-à-dire, abonnées).
Par défaut, l'infrastructure de messagerie prend en charge les flux de travail dans les étendues suivantes :
Contrairement aux versions précédentes, SharePoint ne prend pas en charge les flux de travail dont l'étendue s'applique à un type de contenu ( SPContentType ). Toutefois, l'infrastructure de messagerie étant extensible, elle peut prendre en charge n'importe quelle étendue arbitraire. En tant que développeur, vous pouvez définir la propriété EventSourceId sur une instance WorkflowSubscription donnée sur n'importe quel guid. Vous pouvez ensuite utiliser cette valeur EventSourceId pour appeler PublishEvent(Guid, String, IDictionary<String, Object>), ce qui déclenche un nouveau workflow instance du WorkflowSubscription spécifié.
Service de flux de travail dans Microsoft Azure
Les associations des flux de travail SharePoint sont représentées par leur service de flux de travail dans Microsoft Azure. Lorsqu'une application doit acquérir une association de flux de travail et ses données, elle doit d'abord soumettre une requête à tous les services de flux de travail disponibles sur une étendue donnée.
De même, les instances de flux de travail rapportent un pointeur à leurs services de flux de travail respectifs. C’est de cette façon que leur association appropriée est déterminée.
Démarrage des flux de travail
Les flux de travail peuvent être démarrés manuellement ou automatiquement.
Flux de travail manuels
Les flux de travail manuels démarrent lorsque le service PubSub reçoit un message StartWorkflow. Le message contient les informations descriptives suivantes :
L'identificateur d'association (en d'autres termes, l'instance WorkflowSubscription)
L'ID du contexte d'élément d'origine Il est transmis avec le paramètre ItemId et la propriété EventSource sur l’appel de méthode PublishEvent .
Le type d'événement pour un démarrage manuel ( WorkflowStart).
Paramètres d’initiation de flux de travail supplémentaires, à partir de l’abonnement ou du formulaire Init , le cas échéant. Il s’agit de CorrelationId pour l’abonnement et de WFInstanceId pour le formulaire Init .
Flux de travail à démarrage automatique
Les flux de travail à démarrage automatique sont lancés à l'aide d'un message Add envoyé au service PubSub. Le message contient les informations descriptives suivantes :
L'ID du contexte d'élément d'origine
L'événement lui-même en tant qu'événement Add SharePoint normal
Les paramètres d’initiation du flux de travail.
Remarque
Quand un flux de travail démarre automatiquement sur un événement renouvelable (par exemple, sur l’événement OnItemChanged), il ne peut pas démarrer un autre flux de travail d’une association donnée tant que l’exécution de l’instance de flux de travail de l’association n’est pas terminée.
Abonnements de flux de travail
Le complément naturel des associations est les abonnements : ils permettent au flux de travail d'interagir avec celles-ci. Le flux de travail doit créer des abonnements sur Azure Service Bus à l'aide des méthodes create et delete.
Les signatures des méthodes qui créent l’abonnement et instancient le flux de travail désignent les paramètres facultatifs et obligatoires. La liste des paramètres est déterminée par l’auteur du flux de travail ; ils peuvent donc différer d’une définition de flux de travail à une autre. La liste des paramètres d’abonnement est spécifiée en tant que métadonnées des définitions de flux de travail. Les paramètres d’abonnement sont fournis quand l’abonnement est créé. La liste des paramètres d’initialisation est spécifiée dans XAML et fait partie de la définition de flux de travail. Les paramètres d’initialisation sont fournis quand le flux de travail est instancié.
Les abonnements sont liés à un objet SharePoint spécifique : une instance SPList ou une instance SPWeb. Le type d’objet d’abonnement est transmis sous forme de valeur d’un paramètre quand l’abonnement est créé. Le type d’objet définit l’étendue de l’abonnement. Ainsi, l’abonnement peut uniquement répondre à des événements qui se produisent sur l’objet auquel ils sont abonnés.
Interopérabilité de flux de travail SharePoint
L'interopérabilité de flux de travail SharePoint permet aux flux de travail SharePoint 2010 (créés sur Windows Workflow Foundation 3) d'être appelés à partir de flux de travail SharePoint, basés sur Windows Workflow Foundation 4. Cela vous permet d'exécuter des flux de travail 2010 dans des flux de travail 2013.
Ceci est important car vous disposez peut-être de SharePoint 2010, que vous pouvez réutiliser conjointement avec vos flux de travail SharePoint. En outre, vous pouvez utiliser des activités ou fonctionnalités à partir de SharePoint 2010 qui ne sont pas encore implémentées dans SharePoint.
Pour obtenir une description complète de l’interopérabilité des flux de travail SharePoint, voir Utiliser l’interopérabilité de flux de travail pour SharePoint.