El Proceso A va a enviar una reclamación al Proceso B para que se produzca una respuesta automática —la deniega—. El Proceso A recibe la respuesta y la comenta, finalizando el proceso completo.
Cuando un usuario ejecuta el Proceso A, este se instancia a través de un formulario en el que tiene que poner un nombre de persona y el texto en el que reclama algo.
Una vez que presione el botón de envío, el proceso está instanciado y se ejecutarán automáticamente:
el envío del mensaje conteniendo "quién" y "reclamación" como datos
Proceso B recibe el mensaje
la tarea "respuesta automática" concatenará esos datos y le añadirá el texto "-- denegada porque sí"
se envía la respuesta al Proceso A
Proceso A la recibe
la tarea "leer respuesta" queda a la espera de que alguien la tome y muestra todos los datos recopilados hasta el momento
El usuario toma la tarea pendiente ("leer respuesta") y comenta lo que quiera. Finaliza el proceso.
A continuación vamos a ver todos los pasos necesarios para poner en marcha estos procesos. Se supone que tienes ya una cierta experiencia en el entorno Bonita BPM Suite.
Cuando dibujes el diagrama, los eventos de mensaje no estará conectados. Eso lo conseguiremos más adelante.
Reclama
quien - STRING
reclamacion - STRING
respuesta - STRING
comenta - STRING
Como siempre, ten cuidado con mayúsculas y minúsculas, y evita utilizar tildes.
Vamos a configurar el proceso.
vnreclama.quien
vnreclama.reclamacion
nombre: fSreclama
Nos detenemos en el evento de envío de mensaje y cómo se configura
Añadimos el "contenido del mensaje":
dquien = vnreclama.quien
dreclama = vnreclama.reclamacion
Pasamos al Proceso B y lo configuramos.
Como no hay intervención humana en todo el proceso, no hace falta definir actores. Sin ser necesario, hemos incorporado una senda para recalcar que es el sistema el encargado de la ejecución.
bQuien - TEXTO
bReclamacion - TEXTO
bResponde - TEXTO
No utilizamos variable de negocio, no necesitamos guardar nada en ningún BDM —en la base de datos—, solo vamos trabajar con el mensaje entrante y devolver una respuesta al otro proceso.
Sin formulario de instanciación.
Este proceso lo activa Proceso A al enviar el mensaje. No necesita interactuar con el usuario. Por lo tanto, ni instanciación, ni contranto ni formularios.
Ahora configuramos el evento de inicio de recepción de mensaje del Proceso B. Vamos a traspasar el contenido del mensaje a algunas variables de proceso.
Definiremos las operaciones que debe realizar la tarea.
Queremos conseguir esto:
Y lo hacemos con la siguiente secuencia de acciones
Añadimos el script que genera el valor a asignar a la variable de proceso con:
return (bQuien + ":"+ bReclamacion + "--denegada porque sí")
El proceso termina lanzando el mensaje que sincronizará y reactivará el Proceso A.
Similar a lo hecho con el evento inicial, debemos definir qué datos se transmitirán al otro proceso. En nuestro caso queremos enviar la respuesta generada por la tarea de servicio y almacenada en la variable de proceso bResponde.
Configuración de la lectura de la respuesta proviniente del Proceso B.
Ten en cuenta que estás asignando un valor escalar (rresponde) a una variable compleja (vnreclama). En realidad, lo que queremos es asignar vnreclama.respuesta = rresponde. Eso debemos hacerlo con el método Java vnreclama.setRespuesta() seleccionado
El Proceso A debe tratar los datos recibidos.
vnreclama.comenta
nombre: fLeerRespuesta
Al crear el contrato y, posteriormente, el formulario, Bonita nos genera automáticamente widgets de solo lectura con aquellos atributos de la variable de negocio que ya han sido rellenados antes.
En realidad, todos aquellos atributos de la variable de negocio que no se han incluido en el contrato. Fíjate que podemos ver vnreclama.quien, vnreclama.reclamación y vnreclama.respuesta. El único widget editable es el que rellenará vnreclama.comenta.
Esos datos los obtiene del contexto del caso, de la variable del formulario context.
Podemos personalizar un poco el formulario modificando las etiquetas de los widgets.
Todo listo: ejecuta y comprueba.
Puesto que como usuario "normal" solo vemos aquello que es ejecutado directamente por nosotros, la ejecución del Proceso B no se nos muestra. Para comprobar este extremo, debemos cambiar en Portal nuestro rol a administrador y buscar los casos archivados.