Algunas veces, cuando estamos diseñando un Workflow en SharePoint Designer, nos encontramos que hay ciertas condiciones o acciones que no son exactamente las que deseamos, aunque se parecen mucho.
Un ejemplo. Supongamos que estamos diseñando un Workflow donde en uno de los pasos debemos hacer una comprobación del tipo: “si el estado de aprobación del elemento de la lista es Pendiente, entonces….”. Esto puede parecer muy sencillo, pero desafortunadamente no lo es tanto.
Vamos a ver paso a paso cuál sería el proceso, con sus problemas y soluciones.
Partiremos de que tenemos creada una lista llamada “Pruebas”, cuyos elementos deben ser aprobados o rechazados por unos determinados usuarios. Lo que queremos hacer es que cuando ese estado de aprobación se modifique en el elemento, se ejecuten una serie de acciones. En nuestro caso por simplicidad, simplemente pretenderemos enviar un correo electrónico cuando el elemento se encuentre pendiente de aprobación o rechazo.
Para ello, vamos a crear un Workflow en SharePoint Designer 2007 asociado a nuestra lista, que se lance cada vez que se cree o modifique alguno de sus elementos:
Definiremos un paso del tipo: “Si el estado del elemento es En Espera, enviar correo electrónico”. En principio es muy sencillo:
En el correo electrónico enviaremos la siguiente información:
En principio debería ser así de sencillo, no? Pero vamos a comprobar que el funcionamiento es el correcto.
Creamos un nuevo elemento en la lista, y vemos lo que pasa:
Ooooh. El elemento se ha creado correctamente ¡pero el correo no se ha enviado! ¿Qué ha ocurrido?
Vamos a quitarle al paso del Workflow la condición que le hemos puesto, de forma que el envío de correo se ejecute siempre. Si creamos un nuevo elemento llamado “Elemento 2” veremos que el correo que se envía contendrá este texto:
“El elemento Elemento 2 está en este estado: 2;#Pendiente”
¡Vaya! El estado del elemento no es “En espera” como nos da a elegir SPD, sino “Pendiente”. En realidad lo relevante en este caso no es el texto, sino el número identificador del estado (el 2).
Por tanto, en lugar de la condición que habíamos declarado al principio, necesitaremos una del tipo: “Si el estado del elemento empieza por 2, entonces…”
Pero claro, si intentamos hacerlo desde el diseñador del SPD, nos encontramos que lo único que nos permite es algo como:
Con lo cual lo que necesitamos es cambiar el “2;#En espera” por simplemente “2;”. Para ello lo primero que haremos es guardar el workflow con la condición que SPD nos deja elegir.
Después, tendremos que editar el xml que SPD genera automáticamente, que define las condiciones y acciones de nuestro workflow, en este caso “Comprobar cambio de estado.xoml.rules”.
A continuación buscamos el punto donde está declarada nuestra condición. La forma más rápida es buscar el texto “En espera”. Lo único que tendremos que hacer es reemplazarlo por “2”:
Si guardamos el fichero y volvemos a la interfaz de SPD, veremos que la condición ha cambiado:
Y si probamos ahora a crear o editar cualquiera de los elementos de la lista, comprobaremos que esta vez sí que se envían los correos.
Conclusiones
SPD 2007 es una herramienta que simplifica mucho el diseño de workflows, generando por nosotros el fichero xml que define el comportamiento de dichos workflows. Sin embargo, a veces no hay más remedio que modificar manualmente dicho fichero para conseguir el comportamiento que deseamos. En este caso la modificación es muy sencilla y se puede hacer sin necesidad de conocer el esquema que maneja Microsoft Workflow (WF) de .NET, pero en otros casos es posible que tengamos que indagar en los detalles de sus estructuras para desarrollar funcionalidades más complejas que SPD no permite desde su interfaz de usuario.
