Olá a todos! Meu nome é Tanya, sou o líder da equipe de desenvolvimento de Axapta em Lamoda. Este artigo discutirá o desenvolvimento do nosso primeiro projeto na plataforma Microsoft Dynamics 365 For Finance and Operations.

imagem

Vou falar sobre as abordagens que usamos, sobre os erros que foram cometidos, vou compartilhar meu conhecimento e ganhar experiência. Este artigo pode ser de interesse para quem começa a desenvolver um projeto no D365 ou apenas pensa sobre ele.

Esta é uma transcrição gratuita do relatório da reunião do Mycrosoft Dynamics 365 & Power Platform.

Objetivo do projeto e princípios técnicos

Nossa subsidiária alemã compra mercadorias e as vende para uma entidade legal russa. Anteriormente, usamos o sistema Tsenit, que nos permitia manter registros apenas no nível dos dados financeiros, mas não conseguia lidar com as tarefas de mercadorias e logística. Para resolver esses problemas, tínhamos ferramentas adicionais. Os dados foram armazenados em vários bancos de dados de uma só vez. Tudo isso afetou negativamente a velocidade e a confiabilidade de todo o sistema.

Queríamos que o sistema de contabilidade ajudasse a filial alemã a enviar relatórios, pagar impostos e passar nas auditorias. O ERP passado dificilmente resolveu esses problemas, por isso decidimos desenvolver e lançar nosso próprio sistema contábil. Nosso ERP deveria combinar finanças, contabilidade e logística de agências em um único circuito. Como software principal, escolhemos o Microsoft Dynamics 365 - o antigo Dynamics AX, também conhecido como Axapta.

O componente de negócios é descrito no artigo "Tecnologia, Terceirização e Mentalidade" . Aqui falaremos sobre implementação técnica. Portanto, precisávamos automatizar vários processos de negócios:

Compra de mercadorias de fornecedores;
Venda a uma entidade legal russa;
Integração entre D365 e Ax2012, o sistema contábil de uma entidade legal russa;
;
.

No projeto, decidimos implementar a solução em nuvem Microsoft Dynamics 365, uma vez que o escritório alemão não tinha a infraestrutura de TI para implantar o aplicativo, nem as pessoas que seriam responsáveis por ele. Para pequenas filiais remotas, o esquema SaaS é ideal, pois permite obter todos os ambientes de software e desenvolvimento necessários para iniciar a implementação, imediatamente após a assinatura do contrato com o provedor.

Tínhamos prazos apertados: era necessário concluir todo o desenvolvimento em 3 meses. Como no antigo sistema a contabilidade de mercadorias era realizada em planilhas, transferir todo o conjunto de dados históricos seria uma tarefa impossível no meio de um ano fiscal. Porém, no início do período coberto pelo relatório, basta transferir apenas saldos. Portanto, era necessário lançar 1 de janeiro de 2019 ou adiá-lo por mais um ano.

Nossa equipe não tinha experiência em desenvolvimento na D365. Apesar de todas as circunstâncias, planejamos iniciar esse projeto o mais rápido possível. A seguir, descreverei separadamente todas as etapas do desenvolvimento. Vou me aprofundar em cada iteração em detalhes: que experiência obtivemos e que erros cometemos.

Primeira iteração, modificações no aplicativo versão 7.3

Para começar a trabalhar rapidamente, primeiro desenvolvemos uma arquitetura de aplicativo simples. Consistia em ambientes de desenvolvimento - ambientes DevBox de 1 camada. Todos os componentes foram instalados em um servidor / máquina virtual: Application Object Server (AOS), banco de dados, Dynamics 365 Retail e Management Reporter.

Para o teste, decidimos usar o ambiente SAT - ambiente de duas camadas do Standard Acceptance Test.

O ambiente de duas camadas é um ambiente com várias caixas, cujos componentes são instalados em vários serviços em nuvem e geralmente incluem mais de um Application Object Server (AOS). Na verdade, é o mais próximo possível de um ambiente produtivo, por isso decidimos testá-lo.

Implantamos os primeiros ambientes de desenvolvimento na infraestrutura existente no local, mas sua capacidade não foi suficiente para o desenvolvimento do projeto. Portanto, quando mais dois desenvolvedores se juntaram ao projeto, implantamos o DevBox de maneira rápida e elegante na nuvem.

Nossos ambientes de nuvem foram gerenciados através do portal de serviços do Ciclo de vida.

Tendo terminado com os ambientes, a equipe começou a se desenvolver. Configuramos o ambiente de desenvolvimento no Visual Studio e os conectamos ao controle de versão do Azure DevOps, tendo criado anteriormente uma ramificação para baixar o código. Em seguida, desenvolvemos uma abordagem para o desenvolvimento e transferência de mudanças para o ambiente SAT.

Não há camadas na arquitetura do D365; todo o código padrão foi definido no modelo. As modificações foram transferidas para o ambiente SAT através do portal LCS com um pacote contendo um modelo compilado.

– , – , .

Para começar, implementamos a modificação mais simples e comum - adicionando um novo campo à tabela padrão, inicializando-o ao criar o registro e enviando para o formulário padrão.

