Dynamics AX 2012 SysOperation Framework - Kurzübersicht

Veröffentlicht: 15. Februar 2025 um 22:33:05 UTC
Zuletzt aktualisiert: 12. Januar 2026 um 08:38:46 UTC

Dieser Artikel bietet einen kurzen Überblick (oder eine Kurzanleitung) zur Implementierung von Verarbeitungsklassen und Batch-Jobs 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 gelten möglicherweise nicht für andere Versionen. (Update: Ich kann bestätigen, dass die Informationen in diesem Artikel auch für Dynamics 365 for Operations gelten.)

Dieser Beitrag dient lediglich als kurzer Überblick und Spickzettel. Falls Sie mit dem SysOperation-Framework noch nicht vertraut sind, empfehle ich Ihnen dringend, zusätzlich das Whitepaper von Microsoft zu diesem Thema zu lesen. Die hier bereitgestellten Informationen können hilfreich sein, wenn Sie lediglich Ihr Wissen über die verschiedenen Klassen zur Entwicklung von Operationen mit diesem Framework auffrischen möchten.

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

Datenvertrag (sollte SysOperationDataContractBase erweitern)
Dienst (sollte SysOperationServiceBase erweitern)
Controller (muss von SysOperationServiceController erben)

Zusätzlich kann ich auch eine UIBuilder-Klasse implementieren (die von SysOperationUIBuilder erben muss), aber das ist nur dann notwendig, wenn der Dialog aus irgendeinem Grund komplexer sein muss als das, was das Framework automatisch generiert.

Datenvertrag

Der Datenvertrag enthält die für Ihre Operation benötigten Datenmember. Er ist vergleichbar mit dem typischen CurrentList-Makro des RunBase-Frameworks, jedoch als Klasse implementiert. Der Datenvertrag sollte von SysOperationDataContractBase erben, funktioniert aber auch ohne diese Ersetzung. Der Vorteil der Erweiterung der Oberklasse besteht darin, dass sie nützliche Sitzungsinformationen bereitstellt.

[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 es erkennt. 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 enthält die eigentliche Geschäftslogik. Sie ist nicht für die Anzeige von Dialogen, die Stapelverarbeitung oder Ähnliches zuständig – dafür ist die Controllerklasse verantwortlich. Durch diese Trennung lässt sich der Code besser strukturieren und wiederverwendbarer gestalten.

Wie die Datenvertragsklasse muss auch die Dienstklasse nicht von einer bestimmten Klasse erben. Sie sollte jedoch von der Klasse `SysOperationServiceBase` erben, zumindest wenn der Dienst als Batch-Auftrag ausgeführt werden soll, da die Oberklasse 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 entgegennehmen und mit dem Attribut `SysEntryPointAttribute` versehen sein. 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 Ihrer Operation. Sie stellt außerdem sicher, dass der Code in CIL ausgeführt wird, um eine optimale Leistung zu erzielen. Die Controller-Klasse erbt üblicherweise von der Klasse `SysOperationServiceController`, es gibt jedoch auch andere Optionen.

class MyController extends SysOperationServiceController
{
}

Der Konstruktor der Oberklasse erwartet als Parameter einen Klassennamen, einen Methodennamen und (optional) den Ausführungsmodus. Der Klassen- und Methodenname sollte dem Namen Ihrer Serviceklasse und der auszuführenden Methode entsprechen. Die Konstruktormethode Ihres Controllers könnte beispielsweise so implementiert werden:

public static MyController construct()
{
    ;

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

Dann kann die Hauptmethode der Klasse MyController so einfach sein wie

public static void main(Args _args)
{
    ;

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

Und damit sind Sie im Prinzip fertig. Das obige Beispiel ist natürlich sehr einfach gehalten, und das Framework bietet eine Fülle weiterer Optionen und Möglichkeiten. Es dient jedoch als kurzer Überblick, falls Sie Ihr Wissen auffrischen möchten, wenn Sie das Framework eine Weile nicht verwendet haben.

Weitere Informationen

Wenn Ihnen dieser Beitrag gefallen hat, könnten Ihnen auch diese Vorschläge gefallen: