Bem-vindos a mais um episódio do Microsoft Knowledge Nugget. Eu sou seu apresentador, Mirio Peter. Então, aqui está o cenário. Você está trabalhando no Business Center e precisa de uma pequena mudança. Talvez um campo extra, um registro de cliente, uma etapa de aprovação diferente, ou uma regra que verifica um pedido antes de alguém publicá-lo. Então, alguém menciona extensões, AL, tabelas, páginas e code units, e, de repente, esse pequeno pedido soa como um idioma totalmente novo. É um idioma, claro, mas não precisa parecer misterioso. Pense no Business Center como um prédio comercial. O AL dá aos desenvolvedores as instruções para adicionar uma sala, um formulário ou uma nova regra sem precisar quebrar paredes do prédio. Esse é o nosso Knowledge Nugget de hoje. Ao final deste episódio, você saberá o que significa o desenvolvimento em AL e por que as extensões existem, e como o trabalho personalizado se encaixa no Business Center.

Por que as empresas personalizam o Business Center? O Business Center já lida com muitas tarefas diárias de finanças, clientes, pedidos de venda e faturas de estoque, tudo em um sistema conectado em vez de uma pilha de planilhas e ferramentas separadas. Para muitas empresas, essa configuração padrão cobre a maior parte do trabalho. Mas aqui está a questão. Nenhuma empresa trabalha da mesma maneira. Veja um distribuidor de alimentos que precisa de detalhes de lote que a outra empresa nunca usa, uma empresa de serviços que exige um processo de aprovação especial antes do faturamento, um varejista que deseja níveis de recompensa para descontos, e outra pessoa precisando de um formulário com seus próprios campos de texto e regras internas. A empresa não mudará seus métodos por causa de um campo ausente. E você também não quer que cada pequeno pedido se transforme em uma mudança arriscada em todo o sistema.

Isso costumava ser um problema. Em sistemas mais antigos, os desenvolvedores abriam o código original e o editavam diretamente. E funcionava até a chegada da próxima atualização. Então, a empresa tinha a nova versão da Microsoft de um lado, suas próprias mudanças do outro, e alguém precisava reconciliar tudo antes que a atualização pudesse prosseguir. Imagine um escritor onde cada inquilino passa novos cabos pelas paredes sem um plano. Funciona por um tempo, mas quando o prédio precisa de reparos, ninguém sabe qual cabo pertence a quem. Business Central segue um caminho diferente. Em vez de reescrever o aplicativo padrão, os desenvolvedores criam um complemento separado que se conecta a ele, mantendo a parte padrão no lugar, enquanto as mudanças da empresa ficam ao lado e operam por meio de pontos suportados no sistema. Essa separação é importante quando as atualizações chegam, porque a Microsoft atualiza sua parte do prédio enquanto o trabalho personalizado permanece em seu próprio espaço.

Ainda há testes e correções, afinal são mudanças de software, mas não se espera que o desenvolvedor copie e refaça cada alteração dentro do código original da Microsoft. Então, o que uma empresa realmente personaliza? As personalizações adicionam nada. O sistema padrão não armazena itens como instruções de entrega, pontuação de risco interna, nível de associação ou links para sistemas externos. E elas adicionam telas que guiam a equipe para uma tarefa na ordem correta. Elas também impõem regras, como interromper um pedido quando um documento obrigatório está faltando. Trabalho personalizado também ajuda as pessoas a evitarem etapas manual. Imagine a equipe copiando dados de clientes do Business Central para outra ferramenta toda sexta-feira, verificando condições manualmente, enviando um relatório ao gerente. Uma mudança bem feita mantém essas informações no Business Central, aplica a regra de forma consistente e oferece à equipe um botão ou página que se ajusta ao trabalho diário.

Vamos esclarecer um mito. Você não deve personalizar tudo. O Business Central padrão já possui muitos processos integrados. Mudar algo só porque parece diferente, e um sistema antigo cria trabalho extra mais tarde, tanto um bom trabalho personalizado começa com uma razão de negócio. Qual problema as pessoas estão enfrentando? O que deveria acontecer em vez disso? E o produto padrão já consegue fazer isso? Quando o produto padrão não atende a essa necessidade, o AL entra em cena. O AL foca no próprio Business Central, lendo, adicionando e alterando registros no nível do banco de dados, enquanto controla o que acontece em páginas, relatórios e outras partes do aplicativo. E ele calcula valores, move dados, e exibe mensagens quando as regras falham durante os processos. É muito trabalho para uma única linguagem, mas o AL não é uma ferramenta geral para qualquer tipo de software, e você não escolheria para criar um site público de compras, um jogo móvel ou um aplicativo desktop independente.

