Mi segundo diagrama

Se trata de otro proceso sencillo del que solo te daremos los detalles imprescindibles. Se trata de una solicitud de permiso por ausencia. 

• Nombre del diagrama: EP00

• Nombre del proceso: Pedir permiso xxx

  • donde xxx es tu usuario de la EPS

• BDM Permiso

  • quien STRING

  • motivo STRING

  • aceptada BOOLEAN

• variable de negocio: vnPermiso (com.company.model.Permiso)

• formulario de instanciación: fSolicito

• formulario de tarea: fAprueban

Se trata de un formulario simple de solicitud en el que el solicitante da su nombre y el motivo del permiso, y otro de aprobación o no de la misma solicitud. 

El funcionamiento es el siguiente:

En el formulario de instanciación se elige, mediante la introducción de un número entero, la opción deseada:

1. rellenar entero (vnCompuertas.numero)

2. rellenar string (vnCompuertas.cadena)

3. rellenar fecha (vnCompuertas.fecha)

Este número es examinado en la compuerta exclusiva para que se active el flujo adecuado y se ejecute la tarea deseada. Todas las tareas ofrecen un formulario, cada uno de ellos permitiendo rellenar uno de los datos de la variable de negocio.

Algunos de los formularios que presentamos aquí están retocados, pero con el formulario automático es suficiente.

Compuerta paralela

Modela y pon en funcionamiento el diagrama que se presenta aquí.

Buscamos comprender el funcionamiento de las compuertas y cómo se configuran en Bonita.

Nombre del proceso: EPAND

Una vez duplicado, solo tienes que modificar:

1. Convierte la compuerta XOR a AND.

2. Cambia la etiqueta de la compuerta AND a "G1" —en Bonita es obligatorio darle nombre a cada compuerta—

3. Elimina las de sus flujos de salida.

En realidad 2 y 3 son cambios estéticos, tampoco son imprescindibles.

Con esta compuerta no tiene sentido el formulario de instanciación, podemos quitarlo. Para ello:

1. Con el pool seleccionado, marca en "formulario de instanciación" "sin formulario".

2. Elimina el contrato.

3. Edita la variable de negocio y elimina el valor predeterminado.

Compuerta inclusiva

Modela y pon en funcionamiento el diagrama que se presenta aquí.

Buscamos comprender el funcionamiento de las compuertas y cómo se configuran en Bonita.

Nombre del proceso: EPOR

Duplica el diagrama del ejercicio EPXOR y realiza los cambios pertinentes. En concreto, cambiaras las condiciones de los flujos a elijo<=2 y elijo<=3 respectivamente, dejando la restante por defecto.

Ejecuta con los valores de instanciación (elijo) 3, 2, 1 y 4. La lógica nos dice que con valor 3 solo se ejecuta una tarea, con valor 2 dos, y con valor 1 las tres. Valores mayores que 3... ¿cuántas tareas se ejecutarían?

¿A qué se debe el comportamiento observado en esas ejecuciones?

Compuerta inclusiva 2

En el ejercicio EPor anterior, el flujo por defecto no admite condiciones en Bonita: ¿cómo lo soluciono para que con elijo<=1 se ejecuten las tres tareas, y ninguna con si elijo>3? Ten en cuenta que el proceso debe finalizar en cualquier caso.

Doble ejecución

Modela y pon en funcionamiento un diagrama en bonita que demuestre que una tarea con dos flujos de entrada podría ejecutarse 2 veces.

Cuando expusimos las compuertas hablamos de la necesidad —en la mayoría de los casos, pero no en todos, y sobre todo para las AND y OR— de utilizar parejas, una de ellas de apertura o división del flujo de secuencia (split) y otra de cierre, sincronización o mezcla de flujos (merge). Ahora pretendemos, mediante una compuerta AND, ver qué pasa si no lo hacemos así.

El proceso que se muestra abajo trabaja con una variable de negocio con dos atributos enteros, x e y, ambos se inicializan a 1 en sendas tareas automáticas y, finalmente, se realizan las operaciones que los actualizan:

• x=x*10

• y=y+1

La intuición nos dice que el resultado final debería ser x=10 e y=2. Sin embargo, no ocurre así. El "problema" es que no hemos modelado la compuerta merge-AND, la compuerta de sincronización de los dos flujos que se inician en una compuerta split-AND.

