Miklix

Dynamics AX 2012 SysOperation Framework Snabböversikt

Publicerad: 15 februari 2025 kl. 22:35:43 UTC
Senast uppdaterad: 12 januari 2026 kl. 08:39:09 UTC

Den här artikeln ger en snabb översikt (eller ett fusklapp) om hur man implementerar bearbetningsklasser och batchjobb i SysOperation-ramverket i Dynamics AX 2012 och Dynamics 365 for Operations.


Denna sida har maskinöversatts från engelska för att göra den tillgänglig för så många som möjligt. Tyvärr är maskinöversättning ännu inte en fulländad teknik, så fel kan uppstå. Om du föredrar det kan du se den engelska originalversionen här:

Dynamics AX 2012 SysOperation Framework Quick Overview

Informationen i det här inlägget är baserad på Dynamics AX 2012 R3. Den kan vara giltig för andra versioner, men inte för andra versioner. (Uppdatering: Jag kan bekräfta att informationen i den här artikeln även gäller för Dynamics 365 for Operations)


Det här inlägget är bara tänkt som en snabb översikt och ett fusklapp. Om du är nybörjare på SysOperation-ramverket rekommenderar jag starkt att du också läser Microsofts whitepaper om ämnet. Informationen här kan vara användbar om du bara behöver en snabb uppfräschning av de olika klasserna som är involverade i att utveckla operationer med detta ramverk.

Det finns variationer, men när jag använder ramverket implementerar jag vanligtvis tre klasser:

  • Datakontrakt (bör utökas med SysOperationDataContractBase)
  • Tjänst (bör utöka SysOperationServiceBase)
  • Controller (måste utöka SysOperationServiceController)

Dessutom kan jag också implementera en UIBuilder-klass (måste utöka SysOperationUIBuilder), men det är bara nödvändigt om dialogen av någon anledning måste vara mer avancerad än vad ramverket genererar automatiskt.


Dataavtal

Datakontraktet innehåller de datamedlemmar som behövs för din operation. Det kan jämföras med det typiska CurrentList-makrot som definieras i RunBase-ramverket, men implementeras som en klass istället. Datakontraktet bör utöka SysOperationDataContractBase, men fungerar även om det inte gör det. Fördelen med att utöka superklassen är att den tillhandahåller viss sessionsinformation som kan vara praktisk.

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

I det här exemplet är itemId en datamedlem. Du behöver implementera en parm-metod för varje datamedlem och tagga den med DataMemberAttribute så att ramverket vet vad det är. Detta gör att ramverket automatiskt kan bygga dialogrutan åt dig.

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

    itemId = _itemId;
    return itemId;
}


Service

Serviceklassen är den klass som innehåller själva affärslogiken. Den handlar inte om att visa dialogrutor, batchbearbetning eller något liknande – det är controllerklassens ansvar. Genom att separera detta är det mer sannolikt att du designar din kod väl och skapar mer återanvändbar kod.

Precis som datakontraktsklassen behöver inte serviceklassen ärva från något specifikt, men den bör ärva från SysOperationServiceBase-klassen, åtminstone om du förväntar dig att tjänsten kommer att köras som ett batchjobb, eftersom superklassen ger viss information om batchkontexten. Metoden som startar operationen (dvs. kör affärslogiken) måste ta ett objekt från din datakontraktsklass som indata och bör dekoreras med [SysEntryPointAttribute]. Till exempel:

class MyService extends SysOperationServiceBase
{
}

Med en metod som heter run:

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


Kontroller

Controller-klassen hanterar exekvering och batchbearbetning av din operation. Den säkerställer också att koden exekveras i CIL för maximal prestanda. Controller-klassen ärver vanligtvis från SysOperationServiceController-klassen, även om det finns andra alternativ också.

class MyController extends SysOperationServiceController
{
}

Konstruktorn för superklassen tar ett klassnamn, metodnamn och (valfritt) exekveringsläge som parametrar. Klass- och metodnamnen ska vara namnet på din serviceklass och den metod som ska köras på den. Så du kan implementera din kontrollerns konstruktionsmetod så här:

public static MyController construct()
{
    ;

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

Då kan huvudmetoden för MyController-klassen vara så enkel som

public static void main(Args _args)
{
    ;

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

Och du är i princip klar. Ovanstående är uppenbarligen ett mycket enkelt exempel och ramverket innehåller en uppsjö av andra alternativ och möjligheter, men detta fungerar som en snabb översikt om du behöver fräscha upp dig när du inte har använt ramverket på ett tag.

Vidare läsning

Om du gillade det här inlägget kanske du också gillar dessa förslag:


Dela på BlueskyDela på FacebookDela på LinkedInDela på TumblrDela på XDela på LinkedInFäst på Pinterest

Mikkel Christensen

Om författaren

Mikkel Christensen
Mikkel är skaparen och ägaren av miklix.com. Han har över 20 års erfarenhet som professionell datorprogrammerare/mjukvaruutvecklare och är för närvarande heltidsanställd på ett stort europeiskt IT-bolag. När han inte bloggar ägnar han sin fritid åt en mängd olika intressen, hobbies och aktiviteter, vilket i viss mån kan återspeglas i de olika ämnen som behandlas på den här webbplatsen.