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

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

Este artigo fornece uma visão geral rápida (ou folha de dica) sobre como implementar classes de processamento e trabalhos em lote no framework SysOperation em Dynamics AX 2012 e 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

A informação neste artigo baseia-se no Dynamics AX 2012 R3. Pode ou não ser válida para outras versões. (Atualização: Posso confirmar que a informação deste artigo também é válida para o Dynamics 365 for Operations)

Esta publicação serve apenas como uma visão geral rápida e uma folha de dica. Se é novo no framework SysOperation, recomendo vivamente que leia também o white paper da Microsoft sobre o assunto. A informação aqui pode ser útil se precisar apenas de uma rápida atualização 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 o SysOperationDataContractBase)
Serviço (deve estender o SysOperationServiceBase)
Controlador (deve estender o SysOperationServiceController)

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

Contrato de dados

O contrato de dados contém os membros de dados necessários para a sua operação. Pode ser comparado com o macro típico CurrentList definido no framework RunBase, mas implementado como uma classe. O contrato de dados deveria estender o SysOperationDataContractBase, mas funcionará mesmo que não funcione. A vantagem de estender a super classe é que fornece alguma informação sobre a sessão que pode ser útil.

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

Neste exemplo, o itemId é um membro de dados. Precisas de implementar um método parm para cada membro de dados e marcá-lo com o DataMemberAttribute para que o framework saiba o que é. Isto permite que o framework construa automaticamente o diálogo para 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 lote ou algo do género – essa é responsabilidade da classe controladora. Ao separar isto, é mais provável que desenhe bem o seu código e crie código mais reutilizável.

Tal como a classe data contract, a classe service não precisa de herdar nada em particular, mas deve herdar da classe SysOperationServiceBase, pelo menos se esperar que o serviço seja executado como um batch, pois a superclasse fornece alguma informação sobre o contexto batch. 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 controlador trata da execução e processamento em lote da sua operação. Também garante que o código é executado em CIL para máximo desempenho. A classe controller normalmente herda da classe SysOperationServiceController, embora existam outras opções também.

class MyController extends SysOperationServiceController
{
}

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

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 como

public static void main(Args _args)
{
    ;

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

E basicamente estás acabado. O acima é obviamente um exemplo muito simples e a framework contém uma infinidade de outras opções e possibilidades, mas isto serve como uma visão geral rápida caso precise de uma revisão quando não usa a framework há algum tempo.

Leitura adicional

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