Las Partes Fundamentales de un Motor de Flujo – III Parte

Tras haber repasado los conceptos básicos, y algunos conceptos algo más avanzamos como son las delegaciones, reenví­os y BAM, pasamos ahora a describir una de las piezas fundamentales en el uso de motores de flujo: la Bandeja de Tareas.
El concepto de tarea ya lo repasamos en el capí­tulo de conceptos básicos, donde pudimos ver que éstas se iban generando a medida que se van alcanzando las actividades de cada uno de los flujos que se han definido y son iniciables a través del motor.
Las tareas generadas, estén en el estado que estén, se almacenan en un repositorio especí­fico, el cual es consultable a través del API del motor de flujo con el que estemos trabajando, y que retorna información básica asociada a las tareas del repositorio. Por ejemplo:
* Fecha de Creación
* Nombre de la Actividad a la que representa la tarea
* Estado: Finalizado, Pendiente, Reenviado, En Curso, Cancelado
* Nombre del Flujo asociado
* Fecha de Finalización
* Usuario o grupo que tiene la tarea asignada
Como comentábamos, a través de API pertinente, se pueden consultar las tareas existentes, incorporando además diversos filtros, como pueden ser, las tareas en un determinado estado, tareas creadas entre un rango de fechas, tareas pertenecientes a una determinada actividad o tareas pertenecientes a un determinado usuario. Las capacidades de filtro dependerá del motor de flujo sobre el que estamos trabajando. Existen dos tipos de filtros básicos empleados, como son las tareas pendientes de un usuario en concreto y el conjunto de tareas que aíºn no se han asignado a ningíºn usuario (también llamadas tareas de pool).
A partir de estas consultas ya podemos preparar una bandeja de tareas, la cual consistirí­a en una página (normalmente la inicial de la aplicación), donde un usuario, tras haberse autenticado, podrí­a consultar qué tareas tienen pendientes para él. Otras opciones básicas de consulta para el usuario serí­a ver en la misma bandeja qué tareas no tienen aíºn asignación de usuario, pero están asignadas a uno de los grupos a que dicho usuario pertenece (hablaremos de usuarios, grupos y roles en próximos posts). El usuario podrí­a realizar las tareas que tiene ya asignadas, o asignarse (tomar en propiedad) alguna de las tareas pendientes de asignar y pertenecientes a alguno de sus grupos.
Finalmente, otra de las caracterí­sticas básicas que aparecen en una bandeja de tareas para un usuario, es la capacidad de finalizar una tarea de tipo “punto de control” de forma directa, desde la propia bandeja, sin necesidad de acceder a la tarea para poder finalizarla. Como ya hablamos en su momento, las tareas de tipo “punto de control” son las que íºnicamente es necesario marcar que se han realizado, sin necesidad de incorporar ningíºn tipo de información de negocio relacionada con la misma. Se suelen utilizar mucho en el caso de marcar entregas o recepciones de documentación. En estos casos, en la bandeja de tareas, existe la posibilidad de seleccionar las tareas de tipo “punto de control” para finalizarlas de forma masiva.
Otras opciones más avanzadas y ya desde una bandeja de tareas de un usuario administrador, serí­a contar con la posibilidad de reenviar tareas de la bandeja así­ como la de cancelar las mismas. Incluso, y ya dependiendo del negocio, la posibilidad de crear nuevos flujos, seleccionados del conjunto de flujos disponibles en la aplicación.
Información Adicional, propia del Negocio
Hasta ahora hemos cómo podrí­a funcionar una bandeja de tareas, mostrando en todo caso información relacionada íºnicamente con el motor, pero, hemos de tener en cuenta que un motor de flujo es íºnicamente una herramienta que da soporte para la resolución de un determinado tipo de problema que se da en un ámbito en concreto, y una herramienta que tenga sentido por si misma. Por ejemplo, podrí­amos utilizar nuestro motor para la gestión de una pizzerí­a, o de un call-center, y dicho “negocio” incluirí­a información propia que seguramente serí­a interesante que se mostrara en la bandeja. En el caso de la pizzerí­a, por cada comanda lanzada y que aparecerí­a en la bandeja en forma de tarea, a parte de mostrar la fecha y la hora en que la pizza fue pedida (fecha de creación de la tarea), serí­a interesante mostrar los ingredientes de la misma. En el caso del call-center, serí­a interesante mostrar el nombre y apellidos de la persona que ha realizado la llamada inicial, así­ como un indicador de si está asociado a alguna de las promociones existentes.
Esta situación nos plantea un pequeño problema, ya que la fuente de datos donde se almacenan las tareas con la fuente de datos donde se almacena la información del negocio, no suele ser la misma, y no tanto ya el respositorio, si no la tecnologí­a con la que el respositorio se ha generado. De ahí­ que el mezclar la información propia del negocio con la información del motor de flujo, en tiempo real (hay que pensar que la bandeja de tareas es una herramienta que tiene que mostrar un estado actualizado real en todo momento), represente, a priori un problema, atendiendo además a los requerimientos de velocidad en el uso que este tipo de caracterí­sticas plantea (teniendo en cuenta que va a ser la funcionalidad más empleada de la aplicación, es necesario que lo tiempos de repuesta sean manejables).
Ante todo esto, ¿soluciones? Pues a priori va a depender un poco de la topografí­a de vuestro sistema, y de los requerimientos de usuario, pero, en principio, lo ideal serí­a que al mostrar la información estemos consultando el menor níºmero de sistemas, ya que cuantos más estemos consultando, más vamos a tardar en dar una respuesta. Para ello una opción serí­a incorporar al flujo y a las tareas la información que queremos mostrar en la bandeja. Por ejemplo, al dar de alta el proceso (instancia del flujo), podrí­amos incorporar ya de serie los ingredientes de la pizza, así­ cuando consultemos la bandeja de tareas nos bastarí­a atacar una fuente de datos para obtener toda la información.
Esta decisión a priori no es sencilla, y como os comentábamos va a depender directamente de vuestros requerimientos. Para que os hagáis una idea, en el íºltimo sistema de bandeja de tareas sobre el que he podido trabajar, se consultaban dos fuentes información diferentes y se mezclaba la información en memoria antes de mostrarla en la bandeja, y, este sistema, para la topografí­a  existente, era el más eficiente con diferencia.
Aprovecho la temática para comentar que al trabajar con un motor de flujo podemos encontrarnos con el mismo problema pero a la inversa, es decir, que al trabajar con la información de negocio, necesitemos mostrar cierta información relacionada que está almacenada en el motor de flujo. Por ejemplo, si queremos mostrar cuando una pizza fue entregada, podrí­amos consultar la fecha de fin del proceso. Pero esto nos obligarí­a a consultar primero el repositorio del negocio y a continuación consultar el proceso relacionado para obtener la fecha. Soluciones a esto serí­a que antes de cerrar el proceso se lanzara desde el mismo la actualización de la información del negocio, incorporando la fecha de fin de proceso a la fecha de entrega de la pizza. Tenemos una pequeña información redundante, pero, hemos ganado en eficiencia en cuanto a la consulta de la trazabilidad de la información asociada a  un pedido.
Terminamos por hoy. En el próximo post, hablaremos de Gestión de Usuarios, Grupos y Roles.
Saludos.
Miguel.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.