Extensiones AL en Business Central: qué son y cómo se hacen bien

En Navision, personalizar significaba modificar el código de Microsoft. Funcionaba, pero cada actualización obligaba a revisar a mano todas esas modificaciones, y por eso tantas empresas se quedaban años en la misma versión.

En Business Central eso ya no se hace (en online, directamente no se puede). Todo lo que añades va en una extensión: un paquete aparte que se engancha al estándar sin tocarlo. Es la diferencia entre actualizar con miedo y actualizar dos veces al año sin que nadie se entere.

Qué es una extensión

Una extensión es un proyecto en AL (el lenguaje de Business Central) que se compila en un fichero .app. Dentro puede haber:

Objetos nuevos: tablas, páginas, codeunits (lógica), informes, consultas, enums, APIs...
Extensiones de objetos estándar: tableextension para añadir campos a una tabla de Microsoft, pageextension para mostrarlos en sus pantallas, reportextension para ampliar sus informes.
Suscriptores de eventos: código que se ejecuta cuando el estándar "avisa" de que algo pasa.
Conjuntos de permisos para que cada usuario vea solo lo que debe.

Las extensiones a medida usan el rango de identificadores 50.000 a 99.999. Se instalan, actualizan y desinstalan por separado del estándar.

Cómo se engancha al estándar: un ejemplo

Un caso típico: cada cliente tiene unas instrucciones de entrega y quieres que pasen solas a sus pedidos. Primero, el campo en el cliente y en la cabecera de venta:

tableextension 50100 "CM Customer" extends Customer
{
    fields
    {
        field(50100; "CM Delivery Instructions"; Text[250])
        {
            Caption = 'Instrucciones de entrega';
            DataClassification = CustomerContent;
        }
    }
}

tableextension 50101 "CM Sales Header" extends "Sales Header"
{
    fields
    {
        field(50100; "CM Delivery Instructions"; Text[250])
        {
            Caption = 'Instrucciones de entrega';
            DataClassification = CustomerContent;
        }
    }
}

Después, mostrarlo en la ficha del cliente (y del mismo modo en el pedido):

pageextension 50100 "CM Customer Card" extends "Customer Card"
{
    layout
    {
        addlast(Shipping)
        {
            field("CM Delivery Instructions"; Rec."CM Delivery Instructions")
            {
                ApplicationArea = All;
                ToolTip = 'Instrucciones que se copian a los pedidos de este cliente.';
            }
        }
    }
}

Y por último, la lógica. En lugar de modificar el código que rellena el pedido, nos suscribimos al evento que se dispara cuando se elige el cliente:

codeunit 50100 "CM Sales Subscribers"
{
    [EventSubscriber(ObjectType::Table, Database::"Sales Header", 'OnAfterValidateEvent', 'Sell-to Customer No.', false, false)]
    local procedure CopyDeliveryInstructions(var Rec: Record "Sales Header"; var xRec: Record "Sales Header"; CurrFieldNo: Integer)
    var
        Customer: Record Customer;
    begin
        if not Customer.Get(Rec."Sell-to Customer No.") then
            exit;
        Rec."CM Delivery Instructions" := Customer."CM Delivery Instructions";
    end;
}

Cuatro objetos, cero líneas de Microsoft modificadas. Cuando llegue la siguiente versión, el estándar se actualiza por debajo y la extensión sigue enganchada al mismo evento.

Un detalle: el prefijo CM en nombres y campos. Evita choques con otras extensiones que añadan un campo con el mismo nombre a la misma tabla, y es una buena práctica que conviene seguir desde el primer objeto. En las apps que se publican en el marketplace de Microsoft, además, es obligatorio: el prefijo se registra y tiene al menos tres caracteres.

Extensión a medida o app de AppSource

Hay dos tipos de extensión:

PTE (per-tenant extension): se hace para una empresa concreta y solo se instala en su Business Central. Es lo que se usa para adaptar el ERP a un proceso propio.
App de AppSource: un producto publicado en el marketplace de Microsoft (AppSource, hoy integrado en Microsoft Marketplace), que pasa su validación técnica y cualquiera puede instalar.

Antes de desarrollar una PTE, merece la pena buscar en AppSource: si ya hay una app que resuelve el caso (conectores de bancos, de transportistas, EDI, captura de documentos...), suele salir más a cuenta. Muchas veces la solución es mixta: una app de AppSource y una extensión pequeña que la adapta a tu forma de trabajar.

Lo que hace que una extensión sobreviva a las actualizaciones

Microsoft publica dos versiones mayores al año (en primavera y en otoño) y actualizaciones menores cada mes. Que una extensión las aguante sin problemas no es suerte:

Usa eventos y procedimientos públicos, no copias del código estándar. Si copias una función de Microsoft para cambiarle una línea, te quedas con una versión que ya no se actualiza.
Atiende a los avisos de obsoleto. Antes de retirar algo, Microsoft lo marca como ObsoleteState = Pending y lo mantiene así alrededor de un año. El compilador te avisa: esas advertencias son tareas pendientes, no ruido.
Prueba en un sandbox con la versión preview. Microsoft publica la siguiente versión mayor en preview antes de lanzarla. Compilar y probar ahí la extensión te dice con margen si algo va a romperse.
Ten tests automatizados de los procesos críticos. AL tiene codeunits de test (Subtype = Test) que puedes ejecutar en cada compilación.
Control de versiones y compilación automática. El código en Git y un pipeline que compila y prueba cada cambio. Microsoft mantiene plantillas para esto (AL-Go for GitHub).

Cómo se publica

En Business Central online, las extensiones a medida se instalan desde el Business Central Admin Center (o su API), donde además puedes programar cuándo se actualizan. Desde la versión 28, subirlas desde la página Administración de extensiones dentro del propio Business Central se está retirando: en 2027 dejará de estar disponible para eso.

En on-premises, se publican con las herramientas de administración del servidor (PowerShell).

En los dos casos, el camino es el mismo: primero al sandbox, se prueba, y después a producción.

Resumen

En Business Central no se modifica el estándar: se extiende.
Una extensión bien hecha usa eventos, prefijos propios y el rango de identificadores reservado.
Antes de programar, busca en AppSource.
La compatibilidad con las actualizaciones se trabaja: avisos de obsoleto, sandbox con preview y tests.

Si tienes un proceso que el estándar no cubre o una personalización de Navision que hay que pasar a extensión, te cuento cómo trabajo el desarrollo de extensiones.