4. Procesos (Actividades)

Anahi_Blanco · 27 Agosto, 2026 22:34

4.1 Actividades

4.1.1 Inicio

El elemento de Inicio en BModeler es el punto de partida obligatorio de cualquier proceso y define la modalidad en la que se generarán los casos. Se encuentra en la barra de actividades, desde donde se puede arrastrar al lienzo.

Cuando se arrastra la actividad al lienzo, automáticamente se abre la ventana de configuración en la parte izquierda de la pantalla.

Se debe definir el Nombre y el Tipo para poder guardar la configuración.

Existen tres tipos principales de inicio que un usuario puede configurar:

Inicio Directo (Manual o por API)

Este tipo de inicio permite que el proceso comience de forma inmediata, ya sea por la acción de un usuario o por un sistema externo.

Manual: El usuario inicia el caso directamente desde la prestación de “Casos” haciendo clic en el botón de “Nuevo Caso”.

Datos de API: Se obtiene la API que permite disparar el proceso desde sistemas externos o desde el propio ERP (transacciones de Go).
Configuración de Parámetros: Si se colocan parámetros, al iniciar el caso estos parámetros tienen que ser completados para dar inicio definitivo. Si se opta por el inicio vía API, el administrador puede definir parámetros específicos (como el nombre de un proveedor). A medida que se agregan estos parámetros, el sistema construye automáticamente el cuerpo del JSON que la API esperará recibir para iniciar el caso exitosamente.

Inicio por Formulario

Se utiliza cuando se requiere que el usuario cargue información específica antes de iniciar el caso.

Maquetador Visual: Requiere la configuración de un formulario mediante una herramienta de “arrastrar y soltar” (drag and drop) donde se definen los campos necesarios.
Limitación actual: A diferencia del inicio directo, los procesos que inician por formulario no pueden ser llamados por API actualmente; siempre requieren que el usuario haga clic en “Nuevo Caso” e complete los datos manualmente.

Inicio Programado (Automático)

Este inicio no requiere intervención humana ni llamadas externas, ya que el sistema genera los casos de forma autónoma basándose en una agenda predefinida.

Se debe seleccionar un tipo de programación:

Por Intervalo: Se define una hora de inicio, una de fin y la frecuencia de ejecución (ej. cada 30 minutos o cada 2 horas) dentro de ciertos días, pudiendo activar el toggle para indicar “Todos los dias” o haciendo clic sobre días específicos.

Hora Programada: El caso se dispara en una hora exacta y en los días de la semana seleccionados.

Fecha Relativa: Permite configuraciones basadas en el calendario, como el primer o último día del mes, o fechas fijas semestrales.

Asignación de Propietario: Como no hay un usuario físico iniciando el trámite, es obligatorio asignar un propietario al caso (usuario de Go) para que alguien sea responsable de supervisar o visualizar el avance de esos casos automáticos. Aplica a todos los tipos.

Importante: Para que se comiencen a generar los casos de un proceso con inicio programado debe estar activo el inicio. En caso de que se requiere desactivar por algún motivo para pausar la creación de casos en esta modalidad, se puede inactivar sin perder la configuración.

4.1.2 Actividad de usuario

La Actividad de usuario representa una tarea que debe ser ejecutada por una persona, ya sea un usuario interno del sistema o un usuario invitado (no tiene usuario en Finnegans). Desde esta actividad se ofrece la posibilidad de crear un formulario dinámico de forma customizable.

Esta actividad se divide estructuralmente en tres secciones clave: información de la actividad, el formulario y las notificaciones.

Información de la actividad

En esta sección se define el nombre de la actividad, quién debe ejecutar la tarea, tratamiento de reasignación y tratamientos de rechazos o devolución.

Una de las diferencias sustanciales de BModeler respecto a sistemas anteriores es su capacidad para interactuar con personas que no tienen usuario en el sistema.

Asignar Responsables:

Usuarios Internos

Los usuarios internos acceden a las tareas pendientes directamente desde la prestación BModeler - Casos. Para definir el responsable interno se dispone de 2 modalidades principales:

Único usuario

Permite definir un único usuario responsable para la ejecución de la actividad. Esta configuración admite dos modalidades de asignación:
- Usuario único (Asignación directa): Selección de un usuario específico registrado en el sistema. Es ideal para tareas operativas estáticas donde la responsabilidad siempre recae sobre la misma persona.
- Usuario único por Variable (Atributo): Permite asociar un atributo de proceso (de tipo texto) que contenga el identificador o nombre del usuario. Esta modalidad posibilita que el responsable se asigne de forma dinámica en tiempo de ejecución, tomando los datos recolectados o determinados en etapas previas del flujo.

Equipo
Permite seleccionar un equipo de trabajo previamente creado en BModeler - Equipos para que asuma la responsabilidad de la tarea. Según el objetivo operativo del proceso, el sistema ofrece dos modalidades de comportamiento y distribución de la carga de trabajo:
- Todo el Equipo (Comportamiento por defecto): Permite una gestión colaborativa de las tareas entre todos los miembros de un grupo. Al ingresar a BModeler - Casos, cualquier miembro perteneciente al equipo podrá visualizar la tarea en la grilla e intervenir para completarla o hacerla avanzar.
  El selector de equipos cuenta con dos modos mutuamente excluyentes:
  - Modo Listado(por defecto): Despliega la lista de equipos definidos directamente en la configuración de la prestación BModeler - Equipos.
  - Modo Atributo: Esta selección permite que la asignación del equipo responsable sea plenamente dinámica por medio de un atributo.. En lugar de definir un equipo fijo en el diseño, la responsabilidad del equipo se resuelve automáticamente al iniciar el caso mediante los parámetros de lanzamiento asignados al proceso, sin requerir intervención manual durante la ejecución.

