Bienvenidos a otro episodio de Microsoft Knowledge Nuggets. Soy su anfitrión, Miro Peters. Aquí tienen el escenario. Están trabajando en Business Central y necesitan un pequeño cambio. Quizás un campo adicional en un registro de cliente, un paso a producción diferente, o una regla que verifique un pedido antes de registrarlo. Luego, alguien mencione esa L, tablas, páginas y unidades de código, y de repente esa pequeña solicitud suena como un lenguaje totalmente nuevo. Es un lenguaje claro, pero no tiene por qué parecer misterioso. Piensen en Business Central como un edificio de oficina. A él les da a los desarrolladores las instrucciones para añadir una habitación, un formulario o una nueva regla sin tener que abrir agujeros en el edificio mismo. Esa es la pepita de conocimiento hoy. Al final de este episodio sabrán qué significa el desarrollo A.L., porque existen las extensiones, y cómo encaja el trabajo personalizado en Business Central.

¿Por qué las empresas personalizan Business Central? Business Central ya maneja muchas de las tareas diarias de finanzas, clientes, pedidos de venta y facturas de stock, todo en un sistema conectado a un sistema conectado en lugar de una pira de hojas de cálculo y herramientas separadas. Para muchas empresas, esa configuración estándar cubre la mayor parte del trabajo. Pero aquí está el detalle. No hay dos empresas que trabajen de la misma manera. Tomen como ejemplo a un distribuidor de alimentos que necesita detalles de lote que otra empresa nunca utiliza, un negocio de servicios que requiere un proceso de aprobación especial antes de facturar, un minorista que desea niveles de recompensa para descuentos, y alguien más que necesita un formulario con sus propios campos de redacción y reglas internas. El negocio no cambiará su forma de operar por un campo faltante. Y tampoco quieren que cada pequeña solicitud se convierta en un cambio arriesgado para todo el sistema.

Eso solía ser un problema mayor. Sistemas antiguos. Los desarrolladores abrían el código original y lo editaban directamente. Y funcionaba hasta que llegaba la siguiente actualización. Entonces la empresa tenía la nueva versión de Microsoft por un lado, sus propios cambios por el otro, y alguien tenía que reconciliar todo antes de que la actualización pudiera avanzar. Imaginen una oficina donde cada inquilino pasa nuevos cables a través de las paredes sin un plan. Funciona por un tiempo, pero cuando el edificio necesita reparaciones, nadie sabe qué cable pertenece a quién. Business Central toma una ruta diferente. En lugar de reescribir la aplicación estándar, los desarrolladores crean un complemento separado que se conecte a ella, manteniendo la parte estándar en su lugar mientras los cambios propios de la empresa se sitúan al lado y operan a través de puntos compatibles en el sistema. Esa separación es importante cuando llegan las actualizaciones, porque Microsoft actualiza su parte del edificio mientras que el trabajo personalizado permanece en su propio espacio.

Aún hay pruebas y correcciones después de todo el software, pero no se espera que el desarrollador copie y rehaga cada cambio dentro del código original de Microsoft. Entonces, ¿qué es lo que una empresa personaliza realmente? Las personalizaciones añaden datos. El sistema estándar no almacena cosas como instrucciones de entrega, un puntaje de riesgo interno, un nivel de membresía o un enlace a un sistema externo. Y añaden pantallas que guían al personal a través de una tarea en el orden correcto. También aplican reglas como detener un pedido cuando falta un documento requerido. Trabajo personalizado también ayuda a evitar pasos manuales. Imagina al personal copiando datos de clientes desde Business Central a otra herramienta cada viernes, verificando condiciones a mano y luego enviando un informe a un gerente. Un cambio bien diseñado mantiene esa información en Business Central, aplica la reglámina consistente y le da al personal un botón o página que se ajusta a su trabajo diario.

