Compartir a través de

Trabajar con el modelo de objetos del lado cliente de los servicios de flujo de trabajo de SharePoint

Muestra cómo usar la API de modelo (COM) de objetos de cliente de SharePoint para crear y controlar las instancias y definiciones de flujo de trabajo de Administrador de flujos de trabajo 1.0. Proporcionado por:Andrew Connell, Voitanos

Nota:

Los flujos de trabajo de SharePoint 2010 se han retirado desde el 1 de agosto de 2020 para los nuevos espacios empresariales y se han quitado de los espacios empresariales existentes el 1 de noviembre de 2020. Si está usando los flujos de trabajo de SharePoint 2010, le recomendamos que migre a Power Automate u otras soluciones compatibles. Para más información, consulte Retirada del flujo de trabajo de SharePoint 2010.

Trabajar con el modelo de objetos del lado cliente de los servicios de flujo de trabajo de SharePoint

La implementación de flujos de trabajo en SharePoint 2007 y SharePoint 2010 se mantuvo en gran medida la misma desde una versión a otra. Microsoft ha agregado algunas funcionalidades nuevas SharePoint 2010, como la capacidad para asociar los flujos de trabajo con los sitios y mejora el flujo de trabajo de creación herramientas, SharePoint Designer 2010 y Visual Studio 2010, de sus predecesores. Sin embargo, la implementación de tareas de flujo de trabajo, formularios de flujo de trabajo y el permanece de las API del lado servidor de flujo de trabajo sin en gran medida los cambios.

En SharePoint 2010, Microsoft presenta las características y funcionalidades que se aconseja a los clientes para mover sus personalizaciones en solución de espacio aislado. Estos tendría que ejecutar en un proceso aislado y estaban descriptivos a ambos tipos de implementaciones de SharePoint: local, donde se ha instalado en los servidores de la compañía y se mantiene por la empresa y a la nube, o más concretamente, Office 365 SharePoint.

En SharePoint, Microsoft agregó incluso más funciones; estas actualizaciones se han orientado a las implementaciones de nube. En concreto, Microsoft presentó el nuevo modelo de aplicación de SharePoint, que van más allá del solución de espacio aislado en que, a diferencia de solución de espacio aislado, bloquea de forma explícita el código del servidor deje de ejecutarse en el proceso de SharePoint. Microsoft también creó tecnologías existentes en SharePoint, como el modelo de objetos del lado cliente (CSOM), e introdujo nuevas funcionalidades, como la compatibilidad con identidades de aplicación mediante OAuth.

Y, con la introducción de SharePoint, Microsoft introdujo una plataforma y arquitectura de flujo de trabajo completamente nuevas que reflejan cambios fundamentales en la dirección del producto.

El cambio más importante en la nueva arquitectura es que la ejecución de flujo de trabajo en SharePoint ya no se lleva a cabo en SharePoint. En su lugar, SharePoint utiliza un motor de ejecución totalmente nuevo: Administrador de flujos de trabajo 1.0. Administrador de flujos de trabajo hospeda el tiempo de ejecución Windows Workflow Foundation y todos los servicios necesarios por Windows Workflow Foundation. Cuando se publica un flujo de trabajo o se inicia una nueva instancia de un flujo de trabajo publicado, SharePoint se lo notifica al Administrador de flujos de trabajo que, a su vez, procesa los episodios del flujo de trabajo. Cuando el flujo de trabajo tienen acceso a información en SharePoint, como las propiedades de elementos de lista o propiedades de usuario, se autentica mediante la compatibilidad de OAuth y se comunica a través de la API de REST de nuevas y mejoradas.

Estos cambios en la arquitectura de flujo de trabajo tenían impactos significativos en determinadas áreas, como los formularios de flujo de trabajo personalizado, tal como se explica en el artículo de MSDN "Cómo: crear formularios de flujo de trabajo personalizado de SharePoint con Visual Studio 2012. En este artículo se mencionan una de las cosas que Microsoft agregó a SharePoint para admitir el nuevo estilo de creación de formularios de flujo de trabajo personalizado: las mejoras en el CSOM y la adición de la API de CSOM de servicios de flujo de trabajo.

