Business Central: eventos vs. triggers em AL – um guia de tempo de execução para desenvolvedores

By Mirko Peters · 2026-08-22

Domine o desenvolvimento de AL no Business Central entendendo quando usar triggers ou assinantes de eventos para lógica de negócio personalizada, validações e verificações de lançamento.

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

Entender a diferença entre triggers e eventos no desenvolvimento de AL do Microsoft Dynamics 365 Business Central é essencial para escrever extensões limpas e fáceis de manter. Escolher o mecanismo de execução correto garante que suas regras de validação sejam executadas exatamente no momento certo, evitando entrada de dados incorretos e protegendo atualizações na nuvem tranquilas, sem duplicar o código do aplicativo base.

Principais conclusões

• Triggers ficam embutidos diretamente em objetos AL específicos para executar código imediatamente quando um evento do objeto ou uma modificação de dados ocorre.
• Assinantes de eventos permitem que sua extensão escute notificações do sistema sem modificar o código do aplicativo base ou copiar processos nativos extensos.
• Escolher entre eventos "on before" e "on after" determina se o seu código personalizado pode impedir uma transação ou apenas reagir a uma ação já concluída.
• O momento adequado garante que as regras de validação capturem erros cedo, evitando gargalos de desempenho durante operações pesadas, como o lançamento de pedidos de venda.

A arquitetura da lógica personalizada no Business Central

Ao estender o Dynamics 365 Business Central usando a Application Language (AL) da Microsoft, escrever o código é apenas metade do desafio. O verdadeiro desafio está em decidir onde e quando esse código deve ser executado. Seja ao adicionar um campo simples de nível de recompensa a um registro de cliente ou ao aplicar uma verificação de conformidade complexa antes que uma fatura seja gerada, a longevidade e a estabilidade da sua extensão dependem de como você se conecta ao sistema.

Os modelos de desenvolvimento mais antigos costumavam incentivar os desenvolvedores a reescrever diretamente o código nativo do aplicativo. Se você quisesse que uma verificação fosse executada antes de um documento ser lançado, injetava sua lógica diretamente na rotina de lançamento principal. Embora isso funcionasse por um tempo, cada grande atualização da Microsoft se transformava em um doloroso projeto de reconciliação. O desenvolvimento moderno de extensões do Business Central se baseia em um modelo modular, baseado em aplicativos. Em vez de reescrever rotinas padrão, os desenvolvedores usam pontos de conexão integrados, especificamente triggers e eventos, para incorporar lógica personalizada com segurança junto ao código padrão do aplicativo.

Desmistificando os triggers do AL

Um trigger é um local predefinido e designado dentro de um objeto AL onde você pode escrever código que é executado automaticamente quando uma ação específica acontece. Todos os objetos, padrão ou personalizados, incluindo tabelas, extensões de tabela, páginas, extensões de página, relatórios e codeunits, contêm esses pontos nativos.

Considere um cenário prático: sua organização introduziu um campo personalizado Reward ID no registro do cliente. Quando um usuário seleciona um nível de recompensa na lista suspensa, você precisa que o sistema verifique imediatamente se a conta do cliente está bloqueada ou se atributos secundários precisam ser atualizados. Ao utilizar o trigger OnValidate desse campo específico, seu código é disparado no exato instante em que o usuário faz uma alteração.

Quando usar triggers

Os triggers são mais indicados quando a sua lógica de negócio pertence exclusivamente a um único objeto e ao seu contexto imediato. Por exemplo:

• Validar se um campo de data personalizado está dentro de um trimestre comercial aceitável.
• Executar a lógica de inicialização quando uma página de cartão é aberta para um novo registro.
• Limpar os valores de campos dependentes quando uma opção principal é desmarcada.

Como os triggers ficam restritos aos seus objetos hospedeiros, o código localizado continua fácil de encontrar, ler e manter ao longo do tempo.

Aproveitando os eventos e as assinaturas do Business Central

