Partiendo de Workflow Foundation

En esta ocasión este va a ser un post que en lugar de explicar o dar a conocer algo va a intentar lo contrario, que intentéis compartir vuestra experiencia al respecto de un tema que llevo planteándome hace tiempo y que a nivel laboral también me he encontrado en alguna ocasión.
Como sabréis, hoy en dí­a el BPM esta de moda, y son muchas las empresas privadas e instituciones píºblicas que quieren apostar por este tipo de sistemas. Para proyectos con un presupuesto y alcance suficiente, se intenta abordar el  problema adquiriendo productos desarrollados por otros proveedores especializados en este tipo de producto. El problema aparece en proyectos de menor alcance, donde la inversión por un BPM con la tipologí­a que os comentaba hace un momento, no es viable.
A partir de aquí­ se me ocurren dos alternativas:
* Encontrar una solución BPM, que aunque no cuente con toda la funcionalidad y el nivel de soporte de un producto estandar, pueda atender a las demandas del alcance necesario, de manera gratuita, es decir, un producto de software libre.
* Para desarrollos .NET, partir de la definicion base de Workflow Foundation y extenderla a base de enfocar recursos propios de la empresa a este respecto, con la idea de crear un producto que puede ser reutilizado en otros proyectos de la misma empresa.
Enfocándome en el segundo punto, que es la finalidad del post, mi duda al respecto es si alguno de vosotros se ha tenido que enfrentar a un problema similar, y cuál ha sido su experiencia al respecto. Es decir, partiendo del funcionamient basico de Workflow Foundation, ampliar sus capacidades con requerimientos basicos de un BPM, como podria ser una asignacion de tareas a usuarios, grupos de usuarios, perfiles roles (con sus correspondientes paneles de administracion para el mantenimiento) a actividades. Y lograr crear actividades con lí­mite de tiempo de ejecución o de finalización masiva (como podrian ser las confirmaciones de entrega, o las recepciones de documentación… hemos hablado sobradamente de esto en el especial de motores de flujo). Todo esto, por supuesto, en su sistema basado en persistencia en base de datos. No estamos hablando de flujos que duren horas, si no en flujos que pueden durar, semanas, dí­as, meses y hasta años.
En su momento realicé investigación por mi parte, y encontre ciertas dificultades en el modelo de persistencia y tracking de Workflow Foundation respecto sobre todo a la poca documentacion que encontre que me fuera de utilidad. Se habla mucho de PersistenceService y TrackingService y de la capacidad de ampliar el modelo, pero a nivel de persistencia en base de datos, es de locos enterarse para qué sirve cada una de las tablas que se genera para la persistencia y cada uno de los campos de la misma. Y sin esa base clara, poco se va a poder avanzar para ampliar el funcionamiento.
De ahí­ que en este caso sea yo quien solicita vuestra ayuda, cualquier ayuda que podais aportar respecto a BPM’s de software libre y la posibilidad de embarcarse en el proyecto de ampliar las capacidades de Workflow Foundation. Será más que bienvenida.
Un saludo y muchas gracias.
Miguel.

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.

Las Partes Fundamentales de un Motor de Flujo – II Parte

Tras publicar unos meses atrás la primera parte del artí­culo, comenzamos con la segunda.
Reenví­os
Las tareas pueden ser asignadas en un momento dado a un usuario en concreto, y, a posteriori, por necesidades del negocio asignarse a usuarios diferentes del inicial. Normalmente a funcionalidades de este tipo no suelen tener acceso los usuarios con nivel básico, sino que se encuentran delegadas a usuarios con nivel de administración o a gestores de grupos de usuarios (gestores normalmente asociados al negocio de la aplicación).
Normalmente cuando una tarea es reenviada a otro usuario, el BPM no se limita a cambiar la asignación de propiedad a la tarea (a quien le está asignada un momento dado), sino que se realiza una copia de la tarea inicial y posteriormente crea una nueva tarea la cual pasara a la propiedad del usuario al que se ha reasignado. Finalmente, la tarea inicial pasa a un estado especial (“Reenviado” por ejemplo) y si cuenta con algíºn tipo de campo de observaciones, se indica de forma automática cuál es el identificador de la tarea asociada al reenvió y que se acaba de generar.
El sentido de todo esto es contar con la trazabilidad completa de lo que ha ocurrido. Si el BPM se limitara a cambiar el usuario propietario, nunca sabrí­amos cuales han sido los sucesivos cambios que ha sufrido una tarea.
Delegaciones
Las delegaciones son una serie de reglas que automatizan los reenví­os de tareas a partir de un conjunto de requerimientos establecidos.
Por ejemplo, si tenemos una actividad en nuestro flujo que la realiza un usuario en concreto, podrí­a darse el caso de que de forma temporal queramos que en lugar de realizarla dicho usuario lo hago otro (por ejemplo porque el usuario inicial estarí­a de vacaciones en ese periodo de tiempo y queremos que las tareas que se le asignen no queden esperando a que vuelva).
En el caso de que se cumpliera la condición, automáticamente la tarea se reenviarí­a al usuario de destino, sin necesidad de que la operación deba hacerse de forma manual.
BAM
El BAM (Business Activity Monitoring) es el panel de control a partir del cual un usuario administrador es capaz de obtener información de explotación a partir de los resultados generados a partir de la instanciacion de las plantillas y actividades existentes en el motor, a modo de report. Los indicadores tí­picos muestra el níºmero de instancias por plantillas, los cuellos de botella en diversas actividades, o la eficiencia (relativa) de los usuarios a la hora de completar las tareas. Lo de relativo viene al hilo de que para poder conocer la eficiencia real de un usuario no nos va a bastar la información contenida en el motor, ya que para un resultado real vamos a necesitar conocer (por ejemplo) cuántos dí­as ha trabajado ese año, y mucho me temo que dicha información va a partir de otro modelo de datos referenciado a nuestro propio negocio y no al del motor.
De ahí­ que bajo mi punto de vista, en la mayorí­a de ocasiones el BAM que ofrecen los BPM es insuficiente, ya que nos dan una visión muy superficial de la realidad, y responden a preguntas demasiado concretas. Cuando normalmente para responder a las preguntas del conocedores del negocio vamos a tener que mezclar la propia información de negocio con el resultado contenido en el modelo de datos del motor, y esto, no suele ser precisamente sencillo.
Hasta aquí­ la segunda parte, en la tercera, intentaremos abordar de forma directa el concepto de Bandeja de Tareas, que no es algo que conceptualmente ofrezca el BPM, pero que es muy comíºn su uso a partir de la información que el propio BPM alberga. Hablaremos entre otras cosas de funcionalidades asociadas a la bandeja, así­ como de algunos problemas o decisiones de arquitectura tí­picos a la hora de querer mostrar en la bandeja de tareas información que no es propia del BPM y que forma parte de nuestro negocio.
Saludos.
Miguel.

AgilePoint, Algunos Puntos de Mejora