Introducción a la API de CSOM de servicios de flujo de trabajo en SharePoint

En SharePoint 2007 y SharePoint 2010, la API de flujo de trabajo se manifiesta sólo en el modelo de objetos del lado servidor. En SharePoint, esta misma API de flujo de trabajo sigue presente, ya que SharePoint incluye el antiguo motor de ejecución de flujo de trabajo de SharePoint para la compatibilidad con versiones anteriores.

Sin embargo, la nueva y preferida arquitectura de flujo de trabajo introducida con SharePoint que utiliza Administrador de flujos de trabajo incluye una nueva API del lado servidor. En SharePoint, Microsoft amplió el CSOM para incluir una API eficaz para la nueva arquitectura de flujo de trabajo. Tenga en cuenta que esta adición al CSOM solo se aplica a la nueva arquitectura de flujo de trabajo de SharePoint y Administrador de flujos de trabajo 1.0, no a la versión heredada que todavía está hospedada en SharePoint.

La API de CSOM de servicios de flujo de trabajo, al igual que el resto del CSOM, se implementa en una API de Silverlight administrado de .NET y una API de JavaScript conocido como el modelo de objeto (JSOM) JavaScript. JSOM es lo que los programadores deben usar al crear formularios de flujo de trabajo personalizado, como los formularios será de formularios web forms ASP.NET que no deben tener ningún código del lado servidor. Por lo tanto se usa la API del JSOM de servicios de flujo de trabajo en los formularios de asociación personalizado para crear asociaciones de flujo de trabajo, así como en los formularios de inicio para iniciar nuevas instancias de flujo de trabajo.

Pero las posibilidades no se acaban aquí. El JSOM y CSOM de servicios de flujo de trabajo es muy sólido y permite a los programadores hacer casi cualquier cosa con flujos de trabajo en SharePoint. Aparte de crear instancias y asociaciones de flujo de trabajo, los desarrolladores pueden implementar también mediante programación nuevas definiciones de flujo de trabajo e incluso comunicarse con instancias de flujo de trabajo en ejecución desde el CSOM y JSOM, tal como se describe en el resto de este artículo.

En este artículo se centra en el tema de los formularios de flujo de trabajo en el contexto de SharePoint Server 2013. Se basa en SharePoint con la actualización pública de marzo de 2013 aplicada y Office Developer Tools para Visual Studio 2013. Todo el contenido de este artículo se aplica a las implementaciones locales de SharePoint, así como a Office 365.

Componentes de la API de JSOM y CSOM de Servicios de flujo de trabajo

En este artículo se centra en la API de CSOM de servicios de flujo de trabajo y por lo tanto, por extensión, así como; la API de JSOM no se describe aquí en el lado del servidor API de servicios de flujo de trabajo. El CSOM de servicios de flujo de trabajo consta de varios servicios diferentes que se usan para realizar tareas diferentes. En las secciones siguientes se describe cada una de estas.

Nota:

[!NOTA] Hay un servicio adicional que no está presente en el CSOM, pero está presente en su lugar con la API del lado servidor. Este es el servicio de mensajería, que se usa para administrar message Queue Server y transporte de mensajes.

Para trabajar con las API de JSOM y el CSOM de servicios de flujo de trabajo, los desarrolladores deben agregar las referencias necesarias a sus proyectos (en el caso de COM) y páginas (en el caso de JSOM). Ambas implementaciones tienen los mismos requisitos:

  • Referencia a las bibliotecas principales CSOM y JSOM de SharePoint:
    • Microsoft.SharePoint.Client.dll
    • Microsoft.SharePoint.Client.Runtime.dll
    • Microsoft.SharePoint.Client.WorkflowServices.dll
  • Hacer referencia a las bibliotecas de CSOM de servicios de flujo de trabajo y JSOM:
    • SP.js
    • SP.Runtime.js
    • SP.WorkflowServices.js

