Monitoreo de Eventos de Granularidad Fina en Procesos de Negocio

Transcripción

1 Monitoreo de Eventos de Granularidad Fina en Procesos de Negocio Luis Felipe Criales Tovar y Oscar Fernando González Rojas Departamento de Ingeniería de Sistemas y Computación Universidad de los Andes, Colombia Carrera 1 No 18 A 10, Bogotá , Colombia {l-criale, o-gonza1}@uniandes.edu.co Resumen. El análisis de procesos de negocio permite evaluar la eficiencia de los procesos, a través de este análisis se logra un mejor entendimiento de los procesos. Esto cobra especial importancia para la toma de decisiones de negocio y mejora de los mismos. Los datos asociados a un proceso de negocio son una parte fundamental para medir el desempeño de los del negocio. En estos términos, este artículo presenta una propuesta para interceptar eventos relacionados con las interacciones efectuadas por elementos de un proceso de negocio sobre sus datos asociados. Dicho proceso de negocio está definido sobre un lenguaje de workflow. Adicionalmente, este artículo discute las limitaciones de los lenguajes de definición de procesos para interceptar eventos de granularidad fina sobre los datos. Palabras clave: Ingeniería de software, procesos de negocio, gestión de procesos de negocio (BPM), granularidad fina, anotaciones en java, lenguajes de aspectos. 1 Introducción Los procesos de negocio son un conjunto de actividades o tareas relacionadas entre sí. Dichas actividades utilizan recursos con el fin de transformar las entradas en un producto o servicio, el cual crea un valor al negocio. La gestión de procesos de negocio se crea por la necesidad de las organizaciones de optimizar los procesos. Algunas organizaciones definen sus procesos en un lenguaje de workflow porque permite de manera sistemática modelar, ejecutar y analizar los procesos. La gestión de procesos de negocio (BPM por sus siglas en inglés) [1] brinda una estructura tecnológica para el diseño de procesos de negocio mediante la ejecución automatizada de decisiones y tareas bien definidas. En esta gestión de procesos resulta vital considerar el análisis de procesos de negocio (BPA de sus siglas en inglés) [2], dado que éste provee una idea de cómo funcionan los procesos dentro de una organización. Este análisis permite a las organizaciones medir el desempeño de sus procesos para tomar decisiones de manera oportuna con el propósito de mejorarlos.

2 Durante la implementación de un proceso de negocio es deseable el uso de un framework porque facilita la definición del mismo en todo nivel. Esto se debe a que el framework provee un conjunto de herramientas que permiten el diseño, ejecución y monitoreo de un proceso de negocio. Uno de los frameworks existentes en la actualidad es JBoss jbpm [3], el cual es un framework de código abierto implementado en Java que permite definir procesos de negocio en un lenguaje de workflow [4]. El objetivo de JBoss jbpm es permitir a las organizaciones crear y automatizar sus procesos de negocio con miras a coordinar personas, aplicaciones, recursos y servicios [5]. jbpm cuenta con un lenguaje de definición de procesos llamado jpdl [6], este lenguaje permite definir procesos de negocio de manera intuitiva por medio de una interfaz gráfica basada en el entorno de desarrollo Eclipse [7]. Este lenguaje está implementado en Java, lo que facilita la integración con aplicaciones y librerías escritas en Java. Adicionalmente, jbpm está en la capacidad de ejecutar procesos de negocio definidos en el lenguaje BPEL [8]. La definición de procesos de negocio por medio del lenguaje jpdl tiene limitaciones claras con respecto al manejo de eventos relacionados con los datos de un proceso. El lenguaje no contempla manejo de eventos en términos de los datos; por ejemplo, la asignación de un valor a un dato que modela un proceso de negocio. Sin embargo sí se consideran el manejo de eventos relacionados con tareas, excepciones y nodos. Los eventos relacionados con la interacción de los datos resultan valiosos para la toma de decisiones por parte de la alta gerencia. Por ejemplo, Trouble Ticket [9] es un proceso usado por las organizaciones para realizar la detección, seguimiento, notificación y solución de algún tipo de problema. En este proceso se asignan los problemas a un experto. La información de la asignación del experto se guarda como un dato durante la ejecución del proceso. Para una organización puede resultar crítico el monitoreo del dato del experto por razones particulares del negocio. Como resultado de que el lenguaje no permita definir tipos de eventos sobre los datos críticos para el monitoreo, es necesario definir una estrategia adicional para el manejo de dichos eventos. El lenguaje no permite manejar eventos de granularidad fina [10] sobre de los datos que modelan un proceso de negocio. Granularidad fina se refiere al nivel de detalle del código de programación bajo un contexto específico. En este documento se define la arquitectura general de la solución. Dicha solución se soporta en diferentes alternativas tecnológicas las cuales permiten implementar la solución. Par estos fines, este artículo se divide en nueve secciones. Inicialmente se procede a contextualizar y plantear las definiciones básicas del proceso Trouble Ticket y sus etapas. Posteriormente, se definen los alcances y limites del problema, así como la motivación para resolver éste. En este orden de ideas, se formula una solución al problema y se presentan los resultados derivados de la implementación de la solución. Seguidamente, se enuncian los trabajos relacionados que resultan relevantes; de la misma manera se exponen las potenciales mejoras a la solución implementada. Finalmente, se presentan las conclusiones finales derivadas de la elaboración del trabajo.

3 2 Contexto El grupo de investigación Qualdev [11] en la actualidad está desarrollando un proyecto el cual tiene como propósito crear una plataforma para la medición y el análisis de procesos de negocio a un alto nivel de abstracción. El proyecto BPA [12] (Business Process Analisys) está dividido en diferentes sub-proyectos debido a su tamaño y complejidad. El proyecto BPA Data Centric se tiene como objetivo instrumentar procesos de negocio, definidos en el lenguaje jpdl, para lograr interceptar eventos relacionados con los datos del proceso. Este proyecto pretende diseñar una solución informática para solucionar el problema mencionado anteriormente. A continuación se mostrará el escenario específico de validación de la solución, el cual consiste en un proceso de negocio llamado Trouble Ticket. Posteriormente, se explicará en qué consiste el problema identificado y un requerimiento específico sobre el caso de estudio del proceso. 2.1 Proceso Trouble Ticket Trouble Ticket es un proceso de negocio propuesto por Nortel y la Universidad de Newcastle upon Tyne [13] el cual tiene como objetivo garantizar la calidad del servicio al cliente. Este es un proceso típico dentro de las organizaciones que tienen departamentos dedicados de manera fundamental a prestar las funciones de de servicio a los clientes. Con el propósito de entender mejor el proceso, a continuación se presenta un diagrama del proceso en notación para el modelado de procesos de negocio. Fig. 1. Diagrama del proceso Trouble Ticket. En la figura 1, el círculo con línea más delgada indica el inicio del proceso, mientras el círculo con línea más gruesa indica el fin. El proceso se encuentra separado en los siguientes pasos:

4 Registro del problema. Éste puede iniciarse por un originador, que es un agente interno o externo a la organización. Si es interno, el proceso se inicia cuando el usuario alimenta los datos y radica el ticket. El sistema genera un número de referencia (ID) para rastrear el proceso en el futuro. Reproducir el problema y corregir el reporte. Esta es una actividad de verificación, donde se debe observar si el problema encaja o no un dentro de un problema previamente identificado y parametrizado, lo cual implica que sea reproducible. Si el problema no es identificado dentro los parámetros de un problema reproducible, se corrige el reporte; de otro modo pasa a identificar el problema y la solución. Además de esto, si se tiene una solución conocida se procede directamente a comunicar los resultados; si se identifica como duplicado de otro problema, se guarda esta información y se verifica la solución. Si el problema no es reproducible, se debe acceder al originador para obtener más información o clarificación sobre el caso para corregir el reporte. Identificar el problema y la solución. Esta es la etapa donde se requiere de la actuación de un experto. Éste depura la información y obtiene únicamente datos relevantes; igualmente, ratifica o reasigna el reparto del problema al área que lo debe resolver. El experto identifica la solución a implementar. Posteriormente, el proceso le notifica al originador los resultados. Lo particular de este proceso es que existe un subproceso para solucionar el problema que la organización debe ejecutar, y éste depende de las condiciones propias del problema. Evidentemente, este subproceso debe ser diseñado por la organización con anterioridad. Este significa que el proceso de trouble ticket debe trasladar los datos relevantes en forma de campos al subproceso. Comunicar los resultados. Se le comunican los resultados al originador. Lo ideal es que esta actividad se ejecute en un máximo de tres días después de que el proceso inicia, si no es así, se le comunica a la persona encargada del proceso. 3. Motivación para resolver el problema En el análisis de procesos de negocio los datos juegan un papel fundamental ya que guardan la información más importante que modela o define un proceso de negocio. Además un proceso de negocio está definido en término de los nodos o elementos que

5 lo componen; por ejemplo en el proceso del Trouble Ticket algunos de los elementos son Registro del problema y Reproducir el problema y corregir el reporte. El monitoreo y análisis de procesos de negocio resulta vital para la gerencia en su proceso de toma de decisiones de manera eficaz y pronta. Los datos que contribuyen en la definición de un proceso de negocio son posteriormente elementos necesarios para monitorear el funcionamiento de dichos procesos; por ejemplo, el monitoreo del cambio del dato que contiene la información del experto en el proceso Trouble Ticket. Lograr una granularidad fina sobre los datos de un proceso es fundamental para tomar decisiones o simplemente para llevar un registro de las actividades críticas del proceso. El lenguaje de definición de procesos jpdl permite especificar eventos relacionados con los elementos de un proceso de negocio; por ejemplo, entrar o salir de un nodo, lo cual implica ejecutar código en Java para hacer acciones adicionales antes o después de que se ejecute un nodo en el proceso. Con el fin de lograr un buen análisis sobre un proceso de negocio, es necesario definir eventos que permitan guardar la información de las interacciones entre los datos y los elementos de un proceso. Dichas interacciones se dan cuando un dato es modificado por un elemento del proceso; para el caso particular del proceso del Trouble Ticket esto se presenta, por ejemplo, cuando el elemento Identificar el problema y la solución cambian el dato que guarda la información sobre un experto. De dichas interacciones del proceso se desea guardar la información relevante contenida en el dato y su cambio en el tiempo. Esta información relevante es: la información del valor anterior y posterior del dato. Además de esto, se quiere guardar otra información relevante como el elemento que cambio la información del dato y además el momento exacto cuando ocurrió dicho cambio. A manera ilustrativa, continuando con el ejemplo de la reasignación del experto en el proceso de Trouble Ticket, se debe guardar la información del experto antes y después de la reasignación, además del elemento particular del proceso que lo modificó. Para poder resolver este requerimiento de análisis sobre los datos es necesario implementar una solución que no está incluida dentro de las herramientas que el lenguaje de definición de proceso jdpl provee. Esto surge de la limitación de que el lenguaje sólo permite manejar eventos de granularidad gruesa sobre los datos que modelan un proceso de negocio. Es decir, el lenguaje no permite definir eventos de granularidad fina sobre los datos. Granularidad fina se refiere a un nivel de detalle más alto sobre los eventos relacionados con los datos. Granularidad gruesa es lo opuesto, es decir, un nivel de detalle bajo. Por ejemplo, en el proceso Trouble Ticket se puede definir el dato que modela el experto. Sin embargo, no se puede definir cuando un dato es modificado, consultado o creado. 4. Problema Los eventos que pueden definirse usando jpdl tienen como fin el monitoreo del proceso de negocio; no obstante, para tener un mayor control sobre el proceso es necesario observar eventos relacionados con los datos del proceso, los cuales son

6 críticos para tomar decisiones por parte de la alta gerencia de una organización. Estos eventos deben tener una granularidad fina, la cual no es posible implementar con el uso del lenguaje jpdl. La granularidad fina sobre los eventos se refiere específicamente al valor de los datos que definen el proceso antes y después de que sean modificados o consultados dentro de la ejecución del mismo, por ejemplo el valor del dato que guarda la información del experto en el proceso Trouble Ticket. En este sentido, el problema en general consiste en que el lenguaje jpdl no permite la interceptar eventos de granularidad fina en la ejecución del proceso; más específicamente, eventos relacionados con la interacción de los datos y los elementos que definen un proceso de negocio, por ejemplo el lenguaje no permite definir eventos sobre el dato del experto en el proceso de Trouble Ticket. Para ilustrar el problema, se debe introducir un requerimiento específico de análisis sobre el caso de estudio del proceso de Trouble Ticket, el cual permite entender el problema y el porqué de su solución no se puede lograr con las herramientas que provee el lenguaje jpdl como la definición de eventos para los nodos. Adicionalmente, se explica cuales son los retos que identificamos en el momento de implementar la solución usando las herramientas que provee el lenguaje Requerimiento de análisis Un ejemplo del tipo de requerimientos que requiere un analista de negocio relacionado a este proceso es el de controlar el número de problemas que son asignados a un experto, esto con el fin de determinar la cantidad de trabajo que tiene acumulado un experto en particular o simplemente para tener mayor control sobre el proceso. Para esto, debemos guardar la información de los expertos que están involucrados en la reasignación. Para soportar este requerimiento es necesario tener en cuenta las siguientes consideraciones: (1) En el proceso de trouble ticket los problemas son asignados a un área en particular según las características propias del problema. (2) Posteriormente, éstos son asignados a un experto el cual evalúa el problema para determinar si el mismo pertenece al área a la cual fueron asignados. Esto se debe a que en ocasiones los problemas son asignados a áreas a los cuales no pertenecen o sencillamente a un experto que no es el correcto para solucionarlo. (3) En caso de que un problema no se asigne al experto indicado, éste debe ser reasignado. Cuando los expertos evalúan el problema y consideran que ellos no son los indicados para solucionarlos están en la capacidad de reasignar el problema a otro experto. La reasignación de un experto es crítico para el análisis y monitoreo del proceso de Trouble Ticket. Para el análisis del proceso se espera guardar la información de los expertos involucrados en la reasignación. Es decir, resulta indispensable guardar la información del experto que tenía asignado el problema en primera instancia y además guardar la información del nuevo experto a quien el problema se asigno.

7 4.2. Conceptos importantes del lenguaje jpdl Para entender mejor los problemas para implementar el requerimiento se deben tener en cuenta las siguientes definiciones sobre elementos propios del lenguaje jpdl. Nodos: Los nodos son el elemento básico dentro de la definición de un proceso. Éstos pueden ser de diferentes tipos: de tareas, de decisión, entre otros. Un nodo en jpdl se modela con una caja. En esencia representa un estado dentro del proceso de negocio. Un ejemplo de un nodo en el proceso de Trouble Ticket es el registro del problema. Tareas: En el lenguaje jpdl una tarea es un nodo que tiene que ser ejecutado por un humano. Las tareas modeladas en el lenguaje tienen que estar asignadas a alguien en particular o un grupo de personas. Un ejemplo de una tarea en el proceso de Trouble Ticket es Reproducir el problema y corregir el reporte. Transiciones: Las transiciones especifican la ruta entre dos nodos. En el lenguaje se representan con una flecha que tiene un nodo origen y un nodo destino. Acciones: Las acciones son código en Java que se ejecutan por medio de la definición de eventos, por ejemplo, cuando se entra o sale de un nodo. Variables del proceso: Son un conjunto de datos que determinan el estado de una instancia dentro de la ejecución de un proceso de negocio. Por ejemplo, en el proceso de Trouble Ticket, se tiene una variable de proceso que guarda la información del experto al cual se le asigno el problema. Archivos asociados: Son archivos que ayudan a la ejecución de un proceso. Entre estos archivos asociados se encuentran librerías, páginas web y las clases que definen un proceso de negocio. Estas últimas se refieren a las clases que hacen la lógica del negocio detrás del proceso. Handlers: Clases escritas en Java encargadas de manejar la interacción entre el proceso y la persona que lo está ejecutando. Por ejemplo, en el proceso Trouble Ticket existe un handler para enviar un correo para informar los resultados después de iniciado el proceso. El lenguaje de definición de proceso jpdl ofrece diferentes mecanismos para el análisis y control de los procesos de negocio, entre ellos se encuentran los denominados handlers. Así por ejemplo, se puede definir un handler para manejar uno o un conjunto de nodos definidos en el proceso. El handler designado para el manejo de nodos administra diferentes tipos de eventos, concentrándose con especial atención en los puntos que anteceden y procesen la transición de un nodo a otro. Por ejemplo, con un handler se puede guardar información para auditoria. En la implementación que realizamos del proceso de Trouble Ticket en jpdl la información se guarda en variables del proceso las cuales posteriormente son persistidas en una base de datos. Por ejemplo, la información de un experto en el proceso de trouble ticket se guarda en un atributo de un objeto el cual representa una entidad del proceso. El lenguaje jpdl no permite definir eventos de un nivel de granularidad fina sobre los datos que definen el proceso, en este caso nos referimos a eventos que indiquen cambios en estos datos. Por lo tanto es necesario diseñar e implementar una solución que permita resolver requerimientos sobre los datos a un nivel de granularidad fina.

8 5. Propuesta para resolver el problema La propuesta se divide en tres etapas: 1) La primera consiste en un lenguaje para definir eventos relacionados con la interacción de los datos y los elementos de un proceso de negocio. 2) La segunda etapa consiste en la interpretación de los eventos definidos en la primera etapa. 3) La etapa final consiste en la persistencia misma de los eventos definidos, en esta etapa se persiste la información de los eventos generados en un log. A continuación se explican cada uno de las etapas Lenguaje para definición de eventos La definición de eventos se hace por medio de un lenguaje de anotaciones en Java [14] sobre las clases que modelan el proceso. Para el caso concreto del proceso Trouble Ticket existe una clase que modela la información sobre el problema. La clase en particular se llama Problema, esta tiene un atributo de guardar la información de un experto. En este tipo de clases es donde el administrador del proceso debe hacer las anotaciones para definir los eventos. El lenguaje de definición de eventos está montado sobre dos estructuras fundamentales para caracterizar un evento: la primera el tipo de evento que se quiere generar y la segunda el elemento o actor que dispara el evento generado. El actor hace referencia al elemento del proceso de negocio que dispara el evento, es decir, el elemento que directamente involucrado en la acción que tiene como resultado la generación del evento. La definición del actor, en nuestro lenguaje, restringe los elementos de negocio de interés que interactúan con los datos. El administrador del proceso puede definir cuál es el actor cuya interacción con el dato debe resultar en la producción de un evento. Por ejemplo, el actor en el caso de estudio del proceso de Trouble Ticket para el dato del experto es Identificar el problema y la solución, que es donde se puede reasignar el experto. En segundo término, se encuentran los tipos de eventos. Existen dos tipos de eventos que definimos para el alcance de este proyecto, los eventos de tipo SET y de tipo GET. Sin embargo para el futuro se pueden definir otros tipos de eventos que tengan que ver con un dato. A continuación se explican los dos tipos de eventos. Eventos de tipo SET Estos eventos los define el administrador del proceso en el caso que le interesa saber cuando el valor de un dato es asignado. Es decir, en cualquier momento durante la ejecución del proceso, el valor es asignado usando un nuevo valor y como resultado se produce un evento de tipo SET. Dichos eventos pueden ser generados por diferentes elementos del proceso, más sin embargo el administrador puede definir que solo se deben generar eventos de tipo SET para ciertos elementos, por esta razón definimos los actores, para evitar que elementos que no nos interesan generen eventos. Por ejemplo, en el proceso Trouble Ticket no se quiere generar un evento si el actor de la asignación del experto fue el actor del Registro del Problema.

9 Para entender más ampliamente este tipo de eventos, a continuación se presenta un ejemplo de cómo se define un evento SET. Continuando con el caso del estudio del proceso de Trouble Ticket, se quiere generar un evento de tipo SET sobre el dato llamado experto al cual se le asignó el problema. Este dato está definido como un atributo dentro de la clase Problema. Además se quiere definir que se produzca el evento sólo cuando el actor o elemento que asigna el valor del dato es Reasignar el problema. La figura 2 muestra cómo el administrador podría anotar la clase Problema para indicar interés en este evento. el problema", event=event.set) 2. private String experto; Fig. 2. Ejemplo eventos de tipo SET. En la figura 2, en la línea 1 se observa la anotación que define el evento de tipo SET para el actor Reasignar el problema. En la línea 2 se observa la declaración del atributo experto de la clase Problema. Eventos de tipo GET Estos eventos se definen cuando el administrador está interesado en qué se genere un evento cuándo un dato es consultado. Durante la ejecución de un proceso de negocio, los datos pueden ser consultados por los elementos del proceso, por ejemplo para el caso de estudio del proceso Trouble Ticket los elementos de Identificar el Problema y la Solución y Comunicar los Resultados consultan el dato del experto. Para el análisis de proceso es necesario en ocasiones identificar cuando y cuales elementos interactuaron con datos particulares del proceso. En este tipo de evento también se puede definir el elemento o actor que debe leer el dato para que se genere el evento, dado que muchos elementos pueden interactuar con un dato en particular. A continuación el ejemplo de un evento de tipo GET en el contexto del caso de estudio del proceso de Trouble Ticket. Supongamos que en este caso el administrador del proceso debe monitorear las consultas al dato que contiene la información del área a la cual un problema fue asignado, este dato está modelado en la clase Problema, adicionalmente quiere observar en particular cuando el elemento de Comunicar los resultados lo consulta. Para este caso se define el evento de la siguiente manera. los resultados", event=event.get) 2. private String area; Fig. 3. Ejemplo eventos de tipo GET. En la figura 3, en línea 1 se observa la anotación que define el evento de tipo Get para el actor Comunicar los resultados. En la línea 2 se observa la declaración del atributo área de la clase Problema.

10 5.2. Interpretación de los eventos definidos En esta etapa, implementamos un módulo encargado de interpretar los eventos que el administrador del proceso define sobre los datos, este módulo es llamado el Interpretador. Este módulo es el encargado de generar código para interceptar los eventos. Con este fin, el módulo lee las anotaciones que el administrador del proceso hace sobre los datos en las clases que modelan el proceso. Posteriormente el Interpretador genera el código de aspectos en el lenguaje AspectJ [15], este código permite interceptar los eventos que interfieren con los datos durante la ejecución. Para la implementación de este modulo decidimos usar el lenguaje de aspectos AspectJ. Este lenguaje permite desde el puto de vista tecnológico generar eventos sobre los datos particulares que definen un proceso de negocio. En esta etapa, usamos programación orientada a aspectos (AOP en sus siglas en inglés) [16] la cual permite la encapsulación de los diferentes conceptos que componen una aplicación en entidades bien definidas, con lo cual conseguimos eliminar las dependencias de los diferentes módulos. La decisión de usar programación orientada a aspectos se basa en que el módulo de Interpretación es externo a la definición del proceso de negocio, por lo tanto éste no interfiere con la definición del proceso. Es crítico para nuestra solución que el módulo de Interpretación no interfiera con la definición del proceso, esto para mantener una división de las responsabilidades entre la definición del proceso y nuestro módulo, además para no agregar complejidad innecesaria a la definición del proceso. Adicionalmente, logramos que la mantenibilidad del módulo ya que el administrador no necesita hacer modificaciones en la definición del proceso. En este sentido, si decidimos implementar un nuevo evento sobre los datos solo es necesario modificar el módulo de interpretación de eventos y el lenguaje de definición de eventos, con lo cual no es necesario modificar la definición del proceso. La implementación particular para la programación orientada a aspectos es el lenguaje AspectJ. La decisión de usar este lenguaje en particular responde a que éste está construido como una extensión del lenguaje de programación Java. Esto es fundamental debido a que la definición del proceso de negocio también está generada en código Java; y por lo tanto, resulta fácil la integración de los módulos con el servidor de aplicaciones, el cual está en la capacidad de ejecutar código Java Generación del código de Aspectos para interpretación de eventos La generación del código de aspectos es de vital importancia para la intercepción de los eventos asociados a los datos del proceso. El código generado por el Interpretador se separa en diferentes pasos (éstos se explican más adelante, con el fin de entender más fácilmente cual es el código generado). Para entender mejor el código que generamos es necesario entender los siguientes conceptos de programación orientada a aspectos para el lenguaje AspectJ: Aspectos [17]: Se definen como envoltorios de código, los cuales están asociados a muchas partes de un programa. Son muy similares a las clases Java. Joinpoints [17]: Puntos en el código Java dónde un aspecto puede interceptar a las clases.

11 Pointcut [17]: es un conjunto de Joinpoints concatenados lógicamente. Estos determinan dentro de un programa cuando un conjunto de líneas de código denominado Advice [17] se ejecuta. Esto permite al programador definir cuando y donde este código es ejecutado. En el pointcut habitualmente se define el nombre de la clase y el nombre del método que se quiere interceptar, sin embargo también se pueden definir por medio de expresiones regulares que definen patrones para las clases o métodos. Advice: Son un conjunto de instrucciones que se adicionan a la funcionalidad de una aplicación, estos están directamente asociados a un Pointcut. Estos insertan un nuevo comportamiento en todos los Jointpoints representados por el Pointcut. En los Advice es indispensable especificar cuando se deben ejecutar, es decir, se debe declarar si estos se ejecutan antes, después o durante la ejecución de la aplicación. Se presenta a continuación el código que generamos para el ejemplo del cambio del experto del caso de estudio del proceso de Trouble Ticket. Pointcut En la figura 4 se observa el Pointcut que generamos para la asignación o cambio del atributo experto de la clase Problema. Este pointcut corresponde al ejemplo de la anotación de la figura pointcut setexperto(string value) : 2. set( * Problema.experto) && args (value) Fig. 4. Ejemplo pointcut generado para eventos de tipo SET sobre el dato experto. En la figura 4, en la línea 1 se observa la declaración del pointcut con un valor de entrada. En la línea 2 definimos el evento para la asignación del atributo experto de la clase Problema. Advice Continuando con el caso del estudio de proceso del Trouble Ticket y con el requerimiento del cambio del experto del mismo. A continuación se presentan los advice necesarios para interceptar los valores del atributo del experto de la clase Problema antes y después de la ejecución de la asignación de un valor nuevo. Este ejemplo corresponde a la anotación del ejemplo de la figura before (String value) : setexperto(value){ 2. if(actor.equals(actor_experto)){ 3. Problema x = (Problema)thisJoinPoint.getThis(); 4. valuebeforesetexperto = x.getexperto (); 5. } 6. } 7. after (String value) : setexperto (value){ 8. if(actor.equals(actor_experto)){ 9. valueaftersetexperto = value; 10. savelog("set", "Experto"); 11. } 12. }

12 Fig. 5. Advice generado para el evento de tipo SET del dato experto. En la figura 5, en la línea 1 definimos un advice que se ejecuta antes de la invocación del Poincut de la asignación del atributo experto de la clase Problema. En la línea 7 definimos un advice que se ejecuta después de la invocación del Pointcut de asignación del atributo experto. En la línea 10 se persiste la información del evento que se generó Persistencia de eventos La Persistencia de eventos es el último módulo de la aplicación, este permite separar la lógica de la generación de eventos de su persistencia. Para el caso particular de esta aplicación implementamos un log encargado de persistir los eventos que se generan durante la ejecución de la aplicación. En dichos logs, se guarda la información de los eventos, tales como el actor o elemento que generó el evento, el dato involucrado en el evento y sus valores antes y después de la generación del evento. Además, el módulo guarda la información de la fecha y hora de la generación del evento. Para este módulo implementamos una clase en Java para guardar los eventos en un archivo, dicho archivo queda ubicado en el servidor donde se ejecuta el proceso. Para la implementación de la clase decidimos usar el estándar descrito por el API de Java; esta decisión se basa en que el modulo guarda los logs en el archivo en formato XML [18], con lo cual la lectura de los mismos se facilita porque existen diferentes tecnologías para este fin. 6. Resultados Definimos un lenguaje para caracterizar eventos relacionados con la interacción de los elementos de un proceso de negocio con los datos. Para la definición de estos eventos se utilizó la tecnología de anotaciones; esta resulta ser apropiada dado que permite al administrador de los procesos indicar cuáles son exactamente los datos que quiere observar, el tipo y el actor involucrado en el evento. Implementamos un interpretador del lenguaje; el interpretador es el encargado de generar el código necesario en aspectos para interceptar los eventos que interfieren sobre los datos. El interpretador utiliza plantillas con los aspectos para generar los aspectos específicos de la clase que contiene las anotaciones con los eventos. Finalmente implementamos un módulo encargado de persistir los eventos en un log. A continuación se exponen los diagramas más importantes que componen la solución propuesta.

