Modelado e implementación de un proceso de negocio...

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

mailto:[email protected]

mailto:[email protected]

2 | G u í a P r á c t i c a . B P M - S O A

Índice

Tabla de ilustraciones ..........................................................................................................................................4

1. 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

2. 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

3. Instalación de herramientas ...................................................................................................................... 18

3.1. Eclipse ............................................................................................................................................... 18

3.2. Plugins ............................................................................................................................................... 18

3.3. JBoss AS ........................................................................................................................................... 19

3.4. JBoss ESB ........................................................................................................................................ 19

4. 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

5. 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. Responsabilidad de los Nodos ...................................................................................................... 27

B. Tipo de Nodo: Tarea ..................................................................................................................... 27

C. Tipo de Nodo: Estado .................................................................................................................... 27

D. Tipo de Nodo: Decisión ................................................................................................................. 27

E. Tipo de Nodo: Fork........................................................................................................................ 28

F. Tipo de Nodo: Join ........................................................................................................................ 28

G. Tipo de Nodo: Nodo ...................................................................................................................... 28


H. Tipo de Nodo: Start-State .............................................................................................................. 29

I. Tipo de Nodo: End-State ............................................................................................................... 29

J. Tipo de Nodo: Mail-Node .............................................................................................................. 29

K. Tipo de Nodo: ESB-Service .......................................................................................................... 29

5.2.3. Transiciones .............................................................................................................................. 29

5.3. Adaptación a partir de un modelo BPMN .......................................................................................... 31

5.4. Demo ................................................................................................................................................. 35

5.4.1. Archivo XML generado .............................................................................................................. 39

6. 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

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

7. Integración de una aplicación JEE5 con el bus de servicios de JBoss .................................................... 58

7.1. 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

8. 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 hornetq-

jms.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 sub-

procesos 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]


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-win32-3.0.2.v200909151014R-H192-GA.zip/ Luego se puede invocar Eclipse y abrir las perspectivas agregadas (Web Development y Seam)

http://www.eclipse.org/ganymede/

http://orion.javeriana.edu.co/gf/project/javeviajes/docman/?subdir=7

http://es.sourceforge.jp/projects/sfnet_jboss/downloads/JBossTools/JBossTools3.0.x/JBossTools-ALL-win32-3.0.2.v200909151014R-H192-GA.zip/

http://es.sourceforge.jp/projects/sfnet_jboss/downloads/JBossTools/JBossTools3.0.x/JBossTools-ALL-win32-3.0.2.v200909151014R-H192-GA.zip/


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 jbossesb-

4.9/install/deployment.properties.example y borre la extensión .example de tal forma que éste descriptor

tenga extensión .properties. Luego, ábralo y edite las siguientes propiedades de tal forma que quede como

se indica a continuación:

# application server root directory

org.jboss.esb.server.home=/jboss-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.

http://www.jboss.org/jbossas/downloads/

http://www.jboss.org/jbossesb/downloads


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

http://www.bizagi.com/


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.

http://www.bizagi.com/


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.

Inicio

Solo sirve para indicar que un proceso se ha creado y aún no

comienza su ejecución.

Eventos de inicio: Indican cuando un proceso inicia, no tienen flujos de secuencia entrantes.

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

Especifica la ruta entre nodos.

Pueden tener nombre en el grafo.

Secuencia: representan el control de flujo y secuencia

de los objetos del flujo (actividades, compuertas, eventos).

--------------------------------------------------------------------

Mensaje: representan la interacción entre varios

procesos. No representan flujos de control, representan señales o mensajes.

---------------------------------------------------------------------

Asociaciones: Se usan para asociar información

adicional del proceso.

Subprocesos

Es usado cuando se necesitan

modelar subprocesos a un alto nivel que se requieren dentro del proceso. Nos permite romper un modelo muy complejo en varios más manejables.

Subproceso: Actividad compuesta que incluye un

conjunto interno lógico de actividades y que puede ser analizado en más detalle.

Subproceso embebido: Depende del proceso padre.

No contiene ni pools ni lanes.


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: task-

node; 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 to="notificacion encargado ORL_PC - DDI"

name="no"></transition>

</decision>

<decision name="requiere publicacion">

<transition to="publicar vacante externo" name="si"></transition>

<transition to="publicar vacante sistema" name="no"></transition>

</decision>

<mail-node name="notificacion encargado ORL_PC - DDI">

<transition to="eliminacion de vacante"></transition>

</mail-node>

<node name="publicar vacante externo">

<transition to="publicar vacante sistema"></transition>

</node>

<node name="publicar vacante sistema">

<transition to="elaboracion hoja de vida C"></transition>

</node>

<task-node name="elaboracion hoja de vida C">

<transition to="asociar candidato DDI"></transition>

</task-node>

(...)

<end-state name="fin"></end-state>

</process-definition>

Ilustración 19. Estructura del código jpdl generado por el grafo

Igualmente, en el caso del modelo para la contratación de profesores de cátedra de la Pontificia Universidad

Javeriana (Ver imagen adjunta a este documento: GRH jBPM Modelo Contratación), se generó un archivo

XML en lenguaje JPDL que encontrará en un documento adjunto a esta guía titulado: Contratación XML.

Podrá observar que en el caso del nodo de decisión también se modificó el nombre de las transiciones.

Tenga en cuenta que los cambios realizados en éste archivo, se verán reflejados automáticamente en la

pestaña Diagram. Más adelante, veremos más atributos que pueden ser agregados a la hora de programar

