jueves, 5 de junio de 2014

Reusable Workflows

Cuando hablamos de workflows en SharePoint, solemos estar habituados a visualizarlos como un proceso directamente vinculado a una lista o biblioteca en concreto. Es cierto los workflows de lista son los más utilizados, sin embargo existen workflows de otro tipo, como los reutilizables o los de site que pueden ahorrarnos mucho trabajo en determinadas ocasiones. Hoy quisiera centrarme en los workfows reutilizables (reusable workflows) y mostrar un ejemplo en concreto de sus capacidades y cómo pueden ayudarnos a generar un ecosistema más natural de flujos de trabajo en nuestro entorno.

Para ello vamos a suponer el siguiente escenario: Tenemos un conjunto de procedimientos corporativos (solicitud de vacaciones, solicitudes de compra, solicitudes de certificación, etc.) para los cuales necesitamos un workflow de validación. El proceso en sí es el mismo en todos los casos, exceptuando a los validadores, que son distintos en cada caso.

De forma natural nos vendría a la cabeza implantar un flujo de trabajo para cada proceso distinto, pero existe una opción óptima que es crear un único flujo de trabajo que podremos mantener de forma centralizada, y que podremos, una vez definido, reutilizar n veces para nuestros n procesos de forma muy sencilla (cualquier administrador de una lista/biblioteca de SharePoint podrá hacerlo sin entrar ni siquiera en SharePoint Designer).

Vamos a crear ese flujo reutilizable (de la forma más sencilla posible). Inicialmente vamos a tener que crear el flujo en SharePoint Designer, así que lo ejecutamos y abrimos el site que alberga nuestros listados y formularios de procedimientos. Nos vamos a la sección de Workflows en el menú de navegación y pulsamos en “Reusable Workflows”.

image
Le ponemos un nombre a nuestro flujo reutilizable, una descripción (opcional), lo aplicamos a todos los tipos de contenido y elegimos si lo queremos en formato 2010 o 2013. Recordad que no todos nuestros flujos en 2013 tienen por qué ser en 2010. En este caso quiero utilizar una de las funciones que solo existen en la versión 2010, así que selecciono “SharePoint 2010 workflow”.
image
Una vez se crea la instancia del Workflow y accedemos al diseñador del flujo, lo primero será definir los parámetros de inicialización. Estos parámetros son los que el usuario podrá configurar al crear un nuevo workflow basado en esta instancia, o indicarlos en el caso de que el flujo se lance de forma manual, así que hay que darle importancia a este paso, pues conformará la base de la diferenciación entre uno y otro flujo, aunque partan de la misma definición.

image
En mi caso, defino 2 parámetros configurables. Uno de ellos es “Validators”, que indica qué personas o grupos serán los validadores del flujo (podrá cambiar según el procedimiento a validar), y otro será el nombre del procedimiento en concreto (que usaré como literal en el envío de e-mails para notificar que hay tareas o validaciones realizadas sobre ese mismo proceso). En el parametro “Collect from parameter during:” se puede escoger Initiation (el usuario lo especifica manualmente al lanzar el flujo si el flujo se lanza de forma manual), Association (se especifica en el momento de crear el flujo, en la administración de la lista) o Both (se especifica en ambos casos anteriores). En mi caso escojo “Association”, ya que los flujos se lanzarán automáticamente cuando se genere una nueva solicitud de cualquier procedimiento y no quiero marear al usuario con más preguntas de las necesarias.
image
Una vez definidos los parámetros de inicialización, ya podremos empezar a desarrollar el flujo. Podemos añadir acciones para pasar el valor de los parámetros a variables locales del flujo (aunque es redundante), o escribir en el log history del workflow, pero la acción imprescindible sería enviar un correo electrónico al grupo de validadores (que nos ha entrado por parámetro de inicialización del workflow). El correo a enviar sería algo similar a la siguiente imagen:
image
Observad que utilizo en diversas ocasiones el parámetro recogido en la inicialización del flujo de “Name of request”, de forma que si estás aplicando el workflow a una solicitud de vacaciones, el validador verá un correo con el título “New Holiday Request –…” y si es una solicitud de viaje “New Travel Request – …”.
Para simplificar este flujo de ejemplo, toda la acción de aprovar o rechazar la delego en el campo “Approval Status” que se activa automáticamente en las listas cuando en la pantalla de configuración del versionado indicamos que requiere autorización. De esta forma, el validador solo tendrá que ir a la lista, pulsar en el botón de “Approve/Reject” y indicar si se aprueba o no la solicitud para cambiar el estado de la columna “Approval Status”
image
Delegada la lógica de validación al Approval Status de la lista, solo queda añadir una acción de tipo Wait for field change in current item (en la sección de “List Actions”), donde especificaremos que la columna “Approval Status” no sea igual (to not equal) a “Pending”. El “to no equal” es algo que no tienen los flujos de trabajo en versión 2013, y lo que me ha forzado a hacer este ejemplo en versión 2010.
La primera parte del workflow quedaría similar a la siguiente imagen.
image
Ahora desarrollaremos la segunda parte del workflow en la que trataremos los casos de Validación o Rechazo por parte de los validadores. Para simplificar el ejemplo, lo que he hecho aquí es crear una variable de tipo “string” (ApprovalStatus) y simplemente añado la condición de que si el campo de la lista “Approval Status” es igual a “Approved” inicialice la variable con el valor “approved” y si no con el valor “rejected”.
Posteriormente podemos escribir en blog history para dar constancia del resultado de la validación, pero la tarea importante volverá a ser el envio del correspondiente email al usuario solicitante. En la configuración de dicho e-mail utilizaremos la variable “Approval Status” para indicarle al usuario si su solicitud ha sido aprobada o rechazada.
image
De este modo, la segunda parte del workflow nos quedaría mas o menos como especifica la siguiente imagen.
image
Finalmente, podríamos querer cambiar los permisos de la solicitud al final del flujo, para que esta no pudiera modificarse más y quedara exclusivamente en estado de lectura (es un requerimiento habitual en este tipo de peticiones). Esto exigiría añadir un impersonation step con una acción de “Replace List Items Permissions” (en la sección “List Actions”). De nuevo, esto solo se puede hacer en flujos de tipo SharePoint 2010, así que si escogisteis versión 2013, no podríais hacerlo.
image
Ya hemos finalizado nuestro flujo. Solo queda publicarlo. En este momento, debería tener un aspecto similar al de la siguiente imagen.
image
Una vez publicado ya podemos salir de SharePoint Designer.
(Esta es la parte que más me gusta) Ahora iremos a cualquiera de las listas que contienen los formularios de cada procedimiento posible (gastos mensuales, solicitud de viajes, solicitud de vacaciones…). Da igual cual escojamos. Una vez en ella, iremos a la Ribbon, sección de Settings, y desplegaremos “Workflow Settings” para seleccionar la opción de “Add a Workflow”.
image

Veremos que al listado de Workflows habituales de SharePoint (validación, recopilación de firmas, tres estados…) se ha añadido el Workflow reutilizable que hemos generado en SharePoint Designer. Así que lo seleccionamos y configuramos el resto de parámetros genéricos a nuestro gusto.

image
Al pulsar el botón de “next”, la siguiente pantalla nos mostrará los parámetros de inicialización que habíamos definido en nuestro Workflow, y que son los que nos permitirán dotar de entidad propia a cada uno de los Workflows que generemos en base a la plantilla genérica definida. En este caso seleccionaremos el grupo de validadores y el nombre de este procedimiento en concreto.

image

Pulsamos en “Save” y… ¡¡Listo!! ya tenemos el formulario activo y personalizado para esta lista. Ahora podríamos ir al resto de n listas y crear un workflow similar para cada una de ellas. Una única definición del flujo, pero “infinitas” aplicaciones del mismo. Además, si modificamos el flujo reutilizable en Designer, este se actualizará automáticamente en todas las listas/bibliotecas donde esté aplicando. Fantástico, ¿No?.

Más allá del sencillo ejemplo que hemos construido, lo que quiero remarcar con este post son las ventajas que tiene el uso de un workflow reutilizable:
  • Definición y mantenimiento único. Podemos tener aplicados n workflows, pero modificando la definición base, se aplicará directamente a los n workflows disponibles.
  • Se pueden crear nuevos workflows basados en el reutilizable directamente desde la administración de listas/bibliotecas. Los parámetros que hayamos definido también se podrán configurar desde esta UI.
  • Las acciones disponibles para la construcción del Workflow son idénticas a los workflows de lista.
  • Permite asociar columnas propias del workflow, de forma que cada vez que asociemos este a una lista, la lista creará automáticamente dicha columna (fuerza la existencia de la columna en la lista).
Como único inconveniente a tener en cuenta, porque es importante, es que perdemos el ámbito de una lista específica. Esto implica que no podremos referenciar a una columna particular de una lista dentro del “current item”, y tendríamos que trabajar únicamente con parámetros iniciales configurables o con columnas genéricas como “Title”, “Created”, “Created By”… Esto puede ser crucial para algunos flujos, pero no importar tanto para otros. Así que, como siempre, debemos analizar y escoger el tipo de workflow a crear antes de ponernos manos a la obra.

Eso es todo por hoy, confío en que a partir de ahora, antes de construir un Workflow en vuestro SharePoint consideréis previamente si, quizás, sea mejor hacerlo reutilizable.

¡¡Saludos!!

No hay comentarios: