Modelado e implementación de un proceso de negocio BPM mediante herramientas SOA de software libre.

Transcripción

1 Modelado e implementación de un proceso de negocio BPM mediante herramientas SOA de software libre. Guía práctica Trabajo de grado: Modelado e implementación de un proceso de negocio BPM mediante herramientas SOA de software libre. Caso: Selección y Contratación de profesores de cátedra de la Pontificia Universidad Javeriana Estudiante: Cristian David Romero Melgarejo, cristian.romero@javeriana.edu.co Directora: Ing. María Consuelo Franky de Toro, lfranky@javeriana.edu.co Bogotá D.C. Segundo semestre del año 2011

2 Índice Tabla de ilustraciones Introducción Acerca de la guía Acerca del demo Descripción del Proceso de selección Descripción del Proceso de contratación Descripción del Demo Conceptos de BPM y su implantación con herramientas SOA Procesos de negocio Gestión de Procesos de negocio (BPM) Definición Qué hace BPM? Arquitectura orientada a servicios (SOA) Bus de servicios empresariales (ESB) Instalación de herramientas Eclipse Plugins JBoss AS JBoss ESB Modelación de procesos en BPMN Introducción Demo Proceso de selección Proceso de contratación Modelación de procesos en jbpm Introducción Qué permite modelar el editor gráfico de jbpm? Descripción general Nodos A. Responsabilidad de los Nodos B. Tipo de Nodo: Tarea C. Tipo de Nodo: Estado D. Tipo de Nodo: Decisión E. Tipo de Nodo: Fork F. Tipo de Nodo: Join G. Tipo de Nodo: Nodo G u í a P r á c t i c a. B P M - S O A

3 H. Tipo de Nodo: Start-State I. Tipo de Nodo: End-State J. Tipo de Nodo: Mail-Node K. Tipo de Nodo: ESB-Service Transiciones Adaptación a partir de un modelo BPMN Demo Archivo XML generado Implantación del proceso de negocio usando la consola de JBoss Introducción Demo Alcance Formularios A. Complemento de código en el nodo B. Creación de la forma C. Integración del nodo con la forma Creación de usuarios Nodo de correo electrónico Nodo de decisión Nodos para llamar servicios web Uso del bus de servicios Integración de una aplicación JEE5 con el bus de servicios de JBoss Introducción Relación Entre Anotaciones Referencias G u í a P r á c t i c a. B P M - S O A

4 Tabla de ilustraciones Ilustración 1. Relación entre servicios de negocio y procesos en SOA [18] Ilustración 2. Ejemplo de un modelo en notación BPMN [19] Ilustración 3. Elementos arquitecturales de SOA [18] Ilustración 4. Perspectiva empresarial de SOA [18] Ilustración 5. Arquitectura del bus de servicios empresariales Ilustración 6. Ejemplo de proceso en BPMN [19] Ilustración 7. Proceso de selección de profesores de cátedra de la Pontificia Universidad Javeriana Ilustración 8. Proceso de contratación de profesores de cátedra de la Pontificia Universidad Javeriana Ilustración 9. Ejemplo inicial de un modelo desarrollado con jbpm Ilustración 10. Creación de un nuevo proyecto Ilustración 11. Asignando nombre a un nuevo proyecto Ilustración 12. Creación de un nuevo elemento Ilustración 13. Creación del elemento Process Definition Ilustración 14. Nombrando el proceso Ilustración 15. Partes importantes para la realización de diagramas Ilustración 16. Demo en notación BPMN Ilustración 17. Demo jbpm Ilustración 18. Pestañas de navegación en Eclipse Ilustración 19. Estructura del código jpdl generado por el grafo Ilustración 20. Vista general de los componentes de la consola [27] Ilustración 21. Alcance del desarrollo del demo utilizando la Consola Ilustración 22. Código en jpdl asociado al formulario de una tarea humana Ilustración 23. Código xhtml del formulario de la tarea humana Ilustración 24. Estructura de código en forms.xml Ilustración 25. Código SQL para inserción de usuarios Ilustración 26. Relación de la creación de usuario con el proceso Ilustración 27. Código SQL para inserción de grupos Ilustración 28. Código SQL para relación de usuarios con grupos Ilustración 29. Estructura del nodo para enviar un correo electrónico Ilustración 30. Método para el envío de un correo electrónico Ilustración 31. Estructura del nodo de decisión Ilustración 32. Estructura de la celda para el checkbox de aprobación Ilustración 33. Ruta de creación del servicio web Ilustración 34. Estructura de la clase que contiene el servicio web Ilustración 35. Muestra de la búsqueda del.wsdl Ilustración 36. Estructura de la celda para el checkbox de aprobación Ilustración 37. Cambio de tipo de nodos Ilustración 38. Creación de la cola para el servicio de correo electrónico en el descriptor hornetq-jms.xml Ilustración 39. Creación de la cola para el servicio de invocación de un servicio web en el descriptor hornetqjms.xml Ilustración 40. Creación del mbean para el servicio de correo electrónico en el servidor JMS en el descriptor jbm-queue-service.xml Ilustración 41. Creación del mbean para el servicio de invocación de un servicio web en el servidor JMS en el descriptor jbm-queue-service.xml G u í a P r á c t i c a. B P M - S O A

5 Ilustración 42. Creación del mbean para el servicio de correo electrónico en el servidor JMX en el descriptor jbmq-queue-service.xml Ilustración 43. Creación del mbean para el servicio de invocación de un servicio web en el servidor JMX en el descriptor jbmq-queue-service.xml Ilustración 44. Creación de los canales de correo electrónico e invocación de servicio web en el descriptor jboss-esb.xml Ilustración 45. Estructura de los servicios registrados en el bus en el descriptor jboss-esb.xml Ilustración 46. Líneas a insertar en el descriptor de despliegue de colas del bus en el descriptor deployment.xml Ilustración 47. Cambio en las clases Ilustración 48. Solicitud de materia prima G u í a P r á c t i c a. B P M - S O A

6 1. Introducción 1.1. Acerca de la guía Este documento pretende ser una guía para las Pymes que busquen implementar sus procesos de negocio bajo la filosofía de BPM (Gestión de procesos de negocio), apoyados en una arquitectura orientada a servicios (SOA). Es importante anotar que con cualquiera de las suites o conjunto de herramientas SOA la curva de aprendizaje es elevada, es decir, el tiempo que toma aprender y desarrollar un manejo intermedio de éstas suele ser extenso. Por esta complejidad, surge la motivación de elaborar la presente guía con el ánimo de facilitar el camino a las Pymes. Por otro lado, las suites SOA son herramientas muy costosas y en general fuera del alcance del presupuesto disponible por empresas Pymes. Por esta razón, esta guía fue elaborada pensando en esa situación, dando todas las definiciones y ejemplos a partir de las herramientas libres provistas por el proveedor RedHat-Jboss Acerca del demo Dos de los procesos más comunes a los que se enfrenta una empresa son los de selección y contratación de los recursos humanos que harán posible la operación y el desarrollo de funciones dentro de ella. Por ésta razón, se escogieron como casos de estudio, los procesos de selección y contratación de profesores de cátedra de la Pontificia Universidad Javeriana Descripción del Proceso de selección El proceso de selección consiste en los siguientes pasos: 1. El director de departamento o instituto crea una vacante para un profesor de cátedra dentro del sistema. 2. El profesional de compensación de la oficina de relaciones laborales de la Universidad revisa la apertura de la vacante y las características con las que es solicitada. 3. Luego de efectuarse la revisión, la misma persona del paso anterior, evalúa si la vacante es o no aprobada, para continuar o examinar el proceso hasta éste punto. 4. Si la vacante fue rechazada, el profesional de compensación notifica vía correo electrónico al director de departamento o instituto sobre esta situación. a. Luego de la notificación del rechazo, se procede a eliminar la vacante creada en el sistema, para que sea creada de nuevo con las correcciones impuestas. 6 G u í a P r á c t i c a. B P M - S O A

7 5. Si el director de departamento o instituto solicito la publicación de la vacante en los medios externos dispuestos por la Universidad, se ejecutará esta acción. 6. Independientemente de si se solicitó publicación externa, se publica la vacante en el sistema interno de la Universidad. 7. En este punto, los candidatos pueden ingresar a llenar su hoja de vida y adjuntar la documentación de soporte. 8. El director de departamento o instituto puede asociar los candidatos inscritos a las vacantes disponibles. 9. El director de departamento o instituto hace una preselección de las hojas de vida, dados los perfiles de los postulantes. 10. Si en la preselección se solicitó la realización de una entrevista con el Decano Académico para asegurar algún punto del perfil de la persona, se ejecutará esta acción. 11. El director de departamento o instituto prepara la oferta e ingresa el salario sugerido en el sistema ERP e inicia el proceso de aprobación a través del workflow al decano académico. 12. El decano académico recibe y revisa la solicitud y documentación de soporte sobre la oferta económica. 13. Luego de revisarla, el decano deberá aprobar o rechazar la solicitud. 14. Si la solicitud fue rechazada, el decano académico le notifica al director de departamento o instituto, vía correo electrónico, para que realice los ajustes respectivos. 15. Si la solicitud fue aprobada, se le notifica vía correo electrónico al asistente para asuntos profesorales. 16. El asistente para asuntos profesorales recibe y revisa la solicitud y documentación de soporte sobre la oferta económica. 17. El asistente para asuntos profesorales debe aprobar o rechazar la solicitud. 18. Si la solicitud fue aprobada, se le notifica vía correo electrónico al vicerrector académico. 19. Si la solicitud fue rechazada, el asistente para asuntos profesorales le notifica vía correo electrónico al decano académico para la realización de los ajustes respectivos. a. El decano académico realizará los ajustes a la oferta económica realizada, si así se lo indica el asistente para asuntos profesorales. 20. El vicerrector académico recibe y revisa la solicitud y documentación de soporte sobre la oferta económica. 21. El vicerrector debe aprobar, devolver o rechazar la solicitud. 7 G u í a P r á c t i c a. B P M - S O A

8 22. Si la solicitud fue rechazada, el vicerrector académico le notifica, vía correo electrónico, al decano académico y el proceso vuelve a comenzar desde el numeral Si la solicitud fue devuelta, el vicerrector académico le notifica vía correo electrónico al asistente para asuntos profesorales. a. El asistente para asuntos profesorales revisa las razones por las cuales la oferta fue devuelta. Él decide si devuelve o no la oferta al decano académico. b. Si no la devuelve, se realiza la gestión indicada con el decano académico para pasar a revisión directa con el vicerrector académico. c. Si es devuelta al decano académico y después de que sea realizada la gestión de corrección, el decano académico le notifica al vicerrector académico. 24. Si la solicitud fue aceptada, el vicerrector académico le notifica vía correo electrónico al Jefe de la oficina de relaciones laborales. 25. El jefe de la oficina de relaciones laborales le realiza la oferta económica al candidato, con copia al analista de nómina, profesional de inducción y secretario de facultad. 26. El analista de nómina de la oficina de relaciones laborales prepara el contrato para el candidato. 27. Se realiza la vinculación laboral en el ERP, la asociación de la clase y genera el contrato en el Sistema de administración de estudiantes (SAE). Esta tarea está a cargo del secretario de facultad. 28. El candidato revisa los términos de su contrato y la oferta económica realizada. 29. El candidato deberá evaluar si acepta o no el contrato con la Universidad. 30. Si el candidato no acepto, se le solicita al analista de nómina la terminación del contrato por inconsistencia. 31. Si el candidato acepta, se procede a realizar el proceso de contratación Descripción del Proceso de contratación El proceso de contratación consiste en los siguientes pasos: 1. Dados los recursos de información se define si el profesor es nuevo. 2. En caso de que un profesor sea nuevo: a. Verifica el nombramiento y realiza la solicitud de una apertura bancaria para el pago de la nómina. b. Se realiza el proceso del examen médico. c. Se realiza el proceso de la carnetización institucional. 8 G u í a P r á c t i c a. B P M - S O A

9 d. Se realizan las afiliaciones a seguridad social AHC: Se solicitan los datos respectivos para los trámites de afiliación a seguridad social e. Se le asigna una cuenta de correo electrónico al profesor. f. Se genera el contrato en el sistema ERP con la firma digital del director de recursos humanos y se notifica a la facultad. g. El secretario de facultad le notifica al candidato que debe acercarse a la facultad para firmar el contrato. 3. Se firma el contrato y es remitido a la dirección de recursos humanos de la Universidad. Posterior a esto, se archiva con los documentos de soporte del mismo Descripción del Demo A partir de la descripción de los procesos, se modelarán en BPMN, en jbpm y luego se implantará un subconjunto utilizando las herramientas SOA de JBoss. Esta guía ilustrará todos los pasos tanto de modelaje como de implantación con el ánimo de que las Pymes puedan realizar implantaciones similares de sus procesos de negocio. Para observar todas las características del demo, debe incluir la carpeta dentro del IDE que haya escogido para desarrollo, preferiblemente Eclipse Ganymede. Luego, podrá ejecutarlo registrado el buildfile en el plugin de Ant, y corriendo la función deploy. 9 G u í a P r á c t i c a. B P M - S O A

10 2. Conceptos de BPM y su implantación con herramientas SOA 2.1. Procesos de negocio Las tácticas de negocio y los objetivos son definidos típicamente para unos procesos de negocio particulares. Un proceso de negocio es un grupo de actividades lógicas relacionadas (y generalmente secuenciales) que usan los recursos de la organización para proveer resultados definidos. Los procesos de negocio entregan valor en forma de productos o de servicios, frecuentemente a una entidad externa como un consumidor o un asociado [18]. Generalmente los procesos de negocio cuentan con dos niveles de detalle. Esto se hace para que logre existir un acuerdo entre los ejecutivos de la compañía y los dueños del proceso de negocio. Un modelo, para ejecutivos, contiene un conjunto de escenarios de algo nivel de negocio que muestran el propósito de la organización. El otro modelo, que es para los dueños del proceso de negocio, contiene un conjunto detallado de casos de uso que definen como se suplen las necesidades de la organización. Para cada escenario de negocio de alto nivel, usted puede definir uno, o varios, casos de uso de negocio detallados representando las mismas actividades en la organización (IBM s Rational Unified Process [RUP] for SOMA) [18]. Los escenarios de negocio creados junto con una primera definición de los procesos de negocio son útiles a la hora de descomponer y detallar los procesos desarrollados en la empresa. Por ejemplo, si tomamos el caso de contratación de profesores de una universidad podríamos definirlo a grandes rasgos en una primera instancia, sin embargo, a medida que detallemos este proceso de negocio podríamos tener nuevos subprocesos o actividades agregadas al macro-proceso, cómo por ejemplo la realización de la evaluación médica, la carnetización o la inclusión en determinado software que requiera de varios pasos para el uso del nuevo profesor [18]. Cómo se vio en la sección anterior, una arquitectura orientada a servicios entra a jugar un papel muy importante con los procesos de negocio. Precisamente su objetivo es reconocer y exponer los activos de computación de la organización como servicios de negocio reusables que implementen ciertas funcionalidades básicas, las cuales al ser combinadas permitan el apoyo a la ejecución de complejos procesos de negocio. En este punto vemos una relación directa entre lo llamado procesos de negocio y servicios de negocio. A continuación se detalla esta relación [18]. Ilustración 1. Relación entre servicios de negocio y procesos en SOA [18] 10 G u í a P r á c t i c a. B P M - S O A

11 Los servicios de negocio se encargan de dar apoyo a los procesos de negocio a través de la exhibición de las funcionalidades que se han implementado. Es muy común que la implementación de los servicios de negocio cambien, precisamente porque a medida que cambia el negocio, puede que deban ofrecer unas nuevas o mejoradas funcionalidades. Sin embargo, las reglas con las cuales se publicaron las interfaces muy rara vez cambian, es decir, que la forma de llamar al servicio no tendrá variación así la forma en que ejecuta las órdenes pedidas si haya cambiado [18]. Los procesos de negocio se valen de los servicios de negocio para alcanzar los objetivos de la empresa. Cambian debido a cambios en la estrategia de la organización. En estos procesos se contemplan procedimientos y reglas que sirven a determinados aspectos dentro del negocio [18]. La interacción entre los procesos de negocio y los servicios de negocio se basa en la semántica definida, como se hablaba en la sección anterior sobre SOA. Tener un estándar y un acuerdo para lograr la comunicación entre estos dos aspectos es vital para reducir el impacto que puede generar un cambio en cualquiera de las partes y para simplificar el proceso de construcción de los servicios de negocio que finalmente apoyaran los procesos de negocio [18]. Es importante separar estos dos aspectos para permitir que por un lado los arquitectos de la sección de tecnologías de información tengan el conocimiento sobre los servicios de negocio y cómo estos pueden ser re-usados y configurados de tal forma que sirvan a los procesos de negocio definidos por los analistas de negocio. A través de esta separación, se simplifica la creación de nuevos procesos y la optimización de los existentes. Y más importante aún, con los continuos cambios que se presentan en el mercado y dados nuevos factores de competitividad, una empresa puede ser flexible y mantener sus ventajas con bajos costos a la hora de realizar soportar estos cambios con la re-configuración de sus procesos de negocio y a su vez de los servicios de negocio con los que cuente dentro de la organización [18] Gestión de Procesos de negocio (BPM) Definición Luego de ver la definición y las características de los procesos de negocio, aparece la pregunta sobre cómo lograr una gestión efectiva de estos procesos de negocio? Para dar respuesta a ella, surgió una filosofía llamada BPM. Así como las personas entienden mejor los objetos o fenómenos a través de modelos, las organizaciones, compuestas de personas, también lo hacen. Gracias a los modelos, se tiene la capacidad de identificar visualmente los problemas, y como pueden ser señalados como punto de mejora en una situación dada. Y los procesos de negocio no son la excepción cuando se habla de modelos. La modelación de procesos pertenecientes a una organización, o inclusive a través de varias organizaciones, puede resaltar instantáneamente problemas y es una herramienta importante para la simulación de la eficiencia de ciertos procesos [20]. La gestión de procesos de negocio (BPM) es un conjunto de métodos, herramientas y tecnologías usadas para diseñar, modelar, analizar y controlar los procesos operacionales de un negocio. BPM pretende tener una visión de éstos procesos desde dos ángulos: tecnologías de información y el provisto por los analistas de negocio. De esta forma se busca llegar a conformar procesos efectivos, agiles y transparentes [23]. 11 G u í a P r á c t i c a. B P M - S O A

12 La tecnología de BPM debe incluir todo lo necesario para diseñar, representar, analizar y controlar los procesos operacionales del negocio [23]: El modelamiento de procesos y diseño hacen posible que se plasme de una forma rápida y rigurosa la forma en que los procesos entregan valor a la organización y sus clientes. Además, se ilustra que recursos son necesarios y que rol juegan dentro del proceso. Ilustración 2. Ejemplo de un modelo en notación BPMN [19] La integración se relaciona con aspectos de sistemas de control, sistemas de información, fuentes de datos y otras tecnologías que puedan ser re-utilizadas y re-configuradas de tal forma que se pueda adaptar a los cambios impulsados por el mercado, cumpliendo detalladamente con las necesidades de un proceso determinado. La ejecución es necesaria para que un modelo no se quede solo en diseño, sino que también se permita ejecutar el modelo planteado. Monitoreo de las actividades de negocio: Un seguimiento a las actividades dentro del proceso de negocio es fundamental para obtener retroalimentación a través de métricas, monitoreo, indicadores y tendencias. El control le permite responder a ciertos eventos o circunstancias que ocurran en la ejecución del proceso. Por ejemplo, un cambio de reglas, notificaciones, excepciones y aumento de la capacidad. Retomando la definición y las funciones que provee SOA, en este punto se puede observar como la filosofía BPM encaja con la tecnología provista por la arquitectura orientada a servicios. Esta es una de las razones por las cuales se elaboró la guía bajo el enfoque de BPM SOA, para ilustrar cómo se integra el modelo de negocio con el modelo tecnológico dentro de la empresa Qué hace BPM? BPM es una disciplina amplia, pero tiene un propósito funcional específico. Igualmente, los componentes tecnológicos necesarios para usar la filosofía BPM tendrán unas especificaciones precisas [23]: Centralidad del proceso: BPM unifica el negocio y las actividades de TI, y coordina las acciones y comportamientos de las personas y los sistemas alrededor de un contexto común de procesos de negocio. Usando convenciones y notaciones de modelación de procesos estándar, un gerente de operación puede, por ejemplo, ver el proceso desde la perspectiva de negocio mientras que el gerente de IT puede ver los sistemas y elementos de información. 12 G u í a P r á c t i c a. B P M - S O A

13 Alineación entre el negocio y TI: BPM facilita la colaboración directa y la responsabilidad conjunta tanto de los gerentes de operación como de los profesionales de TI a la hora de diseñar, implementar y optimizar los procesos de negocio. Mejora continua del proceso: Se busca que se pueda obtener retroalimentación de las actividades del proceso a través de su monitoreo y comparación con métricas e indicadores. Composición de soluciones: BPM facilita el diseño rápido, montaje y despliegue de procesos de negocio. Un profesional de TI debe estar en la capacidad de conectar sistemas y servicios al modelo diseñado y aprobado por el analista de negocio. Además, cada vez que haya un cambio sobre el proceso, se debe tener la flexibilidad para que la solución sea adaptada rápidamente. Transparencia: BPM provee un entendimiento de las actividades para todos los participantes. Además, ellos deben ser capaces de ver las métricas de negocio en tiempo real y el rendimiento de los sistemas y servicios disponibles. Interfaces: BPM debe proveer a los gerentes de interfaces que le permitan usar servicios tanto internos como externos, y que estos sean re-usables y adaptables a cualquier configuración requerida. La interface de estos servicios tendrá la información sobre las funciones que cumple, lo cual muy rara vez cambiará, a pesar de que puede que su implementación cambie continuamente Arquitectura orientada a servicios (SOA) Concretamente, una arquitectura orientada a servicios es un estilo arquitectural para construir soluciones empresariales basadas en servicios. SOA tiene que ver con la construcción independiente de servicios alineados con el negocio que puedan ser combinados en procesos significativos, de alto nivel de negocio y con soluciones en el contexto de la empresa. Cualquiera puede crear un servicio, ese no es el reto de SOA. El valor real de SOA se encuentra cuando servicios reusables son combinados para crear procesos de negocio agiles y flexibles. Desafortunadamente, esto no pasa por sí solo. Lograr esto puede ser fácil si una sola organización crea todos sus servicios, pero éste no es el caso de las grandes organizaciones. Así que, parte de la arquitectura de SOA es responsable de proveer el ambiente necesario para crear y usar servicios compuestos a lo largo de la empresa [18]. En otras palabras, la arquitectura SOA permite que diferentes organizaciones desarrollen independientemente los servicios que atiendan a sus necesidades. Sin embargo, a mediano o largo plazo, estos servicios se pueden integrar para dar más valor a las soluciones creadas y que estas tengan mayor impacto en los procesos de negocio [18]. Para lograr la integración, se requiere que los servicios: Sean similares en cuanto a: tamaño, forma, función y otras características. Se adecuen a los estándares de la empresa. Se comuniquen a un nivel técnico. Se comuniquen a un nivel semántico. No tengan huecos ni solapamientos en sus responsabilidades [18]. 13 G u í a P r á c t i c a. B P M - S O A

14 La siguiente figura muestra las capas bajo las cuales se desempeña una arquitectura orientada a servicios, incluyendo dos capas de conceptos. Las descripciones que se encuentran en la parte izquierda hacen referencia a los conceptos funcionales que se usan para construir sistemas y procesos. En la parte derecha, están los conceptos de información que se usan para pasar, describir o manipular datos en los diferentes niveles funcionales. Aquí se puede ver como las organizaciones son una combinación de procesos con información ya que cada capa necesita de ambas abstracciones. Las conexiones entre las capas representan las relaciones entre las funciones [18]. Ilustración 3. Elementos arquitecturales de SOA [18] De abajo hacia arriba las capas son [18]: Recursos de la empresa y datos operacionales: Esta capa se compone de aplicaciones existentes, legacy y sistemas COTS (aplicaciones comerciales fuera de la plataforma), incluyendo aplicaciones CRM (Customer Relationship Management) y ERP (Enterprise Resource Planning) e implementaciones antiguas orientadas a objetos. Estas aplicaciones proveen operaciones de negocio: transacciones que representan unidades lógicas de trabajo en los sistemas de operación de la empresa. Estas operaciones al ser ejecutadas, por lo general, causaran uno o más registros de datos persistentes para ser leídos, escritos o modificados en un sistema de almacenamiento (SOR). Servicios de integración: Los servicios de integración proveen este servicio entre las aplicaciones existentes. Un aspecto muy importante es separar la capa de integración de servicios con la de servicios de negocio para estar en la capacidad de mantener un ambiente empresarial flexible. 14 G u í a P r á c t i c a. B P M - S O A

15 Comúnmente, esto involucra la transformación de datos y funciones de lo que es deseado en el nivel de servicios de negocio a lo que es posible en los sistemas existentes. Servicios de negocio: Proveen servicios de negocio de alto nivel a la empresa. Esta capa se relaciona con la anterior para romper la dependencia directa entre los procesos y los sistemas existentes, así, en caso de que haya un cambio en alguna de las dos capas, solo tendrá que ser modificada la intermediaria. Los servicios son manejados bajo ciertos parámetros para asegurar que se cumplan ciertos contratos respecto a las funciones que deben proveer. Estos contratos son llamados: acuerdos a nivel de servicios (SLA). Para ilustrar mejor que es un SLA, podríamos ver el caso de una revisión de ítems como servicio, cuyo grupo de funciones lógicas podrían ser: Listar todos los ítems, Eliminar ítem por código de ítem o guardar los cambios sobre la lista. Procesos de negocio: Un proceso de negocio consiste en una serie de operaciones que son ejecutadas en una secuencia ordenada acorde a un conjunto de reglas de negocio. A menudo, los procesos de negocio son descritos en un modelo de procesos de negocio, cómo los realizados con la notación estándar BPMN (Business Process Modeling Notation) y ejecutados por un sistema de gestión de procesos de negocio: BPMS. La secuencia, selección y ejecución de las operaciones es llamada Orquestación. Los procesos de negocio proveen conjuntos de acción o actividades de larga duración. Están compuestos por servicios de negocio y típicamente hacen uso de múltiples invocaciones a servicios. Ejemplo de algunos procesos de negocio podrían ser: La contratación de profesores de cátedra de una universidad, el proceso de pago a proveedores internacionales, la matrícula de estudiantes a un colegio o la creación de órdenes de compra. Más adelante se hablará en detalle sobre el concepto de BPM por ser de especial relevancia para esta guía. La siguiente figura muestra una perspectiva empresarial de cómo se implementa SOA, y el uso que hace del bus de servicios (Ver sección 2.4 de este documento, Bus de Servicios Empresariales ESB) para comunicar el modelo de negocio con los servicios y componentes definidos a nivel lógico. Ilustración 4. Perspectiva empresarial de SOA [18] 15 G u í a P r á c t i c a. B P M - S O A

16 Como parte de la determinación del uso que se le dará a la arquitectura se debe observar el ambiente de desarrollo, los frameworks, la infraestructura y las herramientas. No es suficiente con la descripción de cuáles son los servicios; la arquitectura debe permitir una fácil y eficiente creación de esos servicios. Inclusive, se debe especificar como la arquitectura encaja con el proceso de desarrollo y lo apoya en la medida para agregar valor. Es importante que la arquitectura entienda los aspectos de los servicios que deben ser consistentes a lo largo del rango de ambientes de desarrollo, y crear estándares, documentos guías, ejemplos, frameworks, plug-ins o similares que apoyen esos ambientes y procesos de desarrollo [18]. Por último, y no por ello menos importante, se deben consideran las métricas y las medidas de éxito. Una arquitectura orientada a servicios solo es efectiva si esta apoya la consecución de las metas de negocio por las que fue creada. El proceso debe tener métricas y métodos para la recolección de medidas que permitan demostrar cuan efectiva fue la implementación de la SOA [18] Bus de servicios empresariales (ESB) Un bus de servicios empresariales (Enterprise Service Bus ESB) es un software que provee servicios fundamentales para arquitecturas complejas. En el caso de SOA, un ESB provee muchas de las características para su implementación. Se podría definir un ESB como aquel mecanismo que gestiona el acceso a aplicaciones y servicios (incluidos los sistemas legacys) para proveer una interface única, simple y consistente a los usuarios finales [21]. Ilustración 5. Arquitectura del bus de servicios empresariales Entre los propósitos más relevantes de un ESB se encuentran: ocultar la complejidad que implica la comunicación entre servicios heterogéneos, simplificar el acceso a servicios y aplicaciones, hacer que la complejidad y las comunicaciones sean transparentes para el usuario. La clave del éxito de un ESB radica en cuan hábil es para soportar un servicio incremental y la integración de las aplicaciones, no pensado desde el punto de vista de la tecnología disponible, sino de los requerimientos del negocio [21]. De acuerdo con uno de los proveedores de esta herramienta, IBM, un ESB no es un nuevo producto de software, es una nueva forma de observar cómo se integran las aplicaciones, se coordinan recursos y se manipula la información [21]. La arquitectura de un bus de servicios que soporta una arquitectura orientada a servicios, contiene [24]: 16 G u í a P r á c t i c a. B P M - S O A

17 Aprovechamiento de las aplicaciones legacy. Son técnicamente elementos muy antiguos de almacenamiento o procesamiento de información que son de misión crítica para la organización, pero que son muy susceptibles a la hora de ser modificados y demasiado importantes para ser descartados y por lo tanto deben ser reutilizados. Estratégicamente, el objetivo es construir una nueva arquitectura que dará todo el valor esperado, pero tácticamente, los activos de legado deben ser aprovechados e integrados con las nuevas tecnologías y aplicaciones. Capacidad de comunicación de servicios. Esta es una de las capacidades críticas de un ESB, la cual busca la interacción entre servicios a través de una variedad de protocolos y la transformación a partir de un protocolo a otro cuando sea necesario. Otro aspecto importante de una implementación de ESB es la capacidad de soportar los modelos de servicio de mensajería compatible con las interfaces de la arquitectura orientada a servicios (SOA), así como la capacidad de brindar: seguridad, transacciones o información de correlación entre los mensajes. Capacidad de integración. Para apoyar una arquitectura orientada a servicios en un entorno heterogéneo, el ESB debe integrarse con una variedad de sistemas que no soportan directamente el estilo de servicio de interacciones. Esto puede incluir sistemas de legacy, aplicaciones empaquetadas, COTS, etc. Capacidad de transformación. Los distintos componentes conectados a un bus de servicios esperan que sus entradas se presenten en ciertos formatos, y estos pueden ser diferentes a los presentados en las salidas de otros servicios que le envían mensajes. Una de las características de mayor valor en un ESB es que encapsula los detalles de implementación de todos los componentes, logrando que cualquier otro de ellos no conozca estos detalles sobre otro componente. Los servicios de transformación permiten asegurar que los mensajes y datos recibidos por cualquiera de los componentes está en el formato que espera recibirlos, eliminando así la carga de que este se encargará de realizar su propia transformación. El ESB está en capacidad de transformar mensajes en diferentes formatos: XML, de Objetos, entre otros. Capacidades de seguridad. El manejo de la seguridad es uno de los factores claves a la hora de implementar un ESB. Un ESB debe permitir tanto proveer un modelo de seguridad para los consumidores de los servicios, como integrarse con los distintos modelos de seguridad de proveedores de este servicio. En general, se busca que la seguridad tenga aspectos de: autenticación, validación y encriptación/des-encriptación. Capacidades de gestión y monitoreo. En un ambiente SOA, las aplicaciones y los servicios usados pueden cambiar a lo largo del tiempo. Administrar esos cambios es un gran reto, en especial cuando se deben garantizar ciertos requerimientos, por ejemplo, de disponibilidad del sistema. Por esta razón, es importante que un ESB sea capaz de localizar servicios de forma dinámica y se comporte de acuerdo a las necesidades estipuladas. 17 G u í a P r á c t i c a. B P M - S O A

18 3. Instalación de herramientas 3.1. Eclipse Diríjase al siguiente enlace: y descargue la versión llamada Eclipse IDE for Java Developers. Luego, comience la instalación en su máquina y si no desea realizar ninguna configuración especial, puede aceptar la que viene por defecto Plugins Esta sección se toma totalmente de la guía elaborada por la Ingeniera María Consuelo Franky, titulada Instalación y configuración de las herramientas para Java EE 5. Curso: Desarrollo de aplicaciones en Java EE 5 en base a framework. Presentación: 1-guia-configuracion-javaee5.pdf, encontrada en: El conjunto de plugins JBoss Tools All para Eclipse ofrece facilidades adicionales para el desarrollo de aplicaciones Java EE 5, agregando las perspectivas de Web Development y Seam con vistas (windows) especializadas en: Explorador de proyectos JSF (vista Web Projects) Paleta para diseñar páginas JSF (vista JBoss Tools Palette con elementos HTML, Facelets, jax4jsf, RichFaces, Seam; se puede extender con otros elementos como ADF, ICEfaces, etc.) Herramientas Hibernate que permiten ejecutar consultas JPQL (vistas Hibernate Configurations, Query Parameters, Hibernate Query Result, Hibernate Dynamic SQL Preview) Asociar proyectos a servidores registrados en Eclipse (vista JBoss Server View) Diseño de procesos de negocio jbpm (vista Overview, editor jbpm Graphical Process Designer) Lista de componentes Seam de un proyecto, indicando el contexto de cada componente (vista Seam Components, solo funciona para proyectos generados con el asistente Seam Web Project ) Antes de instalar este conjunto de plugins debe cerrarse Eclipse y agregar al principio del archivo eclipse.ini (bajo el directorio de instalación de Eclipse) la opción -clean Con esta opción Eclipse refrescará sus plugins instalados cada vez que se inicie. Para la instalación descomprimir el archivo: JBossTools-ALL-win v R-H192-GA.zip en el directorio raíz de la instalación de Eclipse. El archivo lo puede encontrar en el siguiente link: Luego se puede invocar Eclipse y abrir las perspectivas agregadas (Web Development y Seam) 18 G u í a P r á c t i c a. B P M - S O A

19 3.3. JBoss AS Descargue el Application Server de la dirección: y ubíquelo en una carpeta fácil de recordar para usted. Luego, en Eclipse y abriendo la pestaña del plugin JBoss AS instalado, registre el servidor. Esta acción se realiza dando click derecho, seleccionando la opción para agregar un nuevo servidor, y dentro de este sólo deberá proveer un nombre y la dirección donde se encuentra la carpeta descargada. Luego, podrá correr el servidor normalmente JBoss ESB Luego de tener instalado JBoss Application Server, deberá descargar JBoss ESB 4.9 en la siguiente dirección: Cuando haya descargado la carpeta, regístrela en el IDE Eclipse. Ingrese a jbossesb- 4.9/install/deployment.properties.example y borre la extensión.example de tal forma que éste descriptor tenga extensión.properties. Luego, ábralo y edite las siguientes propiedades de tal forma que quede como se indica a continuación: # application server root directory org.jboss.esb.server.home=/jboss ga # the instance of jboss you are running(default) org.jboss.esb.server.config=default Tenga en cuenta que la sección resaltada en rojo deberá tener la dirección de la carpeta de su computador donde se encuentra el JBoss AS. Luego registre el buildfile y ejecute la tarea ant deploy. Esto instalara todo lo necesario dentro de JBoss AS para que en todas las ocasiones que inicie este servidor, se disponga para usted las herramientas brindadas por el Bus de servicios de JBoss. 19 G u í a P r á c t i c a. B P M - S O A

