Creación de flujos de trabajo de Windows SharePoint Services

¿Qué es un flujo de trabajo de Windows SharePoint Services? 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 de Windows SharePoint Services requiere tener conocimientos de ambos elementos.

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

• Asociación: si un administrador de Windows SharePoint Services 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, como se muestra en el paso 3 del diagrama anterior.

• 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, mostrado en el paso 6 del diagrama anterior, permite a los aprobadores del escenario anterior hacer comentarios acerca del documento e indicar su aprobación o rechazo.

• Modificación: aunque no se muestra en el escenario anterior, 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 basados únicamente en Windows SharePoint Services definen sus formularios como páginas .aspx, aunque los usuarios que usen Office SharePoint Server también pueden usar formularios creados con InfoPath, como se describe más adelante. En ambos casos, la lógica de un flujo de trabajo siempre se define como un grupo de actividades, como en cualquier flujo de trabajo basado en 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 WF Workflow Designer, hospedado en Visual Studio 2005. Los trabajadores de la información, un grupo menos técnico, pueden usar Office SharePoint Designer para crear flujos de trabajo sin escribir código. En las dos secciones siguientes, se analiza cómo se pueden crear flujos de trabajo de Windows SharePoint Services con cada una de estas herramientas.

Creación de flujos de trabajo con Visual Studio 2005 y WF Workflow Designer

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. En el caso de WF, esta herramienta es Workflow Designer, una parte de las extensiones de Windows Workflow Foundation para Visual Studio 2005. Los programadores pueden usar WF Workflow Designer para definir gráficamente las actividades de un flujo de trabajo y el orden en que se deben ejecutar dichas actividades. En la siguiente pantalla se muestra un ejemplo sencillo de esto.

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 WF proporciona un grupo de actividades fundamentales, como se ha descrito anteriormente. Windows SharePoint Services proporciona además un conjunto de actividades diseñadas expresamente para crear flujos de trabajo de Windows SharePoint Services. Algunas de las más importantes son las siguientes:

• OnWorkflowActivated: proporciona un punto de inicio estándar para un flujo de trabajo de Windows SharePoint Services. Entre otras cosas, esta actividad puede aceptar la información suministrada por un administrador de Windows SharePoint Services a través del formulario de asociación cuando el flujo de trabajo se asocia a una biblioteca de documentos o una lista. 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 de Windows SharePoint Services 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 las propiedad SendEmailNotification que, si se establece en true, 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 un historial. La información de este historial se usa para permitir a los usuarios ver dónde se está ejecutando un flujo de trabajo, consultar el historial del flujo 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 un 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, Windows SharePoint Services no es compatible con el servicio de seguimiento estándar de WF.

Un modelo típico para un flujo de trabajo sencillo de Windows SharePoint Services 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 realiza varios cambios en la tarea y, a continuación, activa 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 el historial o incluso la actividad Code de la biblioteca de actividades base, que permite ejecutar código arbitrario.

Todas las actividades proporcionadas por Windows SharePoint Services tienen como objetivo permitir que los flujos de trabajo funcionen en el entorno de Windows SharePoint Services. 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 de Windows SharePoint Services puede crear y usar sus propias actividades personalizadas y no tiene por qué usar únicamente las que proporcionan Windows SharePoint Services 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 de Windows SharePoint Services creado con WF Workflow Designer también puede usar ambas opciones. Para ello, Windows SharePoint Services agrega dos tipos de proyecto a Visual Studio 2005, 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 que debe usar el flujo de trabajo. Para ello, el programador se basa en un archivo llamado workflow.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 de Windows SharePoint Services tiene permiso para esto.

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

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

Para el programador de software, la creación de un flujo de trabajo de Windows SharePoint Services con Visual Studio y WF Workflow Designer 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 de Windows SharePoint Services. Como se describe a continuación, los usuarios que no son programadores profesionales también pueden crear flujos de trabajo con Office SharePoint Designer.

Creación de flujos de trabajo con Office SharePoint Designer 2007

Office SharePoint Designer 2007, un componente con licencia independiente de 2007 Office system, 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 los sitios de Windows SharePoint Services. Esto es sin duda un objetivo útil, pero Office SharePoint Designer debe solucionar además otro problema importante. Si un programador crea un flujo de trabajo de Windows SharePoint Services con Visual Studio, dicho flujo de trabajo se debe instalar en un servidor de Windows SharePoint Services como cualquier otra aplicación. Sin embargo, muchos administradores de Windows SharePoint Services 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 Windows SharePoint Services. Además de permitir a los usuarios con menos conocimientos técnicos crear flujos de trabajo, Office 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 de Windows SharePoint Services.