Consta de 2 partes:

1. Desarrollo del proceso habitual (variables de negocio, contratos, formularios)

2. Adaptación a una nueva organización (organización, actores por senda)

No configures usuarios individuales para las sendas, utiliza otra característica (grupo, roles...)

Utilizarás Bonita Studio. No hay contrato ni formulario de instanciación ("sin formulario"). El proceso mostrará directamente el formulario de la primera tarea.

Organización: personalización de formularios

Una vez comprobado que nuestro proceso funciona como queremos, podemos personalizar los formularios para hacerlos más usables, y mejorados estéticamente.

En el momento de crear el formulario en Bonita Studios, en este caso en las dos tareas con contrato, se abre el navegador con la aplicación UI Designer, un editor de formularios. De momento solo vamos añadir widgets y recolocar y redimensionar los existentes. 

Los formularios que queremos obtener se parecerán, más o menos, a los que presentamos aquí.

Calificación de entregas

En una simulación del proceso de calificación de entregas de un trabajo en clase, materializado en un documento PDF, intervienen dos tipos de usuarios, profesores y estudiantes. Los últimos inician el proceso con la subida del fichero, y los primeros lo califican con una nota de 0 a 10. El estudiante puede no estar de acuerdo con la calificación, por lo que realizaría una reclamación que el profesor atenderá positiva o negativamente.

Para subir y consultar un fichero en el proceso, necesitas haber practicado antes el ejercicio PPdoc Documento.

Formularios

Mejoras

Subprocesos

Se trata de la asignación de cama al ingresar en planta. En primer lugar se verifican los datos para comprobar que la planta, fecha y demás datos son correctos. Después se pasa a buscar una cama y, si es posible, asignársela al nuevo paciente. En caso de error, se redacta un informe y el proceso se cancela.

No hace falta que el o los modelos de datos de negocio sean muy detallados, interesa más ver el flujo de ejecución, pero sí con los atributos imprescindibles para ver el resultado al final (datosOk, camaOk, informe).

Ten en cuenta que el diagrama de Bonita difiere del que se muestra aquí ya que no maneja subprocesos embebidos, se convierten en tareas de llamada a subproceso reutilizable. Eso sí, tendrás que configurar qué tareas llaman a qué procesos.

Para este ejercicio necesitas haber realizado y entendido el ejemplo paso a paso PP06 llamada a actividad.

Aquí tienes unas cuantas pistas de cómo abordar este ejercicio en Bonita.

Tablas de decisión

Pistas

1. No necesita instanciación o, más bien, la instanciación no recoge ningún dato y, por lo tanto, no necesita formulario .

2. La variable de negocio debe constar de, al menos, edad, peso, alergias y tipoVigilancia.

3. Trabaja directamente con la variable de negocio, las condiciones serán scripts de Java que accedan a ella. La ventaja es que todas las condiciones se pueden poner en una fila y una única condición convenientemente conectadas por && y ||.

4. Las tareas de servicio únicamente dan valor a un atributo de la variable de negocio con el tipo de vigilancia correcto para cada conjunto de condiciones.

5. El resultado lo podrás comprobar en Portal.

6. Dale nombres coherentes a cada tarea, flujos del gateway y eventos.

Tablas de decisión 2

Un empleado de ACME introduce una solicitud de compra o servicio con estos datos (instanciación):

• identificador de usuario (long), obtenido automáticamente del caso iniciado

• fecha (fecha), obtenido automáticamente del caso iniciado

• solicita (texto)

• presupuesto (número)

• destino (A, B o C)

Además, la solicitud mantiene un testigo de aprobación ("aprobado", "revisar", "cancelado")

Esta solicitud puede tomar varios caminos en función de esta tabla:

Aprobado: aprobación automática, actualizar el testigo

Revisar: el testigo se actualiza a "revisar"; a continuación, la solicitud debe ser revisada por un supervisor (Helen Kelly), quien decidirá si aprueba sin más, si aprueba con una modificación de presupuesto (un valor adicional al precio estimado original) o si anula la solicitud. Se actualiza el testigo con su decisión.

Cancelado: anulación automática, actualizar el testigo.

Todos los datos mencionados serán persistentes.

Comportamiento evento señal y evento error adjuntos

Queremos comprobar el comportamiento de los eventos adjuntos interruptores, concretamente los de error y los de señal. Supongamos el siguiente par de procesos.

Queremos comprobar, en Bonita Studio, cómo se comportan los eventos de señal y error, y entender las diferencias. Es un escenario en producción, cada proceso puede iniciarse simultáneamente varias veces —varios usuarios inician el mismo proceso—. Es una escalación de eventos, la pregunta es cómo sabe Bonita a qué instancia enviar dichos eventos.

El proceso principal, PRUEBA DE EVENTOS, se inicia con un formulario que pide un número entero y que guardaremos como “identificador”. Lo que pretendemos es poder identificar fácilmente las instancias en ejecución del proceso. 

A continuación, una actividad de llamada activa el proceso ACTUALIZAR ESTADO. Este proceso ofrece un formulario en la tarea “elegir estado” donde marcaremos nuestra opción deseada: “error”, “señal” o “manual”. Cada opción representa terminar este proceso en su correspondiente evento de final.

Cuando PRUEBA DE EVENTOS recupera el control del flujo, o bien termina normalmente, o bien la tarea de llamada se interrumpe y continúa por el flujo correspondiente al evento adjunto interruptor activado, llevando a una tarea de servicio que actualiza un testigo “estado”. 

Notas de desarrollo:

Necesitas un BDM con

• identifica INTEGER

• estado STRING

La forma más fácil de diseñarlo es utilizando el mismo BDM en los dos procesos, y enviando toda la variable de negocio de PRUEBA DE EVENTOS en la tarea de llamada “actualizar estado” —no hace falta definir “datos a recibir”—. Cuando el proceso ACTUALIZAR ESTADO termine, la variable de negocio estará actualizada a los nuevos valores.

Fíjate en que cada tarea de servicio "adorna" el estado elegido ("error" pasa a ser "Terminado en error"). La tarea de llamada necesita una operación adicional que ponga en “estado” el texto deseado —”terminado normalmente”, en este caso—. Las tareas de servicio harán lo propio.

Resultado esperado

Ejemplo de formularios:

El proceso PRUEBA EVENTOS debe ejecutarse al menos 4 veces, con identificadores 1, 2 3 y 4, por ejemplo. Para ello:

Ejecuta una primera vez con identificador 1, pero sin tomar la tarea “elegir estado”. Esto desplegará los procesos en el servidor web.

En la misma página web de Portal, ve a la pestaña “procesos” y ejecuta de la misma manera tres veces más (identificadores 2, 3 y 4)

La prueba de eventos

La prueba consiste en 

1. elegir la tarea con el identificador 4 y terminarla con la opción “manual”, deberían quedarte pendientes las otras 3 tareas.

2. elegir la tarea con el identificador 2 y terminarla con la opción “error”; refresca la lista de tareas; ¿qué tareas quedan aún pendientes?

3. elegir la tarea con el identificador 1 y terminarla con la opción “señal”; refresca la lista de tareas; ¿qué tareas quedan aún pendientes?

Entrega (Moodle)

• Captura de pantalla del diagrama dibujado

• Impresiones de los 4 casos archivados de PRUEBA DE EVENTOS

• Responde a la pregunta ¿qué diferencia hay entre los eventos de señal y los de error? (en el cuadro de texto de esta tarea)

Consulta de servicio web UA

La Universidad de Alicante ofrece una lista de servicios web públicos. Vamos a utilizar el denominado wsasiplan (plengua, pcurso, pcodest), que obtiene información acerca del plan de estudios de una titulación.

Si utilizamos la siguiente URL conseguiremos todas las asignaturas del curso 2021-22 del plan de estudios C210, el grado en Ingeniería Biomédica:

https://cvnet.cpd.ua.es/servicioweb/publicos/pub_gestdocente.asmx/wsasiplan?plengua=C&pcurso=2021-22&pcodest=C210

Lo que pretendemos, en este momento, es obtener esa información en bruto, sin procesar.

Notas del desarrollo

• El proceso no tiene contrato ni fomulario de instanciación

• Necesitas una variable de proceso de tipo texto

• La tarea "recuperar asignaturas" utiliza un conector REST - GET

