Otra interesante herramienta BPM, con toda la potencia adicional de la gestión documental basada en la experiencia de Adobe.
https://www.adobe.com/products/livecycle/
Un saludo.
Category: BPM
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.
Motores de Reglas de Negocio
Muy recomendada la lectura del siguiente artículo:
La sinergia de los BPMR (Motores de Reglas de Negocio) con BPM Y SOA
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.
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:
- 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.
- Asignada: La tarea está pendiente de cerrarse y permanece asignada a un usuario en concreto.
- Finalizada: La tarea ha sido cerrada por un usuario en concreto, el trabajo relacionado ya ha sido finalizado.
- 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.
- Cancelada: La tarea se ha cancelado.
- 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)
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.