imagem

Mesmo em um projeto tão simples, existem novos tipos de objetos. Fizemos uma extensão para adicionar novos campos à tabela padrão. Para trazer o campo para o formulário padrão, criamos um novo tipo de objeto - uma extensão para o formulário. E para inicializar o campo, criamos uma classe que estende os métodos da tabela. Ele permitiu inicializar o campo ao criar o registro.

imagem

Em uma modificação tão simples, vimos um dos princípios básicos do D365 - não uma mudança, mas uma extensão de objetos padrão.

A próxima modificação foi a criação de um novo formulário. Agora, ao criar um formulário, era necessário especificar seu padrão.Um padrão é um padrão que define completamente a estrutura de design de um formulário. Até que reproduzamos completamente a estrutura estabelecida no modelo, nosso formulário não será compilado. É impossível alterar o modelo do formulário finalizado. Portanto, antes de iniciar o desenvolvimento, pensamos antecipadamente em como seria a nossa forma.

imagem

Também mantivemos a capacidade de gerenciar o design do formulário. Se indicássemos padrão - Personalizado, seríamos totalmente responsáveis pelo design do formulário: quais objetos estavam nele e com que aninhamento.

imagem

Conclusões após a primeira iteração

1. Não altere o padrão, apenas expanda-o.

2. Consulte o modelo se usarmos seus objetos em outro modelo. Essa é uma das diferenças entre os modelos do D365 de versões anteriores: um objeto existe em apenas um modelo.

3. Existem limitações na alteração das propriedades de objetos padrão. Nem todas as propriedades dos campos padrão podem ser alteradas em suas extensões de objetos padrão. Por exemplo, a extensão da tabela PurchTable é o campo LineDisc. Podemos controlar a visibilidade do campo e do rótulo, e propriedades como obrigatórias e editáveis não podem ser alteradas.

imagem

4. Não há trabalhos no D365, tudo é feito através das aulas.

5. Vencemos os modelos muito finamente, e acabou que nosso princípio de “uma modificação = um modelo” não funciona.

Segunda iteração e transição para um modelo

No início da segunda iteração, tínhamos dois modelos que se referiam um ao outro. Por esse motivo, não foi mais possível transferir essas modificações de forma independente. Portanto, decidimos trabalhar em um novo modelo, no qual era necessário transferir todas as modificações existentes.

Um modelo no D365 é uma coleção de arquivos de origem localizados em um diretório separado. Ao compilar, eles são coletados em uma biblioteca separada que possui um link com outras bibliotecas.

Portanto, a fusão em um modelo no DevBox se resumiu a transferir arquivos de um diretório para outro e excluir diretórios antigos.

Então, construímos um novo modelo, obtivemos sua versão mais recente em cada DevBox e continuamos a trabalhar na estrutura de um modelo em ambientes de desenvolvimento.

Naturalmente, já transferimos alguns modelos para teste no ambiente SAT. Portanto, foi necessário removê-los e liberar um novo.

Todas as atualizações no ambiente SAT foram feitas usando pacotes, incluindo a remoção de modelos. Criamos um pacote com modelos vazios que precisam ser removidos e adicionamos um script com os nomes desses modelos. Em seguida, coletamos um pacote com um novo modelo e o lançamos no ambiente SAT. Assim, a SAT ganhou um novo modelo.

Quando os modelos foram combinados, percebemos que cada desenvolvedor nomeia as extensões de objetos à sua maneira. Concordamos com as regras para nomear objetos de acordo com o modelo: PurchTable.LamodaModelFormExtension, PurchTableTypeLamodaModelClass_Extension .

Também concordamos na equipe que, para um objeto padrão, criamos apenas uma extensão e fazemos alterações em tudo.

Selecionei algumas modificações interessantes que fizemos nesta fase. Eles mostram possíveis abordagens de desenvolvimento no D365.

Tarefa 1

No lançamento da fatura do pedido de venda, foi necessário substituir o número da fatura pelo número do pedido. Para isso, definimos uma classe padrão com a possibilidade de extensão, o que nos permitiu realizar essa modificação.

imagem

Fizemos uma extensão para a classe SalesInvoiceJourCreate padrão. Existe Next em seu método getNumAndVoucher () - este é o nosso novo super, ele fala sobre chamar o código do método padrão. Após chamar o código padrão, substituímos o número da fatura pelo valor desejado.

Essa é uma das nossas abordagens de desenvolvimento: usar extensões e adicionar nosso próprio código antes ou depois (como uma opção - antes e depois) da execução do código padrão.

Tarefa 2

Foi necessário alterar a exibição dos totais do pedido: agrupar os totais pelo número da fatura do fornecedor nas linhas do pedido. Nesse caso, não encontramos um local para expansão sem reduzir pela metade o desempenho, por isso criamos nossa própria versão dos resultados sem tocar nos padrões.

imagem

Tarefa 3
Outra modificação interessante: nas linhas do formulário do pedido, foi necessário adicionar campos da lista de itens com a capacidade de filtrar. Nas versões anteriores, a modificação era completamente desinteressante e era resolvida simplesmente adicionando uma tabela como fonte de dados ao formulário e sobrepondo os dois métodos.