Administrador de servicios de flujo de trabajo

La puerta de enlace a todos los servicios incluidos en la API de CSOM de servicios de flujo de trabajo es el Administrador de servicios de flujo de trabajo. Este objeto es lo que los programadores utilizar para obtener instancias a todos los demás servicios que se describen en las secciones siguientes. De forma similar a otras implementaciones de API de CSOM, WorkflowServicesManager tiene una dependencia en el CSOM de SharePoint principal y, por lo tanto, debe pasar un contexto de cliente válido y una referencia al sitio de SharePoint al que desea conectarse, como se muestra en los siguientes ejemplos de código de CSOM y JSOM.

CSOM: crear una instancia WorkflowServicesManager

var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);

JSOM: crear una instancia WorkflowServicesManager

var clientContext = SP.ClientContext.get_current();
var workflowServicesManager = SP.WorkflowServices.WorkflowServicesManager.newObject(context, context.get_web());

Servicio de implementación

Al crear flujos de trabajo personalizados con Visual Studio 2012, ya sea con un paquete de solución (.wsp) o como una aplicación de SharePoint ( .app), va a crear definiciones de flujo de trabajo. Una definición es el proceso de flujo de trabajo y todas las reglas de negocio y atributos definidos dentro de él, como la ubicación de los formularios de inicio y asociación personalizado. En su propio, estas definiciones no son muy útiles debido a no se pueden ejecutar fuera del contexto de una asociación con un sitio, lista o biblioteca de documentos. Pueden encontrar las definiciones de flujo de trabajo publicadas y están disponibles en un sitio, vaya a la página donde se puede crear una nueva asociación de flujo de trabajo, tal como se muestra en la ilustración siguiente.

Figura 1. Agregar una asociación de flujo de trabajo Figura 1. Agregar una asociación de flujo de trabajo

La colección de definiciones de flujo de trabajo publicadas es accesible a través del servicio de implementación. Este servicio permite obtener una lista de todas las definiciones actualmente guardadas y publicadas en el sitio, así como para publicar ambas guardado y nuevas definiciones, quitar las definiciones existentes y determinar las acciones de flujo de trabajo que están disponibles para SharePoint Designer 2013-creados los flujos de trabajo.

El objeto WorkflowDeploymentService está disponible a través de la clase WorkflowServicesManager, como se muestra en los siguientes ejemplos de código.

CSOM: obtener una instancia WorkflowDeploymentService

var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
var workflowDeploymentService = workflowServicesManager.GetWorkflowDeploymentService();

JSOM: obtener una instancia WorkflowDeploymentService

var clientContext = SP.ClientContext.get_current();
var workflowServicesManager = SP.WorkflowServices.WorkflowServicesManager.newObject(context, context.get_web());
var workflowDeploymentService = workflowServicesManager.getWorkflowDeploymentService();

Servicio de suscripción

Recuperación de la sección anterior que crear flujos de trabajo y publicar en SharePoint como definiciones. Para usar estas definiciones, un usuario debe crear una asociación que vincula la definición de un sitio específico de SharePoint, lista o biblioteca de documentos junto con los metadatos adicionales. Este proceso funciona y se comporta básicamente de la misma forma en SharePoint 2010, pero la implementación en SharePoint es muy diferente. Administrador de flujos de trabajo 1.0 aprovecha las ventajas de una instancia de Microsoft Azure 1.0 de Bus de servicio.

Bus de servicio es fundamental para porque es compatible con el servicio de publicación y suscripción (también conocido como PubSub). Se trata de un marco de mensajería asincrónico que es compatible con un editor de enviar un mensaje a un tema que se almacenan en el Bus de servicio. Cualquier número de suscriptores puede solicitar para recibir una notificación cuando se publica un mensaje en ese tema que cumple determinados criterios.