Despejemos un mito. No querrá personalizar todo. Business Central estándar ya tiene muchos procesos integrados. Cambiar algo solo porque se ve diferente de un sistema antiguo genera trabajo adicional más adelante. Por lo tanto, un buen trabajo personalizado comienza con una razón comercial. ¿Qué problema está enfrentando la gente? ¿Qué debería suceder en su mundo? ¿Y puede el producto estándar hacerlo ya? Cuando el producto estándar no satisface esa necesidad, AL entra en escena. AL se enfoca en el propio Business Central leyendo, añadiendo y cambiando registros a nivel de base de datos mientras controla lo que sucede en páginas, informes y otras partes de la aplicación. Y calcula valores, mueve datos y muestra mensajes cuando las reglas fallan a los procesos. Es mucho trabajo para un solo lenguaje, pero AL no es una herramienta general para cualquier tipo de software y no lo elegiría para crear un sitio web de compras público, un juego móvil o una aplicación de escritor independiente.

AL existe para una tarea enfocada, dar forma a los datos y el comportamiento dentro de Business Central para que el sistema coincida con cómo opera una empresa. Y eso es exactamente lo que veremos a continuación. AL las extensiones, un modelo de complemento seguro. AL significa Application Language, lenguaje de aplicación. Es el lenguaje de programación de Microsoft para Business Central y brinda a los desarrolladores una forma estructurada de crear nuevas funciones comerciales o cambiar el comportamiento de partes existentes del sistema. Pero la palabra extensión es tan importante como AL. Una extensión es una aplicación independiente que Business Central puede instalar. Contiene el trabajo personalizado de la empresa, mientras la aplicación estándar de Business Central permanece intacta. Piense lo menos como reescribir un manual y más como añadirle páginas aprobadas. O páginas que siguen las reglas originales sin borrarlas.

Eso puede sonar como un detalle técnico, pero cambia cómo perdura el trabajo personalizado con el tiempo. Imaginé que una empresa necesita una nueva oficina para un equipo especial. El enfoque antiguo significaba romper una pared en el edificio principal y cambiar la estructura misma. Podría resolver la necesidad de hoy, pero las reparaciones futuras se vuelven una pesadilla porque el edificio original ya no coincide con sus planos. Una extensión funciona de forma diferente. El edificio ya tiene puertas, tomas de corriente y reglas para añadir espacio. Reconstruye la nueva habitación a través de esas conexiones aprobadas. La habitación pertenece a la empresa, pero el edificio principal aún puede recibir mantenimiento sin derribar cada pared personalizada. Así es exactamente como funcionan las extensiones de Business End. La aplicación base contiene el trabajo estándar que proporciona Microsoft.

Una extensión puede añadir sus propios campos, pantallas, botones, reglas, informes e incluso enlaces a otros sistemas. Puede reaccionar cuando ocurren ciertas secciones comerciales, pero lo hace a través de formas admitidas de conectarse a la aplicación estándar. Por lo tanto, el límite es tan interesante. Eso es algo bueno. Sin límites, una pequeña solicitud personalizada puede llegar profundamente a áreas que no debería tocar. Con las extensiones, el desarrollador trabaja con tipos de objetos claros y puntos de conexión definidos que facilitan la comprensión del código cuando alguien más necesite leerlo después. Este enfoque también se adapta perfectamente a la versión en la nube de Business Central. Microsoft actualiza el servicio regularmente. Una empresa aún necesita aprobar su extensión después de los cambios, especialmente si depende de partes del producto que han cambiado. El software nunca elimina la necesidad de mantenimiento.

Pero mantener el código personalizado o separado reduce la posibilidad de que cada actualización se convierta en una reconstrucción importante de modificaciones antiguas. Puede que escuche a personas mencionar CIMAR-AL cuando hablan de sistemas Dynamics nada más antiguos. CIMAR-AL provenía de un modelo de desarrollo anterior donde los desarrolladores a menudo cambiaban directamente los objetos originales de la aplicación. Muchas empresas ejecutaron sistemas exitosos de esa manera durante años, pero vinculaba el trabajo personalizado mucho más estrechamente al código estándar, y las actualizaciones requerían mucho trabajo de comparación y reparación. AL trasladó a Business Central hacia el desarrollo basado en aplicación. Eso no significa que cada extensión sea grande o complicada. Una extensión podría solo añadir un campo a un registro de cliente y mostrarlo en una pantalla familiar. Otra podría contener una solución completa para un tipo de negocio particular con sus propios registros, procesos, páginas e informes.

Ambas siguen la misma idea básica. La aplicación personalizada vive junto a Business Central en lugar de ocultar una reescritura de la misma. También puede instalar más de una extensión. Una empresa podría usar una extensión de un socio de software para nómina, otra para envíos y una pequeña extensión interna para reglas que solo le importan a esa empresa. Business Central la reúne en el mismo sistema de trabajo siempre que sigan las reglas de la plataforma y no entren en conflicto. Entonces, AL no es solo una forma de escribir code. Es el lenguaje que los desarrolladores usan para crear estas aplicaciones complementarias y las extensiones son el contenedor que lleva esos cambios a Business Central. Ese modelo permite a una empresa adaptar al sistema manteniendo el producto estándar reconocible más fácil de mantener. Ahora hablamos una de estas extensiones y observemos los componentes que contienen.

Los componentes principales de AL dentro de una extensión AL desarrolladores trabajan con objeto. Un objeto es una pieza nombrada de la aplicación con la función crack, como almacenar información, mostrar una pantalla, ejecutar una regla o producir un documento. Una vez creas esas funciones por separado, AL comienza a sentirse mucho menos como un muro de código. Comencemos por el lugar donde reside la información comercial. Las tablas almacenan datos en Business Central. Piensa en una tabla como un archivador digital para un tipo de registro. Un archivador puede contener clientes, otros artículos y otros órdenes de venta. Cada registro es un archivo dentro de ese archivador. Una tabla de clientes contiene un registro para cada cliente. Una tabla de artículos contiene un registro para cada producto. Si su empresa necesita información que Business Central estándar no almacena, una extensión puede crear su propia tabla, quizás para niveles de recompensa, inspecciones de equipos o aprobaciones de proyectos.

Los campos son los espacios etiquetados dentro de cada registro. Un registro de cliente puede incluir un nombre, una dirección, un plazo de pago y un número de teléfono, porque la tabla de clientes contiene campos para esos detalles. Los campos pueden contener texto, fechas, importes, respuestas de sí o no o una opción de una lista fija. Un campo también puede apuntar a otro registro. Por ejemplo, un cliente podría contener un campo de I de recompensa. En lugar de escribir cualquier texto al azar, el personal selecciona un nivel de recompensa de una tabla de recompensa separada. Ese vínculo mantiene los datos limpios porque todos eligen de la misma lista conocida los de las tablas contienen los hechos. ¿Pero cómo ven las personas a esos hechos y cómo trabajan con ellos? Páginas. Una página es la pantalla que abres en Business Central. La ficha de cliente es una página. Una lista de órdenes de venta es una página.

Una página controla lo que los usuarios pueden ver, ingresar, buscar y sobre lo que pueden actuar. Diferentes páginas se adaptan a diferentes trabajos. Una página de fichas se centra en un registro a la vez como un cliente o un artículo. Una página de lista muestra muchos registros en fila, lo que funciona bien cuando necesitas escanear, filtrar o encontrar algo rápidamente. Una página de hoja de trabajo admite tareas donde las personas ingresan o procesan varias líneas de información a la vez. La tabla almacena la información. La página la pone frente al usuario. Esa separación es útil porque puedes cambiar la pantalla sin cambiar dónde residen los datos o reutilizar la misma tabla en más de una página cuando diferentes equipos necesitan vistas distintas de los mismos registros. Ahora, ¿qué sucede si los datos ya pertenecen a un registro estándar de Business Central? Normalmente no se crea una tabla de clientes de reemplazo solo porque necesita un campo adicional.

Se utiliza una extensión de tabla. Una extensión de tabla añade su campo a la tabla de clientes existente. El registro de clientes estándar permanece donde debe estar, mientras que su extensión añade el detalle específico de la empresa junto a los campos estándar. Eso podría ser una idea de recompensa, una nota de entrega, un gestor de cuenta o un campo que conecte con otra parte del negocio. Pero añadir el campo a la tabla no lo pone automáticamente en la pantalla. Para eso se utiliza una extensión de página. Una extensión de página añade un campo, grupo o acción a una página existente. Si la empresa necesita que el personal elija un nivel de recompensa mientras visualiza un cliente, la extensión de página puede colocar el campo de idea de recompensa en la ficha de cliente, justo donde el personal ya trabaja. Eso mantiene la experiencia familiar. En lugar de enviar a los usuarios a una pantalla personalizada separada para un detalle simple de la extensión, añade el detalle a la página que ya conocen.

Una extensión de página también puede añadir acciones, un botón o comando de menú que inicie una tarea. Por ejemplo, una ficha de cliente podría incluir una acción de recompensas que abra la lista de recompensas. Detrás de la pantalla necesita un hogar para las reglas de negocio. Ese hogar suele ser una codeunit. Una codeunit contiene procedimientos AL, que son fragmentos de código con nombre que realizan un trabajo particular. Piensa en ello como el equipo de oficina que gestiona una tarea cuando una página, informe u otro proceso pide ayuda. Supongamos que el nivel de recompensa decide qué descuento se aplica a un cliente. El cálculo del descuento pertenece a una codeunit, no a la página de ficha de cliente en sí. Entonces, un proceso de ventas, un informe o una página futura pueden usar la misma regla sin copiarla en varios lugares. Una regla, un lugar para mantenerla. Business Central también incluye otros tipos de objetos para diferentes trabajos.

Los informes recopilan datos y los presentan en un documento o diseño como una factura o un informe de ventas. Las consultas realizan preguntas enfocadas en los datos, como qué clientes pidieron un determinado artículo durante un periodo. Por ejemplo, los XML reports ayudan a traer datos o enviarlos en un formato estructurado, a menudo cuando otro sistema necesite intercambiar información con Business Central. Ponga esas piezas juntas y podrá visualizar una pequeña extensión de recompensas para cliente. Una tabla de recompensas almacena cada nivel y su porcentaje de descuento. Las páginas de recompensa permiten al personal sus niveles. Una extensión de tabla de clientes añade un ID de recompensa a cada cliente, mientras que una extensión de página de ficha de cliente lo muestra. Una acción de página abre la lista de recompensas y la codeunit calcula la regla de descuento. Cada objeto maneja una parte de trabajo.

Eso hace que la extensión sea más fácil de leer, probar y cambiar cuando la regla de negocio cambie seis meses después. Pero una regla de negocio a menudo debe ejecutarse en el momento exacto, como cuando alguien registra un pedido. Ahí es donde entran los disparadores. Eventos disparadores y reglas de negocio. Se le hace añadir un campo de recompensa de cliente. Bien, esta es la verdadera pregunta. ¿Cuándo debería Business Central usar realmente ese campo? Imagina que estás a punto de registrar un pedido de venta. Antes de que el sistema crea los asientos finales, deseas una comprobación adicional. Quizás el cliente necesite un nivel de recompensa aprobado antes de que se aplique un descuento. O tal vez debe existir un documento de entrega requerido antes de que el pedido pueda avanzar. Quieres esa comprobación en el momento adecuado, pero no quieres copiar todo el proceso de registro de ventas en tu propia extensión solo para añadir una regla.

Ese proceso ya maneja mucho otras bambalinas. Si lo copias, tu extensión quedará atrapada manteniendo todos esos cambios futuros. No es ideal. Por eso AL ofrece a los desarrolladores varias formas de ejecutar código. Cual elijas depende de lo que necesite suceder. Primero, los disparadores. Un disparador es un punto con nombre dentro de un objeto AL donde se puede ejecutar código. Cuando alguien cambia un valor en un campo de tabla, el disparador ejecuta código. Cuando una página se abre o se cierra, el disparador ejecuta código. Informes, consultas, XML reports, tablas, extensiones, AO, todos tienen estos puntos donde un desarrollador puede añadir reglas. Tomemos el campo ID de recompensa en un cliente. Cuando un usuario elige un nivel de recompensa, se puede ejecutar un disparador de validación. El código comprueba ¿está bloqueado el cliente? ¿Existe el nivel de recompensa? ¿Necesita actualizarse otro campo?

La comprobación ocurre justo cuando el valor cambia, no después cuando alguien descubre un error. Los disparadores funcionan bien cuando la regla pertenece estrechamente a eso. Pero Business Central también utiliza evento. Un evento es como un aviso. Una parte de la aplicación lo envía cuando sucede algo. Podría anunciar que un registro está a punto de insertarse, que un documento está a punto de registrarse o que un proceso ha terminado. Tu extensión puede escuchar ese aviso. El código que escuchas se llama suscriptor de eventos, pero un evento nombrado específico. Cuando Business Central lanza ese evento, el suscriptor ejecuta su propio procedimiento. El proceso estándar sigue al mando. Por ejemplo, cuando Business Central comienza a registrar un pedido de venta, lanza un evento antes de continuar. Tu extensión de recompensas recibe ese aviso. Verifica la ley de recompensa y la regla de descuento de quien.

Luego permite que el proceso continúe o lo detiene con un mensaje claro. El proceso de registro estándar sigue perteneciendo a Business Central. Tu extensión solo añade su regla específica de empresa en ese punto de conexión. A menudo escucharás nombres de eventos como on before, on after. On before significa que tu código se ejecuta antes de que termine una acción. Es perfecto para una verificación que puede impedir el siguiente tiempo. O como detener un pedido de venta si una condición falla. After significa que la acción ya ocurrió. Voy a reaccionar. Crear un registro relacionado a actualizar una nota o iniciar otra tarea. Los nombres te indican el momento y el momento importa. Una regla que se ejecuta después del registro no puede evitar. Una regla que se ejecuta demasiado pronto puede no tener los datos necesarios. Por eso los desarrolladores eligen el evento según lo que la regla de negocio debe hacer y cuando.

El código también puede iniciarse a partir de una acción. Un usuario hace clic en un botón como

El código también puede ejecutarse cuando un objeto llama a otro a través de nombre. Suena técnico pero es sencillo. Una parte de la extensión le pide a otra que realice un trabajo. Las variables ayudan con eso. Una variable es un lugar con nombre que guarda un valor mientras se ejecuta el código. Puede ser un número o texto una fecha o incluso un registro de Business Central como cliente actual. En AL las declaras con var. Por ejemplo un procedimiento de recompensas podría usar una variable llamada cliente para guardar el registro del cliente actual. Otra variable llamada porcentaje de descuento guarda los valores descontados. Estos no son registros permanentes. Solo son valores de trabajo para esa parte del código. Esto es lo importante sobre dónde reside el código. Si una regla puede usarse desde más de un lugar ponla en una code unit. De esa forma la ficha del cliente o un proceso de ventas y un informe pueden llamar al mismo procedimiento de descuento en lugar de tener cada uno su versión.

Eso evita un problema conocido. Una pantalla aplica un 10% de descuento otra aplica un 5% y nadie sabe qué regla confiar. Mantener las reglas de negocio compartidas en una code unit le da a la extensión una única fuente para esa decisión. Entonces los disparadores manejan reglas cerca de un objeto. Los eventos permiten que una extensión reaccione a los propios procesos de Business Central. Las code units mantienen la lógica compartida unida. Una vez que esas piezas se conectan la siguiente pregunta es ¿dónde escriben, prueben e inspeccionan los desarrolladores todo este código AL? Desarrollo en AL suele ocurrir en Visual Studio Code a menudo llamado VS Code. Su espacio de trabajo para escribir archivos AL mantiene su extensión organizada. Le ayuda a encontrar problemas y enviar la aplicación terminada a un entorno de Business Central para realizar pruebas. Pero VS Code por sí solo es solo un editor de código general.

Necesita la extensión del lenguaje AL de Microsoft. Esa extensión le enseña a VS Code cómo funciona Business Central. Puede sugerir nombres de objetos mientras se escribe. Señala errores antes de que publique. Le ayuda a explorar campos y procedimientos. Y conecta su proyecto a un entorno de Business Central. Eso ahorra muchas conjeturas. Cuando inicie un nuevo proyecto AL puede ejecutar el comando ALGO dentro de VS Code. Crea la carpeta básica del proyecto y archivos de configuración para el nombre de la extensión, editor, versión y qué entorno de Business Central usar. Piensa en esa carpeta de proyecto como el banco de trabajo de extensión. Cada archivo AL pertenece a él. Un archivo puede contener una tabla, otro una extensión de página y una unidad de código puede tener su propio archivo. De esa manera cuando alguien abre el proyecto puede encontrar la parte correcta sin tener que desplazarse por un documento enorme.

Cuando el código esté listo para probarse VS Code lo compila en un paquete de aplicación. Esa es la versión instalable de la extensión. Business Central lee ese paquete y añade la extensión al entorno. Si falta un campo, hay un error de ortografía o cualquier problema que impida crear la aplicación, VS Code