O AL existe para uma tarefa focada, moldar os dados e o comportamento dentro do Business Central para que o sistema corresponda à forma como a empresa opera. E é exatamente isso que viremos a seguir. AL Extensões, o modelo de complemento seguro. AL significa aplicação language, linguagem de aplicação. É a linguagem de programação da Microsoft para o Business Central, que oferece aos desenvolvedores uma forma estruturada de criar novas funções de negócio ou alterar o comportamento de partes existentes do sistema. Mas a palavra extensão é tão importante quanto o AL. Uma extensão é um aplicativo separado que o Business Central pode instalar. Ela contém o trabalho personalizado da empresa, enquanto o aplicativo padrão do Business Central permanece intocado. Pense nisso menos como reescrever o manual e mais como adicionar páginas aprovadas a ele. Páginas que seguem as regras originais sem apagá-las.

Isso pode parecer um detalhe técnico, mas muda a forma como o trabalho personalizado se mantém ao longo do tempo. Imagine que uma empresa precise de uma nova sala de escritório para uma equipe especial. A abordagem antiga significava derrubar uma parede no prédio principal e alterar a estrutura em si. Pode resolver a necessidade de hoje. Mas repara os futuros se tornam um pesadelo, porque o edifício original já não corresponde à planta. Uma extensão funciona de forma diferente. O edifício já possui portas, pontos de energia e regras para adição de espaço. Você constrói um novo cômodo através dessas conexões aprovadas. O cômodo pertence à empresa, mas o edifício principal ainda pode receber manutenção sem precisar derrubar todas as paredes personalizadas. É exatamente assim que as extensões do Business Central funcionam. O aplicativo base contém o trabalho padrão fornecido pela Microsoft.

Uma extensão pode adicionar seus próprios campos, telas, botões, regras, relatórios e até links para outros sistemas. Ela pode reagir quando certas ações de negócio ocorrem, mas faz isso por meio de formas suportadas de conexão ao aplicativo padrão. Tantos limites são integrados. Isso é algo bom. Sem limite, uma pequena solicitação personalizada pode atingir áreas que não deveria tocar. Com extensões, o desenvolvedor trabalha com tipos de objetos claros e pontos de conexão definidos, o que torna o código mais fácil de entender quando outra pessoa precisar lê-lo depois. Essa abordagem também se encaixa perfeitamente na versão em nuvem do Business Central. A Microsoft atualiza o serviço regularmente. Uma empresa ainda precisa testar sua extensão após as alterações, especialmente se a depender de partes do produto que foram modificadas. O software nunca elimina a necessidade de cuidados. Mas manter o código personalizado separado diminui a chance de que cada atualização se transforme em uma grande reconstrução de modificações antigas.

Você pode ouvir pessoas mencionarem CL ao falarem sobre os sistemas Dynamics Neve mais antigos. O CL veio de um modelo de desenvolvimento anterior, onde os desenvolvedores costumavam alterar os objetos originais do aplicativo diretamente. Muitas empresas mantiveram sistemas bem-sucedidos dessa forma por anos, mas isso vinculava o trabalho personalizado muito mais estreitamente ao código padrão e as atualizações exigiam muito trabalho de comparação e reparo. O IL moveu o Business Central para um desenvolvimento baseado em aplicativos. Isso não significa que toda extensão seja grande ou complicada. Uma extensão pode apenas adicionar um campo a um registro de cliente e exibi-lo em uma tela familiar. Outra pode conter uma solução completa para um tipo de negócio específico com seus próprios registros, processos, páginas e relatórios. Ambas seguem a mesma ideia básica. O aplicativo personalizado vive ao lado do Business Central em vez de esconder uma reescrita dele.

