Se trata de proceso en el que alguien reclama y otra persona responde. Evidentemente, no es la única solución ni decimos que sea la mejor en este caso, pero se trata de poner un ejemplo de cómo desarrollar un paso de mensajes entre dos procesos.
En realidad, el proceso inicial, el del reclamante, solo rellena un formulario que es inmediatamente enviado a "proceso llamado". No hace nada más.
El proceso llamado recibe esos datos y, en su propio formulario, redacta una respuesta. No se hace nada más, los datos simplemente se guardan en la base de datos.
El usuario siempre será Walter Bates. La instanciación del proceso RECLAMACIÓN abre un formulario simple donde un usuario cualquiera rellena los datos solicitados.
Al enviar el formulario, el proceso envía un mensaje a otro proceso, RESPUESTA RECLAMACIÓN, y termina.
Este segundo proceso lee esos datos anteriores y prepara la tarea "responder" para que Walter Bates la pueda tomar y ejecutar. El formulario de esta tarea muestra los datos que le han llegado con el mensaje. Una vez responda, este segundo proceso termina.
El resultado es que tendremos 2 casos archivados; es que hemos ejecutado dos procesos, solo que el primero es el que ha lanzado al segundo mediante un envío de mensaje.
A excepción de la conexión entre la tarea de envío de mensaje y el evento capturado, se supone que tienes el diagrama completo.
Al crear un proceso y senda nuevos, hace falta definir los actores o responsables de ambos. Con el pool seleccionado, añadimos un actor que llamaremos "Actor1".
Con la senda seleccionada, decimos que use el mismo actor seleccionándolo de la lista desplegable.
En la tarea "responder", nos aseguramos de que esté seleccionado el que use el actor definido en la senda.
Con el pool seleccionado, debemos configurar el mapeo de actores.
Esto, que en el otro proceso ya venía definido por defecto, es lo que permite que cualquier miembro de la organización ACME inicie el proceso.
Y, por último, sin salirnos de la configuración, ver si la autenticación es la de Walter Bates, o ponerla nosotros si no estuviera definida:
nombre de usuario: walter.bates
Vamos a definir dos BDM. La intención es definir variables de negocio diferenciadas para cada proceso. Recuerda desplegar el BDM.
quien STRING
reclamacion STRING
respuesta STRING
Ambos procesos manejan su propia variable de negocio correspondiente a dos modelos de datos de negocio definidos para la demostración. No entramos en la eficiencia de esta solución, insistimos en que se trata de un ejemplo.
En RECLAMACIÓN
En RESPUESTA RECLAMACIÓN
El proceso RESPUESTA RECLAMACIÓN define 2 variables de proceso:
vquien TEXTO
vreclama TEXTO
Las vamos a usar para guardar los datos del mensaje y poder acceder a sus valores en el formulario de la tarea "responder".
Aquello que no veas en las siguientes imágenes no se define. Definiremos contrato en el proceso RECLAMACIÓN y en la tarea RESPONDER. El proceso RESPUESTA RECLAMACIÓN no tiene contrato ni formulario de instanciación.
No definiremos ninguno, dejaremos que Bonita los cree en cada ejecución. Más adelante los personalizaremos.
Por último, aunque se supone que lo va a hacer Bonita automáticamente al definir el contrato de la tarea "responder", comprueba que tienes exactamente lo que muestra la imagen.
Las tareas o eventos de envío de mensajes componen un paquete de datos que envían a otro evento o tarea receptores de mensaje. Por lo tanto:
cada mensaje está asociado a un único lanzador y a un único capturador.
los lanzadores pueden enviar varios mensajes, cada uno a un capturador diferente
cada capturador solo se asocia con un mensaje y, por tanto, único lanzador
lanzador y capturador deben estar en pools diferentes —en procesos diferentes que, además, no necesariamente estarán modelados en el mismo diagrama—
Tanto tareas como eventos lanzadores de mensajes, cuando están seleccionados, tienen un panel "mensajes" en la pestaña general. El botón agregar nos permite añadir el mensaje. Fíjate que solo nos deja añadir uno.
Los datos a rellenar son:
nombre del mesaje, a elegir por nosotros
proceso destino: se elige desde una lista desplegable
elemento destino: el capturador, desde una lista desplegable que muestra todos los posibles capturadores del proceso destino
contenido del mensaje: las variables y los valores que almacenarán
En nuestro caso queremos copiar los valores de la variable de negocio vnreclama ("quien" y "reclama") a dos variables que llamaremos "msjquien" y "msjreclama". Fíjate que lo hacemos mediante expresiones java. La secuencia de pasos es la siguiente:
Abrimos el editor de expresiones
vnreclama.quien
El atributo vnreclama.quien es el dato que queremos transferir.
Lo mismo se haría para msjreclama, vnreclama.reclamacion, y ya tenemos preparado el mensaje.
Al igual que antes, el capturador tiene su panel de "contenido del mensaje" dentro de la pestaña "general", cuando lo seleccionamos. La imagen que ves a continuación es el resultado final de la preparación del capturador.
En un principio, te aparecerá vacío pero puedes aprovechar el botón "auto-llenado". Puesto que el mensaje que Bonita "sabe" qué mensaje va a ser capturado, automáticamente genera dos líneas de asignación, una con "msjquien" y otra con "msjreclama". Si hemos definido antes las variables del proceso —de negocio y de proceso—, los desplegables de la izquierda nos las muestran como opciones y solo tenemos que elegir la correcta en cada caso.
Se supone que lo tienes todo, solo queda ejecutar. Recuerda seleccionar el pool RECLAMACIÓN.
No hemos creado formularios, así que el aspecto lo decide Bonita.
En "casos archivados veremos los dos casos, los correspondientes al que inicia la ejecución (RECLAMACIÓN) y al que continúa con la recepción del mensaje (RESPUESTA RECLAMACIÓN).
Podemos, también, examinar cada caso ("acciones", icono del ojo, "ver resumen del caso"). Observa que en Reclamación (1.0) dice que no se ha realizado ninguna actividad. Está haciendo referencia a que, después de la instanciación, no ha intervenido ningún humano, solo se ha ejecutado la tarea automática de envío de mensaje. En el segundo caso, Respuesta Reclamación (1.0) sí hay una tarea de intervención humana con su formulario asociado.
En ambos casos, comprueba los valores almacenados en las variables de negocio.
A continuación, podemos personalizar los formularios para hacerlos un poco más amigables: PP07b Envío de mensaje formularios.