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.

4 thoughts on “AgilePoint, un flujo sencillo y la primera actividad”

  1. Mi objetivo es, en la medida de lo posible, ir añadiendo contenido.
    Cualquier aportación, experiencia o apunte que podáis aportar, será más que bienvenido.
    Saludos.
    Miguel.

  2. Hola:
    Es posible que el campo de tiempo del manual timeout haga referencia al valor de un campo de infopath. Sino he pensado en utilizar primero un condicional para dividir el flujo y poner a la salida de esta dos actividades manuales de timeout con diferentes valores de tiempo de vencimiento. Se que funcionarí­a aunque preferirí­a hacerlo más elegante.
    Un saludo.

  3. Hola Santiago, en principio no deberí­a haber problema en asignar el valor de un campo de infopath a cualquiera de las propiedades de una tarea, en principio es parte del chiste.
    Una vez asignado el XSD que representa tu formulario xpath, deberí­as poder desde el visio al listado de las variables contenidas para poder asignárselas a cualquiera de sus propiedades.

Leave a Reply to Miguel Cancel reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.