Guía práctica - Trabajos de Grado | Ingeniería de Sistemas

Transcripción

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, [email protected]
Directora: Ing. María Consuelo Franky de Toro, [email protected]
Bogotá D.C. Segundo semestre del año 2011
Índice
Tabla de ilustraciones ..........................................................................................................................................4
1.
2.
3.
4.
5.
Introducción ..................................................................................................................................................6
1.1.
Acerca de la guía .................................................................................................................................6
1.2.
Acerca del demo ..................................................................................................................................6
1.2.1.
Descripción del Proceso de selección .........................................................................................6
1.2.2.
Descripción del Proceso de contratación .....................................................................................8
1.2.3.
Descripción del Demo ..................................................................................................................9
Conceptos de BPM y su implantación con herramientas SOA ................................................................. 10
2.1.
Procesos de negocio ......................................................................................................................... 10
2.2.
Gestión de Procesos de negocio (BPM) ........................................................................................... 11
2.2.1.
Definición ................................................................................................................................... 11
2.2.2.
¿Qué hace BPM? ...................................................................................................................... 12
2.3.
Arquitectura orientada a servicios (SOA) .......................................................................................... 13
2.4.
Bus de servicios empresariales (ESB) .............................................................................................. 16
Instalación de herramientas ...................................................................................................................... 18
3.1.
Eclipse ............................................................................................................................................... 18
3.2.
Plugins ............................................................................................................................................... 18
3.3.
JBoss AS ........................................................................................................................................... 19
3.4.
JBoss ESB ........................................................................................................................................ 19
Modelación de procesos en BPMN ........................................................................................................... 20
4.1.
Introducción ....................................................................................................................................... 20
4.2.
Demo ................................................................................................................................................. 21
4.2.1.
Proceso de selección .................................................................................................................... 22
4.2.2.
Proceso de contratación ............................................................................................................... 23
Modelación de procesos en jBPM............................................................................................................. 25
5.1.
Introducción ....................................................................................................................................... 25
5.2.
¿Qué permite modelar el editor gráfico de jBPM? ............................................................................ 26
5.2.1.
Descripción general .................................................................................................................. 26
5.2.2.
Nodos ........................................................................................................................................ 27
A.
B.
C.
D.
E.
F.
G.
Responsabilidad de los Nodos ...................................................................................................... 27
Tipo de Nodo: Tarea ..................................................................................................................... 27
Tipo de Nodo: Estado .................................................................................................................... 27
Tipo de Nodo: Decisión ................................................................................................................. 27
Tipo de Nodo: Fork........................................................................................................................ 28
Tipo de Nodo: Join ........................................................................................................................ 28
Tipo de Nodo: Nodo ...................................................................................................................... 28
2|Guía Práctica. BPM - SOA
H.
I.
J.
K.
5.2.3.
5.3.
Adaptación a partir de un modelo BPMN .......................................................................................... 31
5.4.
Demo ................................................................................................................................................. 35
5.4.1.
6.
Tipo de Nodo: Start-State .............................................................................................................. 29
Tipo de Nodo: End-State ............................................................................................................... 29
Tipo de Nodo: Mail-Node .............................................................................................................. 29
Tipo de Nodo: ESB-Service .......................................................................................................... 29
Transiciones .............................................................................................................................. 29
Archivo XML generado .............................................................................................................. 39
Implantación del proceso de negocio usando la consola de JBoss ......................................................... 42
6.1.
Introducción ....................................................................................................................................... 42
6.2.
Demo ................................................................................................................................................. 43
6.2.1.
Alcance ...................................................................................................................................... 43
6.2.2.
Formularios ............................................................................................................................... 43
A.
Complemento de código en el nodo ............................................................................................ 43
B.
Creación de la forma .................................................................................................................... 44
C. Integración del nodo con la forma ................................................................................................ 46
6.2.3.
Creación de usuarios ................................................................................................................ 46
7.
6.2.4.
Nodo de correo electrónico ....................................................................................................... 48
6.2.5.
Nodo de decisión....................................................................................................................... 49
6.2.6.
Nodos para llamar servicios web .............................................................................................. 50
6.2.7.
Uso del bus de servicios ........................................................................................................... 53
Integración de una aplicación JEE5 con el bus de servicios de JBoss .................................................... 58
7.1.
8.
Introducción ....................................................................................................................................... 58
7.1.1.
Anotación @CreateProcess ...................................................................................................... 58
7.1.2.
Anotación @ResumeProcess ................................................................................................... 58
7.1.3.
Anotación @StartTask .............................................................................................................. 58
7.1.4.
Anotación @BeginTask ............................................................................................................. 59
7.1.5.
Anotación @EndTask ............................................................................................................... 59
7.1.6.
Relación Entre Anotaciones ...................................................................................................... 60
Referencias ............................................................................................................................................... 61
Tabla de ilustraciones
Ilustración 1. Relación entre servicios de negocio y procesos en SOA [18] .................................................... 10
Ilustración 2. Ejemplo de un modelo en notación BPMN [19] ........................................................................... 12
Ilustración 3. Elementos arquitecturales de SOA [18] ...................................................................................... 14
Ilustración 4. Perspectiva empresarial de SOA [18] ......................................................................................... 15
Ilustración 5. Arquitectura del bus de servicios empresariales ......................................................................... 16
Ilustración 6. Ejemplo de proceso en BPMN [19] ............................................................................................. 20
Ilustración 7. Proceso de selección de profesores de cátedra de la Pontificia Universidad Javeriana ............ 23
Ilustración 8. Proceso de contratación de profesores de cátedra de la Pontificia Universidad Javeriana ....... 24
Ilustración 9. Ejemplo inicial de un modelo desarrollado con jBPM ................................................................. 26
Ilustración 10. Creación de un nuevo proyecto ................................................................................................ 35
Ilustración 11. Asignando nombre a un nuevo proyecto ................................................................................... 35
Ilustración 12. Creación de un nuevo elemento ............................................................................................... 36
Ilustración 13. Creación del elemento Process Definition ................................................................................ 36
Ilustración 14. Nombrando el proceso .............................................................................................................. 37
Ilustración 15. Partes importantes para la realización de diagramas ............................................................... 37
Ilustración 16. Demo en notación BPMN .......................................................................................................... 38
Ilustración 17. Demo jBPM................................................................................................................................ 39
Ilustración 18. Pestañas de navegación en Eclipse ......................................................................................... 39
Ilustración 19. Estructura del código jpdl generado por el grafo ....................................................................... 41
Ilustración 20. Vista general de los componentes de la consola [27] ............................................................... 42
Ilustración 21. Alcance del desarrollo del demo utilizando la Consola ............................................................. 43
Ilustración 22. Código en jPDL asociado al formulario de una tarea humana .................................................. 44
Ilustración 23. Código xhtml del formulario de la tarea humana....................................................................... 46
Ilustración 24. Estructura de código en forms.xml ............................................................................................ 46
Ilustración 25. Código SQL para inserción de usuarios .................................................................................... 47
Ilustración 26. Relación de la creación de usuario con el proceso ................................................................... 47
Ilustración 27. Código SQL para inserción de grupos ...................................................................................... 47
Ilustración 28. Código SQL para relación de usuarios con grupos .................................................................. 48
Ilustración 29. Estructura del nodo para enviar un correo electrónico ............................................................. 48
Ilustración 30. Método para el envío de un correo electrónico ......................................................................... 49
Ilustración 31. Estructura del nodo de decisión ................................................................................................ 50
Ilustración 32. Estructura de la celda para el checkbox de aprobación ........................................................... 50
Ilustración 33. Ruta de creación del servicio web ............................................................................................. 51
Ilustración 34. Estructura de la clase que contiene el servicio web.................................................................. 51
Ilustración 35. Muestra de la búsqueda del .wsdl ............................................................................................. 52
Ilustración 36. Estructura de la celda para el checkbox de aprobación ........................................................... 53
Ilustración 37. Cambio de tipo de nodos ........................................................................................................... 53
Ilustración 38. Creación de la cola para el servicio de correo electrónico en el descriptor hornetq-jms.xml ... 53
Ilustración 39. Creación de la cola para el servicio de invocación de un servicio web en el descriptor hornetqjms.xml .............................................................................................................................................................. 53
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 ...................................................................................................................................... 54
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 ..................................................................................................................... 54
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 .................................................................................................................................... 54
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 ................................................................................................................... 54
Ilustración 44. Creación de los canales de correo electrónico e invocación de servicio web en el descriptor
jboss-esb.xml .................................................................................................................................................... 55
Ilustración 45. Estructura de los servicios registrados en el bus en el descriptor jboss-esb.xml ..................... 56
Ilustración 46. Líneas a insertar en el descriptor de despliegue de colas del bus en el descriptor
deployment.xml ................................................................................................................................................. 56
Ilustración 47. Cambio en las clases. ............................................................................................................... 57
Ilustración 48. Solicitud de materia prima ......................................................................................................... 60
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.
1.2.
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.
1.2.1. 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.
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.
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 2.
23. 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.
1.2.2. 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.
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.
1.2.3. 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.
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

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].
2.2.
Gestión de Procesos de negocio (BPM)
2.2.1. 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].
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.
2.2.2. ¿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.

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.
2.3.
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].
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.
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]
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].
2.4.
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]:

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.
3. Instalación de herramientas
3.1.
Eclipse
Diríjase al siguiente enlace: http://www.eclipse.org/ganymede/ 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.
3.2.
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:
http://orion.javeriana.edu.co/gf/project/javeviajes/docman/?subdir=7
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-win32-3.0.2.v200909151014R-H192-GA.zip
en el directorio raíz de la instalación de Eclipse. El archivo lo puede encontrar en el siguiente link:
http://es.sourceforge.jp/projects/sfnet_jboss/downloads/JBossTools/JBossTools3.0.x/JBossTools-ALL-win323.0.2.v200909151014R-H192-GA.zip/
Luego se puede invocar Eclipse y abrir las perspectivas agregadas (Web Development y Seam)
3.3.
JBoss AS
Descargue el Application Server de la dirección: http://www.jboss.org/jbossas/downloads/ 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.
3.4.
JBoss ESB
Luego de tener instalado JBoss Application Server, deberá descargar JBoss ESB 4.9 en la siguiente
dirección: http://www.jboss.org/jbossesb/downloads.
Cuando haya descargado la carpeta, regístrela en el IDE Eclipse. Ingrese a jbossesb4.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-4.2.3.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.
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).
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].
4.2.
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: http://www.bizagi.com/.
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
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: http://www.bizagi.com/.
4.2.1.
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.
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.
4.2.2.
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.
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.
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 $500.000 - $1’000.000 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.
5.2. ¿Qué permite modelar el editor gráfico de
jBPM?
5.2.1. 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]
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]
5.2.2. 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 email, 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?
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.
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 email, 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 email
podría ser enviado de la siguiente forma [8]:
<mail-node name="send email" 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.
5.2.3. 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
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]
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.
Eventos de inicio: Indican cuando un proceso inicia,
no tienen flujos de secuencia entrantes.
Inicio
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
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.
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
Subproceso: Actividad compuesta que incluye un
Es usado cuando se necesitan
conjunto
interno lógico de actividades y que puede ser
modelar subprocesos a un alto nivel
analizado en más detalle.
que se requieren dentro del proceso.
Nos permite romper un modelo muy
complejo en varios más manejables.
Subproceso embebido: Depende del proceso padre.
No contiene ni pools ni lanes.
Subproceso reusable: Es un proceso definido como
un diagrama de procesos independiente y que no
depende del proceso padre.
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.
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].
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.
Ilustración 10. Creación de un nuevo proyecto
Asigne un nombre a su proyecto.
Ilustración 11. Asignando nombre a un nuevo proyecto
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
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
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 e-mail 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 e-mail 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
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.
Ilustración 17. Demo jBPM
5.4.1. Archivo XML generado
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.
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>
<decision name="aprobacion de la vacante">
<transition to="requiere publicacion" name="si"></transition>
<transition
name="no"></transition>
to="notificacion
encargado
ORL_PC
-
DDI"
</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.
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: http://localhost:8080/jbpm-console. 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.
6.2.
Demo
6.2.1. 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
6.2.2. 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.
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
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>
<h:outputText value="Tipo de vacante:"/>
</f:facet>
<h:inputText value="#{var['tipo_vacante']}" />
</jbpm:datacell>
(…)
<jbpm:datacell>
<h:outputText value="Requiere publicacion:"/>
</f:facet>
<h:selectBooleanCheckbox name="pub" value="#{var['publicacion']}"/>
</jbpm:datacell>
<jbpm:datacell>
<h:outputText value="Acciones"/>
</f:facet>
<tf:saveButton value="Guardar"/>
<tf:cancelButton value="Cancelar"/>
<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.
6.2.3. 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.
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; EMAIL_ 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_,EMAIL_,PASSWORD_)
(5,'U','DDI','[email protected]','DDI');
insert
into
JBPM_ID_USER
(6,'U','ORL_PC','[email protected]','ORL_PC');
insert
into
JBPM_ID_USER
(7,'U','C','[email protected]','C');
Ilustración 25. Código SQL para inserción de usuarios
values
values
values
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_)
(3,'G','user','security-role',NULL);
Ilustración 27. Código SQL para inserción de grupos
values
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
(13,'M',NULL,NULL,5,3);
(ID_,CLASS_,NAME_,ROLE_,USER_,GROUP_)
values
(14,'M',NULL,NULL,6,3);
(15,'M',NULL,NULL,7,3);
values
values
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.
6.2.4. 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 {
@Override
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");
}
});
try {
Message message = new MimeMessage(session);
message.setFrom(new InternetAddress("[email protected]"));
message.setRecipients(Message.RecipientType.TO,
InternetAddress.parse("[email protected]"));
message.setSubject("[Asunto de prueba] Notificación proceso de
selección");
message.setText("Estimado señor(a),"
+
"\n\n
Su
solicitud
ha
sido
Modifíquela y envíela de nuevo.");
Transport.send(message);
System.out.println("Email enviado");
} catch (MessagingException e) {
throw new RuntimeException(e);
}
}
}
Ilustración 30. Método para el envío de un correo electrónico
rechazada.
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.
[email protected]: Este es el correo del cuál será emitido el mensaje.
[email protected]: 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.
6.2.5. 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.
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>
<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
6.2.6. 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.
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
http://javeriana.edu.co/publicarext. 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 agregar como @Stateless, @WebService y @WebMethod.
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 existe @WebParam, é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:
publicar(@WebParam(name = “identificacion”) String identificacion)
import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebService;
@Stateless
@WebService(name = "publicar_ext_vac_ws", targetNamespace =
"http://javeriana.edu.co/publicarext")
public class publicar_ext_vac_ws {
@WebMethod
public void publicar() {
System.out.println("Publicando en un sistema externo");
}
}
Ilustración 34. Estructura de la clase que contiene el servicio web
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: http://localhost:8080/jbossws/services. 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 {
@Override
public void execute(ExecutionContext arg0) throws Exception {
try {
Publicar_ext_vac_wsProxy pwse = new
Publicar_ext_vac_wsProxy();
pwse.publicar();
} catch (RemoteException e) {
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.
6.2.7. 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.
El código correspondiente al segundo archivo llamado: jbm-queue-service.xml lo verá en las ilustraciones 40
y 41. El código correspondiente al tercer archivo llamado: jbmq-queue-service.xml lo verá en las ilustraciones
42 y 43. Fíjese que las sentencias resaltadas en rojo, las cuales se encargan de citar la cola, deben coincidir
con las vistas en las ilustraciones 38 y 39.
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.esb.quickstart.destination:service=Queue,name=
quickstart_bpm_orchestration4_enviarMail_service_esb"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">
jboss.messaging:service=ServerPeer</depends>
</mbean>
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
<mbean code="org.jboss.jms.server.destination.QueueService"
quickstart_bpm_orchestration4_publicarwsext_service_esb"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">
jboss.messaging:service=ServerPeer</depends>
</mbean>
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
<mbean code="org.jboss.mq.server.jmx.Queue"
quickstart_bpm_orchestration4_enviarMail_service_esb">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
</mbean>
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
<mbean code="org.jboss.mq.server.jmx.Queue"
quickstart_bpm_orchestration4_publicarwsext_service_esb">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
</mbean>
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
Finalmente, tendremos que crear los servicios dentro del descriptor: jboss-esb.xml. Una vez desplegado,
este archivo se encarga de facilitar los servicios para que sean llamados desde el modelo jBPM. Primero,
dentro de los tag <providers> y <jms-provider> deberemos llamar a través de un tag <jms-bus> las colas
creadas con el propósito de darle soporte a cada uno de los servicios, en nuestro caso, el nodo de correo
electrónico y el de invocación a un servicio web.
En la ilustración 44, se detallan en color azul los tags dentro de los cuales deben ser creados los canales,
encargados de hacer uso de las colas creadas para el intercambio de mensajes. El nombre de estos canales
se resalta en color verde y deben ser tenidos en cuenta debido a que más adelante serán referenciados en
los servicios del bus. Recuerde, que las sentencias en color rojo deben coincidir con las enunciadas en la
ilustración 37 y 38.
<providers>
<jms-provider connection-factory="ConnectionFactory"
name="JBossMQ">
(...)
<jms-bus busid="enviarMailChannel">
<jms-message-filter dest-name=
"queue/quickstart_bpm_orchestration4_enviarMail_service_esb"
dest-type="QUEUE" />
</jms-bus>
<jms-bus busid="publicarwsextChannel">
<jms-message-filter dest-name=
"queue/quickstart_bpm_orchestration4_publicarwsext_service_esb"
dest-type="QUEUE" />
</jms-bus>
</jms-provider>
</providers>
Ilustración 44. Creación de los canales de correo electrónico e invocación de servicio web en el
descriptor jboss-esb.xml
Luego, se arma la estructura de los servicios que harán uso de los canales anteriores para la transferencia
de mensajes. Estos servicios deben tener una categoría, la cual usted puede crear de acuerdo a sus
parámetros, por ejemplo, en este caso el atributo category será proceso_Javeriana. Además debe tener un
nombre, útil a la hora de invocar el servicio, y una descripción que hará más entendible la razón de ser del
servicio registrado en el bus.
A continuación, en la ilustración 45 puede ver en color naranja, las categorías de los servicios; en color azul,
sus descripciones; y en color rojo sus nombres. Tenga en cuenta que ninguno de estos parámetros puede
llevar tildes ni ningún otro carácter especial ya que por cuestiones de la herramienta, no permite compilar.
Adicionalmente, en color verde se enuncian los canales previamente definidos y que deben coincidir con las
propiedades de la ilustración 44.
Las acciones, igual que se hacía en la invocación sin usar el bus de servicios, deberán ser indicadas en la
propiedad class, referenciando a la clase donde se encuentra la implementación. Éstas se resaltan con color
morado.
<services>
<service category="proceso_Javeriana" description=
"Envio de correos electronicos" name="enviarMail">
<listeners>
<jms-listener busidref="enviarMailChannel"
name="enviarMailChannel" />
</listeners>
<actions>
<action class="org.jboss.soa.esb.mail.Enviarmail"
name="mail" />
</actions>
</service>
<service category="proceso_Javeriana" description="Publicacion de una
vacante en un sitio externo" name="publicarwsext">
<listeners>
<jms-listener busidref="publicarwsextChannel"
name="publicarwsextChannel" />
</listeners>
<actions>
<action class="org.jboss.soa.esb.invocacionws.invocarwsext"
name="invext" />
</actions>
</service>
</services>
Ilustración 45. Estructura de los servicios registrados en el bus en el descriptor jboss-esb.xml
En este punto, ya se tiene listo el desarrollo que permitirá la invocación de un servicio registrado en el bus.
Sin embargo, es importante que en el descriptor encargado de desplegar las colas, incluya las creadas para
el correo y la invocación del servicio web. Esto se realiza en el archivo llamado: deployment.xml, de la forma
como se ilustra en la ilustración 46.
<jbossesb-deployment>
(...)
<jmsQueue>quickstart_bpm_orchestration4_enviarMail_service_esb</jmsQueue>
<jmsQueue>quickstart_bpm_orchestration4_publicarwsext_service_esb</jmsQueue>
</jbossesb-deployment>
Ilustración 46. Líneas a insertar en el descriptor de despliegue de colas del bus en el descriptor
deployment.xml
Luego de haber realizado los pasos anteriores, ya está lista la configuración para hacer uso del bus de
servicios. Sin embargo, hay que hacer unas pequeñas modificaciones a las clases que ya se tenían de
correo electrónico e invocación de servicio web, como se muestra en la ilustración 47. En color rojo podrá ver
como se deberá extender ahora de una clase llamada AbstractActionPipelineProcessor. Además, el
método ahora será process y devuelve un Message al bus. Adicionalmente es importante que incluya un
constructor, ya que sin éste, no hará deploy el servicio creado. En nombredelaclase usted deberá poner el
nombre con el cual desea identificar la clase, para el ejemplo del demo, este nombre de la clase toma los de:
EnviarMail e invocarwsext.
public class nombredelaclase extends AbstractActionPipelineProcessor {
@Override
public Message process(Message arg0) throws ActionProcessingException {
//Contenido del método
return null;
}
public invocarwsext(ConfigTree configTree) {
}
}
Ilustración 47. Cambio en las clases.
Finalmente, sobre el buildfile registrado del proyecto, oprima la función de deploy para desplegar las colas y
archivos en el servidor. Luego entre a la página de la consola y siga el proceso que ha creado, o bien, si está
ejecutando éste demo, podrá realizar las mismas acciones cómo se índico a través de toda la sección 6.
7. Integración de una aplicación JEE5
con el bus de servicios de JBoss
7.1.
Introducción
En algunos casos, las funcionalidades brindadas por la consola de jBPM no es suficiente para suplir las
necesidades de una organización. Por esta razón, se presentan a continuación una serie de anotaciones
importantes a la hora de acoplar una aplicación Java EE 5 con jBPM, resaltando el uso del framework Seam
y del bus de Servicios dentro de jBPM.
7.1.1. Anotación @CreateProcess
@CreateProcess(definition="process definition name")
Crea una nueva instancia del proceso jBPM cuando el método retorna una salida no nula. El objeto
ProcessInstance estará disponible en la variable de contexto denominada processInstance [29].
Propiedades:
 definition:
El
nombre
de
la
definición
org.jboss.seam.core.jbpm.processDefinitions [29].
del
proceso
jBPM
vía
7.1.2. Anotación @ResumeProcess
@ResumeProcess(processIdParameter="processId")
Vuelve a entrar al alcance de la instancia del proceso existente jBPM cuando el método retorna una salida no
nula. El objeto ProcessInstances estará disponible en la variable de contexto denominada processInstance
[29].
Propiedades:
processIdParameter: Corresponde al nombre del parámetro de solicitud guardando el identificador del
proceso [29].
7.1.3. Anotación @StartTask
Inicia una tarea en jBPM. Especifica que una conversación de larga duración al igual que la anotación @Begin
comienza cuando el método retorna una salida no nula. Esta conversación está asociada con la tarea de
jBPM especificada en el parámetro de solicitud nombrada, también se define un contexto del proceso de
negocio, para la instancia del proceso de negocio [29].
La instancia de tareas de jBPM estará disponible en la variable de contexto “request” denominada
taskinstance. La instancia del proceso también estará disponible en la variable de contexto “request”
denominada processInstance. Estos objetos están disponibles por inyección @in [29].
Propiedades:
 taskIdParameter: Es el nombre del parámetro de solicitud el cual contiene el identificador de la tarea
[29].

FlushMode: modifica este modo a cualquiera de los manejados por las sesiones Hibernate o el
contexto de persistencia JPA [29].
7.1.4. Anotación @BeginTask
Especifica que una conversación de larga duración comienza cuando el método retorna una salida no nula. Se
asocia con la tarea jBPM especificada en el parámetro de solicitud mencionada [29]. La diferencia entre
@StartTask y @BeginTask es que la primera marca la tarea como iniciada una vez el método retorna de
manera exitosa, la segunda no afecta la tarea, es decir, no modifica ningún valor de la tarea [30].
7.1.5. Anotación @EndTask
Finaliza una tarea jBPM de tipo “Task Node”. Especifica que una conversación de larga duración termina
cuando el método retorna un valor no nulo, y que la tarea actual ha sido completada. Desencadena una
transición jBPM. La transición real disparará la transición por defecto a menos que la aplicación haya llamado
el siguiente método: Transition.setName() [29].
Disparadores de la transición jBPM
@EndTask(transition="transitionName")
Especifica que la tarea termina cuando el método retorna una de las salidas mencionadas.
@EndTask(ifOutcome={"success", "continue"})
Propiedades:
 transition: Corresponde al nombre de la transición jBPM que se disparará cuando termine la tarea. Se
utiliza Defaults a la transición por defecto [29].

ifOutcome: Especifica la salida o salidas JSF (Java Server Faces) que resultan al final de la tarea [29].

beforeRedirect: Por defecto, la conversación no será destruida hasta después de que haya alguna
redirección. Cambiando beforeRedirect a verdadero se especifica que la conversación debería ser
destruida al final de la solicitud actual, y que la redirección será procesada en un nuevo contexto de
conversación [29].
7.1.6. Relación Entre Anotaciones
Con el fin de dar más claridad a las anotaciones presentadas anteriormente se ilustrarán como estas se
relacionan con algunos nodos del ejemplo de una solicitud de materia prima a proveedor.
El nodo Start State se soporta sobre un método
en una clase POJO que se ve de la siguiente
manera [31]:
@CreateProcess(definition="simple")
public void startProcess() {
// Nueva Instancia de la petición
}
Los Task Node también se soportan sobre
clases POJO que contienen métodos con las
anotaciones para conducir a diferentes
transiciones dependiendo del nodo [31].
@StartTask
@EndTask(transition="next")
public void valorMateriaPrima() {
//Operaciones que requiera
}
Ilustración 48. Solicitud de materia prima
8. Referencias
[1] Página oficial del Proyecto JBoss jBPM. Consultada el día 22 de Octubre de 2011:
http://www.jboss.org/jbpm
[2] Información sobre tendencias en la gestión de procesos de negocio 2010. Consultado el día 22 de Octubre
de 2011: http://www.bptrends.com/surveys_landing.cfm
[3] Capítulo 9, Process Modelling. Guía para usuarios de jBPM. Consultado el día 22 de Octubre de 2011:
http://docs.jboss.org/jbpm/v3/userguide/processmodelling.html
[4] Capítulo 18, jBPM Process Definition Language. Guía para usuarios de jBPM. Consultado el 22 de Octubre
de 2011:http://docs.jboss.org/jbpm/v3/userguide/jpdl.html
[5] Jugando con jBPM #4. Start-State Node. Blog Salaboy. Consultado el día 22 de Octubre de 2011:
http://salaboy.wordpress.com/2008/08/21/jugando-con-jbpm-4-start-state-node/
[6] Guía para usuarios de jBPM. Consultado el día 01 de Abril de 2011:
http://docs.jboss.org/jbpm/v3/userguide/
[7] Capítulo 6, Service Orchestration. JBoss Documentation. Consultado el día 22 de Octubre de 2011:
http://docs.redhat.com/docs/en-US/JBoss_Enterprise_SOA_Platform/5/html/ESB_Services_Guide/ch06.html
[8] Capítulo 16, Email Support. Guía para usuarios de jBPM. Consultado el día 22 de Octubre de 2011:
http://docs.jboss.org/jbpm/v3/userguide/mail.html
[9] JBoss jBPM 2.0 jPDL Reference Manual. Consultado el día 22 de Octubre de 2011:
http://www.jboss.com/products/jbpm/docs/jpdl/
[10] ESB Service Orchestration with jBPM. Consultado el día 22 de Octubre de 2011:
http://www.mastertheboss.com/soa-a-esb/120-esb-service-orchestration-with-jbpm.html
[11] Romero, Cristian; Arias, Laura. Características y posibilidades con jBPM 3.X. Proyecto especial SOABPM. Pontificia Universidad Javeriana. 2011.
[12] Macroproceso gestión del talento Humano, Proceso selección. Oficina de organización y métodos.
Consultado el día: 24 de Agosto de 2011. Disponible en:
http://www.javeriana.edu.co/puj/viceadm/oym/ppd/documentos4-DGRH-TH-11.html
[13] Matt Cumberlige, Business Process Management with JBoss jBPM, A practical guide for business
analysts, Packt Publishing, 2007.
[14] BPMN Guía de Referencia, Bizagi.
[15] JBoss jBPM 2.0 jPDL Reference Manual. Consultado el día 22 de Octubre de 2011:
http://www.jboss.com/products/jbpm/docs/jpdl/
[16] Z. E. Akkaoui and E. Zimányi. Defining ETL worfklows using BPMN and BPEL. In DOLAP, pp. 41-48,
2009.
[17] C. Ouyang, M. Dumas, W. M. P. van der Aalst, A. H. M. ter Hofstede, and J. Mendling. From Business
Process Models to Process-Oriented Software systems. ACM Trans. Softw. Eng. Methodol., 19(1), 2009.
[18] Rosen, Michael; Lublinsky, Boris; Smith, Kevin; Balcer, Marc. Applied SOA – Service Oriented
Architecture and design strategies. Wiley Publishing. 2008.
[19] White, Stephen; Miers, Derek; Fisher, Layna; Moreno, Juan. BPMN Guía de Referencia y Modelado:
Comprendiendo y Utilizando BPMN. 2010.
[20] R.K. Ko, “A Computer Scientist’s Introductory Guide to Business Process Management (BPM),”
Crossroads, Vol. 15, No. 4, 11–18 (2009).
[21] Valani, D. and Chawan, R. K. and Ghazali, S. SOA enabled BPM rule engine. Proceedings of the
International Conference; Workshop on Emerging Trends in Technology. 2011
[22] Yang Liu; Enzhao Hu; Xudong Chen;, "Architecture of Information System Combining SOA and BPM,"
Information Management, Innovation Management and Industrial Engineering, 2008. ICIII '08. International
Conference on , vol.1, no., pp.42-45, 19-21 Dec. 2008
[23] Kiran K. Garimella; Bruce D. Williams; Michael J. Lees. BPM Basic for Dummies.
[24] Mike P. Papazoglou, Willem-Jan van den Heuvel; Service oriented architectures: approaches,
technologies and research issues, The VLDB Journal. Springer – verlag. 2007.
[25] Kennedy , Mark. Oracle BPEL Process Manager Quick Start Guide, 10g. BPEL Process Manager.
Oracle. Septiembre 2006.
[26] The jBPM console web application. Jboss. RedHat documentation.
[27] Chapter 1. Introduction. JBoss jBPM jPDL 3.2. jBPM jPDL user guide.
[28] Franky, Maria Consuelo. Aspectos avanzados en las aplicaciones Java EE 5. Parte G. Desarrollo de
aplicaciones Java EE 5 en base a Frameworks. Pontificia Universidad Javeriana.
[29] Información sobre anotaciones JEE que soportan jBPM. Consultado el día 27 de Enero de 2012:
http://docs.jboss.org/seam/1.2.1.GA/reference/en/html/annotations.html
[30] Dan Allen, Seam In Action, Mannin Publications 2009, Chapter 14.
[31] Información sobre anotaciones Jbpm. Consultado el día 27 de Enero de 2012:
http://mastertheboss.com/seam/90-seam-jbpm.html

Guía práctica - Trabajos de Grado | Ingeniería de Sistemas

Transcripción

Documentos relacionados

Nostalgia de futuro, homenaje a Renau de ISIDRO

ILUSTRACIÓN, PUBLICIDAD Y DISEÑO CON CÓMIC

manual de uso de recursos electrónicos para investigación

JBoss jBPM 3 - JBoss.org Documentation

El Libro del BPM