Ejecución del BEP

Un BEP definido en dotBEP no es un documento estático. Una vez que los flujos de trabajo están en su lugar, el BEP puede ponerse en uso activo: el equipo crea instancias de esos flujos para rastrear el trabajo real en progreso, registrar cada decisión y transición, y mantener un registro completo de cómo se llevó a cabo realmente el proyecto. Esto es lo que hace posible el motor de ejecución de dotBEP.

El motor de ejecución

El motor de ejecución es la parte de dotBEP que da vida a los flujos de trabajo. Gestiona el ciclo de vida de las instancias de flujo: crearlas, hacerlas avanzar por sus pasos a medida que ocurren eventos, y registrar cada transición en el camino.

Una instancia de flujo es una ejecución individual de un flujo de trabajo vinculada a un activo específico del proyecto. Ese activo puede ser interno (un entregable definido en el BEP) o externo (cualquier recurso identificado por una URL, como un archivo de Navisworks o una página de Notion). Cada instancia tiene su propio estado actual, su propio historial de transiciones y su propio registro de quién hizo qué y cuándo.

El runtime

Cada BEP en dotBEP tiene su propio runtime. El runtime es la capa ejecutable del BEP: el código que da vida a los comportamientos definidos en los flujos de trabajo. Sin el runtime, un flujo de trabajo es un diagrama. Con él, el flujo puede enviar notificaciones, ejecutar verificaciones automáticas, responder a señales de software externo y encadenar acciones sin intervención humana.

Esta es la expresión más clara de lo que separa al BEP como documento del BEP como software. El runtime es lo que hace concreta esa transición.

Eventos, efectos y automatizaciones

Cuando defines un flujo de trabajo en dotBEP, puedes adjuntarle cuatro tipos de comportamientos. Cada uno cumple un propósito diferente en la ejecución del proceso.

Eventos

Los eventos son señales que mueven una instancia de flujo de un paso al siguiente. Representan algo que ocurrió: se envió un archivo para revisión, se aprobó un modelo, se resolvió un choque. Cuando se emite un evento, el motor verifica qué transición activa desde el paso actual y hace avanzar la instancia en consecuencia.

Los eventos pueden llevar datos consigo. Un evento de envío podría incluir un enlace al archivo enviado. Un evento de aprobación podría incluir los comentarios del revisor. Esos datos se vuelven parte del contexto de la instancia y pueden ser usados por los pasos siguientes.

Efectos

Los efectos son acciones que se ejecutan automáticamente cuando ocurre una transición. Cuando el motor hace avanzar una instancia de flujo de un paso al siguiente, cualquier efecto adjunto a esa transición se dispara inmediatamente después. Un uso común son las notificaciones: cuando se completa un paso, los miembros relevantes del equipo son informados automáticamente.

Los efectos son de disparo y olvido (fire-and-forget): el motor los despacha y continúa sin esperar un resultado. Esto los hace adecuados para notificaciones y registro, pero no para operaciones donde necesitas saber si la acción tuvo éxito, como actualizar datos en un sistema externo. Para esos casos, usa una automatización en su lugar.

Los efectos se definen en el BEP y se implementan en el runtime. El BEP declara qué efectos existen y qué transiciones los activan. El runtime contiene el código real que los lleva a cabo.

Automatizaciones

Las automatizaciones son pasos del flujo de trabajo que se ejecutan sin intervención humana. Donde un paso regular requiere que una persona tome una acción y emita un evento para continuar, una automatización corre por su cuenta: realiza su lógica e inmediatamente emite el evento que hace avanzar el proceso.

Un uso típico es la validación automática: cuando se envía un archivo de modelo, una automatización verifica si cumple ciertos criterios y enruta la instancia al paso de aprobación o de vuelta al autor según el resultado. Nadie necesita activar esto manualmente. El motor llega al nodo de automatización y el paso se ejecuta solo.

Triggers

Los triggers son la forma en que el software externo inicia una instancia de flujo sin que un usuario la arranque manualmente. Cuando una herramienta conectada emite una señal (una nueva versión de modelo subida, un reporte de choques generado, un cambio de estado en una herramienta de gestión de proyecto), el motor la recibe, resuelve qué flujo iniciar y qué activo rastrear, y crea la instancia automáticamente.

Los triggers se definen en el BEP y se implementan en el runtime. El BEP declara qué software puede activar qué flujos. El runtime contiene el handler que interpreta la señal entrante y la mapea al flujo y activo rastreado correctos.

Escribir el runtime

El runtime es código y vive separado del esquema del BEP. No necesita escribirse para autorar un BEP. Si tu proyecto solo usa dotBEP para gobernanza y planificación de coordinación, el runtime no es necesario.

Pero si tu equipo quiere usar el motor de ejecución, el runtime debe implementarse. Tienes tres opciones.

Escribirlo tú mismo. Si tu equipo tiene un desarrollador, el runtime es un proyecto TypeScript que extiende el runtime base de dotBEP. Implementas cada efecto, automatización y trigger como una función handler. El CLI de dotBEP proporciona el andamiaje, los tipos y las herramientas para empezar rápidamente.

Dejar que tu asistente de IA lo escriba. Puedes pedirle directamente a tu IA que implemente el runtime basándose en una descripción de lo que quieres que haga cada efecto, automatización o trigger. Si quieres ir más lejos, existen agentes de IA especializados en escribir código, como Claude Code, GitHub Copilot o Cursor, cuya especialidad es precisamente generar, revisar y refinar código.

Empieza dándole a tu asistente este prompt para que scaffoldee y configure el proyecto por ti:

Quiero crear un nuevo runtime para un BEP. Sigue las instrucciones en https://raw.githubusercontent.com/HoyosJuan/dotbep-cli/refs/heads/master/README.md para scaffoldearlo y configurarlo.

Una vez configurado el proyecto, describes el comportamiento en lenguaje natural y el asistente genera el código correspondiente:

En el flujo de coordinación, añade un efecto al paso de aprobación que envíe una notificación por email al equipo responsable cuando se complete el paso.

Añade una automatización al paso de envío de modelo que verifique si el archivo está en formato IFC y enrute la instancia al paso de revisión si lo está, o de vuelta al paso de envío si no lo está.

El asistente escribirá el código del runtime, explicará qué hace cada parte y realizará ajustes según tu retroalimentación. No necesitas entender el código para validar que hace lo que necesitas.

Dejar que el equipo de dotBEP te ayude. Si quieres que tu BEP cobre vida pero no cuentas con los recursos de desarrollo para escribir el runtime, el equipo de dotBEP puede construirlo por ti. Esto incluye implementar efectos, automatizaciones, triggers e integraciones con herramientas de terceros, y brindar soporte continuo a medida que tus flujos evolucionan. Escribe a juan@dotbep.com para conversar sobre lo que tu proyecto necesita.