Los escenarios de flujo de trabajo de que se ocupa Office SharePoint Designer son distintos en varios aspectos de los escenarios de flujo de trabajo de Visual Studio y WF Workflow Designer. Aunque se pueden crear aplicaciones complejas, el objetivo de Office SharePoint Designer es permitir a los usuarios agregar la lógica empresarial a los sitios de Windows SharePoint Services. Por ejemplo, supongamos que un sitio contiene una lista que permite a sus usuarios enviar solicitudes de cambio. Office 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 Windows SharePoint Services 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 Office SharePoint Designer se debe tratar de un modo distinto? ¿Qué puede convencer a los administradores de Windows SharePoint Services para que permitan la implementación de los flujos de trabajo creados con esta herramienta en los sistemas de que son responsables? La respuesta es que los flujos de trabajo creados con Office SharePoint Designer sólo pueden usar actividades de una lista controlada por el administrador. Aunque un administrador de un sitio puede optar por incluir actividades personalizadas creadas por un programador en esta lista, no tiene por qué hacerlo. Al definir exactamente lo que los flujos de trabajo pueden hacer, el administrador de Windows SharePoint Services puede tener más confianza en que la implementación de la lógica creada con Office SharePoint Designer no desestabilice el sistema.

Debido a que se destina a los trabajadores de la información en lugar de a los programadores y a que se centra en escenarios más sencillos, Office SharePoint Designer usa un modelo para la creación de flujos de trabajo distinto al de WF Workflow Designer hospedado en Visual Studio. En lugar de un enfoque gráfico, Office SharePoint Designer usa un enfoque basado en reglas. Esto es similar en cierto modo al Asistente para reglas de Outlook, una herramienta conocida para muchos usuarios. En la siguiente pantalla se muestra cómo un usuario de Office SharePoint Designer define un paso de un flujo de trabajo.

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 las instrucciones condicionales anteriores. Las selecciones de las acciones incluyen tareas como la asignación de un elemento de tarea a un participante del flujo de trabajo, el envío de correo electrónico, etc. Cada una de estas acciones se realiza mediante alguna actividad de Windows SharePoint Services y las actividades usadas aquí son las mismas que se usan con Visual Studio y WF Workflow Designer. Por ejemplo, la opción Enviar correo electrónico mostrada anteriormente se corresponde con la actividad SendEmail, mientras que Asignar un elemento de tarea se corresponde con una versión especializada en cierta medida de la actividad CreateTask. La lista de acciones también puede incluir cualquier otra actividad permitida por el administrador de Windows SharePoint Services para este sitio, incluidas las actividades personalizadas creadas por los programadores.

Incluso aunque la interfaz de usuario tenga un aspecto muy distinto del enfoque gráfico usado con Visual Studio y WF Workflow Designer, Office SharePoint Designer crea un flujo de trabajo de WF estándar. El resultado real es un flujo de trabajo secuencial 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 WF Workflow Designer, y sólo se pueden crear flujos de trabajo secuenciales, 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 o una lista específicas durante el diseño. No se puede crear una plantilla de flujo de trabajo general para asociarla posteriormente a una biblioteca, lista o tipo de contenido. Aunque esto limita el modo de uso del flujo de trabajo, facilita su implementación. De hecho, cuando el usuario termina de crear un flujo de trabajo con Office SharePoint Designer, la herramienta implementa automáticamente el flujo de trabajo en el sitio de destino. 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 WF Workflow Designer.

Los flujos de trabajo creados con Office 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 Office SharePoint Designer se ocupa del resto. No obstante, de los cuatros puntos del ciclo de vida de un flujo de trabajo de Windows SharePoint Services en que se pueden usar formularios, sólo se usan dos con los flujos de trabajo creados con Office 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 o lista concretas, 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.

Office SharePoint Designer se puede usar para tareas distintas de la creación de flujos de trabajo de Windows SharePoint Services. Por ejemplo, la herramienta se puede usar para crear un sitio de Windows SharePoint Services o para personalizar el aspecto de las páginas de un sitio mediante la edición de la página maestra del sitio. Además, se puede usar para establecer la conexión con los datos externos, lo cual se basa en la compatibilidad con el enlace de datos de ASP.NET. Sin embargo, en el caso de los trabajadores de la información que necesiten crear una lógica que se ejecute en un sitio de Windows SharePoint Services, el aspecto más importante de Office SharePoint Designer es sin duda la compatibilidad con la creación de flujos de trabajo.

Windows SharePoint Services 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. Si se necesitan aplicaciones de flujo de trabajo listas para usar, lo que ocurre con frecuencia, Windows SharePoint Services no es suficiente. Los flujos de trabajo creados únicamente con Windows SharePoint Services presentan además otras restricciones, como la imposibilidad de interactuar con los participantes mediante las aplicaciones cliente de Office. Como se describe a continuación, Office SharePoint Server ofrece un método para solucionar todas estas limitaciones.

Descarga de este libro

En este tema se incluye el siguiente libro descargable para facilitar la lectura y la impresión:

• Planeación de sitios y características (primera parte)

Vea la lista completa de libros disponibles en la página que muestra el contenido descargable para Office SharePoint Server 2007.