Miguel Matas Blog

Ingeniería y Arquitectura de Software, Proyectos IT, Programación, Personas, Problemas, Mejora Continua, la vida.

Archive for the 'InfoPath' Category

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 comments

Introduciendo InfoPath

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.

InfoPath

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.

10 comments