Miklix

Dynamics AX 2012 SysOperation Framework Prezentare generală rapidă

Publicat: 15 februarie 2025 la 22:35:37 UTC
Ultima actualizare: 12 ianuarie 2026 la 08:39:01 UTC

Acest articol oferă o prezentare generală rapidă (sau o fișă informativă) despre cum se implementează clasele de procesare și joburile batch în framework-ul SysOperation din Dynamics AX 2012 și Dynamics 365 for Operations.


Această pagină a fost tradusă automat din limba engleză pentru a o face accesibilă cât mai multor persoane. Din păcate, traducerea automată nu este încă o tehnologie perfecționată, astfel încât pot apărea erori. Dacă preferați, puteți vizualiza versiunea originală în limba engleză aici:

Dynamics AX 2012 SysOperation Framework Quick Overview

Informațiile din această postare se bazează pe Dynamics AX 2012 R3. Este posibil să fie sau nu valabile pentru alte versiuni. (Actualizare: Pot confirma că informațiile din acest articol sunt valabile și pentru Dynamics 365 for Operations)


Această postare este concepută doar ca o prezentare generală rapidă și o fișă informativă. Dacă sunteți nou în framework-ul SysOperation, vă recomand insistent să citiți și cartea albă a Microsoft pe această temă. Informațiile de aici pot fi utile dacă aveți nevoie doar de o scurtă reîmprospătare a cunoștințelor despre diferitele clase implicate în dezvoltarea operațiunilor cu acest framework.

Există variații, dar când utilizez framework-ul, implementez de obicei trei clase:

  • Contract de date (ar trebui să extindă SysOperationDataContractBase)
  • Serviciu (ar trebui să extindă SysOperationServiceBase)
  • Controler (trebuie să extindă SysOperationServiceController)

În plus, aș putea implementa și o clasă UIBuilder (trebuie să extindă SysOperationUIBuilder), dar acest lucru este necesar doar dacă, dintr-un anumit motiv, dialogul trebuie să fie mai avansat decât ceea ce generează automat framework-ul.


Contract de date

Contractul de date conține membrii de date necesari pentru operațiunea dvs. Poate fi comparat cu macro-ul tipic CurrentList definit în framework-ul RunBase, dar implementat ca o clasă. Contractul de date ar trebui să extindă SysOperationDataContractBase, dar va funcționa chiar dacă nu o face. Avantajul extinderii superclasei este că oferă unele informații despre sesiune care pot fi utile.

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

În acest exemplu, itemId este un membru de date. Trebuie să implementați o metodă parm pentru fiecare membru de date și să o etichetați cu DataMemberAttribute, astfel încât framework-ul să știe ce este. Acest lucru permite framework-ului să construiască automat dialogul pentru dvs.

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

    itemId = _itemId;
    return itemId;
}


Serviciu

Clasa service este clasa care conține logica de business propriu-zisă. Nu se ocupă de afișarea dialogurilor, procesarea în loturi sau orice altceva de acest fel - aceasta este responsabilitatea clasei controller. Separând acestea, aveți mai multe șanse să vă proiectați codul bine și să creați un cod mai reutilizabil.

La fel ca clasa contractului de date, clasa serviciului nu trebuie să moștenească nimic anume, dar ar trebui să moștenească de la clasa SysOperationServiceBase, cel puțin dacă vă așteptați ca serviciul să fie rulat ca un job batch, deoarece superclasa oferă informații despre contextul batch. Metoda care pornește operațiunea (adică rulează logica de business) trebuie să ia un obiect din clasa contractului de date ca intrare și ar trebui să fie decorată cu [SysEntryPointAttribute]. De exemplu:

class MyService extends SysOperationServiceBase
{
}

Cu o metodă numită run:

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


Controlor

Clasa controller se ocupă de execuția și procesarea în lot a operației. De asemenea, se asigură că codul este executat în CIL pentru performanță maximă. Clasa controller moștenește de obicei din clasa SysOperationServiceController, deși există și alte opțiuni.

class MyController extends SysOperationServiceController
{
}

Constructorul superclasei primește ca parametri un nume de clasă, un nume de metodă și (opțional) un mod de execuție. Numele clasei și metodei ar trebui să fie numele clasei de servicii și al metodei care ar trebui rulată pe aceasta. Așadar, ați putea implementa metoda de construcție a controlerului astfel:

public static MyController construct()
{
    ;

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

Atunci metoda principală a clasei MyController poate fi la fel de simplă ca

public static void main(Args _args)
{
    ;

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

Și practic ați terminat. Cele de mai sus sunt evident un exemplu foarte simplu, iar framework-ul conține o multitudine de alte opțiuni și posibilități, dar acesta servește ca o scurtă prezentare generală dacă aveți nevoie de o reîmprospătare a cunoștințelor după ce nu ați folosit framework-ul o perioadă.

Lectură suplimentară

Dacă ți-a plăcut această postare, s-ar putea să-ți placă și aceste sugestii:


Distribuie pe BlueskyDistribuie pe FacebookDistribuie pe LinkedInDistribuie pe TumblrDistribuie pe XDistribuie pe LinkedInPin pe Pinterest

Mikkel Christensen

Despre autor

Mikkel Christensen
Mikkel este creatorul și proprietarul miklix.com. El are peste 20 de ani de experiență ca programator de calculatoare/dezvoltator software profesionist și este în prezent angajat cu normă întreagă pentru o mare corporație europeană de IT. Atunci când nu scrie pe blog, își petrece timpul liber cu o gamă largă de interese, hobby-uri și activități, care se pot reflecta într-o anumită măsură în varietatea de subiecte abordate pe acest site.