En este blog tenemos ya unos cuantos artí­culos sobre AgilePoint, hablando de todas las mejoras incorporadas, y de los aciertos en ciertos aspectos tanto de su arquitectura como de su facilidad de explotación y facilidad de integración con otros productos.
Pero como todo producto, siempre hay cosas a mejorar, y hoy vamos a dedicar un pequeño artí­culo a detallar ciertos aspectos, que bajo mi punto de vista podrí­an ser mejoras a tomar en cuenta en próximas versiones.
Procedimientos Almacenados
El propio motor de AgilePoint cuenta con una base de datos en la cual almacena toda la información relacionada con los flujos, actividades, tareas usuarios… Toda esta información es explotable desde el exterior mediante la capa de servicios que AgilePoint provee. Lo curioso de todo esto es que ante una magní­fica decisión de arquitectura (la de orientar todo a servicios), queda al aire un pequeño aspecto de seguridad en base de datos, y es que el usuario que utiliza el propio motor de AgilePoint tiene capacidad de realizar cualquier tipo de consulta, modificación e inserción directa sobre el modelo. No existe ni un sólo procedimiento almacenado que bloquee dicho acceso y que sirva de punto de entrada a las tablas. Tal como hemos hablado en este mismo blog, es una buena práctica de seguridad el crear un usuario que íºnicamente tenga permisos de ejecución sobre procedimientos almacenados en la base de datos, obligando así­ a que todo acceso se haga de forma controla a través de los procedimientos almacenados ya definidos.
Nuevas Propiedades de AgileWorks y AgileParts no Visibles a Través de la Capa de Servicios
Uno de los puntos fuertes de AgilePoint es la capacidad de poder crear nuevas actividades a medida a través de un plugin que incorporan en Visual Studio y que permite al desarrollador crear nuevos AgileWorks y AgileParts (de los cuales aíºn tenemos pendiente hablar en el blog). Entre otras cosas, dichas actividades a medida, permiten definir nuevas propiedades, que pueden ser rellenadas en tiempo de diseño a través del diagramador Envision, provisto por el mismo AgilePoint. Una vez definidas y rellenadas las propiedades, estas pueden ser consumidas a través de los propios AgileWorks y AgileParts con llamadas al API de AgilePoint, pero bajo ningíºn caso pueden ser consultadas directamente a través de servicios web. Es decir, yo puedo tener una tarea instanciada que parte de una actividad de tipo AgileWork a la cual hemos asociado una nueva propiedad llamada “NombreCiudad”, pues no podemos pedirle a un servicio web que retorne el valor de dicha propiedad para poder utilizarlo. íšnicamente podrá ser consumido este valor desde dentro del propio AgileWork en uno de los eventos que tiene relacionados… como por ejemplo, al asignarse la tarea, al cancelarse, al crearse, al finalizarse…
Qué tareas ha generado la finalización de una tarea
En muchas ocasiones nos puede ser íºtil el saber el conjunto de tareas que se han generado a partir de la finalización o completado de una tarea anterior. Esto no es posible conocerlo a partir del propio AgilePoint, ya que en su modelo de datos no está contemplado ningíºn campo que almacene dicha información. La íºnica manera que tenemos es realizar ciertas consultas por fecha y comparar, pero esto no garantiza que en momentos de alta concurrencia nos está retornando fechas que a priori pueden ser válidas, pero que no tienen nada que ver con la actividad procesada.
Grupos a los que pertenece un usuario
Incomprensiblemente podemos saber los usuarios que pertenecen a un grupo, pero no podemos obtener a través de un servicio web los grupos a los que pertenece un usuario. Para resolverlo tenemos que hacer cosas como entrar en cada uno de los grupos, y mirar si hay algíºn usuario que coincida con el que estoy buscando.
Falta de soporte para instalaciones sobre BBDD Oracle y DB2
No se dispone de guí­a de instalación para el producto si se asienta sobre BBDD Oracle, ni tan siquiera aparece en la documentación.
Errores en el guardado de las plantillas en Envision
Incomprensiblemente se produce en ocasiones que al guardar los cambios en una plantilla hay ciertas actividades que al completarlas provocan que el flujo se quede colgado. Se cierra la actividad y aunque esta permanezca en el flujo unida por una flecha con otra, esta nunca se llega a ejecutar, es como si la flecha no estuviera bien conectada. Esto obliga en muchas ocasiones a tener que crear la plantilla desde cero para solventar el problema.
Aquí­ finalizamos con las propuestas, más adelante iremos incorporando nuevos aspectos.
Un saludo.
Miguel.

Tarpipe, Flujos de Trabajo para el Tiempo de Ocio

En https://www.genbeta.com podréis encontrar el siguiente artí­culo que habla de Tarpipe, una herramienta web que permite crear flujos de trabajo para intercomunicar información contenida en diferentes redes sociales, correos electrónicos, etc.

Tarpipe
Tarpipe

Un BPM para el tiempo libre 🙂
Cuanto menos curioso!
https://www.genbeta.com/2009/01/11-tartipe-publicaciones-mediante-flujos-de-trabajo
Saludos.

Las Partes Fundamentales de un Motor de Flujo – I Parte