Mostrar a un integrante del equipo: Este selector se activa únicamente cuando la actividad tiene configurada la opción “Equipo”.
Permite asociar un atributo de proceso que contenga previamente el correo o usuario de un miembro perteneciente al equipo.
- Esta opción trabaja de manera conjunta con la funcionalidad “Guardar usuario reasignado”. Mientras una actividad captura y almacena la identidad del responsable en el atributo, otra actividad posterior puede utilizar la opción “Mostrar a un integrante del equipo” para que el miembro del grupo que avanzó la actividad inicial, también pueda ejecutar una actividad posterior.
- El integrante especificado en el atributo es el único habilitado para completar los datos requeridos del formulario de la actividad de usuario, y hacer avanzar la tarea. El resto de los miembros del equipo mantienen el caso visible en modo lectura dentro de la grilla de casos para dar seguimiento, pero sin permisos para modificar o completar la actividad.

Permite reasignar usuario: Esta casilla le otorga al responsable de una tarea la facultad de derivarla a otro integrante del equipo durante la ejecución del caso (función disponible únicamente para usuarios de GO).
Al marcarla, se habilita automáticamente el campo “Guardar usuario reasignado", el cual permite al diseñador capturar y guardar la identidad de la persona que avanza la actividad dentro de una variable del proceso. De esta manera, cualquier actividad posterior del flujo puede consultar ese dato registrado para heredar al mismo responsable de forma transparente.

Responsable Invitado (Externo)

Permite que personas externas (como proveedores) completen formularios sin tener usuario en el ecosistema Finnegans. Reciben un correo con un link seguro que los lleva directamente al formulario, con un tratamiento de seguridad especial.

Se puede asignar a un único usuario, seleccionando desde atributo o escribiendo como constante, o una lista de usuarios, que también puede estar en un atributo o escribir las direcciones de correo electrónico separadas por “punto y coma”.

Tratamiento de Rechazo y Devolución

El administrador puede configurar botones específicos para gestionar flujos alternativos o correcciones.

Rechazo: Conceptualmente, el rechazo siempre avanza hacia adelante en el flujo; puede finalizar el proceso o llevarlo a una etapa de cierre definitivo.
Devolución: Esta acción permite enviar el caso hacia atrás, específicamente a la actividad de usuario inmediata anterior.
- Atributos: Al devolver un caso, los datos cargados en los atributos se preservan, permitiendo que el usuario anterior realice las correcciones necesarias.
- URL de anulación: Si en el camino de regreso hubo una actividad automática (como una API que impactó datos), se puede configurar una URL de anulación para ejecutar una regla que revierta estos cambios automáticamente.

Formulario

Toda actividad de usuario está ligada obligatoriamente a un formulario diseñado mediante un maquetador visual de “arrastrar y soltar”.

Propiedades de los Campos: Los campos (widgets) pueden marcarse como requeridos (obligatorios para avanzar) o de solo lectura.
Diseño y Visualización:
- Paginado: El formulario puede mostrarse en una sola página con desplazamiento o dividirse en pasos, donde cada contenedor actúa como una página nueva.
- Responsividad: El maquetador permite previsualizar cómo se verá el diseño en PC, tablet y celular. Se recomienda el uso de una sola columna para asegurar una visualización correcta en dispositivos móviles.
Persistencia de Datos: Es crítico vincular cada campo del formulario a un atributo del proceso; si no se guarda en un atributo, la información se perderá y no podrá ser manipulada en etapas posteriores del flujo.

Notificaciones

Permiten dar aviso al responsable de que tiene una tarea pendiente.

Canales: Se pueden configurar por Mail y/o WhatsApp (si el servicio está vinculado).
Personalización: El sistema permite utilizar las plantillas predeterminadas o personalizar el asunto y el cuerpo del mensaje. En el caso del mail, es posible incluso redactar contenidos específicos para cada actividad.

4.1.3 Actividad automática

La actividad automática en BModeler es una actividad del diagramador que agrupa tareas ejecutadas directamente por el sistema, sin necesidad de que intervenga un usuario. Al arrastrarla al lienzo, inicialmente aparece con un icono de rueda dentada, pero una vez configurada, el icono cambia para reflejar la función específica asignada.

Estas actividades cuentan con una funcionalidad clave para los diseñadores de procesos y es la de “Ejecutar prueba”, este botón se encuentra en las actividades de envío de mail, API y Agente IA. Esto permite validar si una configuración (como un envío de mail o una búsqueda de IA) funciona correctamente de forma aislada, sin necesidad de iniciar un caso completo ni recorrer todo el diagrama desde el principio.

A continuación, se detallan las principales herramientas y funcionalidades disponibles dentro de este tipo de actividad:

Notificaciones

Mail

Configuración Dinámica: Permite enviar correos electrónicos de forma automática a destinatarios fijos o dinámicos (utilizando atributos como el “Propietario del caso”).
Personalización con HTML: El cuerpo del mensaje admite la estructura de etiquetas HTML para otorgar un diseño profesional, incluyendo logotipos y formatos específicos.
Uso de atributos: Se pueden insertar datos del proceso en el asunto o cuerpo del mail utilizando la nomenclatura ${nombre_del_atributo}, lo que permite que el sistema reemplace el código por el valor real del caso.

Ejemplo de configuración

Se completaron todos los datos obligatorios.
Se generó un HTML con IA y lo pegamos en el body.

Se hace clic en el botón “Ejecutar prueba”

Aparece un mensaje que se ejecutó con éxito la prueba unitaria.

Así se visualiza el mail en destino.

Gestión de Datos y Archivos

Conversor de formatos

Esta actividad toma información almacenada en un atributo de tipo JSON y la convierte en archivos descargables.

Datos de entrada: se debe seleccionar el atributo en el cual se tiene guardado el archivo a convertir, se espera que el formato sea JSON. En el ejemplo se crea un nuevo atributo, pero este atributo, puede estar creado y se debe seleccionar directamente.

Formatos de Salida: Los archivos resultantes pueden generarse en formato CSV, XLS o XLSX.

Atributo de destino: El archivo generado debe guardarse obligatoriamente en un atributo de tipo Archivo. Como en toda la herramienta, el atributo lo puedo seleccionar, si fue creado previamente o crearlo en el momento de la configuración.

Nombre del archivo: El usuario puede proporcionar un nombre al archivo generado. En el caso de las extensiones .xls y .xlsx se podrá asignar también nombre a la hoja.

Mapeo de Columnas: El usuario puede definir qué campos del JSON original se convertirán en columnas del archivo y asignarles nombres personalizados (ej. cambiar “sku” por “Código de producto”).

Importante: la lectura de los datos es nivel “objeto”, en la imagen lo que se observa es que el JSON tiene una estructura “lista de objetos”.

Una vez que se seleccionan los datos se presentan de forma que se pueda mapear el nombre, según lo requerido.

Integraciones

API

Permite conectar el proceso con el ERP de Finnegans o sistemas externos:

Método HTTP: Selección del tipo de petición a realizar (GET, POST, PUT, PATCH, DELETE).

URL de la API: Dirección del endpoint al cual se realizará la consulta.

Configuraciones Extra: Paneles desplegables para definir:
- Parámetros: Query params para la URL.
- Cabecera (Headers): Definición de tokens de autenticación, content-type, etc.
- Body: Cuerpo de la petición (disponible para métodos POST, PUT y PATCH).

Guardar respuesta en: Selector para elegir el Atributo del Proceso donde se almacenará el resultado (JSON o texto) devuelto por la API para ser usado en pasos posteriores. En el caso que no sea la recepción de datos, se guardará la respuesta respecto a la conexión.

Guest Code

Facilita la integración con Guest Code, para crear o buscar el endpoint de scripts en Python asistidos por inteligencia artificial. El diagramador permite configurar el punto de acceso (endpoint) del script directamente en una llamada API.

En este punto, si el script ya existe en nuestro espacio de trabajo, podemos editar o copiar el nombre y endpoint para utilizar posteriormente.

Para copiar podemos seleccionar “Copiar URL”.

Alternativamente, podemos hacer doble click sobre el endpoint que nos interesa, y se abrirá una ventana con la opción de editar el script. Desde ahí, también se podrá copiar el endpoint a configurar.

En caso de querer generar un nuevo script, se debe hacer clic en el botón “Nuevo” y se comienza con la creación.

Inteligencia Artificial

Agente IA

Permite enviar instrucciones a un modelo de IA para redactar textos, analizar datos o realizar búsquedas en internet.