Enquanto os triggers tratam ações localizadas, processos maiores com várias etapas, como a postagem de pedidos de venda, a expedição de estoque ou a geração de diários financeiros, exigem uma abordagem mais sofisticada. Você não pode simplesmente inserir seu código de validação no meio de uma rotina de postagem complexa sem quebrar o modelo de extensões.

É aqui que os eventos e os assinantes de eventos se tornam indispensáveis. Pense em um evento como uma notificação oficial emitida pelo próprio aplicativo padrão do Business Central. O sistema anuncia marcos importantes, como 'um registro está prestes a ser inserido' ou 'um documento de venda está prestes a ser postado.' Sua extensão pode ouvir esses avisos por meio de um procedimento assinante de evento.

Quando o Business Central dispara esse evento nomeado, o procedimento assinante é acionado, executa a sua regra personalizada e, então, libera o processo ou o interrompe com uma mensagem de erro descritiva. O ponto crucial é que sua extensão nunca precisa copiar, colar ou reescrever o mecanismo de postagem subjacente.

O poder do momento: OnBefore versus OnAfter

Ao criar assinantes de eventos em AL, as convenções de nomenclatura revelam o momento da execução. Entender esse momento é essencial para a confiabilidade do sistema:

• Eventos OnBefore: são executados logo antes de uma ação padrão ser concluída ou confirmada. Este é o local ideal para lógica de bloqueio e verificações de validação. Se um documento de conformidade obrigatório estiver ausente em um pedido de venda, um evento OnBefore de postagem pode identificar a omissão, cancelar a transação e exibir uma mensagem de aviso útil.
• Eventos OnAfter: são executados imediatamente após a conclusão bem-sucedida de um processo padrão. Use os assinantes OnAfter quando precisar reagir a uma ação já finalizada, como criar automaticamente uma tarefa de acompanhamento, atualizar uma tabela externa de logs ou notificar um gerente de contas assim que um pedido for totalmente postado.

Uma regra executada tarde demais não consegue impedir uma transação defeituosa, enquanto uma regra executada cedo demais pode não ter os dados necessários calculados pela rotina padrão. Associar sua lógica à assinatura de evento correta elimina essas armadilhas.

Conclusão

Dominar o equilíbrio entre os triggers de objetos e os assinantes de eventos muda a forma como você desenvolve extensões do Business Central. Ao usar triggers localizados para validações de campos e assinantes de eventos para processos em todo o sistema, você garante que suas personalizações continuem resilientes às atualizações da nuvem, mantendo o ambiente rápido e seguro.

Para se aprofundar nos princípios de design de aplicações modernas e ouvir análises de arquitetura feitas por especialistas, ouça o episódio completo do M365 FM Podcast. Sintonize para descobrir como arquitetos de nuvem e desenvolvedores otimizam o ecossistema Microsoft para o sucesso real dos negócios!

Perguntas frequentes

Qual é a principal diferença entre um trigger e um assinante de evento em AL?

Um trigger é um ponto de execução de código predefinido, criado diretamente dentro de um objeto AL específico (como um campo de tabela ou uma página), enquanto um assinante de evento é um procedimento separado na sua extensão que escuta as notificações publicadas pelo aplicativo base ou por outros objetos, sem alterar o código original.

Um assinante de evento pode impedir que um pedido de venda seja postado?

Sim. Se você usar um assinante de evento 'on before' vinculado ao processo de postagem, seu código personalizado pode avaliar as condições de negócio, exibir uma mensagem de erro e interromper a transação antes que a rotina de postagem finalize os lançamentos.

Quando devo usar um trigger de validação de campo de tabela em vez de um assinante de evento?

Você deve usar um trigger de validação de campo de tabela quando sua regra de negócio estiver estritamente ligada à alteração do valor daquele campo específico, como verificar se um Reward ID personalizado existe ou garantir que um campo de status relacionado seja atualizado imediatamente após a entrada do usuário.

Por que o momento da execução é crítico ao escrever assinantes de eventos em AL?

O momento de execução determina se o seu código roda antes ou depois de um processo principal ser concluído. Se a sua regra rodar cedo demais, os dados necessários talvez ainda não estejam preenchidos; se rodar tarde demais, você perde a capacidade de bloquear transações inválidas.