acciones determinadas que deben ser ejecutadas por cada nodo.


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.

http://localhost:8080/jbpm-console


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_) values

(5,'U','DDI','[email protected]','DDI');


(6,'U','ORL_PC','[email protected]','ORL_PC');


(7,'U','C','[email protected]','C');

Ilustración 25. Código SQL para inserción de usuarios

Es importante que recuerde que los nombres de usuario que cree, serán los usados en el código JPDL

asociado al diagrama de proceso dentro de la etiqueta assignment.

Ilustración 26. Relación de la creación de usuario con el proceso

Luego de esto, se crean los grupos de usuario. En este caso crearemos un grupo de usuarios en la tabla

JBPM_ID_GROUP. Se tiene un ID_ el cual debe ser único en la tabla, CLASS_ la cual debe ser ‘G’ ya que

se esta creando un grupo, un NAME_ el cual será el nombre del grupo, TYPE_ en este caso se crea para

que sea un rol de seguridad y finalmente PARENT_ en el caso de que existan jerarquías dentro de la

organización, sin embargo, en este caso como no aplica se deja el valor en NULL.

insert into JBPM_ID_GROUP (ID_,CLASS_,NAME_,TYPE_,PARENT_) values

(3,'G','user','security-role',NULL);

Ilustración 27. Código SQL para inserción de grupos

Finalmente, debemos asociar los usuarios creados con el grupo indicado. Para esto, usaremos los ID_ de

usuario y de grupo, con la particularidad de que debemos dejar en valor null el NAME_ y el ROLE_ de la

membresía, ya que lo hemos definido con anterioridad y en nuestro caso no tendrá ninguna aplicación.

Tenga en cuenta que el CLASS_ en este caso se señala con una ‘M’ de membership.

insert into JBPM_ID_MEMBERSHIP (ID_,CLASS_,NAME_,ROLE_,USER_,GROUP_) values

(13,'M',NULL,NULL,5,3);



(14,'M',NULL,NULL,6,3);


(15,'M',NULL,NULL,7,3);

Ilustración 28. Código SQL para relación de usuarios con grupos

Luego de realizar esta creación de usuarios, grupos y membresías en la base de datos, el usuario podrá

ingresar a la consola de jBPM y tomar parte de los nodos bajo los cuales se les ha dado permiso de manejo.

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 rechazada.

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

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

http://javeriana.edu.co/publicarext


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) {

http://localhost:8080/jbossws/services


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 hornetq-

jms.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 del proceso jBPM vía

org.jboss.seam.core.jbpm.processDefinitions [29].

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.

Ilustración 48. Solicitud de materia prima

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

}


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 SOA-

BPM. 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/

http://www.google.com/url?q=http%3A%2F%2Fwww.jboss.org%2Fjbpm&sa=D&sntz=1&usg=AFQjCNHZrW_NwU-j-bnul2JV4I_5vghpzw









http://www.bptrends.com/surveys_landing.cfm

http://www.google.com/url?q=http%3A%2F%2Fdocs.jboss.org%2Fjbpm%2Fv3%2Fuserguide%2Fprocessmodelling.html&sa=D&sntz=1&usg=AFQjCNFSSmz8hELWNV1GQjSnhDs74M_7Ng

















http://www.google.com/url?q=http%3A%2F%2Fdocs.jboss.org%2Fjbpm%2Fv3%2Fuserguide%2Fjpdl.html&sa=D&sntz=1&usg=AFQjCNHjKcl9os9FTbYZyPD2qFUpPn1JVg

















http://www.google.com/url?q=http%3A%2F%2Fsalaboy.wordpress.com%2F2008%2F08%2F21%2Fjugando-con-jbpm-4-start-state-node%2F&sa=D&sntz=1&usg=AFQjCNHaRi1P5wXeNi4d8Dkh3VRZGrtyaw




















http://docs.jboss.org/jbpm/v3/userguide/

http://docs.redhat.com/docs/en-US/JBoss_Enterprise_SOA_Platform/5/html/ESB_Services_Guide/ch06.html

http://www.google.com/url?q=http%3A%2F%2Fdocs.jboss.org%2Fjbpm%2Fv3%2Fuserguide%2Fmail.html&sa=D&sntz=1&usg=AFQjCNGCWmuFB8YkshWFokPnVCHkV4z0wA

















http://www.google.com/url?q=http%3A%2F%2Fwww.jboss.com%2Fproducts%2Fjbpm%2Fdocs%2Fjpdl%2F&sa=D&sntz=1&usg=AFQjCNFw1m26kKc4fvTo76PwBS5AO6KyNA
















http://www.google.com/url?q=http%3A%2F%2Fwww.mastertheboss.com%2Fsoa-a-esb%2F120-esb-service-orchestration-with-jbpm.html&sa=D&sntz=1&usg=AFQjCNEkFjg1SeZ1kh1KR2u-0roX1BdU0w

























http://www.javeriana.edu.co/puj/viceadm/oym/ppd/documentos4-DGRH-TH-11.html


















[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

http://www.google.com/url?q=http%3A%2F%2Fdocs.jboss.org%2Fseam%2F1.2.1.GA%2Freference%2Fen%2Fhtml%2Fannotations.html&sa=D&sntz=1&usg=AFQjCNGPnruC-ku8cBm2FKgO0BsVP4jE3g





















http://mastertheboss.com/seam/90-seam-jbpm.html

Modelado e implementación de un proceso de negocio...

Documents

Transcript of Modelado e implementación de un proceso de negocio...