• La tarea "mostrar resultados" no tiene contrato, pero sí formulario. En ese formulario necesitas acceder a la variable de proceso mediante una llamada a una external API. Mostrarás el contenido de esta mediante un widget Text.

El conector solo necesita configuración en par de pasos, introduciendo la URL anteriormente mostrada, y estableciendo la salida: a la variable de proceso se le asigna bodyAsString.

Consulta de servicio web UA alternativa

Vamos a procesar la salida del servicio web para obtener únicamente las asignaturas de tercer curso. Además, vamos a almacenar ese resultado en una variable de negocio de tal forma que el caso archivado tendrá este aspecto:

Si nos fijamos en el XML que devuelve el servicio web, vemos que está estructurado de tal manera que, entre otros, nos informa del código de la asignatura, su nombre y la cantidad de créditos. El dato que vamos a usar para filtrar es el curso.

<?xml version="1.0" encoding="utf-8"?>

<ArrayOfClaseAsiPlan xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://UASI/WS_GESTDOCENTE.wsdl">

...

  <ClaseAsiPlan>

    <codest>C210</codest>

    <caca>2021-22</caca>

    <codasi>33624</codasi>

    <nomasi>GESTIÓN DE PROCESOS SANITARIOS</nomasi>

    <nomasicorto>GESTIÓN DE PROCESOS SANITARIOS</nomasicorto>

    <tipo>B</tipo>

    <ciclo>1</ciclo>

    <curso>3</curso>

    <desccurso>3</desccurso>

    <ofertada>S</ofertada>

    <docencia>S</docencia>

    <complform>N</complform>

    <crdtsteo />

    <crdtspra />

    <crdtsects>6</crdtsects>

    <duracion>S</duracion>

    <tfg>N</tfg>

    <estadoasi>V</estadoasi>

  </ClaseAsiPlan>

...

</ArrayOfClaseAsiPlan>

Por lo tanto, queremos recuperar los datos de ArrayOfClasesAsiPlan.ClaseAsiPlan.codasi, y así con los otros dos datos. 

Notas del desarrollo

• Duplica el diagrama cambiando números de versión para no modificar la versión anterior.

• Necesitas un modelo de datos de negocio con nombre, por ejemplo, WebService

  • codasi STRING

  • nomasi STRING

  • creditos STRING

• Define una variable de negocio en base al BDM anterior, y marca la casilla "es múltiple" —vamos a almacenar varias asignaturas, serán varias filas de la tabla en la base de datos—

• En la tarea "recuperar asignaturas" añadirás una operación para asignar los valores obtenidos a la variable de negocio, con el método Java "addAll"

Necesitamos un script que procese el XML para conseguir los datos que queremos. Supongamos que la variable de proceso que almacena la salida del servicio web se llama miVariable.

def mixml = new XmlSlurper().parseText(miVariable) //XmlSlurper nos permite tratar XML

def i = 0 //variable de iteración

def lista = [] //la lista donde vamos a almacenar las asignaturas

while (mixml.ClaseAsiPlan[i].size() > 0) { //mientras haya datos

if (mixml.ClaseAsiPlan[i].curso=='3'){ //si es de tercer curso

def r = new com.company.model.WebService() //nueva variable basada en el BDM

r.codasi = mixml.ClaseAsiPlan[i].codasi //rellenar la variable

r.nomasi = mixml.ClaseAsiPlan[i].nomasi

r.creditos = mixml.ClaseAsiPlan[i].crdtsects

lista << r //añadir la variable a la lista

}

i++ //siguiente iteración

}

return lista //devuelve una lista de asignaturas con los datos anteriores

El tipo de retorno de este script ha de ser java.util.Collection.

Hacemos uso de la librería XmlSlurper para poder acceder a la estructura del documento XML. En el bucle examinamos cada valor de curso, buscando el valor '3'. Si lo encontramos, significa que estamos con una asignatura de tercer curso. En ese momento, creamos un nuevo objeto con el tipo del BDM (com.company.model.WebService) con la intención de recuperar los datos que nos interesan y añadirlo a una lista. Finalmente, esa lista es el valor devuelto.

La tarea "mostrar resultados" seguirá mostrando todo el XML en bruto, pero el caso archivado solo los datos recuperados de las asignaturas de tercer curso del grado.