Utilisation du modèle d’objet côté client pour les services de flux de travail SharePoint
Montre comment utiliser l'API de modèle (CSOM) SharePoint objet côté client pour créer et contrôler les instances et définitions de flux de travail Workflow Manager 1.0 . Fourni par : Andrew Connell, www.AndrewConnell.com
Notes
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.
Utilisation du modèle d’objet côté client pour les services de flux de travail SharePoint
L'implémentation de workflows dans SharePoint 2007 et SharePoint 2010 sont restés en grande partie identique à partir d'une version à l'autre. Microsoft ajouter de nouvelles fonctionnalités dans SharePoint 2010, telles que la possibilité d'associer des workflows à des sites et améliorer le flux de travail outils de création, SharePoint Designer 2010 et Visual Studio 2010, de leurs prédécesseurs. Toutefois, l'implémentation de tâches de flux de travail, les formulaires de flux de travail et le reste d'API côté serveur du flux de travail en grande partie inchangé.
Dans SharePoint 2010, Microsoft introduit des fonctionnalités et fonctions qui encourager les clients à migrer leurs personnalisations dans solution bac à sable. Il s'exécute dans un processus isolé et ont été convivial pour les deux types de déploiements SharePoint : local, où SharePoint a été installé sur les serveurs de l'entreprise et maintenue par la société et du nuage, ou plus précisément, Office 365.
Dans SharePoint, Microsoft a ajouté encore plus de fonctionnalités ; ces mises à jour ont été orientées sur les déploiements dans le cloud. En particulier, Microsoft a introduit le nouveau modèle d'application de SharePoint, qui s'est passé plus de la solution bac à sable dans la mesure où, à la différence des solution bac à sable, ils explicitement bloqué code côté serveur de s'exécuter dans le processus de SharePoint. Microsoft également élaboré des technologies existantes dans SharePoint, telles que le modèle d'objet côté client (CSOM) et introduit de nouvelles fonctions, telles que la prise en charge pour les identités d'application à l'aide de OAuth.
Et puis, avec l'introduction de SharePoint, Microsoft a introduit une architecture entièrement nouvelle de flux de travail et la plate-forme qui reflètent les changements fondamentaux dans la direction du produit.
La modification la plus importante dans la nouvelle architecture est que l'exécution de flux de travail dans SharePoint n'a plus lieu dans SharePoint. Au lieu de cela, SharePoint utilise un moteur d'exécution totalement nouveau : Workflow Manager 1.0. Workflow Manager héberge le runtime Windows Workflow Foundation et tous les services requis par Windows Workflow Foundation. Lorsqu’un flux de travail est publié ou qu’une nouvelle instance d’un flux de travail publié est démarrée, SharePoint avertit le gestionnaire de flux de travail, qui traite à son tour les épisodes de flux de travail. Lorsque le flux de travail accèdent à des informations dans SharePoint, telles que les propriétés d'élément de liste ou propriétés de l'utilisateur, il s'authentifie à l'aide de la prise en charge OAuth et communique par l'intermédiaire des API reste nouvelles et améliorées.
Ces modifications dans l'architecture de flux de travail avaient des impacts significatifs dans certains domaines, tels que des formulaires de flux de travail personnalisés, comme décrit dans l'article MSDN Comment créer des formulaires personnalisés SharePoint avec Visual Studio 2012. Cet article aborde l'une des choses que Microsoft a ajouté à SharePoint pour prendre en charge le nouveau style de création de formulaires de flux de travail personnalisés : les améliorations apportées à la CSOM et l'ajout de l'API de CSOM des Services de flux de travail.
Introduction à l'API CSOM des Services du flux de travail dans SharePoint
Dans SharePoint 2007 et SharePoint 2010, l’API de flux de travail se manifestait uniquement dans le modèle objet côté serveur. Dans SharePoint, ce même API de flux de travail est toujours présent, étant donné que SharePoint comprend l'ancien moteur d'exécution de flux de travail dans SharePoint pour la compatibilité descendante.
Cependant, l'architecture nouvelle et préférée du flux de travail introduit avec SharePoint qui utilise Workflow Manager inclut une nouvelle API côté serveur. Dans SharePoint, Microsoft a prolongé le CSOM pour inclure une API puissante pour la nouvelle architecture de flux de travail. Notez que cet ajout à la CSOM s'applique uniquement à la nouvelle architecture de flux de travail SharePoint 1.0 et Workflow Manager 1.0, pas à l'ancienne version qui est toujours hébergée par SharePoint.
L'API CSOM des Services de flux de travail, comme le reste de la CSOM, est implémenté dans une API de Silverlight géré .NET et une API de JavaScript connu comme le modèle d'objet (JSOM) JavaScript . JSOM est que les développeurs doivent utiliser lors de la création de formulaires de workflow personnalisés que ces formulaires seront ASP.NET web forms qui ne doivent pas avoir de code côté serveur. Ainsi, l'API JSOM Services de flux de travail est utilisé dans les formulaires d'association personnalisé pour créer des associations de flux de travail, ainsi que sur les formulaires d'initiation pour démarrer de nouvelles instances de flux de travail.
Toutefois, les possibilités ne s’arrêtent pas là. Le CSOM et JSOM services de flux de travail est très robuste et permet aux développeurs de faire presque tout avec les flux de travail dans SharePoint. Outre la création d'instances et les associations de flux de travail, les développeurs peuvent également programmer déploie de nouvelles définitions de flux de travail et même communiquer avec exécutant des instances de workflow à partir des CSOM et JSOM, comme expliqué dans le reste de cet article.
Cet article se concentre sur la rubrique de formulaires de flux de travail dans le contexte de SharePoint Server 2013. Il est basé sur SharePoint avec la mise à jour publique de mars 2013 et les Outils de développement Office pour Visual Studio 2013. Tout le contenu de cet article s’applique aux déploiements locaux de SharePoint ainsi qu’à Office 365.
Composants de API flux de travail Services CSOM et JSOM
Cet article se concentre sur l'API de CSOM des Services de flux de travail et donc, par extension, l'API JSOM. Workflow Services API côté serveur n'est pas abordé ici. Le CSOM de Services de flux de travail se compose de différents services qui sont utilisés pour effectuer des tâches différentes. Chacune d'elles est décrite dans les sections suivantes.
Notes
Il existe un service supplémentaire qui n'est pas présent dans la CSOM, mais est présent à la place avec l'API côté serveur. C'est le Service de messagerie, qui est utilisé pour gérer message queuing et le transport de messages.
Pour travailler avec les API de JSOM et de CSOM des Services de Workflow, les développeurs doivent ajouter les références nécessaires à leurs projets (dans le cas CSOM) et les pages (dans le cas JSOM). Les deux implémentations aient les mêmes besoins :
Référencer les bibliothèques noyaux CSOM et JSOM de SharePoint :
Microsoft.SharePoint.Client.dll
Microsoft.SharePoint.Client.Runtime.dll
Microsoft.SharePoint.Client.WorkflowServices.dll
Référencer les bibliothèques de Workflow Services CSOM et JSOM :
SP.js
SP.Runtime.js
SP.WorkflowServices.js
Gestionnaire de Service de flux de travail
La passerelle pour tous les services inclus dans l'API de CSOM des Services de flux de travail est le Gestionnaire de Service de flux de travail. Cet objet est que les développeurs utilisent pour obtenir des instances de tous les autres services décrites dans les sections suivantes. Similaire à d'autres implémentations de l'API CSOM, la WorkflowServicesManager a une dépendance sur le noyau SharePoint CSOM et, par conséquent, vous devez passer dans un contexte client valide et faire référence au site SharePoint que vous souhaitez connecter, comme indiqué dans les exemples de code suivants CSOM et JSOM.
CSOM : Création d’une instance WorkflowServicesManager
var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
JSOM : Création d’une instance WorkflowServicesManager
var clientContext = SP.ClientContext.get_current();
var workflowServicesManager = SP.WorkflowServices.WorkflowServicesManager.newObject(context, context.get_web());
Service de déploiement
Lorsque vous créez des flux de travail personnalisés à l'aide de Visual Studio 2012, soit à l'aide d'un package de solution (.wsp) ou comme une application SharePoint ( .app), vous créez des définitions de workflow. Une définition est le processus de workflow et de toutes les règles métier et attributs définis au sein de celui-ci, telles que l'emplacement personnalisée formulaires d'association et initiation. De leur côté, ces définitions ne sont pas très utiles, car ils ne peuvent pas être exécutés en dehors du contexte d'une association avec un site, une liste ou une bibliothèque de documents. Vous trouverez les définitions de flux de travail publiées et disponibles sur un site en accédant à la page où une nouvelle association de flux de travail peut être créée, comme illustré dans la figure suivante.
La figure 1. Ajouter une association de flux de travail