Você também pode instalar mais de uma extensão. Uma empresa pode usar uma extensão de um parceiro de software para folha de pagamento, outra para envio, uma pequena extensão interna para regras que importam apenas para aquela empresa. O Business Central as reúne em sistema operacional desde que sigam as regras da plataforma e não entrem em conflito. Tanto a IL não é apenas uma maneira de escrever código. É a linguagem que os desenvolvedores usam para criar esses aplicativos complementares e as extensões são o container que leva essas mudanças para o Business Central. Esse modelo permite que uma empresa personalize o sistema mantendo o produto padrão reconhecível mais fácil de manter. Agora vamos abrir uma dessas extensões e examinar os blocos de construção. Principais blocos de construção AL dentro de uma extensão AL os desenvolvedores trabalham com objetos. Um objeto é uma parte nomeada do aplicativo com uma função clara, como armazenar informações, exibir uma tela, executar uma regra ou produzir um documento.

Quando você vê essas funções separadamente, o AL parece muito menos uma parede de código. Vamos começar pelo local onde as informações comerciais residem. As tabelas armazenam o Business Central. Pense em uma tabela como um arquivo digital para um tipo de registro. Um arquivo pode conter clientes, outro contém itens e outro contém pedidos de venda. Cada registro é um arquivo dentro desse gabinete. Uma tabela de clientes contém um registro para cada cliente. Uma tabela de itens contém um registro para cada produto. Se sua empresa precisa de informações que o Business Central padrão não armazena, uma extensão pode criar sua própria tabela, talvez para níveis de recompensa, inspeções de equipamentos ou aprovações de projetos. Campos são os espaços rotulados dentro de cada registro. Um registro de cliente pode incluir um nome, um endereço, um termo de pagamento e um número de telefone, porque a tabela de clientes contém campos para esses detalhes.

Os campos podem conter texto, datas, valores, respostas sim ou não, ou uma escolha de uma lista fixa. Um campo também pode apontar para outro registro. Por exemplo, um cliente poderia conter um campo de ID e recompensa. Em vez de digitar qualquer texto aleatório, a equipe seleciona o nível de recompensa de uma tabela de recompensa separada. Esse link mantém os dados limpos porque todos escolhem a partir da mesma lista conhecida. Tanto as tabelas contêm os fatos. Mas como as pessoas veem e trabalham com esses fatos? Páginas. Uma página é a tela que você abre no Business Center. O cadastro de cliente é uma página. Uma lista de pedidos de venda é uma página. Uma página controla o que os usuários podem visualizar, inserir, pesquisar e processar. Páginas diferentes atendem a tarefas diferentes. Uma página de cartão foca em um registro por vez, como um cliente ou um item. Uma página de lista mostra muitos registros em linhas, o que funciona bem quando você precisa escanear, filtrar ou encontrar algo rapidamente.

Uma página de planilha oferece suporte ao trabalho em que as pessoas inserem ou processam várias linhas de informações juntas. A tabela armazena as informações. A página te coloca à disposição do usuário. Essa separação é útil porque você pode alterar a tela sem alterar onde os dados residem ou reutilizar a mesma tabela em mais de uma página quando equipes diferentes precisam de visões diferentes dos mesmos registros. Agora, e se os dados já pertencerem a um registro padrão do Business Central? Geralmente, você não cria uma tabela de clientes substituta só porque precisa de um campo extra. Você usa uma extensão de tabela. Uma extensão de tabela adiciona seu campo à tabela de clientes existente. O registro padrão do cliente permanece onde deveria, enquanto sua extensão adiciona o detalhe específico da empresa ao lado dos campos padrão. Um ID de recompensa, uma nota de entrega, um gerente de conta ou um campo que se conecta à outra parte do negócio.

Mas adicionar o campo à tabela não o coloca automaticamente na tela. Para isso, eu uso uma extensão de página. Uma extensão de página adiciona um campo, grupo ou ação a uma página existente. Se a empresa precisa que a equipe escolha um nível de recompensa ao visualizar um cliente, a extensão de página pode colocar o campo de ID de recompensa no cartão do cliente exatamente onde a equipe já trabalha. Isso mantém a experiência familiar. Em vez de enviar os usuários para uma tela personalizada separada por um detalhe simples, a extensão adiciona o detalhe à página que eles já conhecem. Uma extensão de página também pode adicionar ações, um botão ou comando de menu que inicia uma tarefa. Por exemplo, um cartão de cliente poderia incluir uma ação de recompensas que abre a lista de recompensas. Por trás da tela, você precisa de um lugar para as regras de negócio. Esse lugar costuma ser um codinit.

