Panoramica rapida di Dynamics AX 2012 SysOperation Framework

Pubblicato: 15 febbraio 2025 alle ore 22:35:22 UTC

Questo articolo fornisce una rapida panoramica (o promemoria) su come implementare classi di elaborazione e processi batch nel framework SysOperation in Dynamics AX 2012 e Dynamics 365 for Operations.

Questa pagina è stata tradotta automaticamente dall'inglese per renderla accessibile al maggior numero di persone possibile. Purtroppo, la traduzione automatica non è ancora una tecnologia perfezionata, quindi possono verificarsi degli errori. Se preferite, potete consultare la versione originale in inglese qui:

Dynamics AX 2012 SysOperation Framework Quick Overview

Le informazioni contenute in questo post si basano su Dynamics AX 2012 R3. Potrebbero essere valide o meno per altre versioni. (Aggiornamento: posso confermare che le informazioni contenute in questo articolo sono valide anche per Dynamics 365 for Operations)

Questo post è pensato solo come una rapida panoramica e un promemoria. Se non hai familiarità con il framework SysOperation, ti consiglio vivamente di leggere anche il white paper di Microsoft sull'argomento. Le informazioni qui contenute potrebbero essere utili se hai solo bisogno di una rapida rinfrescata sulle diverse classi coinvolte nello sviluppo di operazioni con questo framework.

Esistono delle varianti, ma quando utilizzo il framework in genere implemento tre classi:

Contratto dati (dovrebbe estendere SysOperationDataContractBase)
Servizio (dovrebbe estendere SysOperationServiceBase)
Controller ( deve estendere SysOperationServiceController)

Inoltre, potrei anche implementare una classe UIBuilder ( che deve estendere SysOperationUIBuilder), ma ciò è necessario solo se per qualche motivo il dialogo deve essere più avanzato di quello generato automaticamente dal framework.

Contratto dati

Il contratto dati contiene i membri dati necessari per la tua operazione. Può essere paragonato alla tipica macro CurrentList definita nel framework RunBase, ma implementata come una classe. Il contratto dati dovrebbe estendere SysOperationDataContractBase, ma funzionerà anche se non lo fa. Il vantaggio di estendere la superclasse è che fornisce alcune informazioni di sessione che potrebbero essere utili.

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

In questo esempio, itemId è un membro dati. Devi implementare un metodo parm per ogni membro dati e contrassegnarlo con DataMemberAttribute in modo che il framework sappia di cosa si tratta. Ciò consente al framework di creare automaticamente il dialogo per te.

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

    itemId = _itemId;
    return itemId;
}

Servizio

La classe di servizio è la classe che contiene la logica aziendale effettiva. Non si occupa di mostrare dialoghi, elaborazione batch o cose del genere: questa è responsabilità della classe controller. Separando questo, è più probabile che tu progetti bene il tuo codice e crei codice più riutilizzabile.

Come la classe del contratto dati, la classe del servizio non deve ereditare da nulla in particolare, ma dovrebbe ereditare dalla classe SysOperationServiceBase, almeno se ci si aspetta che il servizio venga eseguito come un job batch, poiché la superclasse fornisce alcune informazioni sul contesto batch. Il metodo che avvia l'operazione (ovvero esegue la logica aziendale) deve prendere un oggetto della classe del contratto dati come input e deve essere decorato con [SysEntryPointAttribute]. Ad esempio:

class MyService extends SysOperationServiceBase
{
}

con un metodo chiamato run:

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

Controllore

La classe controller gestisce l'esecuzione e l'elaborazione batch della tua operazione. Si assicura inoltre che il codice venga eseguito in CIL per le massime prestazioni. La classe controller eredita in genere dalla classe SysOperationServiceController, sebbene vi siano anche altre opzioni.

class MyController extends SysOperationServiceController
{
}

Il costruttore della superclasse accetta come parametri un nome di classe, un nome di metodo e (facoltativamente) una modalità di esecuzione. I nomi di classe e metodo dovrebbero essere il nome della tua classe di servizio e il metodo che dovrebbe essere eseguito su di essa. Quindi, potresti implementare il metodo di costruzione del tuo controller in questo modo:

public static MyController construct()
{
    ;

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

Quindi il metodo principale della classe MyController può essere semplice come

public static void main(Args _args)
{
    ;

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

E hai praticamente finito. Quello sopra è ovviamente un esempio molto semplice e il framework contiene una pletora di altre opzioni e possibilità, ma questo serve come una rapida panoramica se hai bisogno di una rinfrescata quando non usi il framework da un po'.