La verdad es que en el blog llevamos ya acumulados unos cuantos artí­culos que tienen que ver con motores de flujo, pero repasando hoy un poco los temas que se han ido tocando, me he dado cuenta que no hay ningíºn artí­culo que ofrezca un resumen introductorio para las personas que permanezcan ajenas a este mundo y quieran empezar a “tocar pie” y sentirse seguros tratando con estos temas. De ahí­ que el objetivo de este artí­culo es el de aterrizar ciertos conceptos comunes que manejan los motores de flujo que podemos encontrar hoy en dí­a en el mercado.
Para empezar a tratar este tema, creo que primeramente nos debe quedar claro la capacidad y potencia de que sean los propios conocedores de un negocio los que sean capaces de diseñas sus flujos de trabajo. De este tema si que ya hemos hablado anteriormente en un artí­culo anterior. Emplearemos el gráfico de flujo incluido en dicho artí­culo como ejemplo para alguna de las definiciones de las que se van a ir hablando.
Una vez conocido lo que es un flujo de trabajo y cual es su función principal (la capacidad de los propios conocedores del negocio de definir cómo funciona su propio negocio), vamos a desglosar otras de las piezas que forman parte del puzle.
Actividades
Una actividad es cada uno de los pasos que hemos definido en el flujo y que corresponden a acciones determinadas a realizar dentro de nuestro negocio. Por ejemplo, en el artí­culo “Definiendo el Negocio a Base de Flujos”, disponí­amos de actividades como “Disminuir Stock”, “Hacer Pedido”, “Introducir Datos Personales Comprador”, etc.
Estas actividades pueden llevarse a cabo de forma manual (por personas) o automáticas (procesos automáticos), y pueden conllevar el que al realizarse sea necesario incorporar cierta información que quede registrada en algíºn lugar, o simplemente sea necesario marcar que han sido realizadas, a modo de punto de control (por ejemplo, entregar una documentación, marcar que una caja ha sido embalada, etc). Siguiendo el ejemplo de flujo inicial del que disponemos, una actividad manual que incluye la introducción de datos de negocio serí­a la de “Introducir Datos Personales Comprador”, mientras que una automática serí­a la de “Imprimir Factura”, ya que una vez realizada la actividad “Realizar Cobra Manual”, la factura se imprime de forma automática a través de la caja registradora pertinente.
Una actividad también puede contar con una caracterí­stica temporal, ya que podrí­a darse el que tenga que ser cumplida en un plazo de tiempo máximo determinado. Por ejemplo, algíºn tipo de notificación podrí­a requerir respuesta en un plazo de menos de un mes. Si este plazo se superara tal vez necesitáramos realizar alguna otra actividad relacionada con el reenví­o, o cancelar la notificación (como véis, de aquí­ se extrae que los condicionantes temporales pueden afectar al flujo de trabajo, y que estos son piezas que el conocedor del negocio puede utilizar para modelar también el comportamiento del flujo a partir de las excepciones temporales que pueden darse). En una tí­pica aplicación de videoclub, ante una hipotética actividad de “Devolver Pelí­cula”, serí­a totalmente adecuado establecer un lí­mite temporal en nuestra definición de flujo. En caso de que dicho lí­mite temporal se supere, dispondrí­amos de una alarma al respecto, y podrí­amos actuar en consecuencia.
Para acabar con las caracterí­stica de las actividades, lo haremos con una de las más importantes, la “Responsabilidad”, es decir, ¿quién o quiénes van a llevar o pueden llevar a cabo potencialmente una actividad? ¿Todos los trabajadores de nuestro videoclup pueden marcar como devuelta una determinada pelí­cula, o íºnicamente lo podrán realizar las personas que están cara al píºblico? Lo mismo ocurre con nuestro ejemplo de aplicación de compra, ¿todos los trabajadores van a poder realizar un nuevo pedido a un proveedor? Lo más natural es que a la hora de poder modelar una actividad se defina qué persona en concreto va a realizarla, o qué grupo de personas va a poder hacerlo (por ejemplo: contables, administrativos, técnicos, jefes de obra, etc). En conclusión, a la hora de definir un flujo de trabajo podremos definir para las actividades que forman parte del mismo, qué persona o personas la van a realizar. Una vez se inicie el flujo (instancie) y se empiecen a instanciar algunas de las actividades (tareas), se comprobará a qué persona o grupo de personas pertenece, y esta persona o grupo serán notificadas de que algo se espera de ellos.
Finalmente, exponer el caso de que tal vez no se pueda definir inicialmente cuál o cuáles van a ser los responsables de ciertas actividades, ya que dicha casuí­stica dependerá de información proporcionada una vez el flujo haya comenzado. Por ejemplo, en un flujo de una empresa que se encargue de vender pizzas a domicilio, tendrí­a una actividad que serí­a algo así­ como “Llevar Pizzas a Casa del Cliente”, y otra anterior llamada “Seleccionar Persona que Realizará el Reparto” (ya que el reparto dependerá de la disponibilidad de los repartidores en un momento dado). En esta segunda actividad se contarí­a con el listado de todos los repartidores disponibles, la actividad finalizarí­a al marcar el repartidor. Una vez el repartidor se haya marcado, al ejecutarse la actividad “Llevar Pizzas a Casa del Cliente” se asignarí­a de forma automática al repartirdor seleccionado. Estamos hablando ahora de una asignación dinámica de la responsabilidad, y no de una pre-asignación en el tiempo de definición del flujo.
Resumiendo este punto, hemos hablado de las siguientes caracterí­sticas de una actividad: manual, automática, punto de control, temporalidad, responsabilidad (estática y dinámica).
Subrutinas
Una subrutina no es más que un flujo de trabajo pero que está orientado a la reutilización en otros flujos. Por ejemplo, la actividad “Realizar Pedido Proveedor”, seguramente podrí­a tener en su “interior” un conjunto de actividades a realizar (en el ejemplo se simplificó por mayor claridad). Serí­a bastante normal que en otros flujos de trabajo que realizáramos, fuera necesario también en un momento dado (segíºn lo dictamine el flujo), realizar un pedido a un proveedor, entonces en lugar de indicarlo como una actividad estándar, lo estarí­amos indicando como una actividad de subrutina. Al terminarse de ejecutar las actividades de la subrutina, el control volverí­a a la siguiente actividad del flujo principal. Otros ejemplos de subrutinas tí­picas son las de notificación. Podemos tener determinados cuáles son los pasos a realizar en el caso de que queramos realizar una notificación, o una entrega de material. En nuestros flujos de trabajo podrí­amos enlazar directamente como actividad de subrutina dicha acción, en el caso de que fuera necesario realizar una notificación. Para los programadores o personas con conocimientos de programación, estarí­amos hablando de la misma acción que realizan los subprocedimientos en la programación estructurada, agrupaciones de código reutilizable desde llamadas de otros procedimientos principales.
Procesos (instancias de flujos)
Una vez definido nuestro flujo de trabajo, llega la hora de ponerlo en funcionamiento. En el caso de que estuvieramos hablando de nuestra aplicación de compra, si la instaláramos en unos grandes almacenes donde existen multitud de puntos de venta en cada una de las plantas, se estarí­an lanzando procesos de venta de forma continua y simultánea a lo largo de toda la jornada.
A cada una de las instancias realizadas de un diagrama de flujo, se les llama proceso. Un flujo (o plantilla) es a lo que una clase serí­a si estuviéramos hablando en términos de programación en objetos. Es un modelo. Un proceso (o instancia de flujo o plantilla) es a lo que un objeto serí­a si estuviéramos hablando en términos de programación en objetos. Tenemos entonces ahora un sí­mil estupendo, que nos ayuda a comprender mejor esta casuí­stica. De nuestra plantilla podemos hacer cientos de instancias en forma de procesos, de manera que a nuestras clases, podecemos hacer cientos de instancias, en forma de objetos.
Una de las caracterí­sticas principales de un motor de flujo es que es capaz de almacenar todos los estados de transición de un proceso. Es decir, cada vez que se crea una instancia, se almacena la fecha, el usuario que la ha creado, y toda la información que se requiera guardar y que esté relacionada con el flujo. ¿Qué sentido tiene esto? Pues que nuestro flujo no tendrí­a por qué ser completado en un tiempo corto de varios minutos, si no que podrí­a durar dí­as, meses, semanas, incluso años (imaginad por ejemplo un flujo que represente los pasos a realizar en un expediente administrativo).
Gracias a disponer de esta información de forma almacenada podremos saber qué usuarios han lanzado las peticiones de compra y en qué fechas, además de saber si dichas compras han sido ya finalizadas o están en proceso de.
Tareas (instancias de actividades)
Así­ como hemos hecho ya la relación flujo-proceso, ahora nos queda hablar de la relación actividad-tarea. Cada vez que instanciamos un flujo creamos un nuevo proceso íºnico. Cada vez que se alcanza una de las actividades de dicho proceso, creamos, una o varí­as instancias de la misma, a dichas instancias se les llama tareas. Realmente la tarea es lo que hay que llevar a cabo o se ha llevado a cabo en la vida del proceso. Una vez finalizadas las diferentes tareas, las actividades se dan por finalizadas, el motor de flujo calcula el camino a seguir, y se siguen creando nuevas instancias de actividades, que como acabamos de averiguar, se les denomina tareas.
Como habí­amos visto ya cuando hemos hablado de las actividades, estas tienen un responsable. Cuando la actividad se instancia, convirtiéndose en tarea (o tareas), éstas también pasan a tener un responsable (que como hemos visto también se puede asignar de forma manual o automática). La información de las tareas vivas en el flujo se almacena también de forma permanente en el flujo. Una consulta tí­pica y básica es preguntarle al motor de flujo que retorne todas las tareas de un usuario que están en estado “pendiente”. Con esto sabrí­amos todas las tareas que tiene el usuario pendientes de realizar. Su trabajo.
¿Qué más estados puede tener una tarea? Pues depende un moto del motor de flujo que estemos utilizando, pero de forma genérica podrí­amos diferenciar los siguientes:

  1. Pendiente: La tarea está creada, no está finalizada y está pendiente que se le asigne un usuario en concreto. Normalmente pertenecerá a un grupo de usuarios, y está pendiente de que alguno de ellos se la asigne o le sea asignada.
  2. Asignada: La tarea está pendiente de cerrarse y permanece asignada a un usuario en concreto.
  3. Finalizada: La tarea ha sido cerrada por un usuario en concreto, el trabajo relacionado ya ha sido finalizado.
  4. En Ejecución: La tarea está asignada a un usuario, está pendiente de finalizarse, y en estos mismos momentos está siendo ejecutada por el usuario responsable.
  5. Cancelada: La tarea se ha cancelado.
  6. Enviada: La tarea se ha finalizado al haberse enviado a otro usuario, generándose una nueva tarea relacionada a la inicial.