Na versão 7.3, não foi possível estender os métodos para uma fonte de dados de formulário padrão. Para filtrar e não criar um novo formulário para isso, adicionamos o modo de exibição como fonte de dados ao formulário.

A capacidade de estender métodos para a fonte de dados apareceu na versão 8.1 do D365.

imagem

Conclusões após a segunda iteração

Nesta fase, desenvolvemos as modificações básicas necessárias para iniciar o projeto.

Introduzimos as regras para nomear extensões. Eles não apenas ajudaram a tornar os nomes consistentes e compreensíveis, mas simplificaram ainda mais a atualização, pois nossos nomes não coincidiam com os nomes dos objetos padrão do service pack.
Fiquei satisfeito com a rapidez com que a referência cruzada ocorre ao criar um projeto ou modelo - ele é muito convenientemente organizado nesta versão.
A atualização de modelos em diferentes tipos de ambientes ocorre de maneiras diferentes. Estávamos convencidos disso em um exemplo de fusão de modelos.
Antes de iniciar o desenvolvimento de uma nova modificação, é necessário obter a versão mais recente do modelo, pois o desenvolvimento é realizado na estrutura de um modelo.
O mecanismo da entidade de dados para carregar e descarregar dados no Excel ao atualizar dados no produto mostrou-se muito conveniente. Nosso departamento de dados e análise agora está usando-o para recuperar dados do nosso D365 baseado em nuvem.

Fizemos o desenvolvimento principal no prazo. Go Live saiu, o modelo está em prod. E enfrentamos o problema de liberar apenas modificações testadas dentro do modelo. Também queríamos facilitar o processo de depuração durante o teste de modificações e acelerar a atualização do ambiente de teste.

Como funciona agora

Na última iteração, adicionamos dois ambientes: construir e testar. Depois que todos os ambientes foram configurados e verificados, simplificamos os testes e aprendemos a liberar apenas modificações testadas no modelo.

Para o teste, implantamos um ambiente de uma camada e o conectamos à ramificação de desenvolvimento no sistema de controle de versão. A atualização agora consistia em obter a versão mais recente do modelo e de sua montagem. Nesse ambiente, estreamos, como no DevBox usual.

imagem

Pacotes de compilação para liberação agora executados em um novo ambiente de compilação. As modificações testadas foram transferidas para uma nova ramificação no sistema de controle de versão por conjuntos de alterações (pacotes de alterações carregados no sistema de controle de versão), em um princípio do mais antigo ao mais recente.

Em seguida, implantamos o pacote no ambiente SAT, onde foram realizados os testes do usuário, após o que agendamos o pacote no portal LCS para lançamento no produto. Então, configuramos o processo de liberação usando o ambiente de compilação.

E decidimos não revisar os projetos, mas os conjuntos de alterações para modificação, enviados para o controle de versão.

A primeira atualização de versão na nuvem

Como trabalhamos na versão em nuvem, precisávamos ser atualizados regularmente. A primeira atualização foi uma transição da versão 7.3 para a versão 8.0. Demorou cerca de duas semanas.

Obviamente, criamos os principais problemas para nós mesmos, mas também vencemos:

Não concordamos imediatamente com as regras para nomear objetos padrão. Na primeira atualização, nossos nomes de objetos coincidiram com os nomes dos objetos no service pack.
Ao atualizar ambientes em nuvem, necessariamente efetuamos logoff em máquinas AOS; caso contrário, o processo de atualização não pode ser concluído com um usuário conectado.
O pacote de atualização para os ambientes prod e SAT precisava ser combinado com o pacote do modelo.

Hoje, a atualização de todos os nossos ambientes leva cerca de 3-4 dias e ocorre sem o envolvimento dos desenvolvedores. Podemos até lançar um lançamento ao mesmo tempo que a atualização, o principal é que a build, SAT e prod tenham a mesma versão.

O processo de atualização consiste no download do pacote de atualização no portal lcs. O DevBox e o teste são atualizados primeiro, depois a compilação é atualizada, os últimos são SAT e prod.

Resultados de todo o primeiro projeto

Adquirimos experiência na construção da arquitetura de aplicativos do D365.
Desenvolveu uma nova abordagem para revisão de código.
Criamos as regras para a transferência de bancos de dados para o DevBox (no D365 é importante realizar testes iniciais no DevBox, e agora estamos testando desenvolvedores no DevBox).
Escreveu diretrizes de desenvolvimento na D365.
Aprendeu a desenvolver na nuvem.

Toda essa experiência nos ajudou a desenvolver o projeto com mais atenção. Agora que conhecemos os recursos do sistema, podemos construir a arquitetura mais corretamente, ou melhor, definir tarefas. Os processos integrados ao redor do projeto facilitam bastante a conexão de desenvolvedores que estão escrevendo pela primeira vez no D365.

Desenvolvimento do primeiro projeto na plataforma do Microsoft Dynamics 365 For Finance and Operations