01.30.09
Si Matrix Funcionara Bajo Windows…
Un toque de humor de cara al fin de semana que comienza 
http://www.collegehumor.com/video:1886349
Saludos!
Miguel.
[?]
01.24.09
Definición Código de Compensación
Siempre me ha resultado curioso el comprobar que algo que llevas haciendo desde hace tiempo,a alguien se le ha ocurrido ponerle un nombre (¿cómo llamáis al cacharro que usan en las heladerías para hacer las bolas de helado para los cucuruchos? Yo lo llamaba “hacedor de bolas”, hasta que a un amigo se le ocurrió bautizarlo como “Chilaguillo”). Esta misma sensación la ha tenido leyendo teoría de patrones de diseño y de repente decir, anda, pero si esto lo llevo haciendo de hace tiempo, no sabía que era un patrón. Bueno, para ser sinceros, me ha pasado más veces con los anti-patrones que con los patrones
Esta semana, en el curso de Biztalk, me ha vuelto a pasar, resulta que una de las opciones que incluye la herramienta es la de incorporar actividades de compensación, algo que, venía haciendo desde tiempo atrás, sin saber que tenía ese nombre.
Un código o una acción de compensación se puede contemplar cuando estamos realizando una incursión en un entorno no transaccional, donde aplicamos cambios sobre diferentes orígenes de datos. Si en alguno de los puntos se produce un error, podríamos no disponer de la posibilidad de volver todo al estado inicial de forma automática y con total seguridad de que se va a hacer de forma correcta (lo que sería una transacción de base de datos por ejemplo, o utilizando el componente de transacciones distribuidas de Microsoff el MSDTC).
Si no lo podemos resolver de forma automática, algo tendremos que hacer para que nuestro conjunto de datos no quede en un estado inconsistente. ¿Y qué podemos hacer? Pues muy fácil, compensar el error :)
Por poner un ejemplo algo gráfico, imaginaos una aplicación donde al pulsar un botón de “Iniciar Proceso” se lleven a cabo una serie de acciones que implican la creación de ciertos registros a través de servicios web pertenecientes a diferentes proveedores. Podría darse el caso que alguno fallara, cuando una llamada a un servicio anterior ya ha sido confirmada. En ese caso, en el bloque “catch” correspondiente, tendríamos que comprobar cuál ha sido la llamada que ha fallado e intentar volver a su estado inicial las acciones que ya teníamos confirmadas. Nos iría estupendo por ejemplo con contar métodos dentro de los mismos servicios web que nos permitieran volver atrás la acción (si hemos hecho una inserción, pues disponer de un método para hacer el borrado). Aunque también caben otro tipo de compensaciones que aunque a primera vista no parezcan muy elaboradas pueden dar muy buenos resultados, como enviar un e-mail a un administrador indicando en que punto del proceso se ha producido el fallo, o incorporar una entrada en el monitorizador de eventos del servidor para que salte la alerta automáticamente a los responsables del sistema, resolviendo el usuario el problema de forma manual.
Un saludo.
Miguel.
[?]
01.23.09
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.
[?]
01.22.09
Renovando y Google Friend Connect
Aunque suene tópico, “renovarse o morir”
Hacía tiempo que buscaba un cambio de imagen, y por fin llegó.
Incluyo además el plugin de Google Friend Connect. Tiene su gracia.
Saludos.
Miguel.
[?]
01.20.09
Formación Biztalk 2006
Esta semana estoy participando en un curso de Biztalk 2006. El curso lo imparte Francisco González, de Solid Quality Learning.
La verdad es que tenía ganas de conocer la herramienta, ya que forma parte de los “grandes desconocidos” a nivel estándar, y, además, teniendo que ver con gestión de flujos y conocimiento de negocio, se “toca” bastante con lo que me vengo dedicando últimamente.
Biztalk a grandes rasgos es un integrador de sistemas, y no confundir con Integration Services, aunque pueda utilizarse también para realizar acciones similares en muchos casos. Lo más curioso es que realmente Biztalk es un transportador de mensajes entre diferentes entornos, toda “orquestación” funciona mediante mensajes xml que deben respetar ciertas estructuras xsd definidas a partir de la misma herramienta.
La verdad es que se presenta como una herramienta muy interesante para la pequeña/mediana empresa, que se encuentra en la típica situación de contar con varios sistemas de información conviviendo al mismo tiempo, y que en un momento dado necesita explotar la información contenida en cada uno de dichos sistemas. La lástima de todo esto es la inversión inicial que debe realizarse para poner en marcha todo esto, ya que entre licencias de Biztalk y SQL Server, nos vamos practicamente a 100.000€ euros.
Describo a continuación el temario que estamos tratando:
Modulo 1: Introducción a BizTalk Server 2006
Modulo 2: Creación de Schemas
Modulo 3: Creación de Maps
Modulo 4: Desplegando un proyecto BizTalk
Modulo 5: Enrutando Mensajes de BizTalk
Modulo 7: Integración con Adaptadores
Modulo 8: Creación de Orquestaciones en BizTalk
Modulo 9: Automatización de Procesos de Negocio
Modulo 10: Creación de Procesos de Negocio Transaccionales
Modulo 11: Desplegando y Gestionando Aplicaciones BizTalk
Modulo 12: Integración con Web Services
Modulo 13: Integración con Reglas de Negocio
Modulo 14: Monitorizando Actividades de Negocio
Modulo 15: Integración con Partners Comerciales
Un saludo.
Miguel.
[?]
01.16.09
Tarpipe, Flujos de Trabajo para el Tiempo de Ocio
En http://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
Un BPM para el tiempo libre
Cuanto menos curioso!
http://www.genbeta.com/2009/01/11-tartipe-publicaciones-mediante-flujos-de-trabajo
Saludos.
[?]
01.14.09
Google PageRank = 4
Hola a todos,
Interesantísima buena noticia, esta semana el blog ha pasado de estar valorado con un PageRank 3 a estarlo con 4.
Muchísimas gracias a todos por visitar los artículos, la mejor noticia para mi es saber que a alguien le puedan ser útiles todas las referencias que se van incluyendo, y a cuantos más sea, mejor
Abrazos!
Miguel.
[?]
01.05.09
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!
[?]