Mais upgrade!

Com o lançamento do Ax 2009 no Brasil muitos desenvolvedores terão que trabalhar no upgrade das customizações feitas para seus clientes no Ax 4.0 para a 5.0. Deixo aqui a dica para verem o ultimo post no blog Palle Agermark on AX, principlamente se vocês planejam mudar aquele desenvolvimento feito para o cliente x na camada cus para a camada var, por exemplo, para reutilizar em outros clientes.



Abs

Smart customizations pt. 2

Toda implantação de um ERP exige algum nivel de customização para o cliente: seja um novo processo um modificação de um processo existente ou um novo relatório, os desenvolvedores devem seguir alguns principios no desenvolimento de suas customizações para fazer isso de uma maneira mais eficaz, tanto na manutenção, quanto no upgrade, aqui vão algumas dicas:

1. Mantanha a lógica do negócio e logica de interface separados - isto significa: não escreva lógica relacionada a funcionalidade que esta criando em forms, utilizar o máximo possível classes.


2. Quando for utilizar tabelas, trabalhe com um registro por vez em table instance methods (custInvoiceJour.initFromSalesTable por exemplo), enquanto table static methods devem cuidar de um grupo de registros.


3. Sempre tente utilizar field groups nos formulários. eles são automaticamente atualizados nos formulários quando um novo campo é inserido.


4. Classes: lógicas que envolvam diferentes tabelas como processos de atualização (faturamento ou um cálculo de comissão) devem estar escritos em classes. Tente utilizar o princípio de "Single Responsibility (SRP)" em suas classes, esse principio diz que uma classe deve ser implementada tendo apenas um único e exclusivo objetivo, portanto não faça das suas novas classes um canivete suiço.
   
5. Evite overlaying em suas classes e tabelas: caso você modifique um método que ja exista em uma camada abaixo da que esta trabalhando e depois acabe desistindo dessa modificação não esqueça de remover a modificação da camada que esta trabalhando, caso o método permaneça em uma camada acima mesmo sem nenhuma alteração, caso ele seja alterado em sua camada original, seja por uma nova versão ou fix, o Ax não vai executar essa nova alteração. O overlaying também pode acontecer quando se imposta um XPO, portanto, verifique sempre se os metodos alterados realmente contém alterações!

Um bom lugar para iniciar o estudo sobre desenvolvimento no Ax é a página do MSDN do Dynamics Ax, ele é aberto ao publico e e tem informações que vão desde a arquitetura do Ax, cutomizações basicas e desenvolvimento em X++.

Vale a pena dar uma revisada no meu post sobre upgrade.

Até a próxima.

Smart customizations Ax

Seguindo meu post sobre upgrade de versão, segue um link de um webcast feito por Michael Fruergaard, arquiteto do time de Ax da microsoft, que explica como customizar o Ax de uma maneira a simplicficar futuros upgrades.
Com o lançamento do Ax 2009, é muito importante todos os desenvolvedores de Ax pensarem também como lidar com o upgrade das customizaçòes feitas para seus clientes.

Dynamics AX 4.0 - Smart customizations

Rodrigo

Upgrade de codigo

Tenho visto muitas duvidas em relação a upgrade de versão ou mesmo de service pack para o Ax no forum do Ax no MSDN Brasil. Provavelmente este ano clientes e parceiros terão mais um upgrade que será no lançamento da versão 2009, sem contar o service pack 3 para a versão 4.0.

Então, como se preparar para a atualização de código?

A primeira tarefa é entender como funciona a tecnologia de camadas do Ax.

{imagem 01}

As camadas são uma hierarquia de niveis no código fonte da aplicação para garantir que mudanças e adições possam ser feitas sem interfirir em elementos da aplicação em um nível abaixo da camada em que se esta fazendo a alteração.

Cada camada é gravada em um arquivo separado chamado Ax.aod, por exemplo Axgls.aod para a camada GLS, onde nossa localização foi desenvolvida.

Ainda exista as camadas de patch, elas são chamadas de SYP, GLP, DIP e assim por diante, elas são utilizadas por exemplo no release de service packs. A ideia basica é que quando uma pequena correção ou atualização é feita, ela deva ser distribuida em uma camada de patch, sem modificar a aplicação existente.

Conteúdo das camadas e overlaying

Os elementos da aplicação podem variar em tamanho, enquanto forms e relatórios contém grande quantidade de código, campos, grupo de campos, class methods, table methods contém menor quantidade de código.


Customizando esses elementos em uma camada limpa, por exemplo a VAR, o Ax copia o elemento da camada abaixo para camada que você esta customizando, sobrepondo seu conteúdo original, o compilador passa a executar o elemento modificado e não mas o elemento original. Na figura, os objetos modificados são representados por quadrados verde um pouco mais escuro.





{imagem 02}

Durante o upgrade de versão (ou service pack) conflitos podem occorer quando:

• Você customizou um elemento E a Microsoft também alterou o elemento original.

{imagem 03}

Na figura acima, podemos ver que uma série de objetos foram modificados por uma nova versão (ou service pack), quadrados que eram verdes e passaram a laranja são aqueles que sofreram alterações. Aqueles em que a alteração da Microsoft tenha coincidido com a alteração feita para o cliente devem ser atualizados.

Não há uma ferramenta mágica para que o codigo seja atualizado, quanto mais automaticamente, para a nova versão. Porém o Ax compara individualmente os seguintes elementos:

• EDTs
• Base Enums
• Table fields
• Table field groups
• Table methods
• Class methods
• Forms
• Reports

Percebam que a granularidade aplicada a table fields, table methods e class methods (que são elementos menores de elementos principais como Table e Class) não se aplica a Forms e Reports, que tem uma granularidade é bem maior, isso significa que uma minima alteração em forms ou reports faz com que o elemento inteiro seja copiado da camada inferior para a sua camada, dificultando em muito a atualização do código.

Para resolver os conflitos de atualização de código, um projeto de atualização deve ser criado. Ele pode ser acessado a partir de: Ferramentas\Ferramentas de Desenvolvimento\Atualização de versão\Criar projeto de atualização

Abaixo a seguinte lógica é aplicada quando executamos o processo de criação do projeto de atualização (Upgrade Project).

Apenas elementos em que tenha havido conflito vão ser inseridos no projeto de atualização, o trabalho a ser feito agora é comparar elemento a elemento e trazer para sua camada a atualização feita tanto pelo service pack quanto pela nova versão.

Para isso o Ax tem a ferramenta de comparação, em que é possivel, em muitos casos trazer (ou remover) a modificação da camada inferior para a sua camada de trabalho apenas clicando em flechas que indicam que o codigo deva ser inserido, removido ou realojado dentro do método.

Nos proximos posts eu devo voltar a configuração e utilização dos impostos retidos e trazer algumas dicas na fase de programação da solução para o cliente para tentar minimizar o code upgrade em novas versões.

Links uteis:
Upgrade Methodology (em ingles) - não deixe de conferir e seguir TODO o processo de upgrade descrito Implementation Guide.

Forum do MSDN Brasil para o Dynamics AX