Business Central: eventos frente a disparadores en AL, una guía de tiempos para desarrolladores

By Mirko Peters · 2026-08-22

Domina el desarrollo de AL en Business Central entendiendo cuándo usar disparadores o suscriptores de eventos para la lógica de negocio personalizada, las validaciones y las comprobaciones de registro.

Automatically translated with AI from the original post. Read the English original

Comprender la diferencia entre disparadores y eventos en el desarrollo de AL para Microsoft Dynamics 365 Business Central es fundamental para escribir extensiones limpias y fáciles de mantener. Elegir el mecanismo de ejecución adecuado garantiza que tus reglas de validación se ejecuten en el momento exacto, evita la entrada de datos incorrectos y protege las actualizaciones en la nube sin duplicar el código de la aplicación base.

Puntos clave

• Los disparadores están integrados directamente en objetos AL concretos y se ejecutan de inmediato cuando se produce un evento del objeto o una modificación de datos.
• Los suscriptores de eventos permiten que tu extensión escuche notificaciones de todo el sistema sin modificar el código de la aplicación base ni copiar procesos nativos extensos.
• Elegir entre los eventos "on before" y "on after" determina si tu código personalizado puede impedir una transacción o simplemente reaccionar a una acción ya completada.
• Un buen momento de ejecución permite que las reglas de validación detecten los errores pronto y evita cuellos de botella de rendimiento durante operaciones intensivas, como el registro de pedidos de venta.

La arquitectura de la lógica personalizada en Business Central

Al extender Dynamics 365 Business Central con el lenguaje de aplicaciones de Microsoft (AL), escribir el código es solo la mitad del trabajo. El verdadero reto está en decidir dónde y cuándo debe ejecutarse ese código. Tanto si añades un sencillo campo de nivel de recompensa a un registro de cliente como si aplicas una compleja comprobación de cumplimiento antes de generar una factura, la longevidad y la estabilidad de tu extensión dependen de cómo te enganches al sistema.

Los modelos de desarrollo antiguos solían animar a reescribir directamente el código nativo de la aplicación. Si querías que una comprobación se ejecutara antes de registrar un documento, insertabas tu lógica directamente en la rutina de registro principal. Aunque esto funcionaba de forma temporal, cada actualización importante de Microsoft se convertía en un doloroso proyecto de reconciliación. El desarrollo moderno de extensiones para Business Central se basa en un modelo modular y basado en aplicaciones. En lugar de reescribir rutinas estándar, los desarrolladores usan puntos de conexión integrados, en concreto disparadores y eventos, para incorporar la lógica personalizada de forma segura junto al código estándar de la aplicación.

Desmitificando los disparadores de AL

Un disparador es un punto predefinido y designado dentro de un objeto AL donde puedes escribir código que se ejecuta automáticamente cuando se produce una acción concreta. Todos los objetos, estándar y personalizados, incluidas las tablas, las extensiones de tabla, las páginas, las extensiones de página, los informes y los codeunits, contienen estos puntos nativos.

Piensa en un escenario práctico: tu organización ha añadido un campo personalizado de ID de recompensa en el registro de cliente. Cuando un usuario selecciona un nivel de recompensa de la lista desplegable, el sistema debe comprobar de inmediato si la cuenta del cliente está bloqueada o si hay atributos secundarios que haya que actualizar. Al utilizar el disparador OnValidate de ese campo concreto, tu código se ejecuta en el mismo instante en que el usuario realiza el cambio.

Cuándo usar disparadores

Los triggers se aprovechan mejor cuando tu lógica de negocio pertenece exclusivamente a un único objeto y a su contexto inmediato. Por ejemplo:

• Validar que un campo de fecha personalizado cae dentro de un trimestre de negocio aceptable.
• Ejecutar la lógica de inicialización cuando se abre una página de tarjeta para un nuevo registro.
• Limpiar los valores de campos dependientes cuando se desmarca una opción principal.

Como los triggers están muy acotados a sus objetos host, facilitan que el código localizado sea fácil de encontrar, leer y mantener con el tiempo.

Aprovechar los eventos y suscripciones de Business Central

Mientras los triggers gestionan acciones localizadas, los procesos más amplios de varios pasos, como registrar pedidos de venta, enviar inventario o generar diarios financieros, requieren un enfoque más sofisticado. No puedes simplemente insertar tu código de validación en medio de una rutina de registro compleja sin romper el modelo de extensibilidad.

