Los eventos de señales son otro mecanismo de sincronización entre procesos. Una señal no tiene las limitaciones en cuanto a emisores y receptores de un mensaje pero tampoco contiene datos. Simplemente inicia o reactiva otro proceso. Pero, al igual que los mensajes, emisor y receptor deben estar en procesos (pools) separados.
En este ejemplo tenemos un proceso principal, ELECCIÓN, que nos permite elegir si emitir una u otra señal. Si se elige la opción "por arriba" se inicia el proceso ASIGNA10. Por contra, si se elige "por abajo", se activan los procesos ASIGNA30 y ASIGNA40. Estos procesos son automáticos, no requieren intervención humana y, simplemente, establecen el valor de su variable de negocio a 10, 30 y 40 respectivamente.
Lo importante es darse cuenta de que una señal se captura por todos los procesos que la estén esperando.
Al elegir "por arriba", el flujo se va por la opción por defecto y activa la señal "elegido 10". Puedes pensar que los inicios de señal de los otros procesos están escuchando permanentemente a la espera de que se emita la señal adecuada. En este caso, se inicia el proceso ASIGNA10 que, en una tarea de servicio, asigna y almacena el valor 10.
Si hubiéramos elegido "por abajo", los procesos que se activan son ASIGNA30 y ASIGNA40, y sus resultados se verían de forma análoga.
Vamos a utilizar el mismo esquema para todos los procesos:
Senyal
valor INTEGER
Recuerda que vamos a definir una variable de negocio en cada proceso. Esto significa que tendremos, en realidad, 2 valores en cada ejecución: el del proceso principal ELECCIÓN y el del proceso activado, ASIGNA10 o ASIGNA30. Si piensas en términos de tabla de base de datos, tendremos dos filas con diferente valor en la columna "valor". En términos de BPM, tendremos 2 casos, 2 instancias de proceso y, por tanto, 2 variables de negocio con su valor correspondiente cada una.
Solo se muestra aquello que hay que definir o completar. Dicho de otro modo, no necesitas configurar nada más que lo que veas aquí.
En los tres procesos procederemos de forma similar. Únicamente les hemos dado diferente nombre en cada proceso por claridad, pero podría haber sido el mismo; son procesos diferentes.
En todos los casos el objeto de negocio es com.company.model.Senyal
Elección: vnsenyal
Asigna10: vnsenyal10
Asigna30: vnsenyal30
Asigna40: vnsenyal40
Solo vamos a definir un formulario de instanciación. Los otros procesos no lo necesitan.
fsenyalsin
En el formulario, por simple estética, añadimos un widget TEXT con el texto informativo de qué valores utilizar en "valor".
Utiliza el valor 0 para "por arriba", y el valor 1 para "por abajo".
Aunque no es estrictamente necesario, en los otros procesos vamos a marcar que no usan formulario de instanciación.
Para establecer las condiciones de activación de los flujos opcionales de la compuerta exclusiva, debes seleccionar uno y modificar datos en la pestaña "general".
En el caso de "por arriba" marcamos flujo por defecto.
Los flujos por defecto nos aseguran que el proceso no se atascará por una mala definición de condiciones. En nuestro proceso, una consecuencia de esto es que cualquier valor distinto de 1 nos llevará por ese flujo.
En el de "por abajo", editamos la expresión, eligiendo la opción script. El nombre de la expresión puede ser cualquiera, pero el código debe ser —aunque se admiten otro tipo de expresiones—:
vnsenyal.valor==1
Las que realizarán automáticamente las tareas de script, cuando sean activadas. En todos los casos se utiliza el método Java setValor() definido automáticamente para el BDM Senyal. Hay que tener cuidado en que la constante definida en cada caso tenga el tipo de retorno java.lang.Integer.
Hemos dejado para el final la configuración de los eventos de señal. Hasta ahora, habrás visto que todos ellos tienen una marca de error, precisamente por que nos faltaba este paso.
Selecciona el evento de señal final "elegido 10" en el proceso ELECCIÓN. Como código de la señal podemos escribir lo que queramos, lo importante es que alguien esté esperando ese código.
En este ejemplo, el código será e10.
Hacemos lo mismo para "elegido 30", pero con el código e30.
Ahora configuraremos los eventos de captura, los inicios de los otros procesos. La mecánica es exactamente la misma.
Estamos esperando que estos procesos se activen simultáneamente con un único lanzamiento de señal. Por lo tanto, utilizaremos los mismos códigos de antes.
Fíjate que, aunque tenemos 3 eventos de inicio a configurar, "elegido 30" está presente en dos procesos. Por lo tanto, daremos el mismo código a esos dos eventos de inicio.
Los procesos Asignaxx solo ejecutan tareas de script y no se les ha definido actores. Esto significa que los usuarios "normales" no tienen acceso a ellos. Por lo tanto, necesitamos acceder a la vista de "administrador" —cosa que podemos hacer siempre—. Con la vista "usuario", solo podríamos ver lo que ha hecho Walter Bates, que solo ha ejecutado un proceso sin tareas (ELECCIÓN), no veríamos los casos de los otros procesos.
Una vez a la vista los casos archivados, comprueba en las "acciones" los valores almacenados en cada caso.
Ten en cuenta que, aunque el modelo de datos de negocio es único, cada proceso maneja su propia variable de negocio. Para entendernos, siguiendo la ejecución mostrada arriba, en la tabla SENYAL se insertan 2 filas, cada una de ellas generada por cada proceso.
Prueba el valor 1.