La collection de définitions de workflow publié est accessible via le service de déploiement. Ce service vous permet d'obtenir une liste de toutes les définitions actuellement enregistrées et publiées sur le site, ainsi que pour publier les deux enregistrés et les nouvelles définitions, supprimer les définitions existantes et de déterminer les actions de flux de travail disponibles pour SharePoint Designer 2013-a créé des flux de travail.
L'objet WorkflowDeploymentService est disponible via la classe WorkflowServicesManager, comme illustré dans les exemples de code suivants.
CSOM : Obtenir une instance WorkflowDeploymentService
var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
var workflowDeploymentService = workflowServicesManager.GetWorkflowDeploymentService();
JSOM : Obtenir une instance WorkflowDeploymentService
var clientContext = SP.ClientContext.get_current();
var workflowServicesManager = SP.WorkflowServices.WorkflowServicesManager.newObject(context, context.get_web());
var workflowDeploymentService = workflowServicesManager.getWorkflowDeploymentService();
Service d’abonnement
Créer des workflows et de les publier dans SharePoint en tant que définitions de rappel à partir de la section précédente. Pour utiliser ces définitions, un utilisateur doit créer une association qui lie la définition d'un site SharePoint spécifique, une liste ou une bibliothèque de documents avec des métadonnées supplémentaires. Fondamentalement, ce processus fonctionne et se comporte de la même façon dans SharePoint 2010, mais la mise en œuvre dans SharePoint est très différente. Workflow Manager 1.0 tire parti d'une instance de Microsoft Azure 1.0 de Bus de Service.
Bus de service joue un rôle dans la mesure où il prend en charge le service de publication et d'abonnement (également connu sous le nom PubSub). Il s'agit d'une structure de messagerie asynchrone qui prend en charge un éditeur envoie un message à une rubrique stockée dans le Bus des services. Un nombre quelconque d'abonnés peut demander à être averti lorsqu'un message est publié dans cette rubrique qui répond à des critères spécifiques.
SharePoint et Workflow Manager 1.0 utilisent le modèle de PubSub pour créer des associations. Associations de flux de travail sont créées en tant qu'abonnements sur des sujets. Par exemple, une association de définition de flux de travail peut être créée sur la liste et configurée pour démarrer automatiquement lorsque les éléments sont ajoutés à la liste. Lorsqu'un élément est ajouté à la liste, SharePoint publie un événement vers Workflow Manager 1.0, qu'il envoie à la rubrique Service Bus. Le message est évalué et les abonnements inscrits reçoivent l'événement. L'association auquel vous êtes abonnée est trouvée et que le flux de travail est démarré. Pour plus d'informations sur le fonctionnement de ce processus, consultez l'article MSDN, Notions de base sur les flux de travail SharePoint.
Ce doit clarifier, puis, pourquoi les associations de flux de travail sont maintenant appelées des abonnements dans l'API (autrement dit, dans les coulisses). Vous pouvez utiliser un Service d'abonnement dans le CSOM de Services de flux de travail pour Explorer les abonnements et les associations existantes, créer et supprimer des associations et des abonnements et demander à être averti des événements.
L'objet WorkflowSubscriptionService est disponible via la classe WorkflowServicesManager, comme illustré dans les exemples de code suivants.
CSOM : Obtenir une instance WorkflowSubscriptionService
var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
var workflowSubscriptionService = workflowServicesManager.GetWorkflowSubscriptionService();
JSOM : Obtenir une instance WorkflowSubscriptionService
var clientContext = SP.ClientContext.get_current();
var workflowServicesManager = SP.WorkflowServices.WorkflowServicesManager.newObject(context, context.get_web());
var workflowSubscriptionService = workflowServicesManager.getWorkflowSubscriptionService();
Service instance
Le service final que nous traiterons est le service de l'instance. Vous pouvez utiliser ce service pour effectuer plusieurs tâches avec des instances de workflow, tels que le démarrage, suspension, reprise, arrêt et l'annulation des instances de workflow. Vous pouvez également l'utiliser pour collecter des informations de débogage, ainsi que d'énumérer tous en cours d'exécution des flux de travail, ainsi que ceux qui ont déjà effectué. Enfin, vous pouvez utiliser ce service pour publier des événements dans des flux de travail qui est en cours d'exécution, comme nous le verrons plus loin dans cet article.
L'objet WorkflowInstanceService est disponible via la classe WorkflowServicesManager, comme illustré dans les exemples de code suivants.
CSOM : Obtenir une instance WorkflowInstanceService
var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
var workflowInstanceService = workflowServicesManager.GetWorkflowInstanceService();
JSOM : Obtenir une instance WorkflowInstanceService
var clientContext = SP.ClientContext.get_current();
var workflowServicesManager = SP.WorkflowServices.WorkflowServicesManager.newObject(context, context.get_web());
var workflowInstanceService = workflowServicesManager.getWorkflowInstanceService();
Service Interop
Dans les versions précédentes de SharePoint, spécifiquement SharePoint 2007 et SharePoint 2010, SharePoint hébergeait le runtime de Windows Workflow Foundation. Comme indiqué précédemment, Microsoft s’est éloigné de cette approche dans SharePoint en introduisant une dépendance sur Workflow Manager 1.0, qui héberge le runtime de flux de travail en dehors de SharePoint. Par conséquent, les flux de travail ne sont plus exécutés et gérés dans SharePoint ; à la place, SharePoint passe la gestion de flux de travail et l’exécution du flux de travail à Workflow Manager 1.0.
Toutefois, pour des raisons de compatibilité ascendante, Microsoft a conservé les flux de travail hérités de style Pre-SharePoint dans SharePoint en conservant le moteur d'exécution Windows Workflow Foundation. Par conséquent, tous les workflows créés dans SharePoint 2010 seront exécutés comme prévu dans un environnement SharePoint. En outre, Microsoft a inclus une nouvelle activité, InvokeSharePointWorkflow, qui peut être utilisée dans un flux de travail SharePoint pour démarrer un workflow existant dans l'hôte de flux de travail SharePoint 2010 qui est inclus dans SharePoint. Cela vous permet de tirer parti des investissements migrés à partir des versions précédentes de workflow existant.
Notes
L'activité InvokeSharePointWorkflow est un wrapper pour la méthode CSOM, StartWorkflow .
Le CSOM de Services de flux de travail SharePoint inclut également un service spécial qui permet aux développeurs d'interagir avec les flux de travail hérités. Le InteropService vous permet de démarrer et arrêter le flux de travail, ainsi qu'activer et désactiver les notifications d'événement pour l'exécution des workflows.
L'objet WorkflowDeploymentService est disponible via la classe WorkflowServicesManager, comme illustré dans les exemples de code suivants CSOM et JSOM.
CSOM : Obtenir une instance InteropService
var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
var workflowInteropService = workflowServicesManager.GetWorkflowInteropService();
JSOM : Obtenir une instance InteropService
var clientContext = SP.ClientContext.get_current();
var workflowServicesManager = SP.WorkflowServices.WorkflowServicesManager.newObject(context, context.get_web());
var workflowInteropService = serviceManager.getWorkflowInteropService();
Exemple : Scénarios de flux de travail Services CSOM
Les sections suivantes montrent comment utiliser les différents services dans le CSOM Services de flux de travail pour effectuer des tâches courantes dans des solutions personnalisées.
Obtenir tous les flux de travail installés
La plupart des autres services de le CSOM de Services de flux de travail requièrent que vous obtenez des références à la définition de flux de travail qui a été publié. Définitions de workflow sont généralement référencées par leur ID, qui est des GUID.
Pour obtenir une liste de toutes les définitions de flux de travail publié, obtenez d'abord une instance du service de déploiement à l'aide de la méthode GetWorkflowDeploymentService . Ensuite, récupérer la collection de toutes les définitions de flux de travail à l'aide de la méthode EnumerateDefinitions(Boolean) . Voici un exemple de code :
// connect to the workflow services via a CSOM client context
var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
// connect to the deployment service
var workflowDeploymentService = workflowServicesManager.GetWorkflowDeploymentService();
// get all installed workflows
var publishedWorkflowDefinitions = workflowDeploymentService.EnumerateDefinitions(true);
clientContext.Load(publishedWorkflowDefinitions);
clientContext.ExecuteQuery();
// display list of all installed workflows
foreach (var workflowDefinition in publishedWorkflowDefinitions) {
Console.WriteLine("{0} - {1}", workflowDefinition.Id.ToString(), workflowDefinition.DisplayName);
}
Obtenir tous les abonnements et les associations
Pour démarrer une nouvelle instance de flux de travail, vous devez d'abord obtenir une référence à une association de flux de travail existant. S'appuyant sur l'exemple de code précédent, l'exemple suivant montre comment obtenir une liste de toutes les associations de flux de travail d'une définition de flux de travail spécifique dans un site.
Une fois que vous avez obtenu une définition de flux de travail à l'aide de l'exemple ci-dessus, utilisez la méthode GetWorkflowSubscriptionService pour créer une instance du service d'abonnement. Ensuite, utilisez la méthode EnumerateSubscriptionsByDefinition (en passant l'ID d'une définition de flux de travail) pour obtenir une liste de toutes les associations qui existent pour le flux de travail spécifié. Notez qu'il existe plusieurs méthodes permettant d'obtenir des associations de flux de travail, y compris les éléments suivants :
L'exemple de code suivant illustre l'obtention des associations et des abonnements.
// connect to the workflow services via a CSOM client context
var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
// connect to the deployment service
var workflowDeploymentService = workflowServicesManager.GetWorkflowDeploymentService();
// get all installed workflows
var publishedWorkflowDefinitions = workflowDeploymentService.EnumerateDefinitions(true);
clientContext.Load(publishedWorkflowDefinitions);
clientContext.ExecuteQuery();
// find the first workflow definition
var firstWorkflowDefinition = publishedWorkflowDefinitions.First();
// connect to the subscription service
var workflowSubscriptionService = workflowServicesManager.GetWorkflowSubscriptionService();
// get all workflow associations
var workflowAssociations = workflowSubscriptionService.EnumerateSubscriptionsByDefinition(firstWorkflowDefinition.Id);
clientContext.Load(workflowAssociations);
clientContext.ExecuteQuery();
foreach (var association in workflowAssociations) {
Console.WriteLine("{0} - {1}",
association.Id, association.Name);
}
Ajouter une association de flux de travail
Création d'une nouvelle association de flux de travail, qui peut également être appelée un abonnement, exige des efforts supplémentaires avant de réellement publier l'association vers SharePoint. C'est pourquoi chaque abonnement doit disposer d'informations supplémentaires, qui sont normalement recueillies sur la page association. Ces métadonnées incluent les éléments suivants :
L'ID de la définition de flux de travail, l'association est basée sur.
L'ID de la bibliothèque SharePoint site, liste ou document l'association de flux de travail est créée sur.
Le nom complet de l'association.
Le démarrage d'options (si démarré manuellement ou automatiquement lorsqu'un élément de liste est ajouté ou mis à jour).
ID de la liste qui stockera tous les messages de liste de l'historique pour cette association.
ID de la liste qui stockera toutes les tâches de cette association.
Le cas échéant, une collection de toutes les paires nom/valeur qui doit être envoyé vers le flux de travail. Ce sont les champs qui sont généralement transmis par un formulaire d'association personnalisé.
Créer une association de flux de travail personnalisée
- Pour créer une association personnalisée, utilisez d'abord la méthode GetWorkflowSubscriptionService pour obtenir une référence pour le service d'abonnement.
// connect to the deployment service
var workflowDeploymentService = workflowServicesManager.GetWorkflowDeploymentService();
// get all installed workflows
var publishedWorkflowDefinitions = workflowDeploymentService.EnumerateDefinitions(true);
clientContext.Load(publishedWorkflowDefinitions);
clientContext.ExecuteQuery();
// find the first workflow definition
var firstWorkflowDefinition = publishedWorkflowDefinitions.First();
// connect to the subscription service
var workflowSubscriptionService = workflowServicesManager.GetWorkflowSubscriptionService();
Créer une nouvelle instance de l'objet de la classe WorkflowSubscription .
Définissez les propriétés requises sur l'objet WorkflowSubscription, comme illustré dans l'exemple de code suivant. Dans l'exemple, commentaires de code expliquent chacun des paramètres de propriété. Notez que certaines propriétés qui ne sont pas pertinentes pour les services de flux de travail CSOM ont été oubliées pour une meilleure lisibilité. Ces propriétés ont été omises :
listId. ID de la liste à laquelle l'association est créée.
historyListId. ID de la liste qui stocke tous les messages de liste de l'historique de l'association.
taskListId. ID de la liste qui stockera toutes les tâches de l'association.
Une fois créé, l'abonnement doit être publié à SharePoint à l'aide de la méthode PublishSubscriptionForList , comme illustré dans l'exemple de code suivant :
// create a new association / subscription
WorkflowSubscription newSubscription = new WorkflowSubscription(clientContext) {
DefinitionId = firstWorkflowDefinition.Id,
Enabled = true,
Name = "New Workflow Association"
};
var startupOptions = new List<string>();
// automatic start
startupOptions.Add("ItemAdded");
startupOptions.Add("ItemUpdated");
// manual start
startupOptions.Add("WorkflowStart");
// set the workflow start settings
newSubscription.EventTypes = startupOptions;
// set the associated task and history lists
newSubscription.SetProperty("HistoryListId", workflowHistoryListId.ToString());
newSubscription.SetProperty("TaskListId", workflowTaskListId.ToString());
// OPTIONAL: add any association form values
newSubscription.SetProperty("Prop1","Value1");
newSubscription.SetProperty("Prop2","Value2");
// create the association
workflowSubscriptionService.PublishSubscriptionForList(newSubscription, listId);
clientContext.ExecuteQuery();
Obtenir toutes les instances de flux de travail
Vous pouvez également utiliser les services d'instance de flux de travail pour afficher toutes les instances de workflow qui sont exécutent sur un site, une liste ou une bibliothèque de documents SharePoint. L'objet d'instance qui est retourné contient des informations sur l'instance, tels que lorsqu'il a été mis à jour l'état en cours et toutes les erreurs qui ont peuvent se produire lorsqu'il a été exécuté précédemment. En outre, elle fournit une collection de paires nom/valeur qui ont été soumis au flux de travail à partir du formulaire d'initiation personnalisées.
Pour ce faire, démarrez à l'aide de la méthode GetWorkflowInstanceService pour obtenir une référence à l'instance de service. Notez que le WorkflowInstanceService fournit plusieurs méthodes permettant d'obtenir la collection des instances de workflow en cours d'exécution :
Enumerate . Accepte une association de flux de travail (autrement dit, un abonnement) en tant que paramètre et peut être utilisé pour obtenir toutes les instances qui ont été créés en fonction de l'association spécifiée.
EnumerateInstancesForSite : création d'une liste de toutes les instances de workflow qui a été démarré sur le site SharePoint qui a été défini lorsque Obtient l'objet WorkflowServiceManager d'origine.
EnumerateInstancesForListItem . Accepte une liste d'ID et l'ID de l'élément ; Cette méthode permet d'obtenir toutes les instances de workflow qui ont été créés sur un élément de liste spécifique.
Chacune de ces méthodes possède également une méthode de remplacement *WithOffset() (par exemple, EnumerateWithOffset ). Ces méthodes permettent d'obtenir un sous-ensemble des instances de flux de travail dans les cas où le travail avec l'ensemble de la collection serait fastidieux. Pour obtenir le nombre d'instances de flux de travail, utilisez la méthode CountInstances ou la méthode CountInstancesWithStatus .
L'exemple de code suivant illustre l'obtention des instances de workflow :
// connect to the instance service
var workflowInstanceService = workflowServicesManager.GetWorkflowInstanceService();
// get all instances
var workflowInstances = workflowInstanceService.EnumerateInstancesForListItem(listId, listItemId);
foreach (var instance in workflowInstances)
{
Console.WriteLine("{0} - {1} - {2}",
instance.Id.ToString(),
instance.LastUpdated,
instance.Status.ToString());
}
Démarrer une instance de flux de travail
Démarrez une nouvelle instance d'une association de flux de travail consiste à répéter la plupart des étapes qui ont été démontrés dans les exemples précédents. Pour démarrer un flux de travail sur un élément dans une liste ou bibliothèque de documents, d'abord obtenir une référence à l'association de flux de travail et l'ID de l'élément dans la liste. Une collection de paires nom/valeur d'informations peut être envoyée vers le flux de travail lorsqu'il est démarré. Cela se produit lorsqu'il existe un formulaire d'initiation personnalisé qui est utilisé pour collecter les données de l'utilisateur de démarrage du workflow. Passez dans une collection, même s'il est une collection vide, lorsque le flux de travail ou du flux de travail ne pourra pas démarrer et renvoie une erreur.
Création dans les exemples précédents, utilisez la méthode GetWorkflowInstanceService pour obtenir une instance du service d'instance de flux de travail. Ensuite, démarrez le flux de travail en appelant une des deux méthodes. Un démarre des flux de travail sur un site, tandis que l'autre lance un flux de travail sur un élément de liste.
StartWorkflow . Démarre un flux de travail sur le site SharePoint qui a été défini lors de la création de l'objet WorkflowServicesManager d'origine. Lorsque vous utilisez cette méthode, vous devez passer l'association de flux de travail et les propriétés de démarrage supplémentaires présentes sur le formulaire d'initiation.
StartWorkflowOnListItem . Démarre un flux de travail sur un élément de liste spécifique. À l'aide de cette méthode vous oblige à passer l'ID de l'élément de liste de votre choix, en plus d'autres valeurs de paramètres requis par la méthode StartWorkflow.
L'exemple de code suivant montre comment démarrer une instance de workflow.
// connect to the deployment service
var workflowDeploymentService = workflowServicesManager.GetWorkflowDeploymentService();
// get all installed workflows
var publishedWorkflowDefinitions = workflowDeploymentService.EnumerateDefinitions(true);
clientContext.Load(publishedWorkflowDefinitions);
clientContext.ExecuteQuery();
// find the first workflow definition
var firstWorkflowDefinition = publishedWorkflowDefinitions.First();
// connect to the subscription service
var workflowSubscriptionService = workflowServicesManager.GetWorkflowSubscriptionService();
// get all workflow associations
var workflowAssociations = workflowSubscriptionService.EnumerateSubscriptionsByDefinition(firstWorkflowDefinition.Id);
clientContext.Load(workflowAssociations);
clientContext.ExecuteQuery();
// find the first association
var firstWorkflowAssociation = workflowAssociations.First();
// connect to the instance service
var workflowInstanceService = workflowServicesManager.GetWorkflowInstanceService();
// start the workflow
var startParameters = new Dictionary<string, object>();
workflowInstanceService.StartWorkflowOnListItem(firstWorkflowAssociation, listItemId, startParameters);
clientContext.ExecuteQuery();
Publier des messages et événements aux flux de travail en cours d’exécution
Une autre fonctionnalité puissante qui a été ajoutée dans SharePoint est la possibilité de publier des événements personnalisés dans les instances de flux de travail en cours d'exécution. Ces flux de travail peut avoir une activité, WaitForCustomEvent, qui est à l'écoute d'un événement spécifique doit être publié sur le flux de travail. L'événement peut également contenir une chaîne en tant que partie du message, l'activité peut stocker en tant que variable.
Pour publier un événement à partir du client à l'aide de la CSOM du Service de flux de travail, commencez par obtenir une référence à l'instance de workflow spécifique que l'événement doit être publiée dans. Puis, à l'aide du service de l'instance, publie l'événement à l'aide de la méthode PublishCustomEvent . Lorsque vous utilisez cette méthode, vous devez passer l'instance souhaitée, le nom de l'événement et une charge utile facultative, comme indiqué dans l'exemple de code suivant.
// connect to the instance service
var workflowInstanceService = workflowServicesManager.GetWorkflowInstanceService();
// get all instances
var workflowInstances = workflowInstanceService.EnumerateInstancesForListItem(listId, listItemId);
var targetInstance = workflowInstances.First();
// publish custom event
instanceService.PublishCustomEvent(targetInstance, "AdHocMaintenanceRequest", "Flat Tire");
clientContext.ExecuteQuery();
Pour recevoir le message dans le flux de travail, ajoutez une activité WaitForCustomEvent et, à l'aide de la fenêtre Propriétés, affectez à la propriété EventName pour le nom de l'événement est à l'écoute de l'activité (dans l'exemple ci-dessus, ce serait la chaîne « AdHocMaintenanceRequest »). Puis, définissez la propriété Result à la variable dans laquelle la charge utile de l'événement est stocké, comme illustré à la Figure 2.
La figure 2. EventName en entrée et sortie résultat

Cette technique de publication d'un événement personnalisé est illustrée dans l'exemple de Code MSDN : SharePoint : itinéraires de flux de travail pour les États en fonction des Actions et des événements.
Conclusion
Microsoft a introduit des workflows dans la plate-forme SharePoint 2007 et la plate-forme de flux de travail est resté principalement inchangé dans SharePoint 2010. Ceci était également vrai lorsqu'il était à des formulaires personnalisés dans le flux de travail SharePoint. SharePoint, d'autre part, introduit de nombreuses modifications à l'architecture et la plate-forme de flux de travail.
L'une des améliorations majeures dans les flux de travail de SharePoint est l'expansion de CSOM pour inclure une API de Services de flux de travail complète. Cet ajout permet aux développeurs d’interagir avec les définitions de flux de travail, les associations et les abonnements et de créer et d’interagir avec les instances de ces flux de travail.