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

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

Este artigo fornece uma visão geral rápida (ou folha de dicas) sobre como implementar classes de processamento e trabalhos em lote na estrutura SysOperation no Dynamics AX 2012 e no 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. 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 é apenas uma visão geral rápida e uma folha de dicas. Se você é novo no framework SysOperation, eu sugiro fortemente que você leia o white paper da Microsoft sobre o assunto também. As informações aqui podem ser úteis se você só precisa de uma rápida atualização sobre as 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 ( deve estender SysOperationUIBuilder), mas isso só é necessário se, por algum motivo, o diálogo tiver que 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 sua operação. Ele pode ser comparado à macro CurrentList típica definida na estrutura 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 DataMemberAttribute para que o framework saiba o que é. Isso permite que o framework crie o diálogo automaticamente para você.

[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ócios real. Ela não se preocupa em mostrar diálogos, processamento em lote ou qualquer coisa do tipo – essa é a responsabilidade da classe controladora. Ao separar isso, você tem mais probabilidade de projetar bem seu código e fazer um código mais reutilizável.

Assim como a classe de contrato de dados, a classe de serviço não precisa herdar de nada em particular, mas deve herdar da classe SysOperationServiceBase, pelo menos se você espera que o serviço seja executado como um trabalho em lote, pois 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 [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 controller lida com 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 desempenho máximo. A classe controller normalmente herda da classe SysOperationServiceController, embora também haja outras opções.

class MyController extends SysOperationServiceController
{
}

O construtor da superclasse recebe um nome de classe, nome de método e (opcionalmente) modo de execução como parâmetros. Os nomes de classe e método devem ser o nome da sua classe de serviço e o método que deve ser executado nela. Então, você pode implementar o método de construção do seu 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 quanto

public static void main(Args _args)
{
    ;

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

E você basicamente terminou. O acima é obviamente um exemplo muito simples e o framework contém uma infinidade de outras opções e possibilidades, mas isso serve como uma rápida visão geral se você precisar de uma atualização quando não tiver usado o framework por um tempo.