13 6.1. Diagrama general de la solución La figura 6 presenta el diagrama general de la solución. En este diagrama se pueden ver los tres diferentes módulos que componen la aplicación. 1) El primer módulo es el encargado de la definición de los eventos por medio de anotaciones. 2) El segundo módulo es el Interpretador de los eventos el cual genera el código de los aspectos. 3) Finalmente, el tercer módulo, de Persistencia, se encarga de llevar un registro de los eventos. Fig. 6. Diagrama de componentes de la aplicación. El componente del Interpretador depende directamente del componente del lenguaje de definición de eventos. El Interpretador lee las anotaciones sobre los datos escritos por el administrador del proceso, a partir de estas anotaciones genera el código de aspectos que intercepta los eventos de la interacción de los datos con los elementos del proceso. Finalmente el componente Interpretador de eventos usa los servicios del componente de Persistencia Arquitectura de la aplicación La figura 7 muestra los componentes antes y durante ejecución que hacen parte de la solución completa, incluyendo el motor de procesos y la definición del proceso. En la parte izquierda de la figura 7 se aprecian los elementos o artefactos que interactúan en la ejecución de un proceso de negocio. En la parte derecha de la misma figura se observa los elementos que permiten definir un proceso de negocio, además de los elementos que ayudan a definir la intercepción de los datos. En el lado del servidor de la figura 7, se encuentran las clases compiladas en Java que incluyen los aspectos enfocados a generar los eventos definidos con el lenguaje propuesto. Además en la figura se observa el modulo de la Persistencia de eventos, este modulo fue implementado por nosotros. En el lado del cliente de la figura 7, se encuentra el proyecto que permite definir un proceso de negocio en un lenguaje de workflow, el cual no es implementado por nosotros. En dicho proyecto, el administrador del proceso incluye las anotaciones con los eventos sobre los datos, estas anotaciones están dentro de las clases en Java que modelan un proceso. Además en el proyecto el administrador del proyecto debe incluir el Interpretador de eventos, el cual fue implementado por nosotros.

14 Finalmente, el administrador del proceso debe incluir el compilador de AspectJ el cual permite generar las clases compiladas en java con los aspectos. Fig. 7. Diagrama de despliegue de la aplicación Diagrama de secuencia definición de un evento En la figura 8 se observa un diagrama de proceso en el cual se aprecia el flujo de los sucesos para la definición de un evento sobre un dato del proceso. En el primer paso el Administrador del proceso define un evento en una clase en Java del proceso, esto lo define con una anotación en Java usando nuestro lenguaje. En el segundo paso el administrador del proceso inicia el proceso de interpretar los eventos definidos en el paso anterior usando el componente Interpretador. En el tercer paso se recorren las clases del proyecto en busca de las anotaciones de eventos. Finalmente en el cuarto paso se genera cada uno de los aspectos que permite interceptar los eventos sobre los datos. Estos aspectos leen el valor del dato antes y después del evento, esta información es persistida usando los servicios del modulo de Persistencia. Fig. 8. Diagrama de proceso de la definición de un evento.

