Visão geral rápida do Dynamics AX 2012 SysOperation Framework

Publicado: 15 de fevereiro de 2025 às 22:35:36 UTC

Este artigo fornece uma visão geral rápida (ou folha de dicas) sobre como implementar classes de processamento e trabalhos em batch na estrutura SysOperation no Dynamics AX 2012 e no Dynamics 365 for Operations.

Esta página foi traduzida automaticamente do inglês para a tornar acessível ao maior número possível de pessoas. Infelizmente, a tradução automática ainda não é uma tecnologia aperfeiçoada, pelo que podem ocorrer erros. Se preferir, pode ver a versão original em inglês aqui:

Dynamics AX 2012 SysOperation Framework Quick Overview

As informações neste post são baseadas no Dynamics AX 2012 R3. Pode ou não ser válido para outras versões. (Atualização: Posso confirmar que a informação neste artigo também é válida para o Dynamics 365 for Operations)

Este post serve apenas como uma rápida visão geral e uma folha de dicas. Se é novo no framework SysOperation, recomendo vivamente que leia também o white paper da Microsoft sobre o assunto. As informações aqui podem ser úteis se apenas necessitar de uma rápida atualização sobre as diferentes classes envolvidas no desenvolvimento de operações com esta estrutura.

Existem variações, mas quando utilizo o framework normalmente implemento três classes:

Contrato de dados (deve estender SysOperationDataContractBase)
Serviço (deve estender SysOperationServiceBase)
Controller ( deve estender SysOperationServiceController)

Além disso, também posso implementar uma classe UIBuilder ( deve estender SysOperationUIBuilder), mas isso só é necessário se, por algum motivo, o diálogo tiver de ser mais avançado do que aquele que a framework gera automaticamente.

Contrato de dados

O contrato de dados contém os membros de dados necessários para o seu funcionamento. Pode ser comparada à macro típica CurrentList definida na estrutura RunBase, mas implementada como uma classe. O contrato de dados deve estender SysOperationDataContractBase, mas funcionará mesmo que isso não aconteça. A vantagem de estender a superclasse é que fornece algumas informações de sessão que podem ser úteis.

[DataContractAttribute]
class MyDataContract extends SysOperationDataContractBase
{
    ItemId itemId;
}

Neste exemplo, o itemId é um membro de dados. É necessário implementar um método parm para cada membro de dados e marcá-lo com o DataMemberAttribute para que a framework saiba o que é. Isto permite que o framework crie automaticamente o diálogo por si.

[DataMemberAttribute]
public ItemId parmItemId(ItemId _itemId = itemId)
{
    ;

    itemId = _itemId;
    return itemId;
}

Serviço

A classe de serviço é a classe que contém a lógica de negócio real. Não se preocupa em mostrar diálogos, processamento em batch ou qualquer coisa do género – isso é da responsabilidade da classe controladora. Ao separar isto, tem mais hipóteses de projetar bem o seu código e torná-lo mais reutilizável.

Tal como a classe de contrato de dados, a classe de serviço não precisa de herdar de nada em particular, mas deve herdar da classe SysOperationServiceBase, pelo menos se espera que o serviço seja executado como um trabalho em lote, uma vez que a superclasse fornece algumas informações sobre o contexto do lote. O método que inicia a operação (ou seja, executa a lógica de negócio) deve receber um objeto da sua classe de contrato de dados como entrada e deve ser decorado com o [SysEntryPointAttribute]. Por exemplo:

class MyService extends SysOperationServiceBase
{
}

com um método chamado run:

[SysEntryPointAttribute]
public void run(MyDataContract _dataContract)
{
    // run business logic here
}

Controlador

A classe do controlador trata da execução e do processamento em lote da sua operação. Também garante que o código é executado em CIL para o máximo desempenho. A classe do controlador herda normalmente da classe SysOperationServiceController, embora também existam outras opções.

class MyController extends SysOperationServiceController
{
}

O construtor da superclasse recebe como parâmetros um nome de classe, um nome de método e (opcionalmente) um modo de execução. Os nomes das classes e dos métodos devem ser o nome da sua classe de serviço e o método que deve ser executado na mesma. Assim, pode implementar o método de construção do seu controlador assim:

public static MyController construct()
{
    ;

    return new MyController(classStr(MyService),
    methodStr(MyService, run));
}

Assim o método principal da classe MyController pode ser tão simples como

public static void main(Args _args)
{
    ;

    MyController::construct().startOperation();
}

E basicamente está pronto. O exemplo acima é obviamente muito simples e a estrutura contém uma infinidade de outras opções e possibilidades, mas isto serve como uma rápida visão geral caso necessite de uma atualização após algum tempo sem utilizar a estrutura.