Guidelines para uso de eventos no AX 2012

Se você responder sim a pelo menos uma dessas perguntas, então é melhor passar a event handlers nas suas customizações o quanto antes!

  • Você está tendo dificuldade em instalar hotfixe após hotfix, CU após CU?
  • Será que a migração do código consome mais tempo do que você desejava inicialmente?
  • As customizações estão feitas de tal forma que cada atualização requer merges cada vez mais complicados, de tal forma que o desenvolvedor fica perdido tentando descobrir qual o código vai para onde?

Se utilizado corretamente, event handlers tem o potencial de reduzir muito o tempo gasto em upgrades de código.

Caso você nunca tenha ouvido falar, existe um white paper que explica o uso de delegates e event handlers aqui e no MSDN aqui.

Contudo, a ideia é simples: ao minimizar o código em objetos de core (ou sys), você pode fazer o processo de upgrade de código de maneira muito mais fácil por que toda a lógica de negócios esta agrupada em novos métodos em novos objetos ou métodos no próprio objecto que necessita de customização e não causa ‘overlayering’ nos métodos originais.

Para minimizar o impacto das customizações a ideia é a seguinte: Uma determinada customização me obriga a alterar o método updateOrderBalances da classe TradeTotals, ao invés de entrar no método e fazer as mudanças necessárias, eu adiciono um POST event handler ao método updateOrderBalances que chama o método estático postUpdateOrderBalancesHandler_BR na mesma classe.

event handler on trade totals

Por uma decisão de implementação, eu quis colocar minha customização em um método private na mesma classe (postUpdateOrderBalancesBR), separando assim a real lógica de negócio da chamada do event handler.

image

Event handlers podem ser usados em:

  • Métodos de classe
  • Métodos estáticos de classe
  • Métodos de tabelas
  • Métodos estáticos de tabela

Event handlers em classes

Adicionar 2 métodos na mesma classe: O event handler é chamado pelo infraestrutura e tem uma chamada para o segundo método, chamado pre/post method que contei a regra de negócio, esse método deve ser private.

Quando o método original retornar algum valor, o pre/post method deve por padrão deve retornar o valor original.

Prós:

  • Clara separação de infraestrutura e regra de negócio
  • Acesso a variáveis de classe
  • Event handler pode ser gerados automaticamente por um editor script

Convenção de nome para event handler: <”pre” | “post”><method name>EventHandler

Convenção de nome para pre/post method: <”pre” | “post”><method name>

Event handlers em tabelas

Adicionar uma nova classe que será utilizada para chamar o event handler, e então seguir os guidelines para classes.

Convenção de nome para classe: <associated table name>EventHandler

Quando usar?

Não é sempre que podemos usar event handlers, veja as dicas a seguir:

Não candidatos:

  • Código dentro de loops
  • Código que usa ou muda variáveis do método

Candidatos:

  • Código adicionado no começo do método
  • Código adicionado no fim do método

Fortes candidatos:

  • ModifiedField
  • ValidateField
  • Métodos InitFrom*

Deve ser usado com cautela:

  • Código adicionados dentro de clausulas IF, você pode copiar o if para dentro do pre/post method
  • Códigos entre ttsBegin/ttsCommit quando o método é publico
  • Métodos Display – pode haver uma queda de performance na UI