SharePoint y Administrador de flujos de trabajo 1.0 usan el modelo de PubSub para crear asociaciones. Asociaciones de flujo de trabajo se crean como suscripciones en temas. Por ejemplo, una asociación de definición de flujo de trabajo puede crearse en la lista y configurada para iniciarse automáticamente cuando se agregan elementos a la lista. Cuando se agrega un elemento a la lista, SharePoint publica un evento en Administrador de flujos de trabajo 1.0, que envía al tema de Bus de servicio. El mensaje se evalúa y se informa a las suscripciones registradas del evento. La asociación está suscrita se encuentra y se inicia el flujo de trabajo. Para obtener más información sobre cómo funciona este proceso, consulte el artículo de MSDN, Aspectos básicos del flujo de trabajo de SharePoint.

Esto debe aclarar, entonces, ¿por qué las asociaciones de flujo de trabajo se denominan ahora suscripciones dentro de la API (es decir, en segundo plano). Puede usar un servicio de suscripción en el CSOM de servicios de flujo de trabajo para explorar las suscripciones y asociaciones existentes, crear y eliminar suscripciones y asociaciones y solicitar una notificación de eventos.

El objeto WorkflowSubscriptionService está disponible a través de la clase WorkflowServicesManager , como se muestra en los ejemplos de código siguientes.

CSOM: obtener una instancia WorkflowSubscriptionService 

var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
var workflowSubscriptionService = workflowServicesManager.GetWorkflowSubscriptionService();

JSOM: obtener una instancia WorkflowSubscriptionService 

var clientContext = SP.ClientContext.get_current();
var workflowServicesManager = SP.WorkflowServices.WorkflowServicesManager.newObject(context, context.get_web());
var workflowSubscriptionService = workflowServicesManager.getWorkflowSubscriptionService();

Servicio de instancia

El servicio final que trataremos es el servicio de instancia. Puede usar este servicio para realizar varias tareas con instancias de flujo de trabajo, como iniciar, suspender, reanudar, finalización y cancelación de instancias de flujo de trabajo. También puede utilizarlo para recopilar información de depuración, así como enumerar a través de todos están ejecutando los flujos de trabajo, así como los que ya ha completado. Por último, puede usar este servicio para publicar los eventos en los flujos de trabajo que se están ejecutando, como veremos más adelante en este artículo.

El objeto WorkflowInstanceService está disponible a través de la clase WorkflowServicesManager , como se muestra en los ejemplos de código siguientes.

CSOM: obtener una instancia WorkflowInstanceService 

var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
var workflowInstanceService = workflowServicesManager.GetWorkflowInstanceService();

JSOM: obtener una instancia WorkflowInstanceService 

var clientContext = SP.ClientContext.get_current();
var workflowServicesManager = SP.WorkflowServices.WorkflowServicesManager.newObject(context, context.get_web());
var workflowInstanceService = workflowServicesManager.getWorkflowInstanceService();

Servicio de interoperabilidad

En versiones anteriores de SharePoint, específicamente SharePoint 2007 y SharePoint 2010, SharePoint hospedaba el tiempo de ejecución de Windows Workflow Foundation. Como se explicó anteriormente, Microsoft se alejó de este enfoque en SharePoint al introducir una dependencia en Administrador de flujos de trabajo 1.0, que hospeda el tiempo de ejecución de flujo de trabajo fuera de SharePoint. Por lo tanto, los flujos de trabajo ya no se ejecutan y administran dentro de SharePoint; en su lugar, SharePoint entrega las responsabilidades de administración y ejecución del flujo de trabajo a Administrador de flujos de trabajo 1.0.

Sin embargo, para proporcionar compatibilidad con versiones anteriores, Microsoft conserva en SharePoint el modelo heredado de hospedaje de flujos de trabajo anteriores a SharePoint al mantener el motor de tiempo de ejecución de Windows Workflow Foundation. Por lo tanto, todos los flujos de trabajo creados en SharePoint 2010 seguirán funcionando según lo previsto en un entorno de SharePoint. Además, Microsoft incluyó una nueva actividad, InvokeSharePointWorkflow, que se puede usar en un flujo de trabajo de SharePoint para iniciar un flujo de trabajo existente en el host de flujo de trabajo de SharePoint 2010 que se incluye en SharePoint. Esto le permite aprovechar las inversiones han migrado desde versiones anteriores de flujo de trabajo existente.

Nota:

La actividad de InvokeSharePointWorkflow es un contenedor para el método CSOM, StartWorkflow .

El CSOM de servicios de flujo de trabajo de SharePoint también incluye un servicio especial que permite a los desarrolladores interactuar con estos flujos de trabajo heredados. InteropService permite iniciar y detener flujos de trabajo, así como habilitar y deshabilitar notificaciones de eventos para ejecutar flujos de trabajo.

El objeto WorkflowDeploymentService está disponible a través de la clase WorkflowServicesManager , como se muestra en los siguientes ejemplos de código de CSOM y JSOM.

CSOM: obtener una instancia InteropService 

var clientContext = new ClientContext(siteCollectionUrl);
var workflowServicesManager = new WorkflowServicesManager(clientContext, clientContext.Web);
var workflowInteropService = workflowServicesManager.GetWorkflowInteropService();

JSOM: obtener una instancia InteropService 

var clientContext = SP.ClientContext.get_current();
var workflowServicesManager = SP.WorkflowServices.WorkflowServicesManager.newObject(context, context.get_web());
var workflowInteropService = serviceManager.getWorkflowInteropService();

Ejemplo: escenarios de CSOM de servicios de flujo de trabajo

Las secciones siguientes muestran cómo usar los distintos servicios en el CSOM de servicios de flujo de trabajo para realizar tareas comunes en soluciones personalizadas.

Obtener todos los flujos de trabajo instalados

La mayoría de los otros servicios en el CSOM de servicios de flujo de trabajo requieren que obtener referencias a la definición de flujo de trabajo que se publicó anteriormente. Normalmente se hace referencia a las definiciones de flujo de trabajo por sus identificadores, que son GUID.

Para obtener una lista de todas las definiciones de flujo de trabajo publicadas, primero obtenga una instancia del servicio de implementación mediante el método GetWorkflowDeploymentService . A continuación, recupere la colección de todas las definiciones de flujo de trabajo mediante el método EnumerateDefinitions(Boolean) . Este es el código de ejemplo:

// 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);
}

Obtener todas las asociaciones y suscripciones

Para iniciar una nueva instancia de flujo de trabajo, deberá obtener una referencia a una asociación de flujo de trabajo existente. Basándose en el ejemplo de código anterior, en el siguiente ejemplo se muestra cómo obtener una lista de todas las asociaciones de flujo de trabajo de una definición de flujo de trabajo específico de un sitio.

Una vez que haya obtenido una definición de flujo de trabajo con el ejemplo anterior, use el método GetWorkflowSubscriptionService para crear una instancia del servicio de suscripción. A continuación, utilice el método EnumerateSubscriptionsByDefinition (pasando el identificador de una definición de flujo de trabajo) para obtener una lista de todas las asociaciones que existen para el flujo de trabajo especificado. Tenga en cuenta que existen varios métodos disponibles para obtener las asociaciones de flujo de trabajo, incluidas las siguientes:

En el ejemplo de código siguiente se muestra cómo obtener asociaciones y suscripciones:

// 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);
}

Crear una asociación de flujo de trabajo