Interacción con Atributos: Al igual que en los correos, se pueden incluir atributos del proceso dentro del pedido (prompt) a la IA utilizando la sintaxis ${nombre_atributo}. Al escribir los caracteres ${ (pesos + llave de apertura) se despliega la lista de atributos del proceso.

Almacenamiento de Respuestas: El resultado generado por la IA se guarda en un atributo de texto seleccionado por el usuario.

4.1.4 Controles de flujo

Estas actividades son fundamentales para dirigir, pausar, desviar, retornar o interconectar el recorrido de un caso a lo largo de un proceso de negocio. Su objetivo principal es modelar la lógica de negocio tanto para el “camino feliz” (el flujo estándar) como para gestionar excepciones y caminos alternativos.

4.1.4.1 Compuerta exclusiva

La compuerta de decisión exclusiva es una actividad del diagramador de BModeler que se utiliza para dirigir el flujo de un proceso hacia un camino o hacia otro, basándose en el cumplimiento de una condición específica.

A continuación, se presenta un detalle explicativo de su funcionamiento, requisitos y configuración para los usuarios:

1. Requisito Obligatorio de Conexión

Para poder configurar la lógica de una compuerta exclusiva, es indispensable que primero esté conectada físicamente en el lienzo a dos actividades de salida.

Si intentas configurar la decisión antes de realizar estas conexiones, el sistema te mostrará un mensaje indicando que la compuerta debe estar conectada a dos actividades para poder avanzar.

2. Configuración de la Decisión

Una vez realizadas las conexiones, al seleccionar la compuerta podrás acceder a su configuración:

Nombre de la decisión: Se debe definir una etiqueta clara para la condición (por ejemplo, “Aprobado”).
Dato a evaluar: Es el valor que el sistema va a revisar. Puede ser un valor fijo escrito de forma constante o, lo más recomendado, un atributo o parámetro dinámico del proceso (como la fecha de hoy o el propietario del caso).
Operadores de comparación: El sistema permite evaluar el dato mediante las siguientes funciones lógicas:
- Igual
- Distinto
- Mayor
- Menor
- Mayor o igual
- Menor o igual

3. Construcción de Condiciones Complejas

BModeler permite crear reglas más avanzadas combinando varias condiciones:

Conectores lógicos: Puedes utilizar operadores lógicos Y (AND) o O (OR) para evaluar múltiples variables en simultáneo. Por ejemplo: Si la fecha es igual a la de hoy Y el propietario del caso es un usuario específico.
Uso de paréntesis: Sirven para agrupar las condiciones y estructurar el orden de evaluación lógica.
Interfaz de Diseño (Drag and Drop): La construcción de la regla se realiza mediante un lienzo visual donde se arrastran y sueltan los conectores, paréntesis y condiciones.

5. Definición de Caminos (Verdadero / Falso)

Una vez que la condición está armada, se configuran las salidas del flujo de manera muy sencilla:

El usuario debe indicar qué actividad conectada debe ejecutarse si se cumple la condición (por ejemplo, enviar un mail automático).
De forma automática, el sistema asignará la ruta inversa (si no se cumple la condición) a la otra actividad que conectaste previamente, completando así la bifurcación lógica de la compuerta.

4.1.4.2 Compuerta paralela

La Compuerta Paralela (representada en el lienzo con un icono de suma “+” dentro de un rombo) es una actividad de control de flujo que permite dividir el proceso en múltiples caminos ejecutados simultáneamente o volver a integrarlos en un solo punto. A diferencia de la compuerta exclusiva, no evalúa condiciones ni reglas de negocio; la activación de todas sus ramas es incondiciona

A continuación, se detalla el funcionamiento de esta actividad:

El Ciclo de Divergencia y Convergencia

Este componente trabaja bajo un principio de apertura y cierre del flujo de trabajo:

Compuerta de Apertura (Divergencia): Es el punto en el diagrama donde un único camino se bifurca en múltiples actividades que se disparan simultáneamente. El maquetador muestra un aviso para recordar al diseñador que, para asegurar el correcto funcionamiento del proceso, es obligatorio colocar una segunda compuerta que vuelva a reunir los caminos segmentados.
Compuerta de Cierre (Convergencia): Es el punto donde todas las actividades que venían ejecutándose en paralelo se vuelven a encontrar para unificar el proceso y permitir que avance hacia las siguientes etapas.
El Par Obligatorio (DIvergencia y convergencia): Para garantizar la integridad del flujo, toda compuerta de apertura paralela debe contar obligatoriamente con su correspondiente compuerta de cierre asociada.

Regla de Sincronización Obligatoria

La compuerta de cierre actúa como un retenedor del proceso:

Espera al último camino: El flujo del proceso no seguirá adelante bajo ninguna circunstancia hasta que todas las actividades que se lanzaron en paralelo hayan finalizado.
Ejemplo práctico: Si la compuerta de apertura lanza tres tareas (como un envío de mail automático, una consulta a la inteligencia artificial y un formulario manual para un usuario externo): las actividades del mail y de la IA pueden terminar casi de inmediato. Sin embargo, si el usuario externo no completa el formulario, el caso completo permanecerá pausado en la compuerta de cierre y no avanzará en el flujo principal.

Importante:

No sirve para elegir caminos opcionales: si el monto es mayor a $1000 ir por flujo A, y si es menor ir por flujo B, no debes usar una compuerta paralela.
La solución: Para evaluar condiciones y seleccionar un único camino entre tres o más opciones, el usuario debe diseñar y anidar compuertas de decisión exclusivas en el lienzo.

4.1.4.3 Temporizador de fecha

El temporizador de fecha es una actividad del diagramador de BModeler diseñada para establecer plazos de entrega y controlar qué sucede cuando una tarea de usuario no se completa a tiempo.

A continuación, se detalla su comportamiento, reglas de diseño y configuración:

1. Regla Obligatoria de Ubicación (Anclaje)

A diferencia de otras actividades del diagramador, el temporizador de fecha no puede colocarse directamente sobre el lienzo en blanco.
Debe arrastrarse y soltarse obligatoriamente encima de una actividad de usuario. Al hacerlo, queda visualmente anclado a esa tarea específica.

Configuración del Flujo (Caminos de Salida)

Al igual que las compuertas exclusivas, para poder configurar este elemento, es necesario conectarlo físicamente a las actividades de salida primero:

Camino Feliz (A tiempo): Es la flecha que sale normalmente de la actividad de usuario hacia la siguiente etapa si el formulario es completado dentro del plazo.
Camino de Vencimiento (Expirado): Es la flecha que sale directamente desde el icono del temporizador hacia otra actividad (como un envío de mail de alerta o un fin alternativo del proceso) para definir qué camino toma el caso si el tiempo configurado se agota sin respuesta.

3. Modos de Configuración de Tiempo

Al abrir las propiedades del temporizador (una vez conectado), el sistema ofrece dos modalidades para definir el vencimiento: Desde el proceso y En ejecución.

En ejecución: En este modo, no se preconfigura ningún tiempo en el diagramador. El vencimiento se define al momento de ejecutar el caso.
- Ejemplo de uso: Está pensado para situaciones donde la tarea se asigna a un equipo completo. Quien tome el caso dentro de ese equipo puede reasignar la tarea a una persona específica y definir manualmente un límite de tiempo personalizado en ese instante.

Desde el proceso: El límite de tiempo se define rígidamente durante el diseño del diagrama.
- Se puede establecer una duración constante indicando un valor numérico y seleccionando la unidad de tiempo (día, hora o minuto).
- También existe la opción de definirlo de forma dinámica seleccionando un atributo del proceso que contenga dicho valor.

4.1.4.4 Compensador de tiempo

El compensador de tiempo es una actividad del diagramador de BModeler diseñada específicamente para detener o pausar el flujo de un proceso durante un período determinado y, una vez transcurrido ese lapso, reanudarlo de forma automática hacia la siguiente etapa.

A continuación, se detallan sus características de configuración, diferencias lógicas y recomendaciones de uso:

¿Para qué sirve y cómo se configura?

Pausa del proceso: Se utiliza cuando la lógica del negocio requiere una espera obligatoria entre dos acciones. Por ejemplo, se puede colocar en el medio del diagrama para que, tras enviar una notificación, el sistema espere 1 día (o un tiempo determinado) antes de enviar un formulario para completar.
Configuración del parámetro: Al abrir sus propiedades, el diseñador debe definir el valor correspondiente en el campo de tiempo de espera (“tiempo, espera”).

Diferencia clave con el Temporizador de fecha

Para evitar errores comunes de diseño en el lienzo, es vital comprender que operan bajo lógicas completamente distintas:

El compensador de tiempo se coloca de manera independiente en el flujo y su única función es congelar transitoriamente el avance general del caso por una cantidad de tiempo (como horas o días) antes de seguir adelante.
El temporizador de fecha se ancla de forma obligatoria sobre una actividad de usuario y sirve para establecer una fecha límite de entrega, derivando el flujo por un camino alternativo únicamente si el usuario no completa la tarea a tiempo.

Importante: Es indispensable conectar físicamente la salida del compensador hacia la actividad que debe continuar después de la pausa.

4.1.4.5 Conector de proceso

El conector de procesos es una actividad del diagramador de BModeler que sirve como un puente para enlazar y ejecutar un proceso secundario (subproceso) desde el flujo de un proceso principal (proceso padre).

Principales Beneficios

Reutilización de Lógica de Negocio: Permite modularizar tareas recurrentes (por ejemplo: validaciones crediticias, envío de notificaciones especiales, aprobaciones o cálculos complejos) y reutilizarlas en múltiples procesos sin necesidad de rediseñarlas.
Desacoplamiento y Limpieza de Diagramas: Reduce la complejidad visual de los flujos principales manteniendo cada proceso enfocado en su propósito específico.
Flexibilidad Operativa: Admite la combinación de tareas automáticas y manuales mediante modalidades sincrónicas o asincrónicas.

Nota: Un subproceso conserva su independencia; es decir, puede ser llamado por otro proceso a través de un conector o bien ejecutarse como un proceso autónomo por sí mismo.

Modalidades de Ejecución

Al configurar un Conector de Procesos, el usuario debe seleccionar cómo interactúa el flujo padre con el subproceso invocado. Hay dos modalidades de ejecución:

Modo Asincrónico (“Lanza y Continúa”)

Comportamiento del Proceso Padre: Dispara la ejecución del subproceso e inmediatamente avanza hacia la siguiente actividad de su diagrama.
Respuesta de Salida: No espera ninguna respuesta ni confirmación del subproceso.
Estructura JSON de Salida: Opcional. Si el subproceso no tiene salida configurada, se asigna una estructura vacía {}.
Mapeo de Datos: No requiere almacenar datos de retorno en el flujo principal.

Modo Sincrónico (“Lanza y Espera”)

Comportamiento del Proceso Padre: Pausa su flujo en la actividad del conector a la espera de que el subproceso finalice.
Respuesta de Salida: Requiere obligatoriamente que el subproceso retorne una respuesta estructurada para continuar.
Estructura JSON de Salida: Obligatorio. El subproceso debe tener definida una estructura de salida válida con al menos un par clave/valor.
Mapeo de Datos: Permite seleccionar o crear un atributo de tipo JSON en el proceso padre donde se guardará el resultado devuelto.

Condiciones de Elegibilidad de Subprocesos

Para que un subproceso aparezca disponible en el desplegable “Proceso a Ejecutar” dentro de la configuración del conector, debe cumplir obligatoriamente con los siguientes requisitos:

Habilitado como Subproceso: En la sección Detalles del proceso del subproceso, debe estar activada la casilla “Habilitar como subproceso”.

Tipo de Inicio Directo: En la Configuración de inicio del subproceso, la actividad de Inicio debe ser de tipo Directo.

Control de Recursividad (Bucles Infinitos): Para evitar ciclos infinitos de invocación, el sistema valida que no exista recursividad circular en la cadena de procesos.
Ejemplo: Si el Proceso A invoca al Subproceso B, y el Subproceso B invoca al Subproceso C, el Subproceso C no podrá seleccionar como subproceso a A, ni a B, ni a C. El sistema filtrará y excluirá automáticamente estos procesos del selector.

Regla de anidamiento: Se permite una profundidad multinivel (Padre → Hijo → Nieto → Bisnieto) siempre y cuando no se viole la regla anti-recursividad.

Elementos de la Configuración del Conector

En el entorno del diseñador, la actividad Conector de Procesos agrupa los siguientes componentes funcionales:

Definición Básica

Nombre de Actividad: Etiqueta descriptiva que identifica la función del conector en el diagrama (ej. “Validar Crédito del Cliente”).
Proceso a Ejecutar: Selector con filtrado automático que enumera únicamente los subprocesos válidos y elegibles.

Entradas y Parámetros Iniciales

Parámetros de Inicio del Subproceso: Si el subproceso elegido requiere datos de entrada para comenzar (definidos en la configuración de la actividad de Inicio), el conector los detecta automáticamente y los presenta como campos obligatorios. Cada parámetro se puede completar con un valor constante o vincular con un atributo existente en el proceso padre.

Gestión de Salidas y Respuestas (Modo Sincrónico)

Atributo de Almacenamiento (¿Dónde guardar respuesta?): Determina qué variable del proceso padre guardará la información estructurada que retorne el subproceso. Se puede seleccionar un atributo JSON existente o crear uno nuevo en el momento.

Estructura de Respuesta del Subproceso: Configurada a nivel del subproceso (sección Detalles del proceso). Define las claves y valores que el subproceso entregará al padre al concluir, independientemente del camino interno que haya recorrido.

Disponibilidad de la Casilla de Subproceso: Como se comentó anteriormente, la habilitación como subproceso se gestiona desde el menú de Detalles del proceso una vez que el proceso ya existe.

Cabe aclarar que la casilla de habilitar como subproceso no está disponible en la ventana de creación del proceso inicial (botón “Crear nuevo proceso”) debido a que para definir salidas o contratos de datos es indispensable que la estructura general y sus atributos ya estén registrados.

Visibilidad, Monitoreo y Trazabilidad en la Grilla de Casos

El uso del Conector de Procesos impacta directamente en el panel de monitoreo de BModeler (BModeler - Casos), garantizando transparencia y trazabilidad sobre cada ejecución:

Nomenclatura Jerárquica de Casos Hijos: Cuando se dispara un subproceso desde un conector, se crea un caso independiente que en la columna ID adopta automáticamente la estructura:
[ID_Caso_Hijo] - Hijo_de_[Nombre_del_Proceso_Padre]
Inyección Automática de Metadatos: Al momento de la llamada, el sistema transmite automáticamente al caso hijo metadatos clave del proceso padre (como el ID del caso de origen y el usuario propietario inicial) sin requerir que el usuario configure variables adicionales.
Doble Naturaleza del Subproceso: Un proceso habilitado como subproceso cumple dos funciones posibles:

Como Caso Hijo: Ejecutado a través de un conector, mostrando la etiqueta Hijo_de_ en la grilla.
Como Caso Independiente: Ejecutado de forma directa e individual (por ejemplo, desde el botón “Nuevo Caso”), apareciendo en la grilla con un ID estándar sin prefijo.

Gestión de Excepciones y Fallos: En la modalidad sincrónica, si un subproceso sufre un fallo o detención por error, el evento es notificado al proceso padre como un resultado formal. Esto genera que el proceso padre se coloque como estado fallido.

4.1.5 Procesador de listas

El Procesador de listas (o Iterador de listas) es un componente contenedor diseñado para recorrer colecciones de datos estructuradas en formato JSON de forma secuencial, segura y controlada. Su función principal es ejecutar un flujo de trabajo por cada elemento de una lista de entrada, y consolidar automáticamente los resultados en un atributo global.

El procesador de listas admite como máximo una sola actividad dentro del contenedor por iteración y funciona de manera exclusiva sobre estructuras de datos en formato JSON (listas simples o listas de objetos).

Actividades Permitidas

El contenedor admite una sola actividad embebida.

Las actividades internas admitidas son:

Actividad Automática
Actividad de Usuario
Agente de IA
Llamada a subproceso con inicio por API

Integración con Subprocesos:

Solo pueden seleccionarse subprocesos que tengan configurado un tipo de Inicio Directo por API.
Cuando la actividad interna es una invocación a un subproceso, la arquitectura de BModeler aplica un principio de desacoplamiento total:
- Garantía de aislamiento: El proceso padre no puede acceder ni modificar las variables internas o el estado del subproceso hijo, ni el hijo tiene visibilidad del entorno global del padre.
- Contrato de Entrada/Salida: Toda transferencia de información entre ambos procesos se realiza formalmente a través de un contrato de parámetros:
  - Entrada: El proceso padre mapea y envía únicamente los datos requeridos como parámetros de inicio del subproceso hijo.
  - Salida: El subproceso hijo ejecuta su flujo interno de forma independiente y, al finalizar, devuelve una estructura estandarizada que el procesador de listas toma para anexar al atributo de respuesta consolidada.

Importante: Si se incluye una Actividad de usuario / manual dentro del contenedor y no se le configura un plazo de vencimiento (timeout) mediante un temporizador, el diagramador mostrará una advertencia visual en el diseño para prevenir que un hilo de ejecución quede bloqueado de manera indefinida esperando la respuesta de un usuario.

Configuración

Nombre del procesador: Identificador descriptivo del elemento dentro del diagrama del proceso.
Lista a recorrer: Atributo de origen que contiene la colección a iterar. Debe ser obligatoriamente de tipo JSON.
Tratamiento de fallos: Define el comportamiento del motor del proceso ante un error en una iteración individual:
- Pausar y marcar el hilo como fallido: Detiene la ejecución en la iteración afectada y marca el hilo en estado fallido. Esto permite reintentar la ejecución desde ese punto específico sin necesidad de reiniciar todo el proceso. Esta opción se encuentra seleccionada por defecto.
- Ignorar el error y continuar: Omite la iteración que presentó el fallo, registra la novedad en la auditoría del caso y avanza automáticamente a la siguiente iteración.
Guardar respuesta en: Este campo no es obligatorio. Si se deja en blanco, el procesador de listas recorrerá la colección y ejecutará la actividad configurada por cada elemento, pero no guardará una lista de respuestas en una variable global al finalizar el ciclo. Resulta útil cuando las iteraciones realizan acciones directas (como enviar notificaciones o actualizar registros externos) donde no se requiere retornar datos al proceso padre. Ofrece las siguientes opciones:
- Crear un nuevo atributo
- Seleccionar un atributo existente: Permite elegir un atributo del proceso.
Luego se configura la actividad que se requiere procesar por cada elemento de la lista (en la imagen se arrastro una actividad de usuario).

4.1.6 Fin

La actividad fin concluye el flujo de un caso dentro de BModeler. Su configuración en el lienzo es sumamente directa, ya que únicamente requiere que se le asigne un nombre y se conecte con la actividad anterior.

El sistema permite utilizar dos tipos de eventos de fin según las necesidades de diseño:

Fin Común

Es el cierre estándar que se utiliza cuando el proceso se ejecuta con normalidad y finaliza bajo las condiciones deseadas o esperadas (el “camino feliz”).

Fin Alternativo

Este tipo de fin sirve para diferenciar visualmente los distintos desenlaces que pueden tener los casos.

Lógica de desvío: Se utiliza para separar el camino exitoso de los caminos de excepción o desvíos. Por ejemplo, si una actividad se vence por tiempo y el caso se cierra de manera anticipada, se puede conectar a un fin alternativo.
Identificación en la grilla de casos: Su gran ventaja es que permite distinguir de forma clara en la grilla de casos cómo terminó cada instancia. De este modo, el usuario puede saber rápidamente si el caso concluyó de la forma planeada o si finalizó debido a un vencimiento u otra causa externa.
Criterio del usuario: No implica necesariamente un resultado negativo; queda a total consideración de quien diseña el proceso decidir si lo utiliza para reconocer un vencimiento, un rechazo o simplemente un flujo de cierre administrativo diferente

4.1.7 Maquetador de formulario

El maquetador de formularios de BModeler es la herramienta visual integrada dentro de las actividades de inicio (por formulario) y las actividades de usuario. Está diseñado bajo una interfaz de “arrastrar y soltar” (drag and drop), lo que permite a los diseñadores estructurar campos de manera sencilla para que los usuarios finales —tanto internos de la organización como invitados externos— carguen y validen información.

A continuación, se presenta un detalle explicativo de sus funcionalidades y características clave:

Estructura y Organización del Lienzo

El maquetador se conforma por dos pestañas: Formulario (construcción del formulario) y Estilos (configuración del estilo a aplicar al formulario).

Formulario

Esta pantalla cuenta con las siguientes secciones:

Añadir: lista de campos (widgets) disponibles.
Editar: una vez que el campo es arrastrado al panel derecho, se habilita esta solapa para poder realizar la configuración.

Los diferentes campos de carga (widgets) se organizan mediante contenedores, los controles de los contenedores aparecen una vez que se arrastró el primer campo:

Columnas: Cada contenedor puede configurarse en una o varias columnas para distribuir los widgets visualmente.
Duplicar y Eliminar: Es posible replicar exactamente un contenedor completo con un solo clic (botón de copiar) o eliminarlo de forma directa con el icono del tacho de basura.

4. Procesos_Actividades-4.1.6 Maquetador de formulario-41920×858 59.5 KB
Paginado (“Dividir formulario en pasos”): El diseñador puede activar esta opción para que cada contenedor del lienzo se comporte como una página individual. Al usuario final se le presentará un formulario paginado con botones para avanzar paso a paso. Si esta opción se desactiva, todo el contenido se mostrará de corrido en una sola página con desplazamiento vertical (scroll).

Visualización responsive: se puede ir diseñando el formulario y ver como se visualiza en diferentes resoluciones. El maquetador incluye una botonera superior que permite alternar la vista previa entre PC/Escritorio, Tablet y Teléfono móvil.

Vista previa: al hacer clic se visualiza el resultado final del formulario (como lo visualizará quien lo complete). Ej: En caso de querer ver cómo se visualizará el formulario en un teléfono móvil y con división en pasos. Para volver a seguir editando se debe hacer clic en el botón “Volver a editar”.

Configuración y Propiedades de los Widgets

Al seleccionar cualquier elemento arrastrado, se habilita la pestaña de edición para ajustar sus propiedades individuales:

Campo Requerido (Obligatorio): Si se activa esta propiedad, el usuario final no podrá completar el formulario ni avanzar en el proceso hasta que el campo contenga datos (el botón de continuar permanecerá bloqueado).
Solo Lectura: Permite mostrar información fija o precalculada que el usuario no podrá editar, útil en etapas de validación o control.

Título y Textos de Ayuda: Se puede activar o desactivar el título del widget, definir una descripción explicativa en la parte inferior y configurar un placeholder (texto indicativo gris dentro del campo).

Guardar en Atributo (Persistencia de Datos): Todo dato que se requiera utilizar en etapas posteriores del proceso debe guardarse en un atributo. El maquetador asiste al usuario filtrando y forzando que el tipo de atributo coincida exactamente con la naturaleza del widget (por ejemplo, el widget de número solo permite guardar o crear atributos numéricos).

Tipos de Widgets Disponibles

El maquetador cuenta con una paleta diversa de elementos para capturar diferentes tipos de datos:

Campos de Texto: Para cadenas generales (línea simple) o bloques extensos (TextArea).

Números y Fechas: Campos validados para valores numéricos, fechas o fecha y hora, que incluyen funcionalidades avanzadas como fechas relativas (por ejemplo, definir por defecto “hoy menos 2 días”).

Selectores de Opciones:
- Checkbox y Radio Button: Para selecciones múltiples o exclusivas.

En el caso de Radio Button, se puede editar las opciones (1) y valor (2) que se guardará cuando se seleccionen.

Selector: Desplegables que pueden cargarse de forma estática (escribiendo clave-valor a mano) o de forma dinámica (realizando consultas automatizadas a un diccionario de datos o API).

En el caso de seleccionar que sea dinámico, se puede indicar si se quiere que sea Simple o Anidado.

Simple: Lo primero que se debe configurar es si se quiere utilizar datos del Diccionario de Datos de Finnegans o no.

En el campo “Diccionario de datos o API”, cambiando entre los iconos de la T o las tres rayas horizontales se selecciona si se quiere seleccionar un maestro existente o ingresar la URL de una API, según se muestra a continuación

Si se selecciona un maestro, se puede configurar una cabecera de requerirlo:

Luego se deben obtener los datos para poder indicar qué dato es el que se va a mostrar en “dato a mostrar” como opción del selector y cual es el dato que se guardará en “dato a guardar”.

Anidado: Los selectores anidados (o en cascada) permiten establecer relaciones de dependencia jerárquica entre diferentes campos de tipo selector dentro de los formularios de BModeler. Con esta funcionalidad, la selección que realiza el colaborador que debe completar el formulario en un selector principal (padre) filtra automáticamente las opciones disponibles en los selectores secundarios (hijos) en tiempo de ejecución.

Al seleccionar tipo Anidado se debe presionar en “Configurar selectores” para comenzar la configuración de los selectores anidados

Aquí se crea la configuración de un Nivel 1 (nivel raíz) de selector anidado. El comportamiento técnico varía en función de dónde provengan los datos configurados:

Seleccionar API Finnegans: Se selecciona una API existente de Finnegans. Una vez seleccionada la API Finnegans se puede configurar una Cabecera, si el campo es requerido (obligatorio de completar para el colaborador), el Título con el que aparecerá el selector en el formulario y en qué atributo se quiere guardar:

Luego de igual manera que para los selectores dinámicos Simple desde API se Obtiene los datos para completar qué dato es el que se va a mostrar en “dato a mostrar” como opción del selector, cual es el dato que se guardará en “dato a guardar” y “Valor para cascada” que será el valor que se utilizara para prefiltrar el selector del siguiente nivel.

Al presionar en “Agregar selector” el sistema dará la posibilidad de configurar un segundo selector dependiente del anterior el cual se pre filtrara por el dato filtrado en “Valor para cascada” en momento de ejecución:

Una vez seleccionada la “API del siguiente nivel” se habilitará la posibilidad de configurar el selector de Nivel 2, con la misma dinámica del Nivel 1, se configura cabecera de ser necesario, si es campo requerido, Título de selector, guardar en atributo, se obtiene datos para completar qué dato es el que se va a mostrar en “dato a mostrar” como opción del selector, cual es el dato que se guardará en “dato a guardar” y “Valor para cascada” que será el valor que se utilizara para prefiltrar el selector del siguiente nivel.

Desde aquí tenemos posibilidad de configurar selectores dependientes del Nivel 2 o agregar selectores desde el Nivel 1 que sería el nivel raíz directamente relacionándolos al mismo.

APIs Externas: Permite consumir endpoints o servicios web propios desarrollados por otros equipos. El usuario ingresa manualmente la URL del Endpoint correspondiente a cada nivel (Nivel 1, Nivel 2, etc.).

Una vez colocada la URL se puede configurar Parámetros de ruta y la Cabecera.

La configuración y la concatenación siguiente de los distintos niveles (Nivel 1, Nivel 2, etc) se realiza de igual manera y con la misma lógica que la explicada en Seleccionar API Finnegans.

La única excepción en la configuración es que dado que la API se ejecuta en tiempo de ejecución, al obtener datos en tiempo de diseño, dispondremos de un campo llamado Columna de relación y Valor de ejemplo (solo preview) que servirá para indicar que columna se relacionara con el siguiente nivel y probar que la API conecte correctamente y asegurarse que se conecte de manera correcta con el siguiente nivel.

En caso de querer eliminar algún Nivel disponemos del icono del tachito de basura para eliminarlo sin inconvenientes.

Una vez finalizada la configuración presionamos el botón Guardar y la configuración persistirá.

Subida de Archivos: Permite al usuario adjuntar documentos que se guardarán en un atributo de tipo archivo.

Grillas (Tablas): Tablas interactivas basadas en estructuras JSON para que el usuario complete filas y columnas. Para poder configurar un widget grilla lo primero que se debe hacer es tener la estructura en un atributo tipo JSON. Esta estructura ya puede tener datos o simplemente plantear una estructura de grilla vacía que se completará en el momento de ejecución del caso.

Una vez que se selecciona el atributo desde donde se va a tomar la estructura y donde luego de la ejecución se guardan los valores, se puede configurar como se visualizará la grilla en el momento de ejecución.

Una vez que selecciono la estructura que me interesa en este caso las “filas”, puedo comentar a ajustar las columnas.

En el caso que el diseño requiera que una de las columnas de la grilla sea editable y los datos se ingresen en el momento de ejecución del caso, se debe tildar el check de “Permite edición” e indicar el tipo de dato que permite la celda.

Nota: en el caso de requerir que la celda ofrezca opciones se puede elegir la opción “Selector” y tendrá el mismo tratamiento que el widget Selector visto anteriormente

Descripción: Textos enriquecidos con alineación que funcionan como separadores estéticos.

Envío de Link: enlaces cliqueables hacia URLs externas.

Importante: se aplica la misma distribución de columnas en todos los dispositivos (no reorganiza de manera responsiva automática las columnas múltiples a una sola en pantallas pequeñas). Por lo tanto, si se pretende que los usuarios completen el formulario desde dispositivos móviles, la recomendación oficial es diseñar siempre los contenedores utilizando una sola columna para garantizar que los campos no se deformen ni se vuelvan ilegibles en celulares.