Aquí es donde los eventos y los suscriptores de eventos se vuelven imprescindibles. Piensa en un evento como una notificación oficial que emite la aplicación estándar de Business Central. El sistema anuncia hitos importantes, como 'un registro está a punto de insertarse' o 'un documento de venta está a punto de registrarse.' Tu extensión puede escuchar estos avisos mediante un procedimiento suscriptor de eventos.

Cuando Business Central lanza ese evento con nombre, tu procedimiento suscrito se activa, ejecuta tu regla personalizada y, o bien da luz verde, o bien detiene el proceso con un mensaje de error descriptivo. Y lo más importante: tu extensión nunca tiene que copiar, pegar o reescribir el motor de registro subyacente.

El poder del momento: OnBefore frente a OnAfter

Al crear suscriptores de eventos en AL, las convenciones de nomenclatura revelan el momento de ejecución. Comprender este momento es fundamental para la fiabilidad del sistema:

• Eventos OnBefore: se ejecutan justo antes de que una acción estándar termine o se confirme. Es el lugar ideal para la lógica de bloqueo y las comprobaciones de validación. Si falta un documento de cumplimiento obligatorio en un pedido de venta, un evento OnBefore de registro puede detectar la omisión, cancelar la transacción y mostrar un mensaje de advertencia útil.
• Eventos OnAfter: se ejecutan inmediatamente después de que un proceso estándar se complete correctamente. Usa suscriptores OnAfter cuando necesites reaccionar a una acción terminada, como crear automáticamente una tarea de seguimiento, actualizar una tabla de registro externa o notificar a un gestor de cuentas una vez que el pedido se ha registrado por completo.

Una regla que se ejecuta demasiado tarde no puede impedir una transacción defectuosa, mientras que una regla que se ejecuta demasiado pronto puede carecer de los datos necesarios que calcula la rutina estándar. Asociar tu lógica a la firma de evento correcta elimina estos problemas.

Conclusión

Dominar el equilibrio entre los triggers de objeto y los suscriptores de eventos transforma la forma en que abordas las extensiones de Business Central. Al aprovechar los triggers localizados para las validaciones de campos y los suscriptores de eventos para los procesos de todo el sistema, consigues que tus personalizaciones se mantengan resistentes a las actualizaciones en la nube y que tu entorno siga siendo rápido y seguro.

Para profundizar en los principios de diseño de aplicaciones modernas y escuchar análisis arquitectónicos de expertos, escucha el episodio completo del podcast M365 FM. ¡Sintoniza para descubrir cómo los arquitectos y desarrolladores de la nube optimizan el ecosistema de Microsoft para lograr el éxito empresarial en el mundo real!

Preguntas frecuentes

¿Cuál es la diferencia principal entre un trigger y un suscriptor de eventos en AL?

Un trigger es un punto de ejecución de código predefinido que se crea directamente dentro de un objeto AL específico (como un campo de tabla o una página), mientras que un suscriptor de eventos es un procedimiento independiente de tu extensión que escucha las notificaciones publicadas por la aplicación base u otros objetos, sin modificar el código original.

¿Puede un suscriptor de eventos impedir que se registre un pedido de venta?

Sí. Si usas un suscriptor de eventos "on before" vinculado al proceso de registro, tu código personalizado puede evaluar las condiciones de negocio, lanzar un mensaje de error y detener la transacción antes de que la rutina de registro finalice los asientos.

¿Cuándo debo usar un trigger de validación de campo de tabla en lugar de un suscriptor de eventos?

Debes usar un trigger de validación de campo de tabla cuando tu regla de negocio esté estrictamente ligada al cambio de valor de ese campo concreto, por ejemplo, para comprobar si existe un Reward ID personalizado o para asegurar que un campo de estado relacionado se actualiza de inmediato al introducir datos el usuario.

¿Por qué es crítico el momento de ejecución al escribir suscriptores de eventos en AL?

El momento de ejecución determina si tu código se ejecuta antes o después de que se complete un proceso principal. Si tu regla se ejecuta demasiado pronto, es posible que los datos necesarios aún no estén completos; si se ejecuta demasiado tarde, pierdes la capacidad de bloquear transacciones no válidas.