Entorno Desarrollo AgilePoint

A continuación un simple ejemplo de lo que podrí­a ser un entorno de desarrollo para N desarrolladores trabajando conjuntamente en el desarrollo de un aplicativo sobre AgilePoint BPM, y con la gestión de código fuente de la aplicación mediante Team Foundation Server.
EntornoDesarrolloAgilePoint
El entorno del desarrollador que podrí­a distribuirse facilmente mediante máquinas virtuales, cuenta con todo lo necesario para la construcción. Visual Studio 2008 SP1 + Framework 3.5 SP1 para trabajar con las íºltimas versiones estables y consolidadas en el mercado de tecnologí­a .NET. En el caso de estar trabajando en el desarrollo de aplicaciones web, un IIS local donde desplegar las aplicaciones web y hacer las pertinentes pruebas de desarrollo y debugs. A Visual Studio se le incorpora el plugin AgilePoint Developer para el desarrollo a medida de nuevos AgileWorks, AgileParts y AgileConnectors. Finalmente se cuenta con la disponibilidad de Microsoft Visio 2007 más el plugin AgilePoint Envision, para el desarrollo en local de las plantillas (flujos de trabajo) de AgilePoint.
En el repositorio central se almacena todo el código fuente generado por los desarrolladores mediante el uso de Team Foundation Server, que garantiza la trazabilidad del código, gestión de versiones, etc; además de poder convertirse en una herramienta de gestión y control centralizado del trabajo asociado al desarrollador. Asignación de trabajo mediante el uso de Work Items, y el control de los bugs existentes en la aplicación son algunas de sus capacidades. Al mismo tiempo, mientras el uso de Sharepoint, permite crear fácilmente portales asociados a cada uno de los proyectos en desarrollo, donde el equipo de construcción puede compartir documentación de forma centralizada y todo tipo de información de gestión o técnica asociada a cada uno de los proyectos. Debemos tener en cuenta que este entorno deberá mantener también el control de versiones asociado a las plantillas de Visio que se vayan generando mediante NVision.
El entorno de desarrollo de Agilepoint, que centraliza tanto el AgilePoint Server, la gestión web del mismo a través del Enterprise Manager, y el interfaz de servicios web que permite gestionar de forma remota y transparente el acceso a las facilidades que provee el motor de Agilepoint.
Finalmente se expone un íºltimo entorno, representativo de cada tipo de aplicación, que no hace más que definir la posible existencia de un tercer entorno de integración, necesario para el desarrollo de la aplicación, como otros servicios de comunicación u otros aplicativos existentes en el sistema sobre los que nuestra aplicación en desarrollo deba integrarse.
Un saludo.
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.

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.

Novedades AgilePoint v4.5

Listo brevemente alguna de las incorporaciones en la nueva versión:
1) Compatibilidad con Visual Studio 2008
2) Compatibilidad con Framework 3.5
3) Compatibilidad con Windows 2008 Server
4) Nuevo AgileWork: Dynamic Group
5) AgilePoint DataServices (hablaremos de ellos)
6) Nueva herramienta para deploy de Plantillas, AgileWorks y AgileParts
7) Resolución de varios bugs conocidos.
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.

AgilePoint, Jugando con el WorkToPerform

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
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
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
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.

AgilePoint, Actividad WebService

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
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
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.

AgilePoint, Propiedades de Plantilla y Actividad E-Mail

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
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
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.

AgilePoint, un flujo sencillo y la primera actividad

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
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.
Actividad TimeOut
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.

AgilePoint, Migrando Procesos

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.