Miklix

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

Publicat: 5 de març del 2025, a les 19:29:18 UTC

Aquest article ofereix una visió general ràpida (o full de trucs) sobre com implementar classes de processament i treballs per lots al marc SysOperation al Dynamics AX 2012 i 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 Dynamics AX 2012 R3. Pot ser vàlid 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 una visió general ràpida i un full de trucs. Si sou nou al marc SysOperation, us recomano que llegiu també el llibre blanc de Microsoft sobre el tema. La informació aquí pot ser útil si només necessiteu una ràpida ressenya de les diferents classes implicades en el desenvolupament d'operacions amb aquest marc.

Hi ha variacions, però quan faig servir el marc normalment implemento tres classes:

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

A més, també puc implementar una classe UIBuilder ( ha d' estendre SysOperationUIBuilder), però això només és necessari si el diàleg per algun motiu ha de ser més avançat que el que el marc genera automàticament.


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 RunBase, però en canvi s'implementa com a classe. El contracte de dades hauria d'estendre SysOperationDataContractBase, però funcionarà encara que no ho faci. L'avantatge d'ampliar la superclasse és que proporciona informació de la sessió que pot ser útil.

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

En aquest exemple, l'elementId és un membre de dades. Heu d'implementar un mètode parm per a cada membre de dades i etiquetar-lo amb el DataMemberAttribute perquè el marc sàpiga què és. Això permet que el marc 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 o res semblant, això és responsabilitat de la classe del controlador. En separar-ho, és més probable que dissenyeu bé el vostre codi i feu més codi reutilitzable.

Igual que la classe de contracte de dades, la classe de servei no necessita heretar de res en particular, però hauria d'heretar de la classe SysOperationServiceBase, almenys si espereu que el servei s'executi com un treball 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 del controlador gestiona l'execució i el processament per lots de la vostra operació. També s'assegura que el codi s'executa en CIL per obtenir el màxim rendiment. La classe del controlador normalment hereta de la classe SysOperationServiceController, tot i que també hi ha altres opcions.

class MyController extends SysOperationServiceController
{
}

El constructor de la superclasse pren un nom de classe, un nom de mètode i (opcionalment) el mode d'execució com a paràmetres. 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 com aquest:

public static MyController construct()
{
    ;

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

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

public static void main(Args _args)
{
    ;

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

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

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

Mikkel Bang Christensen

Sobre l'autor

Mikkel Bang 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.