09.01.08
Posted in AgilePoint, BPM at 7:47 am by Miguel
Como hemos hablado en anteriores artículos, “WorkToPerform” es una de las propiedades que definen algunos tipos de actividad de AgilePoint (como por ejemplo las actividades “Manual” y “Manual with TimeOut”).
En esta propiedad definimos cuál es el trabajo a realizar. A niveles prácticos el trabajo a realizar se resume en un interfaz gráfica que va a ser la encargada de transmitirnos cuál va a ser el siguiente paso en el flujo y de almacenar cierta información de negocio que maneje nuestra propia aplicación. Resumiendo, “WorKToPerform” es nuestro link entre la actividad del flujo y la capa de presentación.
El típico ejemplo de uso de “WorkToPerform” sería por ejemplo definir que en la actividad “Aprobar Compra” el “WorkToPerform” a realizar sería “Aprobar”. Esto se traduciría en que vamos a necesitar en nuestra aplicación (pongamos que es una aplicación web) un fichero “compra.jsp” o “compra.php” o “compra.aspx” que es el que visualizará el usuario y en el que nos aparecería un hipotético radiobutton que marca o “Aprobar” o “No Aprobar”.
WorkToPerform de un nivel
Hasta aquí va la cosa más o menos bien, tenemos una página web para cada acción a realizar y listo.
Vamos a complicar ahora un poco más la cosa y vamos a suponer que debido a requerimientos funcionales, nuestra actividad del flujo no viene representada por un único aspx, si no que puede ser representada por varios ascx (controles de usuario ASP.NET), y vamos a complicarlo un poco más aún, que dichos ascx deberían poder cargarse en diferentes paneles ubicados en un aspx concreto.
Página con varios paneles contenedores
¿Cómo podríamos resolver este problema mediante el uso de “WorkToPerform”? Pues tal vez pudiéramos hacer algo similar a esto:
PanelConfirmaciones:Confirmacion1,Confirmacion2//PanelNegocio:Negocio3,Negocio4
WorkToPerform Multi-Nivel
Analizando un poco la estructura podremos ver que lo que acabamos de hacer es definir en qué panel vamos a cargar una serie de controles ascx. Por lo que necesitamos tener en nuestra aplicación una carpeta con los siguientes ficheros: Confirmacion1.ascx, Confirmacion2.ascx, Negocio3.ascx y Negocio4.ascx.
Ahora lo que queda es que en nuestra capa cliente, cuando recibamos la información relacionada a la actividad, capturemos su “WorkToPerform” y lo interpretemos a la hora de cargar la página para cargar los ascx definidos de forma dinámica.
Fantástico, de esta forma tan sencilla hemos conseguido definir un sistema que permite trabajar a múltiples niveles (imaginaros por ejemplo que pueden existir diferentes paneles cargados en diferentes pestañas de un control de tabuladores)
Saludos.
Miguel.
Permalink
08.20.08
Posted in AgilePoint, BPM at 10:04 am by Miguel
Siguiendo con las actividades de AgilePoint, hoy vamos a ver la actividad WebService.
La finalidad, es clara, llamar en un momento dado a un servicio web para realizar una actualización en un sistema remoto, o para incorporar información que retorne el servicio web a nuestro proceso.
Tanto la actividad WebService, como la actividad E-Mail (de la que hablamos ayer) son actividades automáticas, que no necesitan actividad humana relacionada. Una vez se llega a ese punto del flujo se ejecutan y una vez ejecutadas el flujo continúa al siguiente paso de manera automática. Este es el mismo comportamiento que siguen los AgileParts, los cuales veremos en próximas entregas.
A continuación la paleta de propiedades de la Actividad WebService:
AgilePoint, Actividad WebService
Destacamos la obvia posibilidad de indicar tanto las credenciales, proxy, timeout… valores típicos para la llamada a un servicio web. Disponemos también de la posibilidad de realizar un envío de email automático al entrar en la actividad y al salir (para indicar algún tipo de aviso o saber si ha ocurrido algún error)…
Una nueva categoría que aparece en las propiedades y que es común a muchas de las actividades automáticas, es la categoría “Status and Error Message”. En las propiedades de dicha categoría, en el caso de que se produzca un error se va a indicar en ellas. Como supondréis, si luego tratáis en el flujo las propiedades $ErrorMessage y $Success, podréis manejar las condiciones y el resultado final del flujo.
Pero una de las piezas fundamentales que nos queda aquí para definir es cuál es la URL donde se encuentra alojado el servicio y cuál es en concreto el método que vamos a llamar. Para ello debemos hacer click en la propiedad “Configure”, y a continuación nos aparecerá la siguiente pantalla emergente:
AgilePoint, Actividad WebService, Definiendo la Conexión
En la zona superior disponemos de la capacidad de señalar una URL para poder cargar el listado de métodos y seleccionar uno en concreto. En la zona inferior tenemos una casilla donde indicamos la URL a la que llamará el proceso en el momento de ejecutar la llamada. En un principio parece no tener mucho sentido esto último ya que aparentemente estamos duplicando el trabajo, pero, la razón de hacerlo así, es que en la zona inferior vamos a poder definir una variable del tipo $URLServicioWeb, para que así podamos definir “desde fuera” en un momento dado cuál es la URL que aloja el servicio web en un entorno de trabajo en concreto. Este es un punto donde las “Propiedades Globales” entran en juego, las propiedades globales se definen desde el Enterprise Manager y aplican en cualquier plantilla disponible en el servidor (las veremos más adelante).
Por último me gustaría que os fijarais en la última captura de pantalla que he incorporado, donde se ve que hemos llamado a uno de los servicios web que provee el propio AgilePoint para poder manejar los procesos y plantillas. La pestaña de valores que retorna el servicio web es la que está marcada, y como véis todos los valores que retorna tienen el símbolo del dolar delante. Esto quiere decir, que a partir de la ejecución de la actividad, todos estos valores van a estar disponibles en el flujo, y que en cualquier momento los váis a poder utilizar para tomar decisiones o para almacenar información. Lo mismo ocurre en los parámetros de entrada del flujo (aunque no se vean en la pantalla) si los tenéis “definidos” y escritos antes, automáticamente se llamará al servicio web pasándole vuestros valores. Muy, muy interesante este uso.
Saludos.
Miguel.
Permalink
08.19.08
Posted in AgilePoint, BPM at 8:33 am by Miguel
El mundo de las propiedades en AgilePoint es parte de la potencia que ofrece el producto. Para dejar un ejemplo claro de su uso, sin sin irme demasiado por las ramas, voy a apoyarme en la Actividad E-Mail, disponible en el Stencil Generic BPM de Envision.
Como supondréis, el fin de la actividad e-mail es el de, en un momento dado, enviar un correo electrónico a una dirección de e-mail determinada. Propiedades como Audit Level y Wait All Incoming las hemos visto ya en anteriores artículos (aunque a Wait All Incoming vamos a dedicarle una entrada por separado para avanzar un poco más su funcionamiento). En cuanto a la propiedad “Deferred Time” va a permitirnos enviar un e-mail en “diferido”, es decir, el envío puede no realizarse justo al ejecutarse la actividad, si no en un momento dado que definamos, más adelante en el tiempo.
Actividad E-Mail
Otras de las propiedades de la Actividad E-Mail son, dentro de la categoría “Notification” la propiedad “Email”, al desplegarla y seleccionando la opción “Add Template”, nos aparece el formulario inferior.
Actividad E-Mail, definición de la plantilla del e-mail
Rellenando los valores del formulario podréis observar que hay algunos que están dispuestos con el símbolo del dolar como prefijo, los valores con el dólar delante son las llamadas propiedades de plantilla. Estos valores, son variables que pueden ir cambiado a medida que el flujo de trabajo va avanzando. La gran ventaja que dispone Envision, es que en cualquier punto vamos a poder añadir una variable de plantilla, como véis en el ejemplo, en las cláusulas from y to, así como en el cuerpo del mensaje la estamos utilizando. También podemos utilizar dichas variables en las propiedades de la Actividad Manual con TimeOut (que ya hemos visto), asignándole a la propiedad Participants el valor “$usuario”. Lo único que quedaría en este último caso, es en algún punto establecer el valor de la propiedad $usuario.
No vamos a necesitar ni definir ni inicializar los valores en ningún punto. No contamos con un listado de propiedades de la plantilla, a la hora de compilar la plantilla no va a hacer ninguna comprobación al respecto. Si a la hora de aplicar el valor de la propiedad, esta no tiene, retornará un valor nulo, y punto. Por ejemplo, si asignamos a una actividad de condición simple (las veremos más adelante) una variable y dicha variable no tiene valor, retornará siempre falso.
El establecimiento de los valores de una propiedad puede llevarse a cabo de diferentes maneras, por ejemplo, tras un cálculo realizado por una actividad automática (como la llamada a un servicio web por ejemplo, lo veremos más adelante), al realizarse la instancia de una plantilla (creando un proceso), o llamada a un proceso en concreto a través de un servicio web de AgilePoint y estableciendo los valores.
Saludos.
Miguel.
Permalink
08.17.08
Posted in AgilePoint, BPM, InfoPath at 8:32 pm by Miguel
Siguiendo con AgilePoint, hoy empezamos con un flujo sencillo definido a través de la herramienta Envision (visio + plugin de ascentn), en donde podemos empezar a ver las primeras actividades (shapes) existentes en la paletas (stencils) de Envision.
AgilePoint + Envision
En primer lugar, un resumen a alto nivel de la herramienta. Para los que estéis acostumbrados a trabajar con Visio os va a sonar prácticamente todo, menos algunos iconos de la barra de herramientas que ubicados en la fila inferior derecha, que son propios de AgilePoint (los veremos en su momento). Otro de los temas que os pueden llamar la atención, es la ventana de propiedades de la zona derecha, más que de Visio, parece sacada de un entorno de desarrollo como Visual Studio. A la izquierda, las paletas de Visio (Stencils), que contienen figuras (las actividades de AgilePoint), que tampoco os sonarán, pero que iremos viendo poco a poco. En el centro, el flujo de trabajo que se ha diseñado (Plantillas/Templates en AgilePoint).
Empezando por la plantilla (vamos a empezar ya a utilizar vocabulario AgilePoint), un flujo sencillo donde participan diferentes actividades de diversa índole.
- Actividad Start: Marca el inicio del flujo a seguir. Sólo puede haber uno por plantilla.
- Actividad Stop: Marca el fin del flujo a seguir. Sólo puede haber uno por plantilla.
- Actividad Subrutina: Corresponde al texto “Notificación”. Una actividad de subrutina representa la llamada a otra plantilla. Una curiosidad al respecto de AgilePoint es que una de las propiedades de la actividad de subrutina define que puede llamarse de forma síncrona o asíncrona, es decir, que cuando se entre en la subrutina se va a esperar en el flujo padre a que termine su hijo, o que se va a lanzar la subrutina hija y el flujo padre va a continuar también al mismo tiempo, respectivamente. Veremos esta actividad más afondo en próximos artículos.
- Actividad Servicio Web: Realiza una llamada a un servicio web determinado, veremos esta actividad más afondo en próximos artículos.
- Actividad Envío de E-Mail: Envía un email a un conjunto de recipientes determinados. Veremos esta actividad más afondo en próximos artículos.
- Actividad Condición Única: Evalúa condiciones de un estado, tipo verdadero y falso. Veremos las condiciones también en próximos artículos.
Actividad Manual y Actividad Manual con TimeOut
La actividad manual es una de las actividades básicas que a priori se van a utilizar más en un desarrollo. Representa una actividad que va a necesitar una intervención humana para ser llevada a cabo. ¿Qué tipo de intervención? Pues ninguna en concreto, representa cualquier tipo de intervención que se quiera realizar. Cuando empecemos a describir las propiedades una a una, veremos donde marcamos cuál es en concreto el trabajo a realizar.
La Actividad Manual con TimeOut funciona como una Actividad Manual, pero incorpora una nueva salida relacionada con un temporizador. En el caso de que la tarea se procese dentro del tiempo estimado, saldremos por un lado, si el tiempo se cumple saldremos por el otro (la salida de la línea roja en la plantilla del ejemplo). La ventaja de esta actividad es que podemos relacionar un comportamiento u otro dependiendo de este temporizador.
A continuación, tenéis la paleta de propiedades asociada a la Actividad Manual con TimeOut. Vamos a ir exáminando alguna de ellas.
Empezando por arriba, tenemos las propiedades englobas en “Time Span”. Aquí es donde podemos definir cuál es el espacio emporal asociado al temporizador que activa la salida roja. Definimos la unidad de tiempo y el valor de dicha unidad. Algo a resaltar también es la propiedad “Business Time”. Si la dejamos en “false” se atenderá a días naturales, si la dejamos a “true” seguirá el calendario laboral que se haya definido en el panel de administración base de AgilePoint (lo veremos en próximas entregas).
La propiedad “Work To Perform” es la propiedad principal de este tipo de actividad, ya que es la que define realmente qué trabajo se debe realizar. “Work To Perform” es el enlace entre el motor de flujo y la capa de presentación, a través del valor que indiquemos aquí se podrá establecer con la aplicación de presentación de turno que utilicemos, el aspecto visual a mostar. Por poner un ejemplo, si hubiéramos creado la plantilla de Agilepoint indicando que usará soporte Infopath (veremos como en otros posts), en el “Work To Perform” nos hubiera dejado elegir entre una de las vistas disponibles en el archivo de InfoPath asociado. En el caso de no trabajar con InfoPath para la capa de presentación si no con una aplicación ASP.NET, el “Work To Perform” podría asociarse al nombre de la página “aspx” donde se pediría al usuario la información asociada a la actividad. Un ejemplo de esto último, si tenemos una actividad manual que tiene un “Work To Perform” llamado “Firmar”, en nuestra capa de presentación web necesitaríamos un archivo en la raíz de la aplicación llamado “Firmar.aspx, Firmar.jsp, Firmar.html…”. En dicha página se encontrarían representadas las reglas de negocio asociadas a la actividad definida en la plantilla.
En la categoría “Notificación”, se representan los diferentes estados en los cuales podríamos enviar un e-mail de forma automática: al crearse la tarea asociada a la activida, al cerrarse, al reasignarse…
Categoría “Participantes”, muy interesante también. La propiedad “Participants” define a qué usuarios se van a asignar las tareas surgidas de la actividad. Se puede definir de varias maneras, mediante una variable (el uso de variables más adelante lo veremos también), o seleccionando directamente un usuario, grupo o rol definidos en el propio AgilePoint (otro tema más a ver en capítulos posteriores). Junto a la propiedad “Participants” tenemos “Max. Participants”, que define cuántos usuarios como mucho tendrán acceso a la actividad. Por defecto es uno, por lo que al alcanzarse esta actividad en el flujo se generaría una tarea para el usuario en concreto marcado como participante, o como máximo a un usuario del grupo o rol asignado como participante. En el caso de asignar como participante a un grupo de 5 usuarios y poner la variable “Max. Participants” a 3, se generarían 3 tareas como máximo asociadas a la actividad, con el mismo “Work To Perform” accesible a los tres.
En la categoría “Avanzadas”, se agrupan las siguientes propiedades:
- Audit Level: Indica el nivel de auditoría, dependiendo de si seleccionamos “High” o “Low” almacenarán más o menos información en las tablas internas de históricos de uso con información asociada al proceso (instancia de la plantilla)
- Auto Complete: Si es “true” la actividad se completará de forma automática una vez lleguemos a ella (se suele utilizar en tareas que se encuentran en el primer lugar de ejecución en la plantilla)
- Reuse Participant: En el caso de que tengamos un bucle, y volvamos a pasar por la misma actividad más de una vez, en el caso de que la actividad tenga asociado un grupo, la tarea creada se asignará al mismo usuario del grupo al que se le asignó inicialmente.
- Wait All Incoming: En el caso de que tengamos más de una entrada sobre la misma actividad, indica si se debe esperar a que lleguen todas para continuar o no. Esta propiedad la veremos más a fondo próximamente.
- Wait Work Performed: Define si la tarea necesita implícitamente validar cierta información de negocio o de condiciones del flujo. Por ejemplo, el cálculo de una factura puede necesitar validar información de negocio, en cambio, indicar que se ha recibido una documentación no. Veremos más adelante un ejemplo bastante claro de esto, cuando hablemos de “Bandejas de Tareas”.
Próximamente más artículos relacionados con AgilePoint.
Saludos.
Miguel.
Permalink
08.07.08
Posted in AgilePoint, BPM at 10:53 pm by Miguel
A la hora de trabajar con motores de flujo la forma natural de trabajar suele seguir los siguientes pasos:
1) Los flujos se definen, modelando el area de negocio a controlar, y se publican en el motor flujo.
2) Una vez publicados los flujos, se instancian, lo que eran definiciones iniciales pasan a tener ya vida propia, y las primeras tareas caen en las bandejas de los usuarios.
3) Las mejoras en los procesos de negocio llevan a que se produzcan mejoras en los flujos ya modelados y que se generen nuevas versiones.
4) La nueva versión del proceso de negocio se sube al servidor y pasa a ser también instanciada. Las instancias anteriores siguen en marcha siguiendo el patrón anterior, las nuevas se harán a través de la nueva definición.
¿Pero qué pasa si queremos modificar la versión de un flujo que ya está intanciado y actualizarlo a la última versión? AgilePoint, provee una opción desde el Enterprise Manager para que se puedan migrar los Procesos (en AgilePoint definición de flujo = Plantilla, instancia de plantilla = Proceso) a una versión determinada (tanto anterior como posterior).
Eso sí, cuidadín con los usos. No es lo mismo cambiar de versión un flujo instanciado para modificar el usuario que era responsable de una actividad determinada, o para añadir una opción nueva a una condición, que para modificar el 50% de la forma del flujo. Como siempre, todas las herramientas que son para hacer Merges, hay que tratarlas con sumo cuidado.
De todas maneras, la funcionalidad queda aquí. Versiones de plantillas que se pasan a producción y que en un momento dado pasan a estar instanciadas, podría llegar a conseguirse solucionar problemas de definición cambiando la versión de dichas instancias.
Saludos.
Miguel.
Permalink
08.04.08
Posted in BPM at 7:52 am by Miguel
Un link interesante para los interesados en conocer las últimas noticias al respecto de los sistemas BPM
http://www.bpm-spain.com/
Saludos.
Miguel.
Permalink
08.03.08
Posted in AgilePoint, BPM at 4:05 pm by Miguel
Uno de los mayores valores añadidos de AgilePoint es la capacidad de extensión que provee a los desarrolladores. No se parte de un producto cerrado a partir del cual nos las tengamos que arreglar con lo que hay, si no que se parte de una base suficiente y provee además de un entorno de desarrollo para aumentar las capacidades base.
Como entorno de desarrollo para obtener la extensibilidad, más fácil imposible, Visual Studio 2005 (en septiembre cuando salga a la luz la versión 5 de AgilePoint estará disponible también la posibilidad de trabajar con Visual Studio 2008). Cualquier desarrollador con conocimientos del Framework de .NET y de C# o VB.NET podrá aprovechar las capacidades de extensibilidad de AgilePoint.
Aprovecho para lanzar palabras clave de las cuales nos vamos a tener que empezar a familiarizar
- AgileWorks: Actividades manuales reutilizables en los flujos.
- AgileParts: Actividades automáticas reutilizables en los flujos.
- AgileConnector: Ideado para facilitar las conexiones entre AgilePoint y otros sistemas.
Estas son las tres herramientas básicas de extensibilidad de AgilePoint, enfocadas cada una de ellas a resolver una problemática en concreto.
Las iremos viendo poco a poco en sucesivos artículos.
Saludos.
Miguel.
Permalink
07.28.08
Posted in AgilePoint, BPM, Herramientas, InfoPath at 7:38 am by Miguel
Microsoft InfoPath (evolución de XDocs), definida por algunos como la aplicación que venía incluida en el paquete de Microsoft Office 2003 y que nadie instalaba, y que si alguno decidía a instalar, tras diez minutos trabajando con ella se desinstalaba tras no entender muy bien qué partido se le podría sacar.
Dejando de lado las anécdotas, y como siempre, partiendo del concepto de reutilización, os dejo dos links para que os empecéis a hacer un poco a la idea de qué es InfoPath y para qué sirve.
Overview
Creando Formularios Inteligentes
Con InfoPath, mediante una sencilla interfaz gráfica pensada para personas de nivel de conocimientos medio permite la creación de formularios inteligentes de manera rápida.
Hasta aquí nada nuevo respecto a lo que conocíamos, aparenta ser una herramienta para crear pantallas con cierta lógica de comportamiento que intenta poner al alcance de personas no técnicas el desarrollo de interfaces de este tipo.
La cuestión es que la cosa no acaba aquí. La principal potencia de InfoPath es que al mismo tiempo que el usuario va definiendo de manera visual el formulario, por detrás se está generando una estructura xml que define la misma, incluyendo sus restricciones. Es decir, se está creando un schema que define la visualización y limita el tipo de dato que puede permanecer almacenado en cada uno de los campos que trabajamos.
Una vez llegados a este punto, la cosa cambia. A partir de esta estructura de plantilla pueden crearse ficheros con la información cumplimentada al rellenar el formulario y que respetarán 100% las limitaciones de lógica que este mismo provee.
Infopath pasa a ser entonces una herramienta interesantísima para almacenar información en formato xml. Es por ejemplo muy común que se utilice InfoPath para diseñar las interfaces gráficas de aplicaciones basadas en motores de flujo. En concreto con AgilePoint, mediante la combinación de AgilePoint+Sharepoint+InfoPath pueden lograrse resultados espectaculares en eficiencia en el diseño de aplicaciones basadas en flujos de trabajo.
Saludos.
Miguel.
Permalink
07.21.08
Posted in AgilePoint, BPM, Cursos at 6:45 pm by Miguel
Esta semana participo en un curso de formación de AgilePoint.
En cuanto al contenido:
Introducción a BPM
Desarrollar una solución en BPM
Elementos de AgilePoint
Ejemplos de Procesos
Administración
Enterprise Manager
Reporting
SharePoint Integration
SharePoint Document Library
InfoPath & SharePoint Form Library
WorkShop de Diseño de Procesos
AgilePoint Server API
Custom ASP.NET solution
Developing AgileParts
Developing AgileWorks
Developing AgileStubs
Developing AgileConnectors
Debugging
WorkShop de Desarrollo en AgilePoint
Y con el valor añadido de la participación de uno de los mentores de Solid Quality, en concreto, Daniel Seara.
Saludos.
Miguel.
Permalink
06.12.08
Posted in BPM at 7:54 am by Miguel
Muy interesante.
http://is.tm.tue.nl/research/patterns/
¿Permite el motor de flujo que utilizáis la implementación de todos estos patrones? Podría ser una forma de medir la potencia que os aporta en comparación a otros motores de flujo del mercado.
Saludos.
Miguel.
Permalink
« Previous Page — « Previous entries « Previous Page · Next Page » Next entries » — Next Page »