Aqui damos fin a la primera parte del artí­culo, en la segunda, trataremos otros temas relacionados como son: Bandeja de Tareas, Delegaciones, BAM y otras piezas.
Saludos a todos y feliz año!

Autenticación con AgilePoint y el uso de Surrogate (2ª Parte)

En un artí­culo anterior hablábamos de la autenticación con AgilePoint y la surrogación. Echaba en falta algíºn gráfico que dejara algo más clara la forma de trabajar, así­ que lo adjunto en esta segunda parte.

Esquema Surrogate
Esquema Surrogate

Como véis, se aprecian las tres combinaciones de las que se habla en la primera parte.

  • Opción A: Usuario a través de un navegador web, el servidor web tiene que impersonar al usuario llamante.
  • Opción B: Usuario a través de aplicación de escritorio que trabaja contra una capa de servicios, el servidor de negocio tiene que impersonar al usuario llamante.
  • Opción C: Usuario a trvés de aplicación de escritorio que trabaja directamente con servicios de AgilePont, no hace falta impersonación, el propio usuario pertenece al dominio y se autentica directamente con sus credenciales de red.

Pocos artí­culos íºltimamente. Mucho trabajo.
Saludos!
Miguel.

Autenticación con AgilePoint y el uso de Surrogate

Una de las principales capacidades que ofrece AgilePoint como producto, es la orientación a servicios que han dado a la solución de software. Para ello, en la versión 4.0 de la herramienta ofrecen en concreto dos servicios que agrupan todos los métodos que permiten acceder a la funcionalidad del motor.
workflow.asmx
Servicio que encapsula todos los métodos asociados a la manipulación de los flujos (incluyendo por ejemplo servicios para instanciar plantillas, obtener información de un proceso, establecer el valor de una de las propiedades de un proceso…).
admin.asmx
Servicio que encapsula todos los métodos asociados a la administración del propio motor (incluyendo por ejemplo servicios especí­ficos para la creación de usuarios, permisos, roles…).
A priori, con estas dos piezas, y desde cualquier tipo de tecnologí­a cliente, podrí­amos manipular el BPM desde una aplicación cliente creada por nosotros mismos.
La pieza que aquí­ nos falta es conocer cómo se protege AgilePoint para que no todos los usuarios que tengan acceso a dichos asmx puedan utilizarlos para acceder al motor y manipularlo a su gusto. Como comprenderéis, si no existiera dicha autenticación estarí­amos hablado de un fallo de seguridad como la copa de un pino.
El requerimiento indispensable para poder acceder a los servicios, es que el mismo objeto que está realizando la conexión al servicio cuente con las credenciales de red del usuario que está haciendo la llamada. Esto ya en principio garantiza que la persona que está llamando al servicio está autenticada en el dominio, que quieras que no, supone una primera barrera de seguridad. Pero esto, no es suficiente, ya que necesitaremos que el usuario que esté haciendo la llamada también esté dado de alta en la propia base de datos de usuarios de Agilepoint. Como curiosidad, remarcar que la propia herramienta de gestión de usuarios de AgilePoint provee de facilidades para sincronizarse con el directorio activo e importar la información de los usuarios de dicho directorio a la base de datos de usuario de AgilePoint.
Resumiendo, si disponemos de nuestras credenciales de red validadas, se las pasamos a AgilePoint y nuestro usuario está también incluido en el repositorio de usuarios de AgilePoint, olé, ya podemos usar los servicios sin problemas.
Pongamos por ejemplo que estamos trabajando con una aplicación de escritorio que referencia los servicios web de AgilePoint directamente. Siguiendo este procedimiento, conseguiremos autenticarnos sin problema.
La casuí­stica complicada viene cuando por ejemplo trabajando en web, o en el caso de que no conectemos directamente con nuestra aplicación al servicio, si no que tengamos otra aplicación que haga la conexión en nuestro nombre. Estarí­amos hablando de una tí­pica aplicación web, donde el usuario que la está ejecutando es del del pool del servidor de aplicaciones y no la persona que ha abierto el navegador en su casa… o en el caso de que nuestra aplicación de servicios no ataque directamente a los servicios de AgilePoint si no que llame a una capa de negocio con orientación a servicios que sea la que se encargue después de llamar a Agilepoint. En ambos casos tenemos “algo”por enmedio que tiene sus propias credenciales que no son precisamente las nuestras.
Ante este problema tenemos una primera solución para lograr la autenticación, nos creamos un usuario para ese “algo” intermedio en nuestro directorio activo, lo damos de alta también en la base de datos de Agilepoint, y ala, cuando llamemos al “algo” este se podrá autenticar y hacer el trabajo sin problemas. Esto funciona, pero tiene un problema de base, que todos los usuarios trabajarán contra el BPM usando el mismo usuario, y esto va en contra del funcionamiento basado en flujos.
Como hemos tratado ya en otros artí­culos, uno de los componentes principales de un motor de flujo es el responsable de cada una de las tareas definidas en el flujo de trabajo. Parte de la gracia de este sistema de trabajo es que la persona que conoce el negocio define las responsabilidades de cada uno de los pasos a seguir, y a partir de esta responsabilidad, los usuarios asignados tendrán constancia de que tienen que realizar cada una de las tareas. Imaginaos entonces que siguiendo un flujo determinado se asigna la responsabilidad de las tareas generadas a una serie de usuarios. ¿Cómo voy a conseguir entonces preguntarle al motor de flujo que me de las tareas de dicho usuario especí­fico si siempre estoy haciendo login a través de un usuario intermedio comíºn a todos? En este caso todos serí­amos el mismo usuario y recibirí­amos siempre las mismas tareas.
Después de toda la puesta en situación inicial llegamos entonces al punto clave y objetivo del artí­culo, el Surrogate. Mediante la “surrogación” (no creo que esté este palabro en ningíºn diccionario) conseguimos decir en la autenticación que el usuario intermedio comíºn a todos hable en nombre de otro. Es decir, nos autenticamos igual, pero en un momento dado dicho usuario le dice a AgilePoint: “Oye tí­o, yo soy el que me autentico siempre, estas son mis credenciales y seguro que además me tienes en tu base de datos, y, a partir de ahora mismo todas las operaciones que voy a mandarte las voy a hacer en nombre de Pepe, por lo tanto, cuando te pida que me des todas las tareas en estado ofrecido me estoy refiriendo a las de Pepe, y cuando te diga que proceses una tarea lo vas a hacer también en nombre de Pepe”.
Claro está, “Pepe” va a tener que estar dado de alta en el repositorio de usuario de AgilePoint, o si no por mucho que le diga “el de siempre” que va a hablar en nombre de “Pepe”, AgilePoint va a responder: “no sé de quién me estás hablando”.
A partir de aquí­, para ver a nivel de código cómo funciona esto, os dejo un link de la página de Ascentn donde podéis ver el ejemplo:
Ejemplo KB-Ascentn
Para acabar, y como podréis ver en el link que os acabo de dejar, no todos los usuario disponibles en el repositorio de usuarios de AgilePoint tienen la capacidad de hablar en el nombre de otros. Para disponer de dicha capacidad, se debe dar de alta el usuario como “Impersonator” a través de la herramienta de configuración del servidor de AgilePoint.
Espero haberme explicado con suficiente claridad, no es precisamente fácil intentar trasladar el uso del Surrogate.
Saludos.
Miguel.