20 4. Modelación de procesos en BPMN 4.1. Introducción A medida que las empresas se desarrollan, sus procesos de negocio se van haciendo más complejos y el mercado comienza a exigir que sean más organizadas en cuanto a la integración de los procedimientos que manejan y a la efectividad con la que apoyan la consecución de metas planteadas. Cuanto más exigencias tenga una empresa y mayor maduración tenga, sus procesos serán repetibles y escalables, organizados de tal forma que se puedan re-configurar y brindar flexibilidad en la operación de la compañía [19]. Uno de los pilares de la gestión y dirección de las empresas consiste en tener claros estos procesos que permiten la supervivencia en el mercado. Si se comprende con detalle estos procesos, será factible evaluarlos y mejorarlos. En otras palabras, se podrá organizar el trabajo de mejor manera y considerar las siguientes preguntas para mejorar la productividad [19]: Cuáles pasos son realmente necesarios? Quién debería realizarlos? Deben quedarse en la empresa o en el subcontratado? Cómo deben ser realizados? Qué funcionalidades se necesitan? Qué resultados se esperan y como serán monitoreados? Para facilitar el proceso de dar respuesta a estas preguntas, se toma la decisión de modelar los procesos, preferiblemente bajo un estándar que facilite la comunicación entre entidades o personas y el entendimiento por cada una de ellas sobre las actividades que se deben seguir dentro del proceso. Generalmente, estos modelos guiarán el trabajo y la forma en que se organizan los recursos para alcanzar los objetivos. Para ver como se ilustra el flujo de trabajo se puede ver la imagen a continuación [19]. Ilustración 6. Ejemplo de proceso en BPMN [19] En la ilustración anterior, se pueden ver actividades que dan inicio al proceso (círculo verde) o que indican la finalización del mismo (círculo rojo). Además, se tienen actividades realizadas por humanos (las cuales están indicadas con el símbolo de una persona en la parte superior derecha) y actividades realizadas automáticamente (las cuales están indicadas con el símbolo de un piño en la parte superior derecha). 20 G u í a P r á c t i c a. B P M - S O A

21 Finalmente, el rombo indica las decisiones que deben ser tomadas por cierto actor o de forma automática por un servicio o sistema. Las convenciones completas serán explicadas en la sección 5.3 En la industria, el estándar utilizado para la modelación de procesos es BPMN, el cual provee una serie de herramientas conceptuales para expresar los procesos de negocio en un lenguaje intuitivo, el cual puede ser interpretado luego en un lenguaje de ejecución, como BPEL, el cual es un estándar para componer servicios asíncronos y síncronos en un flujo colaborativo de proceso [25]. Además es una notación usada para diseñar todos los procesos organizacionales uniformemente, para que de esta forma se pueda comunicar fácilmente cada proceso con otras personas tanto dentro como fuera de la organización [16]. Otra de las razones por la cual BPMN es ampliamente utilizado como estándar, es que además de facilitar la comunicación entre los analistas del dominio, les permite apoyarse para tomar decisiones basadas en técnicas como análisis de costo, análisis de escenario y simulación. Sin embargo, los modelos BPMN también son usados como la base para especificar los requerimientos de software y en tales casos, son entregados a los desarrolladores de software encargados de la elaboración del sistema [17] Demo A continuación se mostrará la modelación BPMN que se realizó de los dos procesos de la dirección de gestión humana de la Pontificia Universidad Javeriana: selección y contratación de profesores de cátedra. De estos casos se tomará un subconjunto para implantarlo como demo con el fin de ilustrar el uso de herramientas SOA. Se explicaran los componentes de dichos diagramas, sin embargo, para ver más detalles sobre la notación usada y cómo podría usted elaborar sus propios modelos de procesos, por favor diríjase a la sección 5.3 de este documento. Tenga en cuenta que la descripción de la notación y la realización de estos modelos fue hecha a partir del uso del modelador de procesos de negocio de Bizagi: Antes de realizar cualquier modelo, debe partir de la premisa bajo la cual debe identificar que entidades intervienen en el proceso de negocio. Entienda por entidades aquella agrupación de individuos o instituciones homogéneos pero que entre el grupo de entidades es heterogénea respecto a los demás. También tenga en cuenta que bien puede usted dividir a todos los involucrados en el proceso como entidades diferentes, dependiendo del grado de complejidad y tipo de tareas que deba realizar cada uno. Luego de identificar las entidades, debe resaltar los individuos o departamentos que dentro de ellas actúan para llevar a cabo las actividades del proceso de negocio. Cada uno de estos individuos o departamentos tendrá una línea dentro del pool llamada lane. De esta forma, usted tendrá tantos pools como entidades haya identificado, y dentro de cada uno de los pool tendrá tantos lanes como individuos o departamentos pertenecientes a cada entidad haya determinado. Finalmente, debe conocer que actividades realiza cada individuo dentro del contexto de su entidad y de qué tipo es esa actividad: si es manual o automática, y dentro de estos dos tipos podrá encontrar ciertas variaciones como envió de correos, solicitud de servicios, tiempos de espera, etc. La modelación en Bizagi es sencilla de realizar, simplemente debe seleccionar el elemento que desea insertar en el menú de la derecha y arrástralo hasta la hoja en blanco. A partir de esta acción puede realizar cualquier diagrama. Además, provee de cierta flexibilidad que dando click derecho sobre cada componente insertado, le permitirá indicar más exactamente el tipo de componente, es decir, a través de esta acción 21 G u í a P r á c t i c a. B P M - S O A

22 puede ilustrar si una actividad es el envío de un correo electrónico, la recepción de un correo, una tarea humana o una actividad automática. Nota: Dado que el alcance de esta guía no pretende ahondar mucho en la modelación de procesos en BPMN, le recomendamos que para más detalles consulte la guía oficial provista por la OMG (Object Management Group) o ingrese a la documentación provista en la página de Bizagi: Proceso de selección El proceso de selección de profesores de cátedra en la Pontificia Universidad Javeriana se realiza siempre que un director de departamento o un instituto soliciten la contratación de una persona para uno de estos cargos. En éste participan cuatro entidades representadas en cuatro diferentes pools: La facultad, la oficina de relaciones laborales, la vicerrectoría académica y los candidatos. En la imagen del proceso mostrada en la ilustración 6 (que puede detallar mejor, junto con las abreviaciones correspondientes, en la imagen adjunta a este documento llamada: GRH BPMN modelo selección), cada pool se muestra con colores diferentes. Encontrará en el pool de la facultad, en el lane del director de departamento o instituto el símbolo de comienzo del proceso representado a través de un círculo verde. Finalizado todo el proceso de negocio, en el caso de que un candidato haya rechazado la propuesta, podrá ver que en el pool de la oficina de relaciones laborales, en el lane del asistente de nómina se dará terminación a la oferta laboral y se acabará la instancia del proceso, que se simboliza con un círculo rojo. Si por el contrario, un candidato decidió aceptar la oferta realizada, se dará paso al proceso de contratación y posterior a este se darán por finalizados los procesos de selección y contratación del profesor de cátedra. Del modelo, también es importante destacar el envío y recepción de correos electrónicos, los cuales se identifican porque en la parte derecha superior de cada actividad hay una figura con forma de carta y tienen una flecha con dirección izquierda derecha si es de envío, mientras que las actividades de recepción de correos tienen la misma identificación de la figura pero la flecha esta con dirección derecha izquierda. Para ver el detalle del proceso de selección de profesores de cátedra de la Pontificia Universidad Javeriana, puede dirigirse a la primera sección de este documento, donde se explica detalladamente el flujo y podrá comparar sus características respecto al siguiente diagrama en notación BPMN. 22 G u í a P r á c t i c a. B P M - S O A

23 Ilustración 7. Proceso de selección de profesores de cátedra de la Pontificia Universidad Javeriana También encontrará actividades de decisión, representadas por un rombo amarrillo. En ellas las decisiones se toman de acuerdo a ciertas reglas y dependiendo de su respuesta tomarán un rumbo u otro. En el modelo, podrá ver que cada camino será tomado si la respuesta a esa pregunta coincide con el nombre que se le dio a la relación que lleva a la siguiente actividad Proceso de contratación El proceso de contratación de un profesor de cátedra se realiza inmediatamente después de que termina el proceso de selección. En éste participan tres entidades representadas en tres diferentes pools: La oficina de operaciones, la facultad que solicito el profesor y el o los candidatos elegidos. En la imagen del proceso mostrado en la ilustración 7 (que puede detallar mejor, junto con las abreviaciones correspondientes, en la imagen adjunta a este documento llamada: GRH BPMN modelo contratación), el pool de la oficina de operaciones se representa en el degradado de azul oscuro. En ellos encontrara los puntos de inicio del proceso y de finalización, representados con un círculo verde y rojo respectivamente. Para ver el detalle del proceso de contratación de profesores de cátedra de la Pontificia Universidad Javeriana, puede dirigirse a la primera sección de este documento, donde se explica detalladamente el flujo y podrá comparar sus características respecto al siguiente diagrama en notación BPMN. 23 G u í a P r á c t i c a. B P M - S O A

24 Ilustración 8. Proceso de contratación de profesores de cátedra de la Pontificia Universidad Javeriana Además, verá que dentro del proceso hay dos actividades que deben ser realizados por personas representados con el símbolo de un humano. Y encontrará cinco actividades más que deben ser realizadas por el sistema bien sea automáticamente o con el llamado a ciertos servicios de negocio pertenecientes a la misma oficina de operaciones. En el pool de la facultad y en su lane de secretario de la facultad, verá que esta persona solo envía un correo electrónico. Luego en el pool de los candidatos, en el lane de candidato se hace la firma del contrato y finalmente se archivan los documentos generados, actividad bajo la responsabilidad del auxiliar de archivo cuyo lane está ubicado en el pool de la oficina de operaciones. 24 G u í a P r á c t i c a. B P M - S O A

25 5. Modelación de procesos en jbpm 5.1. Introducción En la actualidad, las compañías necesitan crecer de manera rápida para permanecer en el mercado que cada vez es más competitivo; la mayoría de estas compañías comprenden el problema y optan por diseñar procesos de negocio, sin embargo, no están organizados ni mucho menos automatizados, la razón es que implementar soluciones para automatizar los procesos resulta costoso. Actualmente las empresas invierten entre $ $ de dólares para esta tarea [2], pero lo que muchas de ellas desconocen es que existen herramientas libres para implementar tales soluciones, una gran alternativa para que las empresas sean competitivas en el mercado a un precio favorable. Jboss jbpm es una de estas herramientas libres la cual permite modelar procesos de negocio. Una de sus mayores ventajas es que establece un puente entre los analistas de negocio y los desarrolladores [1]. Esta guía presenta varias características sobre jbpm versión: 3.X, entre ellas: la forma de modelar los procesos de negocio, el uso de anotaciones para conducir el proceso de negocio y un demo. Existen en el mercado varios editores libres para BPM. Sin embargo, vale la pena destacar que gracias a que se cuenta con la suite SOA de JBoss para implementar los procesos de negocio modelados, se puede hacer el paso del diagrama jbpm a su desarrollo. Lo anterior, se hace sin costos de licencia lo que facilita su adquisición y ajuste a presupuesto de las Pymes en éste caso. Gracias a esa situación y a la curva de aprendizaje elevada para la utilización de esta herramienta, se decidió realizar esta guía. 25 G u í a P r á c t i c a. B P M - S O A

26 5.2. Qué permite modelar el editor gráfico de jbpm? Descripción general Una definición de proceso jbpm representa la especificación formal de un proceso de negocio y está basada en un grafo dirigido. El grafo está compuesto de nodos y transiciones. Cada nodo del grafo tiene un tipo específico. El tipo del nodo define el comportamiento en tiempo de ejecución. Una definición de proceso tiene exactamente un estado inicial. [3] Ilustración 9. Ejemplo inicial de un modelo desarrollado con jbpm Un Token indica en que nodo del grafo se encuentra la ejecución. A medida que la ejecución avanza, el token va de nodo en nodo según sea la instrucción dada. [3] Una instancia de proceso es una ejecución de una definición de proceso jbpm. Cuando una instancia de proceso es creada, un Token es creado para el camino principal de la ejecución. Este Token es llamado el Token Raíz de la instancia de proceso y es posicionado en el estado inicial de la definición de proceso. [3] Una señal hace que el Token continúe en la ejecución del grafo. Cuando el Token recibe una señal sin nombre, éste dejará su nodo actual y saldrá hacia la transición por defecto. Sin embargo, si en la especificación de la señal viene un nombre de transición definido, el Token dejará el nodo actual y saldrá por la transición definida. [3] Tan pronto un Token entra a un nodo, éste será ejecutado. Los nodos en sí mismos son responsables por la continuidad de la ejecución del grafo y de su comportamiento dependerá los caminos que siga el Token de ese punto en adelante. Un nodo que espera una señal para continuar con la ejecución será llamado un nodo estado. [3] 26 G u í a P r á c t i c a. B P M - S O A

27 El gráfico representa la secuencia del proceso de negocio y cómo se comporta desde una vista gerencial. Sin embargo, oculta muchos detalles técnicos que más adelante serán modelados por las acciones en código Java. [3] Nodos Un nodo tiene un tipo específico. El tipo determina qué pasará cuando la ejecución llegue a este nodo en el tiempo de ejecución. En jbpm existen ciertos tipos de nodos pre-implementados que pueden ser usados, o bien, se podrían crean nuevos tipos de nodos escribiendo el código correspondiente para implementar un comportamiento específico [3]. El propósito de este documento solo es presentar un resumen, si desea conocer más información al respecto consulte el Manual [6]. A. Responsabilidad de los Nodos Cada nodo tiene dos responsabilidades principales: Primero, pueden ejecutar código Java plano, es decir la función que deben realizar dentro del proceso. Por ejemplo, actualizar una base datos, enviar un , etc. Segundo, un nodo es responsable por la propagación (continuidad) de la ejecución del proceso. Un nodo podrá: No propagar la ejecución; Propagar la ejecución por una de las transiciones; Propagar la ejecución por varios caminos (fork), creando varios tokens; Finalizar la ejecución del camino. [3] Muchas de las herramientas de flujos de trabajo y sistemas BPM son propietarias. En este sentido, jbpm representa una ventaja ya que a través del lenguaje JPDL (jbpm Process Definition Language) [4], se le otorga el don a los desarrolladores de crear modelos más complejos y poderosos. A continuación, se discutirán los tipos de nodos más importantes de JPDL. Se podría decir que JPDL es a jbpm, lo que BPEL es a BPMN. JPDL permite darle vida al modelamiento realizado en jbpm, dando paso a la ejecución de los nodos propuestos. Es un esquema XML en el cual se relaciona el modelo con las clases o direcciones de servicios que deberá ejecutar cuando se encuentre en un nodo determinado. B. Tipo de Nodo: Tarea Un nodo de tarea representa una o más tareas que son realizadas por humanos. Así que cuando la ejecución llega a un nodo de Tarea, se esperará hasta que el usuario realice su tarea cuya finalización creará la señal que dará continuidad al token hacia los nodos siguientes. El tiempo que tardan los usuarios desde que llega la ejecución al nodo hasta que completan sus tareas, se llama estado de espera. [3] C. Tipo de Nodo: Estado Es un nodo de espera en el cual no se ejecuta ninguna tarea. Su principal uso es cuando se espera la señal de otro sistema para continuar con la ejecución. [3] D. Tipo de Nodo: Decisión Existen dos formas de modelar una decisión. La diferencia radica en Quién está tomando la decisión. La decisión deberá ser tomada por el proceso, según la definición de proceso?, o La decisión dependerá de una entidad externa? 27 G u í a P r á c t i c a. B P M - S O A

28 a. Un nodo de decisión debe ser usado si es el propio proceso el responsable de tomar la decisión. Hay dos formas para especificar el criterio de decisión. Una es añadiendo condiciones a las transiciones mediante scripts, los cuales pueden estar en XML o beanshell script. Los nodos recorrerán estas transiciones, hasta que encuentren una que satisfaga las condiciones. La primera que retorne true, marcará el camino a seguir. b. Cuando la decisión no depende del proceso, sino de una entidad externa, la solución ideal es ubicar un nodo de estado con varias transiciones de salida. Cuando llegue la señal, ésta deberá indicar cuál es el camino a tomar. [3] E. Tipo de Nodo: Fork Un fork divide un camino de ejecución en múltiples caminos de ejecución concurrente. El comportamiento por defecto del Fork, crea un token hijo para cada transición que se desprende de este nodo. De esta forma se crea una relación de padre - hijo. [3] F. Tipo de Nodo: Join Un Join por defecto asume que todos los tokens que llegan a él, son hijos de un mismo padre. Esta situación se presenta cuando con anterioridad se usó un nodo fork y se pretende que la ejecución concurrente de los tokens hijos creados llegue a un solo punto. Luego de que todos lleguen a este punto, se seguirá por una única transición. Cuando uno o más tokens hijos no han llegado, el nodo se comportará como un nodo de estado a la espera de ellos. [3] G. Tipo de Nodo: Nodo Este nodo permite escribir el propio código a través de una acción. Éste nodo, al igual que los anteriores, será representado en el grafo pero no sé darán detalles técnicos ya que la implementación lógica no es relevante para el analista de negocio. [3] Si se desea invocar un Web-Service, este nodo permitirá realizar esta acción. El siguiente ejemplo puede aclarar esta implementación [7]: Se puede observar como los Nodo tipo <<Node>> son invocaciones a Web-Services que posiblemente residan en un Bus de Servicios, mientras que los nodo tipo <<Task Node>> son acciones de revisión por parte de los usuarios interesados. 28 G u í a P r á c t i c a. B P M - S O A

29 H. Tipo de Nodo: Start-State Este nodo es el primero en un proceso. Al ser el primero debe cumplir que a él no llega ninguna transición y solo podrá haber un Start-State por proceso. Otra característica importante es que éste nodo no se ejecuta. Solo sirve para indicar que un proceso se ha creado y aún no comienza su ejecución. Un proceso sin nodo Start es válido, pero no puede ser ejecutado. [4][5] I. Tipo de Nodo: End-State Una definición de proceso tiene solo un nodo de este tipo. La instancia de proceso es finalizada cuando la ejecución llega a este punto. [9] J. Tipo de Nodo: Mail-Node Este nodo se encarga precisamente de enviar un , según la configuración dada. Se tiene un gran número de configuraciones que van desde el mensaje en sí mismo hasta el servidor como un todo. En el caso del nodo y en código JPDL, un podría ser enviado de la siguiente forma [8]: <mail-node name="send " to="#{universidad}" subject="investigación" text="se ha cumplido el objetivo"> <transition to="the next node" /> </mail-node> Se hablará sobre la forma de implementar este nodo en en el capítulo dedicado al uso de la Consola de JBoss. K. Tipo de Nodo: ESB-Service Cuando se invoca un nodo de este tipo, se conoce como Orquestación de Servicios. De esta forma se pueden invocar servicios ESB registrados en el bus JBoss ESB y embebidos en algunas acciones especiales dentro de la definición del proceso. Hay tres tipos de comunicación en este sentido: Llamado de una vía, cuando se desea enviar información del proceso jbpm al bus ESB, generalmente se hace dentro de las transiciones; Comunicación de dos vías, realizado en un nodo aparte, sirve para enviar peticiones y recibir información; Comunicación de dos vías con tiempo de espera, se establece un tiempo límite de espera de las respuestas [10]. Los servicios ESB se explicarán más adelante en el capítulo dedicado al uso de la Consola de JBoss Transiciones Las transiciones tienen un nodo fuente y un nodo destino. El nodo fuente es representado con la propiedad FROM y el nodo destino es representado con la propiedad TO. Una transición puede tener un nombre, el cual será especificado en sus propiedades. Es importante que esta propiedad sea única. Adicionalmente, cada nodo conocerá la lista de transiciones con las que se relaciona, en 29 G u í a P r á c t i c a. B P M - S O A

30 caso de que la programación así lo requiera, la transición por defecto será la primera en la lista de un nodo fuente. [3] Nota: Si desea ver más ejemplos o aclarar alguna particular puede dirigirse al documento: Características y posibilidades con jbpm 3.X [11] 30 G u í a P r á c t i c a. B P M - S O A

31 5.3. Adaptación a partir de un modelo BPMN En la sección anterior se mostró como se trabajaba con jbpm a la hora de modelar ciertas actividades necesarias dentro de un proceso. De la misma manera, BPMN tiene sus propias siglas descritas a continuación y como éstas se pueden traducir a jbpm. Elemento jbpm BPMN Tarea Desempeñada por humanos, será asignada a una persona cuando el proceso sea ejecutado, la instancia del proceso esperara a que la tarea sea completada por la persona encargada. Es un tipo de nodo especial. Permite al desarrollador escribir un nodo definido por él. Típicamente es usado cuando el desarrollador necesita escribir código para hacer que el sistema desempeñe alguna acción. Representan el trabajo realizado dentro de una organización. Consumen recursos. Pueden ser simples o compuestas. Se divide en los tipos que se muestran en la imagen anterior. El tipo de tarea similar a la tarea de jbpm es la denominada Usuario. Las más importantes en nuestro ejemplo, son las tareas de usuario, que son las realizadas por un humano. Las tareas de servicio, que son realizadas automáticamente bien sean por un servicio interno o externo. Y finalmente, las tareas de envío o recepción que tienen que ver con el correo electrónico. Decisión Se utiliza cuando la decisión que se toma es basada en datos y no por el usuario, si no por el proceso en sí mismo. Compuerta Exclusiva basada en eventos. Divergencia: Ocurre cuando en un punto del flujo basado en los datos del proceso se escoge un solo camino de varios disponibles. Convergencia: Es utilizada para confluir caminos excluyentes. Las compuertas son utilizadas para controlar la divergencia y convergencia del flujo. Inicio Eventos de inicio: Indican cuando un proceso inicia, no tienen flujos de secuencia entrantes. Solo sirve para indicar que un proceso se ha creado y aún no comienza su ejecución. Evento de inicio sin especificar: No se especifica ningún comportamiento en particular para iniciar el 31 G u í a P r á c t i c a. B P M - S O A

32 proceso. Evento de inicio de Mensaje: Un proceso inicia cuando un mensaje es recibido. Evento de Inicio de Temporización: Indica que un proceso inicia cada ciclo de tiempo o en una fecha específica. Evento de Inicio de Condición: Un proceso inicia cuando una condición de negocio se cumple. Evento de Inicio de Señal: El proceso inicia cuando se captura una señal lanzada desde otro proceso. Tenga en cuenta que una señal no es un mensaje, un mensaje tiene claramente definido un destinatario, la señal no. Evento de Inicio Múltiple: Indica que existen muchas formas de iniciar el proceso y que al cumplirse una de ellas iniciará el proceso. Fin Una definición de proceso tiene solo un nodo de este tipo. La instancia de proceso es finalizada cuando la ejecución llega a este punto. Evento de Fin sin especificar: Indica que un camino del flujo llego al fin. Evento de Fin de Mensaje: Permite enviar un mensaje al finalizar el flujo. Evento de Fin de Señal: Permite enviar una señal al finalizar el flujo. Evento de Fin Múltiple: Indica que varios resultados pueden darse al finalizar un flujo. Evento de Fin de Cancelación: Permite enviar una excepción de la cancelación al finalizar el flujo. Solo se utiliza en subprocesos transaccionales. 32 G u í a P r á c t i c a. B P M - S O A

33 Evento de Fin de Error: Permite enviar una excepción de error al finalizar el flujo. Evento de Fin de Compensación: Este tipo de fin indica que es necesaria una compensación al finalizar el flujo. Fork/Join Representa actividades que se pueden realizar en paralelo. Un Fork divide el camino de ejecución, para luego ser unidos por un Join. Compuerta Paralela: Divergencia: Se utiliza cuando varias actividades pueden realizarse concurrentemente o en paralelo, corresponde a Fork en jbpm. Convergencia: Permite sincronizar varios caminos paralelos en uno solo. El flujo continúa cuando todos los flujos de secuencia de entrada hayan llegado a la figura, corresponde a Join en jbpm. Transiciones Secuencia: representan el control de flujo y secuencia de los objetos del flujo (actividades, compuertas, eventos). Especifica la ruta entre nodos. Pueden tener nombre en el grafo Mensaje: representan la interacción entre varios procesos. No representan flujos de control, representan señales o mensajes Asociaciones: Se usan para asociar información adicional del proceso. Subprocesos Es usado cuando se necesitan modelar subprocesos a un alto nivel que se requieren dentro del proceso. Nos permite romper un modelo muy complejo en varios más manejables. Subproceso: Actividad compuesta que incluye un conjunto interno lógico de actividades y que puede ser analizado en más detalle. Subproceso embebido: Depende del proceso padre. No contiene ni pools ni lanes. 33 G u í a P r á c t i c a. B P M - S O A

34 Canales / Swimlanes No se representan gráficamente, sin embargo, si se especifican en XML. Se definen grupos o roles que luego serán útiles para asignar las tareas a las personas. Subproceso reusable: Es un proceso definido como un diagrama de procesos independiente y que no depende del proceso padre. Pool: Actúa como contenedor de un proceso, representa un Participante Entidad o Rol. Siempre existe al menos uno, así no se diagrame. Lane: Subdivisiones del Pool. Representan los diferentes participantes al interior de una entidad. Nota: La tabla anterior fue generada a partir de: [13] [14] [15]. 34 G u í a P r á c t i c a. B P M - S O A

35 5.4. Demo Para la modelación de procesos, se ha tomado como referente el proceso de selección y contratación de profesores de cátedra de la Pontificia Universidad Javeriana [12]. De esta forma, podrá ver la transformación de cualquier diagrama hacia un esquema jbpm. Para este ejemplo se han elaborado los diagramas correspondientes en notación BPMN con el fin de que tenga un referente de un estándar internacional, y luego se muestra como su notación se transforma en un diagrama jbpm. Para crear un diagrama de jbpm, utilizando Eclipse con los plugins indicados en el capítulo de instalación, debe iniciar un nuevo proyecto. Asigne un nombre a su proyecto. Ilustración 10. Creación de un nuevo proyecto Ilustración 11. Asignando nombre a un nuevo proyecto 35 G u í a P r á c t i c a. B P M - S O A

36 Dé click derecho sobre el nombre del proyecto y cree un nuevo elemento Other. Ilustración 12. Creación de un nuevo elemento Ahora, busque el elemento Process Definition dentro de la carpeta JBoss jbpm. Ilustración 13. Creación del elemento Process Definition 36 G u í a P r á c t i c a. B P M - S O A

37 Finalmente, escriba el nombre que le dará a su proceso. Ilustración 14. Nombrando el proceso Luego tendrá acceso a todas las herramientas de modelación que brinda jbpm. Verá que el proceso creado corresponde a un archivo XML, y que como puede ver en la siguiente imagen, tiene 4 modos de edición: Diagram, Deployment, Design y Source. En el modo de edición Diagram, tiene acceso a todos los tipos de nodo, descritos en la sección anterior, en el menú de la izquierda. Deberá seleccionar uno y arrástralo para comenzar la modelación de su proceso. Igualmente, con la opción llamada Transition podrá agregar las relaciones entre los diferentes nodos que haya puesto en el diagrama. Ilustración 15. Partes importantes para la realización de diagramas 37 G u í a P r á c t i c a. B P M - S O A

38 Para observar mejor la modelación de un proceso, lo ilustraremos con el caso de desarrollo escogido: El proceso de selección y contratación de profesores de cátedra de la Pontificia Universidad Javeriana. Primero, si usted ya tiene sus diagramas en otra notación, por ejemplo BPMN, verá que es sencillo modelar el mismo proceso en jbpm. A continuación se muestra una parte del proceso de selección de profesores de cátedra (El proceso completo se encuentra en la imagen adjunta a este documento: GRH BPMN Modelo Selección) modelado con la notación BPMN. Verá que cada uno de los nodos tiene un tipo de nodo, bien sea enviar un o realizar una tarea humana. Además, a la izquierda puede ver que cada uno de esos nodos tiene un responsable, en este caso el profesional de compensación de la entidad: Oficina de relaciones laborales. En el siguiente ejemplo, verá cómo llega un mensaje o una señal al nodo llamado: revisión de la vacante ORL_PC. En este punto el profesional de compensación de la oficina de relaciones laborales (ORL_PC) hará una revisión de la vacante propuesta para profesor de cátedra de la Universidad. Luego, de realizar la revisión, pasara a un nodo de decisión donde se preguntará si aprueba o no la propuesta de esa vacante. De no hacerlo, enviara una notificación vía al Director de departamento o instituto (ORL_PC DDI). Si la aprueba, y se requiere publicación en medios publicitarios, ira a un servicio que realice esta actividad. Finalmente, en este ejemplo, el flujo de actividades termina con la publicación de la vacante en el sistema interno de la Universidad. Ilustración 16. Demo en notación BPMN En las imágenes adjuntas no solo encontrara el proceso de selección, sino también el de contratación (Ver imagen adjunta a este documento: GRH BPMN Modelo Contratación). Ahora, la imagen 15, que encuentra a continuación, corresponde a la misma sección de proceso anterior pero con la imagen generada desde la modelación con jbpm. Igual que BPMN y como se ilustro al inicio de la sección de modelación, jbpm provee un ambiente para crear nodos de cualquier tipo, y en este caso equivalentes a los ya presentados con la notación anterior. Los nodos fueron creados arrastrándolos dentro del diagrama y las relaciones entre ellos, con la opción Transition del menú lateral. Si desea ver y comparar los modelos generados con una y otra notación, también se ha 38 G u í a P r á c t i c a. B P M - S O A

39 adjuntado a este documento dos imágenes donde se usó jbpm (Ver imágenes adjuntas a este documento: GRH jbpm Modelo Contratación y GRH jbpm Modelo Selección). La explicación correspondiente del diagrama, donde podrá detallar cuál es la función de cada nodo, la podrá encontrar en el archivo adjunto llamado: Documentación modelo jbpm. De esta forma, puede crear sus diagramas de proceso inicialmente desde jbpm, o puede crearlos a partir de los diagramas con los que ya cuente dentro de su organización. Para facilitar la conversión, en este caso de la notación estándar internacional BPMN, hacia jbpm puede consultar la siguiente sección. Luego, se mostrará el archivo XML generado por el gráfico y como se interpreta Archivo XML generado Ilustración 17. Demo jbpm Ilustración 18. Pestañas de navegación en Eclipse El archivo XML generado a partir del diagrama realizado en jbpm se puede visualizar haciendo click en la pestaña llamada Source. Las siguientes son las líneas escritas en lenguaje JPDL, encontradas en el archivo XML, a partir del modelo realizado en jbpm con el caso de la selección de profesores de la Pontificia Universidad Javeriana (Ver imagen adjunta a este documento: GRH jbpm Modelo Selección). Tenga en cuenta que éste archivo no tiene tildes para evitar posibles problemas después a la hora de ejecutar el diagrama. En primera instancia, fíjese en la sección de código resaltada en rojo. Es un nodo tipo start, lo puede reconocer por el inicio y final de la etiqueta: start-state. Además, encuentra que tiene una propiedad name. Todos los nodos cuentan con esta propiedad que indica cual será el nombre que identificara a este nodo (sin embargo, para el caso de los fork y los join, el nombre no aparecerá en el diagrama). Es importante, porque además de identificar el nodo en el diagrama, permite la creación de las relaciones entre nodos. 39 G u í a P r á c t i c a. B P M - S O A

40 Precisamente, el atributo transition to es el que indica hacia donde se dirigirá la ejecución luego de terminar las tareas del nodo que contiene la propiedad. En el ejemplo, luego de que el nodo start-state llamado inicio de la señal, la ejecución pasará directamente al nodo llamado crear vacante DDI. (Recuerde que las siglas y la explicación de cada nodo la puede encontrar en el archivo adjunto a este documento, llamado: Documentación modelo jbpm). Las transiciones y su direccionalidad se pueden ver representadas a través de la propiedad to, la cual tiene como valor el nombre del nodo al cual se deben dirigir. Cuando se crea un modelo con el editor gráfico podrá editar los nombres de las transiciones. Si lo considera importante para su entendimiento, puede poner nombre a todas las transiciones entre nodos. Sin embargo, los casos más relevantes para realizar esta acción es cuando se tiene nodos de decisión. Fíjese en la sección que está en azul, en ella se aclara que dependiendo de la decisión, el nodo destino será requiere publicación o notificacion encargado ORL_PC DDI. (Recuerde que las siglas y la explicación de cada nodo la puede encontrar en el archivo adjunto a este documento, llamado: Documentación modelo jbpm). A continuación, se mostrará un segmento del código JPDL que corresponde a la imagen del demo de jbpm. Si desea ver el código entero de ambos diagramas, podrá ver los archivos adjuntos a esta guía titulados: Selección XML y Contratación XML. Las etiquetas resaltadas en color verde muestran como cada tipo de nodo es traducido al lenguaje JPDL con el cual se podrán hacer posteriores referencias a métodos de clases o servicios del bus que permitan desarrollar determinada funcionalidad. Por ejemplo, un nodo de tarea será identificado con la etiqueta: tasknode; un nodo de decisión lo identificará con la etiqueta: decision; un nodo de correo electrónico lo identificará con la etiqueta: mail-node. El código resaltado en color rojo muestra un ejemplo de cómo, al dibujar un nodo start en el diagrama, automáticamente se crea este código para ilustrar el nodo de inicio y la primera transición hacia donde se dirige. En el código resaltado en azul, se da el ejemplo de un nodo de decisión, el cual dentro de sus transiciones incluye el atributo name, para que la persona que interpreta el diagrama pueda seguir la secuencia de acciones cuando existe una decisión por tomar y dependiendo de su resultado la ejecución seguirá por un camino u otro. <?xml version="1.0" encoding="utf-8"?> <process-definition xmlns="" name="seleccion catedra"> <start-state name="inicio"> <transition to="crear vacante DDI"></transition> </start-state> <task-node name="crear vacante DDI"> <transition to="revision de la vacante ORL_PC"></transition> </task-node> <task-node name="revision de la vacante ORL_PC"> <transition to="aprobacion de la vacante"></transition> </task-node> 40 G u í a P r á c t i c a. B P M - S O A

41 <decision name="aprobacion de la vacante"> <transition to="requiere publicacion" name="si"></transition> <transition to="notificacion encargado ORL_PC - DDI" name="no"></transition> </decision> <decision name="requiere publicacion"> <transition to="publicar vacante externo" name="si"></transition> <transition to="publicar vacante sistema" name="no"></transition> </decision> <mail-node name="notificacion encargado ORL_PC - DDI"> <transition to="eliminacion de vacante"></transition> </mail-node> <node name="publicar vacante externo"> <transition to="publicar vacante sistema"></transition> </node> <node name="publicar vacante sistema"> <transition to="elaboracion hoja de vida C"></transition> </node> <task-node name="elaboracion hoja de vida C"> <transition to="asociar candidato DDI"></transition> </task-node> (...) <end-state name="fin"></end-state> </process-definition> Ilustración 19. Estructura del código jpdl generado por el grafo Igualmente, en el caso del modelo para la contratación de profesores de cátedra de la Pontificia Universidad Javeriana (Ver imagen adjunta a este documento: GRH jbpm Modelo Contratación), se generó un archivo XML en lenguaje JPDL que encontrará en un documento adjunto a esta guía titulado: Contratación XML. Podrá observar que en el caso del nodo de decisión también se modificó el nombre de las transiciones. Tenga en cuenta que los cambios realizados en éste archivo, se verán reflejados automáticamente en la pestaña Diagram. Más adelante, veremos más atributos que pueden ser agregados a la hora de programar acciones determinadas que deben ser ejecutadas por cada nodo. 41 G u í a P r á c t i c a. B P M - S O A

42 6. Implantación del proceso de negocio usando la consola de JBoss 6.1. Introducción La aplicación web de la Consola de jbpm cumple con varios propósitos. En primer lugar, sirve como una interfaz central de usuario para interactuar con las tareas en tiempo de ejecución generadas por la ejecución de procesos. En segundo lugar, se trata de una consola de administración y monitoreo que permite inspeccionar y manipular instancias de ejecución. La tercera función es BAM (Business Activity Monitoring) Estas son las estadísticas sobre las ejecuciones del proceso. Esta información es útil para los gerentes ya que pueden encontrar cuellos de botella o generar otro tipo de optimizaciones [26]. Ilustración 20. Vista general de los componentes de la consola [27] El desarrollo para ejecución en Consola brinda varios beneficios, entre los que se encuentra un desarrollo más rápido de la aplicación debido a que no requiere de un trabajo intenso en el diseño gráfico. La consola ya provee un entorno en el cual solo se deben especificar los campos de los formularios necesarios para la realización de las tareas humanas y, del modo que veremos, se vinculan los nodos del proceso a estos formularios. Sin embargo, tenga en cuenta que esta consola es estándar, por lo cual si usted requiere de un nivel de personalización mayor deberá recurrir al desarrollo de una aplicación. Para acceder a la consola debe tener un servidor activo y luego, a través de un navegador web, ingresar a la dirección: En ella encontrará una pantalla de bienvenida, la cual tendrá una sección para que se identifique con cualquiera de los usuarios y contraseñas definidos, los cuales deberán tener diferentes permisos sobre el proceso en ejecución. Para la asignación de estos permisos y la correspondiente creación de usuarios y contraseñas, remítase a la siguiente sección donde se dará la demostración de cómo hacerlo. 42 G u í a P r á c t i c a. B P M - S O A

43 6.2. Demo Alcance Dado que para mostrar la funcionalidad de la consola es innecesario desarrollar por completo los dos procesos, se realizará el demo tomando como ejemplo solo una parte del proceso de selección de profesores de cátedra. Se ilustraran los nodos más importantes: nodo de inicio, nodo de finalización de proceso, correo electrónico, tarea humana, nodo de decisión y llamado a un servicio del bus. Podrá ver el alcance en la siguiente imagen: Ilustración 21. Alcance del desarrollo del demo utilizando la Consola Formularios A. Complemento de código en el nodo Una de las funciones de la consola de jbpm permite enlazar formularios con nodos de tarea. A través de estos formularios usted podrá mostrar o recopilar información necesaria para la continuidad de su proceso. En el demo adjunto a este documento usted encontrara en la carpeta processdefinition los archivos de extensión.xhtml (páginas web) que son enlazados a los nodos de tarea. Se va a tomar como ejemplo el nodo de tarea llamado: crear vacante DDI. Fíjese en el código que se debe agregar para realizar el enlace. 43 G u í a P r á c t i c a. B P M - S O A

44 Con color azul verá las variables del formulario que debe llenar la persona. En este caso, la variable es llamada tipo_vacante y el usuario que tenga acceso a esta tarea tendrá los permisos de escritura (write) y lectura (read). Además se indica que antes de pasar a la siguiente etapa, el usuario deberá ingresar este valor obligatoriamente. Eso se indica con la palabra required. Por otro lado, y muy importante para la seguridad, fíjese en la sección resaltada en color naranja. El valor asignado a la variable llamada actor-id es la que corresponde al rol que podrá tener permisos sobre esta tarea. La forma de crear estos roles la verá más adelante. También debe asegurarse de poner la etiqueta controller, resaltados en color rojo, dentro de los cuales especificara las variables usadas en el formulario. Ahora, vista la forma de especificar en jpdl las variables que se usarán, podrá ver a continuación la forma de realizar y enlazar el archivo xhtml que le dará soporte gráfico al código realizado. <task-node name="crear vacante DDI"> <task name="crear vacante"> <assignment actor-id="ddi"></assignment> <controller> <variable name="tipo_vacante" access="read,write,required" /> <variable name="unidad_negocio" access="read,write,required" /> <variable name="familia_puesto" access="read,write,required" /> <variable name="posicion" access="write" /> <variable name="cd_puesto" access="read,write,required" /> <variable name="titulo_oferta" access="read,write,required" /> <variable name="fecha_inicial" access="read,write,required" /> <variable name="fecha_final" access="read,write,required" /> <variable name="detalles" access="read,write,required" /> <variable name="publicacion" access="read,write,required" /> </controller> </task> <transition to="revision de la vacante ORL_PC"></transition> </task-node> Ilustración 22. Código en jpdl asociado al formulario de una tarea humana B. Creación de la forma Para ver el código completo de los formularios con extensión.xhtml ingrese a la carpeta del demo llamada processdefinition. A continuación sólo vera secciones orientadas a guiar el entendimiento sobre la forma de creación de formularios. En este caso, se muestra el archivo llamado Vacante.xhtml el cual contiene la orientación gráfica, por darle una definición, sobre el formulario que aparecerá en la consola. Las etiquetas en color rojo delimitan la sección del formulario, sin ellas, no será entendible cuáles campos se deberá incluir en la consola. La etiqueta en color verde sirve para que en el titulo del formulario se muestre el nombre de la tarea que se esta realizando en el momento. La sección de código en color naranja es la forma en que se agrega una celda. Cada celda es un campo en el formulario que contiene un nombre, el cual servirá de guía a la persona que esta llenando los datos, y un valor que corresponde a la asignación que tiene esta variable. Si esta variable ya existe, aparecerá el valor establecido anteriormente, mientras que si no tiene valor alguno, se guardará esta información en el contexto de ejecución de la aplicación. Tenga en cuenta que se esta guardando un vector de variables y por esta 44 G u í a P r á c t i c a. B P M - S O A

45 razón se denomina var[ nombre_de_la_variable ]. El nombre que le de a la variable en un campo debe corresponder al nombre que le dio en el código del proceso escrito en jpdl. La sección en código azul es otro ejemplo de celda de datos donde al contrario de usar un elemento tipo inputtext como en la sección naranja, se uso un selectbooleancheckbox para la necesidad que se requiera. Podrá encontrar una variedad de elementos como estos dentro de la plataforma UI. En este caso concreto, al tener un elemento de tipo CheckBox, dentro de la variable quedaran almacenados dos valores: true o false. True será en caso de que se sea seleccionada la caja y false si ésta se deja vacía. Es importante que tenga en cuenta que tipo de retorno tienen los elementos escogidos. Finalmente, la sección morada indica los botones de acción que se tendrán disponible en el formulario. En este caso, se puede usar los provistos por los componentes tf que principalmente ofrecen: savebutton: Permitirá guardar los datos de la tarea y regresar más tarde a completarla, tomando en cuenta la misma instancia de proceso. cancelbutton: Cancelará y eliminara todos los datos que hayan sido llenados. Finaliza el nodo de tarea. transitionbutton: Da paso a la transición, con una función de guardar ejecutada antes de pasar al siguiente nodo, de tal forma que se siga con la secuencia natural modelada para el proceso. <ui:component> <jbpm:dataform> <f:facet name="header"> <h:outputtext value="#{taskname}"/> </f:facet> <jbpm:datacell> <f:facet name="header"> <h:outputtext value="tipo de vacante:"/> </f:facet> <h:inputtext value="#{var['tipo_vacante']}" /> </jbpm:datacell> ( ) <jbpm:datacell> <f:facet name="header"> <h:outputtext value="requiere publicacion:"/> </f:facet> <h:selectbooleancheckbox name="pub" value="#{var['publicacion']}"/> </jbpm:datacell> <jbpm:datacell> <f:facet name="header"> <h:outputtext value="acciones"/> </f:facet> <tf:savebutton value="guardar"/> <tf:cancelbutton value="cancelar"/> 45 G u í a P r á c t i c a. B P M - S O A

46 <tf:transitionbutton value="crear vacante"/> </jbpm:datacell> </jbpm:dataform> </ui:component> Ilustración 23. Código xhtml del formulario de la tarea humana C. Integración del nodo con la forma Luego de haber realizado las dos secciones anteriores, deberá vincular los archivos para que efectivamente, cuando se ejecute el proceso y se llegue al nodo de tarea estipulado, se llame el formulario indicado para que el usuario pueda ingresar o consultar la información pertinente y se logré la operación deseada. Para vincular el formulario con el nodo debe ingresar al archivo llamado forms.xml dentro de la carpeta de processdefinition, allí encontrará la estructura resaltada en el cuadro rojo. Ilustración 24. Estructura de código en forms.xml Las etiquetas <forms> delimitan el número de formas que se especificarán para la aplicación en consola. Dentro de ellos existen formas individuales con dos atributos: task y form. Para un mejor entendimiento, observe la sección anterior en color verde. El atributo task tiene como valor el nombre que tiene la tarea dentro del nodo y el atributo form tiene el nombre del archivo donde se creo la estructura de la forma. De esta manera, podrá vincular todas sus tareas humanas a una forma creada por usted mismo Creación de usuarios Para crear los usuarios que tendrán permisos sobre cada uno de los nodos, por ejemplo, en el caso de un nodo de tarea aquellos usuarios que podrán ingresar o leer información, debe dirigirse a la carpeta dentro del servidor ~/server/default/deploy/jbpm.esb/jbpm-sql/ y allí editar el archivo llamado import.sql. Dentro de éste encontrará instrucciones de insert dirigidos a tres tablas diferentes que contienen: los usuarios, los grupos de usuarios y finalmente como se asocian esos grupos con los usuarios existentes. 46 G u í a P r á c t i c a. B P M - S O A

47 En este caso vamos a realizar la siguiente inserción de usuarios en la tabla. Como puede ver en el ejemplo, verá que se añadieron los usuarios: DDI (Director de departamento o instituto), ORL_PC (Oficina de relaciones laborales Profesional de compensación) y C (Candidato). En cuanto al ID, usted podrá ingresar cualquier número siempre y cuando sea único en la tabla; CLASS_ hace referencia a si es usuario por lo tanto deberá ir el valor U siempre; NAME_ es el rol del usuario; _ el correo electrónico y PASSWORD_ la contraseña que le asignara a ese rol de usuario. insert into JBPM_ID_USER (ID_,CLASS_,NAME_, _,PASSWORD_) values (5,'U','DDI','ddi@sample.domain','DDI'); insert into JBPM_ID_USER (ID_,CLASS_,NAME_, _,PASSWORD_) values (6,'U','ORL_PC','orl_pc@sample.domain','ORL_PC'); insert into JBPM_ID_USER (ID_,CLASS_,NAME_, _,PASSWORD_) values (7,'U','C','c@sample.domain','C'); Ilustración 25. Código SQL para inserción de usuarios Es importante que recuerde que los nombres de usuario que cree, serán los usados en el código JPDL asociado al diagrama de proceso dentro de la etiqueta assignment. Ilustración 26. Relación de la creación de usuario con el proceso Luego de esto, se crean los grupos de usuario. En este caso crearemos un grupo de usuarios en la tabla JBPM_ID_GROUP. Se tiene un ID_ el cual debe ser único en la tabla, CLASS_ la cual debe ser G ya que se esta creando un grupo, un NAME_ el cual será el nombre del grupo, TYPE_ en este caso se crea para que sea un rol de seguridad y finalmente PARENT_ en el caso de que existan jerarquías dentro de la organización, sin embargo, en este caso como no aplica se deja el valor en NULL. insert into JBPM_ID_GROUP (ID_,CLASS_,NAME_,TYPE_,PARENT_) values (3,'G','user','security-role',NULL); Ilustración 27. Código SQL para inserción de grupos Finalmente, debemos asociar los usuarios creados con el grupo indicado. Para esto, usaremos los ID_ de usuario y de grupo, con la particularidad de que debemos dejar en valor null el NAME_ y el ROLE_ de la membresía, ya que lo hemos definido con anterioridad y en nuestro caso no tendrá ninguna aplicación. Tenga en cuenta que el CLASS_ en este caso se señala con una M de membership. insert into JBPM_ID_MEMBERSHIP (ID_,CLASS_,NAME_,ROLE_,USER_,GROUP_) values (13,'M',NULL,NULL,5,3); 47 G u í a P r á c t i c a. B P M - S O A

48 insert into JBPM_ID_MEMBERSHIP (ID_,CLASS_,NAME_,ROLE_,USER_,GROUP_) values (14,'M',NULL,NULL,6,3); insert into JBPM_ID_MEMBERSHIP (ID_,CLASS_,NAME_,ROLE_,USER_,GROUP_) values (15,'M',NULL,NULL,7,3); Ilustración 28. Código SQL para relación de usuarios con grupos Luego de realizar esta creación de usuarios, grupos y membresías en la base de datos, el usuario podrá ingresar a la consola de jbpm y tomar parte de los nodos bajo los cuales se les ha dado permiso de manejo Nodo de correo electrónico La versión de jbpm 3.X no soporta SSL ni STARTTLS, por lo tanto, esta dificultad hace que no se pueda implementar un nodo de correo electrónico usando un servidor como Gmail. Sin embargo, existe una solución a este inconveniente la cual consiste en cambiar el tipo de nodo de mail-node a un node. Luego, con este nodo, se llamará una acción ejecutada desde una clase que permite enviar correos electrónicos. A continuación, verá el desarrollo de esta solución. Primero, en el código escrito en JPDL del nodo tipo node, deberá agregar la siguiente acción: <node name="notificacion encargado ORL_PC - DDI"> <action name="mail" class="org.jboss.soa.esb.mail.enviarmail"> </action> <transition to="crear vacante DDI"></transition> </node> Ilustración 29. Estructura del nodo para enviar un correo electrónico La parte resaltada en rojo indica la ubicación de la clase que tiene el método a ejecutar para enviar un correo electrónico. Dentro de esta clase usted encontrará lo siguiente. Tenga en cuenta que la clase, resaltada en color rojo, deberá llamarse de la misma forma descrita en la sección de código anterior. public class Enviarmail implements ActionHandler public void execute(executioncontext arg0) throws Exception { Properties props = new Properties(); props.put("mail.smtp.host", "smtp.gmail.com"); props.put("mail.smtp.socketfactory.port", "465"); props.put("mail.smtp.socketfactory.class", "javax.net.ssl.sslsocketfactory"); props.put("mail.smtp.auth", "true"); props.put("mail.smtp.port", "465"); props.put("mail.smtp.starttls.enable", "true"); Session session = Session.getDefaultInstance(props, new javax.mail.authenticator() { protected PasswordAuthentication getpasswordauthentication() { return new PasswordAuthentication("usuarioejemplo", "contraseñaejemplo"); } 48 G u í a P r á c t i c a. B P M - S O A

49 }); try { Message message = new MimeMessage(session); message.setfrom(new InternetAddress("emisor@ejemplo.com")); message.setrecipients(message.recipienttype.to, InternetAddress.parse("recipiente@ejemplo.com")); message.setsubject("[asunto de prueba] Notificación proceso de selección"); message.settext("estimado señor(a)," + "\n\n Su solicitud ha sido rechazada. Modifíquela y envíela de nuevo."); Transport.send(message); System.out.println(" enviado"); } catch (MessagingException e) { throw new RuntimeException(e); } } } Ilustración 30. Método para el envío de un correo electrónico El método resaltado en color azul es el que indica que su contenido se debe ejecutar tan pronto como el nodo llame esta acción. Dentro de este método se encuentran varias secciones resaltadas en color naranja. A continuación se hará una descripción de cada una de ellas y cómo, para el caso de gmail, usted deberá configurarlas: Mail.smtp.host: este atributo deberá tener la característica STMP que usará para enviar los correos. En el ejemplo usted ve que se usara gmail. Para los demás atributos de configuración del servidor de correos puede consultar la documentación del servicio que desee usar y fijar estos valores. Usuarioejemplo y contraseñaejemplo: Se deberá tener una cuenta de correo electrónico con contraseña, y esos valores se deberán escribir en este campo. emisor@ejemplo.com: Este es el correo del cuál será emitido el mensaje. recipiente@ejemplo.com: Este es el correo al cuál será remitido el mensaje. [Asunto de prueba]: Acá podrá especificar el asunto con el cual enviará el mensaje. Texto del mail: El texto que enviará en el mensaje Nodo de decisión Estos nodos basan su decisión dependiendo del valor que tenga uno de los objetos contenido en cualquiera de los formularios. Por ejemplo, un nodo de decisión determinaría hacia donde enviar el token de ejecución dependiendo de si un checkbox esta o no seleccionado o también si se escribió determinada palabra en un área de texto. En el caso de éste demo, el primer nodo de decisión se relaciona con la aprobación o negación de la vacante creada para la contratación de un profesor. Por lo tanto, a continuación veremos el código escrito en JPDL derivado de la diagramación del modelo y cómo, en la sección resaltada en rojo, se fija el atributo expression para consultar el valor de la variable, en este caso, un checkbox. 49 G u í a P r á c t i c a. B P M - S O A

50 El atributo expression mira el valor con el que haya sido enviando el checkbox dentro del formulario en el momento en que llega al nodo de decisión. Si su valor fue true, fijará la respuesta como un verdadero y seguirá su ejecución mediante la transición que tenga en su atributo name el mismo valor. En el caso contrario, la ejecución se dirigirá a través de la transición con name falso. <decision name="aprobacion de la vacante" expression="#{(aprob.value == true)?'verdadero':'falso'}"> <transition to="requiere publicacion" name="verdadero"></transition> <transition to="notificacion encargado ORL_PC - DDI" name="falso"></transition> </decision> Ilustración 31. Estructura del nodo de decisión Por otro lado, tenga en cuenta que la celda en el archivo revision_vacante.xhtml se debe relacionar, como se menciono en la sección 6.2.2, con la variable del checkbox. Además, en este momento es importante el name que se le haya dado también en la celda. Compare el atributo expression resaltado con rojo en la sección anterior y verá que su contenido hace un llamado a aprob.value, ahora mire la siguiente sección de código resaltada en rojo y verá que se tiene el mismo nombre aprob. El llamado a su value, se hace para saber si fue o no checkeado. <jbpm:datacell> <f:facet name="header"> <h:outputtext value="es aprobada:"/> </f:facet> <h:selectbooleancheckbox name="aprob" value="#{var['aprobacion']}"/> </jbpm:datacell> Ilustración 32. Estructura de la celda para el checkbox de aprobación Nodos para llamar servicios web Como se habló en la sección 5.2.2, los nodos tipos node dan la libertad para realizar acciones más complejas que la toma de una decisión o de la realización de una tarea humana. Una de las situaciones frecuentes es invocar servicios de sistemas existentes dado que en general los procesos de negocio modelan integración de múltiples sistemas de la empresa. Esta integración se puede realizar a través de la invocación de servicios web, los cuales pueden ser creados internamente en la organización, adquirirlos gratis o bajo algún tipo de licenciamiento. El alcance de esta guía no abarca el tema de conceptos y gestión de servicios web, sin embargo, si se mostrará el camino para usarlos en un modelo de proceso, desarrollado con las herramientas de JBoss. Para comenzar, y dado nuestro ejemplo del proceso de selección de profesores de cátedra, crearemos un servicio web para el nodo que implica publicación de una vacante en un sistema externo. Primero, se debe crear un nuevo proyecto siguiendo la siguiente ruta: File New Project Java / Java Project. Se da el nombre que se desee y se acepta la creación del mismo. Dentro del proyecto se debe crear una clase que contendrá el servicio web. 50 G u í a P r á c t i c a. B P M - S O A

51 Ilustración 33. Ruta de creación del servicio web Como puede ver en la ilustración anterior, se creo la clase siguiendo una ruta determinada. Esta práctica es recomendada como una forma de tener un orden y estándar para la creación de servicios web. La ruta de carpetas o paquetes índica que se alojará y podrá ser consultado en la dirección En la última carpeta es donde se debe poner la clase creada. Esta clase tendrá en su implementación los métodos web que podrán ser invocados cuando se tenga acceso al servicio web. A continuación puede ver un ejemplo sencillo de la implementación de un servicio web, éste puede tener la complejidad que desee otorgarle. Tenga en cuenta las anotaciones que debe Dentro de la clase puede crear tantos métodos web como sean necesarios para sus operaciones, o bien, esto es lo que hacen los proveedores cuando le ofrecen a usted una licencia por el uso de algún servicio web ya creado, como servicios de pago desde tarjetas de crédito, entre otros. Además de las anotaciones anteriores, también ésta se usa dentro de los métodos cuando necesite que lleguen a ellos valores por parámetro. Por ejemplo, si necesitara un parámetro llamado identificación en el método publicar(), debería mostrarlo de la siguiente manera: import javax.ejb.stateless; import javax.jws.webmethod; import javax.jws.webservice; publicar(@webparam(name = identificacion ) = "publicar_ext_vac_ws", targetnamespace = " public class publicar_ext_vac_ws public void publicar() { System.out.println("Publicando en un sistema externo"); } } Ilustración 34. Estructura de la clase que contiene el servicio web 51 G u í a P r á c t i c a. B P M - S O A

52 Una vez creada la clase, debe generar el.jar de la aplicación creada. En Eclipse, se hace dando click derecho sobre el archivo.java (resaltado en la ilustración 33), luego se da click en Export y finalmente se selecciona dentro de la carpeta Java la opción JAR file. Allí deberá dar una ubicación para guardar el archivo. Ilustración 35. Muestra de la búsqueda del.wsdl Ahora, debe copiar el archivo dentro del servidor que este usando en la siguiente ruta: ~/server/default/deploy. Una vez puesto dentro de esta carpeta, inicie el servidor y cuando termine de hacerlo, diríjase a la siguiente dirección: Allí encontrará el archivo.wsdl del servicio publicado, el cual es el descriptor del servicio web creado y publicado. Éste archivo será usado dentro de nuestro proyecto principal para invocar los métodos del servicio web. Para obtenerlo, debe dar click derecho y descargarlo en una carpeta de su computador. A partir de éste archivo y haciendo uso de uno de los plugins instalados (JAX WS), los cuales generan clases proxy que permiten la conexión, realice sobre el proyecto principal las siguientes acciones: New Web Service Client. Allí indique la ruta donde se encuentra el wdsl y luego el directorio de salida. Con este plugin se van a generar clases e interfaces esenciales para la invocación del servicio web creado. Las interfaces son las siguientes: publicar_ext_vac_ws y publicar_ext_vac_wsservice y las clases son: publicar_ext_vac_wsservicelocator, publicar_ext_vac_wsbindingstub y publicar_ext_vac_wsproxy [28]. Ahora, de la misma forma que se hace con el nodo de enviar el correo electrónico, debemos crear una clase para invocar el servicio web, atando el método a una acción llamada desde el nodo. Para realizar esto, cree una clase dentro de la carpeta: org.ejemplo.jboss.soa.esb.invocacionws, de la siguiente manera: public class invocarwsext implements ActionHandler public void execute(executioncontext arg0) throws Exception { try { Publicar_ext_vac_wsProxy pwse = new Publicar_ext_vac_wsProxy(); pwse.publicar(); } catch (RemoteException e) { 52 G u í a P r á c t i c a. B P M - S O A

53 } } e.printstacktrace(); } return null; Ilustración 36. Estructura de la celda para el checkbox de aprobación En la ilustración 36 puede ver cómo, en color verde, se crea una instancia del proxy generado previamente automáticamente, y luego usando ese proxy, llama al método que desea ejecutar. De esta forma, cuando ejecute el proceso y pase por este nodo, se llamará al método del web service deseado, dando un rango más amplio de posibilidades de desarrollo para sus propósitos Uso del bus de servicios Ahora veremos cómo se pueden implementar los nodos de correo electrónico y los llamados a servicios web aprovechando el bus de servicios, el cuál finalmente, es el motor que permitirá a la empresa tener más flexibilidad, escalabilidad e integridad. Ilustración 37. Cambio de tipo de nodos Se deben modificar cuatro archivos que atañen a la configuración del bus de servicios, con el propósito de crear las colas, los listeners y los servicios como tal que podrán ser invocados desde un modelo de jbpm. El primero de ellos es: hornetq-jms.xml. En este archivo se declara la creación de la cola que nos servirá para invocar el servicio que necesitemos. En las ilustraciones 38 y 39 verá el ejemplo tanto de la cola para el correo electrónico como para la invocación de servicios web. <queue name="quickstart_bpm_orchestration4_enviarmail_service_esb"> <entry name="queue/quickstart_bpm_orchestration4_enviarmail_service_esb"/> </queue> Ilustración 38. Creación de la cola para el servicio de correo electrónico en el descriptor hornetqjms.xml <queue name="quickstart_bpm_orchestration4_publicarwsext_service_esb"> <entry name="queue/quickstart_bpm_orchestration4_publicarwsext_service_esb"/> </queue> Ilustración 39. Creación de la cola para el servicio de invocación de un servicio web en el descriptor hornetq-jms.xml Usted podrá dar cualquier nombre a estas colas siempre y cuando sea antecedida por la sentencia: queue/(nombre de la cola). El segundo y tercer archivo se encargan de la creación de los Managed Beans (mbeans) dentro del servidor de mensajes (JMS) y el servidor para monitorear los servicios publicados (JMX). En ambos deben existir sentencias que aseguren el funcionamiento de los servicios que posteriormente serán llamados desde el bus de servicios. 53 G u í a P r á c t i c a. B P M - S O A