Dynamics AX 2012 SysOperation Framework - Kurzübersicht

Veröffentlicht: 15. Februar 2025 um 22:33:05 UTC

Dieser Artikel bietet einen kurzen Überblick (oder Spickzettel) zur Implementierung von Verarbeitungsklassen und Batchaufträgen im SysOperation-Framework in Dynamics AX 2012 und Dynamics 365 for Operations.

Diese Seite wurde maschinell aus dem Englischen übersetzt, um sie so vielen Menschen wie möglich zugänglich zu machen. Leider ist die maschinelle Übersetzung noch keine ausgereifte Technologie, so dass Fehler auftreten können. Wenn Sie es vorziehen, können Sie sich die englische Originalversion hier ansehen:

Dynamics AX 2012 SysOperation Framework Quick Overview

Die Informationen in diesem Beitrag basieren auf Dynamics AX 2012 R3. Sie können für andere Versionen gültig sein, müssen es aber nicht. (Update: Ich kann bestätigen, dass die Informationen in diesem Artikel auch für Dynamics 365 for Operations gültig sind.)

Dieser Beitrag ist nur als kurzer Überblick und Spickzettel gedacht. Wenn Sie mit dem SysOperation-Framework noch nicht vertraut sind, empfehle ich Ihnen dringend, auch das Whitepaper von Microsoft zu diesem Thema zu lesen. Die Informationen hier können nützlich sein, wenn Sie nur einen kurzen Auffrischungskurs über die verschiedenen Klassen benötigen, die an der Entwicklung von Operationen mit diesem Framework beteiligt sind.

Es gibt Variationen, aber wenn ich das Framework verwende, implementiere ich normalerweise drei Klassen:

Datenvertrag (sollte SysOperationDataContractBase erweitern)
Service (sollte SysOperationServiceBase erweitern)
Controller ( muss SysOperationServiceController erweitern)

Darüber hinaus kann ich auch eine UIBuilder-Klasse implementieren ( muss SysOperationUIBuilder erweitern), aber das ist nur erforderlich, wenn der Dialog aus irgendeinem Grund fortgeschrittener sein muss als das, was das Framework automatisch generiert.

Datenvertrag

Der Datenvertrag enthält die für Ihren Vorgang erforderlichen Datenelemente. Er kann mit dem typischen CurrentList-Makro verglichen werden, das im RunBase-Framework definiert ist, aber stattdessen als Klasse implementiert ist. Der Datenvertrag sollte SysOperationDataContractBase erweitern, funktioniert aber auch, wenn dies nicht der Fall ist. Der Vorteil der Erweiterung der Superklasse besteht darin, dass sie einige Sitzungsinformationen bereitstellt, die nützlich sein können.

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

In diesem Beispiel ist die itemId ein Datenelement. Sie müssen für jedes Datenelement eine parm-Methode implementieren und es mit dem DataMemberAttribute kennzeichnen, damit das Framework weiß, was es ist. Dadurch kann das Framework den Dialog automatisch für Sie erstellen.

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

    itemId = _itemId;
    return itemId;
}

Service

Die Serviceklasse ist die Klasse, die die eigentliche Geschäftslogik enthält. Sie kümmert sich nicht um die Anzeige von Dialogen, Stapelverarbeitung oder Ähnliches – das ist Aufgabe der Controllerklasse. Durch die Trennung können Sie Ihren Code besser gestalten und wiederverwendbareren Code erstellen.

Wie die Datenvertragsklasse muss die Serviceklasse nicht von etwas Bestimmtem erben, sie sollte jedoch von der SysOperationServiceBase-Klasse erben, zumindest wenn Sie erwarten, dass der Service als Batch-Job ausgeführt wird, da die Superklasse einige Informationen zum Batch-Kontext bereitstellt. Die Methode, die den Vorgang startet (d. h. die Geschäftslogik ausführt), muss ein Objekt Ihrer Datenvertragsklasse als Eingabe verwenden und sollte mit dem [SysEntryPointAttribute] dekoriert werden. Beispiel:

class MyService extends SysOperationServiceBase
{
}

mit einer Methode namens run:

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

Regler

Die Controller-Klasse übernimmt die Ausführung und Stapelverarbeitung Ihres Vorgangs. Sie stellt außerdem sicher, dass der Code für maximale Leistung in CIL ausgeführt wird. Die Controller-Klasse erbt normalerweise von der Klasse SysOperationServiceController, obwohl es auch andere Optionen gibt.

class MyController extends SysOperationServiceController
{
}

Der Konstruktor der Superklasse verwendet als Parameter einen Klassennamen, einen Methodennamen und (optional) einen Ausführungsmodus. Die Klassen- und Methodennamen sollten der Name Ihrer Serviceklasse und der Methode sein, die darauf ausgeführt werden soll. Sie könnten die Konstruktmethode Ihres Controllers also folgendermaßen implementieren:

public static MyController construct()
{
    ;

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

Dann kann die Hauptmethode der MyController-Klasse so einfach sein wie

public static void main(Args _args)
{
    ;

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

Und im Grunde sind Sie fertig. Das obige Beispiel ist natürlich sehr einfach und das Framework enthält eine Vielzahl anderer Optionen und Möglichkeiten, aber dies dient als schneller Überblick, falls Sie Ihr Wissen auffrischen müssen, wenn Sie das Framework eine Weile nicht verwendet haben.