Uma codinit contém procedimentos aérea, que são partes de código nomeadas que realizam uma tarefa específica. Pense nisso com uma equipe de back-office que lida com uma tarefa quando uma página, relatório ou outro processo pede ajuda. Suponha que o nível de recompensa decida qual desconto se aplica um cliente. O cálculo do desconto pertence a uma codinit, não a página do cartão do cliente em si. Assim, um processo de vendas, um relatório ou uma página futura podem usar a mesma regra sem copiá-la em vários lugares. Uma regra é um lugar para mantê-la. O Business Central também inclui outros tipos de objetos para diferentes tarefas. Relatórios coletam dados e os apresentam em um documento ou layout, como uma fatura ou um relatório de vendas. Consultas Queries fazem perguntas focadas nos dados, como quais clientes solicitaram um determinado item durante o período. Por exemplo, os XML ports ajudam a trazer dados ou enviá-los em um formato estruturado frequentemente quando outro sistema precisa trocar informações com o Business Central.

Junte essas peças e você poderá imaginar uma pequena extensão de recompensas para o cliente. Uma tabela de recompensas armazena cada nível e sua porcentagem de conta. Páginas de recompensas permitem que a equipe gêne esses níveis. Uma extensão de tabela de clientes adiciona um ID de recompensa a cada cliente, enquanto uma extensão de página de cartão de cliente o exibe. Uma ação de página abre a lista de recompensas e a Codionit calcula a regra de desconto. Cada objeto lida com uma parte do trabalho. Torna a extensão mais fácil de ler, testar e alterar quando a regra de negócio mudar seis meses depois. Mas uma regra de negócio geralmente precisa ser executada no momento exato, como quando alguém lança um pedido. É aí que entram os gatilhos e eventos. Eventos, gatilhos e regras de negócio. Então você adiciona um campo de recompensa ao cliente. Ótimo. Aqui está a pergunta real. Quando o Business Central deve realmente usar esse campo?

Imagine que você está prestes a lançar um pedido de venda. Antes que o sistema crie os lançamentos finais, você quer uma verificação extra. Talvez o cliente precise de um nível de recompensa aprovado antes que um desconto seja aplicado. Ou talvez um documento de entrega obrigatório precise existir antes que o pedido possa prosseguir. Você quer essa verificação no momento certo, mas não quer copiar todo o processo de lançamento de vendas para a sua própria extensão apenas para adicionar uma regra. Esse processo já lida com muita coisa nos bastidores. Se você copiá-lo, sua extensão ficará presa mantendo todas essas futuras alterações. Nada ideal. Portanto, o AL oferece aos desenvolvedores algumas maneiras de executar como. A opção que você escolher depende do que precisa acontecer. Primeiro, os gatilhos. Um gatilho é um ponto nomeado dentro de um objeto AL onde o código pode ser executado.

Quando alguém altera um valor em um campo de tabela, o gatilho dispara o código. Quando uma página abre ou fecha, o gatilho dispara o código. Relatórios, consultas, XML ports, tabelas, extensões e objetos de aplicação. Todos têm esses pontos onde um desenvolvedor pode adicionar regra. Pegue o campo de ID e recompensa um cliente. Quando um usuário escolhe o nível de recompensa, um gatilho de validação pode ser executado. O código verifica. O cliente está bloqueado. O nível de recompensa existe. Outro campo precisa de uma atualização. A verificação acontece exatamente quando o valor muda, não depois, quando alguém descobre um erro. Gatilhos funcionam bem quando a regra pertence estritamente a esse objeto. Mas o Business Center também usa eventos. Um evento é com um aviso. Uma parte da aplicação envia esse aviso quando algo acontece. Ele pode anunciar que um registro está prestes a ser inserido, ou que um documento está prestes a ser lançado, ou que um processo terminou.

