Miklix

Visió general ràpida de Dynamics AX 2012 SysOperation Framework

Publicat: 5 de març del 2025, a les 19:29:18 UTC
Última actualització: 12 de gener del 2026, a les 8:40:30 UTC

Aquest article ofereix una visió general ràpida (o guia) sobre com implementar classes de processament i treballs per lots al marc de treball SysOperation del Dynamics AX 2012 i del Dynamics 365 for Operations.


Aquesta pàgina es va traduir automàticament de l'anglès per tal de fer-la accessible al màxim de persones possible. Malauradament, la traducció automàtica encara no és una tecnologia perfeccionada, de manera que es poden produir errors. Si ho prefereixes, pots veure la versió original en anglès aquí:

Dynamics AX 2012 SysOperation Framework Quick Overview

La informació d'aquesta publicació es basa en el Dynamics AX 2012 R3. Pot ser vàlida o no per a altres versions. (Actualització: puc confirmar que la informació d'aquest article també és vàlida per al Dynamics 365 for Operations)


Aquesta publicació només pretén ser una breu descripció general i una guia pràctica. Si sou nous al framework SysOperation, us recomano que llegiu també el document tècnic de Microsoft sobre el tema. La informació que trobareu aquí us pot ser útil si només necessiteu un repàs ràpid de les diferents classes implicades en el desenvolupament d'operacions amb aquest framework.

Hi ha variacions, però quan utilitzo el marc de treball normalment implemento tres classes:

  • Contracte de dades (hauria d'ampliar SysOperationDataContractBase)
  • Servei (hauria d'ampliar SysOperationServiceBase)
  • Controlador (ha d'ampliar SysOperationServiceController)

Més, també puc implementar una classe UIBuilder (que ha d'estendre SysOperationUIBuilder), però això només és necessari si el diàleg per alguna raó ha de ser més avançat del que genera automàticament el framework.


Contracte de dades

El contracte de dades conté els membres de dades necessaris per a la vostra operació. Es pot comparar amb la macro típica CurrentList definida al marc de treball RunBase, però implementada com una classe. El contracte de dades hauria d'estendre SysOperationDataContractBase, però funcionarà encara que no ho faci. L'avantatge d'estendre la superclasse és que proporciona informació de sessió que pot ser útil.

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

En aquest exemple, l'itemId és un membre de dades. Cal implementar un mètode parm per a cada membre de dades i etiquetar-lo amb l'Attribute DataMember perquè el marc de treball sàpiga què és. Això permet que el marc de treball creï automàticament el diàleg.

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

    itemId = _itemId;
    return itemId;
}


Servei

La classe de servei és la classe que conté la lògica de negoci real. No es preocupa de mostrar diàlegs, processament per lots ni res semblant; això és responsabilitat de la classe controladora. Si separeu això, és més probable que dissenyeu bé el vostre codi i que creeu un codi més reutilitzable.

Igual que la classe de contracte de dades, la classe de servei no necessita heretar de res en particular, però sí que hauria d'heretar de la classe SysOperationServiceBase, almenys si espereu que el servei s'executi com una tasca per lots, ja que la superclasse proporciona informació sobre el context del lot. El mètode que inicia l'operació (és a dir, executa la lògica de negoci) ha de prendre un objecte de la vostra classe de contracte de dades com a entrada i ha d'estar decorat amb [SysEntryPointAttribute]. Per exemple:

class MyService extends SysOperationServiceBase
{
}

Amb un mètode anomenat run:

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


Controlador

La classe controladora gestiona l'execució i el processament per lots de la vostra operació. També s'assegura que el codi s'executi en CIL per obtenir el màxim rendiment. La classe controladora normalment hereta de la classe SysOperationServiceController, tot i que també hi ha altres opcions.

class MyController extends SysOperationServiceController
{
}

El constructor de la superclasse pren com a paràmetres un nom de classe, un nom de mètode i (opcionalment) un mode d'execució. Els noms de classe i mètode haurien de ser el nom de la vostra classe de servei i el mètode que s'hi hauria d'executar. Per tant, podeu implementar el mètode de construcció del vostre controlador així:

public static MyController construct()
{
    ;

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

Aleshores, el mètode principal de la classe MyController pot ser tan simple com

public static void main(Args _args)
{
    ;

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

I ja està. L'anterior és, òbviament, un exemple molt senzill i el marc de treball conté una gran quantitat d'altres opcions i possibilitats, però això serveix com a visió general ràpida si necessiteu un repàs quan no heu utilitzat el marc de treball durant un temps.

Lectures addicionals

Si t'ha agradat aquesta publicació, també et poden agradar aquests suggeriments:


Comparteix a BlueskyComparteix a FacebookComparteix a LinkedInComparteix a TumblrComparteix a XComparteix a LinkedInPin a Pinterest

Mikkel Christensen

Sobre l'autor

Mikkel Christensen
Mikkel és el creador i propietari de miklix.com. Té més de 20 anys d'experiència com a programador/desenvolupador de programari informàtic professional i actualment treballa a temps complet per a una gran corporació informàtica europea. Quan no fa blocs, dedica el seu temps lliure a una gran varietat d'interessos, aficions i activitats, que fins a cert punt es poden reflectir en la varietat de temes tractats en aquest lloc web.