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

Publicado: 15 de fevereiro de 2025 às 22:35:35 UTC
Última atualização: 12 de janeiro de 2026 às 08:38:59 UTC

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

Esta página foi traduzida automaticamente do inglês para torná-la acessível ao maior número possível de pessoas. Infelizmente, a tradução automática ainda não é uma tecnologia aperfeiçoada, portanto, podem ocorrer erros. Se preferir, você pode visualizar 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. Elas podem ou não ser válidas para outras versões. (Atualização: Posso confirmar que as informações neste artigo também são válidas para o Dynamics 365 for Operations.)

Este post serve apenas como uma visão geral rápida e um guia de consulta rápida. Se você é novo no framework SysOperation, recomendo fortemente que leia também o white paper da Microsoft sobre o assunto. As informações aqui podem ser úteis se você precisar apenas de uma revisão rápida das diferentes classes envolvidas no desenvolvimento de operações com este framework.

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

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

Além disso, também posso implementar uma classe UIBuilder (que deve estender SysOperationUIBuilder), mas isso só é necessário se, por algum motivo, a caixa de diálogo precisar ser mais complexa do que aquela gerada automaticamente pelo framework.

Contrato de dados

O contrato de dados contém os membros de dados necessários para sua operação. Ele pode ser comparado à macro CurrentList típica definida no framework RunBase, mas implementada como uma classe. O contrato de dados deve estender SysOperationDataContractBase, mas funcionará mesmo que não o faça. A vantagem de estender a superclasse é que ela 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. Você precisa implementar um método parm para cada membro de dados e marcá-lo com o atributo DataMemberAttribute para que o framework saiba do que se trata. Isso permite que o framework construa automaticamente o diálogo para você.

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

    itemId = _itemId;
    return itemId;
}

Serviço

Classe de serviço é a classe que contém a lógica de negócios propriamente dita. Ela não se preocupa com a exibição de diálogos, processamento em lote ou qualquer coisa do tipo — essa é a responsabilidade da classe controladora. Ao separar essas duas responsabilidades, você tem mais chances de projetar seu código de forma eficiente e criar um código mais reutilizável.

Assim como a classe de contrato de dados, a classe de serviço não precisa herdar de nenhuma classe em particular, mas deve herdar da classe `SysOperationServiceBase`, pelo menos se você espera que o serviço seja executado como um job em lote, já 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ócios) deve receber um objeto da sua classe de contrato de dados como entrada e deve ser decorado com o atributo `[SysEntryPointAttribute]`. Por exemplo:

class MyService extends SysOperationServiceBase
{
}

Com um método chamado executar:

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

Controlador

Classe controladora gerencia a execução e o processamento em lote da sua operação. Ela também garante que o código seja executado em CIL para obter o máximo desempenho. A classe controladora normalmente herda da classe SysOperationServiceController, embora existam outras opções também.

class MyController extends SysOperationServiceController
{
}

O construtor da superclasse recebe como parâmetros o nome da classe, o nome do método e (opcionalmente) o modo de execução. Os nomes da classe e do método devem ser o nome da sua classe de serviço e o método que deve ser executado nela. Portanto, você pode implementar o método construtor do seu controlador da seguinte forma:

public static MyController construct()
{
    ;

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

Então, o método principal da classe MyController pode ser tão simples quanto

public static void main(Args _args)
{
    ;

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

E basicamente você terminou. O exemplo acima é obviamente muito simples e a estrutura contém uma infinidade de outras opções e possibilidades, mas serve como uma visão geral rápida caso você precise relembrar alguns conceitos básicos depois de um tempo sem usar a estrutura.

Leitura adicional

Se você gostou deste post, você também pode gostar destas sugestões: