Panoramica rapida di Dynamics AX 2012 SysOperation Framework

Pubblicato: 15 febbraio 2025 alle ore 22:35:22 UTC
Ultimo aggiornamento: 12 gennaio 2026 alle ore 08:38:51 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 articolo si basano su Dynamics AX 2012 R3. Potrebbero essere valide anche 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 conoscete il framework SysOperation, vi consiglio vivamente di leggere anche il white paper di Microsoft sull'argomento. Le informazioni qui contenute potrebbero essere utili se avete bisogno di una rapida panoramica delle 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 la finestra di dialogo deve essere più avanzata di quella generata automaticamente dal framework.

Contratto di dati

Il contratto dati contiene i membri dati necessari per l'operazione. Può essere paragonato alla tipica macro CurrentList definita nel framework RunBase, ma implementato come 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. È necessario implementare un metodo parm per ogni membro dati e contrassegnarlo con DataMemberAttribute in modo che il framework sappia di cosa si tratta. Questo consente al framework di creare automaticamente la finestra di dialogo.

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

    itemId = _itemId;
    return itemId;
}

Servizio

La classe di servizio è la classe che contiene la logica di business vera e propria. Non si occupa di visualizzare finestre di dialogo, elaborare batch o cose del genere: questa è responsabilità della classe controller. Separando queste due classi, è più probabile progettare il codice in modo efficace e renderlo 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 si prevede che il servizio venga eseguito come un processo batch, poiché la superclasse fornisce alcune informazioni sul contesto batch. Il metodo che avvia l'operazione (ovvero esegue la logica di business) deve accettare 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 dell'operazione. Garantisce inoltre che il codice venga eseguito in CIL per ottenere le massime prestazioni. La classe controller in genere eredita dalla classe SysOperationServiceController, sebbene siano disponibili anche altre opzioni.

class MyController extends SysOperationServiceController
{
}

Il costruttore della superclasse accetta come parametri il nome della classe, il nome del metodo e (facoltativamente) la modalità di esecuzione. I nomi della classe e del metodo dovrebbero essere il nome della classe del servizio e il metodo che deve essere eseguito su di essa. Quindi, potresti implementare il metodo di costruzione del 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 il gioco è fatto. Quello sopra è ovviamente un esempio molto semplice e il framework contiene una miriade di altre opzioni e possibilità, ma questo può servire come rapida panoramica se hai bisogno di una rinfrescata se non usi il framework da un po'.

Ulteriori letture

Se ti è piaciuto questo post, potrebbero piacerti anche questi suggerimenti: