Plan para crear flujos de trabajo (SharePoint Server 2010)

 

Se aplica a: SharePoint Foundation 2010, SharePoint Server 2010

Última modificación del tema: 2016-11-30

¿Qué es un flujo de trabajo? Consta básicamente de dos elementos: los formularios que el flujo de trabajo usa para interactuar con los usuarios y la lógica que define el comportamiento del flujo de trabajo. Entender cómo se crean los flujos de trabajo requiere tener conocimientos de ambos elementos.

Debido a que establece la comunicación con los usuarios mediante un explorador web, un flujo de trabajo se basa en ASP.NET para mostrar los formularios. Por consiguiente, estos formularios se definen como páginas .aspx. Un flujo de trabajo puede mostrar sus propios formularios en cuatro puntos de su ciclo de vida:

• Asociación: si un administrador asocia una plantilla de flujo de trabajo con una biblioteca de documentos o una lista concretas, es posible que pueda establecer opciones que se aplicarán a todas las instancias de flujo de trabajo creadas a partir de esta asociación. Si el autor del flujo de trabajo decide permitir esto, debe proporcionar un formulario que permita al administrador especificar esta información.

• Inicio: es posible que el iniciador de un flujo de trabajo tenga permiso para especificar opciones al empezar a ejecutar una instancia. Por ejemplo, en el escenario de aprobación descrito, las opciones incluyen la especificación de la lista de participantes en el flujo de trabajo y la definición del tiempo de que dispone cada participante para completar la tarea. Si un flujo de trabajo permite esto, el autor debe proporcionar un formulario para permitir al iniciador que establezca estas opciones.

• Finalización de tareas: la instancia de flujo de trabajo en ejecución debe mostrar un formulario a los participantes en el flujo de trabajo para permitirles completar la tarea. Este formulario permite a los aprobadores del escenario anterior hacer comentarios acerca del documento e indicar su aprobación o rechazo.

• Modificación: el creador de un flujo de trabajo puede permitir su modificación mientras se está ejecutando. Por ejemplo, es posible que un flujo de trabajo permita la adición de nuevos participantes una vez iniciada su ejecución o la ampliación de la fecha de vencimiento para completar las tareas. Si se usa esta opción, el flujo de trabajo debe mostrar un formulario en este punto para permitir que el participante especifique qué cambios se deben realizar.

Los flujos de trabajo generados mediante Microsoft SharePoint Server 2010 pueden usar formularios creados con InfoPath. La lógica de un flujo de trabajo siempre se define como un grupo de actividades, al igual que cualquier flujo de trabajo basado en Windows Workflow Foundation (WF). Para especificar la lógica y los formularios para un flujo de trabajo, Microsoft proporciona dos herramientas distintas, cada una de las cuales se dirige a una audiencia diferente. Los programadores de software pueden usar la característica Diseñador de flujo de trabajo de Windows Workflow Foundation. Esta herramienta se ejecuta en Visual Studio 2010 Professional Edition y proporciona un entorno gráfico para organizar las actividades en los flujos de trabajo. Los trabajadores de la información, un grupo menos técnico, pueden usar Microsoft SharePoint Designer 2010 para crear flujos de trabajo sin escribir código. En las dos secciones siguientes se analiza la creación de flujos de trabajo con cada una de estas herramientas.

Creación de flujos de trabajo con Visual Studio 2010 y el Diseñador de flujo de trabajo de WF

Los flujos de trabajo creados con SharePoint Server pueden usar formularios de flujo de trabajo de Microsoft InfoPath 2010 en lugar de solo los formularios .aspx. Para crear estos formularios, el autor de un flujo de trabajo usa Microsoft InfoPath. Esta herramienta proporciona un editor gráfico que permite al autor definir el contenido del formulario. Los programadores que prefieren trabajar exclusivamente en el entorno de Visual Studio pueden usar Visual Studio 2010 Professional Edition.

Una vez creados, los formularios de flujo de trabajo de InfoPath se adjuntan a un flujo de trabajo mediante un archivo workflow.xml, al igual que los formularios ASP.NET. A diferencia de los formularios ASP.NET, sin embargo, los programadores no necesitan escribir código personalizado para mover la información entre los formularios de flujo de trabajo de InfoPath y un flujo de trabajo. En lugar de ello, SharePoint Server y InfoPath proporcionan este vínculo, lo cual simplifica el proceso en gran medida para las personas que crean flujos de trabajo.

Desde varias perspectivas, un flujo de trabajo es como un diagrama de flujo. Por lo tanto, es razonable proporcionar una herramienta gráfica que permita a los programadores especificar las acciones de un flujo de trabajo. Esta herramienta es la herramienta de flujo de trabajo de SharePoint en Visual Studio 2010 Professional, que es un tipo de proyecto que usa el Diseñador de flujo de trabajo de Windows Workflow Foundation (WF) y agrega compatibilidad de implementación y formularios para flujos de trabajo. Los programadores pueden usar el Diseñador de flujo de trabajo de WF para definir gráficamente las actividades de un flujo de trabajo y el orden en que se deben ejecutar dichas actividades. A continuación, la pantalla muestra un ejemplo simple de cómo se ve esto en Microsoft Visual Studio.

Flujo de trabajo de recopilar comentarios

Las actividades disponibles para su uso se muestran en el cuadro de herramientas de la parte izquierda de la pantalla. El programador puede arrastrar estas actividades a la superficie de diseño para definir los pasos de un flujo de trabajo. Las propiedades de cada actividad se pueden establecer en la ventana de propiedades que aparece en la esquina inferior derecha.

La biblioteca de actividades base de Windows Workflow Foundation proporciona un grupo de actividades fundamentales, como se ha descrito anteriormente. SharePoint Server proporciona además un conjunto de actividades diseñadas expresamente para crear flujos de trabajo. Algunas de las más importantes son las siguientes:

• OnWorkflowActivated: proporciona un punto de inicio estándar para un flujo de trabajo. Entre otras cosas, esta actividad puede aceptar la información suministrada por un administrador de SharePoint a través del formulario de asociación cuando el flujo de trabajo se asocia a una biblioteca de documentos, una lista, un tipo de contenido o un sitio. Además, puede aceptar la información suministrada a través del formulario de inicio cuando se inicia el flujo de trabajo. Todos los flujos de trabajo deben empezar por esta actividad.

• CreateTask: crea una tarea asignada a un usuario concreto de una lista de tareas. Por ejemplo, el flujo de trabajo de aprobación del escenario descrito anteriormente usaba esta actividad para agregar una tarea a la lista de tareas usada por cada participante. Esta actividad tiene además la propiedad SendEmailNotification que, si se establece en verdadero, envía automáticamente un mensaje de correo electrónico a la persona para la que se creó la tarea.

• OnTaskChanged: acepta información del formulario de finalización de tareas. El flujo de trabajo de aprobación del escenario anterior usaba esta actividad para aceptar la entrada de cada participante al aprobar el documento.

• CompleteTask: marca una tarea como completada.

• DeleteTask: quita una tarea de una lista de tareas.

• OnWorkflowModified: acepta información del formulario de modificación, que se puede usar a continuación para cambiar el modo en que se comporta esta instancia del flujo de trabajo. Si el creador del flujo de trabajo opta por no incluir ninguna instancia de esta actividad en el flujo de trabajo, dicho flujo de trabajo no se puede modificar mientras se esté ejecutando.

• SendEmail: envía un mensaje de correo electrónico a la persona o el grupo de personas especificados.

• LogToHistoryList: escribe información acerca de la ejecución del flujo de trabajo en una lista de historial. La información de esta lista se usa para permitir a los usuarios ver dónde se está ejecutando un flujo de trabajo, consultar el historial de trabajo una vez completado, etc. Para permitir este tipo de supervisión, el autor del flujo de trabajo debe escribir la información en una lista de historial en los puntos correspondientes de la ejecución del flujo de trabajo. Dado que proporciona su propio mecanismo de seguimiento de flujos de trabajo, SharePoint Server no es compatible con el servicio de seguimiento estándar de WF.

Un modelo típico para un flujo de trabajo sencillo empieza por la actividad OnWorkflowActivated y, a continuación, usa la actividad CreateTask para asignar una tarea a un participante del flujo de trabajo. Es posible que se use la actividad While estándar de la biblioteca de actividades base para esperar hasta que el usuario complete la tarea. Para saber cuándo ocurre esto (quizá el usuario realice varios cambios en la tarea y, a continuación, active una casilla del formulario de finalización de tareas al terminar), se ejecuta la actividad OnTaskChanged en la actividad While para extraer la información que el usuario haya especificado en el formulario. Cuando el usuario complete la tarea, es posible que se ejecute la actividad CompleteTask, seguida de la actividad DeleteTask. A continuación, el flujo de trabajo puede continuar con el siguiente participante mediante la actividad CreateTask para asignarle una tarea, y así sucesivamente. Obviamente, se pueden realizar más actividades, como el envío de correo electrónico, el registro de información en la lista de historial o incluso la actividad Code de la biblioteca de actividades base, que permite ejecutar código arbitrario.

Todas las actividades proporcionadas por SharePoint Server tienen como objetivo permitir que los flujos de trabajo funcionen en el entorno de SharePoint. La lógica empresarial que implementa un flujo de trabajo la decide en su totalidad el creador del flujo de trabajo. De hecho, el programador que cree un flujo de trabajo puede crear y usar sus propias actividades personalizadas y no tiene por qué usar únicamente las que proporcionan SharePoint Server y WF.

Como se ha descrito anteriormente, Windows Workflow Foundation es compatible con los flujos de trabajo secuenciales y de equipo de estado. Un flujo de trabajo creado con el Diseñador de flujo de trabajo de WF también puede usar cualquiera de estas opciones. Para ello, SharePoint Server agrega tipos de proyecto a Visual Studio, uno para cada uno de estos estilos de flujo de trabajo.

Con independencia del estilo elegido, el programador debe definir algo más que la lógica del flujo de trabajo; debe especificar también los formularios .aspx o InfoPath que debe usar el flujo de trabajo. Para ello, el programador se basa en un archivo llamado element.xml. Este archivo proporciona una plantilla que el programador rellena para especificar qué formulario, si lo hay, se debe mostrar en cada uno de los cuatro puntos en que el flujo de trabajo tiene permiso para esto.

Un programador debe realizar determinadas tareas para pasar información entre un flujo de trabajo y los formularios .aspx que usa. El espacio de nombres Microsoft.Windows.SharePoint.Workflow expone un modelo de objetos para programadores. Si se usan los tipos en este espacio de nombres, el creador de un flujo de trabajo puede pasar información de un formulario .aspx al flujo de trabajo y viceversa.

Una vez que se han creado el flujo de trabajo y sus formularios, el programador debe empaquetarlos en lo que se denomina una característica. A continuación, el administrador de SharePoint Services debe instalar esta característica, que incluye la instalación de los ensamblados del flujo de trabajo en la memoria caché global de ensamblados del sistema de destino. El flujo de trabajo nuevo estará visible para el administrador como una plantilla de flujo de trabajo que se puede asociar a una biblioteca de documentos, lista, tipo de contenido o sitio.

Para el programador de software, la creación de un flujo de trabajo con Visual Studio y el Diseñador de flujo de trabajo de WF no resulta especialmente difícil. El programador debe entender los aspectos específicos del trabajo en este entorno, pero gran parte de estas tareas le resultarán familiares. No obstante, los programadores de software no son los únicos que desean crear flujos de trabajo. Como se describe a continuación, los usuarios que no son programadores profesionales también pueden crear flujos de trabajo con Microsoft SharePoint Designer 2010.

Creación de flujos de trabajo con Microsoft SharePoint Designer 2010

Microsoft SharePoint Designer 2010 es una aplicación independiente que puede descargarse gratuitamente. Microsoft SharePoint Designer permite que los trabajadores de la información y otros usuarios agreguen la lógica de aplicación (implementada como un flujo de trabajo) a sitios de SharePoint. Esto es sin duda un objetivo útil, pero Microsoft SharePoint Designer debe solucionar además otro problema importante. Si un programador crea un flujo de trabajo con Visual Studio, dicho flujo de trabajo se debe implementar en un servidor que ejecute SharePoint Server como cualquier otra característica. Sin embargo, muchos administradores de SharePoint no permiten que se implemente código arbitrario en sus servidores, ya que consideran que el riesgo de desestabilización del sistema es considerable. No obstante, poder crear una lógica empresarial directa asociada a los documentos y los elementos de lista resulta muy útil y es algo necesario para muchos usuarios de SharePoint. Además de permitir a los usuarios con menos conocimientos técnicos crear flujos de trabajo, Microsoft SharePoint Designer también soluciona este problema al proporcionar un método más seguro para definir e implementar la lógica empresarial en los servidores que ejecutan SharePoint Server.

Los escenarios de flujo de trabajo de que se ocupa Microsoft SharePoint Designer son distintos en varios aspectos de los escenarios de flujo de trabajo de Visual Studio y del Diseñador de flujo de trabajo de WF. Aunque se pueden crear aplicaciones complejas, el objetivo de Microsoft SharePoint Designer es permitir a los usuarios agregar la lógica empresarial a los sitios de SharePoint. Por ejemplo, supongamos que un sitio contiene una lista que permite a los usuarios enviar solicitudes de cambio. Microsoft SharePoint Designer se puede usar para crear un flujo de trabajo que informe automáticamente al remitente de cuándo se acepta o rechaza su solicitud de cambio. De forma similar, un flujo de trabajo personalizado puede informar a un grupo de usuarios concreto siempre que se agregue un documento nuevo a una biblioteca de documentos específica. Este tipo de notificación personalizada no es complicada (la creación de los flujos de trabajo es sencilla), pero sí resulta compleja en el caso de versiones anteriores de SharePoint Server debido a que los administradores son reacios a instalar código escrito por el usuario.

En este punto se plantea una cuestión obvia: ¿por qué la lógica creada con Microsoft SharePoint Designer se debe tratar de un modo distinto? ¿Qué puede convencer a los administradores de SharePoint para que permitan la implementación de los flujos de trabajo creados con esta herramienta en los sistemas de los que son responsables? La respuesta es que los flujos de trabajo creados con Microsoft SharePoint Designer sólo pueden usar actividades de una lista controlada por el administrador. Además de las actividades que proporciona SharePoint Server, el administrador de un sitio puede optar por incluir actividades personalizadas creadas por un programador en esta lista. Al definir exactamente lo que los flujos de trabajo pueden hacer, el administrador de SharePoint puede tener más confianza en que la implementación de la lógica creada con Microsoft SharePoint Designer no desestabilice el sistema.

Dado que está dirigido a trabajadores de la información en lugar de programadores, y dado que se centra en escenarios más sencillos, Microsoft SharePoint Designer usa un modelo para la creación de flujos de trabajo distinto al del Diseñador de flujo de trabajo de WF hospedado en Visual Studio. En lugar de un enfoque gráfico, Microsoft SharePoint Designer usa un enfoque basado en reglas. Es similar en cierto modo al Asistente para reglas de Microsoft Outlook, una herramienta conocida por muchos usuarios. En la siguiente pantalla se muestra cómo un usuario de Microsoft SharePoint Designer define un paso de un flujo de trabajo. Observe que este flujo de trabajo ejecuta algunas acciones en paralelo, mientras que otras acciones se ejecutan en serie. Las versiones anteriores de SharePoint Server sólo eran compatibles con la ejecución en serie de acciones; las acciones se ejecutaban únicamente de manera consecutiva.

Flujo de trabajo para ordenar procesos

Cada paso puede incluir una condición y una acción. La condición determina si la acción de este paso se debe ejecutar, como se muestra en la instrucción If anterior. Las selecciones de las acciones incluyen tareas, como la asignación de un animador a un evento, la recopilación de aprobación y muchas otras más. Cada una de estas acciones se realiza mediante alguna actividad de SharePoint Server y las actividades usadas aquí son las mismas que se usan con Visual Studio y el Diseñador de flujo de trabajo de WF. La lista de acciones también puede incluir cualquier otra actividad permitida por el administrador de SharePoint para este sitio, incluidas las actividades personalizadas creadas por los programadores. En SharePoint Server, también existe un conjunto de actividades disponibles que permite a los usuarios personalizar la aprobación común o el paradigma de recopilar comentarios de “crear un conjunto de tareas y esperar que se completen” en un diseñador especial en Microsoft SharePoint Designer.

Incluso aunque la interfaz de usuario tenga un aspecto muy distinto del enfoque gráfico usado con Visual Studio y el Diseñador de flujo de trabajo de WF, Microsoft SharePoint Designer crea un flujo de trabajo de WF estándar. El resultado real es un flujo de trabajo secuencial, paralelo o una combinación de ambos, con condiciones expresadas mediante el motor de reglas de WF. No obstante, los flujos de trabajo creados con esta herramienta tienen algunas limitaciones. Por ejemplo, no se pueden modificar mientras se están ejecutando, a diferencia de los que se crean con Visual Studio y el Diseñador de flujo de trabajo de WF, y solo se pueden crear flujos de trabajo secuenciales y paralelos, ya que los de equipo de estado no son compatibles. Además, para la creación de flujos de trabajo con esta herramienta se deben tener en cuenta una biblioteca de documentos, una lista o un sitio específicos durante el diseño. Los creadores de flujos de trabajo también pueden crear una plantilla de flujo de trabajo general que puede asociarse posteriormente a cualquier biblioteca, lista o tipo de contenido. Aunque esto limita el modo de uso del flujo de trabajo, facilita su implementación. De hecho, cuando un usuario finaliza la creación de un flujo de trabajo con Microsoft SharePoint Designer, la herramienta proporciona una implementación del flujo de trabajo en el sitio de destino con un solo clic, incluida la activación del flujo de trabajo. Este proceso resulta mucho menos complejo que el proceso de implementación en varios pasos requerido para los flujos de trabajo creados con Visual Studio y el Diseñador de flujo de trabajo de WF.

Los flujos de trabajo creados con Microsoft SharePoint Designer también pueden mostrar formularios personalizados. Sin embargo, en lugar de requerir que los autores de los flujos de trabajo creen las páginas .aspx directamente, la herramienta genera estas páginas. El autor especifica información detallada acerca del aspecto que deben tener las páginas generadas, como los campos que deben contener, y Microsoft SharePoint Designer se ocupa del resto. No obstante, de los cuatros puntos del ciclo de vida de un flujo de trabajo en que se pueden usar formularios, solo se usan dos con los flujos de trabajo creados con Microsoft SharePoint Designer: inicio y finalización de tareas. Dado que todos los flujos de trabajo creados con esta herramienta se deben asociar a una biblioteca de documentos, lista, tipo de contenido o sitio concreto, no es necesario el paso de asociación y, por lo tanto, tampoco es necesario ningún formulario de asociación. Además, debido a que estos flujos de trabajo no se pueden modificar mientras se están ejecutando, no es necesario ningún formulario de modificación.

Microsoft SharePoint Designer también permite importar flujos de trabajo creados con Microsoft Visio 2010. Esto permite a los administradores de empresas y a los autores de flujos de trabajo crear la lógica de flujo de trabajo usando un entorno gráfico conocido. A continuación, el autor de un flujo de trabajo puede importar la lógica del flujo de trabajo en Microsoft SharePoint Designer, modificarla si es necesario y, después, publicarla en un sitio de SharePoint.

SharePoint Server proporciona un nivel de funcionalidad considerable para crear flujos de trabajo orientados a los documentos. No obstante, en última instancia, se trata de una plataforma para el desarrollo y la ejecución. No proporciona ninguna funcionalidad de flujo de trabajo que puedan usar directamente los usuarios finales. Los flujos de trabajo que se ejecutan en SharePoint Server presentan además otras restricciones, como la imposibilidad de interactuar con los participantes mediante aplicaciones cliente de Office.

Comparación de herramientas de creación

En la siguiente tabla se muestran las diferencias importantes entre las herramientas admitidas por Microsoft para crear flujos de trabajo en SharePoint Server utilizando tanto SharePoint Designer como el Diseñador de flujo de trabajo de WF en Visual Studio 2010 Professional Edition.

Capacidad y requisito	SharePoint Designer	Diseñador de flujo de trabajo de WF en Visual Studio
¿Los flujos de trabajo pueden crearse únicamente mediante acciones aprobadas por los administradores de sitios?	Sí	No
¿Los flujos de trabajo son accesibles en aplicaciones cliente (distintas del explorador)?	Sí	Sí
¿Se puede usar Microsoft Visio Professional para crear una lógica de flujo de trabajo?	Sí	No
¿Se necesita escribir código?	No	Sí
¿Se proporcionan actividades adicionales (aparte de las que proporciona SharePoint Server)?	No	Sí
¿Se pueden crear actividades personalizadas?	No	Sí
¿Se pueden usar los formularios de InfoPath en este flujo de trabajo?	Sí	Sí
¿Se puede modificar el flujo de trabajo mientras se está ejecutando?	No	Sí
¿Publicación de flujos de trabajo con un solo clic?	Sí	Sí
¿Es posible implementar flujos de trabajo de forma remota?	Sí	No
¿Pueden estar disponibles a través de la granja de servidores?	No	Sí
¿Pueden estar en el ámbito de una colección de sitios?	Sí	Sí