Un sandbox es un entorno de Business Central separado donde puede probar cambios sin arriesgar el trabajo comercial real. Publica la extensión, abre las páginas modificadas, ingresa registros de prueba y ve si las reglas funcionan como se espera. Esa separación es importante. No querrá descubrir que una nueva regla de validación bloquea los pedidos de venta mientras el personal intente hacer su trabajo. En un sandbox puede cometer errores, eliminar datos de prueba, cambiar el código y volver a publicar sin afectar los registros reales. A veces el código se ejecuta pero el resultado aún parece incorrecto. Es ahí cuando la depuración ayuda. Coloca un punto de interrupción en el código, inicia el proceso y la extensión se pausa mientras se ejecuta. En esa pausa puede inspeccionar valores como el cliente actual, el nivel de recompensa seleccionado o el porcentaje de descuento que calculó el procedimiento.

En lugar de adivinar por qué falló una regla, puede ver exactamente qué recibió el código. Los equipos de desarrollo también usan Git para mantener la historia de su trabajo. Git registra los cambios en los archivos del proyecto a lo largo del tiempo. Si alguien cambia una regla e introduce un problema, el equipo puede comparar versiones, ver qué cambió y revertir si es necesario. Un desarrollador trabaja en la misma extensión. Para un principiante, el mejor camino es empezar poco a poco. Primero aprenda a moverse por Business Central, luego crea una tabla y una página. Después extienda una página estándar, añada una regla de negocio simple y aprenda cómo encajan los eventos y los datos de instalación en el proyecto. A continuación, conectemos esas piezas mediante un pequeño complemento que una empresa realmente podría usar. Un ejemplo sencillo, crear un complemento de recompensa para cliente.

¿Cómo es realmente una extensión a él real? Sumerjámonos en un ejemplo sencillo. Imagine que su empresa adquiere niveles de recompensa para clientes, cada uno con su propio descuento. Empiece creando una tabla de recompensa. Piense en ella como un archivador digital donde cada archivo contiene un ID, una descripción y un porcentaje de descuento. Oro obtiene un 10% de descuento. Su personal necesita gestionar esos niveles sin tocar herramientas técnicas. Siki añade dos páginas, una página de lista de recompensas para ver todos los niveles y una página de tarjeta de recompensa para editar o crear. Pueden añadir un nuevo nivel, ajustar un porcentaje o revisar lo que hay sin abrir ningún entorno de desarrollo. A continuación,

ese campo vincula a cada cliente con un registro de recompensa. Usted coloca ese campo directamente en la página de tarjeta de cliente donde el personal ya gestiona los detalles del cliente. Luego añade una acción de recompensas para que puedan abrir la lista de recompensas directamente desde esa misma tarjeta. La regla de descuento en sí reside dentro de una Code Unit. Cuando otro proceso necesita el descuento de un cliente, llama a esa Code Unit en lugar de calcularlo una y otra vez en cada página. Eso es eficiente. Una Code Unit de instalación añade niveles de recompensa iniciales la primera vez que se instala su este. Y un suscriptor de eventos verifica el nivel de recompensa elegido durante un proceso de ventas aplicando la regla de su empresa exactamente en el momento adecuado. Es una extensión pequeña pero observe lo que contiene. Tablas de datos, pantallas de usuario, acciones de navegación, lógica de configuración y reglas de negocio.

Todo trabajando en conjunto. Ese es el verdadero poder de AI. Inclusión, su punto de partida en el desarrollo AL. Entonces aquí está la conclusión. El desarrollo en AL le permite añadir las funciones específicas que su empresa necesita a Business Central sin tocar la aplicación principal. Y no tiene que construir todo de una vez. Empiece con un campo, una extensión de página y una regla clara. Ese es su primer bloque de construcción. Si este dato de conocimiento te resultó útil, suscríbete en tu plataforma de podcast favorita y compártelo con alguien que recién comienza en el desarrollo de Business Central. Acompáñanos la próxima vez donde añadiremos otra pieza más a romper. Soy Merco Peters y este ha sido otro episodio de Microsoft Knowledge Nuggets en M365FM.