Sua extensão pode ouvir esse aviso. O código que houve é chamado de assinante evento evento subscriber. Ele espera por um evento nomeado específico. Quando o Business Center aciona esse evento, o assinante executa seu próprio procedimento. O processo padrão permanece no comando. Por exemplo, quando o Business Center começa a lançar um pedido de venda, ele aciona um evento antes de continuar. Sua extensão de recompensas recebe esse aviso. Ela verifica o ID de recompensa e a regra de desconto do cliente. Então, ela permite que o processo continue ou interrompe com uma mensagem clara. O processo de lançamento padrão ainda pertence ao Business Center. Sua extensão apenas adiciona a regra específica da empresa nesse ponto de conexão. Você ouvirá frequentemente nomes de eventos, como on before ou on after. On before significa que seu código é executado antes de uma ação terminar. Isso é perfeito para uma verificação que pode impedir a próxima etapa.

Como parar um pedido de venda se uma condição falhar. After significa que a ação já ocorreu. Você pode reagir, criar um registro relacionado, atualizar uma nota ou iniciar outro trabalho. Os nomes indicam o momento, e o momento é importante. Uma regra executada após o lançamento não pode impedir. Uma regra executada muito cedo pode não ter os dados que precisa. Portanto, os desenvolvedores escolhem um evento com base no que a regra de negócio deve fazer com ela. O código também pode ser iniciado a partir de uma ação. Um usuário clica em um botão como Verificar status de recompensa e essa ação chama um procedimento. O código também pode ser executado quando um objeto chama outro por meio de uma variável. Isso parece técnico, mas é simples. Uma parte da extensão pede a outra para realizar uma tarefa. As variáveis ajudam com ela. Uma variável é um local nomeado que mantém um valor enquanto o código é executado.

Pode ser um número, texto, uma data ou até um registro do Business Central como cliente atual. Em AL você os declara com VAR. Por exemplo, um procedimento de recompensa pode usar uma variável chamada cliente para manter o registro do cliente atual. Outra variável chamada percentual de desconto mantém os valores com desconto. Esses não são registros permanentes. São apenas valores de trabalho para aquela parte do código. Aqui está a questão sobre onde o código reside. Se uma regra puder ser usada em mais de um lugar, coloque uma codinit. Dessa forma, o cartão de cliente, um processo de vendas e um relatório podem chamar o mesmo procedimento de desconto em vez de cada um ter sua própria versão. Isso evita um problema comum. Uma tela aplica 10% de desconto, outra aplica 5% e ninguém sabe em qual regra confiar. Manter regras de negócios compartilhadas em uma única codinit dá à extensão uma única fonte para essa decisão.

Portanto, os gatilhos lidam com regras próximas a um objetivo. Eventos permitem que uma extensão reaja aos próprios processos do Business Central. O Code Units mantém a lógica compartilhada reunida. Uma vez que essas partes se conectam, a próxima pergunta é onde os desenvolvedores escrevem, testam e inspecionam todo esse código AL. Onde o desenvolvimento AL acontece, o desenvolvimento AL geralmente ocorre no Visual Studio Code, também conhecido como VS Code. É o seu espaço de trabalho para escrever arquivos AL. Ele mantém sua extensão organizada. Ajuda a encontrar problemas. Envia o aplicativo finalizado para o ambiente do Business Central para teste. Mas o VS Code por si só é apenas um editor de código geral. Ele precisa da extensão de linguagem AL da Microsoft. Essa extensão ensina ao VS Code como o Business Central funciona. Ela pode sugerir nomes de objetos conforme você digita. Ela aponta erros antes de você publicar.

Ela ajuda você a navegar por campos e procedimentos. Conecta seu projeto ao ambiente do Business Central. Isso economiza muito trabalho de vença. Ao iniciar um novo projeto AL, você pode executar o comando ALGO dentro do VS Code. Ele cria a pasta básica do projeto e os arquivos de configuração com o nome da extensão, editor, versão e qual ambiente do Business Central usar. Usar. Pense nessa pasta de projeto com a bancada de trabalho da extensão. Cada arquivo AL pertencer. Um arquivo pode contar uma tabela, outro uma extensão de página. Um Codenit pode ter seu próprio arquivo. Quando alguém abre o projeto, pode encontrar a parte certa sem enrolar um documento enorme. Quando o código está pronto para teste, o VS Code compila em um pacote de aplicativo. Essa é a versão instalável da extensão. O Business Central lê esse pacote e adiciona a extensão ao ambiente. Se houver um campo faltando, um erro de digitação ou qualquer problema que impeça a criação do aplicativo, o VS Code avisa antes que o pacote chegue ao Business Central.