Creación de una nueva asociación de flujo de trabajo, que puede también se conoce como una suscripción, requiere un esfuerzo adicional antes de publicar realmente la asociación a SharePoint. Esto es debido a que cada suscripción debe tener información adicional, que normalmente se recopila en la página de asociación. Estos metadatos incluyen lo siguiente:

  • El identificador de la definición de flujo de trabajo que se basa la asociación.
  • El identificador de la biblioteca de documentos, lista o sitio de SharePoint en la que se crea la asociación de flujo de trabajo.
  • El nombre para mostrar de la asociación.
  • El inicio de las opciones (si iniciar de forma manual o automáticamente cuando se agrega o actualiza un elemento de lista).
  • Identificador de la lista que se va a almacenar todos los mensajes de la lista de historial para esta asociación.
  • Identificador de la lista que se va a almacenar todas las tareas de esta asociación.
  • De forma opcional, una colección de los pares nombre/valor que se debe enviar al flujo de trabajo. Estos son los campos que normalmente se pasan desde un formulario de asociación personalizado.

Crear una asociación de flujo de trabajo personalizada

  1. Para crear una asociación personalizada, use primero el método GetWorkflowSubscriptionService para obtener una referencia al servicio de suscripción.

    // 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();

  2. Cree una nueva instancia de objeto de la clase WorkflowSubscription .

  3. Establecer las propiedades necesarias en el objeto WorkflowSubscription, como se ilustra en el siguiente ejemplo de código. En el ejemplo, comentarios de código explican cada uno de los valores de propiedad. Tenga en cuenta que algunas propiedades que no son relevantes para los servicios de flujo de trabajo CSOM se han dejado para mejorar la legibilidad. Se omiten estas propiedades:

  4. listId. Identificador de la lista en el que se crea la asociación.

  5. historyListId. Identificador de la lista que almacena todos los mensajes de la lista de historial de la asociación.

  6. taskListId. Identificador de la lista que se va a almacenar todas las tareas de la asociación.

  7. Una vez creada, la suscripción debe publicarse en SharePoint mediante el método PublishSubscriptionForList , como se muestra en el ejemplo de código siguiente:

// 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();

Obtener todas las instancias del flujo de trabajo

También puede usar el servicio de la instancia de servicios de flujo de trabajo para ver todas las instancias de flujo de trabajo que se ejecutan en un sitio, lista o biblioteca de documentos de SharePoint. El objeto de instancia que se devuelve contiene información sobre la instancia, como los errores que se hayan producido cuando ejecutó anteriormente, el estado actual y se actualizaron por última vez. Además, proporciona una colección de pares nombre/valor que se han enviado al flujo de trabajo desde el formulario de inicio personalizado.

Para ello, empiece por usar el método GetWorkflowInstanceService para obtener una referencia al servicio de instancia. Tenga en cuenta que el WorkflowInstanceService proporciona varios métodos para obtener la colección de instancias de flujo de trabajo en ejecución:

  • Enumerar. Acepta una asociación de flujo de trabajo (es decir, una suscripción) como un parámetro y a continuación, puede utilizarse para obtener todas las instancias que se han creado en función de la asociación especificada.
  • EnumerateInstancesForSite : Obtiene una lista de todas las instancias de flujo de trabajo que se han iniciado en el sitio de SharePoint que se estableció al crear el objeto de WorkflowServiceManager original.
  • EnumerateInstancesForListItem . Acepta una lista de identificador y el identificador de elemento; Use este método para obtener todas las instancias de flujo de trabajo que se han creado en un elemento de lista específico.

Cada uno de estos métodos también tiene un método *WithOffset() alternativo (por ejemplo, EnumerateWithOffset). Estos métodos alternativos permiten obtener un subconjunto de las instancias de flujo de trabajo en los casos donde sería complicado trabajar con toda la colección. Para obtener un recuento del número de instancias de flujo de trabajo, utilice el método CountInstances , o el método CountInstancesWithStatus .

En el ejemplo de código siguiente se muestra al obtener instancias de flujo de trabajo:

// 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());
}

Iniciar una sesión de flujo de trabajo

Iniciar una nueva instancia de una asociación de flujo de trabajo consiste en Repetir muchos de los pasos que se hayan demostrado en los ejemplos anteriores. Para iniciar un flujo de trabajo en un elemento de una lista o biblioteca de documentos, primero obtenga una referencia a la asociación de flujo de trabajo y el identificador del elemento de la lista. Una colección de pares nombre/valor de la información puede enviarse al flujo de trabajo cuando se inicia. Esto ocurre cuando hay un formulario de inicio personalizado que se usa para recopilar datos del usuario iniciar el flujo de trabajo. A continuación, pase una colección, incluso si es una colección vacía, al iniciar el flujo de trabajo o el flujo de trabajo se producirá un error iniciar y devolver un error.

A partir de ejemplos anteriores, use el método GetWorkflowInstanceService para obtener una instancia del servicio de instancia de flujo de trabajo. A continuación, inicie el flujo de trabajo mediante una llamada a uno de estos dos métodos. Uno inicia los flujos de trabajo en un sitio, mientras que el otro inicia un flujo de trabajo en un elemento de lista.

  • StartWorkflow . Inicia un flujo de trabajo en el sitio de SharePoint que se estableció al crear el objeto WorkflowServicesManager original. Cuando se usa este método, debe pasar en la asociación de flujo de trabajo y las propiedades de inicio adicional está presentes en el formulario de inicio.
  • StartWorkflowOnListItem . Inicia un flujo de trabajo en un elemento de lista específico. Uso de este método requiere pasar el identificador del elemento de lista deseada, además de otros valores de los parámetros requeridos por el método StartWorkflow.

En el ejemplo de código siguiente se muestra cómo iniciar una instancia de flujo de trabajo.

// 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();

Publicar mensajes y eventos en flujos de trabajo en ejecución

Otra característica muy eficaz que se agregó en SharePoint es la capacidad para publicar eventos personalizados en instancias de flujo de trabajo en ejecución. Estos flujos de trabajo pueden tener una actividad, WaitForCustomEvent, que escucha de un evento específico para su publicación en el flujo de trabajo. El evento también puede contener una cadena como parte del mensaje, que puede almacenar la actividad como una variable.

Para publicar un evento desde el cliente mediante el CSOM de servicio de flujo de trabajo, primero obtenga una referencia a la instancia de flujo de trabajo específico que debe publicarse en el evento. A continuación, con el servicio de instancia, publique el evento mediante el método PublishCustomEvent . Cuando se usa este método, debe pasar la instancia deseada, nombre del evento y una carga opcional, tal como se muestra en el siguiente ejemplo de código.

// 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();

Para recibir el mensaje del flujo de trabajo, agregar una actividad de WaitForCustomEvent y, mediante la ventana Propiedades, establezca la propiedad de EventName en el nombre del evento está escuchando la actividad (en el ejemplo anterior, sería la cadena "AdHocMaintenanceRequest"). A continuación, establezca la propiedad Result a la variable en el que se almacena la carga del evento, tal como se muestra en la figura 2.

Figura 2. EventName de entrada y resultado de salida Figura 2. EventName de entrada y resultado de salida

Esta técnica de publicación de un evento personalizado se muestra en el ejemplo de código de MSDN: SharePoint: flujos de trabajo de ruta a estados dependiendo de acciones y eventos.

Conclusión

Microsoft presentó los flujos de trabajo en la plataforma SharePoint 2007 y la plataforma de flujo de trabajo permanecido prácticamente invariable en SharePoint 2010. También era true cuando llegó a formularios personalizados en flujos de trabajo de SharePoint. SharePoint, por otro lado, introdujo muchos cambios en la arquitectura y plataforma de flujo de trabajo.

Una de las principales mejoras en flujos de trabajo en SharePoint es la expansión de CSOM para incluir una API de servicios de flujo de trabajo completa. Esta adición permite a los programadores interactuar con las definiciones de flujo de trabajo, asociaciones y suscripciones, y crear e interactuar con las instancias de estos flujos de trabajo.

Vea también