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 o entregable específico del proyecto. Por ejemplo, si tu BEP define un flujo de coordinación, cada ciclo de detección de choques en cada modelo se convierte en una instancia independiente de ese flujo. Cada instancia tiene su propio estado actual, su propio historial de transiciones y su propio registro de quién hizo qué y cuándo. Esto es lo que le da al equipo trazabilidad: no solo cómo debería ser el proceso, sino lo que realmente ocurrió.
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 tres 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 comentario de la persona que envía. Un evento de aprobación podría incluir el nombre 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. Pero los efectos pueden hacer cualquier cosa: actualizar un sistema externo, crear un registro, disparar una acción en otra herramienta.
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.
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 dos opciones.
Escribirlo tú mismo. Si tu equipo tiene un desarrollador, el runtime es una clase TypeScript que extiende el runtime base de dotBEP. Implementas cada efecto y automatización como una función handler. El SDK de dotBEP proporciona los tipos y las herramientas para hacerlo con seguridad de tipos completa. El código fuente y la documentación están disponibles en el repositorio de GitHub de dotBEP.
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 o automatización. 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. En cualquier caso, 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.