15 7. Trabajos relacionados Uno de los artículos más relacionados con el tema tratado en este documento es How Do I Model State? Let Me Count the Ways [19], el cual está dedicado a cómo definir las interacciones de las operaciones del estado de un servicio en una organización, con el estado se refieren específicamente al cambio del valor de los datos asociados a dichos servicios. Por lo tanto el propósito general del artículo es cómo implementar un servicio que permita modelar la interacción de los datos en un servicio. En el artículo presentan cuatro posibles maneras para modelar la interacción de los datos de un servicio. A continuación se enumeran cada una de los estilos expuestos en el artículo. 1. WS-RF (Web Service Resource Framework) [20]: Es un framework especificado por OASIS [21] en el cual se define como el estado de las aplicaciones se modela usando tecnologías de servicios web. En el framework se definen las operaciones que acceden o modifican el estado o valor de los datos en un servicio web. 2. WS-Transfer (Web Services Transfer) [22]: Es un estándar definido por un grupo liderado por Microsoft; en la actualidad está especificado como un estándar en la W3C (World Wide Web Consortium) [23]. En el estándar se especifica el mecanismo para acceder al estado de los archivos XML que usan los servicios web. 3. HHTP (Hypertext Transfer Protocol): Es el protocolo de transferencia de la web, el cual está especificado en una serie de RFC [24]. Este fue desarrollado por el consorcio W3C y IETF [25] (Internet Engineering Task Force). 4. Sin convenciones: Es la ultima manera de manejar el estado de las aplicaciones, en esta ultima no se tiene definido un estándar para manejar los datos. El manejo del estado se hace según el contexto de la aplicación y la semántica modifica o accede el estado de la aplicación. Se puede usar cualquier tipo de tecnología para implementar este estilo. Nuestra implementación se basa en el cuarto estilo. La principal ventaja que permite el último es que no se limita por el alcance de un estándar. Esto es crítico porque la definición de los procesos de negocio tienen características que impiden implementar la solución siguiendo un estándar. Por ejemplo la forma en cómo un proceso de negocio accede a los datos. 8. Trabajo Futuro La implementación actual del módulo de persistencia de eventos tiene muchas posibilidades de mejora que planteamos como trabajo futuro. Por ejemplo, es posible implementar un modulo que permita informar al administrador en tiempo real sobre eventos relacionados con los datos que permita tomar decisiones de manera oportuna. Para el alcance de este proyecto sólo se implementaron dos eventos, estos eventos son de tipo SET y GET. Por lo tanto planteamos como trabajo futuro la implementación de nuevos eventos sobre los datos. Por ejemplo, es posible implementar un evento cuando un dato es creado.

16 9. Conclusiones El lenguaje de definición de procesos de negocio jpdl no soporta la intercepción de las interacciones de los datos con los elementos que definen un proceso. La interacción de estos datos es fundamental para el análisis de procesos, porque permite a la alta gerencia de una organización tomar decisiones de manera oportuna. En este trabajo se logró definir un lenguaje de definición de eventos sobre los datos, el cual permite interceptar interacciones entre los elementos de un proceso de negocio y los datos. Además, presentamos la implementación de un generador de aspectos que permite instrumentar un proceso de negocio y generar eventos durante la ejecución del proceso. Finalmente se implementó un módulo para la persistencia de los eventos generados por el modulo de generación de eventos. Estas implementaciones permiten definir eventos de granularidad fina sobre los datos, los cuales son vitales para el análisis y el monitoreo de procesos de negocio. Agradecimientos Este proyecto se hizo bajo la asesoría de Nicolás López Giraldo y Rubby Casallas. Referencias 1. Matt Cumberlidge, Business Process Management with JBoss jbpm, A practical guide for Business Analysts: Develop business process models for implementation in a business process management system. Pack Publishing, Birmingham, Mumbai. July ISBN 13: Business Process Analysis, A recognized leader in Business Process Analysis. Casewise Ltd JBoss jbpm, Página principal Jeff Hanson, Manage your business processes with JBoss jbpm: Get started using JBoss's business process management tool. June JBoss jbpm Datasheet, April JBoss jbpm jpdl, Página principal Proyecto Eclipse, 8. BPEL Cookbook: Best Practices for SOA-based integration and composite applications development. Ten practical real-world case studies combining business process management and web services orchestration. Pack Publishing. July ISBN 13: Nortel supported by University of Newcastle upon Tyne, Workflow Scenario: Trouble Ticket. OMG Document Number bom/ Énfasis, Programación Orientada a Aspectos de Grano Fino. M. en C. Ulises Juárez Martínez. Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional de México. Octubre de 2008.

17 11. Grupo Qualdev Proyecto Business Process Analysis (BPA). Página principal del proyecto. ing:processmodeling 13. Nortel y la Universidad de Newcastle upon Tyne, Revised Submission for Workflow Management Facility Specification, OMG Document bom/ Java Annotations. Sun Microsystem, Inc Rusell Miles. AspectJ Cookbook. Aspect Oriented Solutions to Real-World Problems. O Reilly. December ISBN 13: Colyer, Adrian. Eclipse Aspectj : aspect-oriented programming with Aspectj and the Eclipse Aspectj development tools ISBN: Laddad, Ramnivas. AspectJ in action: practical aspect-oriented programming ISBN: Erik T. Ray. Learning XML. Second Edition. O Reilly. Sep ISBN-13: Ian Foster, Savas Parastatidis, Paul Watson, Mark McKeown. How Do I Model State? Let Me Count the Ways. Queue Volume 7, Issue 2. Feb ISSN: OASIS Web Service Resources 1.2, WS-Resources. OASIS Standard. 1 April OASIS, página principal Web Service Transfer, WS-Transfer. W3C Member Submission 27. September World Wide Web Consortium, página principal Request For Comments, página principal The Internet Engineering Task Force, página principal.