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:

{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