Os testes devem ocorrer primeiro. Um ambiente... Um sandbox é um ambiente separado do Business Central, onde você pode testar alterações sem arriscar o trabalho real da empresa. Você publica a extensão, abre as páginas, faz alterações, insere registro de teste e vê se as regras funcionam como esperado. Essa separação é importante. Você não quer descobrir que uma nova regra de validação bloqueia pedidos de venda enquanto a equipe tenta realizar seu trabalho. Em um sandbox, você pode cometer erros, remover dados de teste, alterar o código e publicar novamente sem afetar os registros reais. Às vezes o código é executado, mas o resultado ainda parece incorreto. É aí que a depuração ajuda. Você coloca um ponto de interrupção no código, inicia o processo e a extensão pausa durante a execução. Nessa pausa, você pode inspecionar valores como o cliente atual, o nível de recompensa selecionado ou a porcentagem de desconto que o procedimento calculou.

Em vez de adivinhar por que uma regra falhou, você pode ver exatamente o que o código recebeu. Para em desenvolvimento, também usa o Git para manter o histórico do seu trabalho. O Git registra as alterações nos arquivos do projeto ao longo do tempo. Se alguém alterar uma regra e causar um problema, a equipe pode comparar versões, ver o que mudou e reverter, se necessário. Isso também ajuda quando mais de um desenvolvedor trabalha na mesma extensão. Para um iniciante, o melhor caminho é começar pequeno. Aprenda a navegar no Business Central primeiro, depois crie uma tabela e uma página. Depois disso, estenda uma página padrão, adicione uma regra de negócio simples e aprenda como eventos e dados de instalação se encaixam no projeto. Em seguida, vamos conectar essas peças por meio de um pequeno complemento que uma empresa realmente poderia usar. Um exemplo simples, criar um complemento de recompensas para o cliente.

Como é uma extensão AL real, vamos mergulhar em um exemplo simples. Imagine que sua empresa queira níveis de recompensa para clientes, cada um com seu próprio desconto. Você começa criando uma tabela de recompensa. Pense nela como um arquivo digital, onde cada pasta contém um ID, uma descrição e um percentual de desconto. O nível ouro recebe 10% de desconto. Sua equipe precisa gerenciar esses níveis sem tocar em ferramentas técnicas. Então, se adiciona em duas páginas, uma página de lista de recompensas para ver todos os níveis e uma página de cartão de recompensa para editar o que não. Eles podem adicionar um novo nível, ajustar um percentual ou revisar o que existe sem abrir em nenhum ambiente de desenvolvimento. A seguir, você estende a tabela de clientes com um novo campo chamado Recompensa. Esse campo vincula cada cliente a um registro de recompensa. E você coloca esse campo diretamente na página do cartão do cliente, onde a equipe já gerencia os detalhes do cliente.

Então, você adiciona uma ação de recompensas para que eles possam abrir a lista de recompensas diretamente nesse mesmo cartão. A regra de desconto em si vive dentro de uma code unit. Quando outro processo precisa do desconto de um cliente, ele chama essa code unit em vez de calculá-lo repetidamente em cada página. Isso é oficiente. Uma code unit de instalação adiciona níveis de recompensa iniciais na primeira vez que sua extensão instala. E um assinante de evento verifica o nível de recompensa escolhido durante um processo de vendas, aplicando a regra da sua empresa no momento exato. Essa é uma pequena extensão, mas observe o que ela contém. Tabelas de dados, telas de usuário, ações de navegação, lógica de configuração e regras de negócio. Tudo trabalhando junto. Esse é o verdadeiro poder da AER. Conclusão, seu ponto de partida no desenvolvimento em AER. Então, aqui está a levar em conta.

O desenvolvimento em AER permite que você adicione ao Business Central os recursos específicos de que sua empresa precisa sem tocar no aplicativo principal. E você não precisa construir tudo de uma vez. Comece com um campo, uma extensão de página e uma regra clara. Esse é o seu primeiro bloco de construção. Se você achou esta pílula de conhecimento útil, inscreva-se na sua plataforma de podcast favorita e compartilhe com alguém que está começando no desenvolvimento do Business Central. Junte-se a nós na próxima vez, onde adicionaremos mais uma peça. Eu sou Marco Peters, e este foi mais um episódio de Pílulas de Conhecimento Microsoft no M305FM.