Dynamics AX 2012 SysOperation Framework Szybki przegląd

Opublikowano: 15 lutego 2025 22:35:34 UTC
Ostatnia aktualizacja: 12 stycznia 2026 08:38:57 UTC

W tym artykule znajdziesz krótki przegląd (lub ściągę) sposobów wdrażania klas przetwarzania i zadań wsadowych w środowisku SysOperation w systemie Dynamics AX 2012 i Dynamics 365 for Operations.

Ta strona została przetłumaczona maszynowo z języka angielskiego, aby była dostępna dla jak największej liczby osób. Niestety, tłumaczenie maszynowe nie jest jeszcze dopracowaną technologią, więc mogą wystąpić błędy. Jeśli wolisz, możesz wyświetlić oryginalną angielską wersję tutaj:

Dynamics AX 2012 SysOperation Framework Quick Overview

Informacje zawarte w tym poście dotyczą systemu Dynamics AX 2012 R3. Mogą, ale nie muszą, być aktualne dla innych wersji. (Aktualizacja: Potwierdzam, że informacje zawarte w tym artykule dotyczą również systemu Dynamics 365 for Operations).

Ten post ma na celu jedynie szybkie omówienie i ściągę. Jeśli dopiero zaczynasz przygodę z frameworkiem SysOperation, gorąco polecam również zapoznanie się z dokumentem Microsoftu na ten temat. Zawarte tu informacje mogą okazać się przydatne, jeśli potrzebujesz jedynie krótkiego przypomnienia o różnych klasach wykorzystywanych w tworzeniu operacji w tym frameworku.

Istnieją pewne warianty, ale kiedy korzystam z tego frameworka, zwykle implementuję trzy klasy:

Kontrakt danych (powinien rozszerzać SysOperationDataContractBase)
Usługa (powinna rozszerzać SysOperationServiceBase)
Kontroler (musi rozszerzać SysOperationServiceController)

Dodatkowo mogę również zaimplementować klasę UIBuilder (musi rozszerzać SysOperationUIBuilder), ale jest to konieczne tylko wtedy, gdy z jakiegoś powodu okno dialogowe musi być bardziej zaawansowane niż to, co framework generuje automatycznie.

Umowa danych

Kontrakt danych zawiera elementy danych potrzebne do wykonania operacji. Można go porównać do typowego makra CurrentList zdefiniowanego w środowisku RunBase, ale zaimplementowanego jako klasa. Kontrakt danych powinien rozszerzać SysOperationDataContractBase, ale będzie działał nawet wtedy, gdy tego nie zrobi. Zaletą rozszerzania superklasy jest to, że dostarcza on pewnych przydatnych informacji o sesji.

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

W tym przykładzie itemId jest elementem danych. Musisz zaimplementować metodę parm dla każdego elementu danych i oznaczyć go atrybutem DataMemberAttribute, aby framework wiedział, czym on jest. Dzięki temu framework automatycznie utworzy okno dialogowe.

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

    itemId = _itemId;
    return itemId;
}

Praca

Klasa usługi to klasa zawierająca faktyczną logikę biznesową. Nie zajmuje się ona wyświetlaniem okien dialogowych, przetwarzaniem wsadowym ani niczym podobnym – za to odpowiada klasa kontrolera. Oddzielenie tych dwóch klas zwiększa prawdopodobieństwo, że kod będzie lepiej zaprojektowany i będzie bardziej wielokrotnego użytku.

Podobnie jak klasa kontraktu danych, klasa usługi nie musi dziedziczyć po niczym konkretnym, ale powinna dziedziczyć po klasie SysOperationServiceBase, przynajmniej jeśli oczekujesz, że usługa będzie uruchamiana jako zadanie wsadowe, ponieważ superklasa dostarcza pewnych informacji o kontekście wsadowym. Metoda uruchamiająca operację (tj. uruchamiająca logikę biznesową) musi przyjmować obiekt klasy kontraktu danych jako dane wejściowe i powinna być oznaczona atrybutem [SysEntryPointAttribute]. Na przykład:

class MyService extends SysOperationServiceBase
{
}

Za pomocą metody o nazwie run:

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

Kontroler

Klasa kontrolera obsługuje wykonywanie i przetwarzanie wsadowe operacji. Zapewnia również wykonywanie kodu w języku CIL, co zapewnia maksymalną wydajność. Klasa kontrolera zazwyczaj dziedziczy po klasie SysOperationServiceController, choć istnieją również inne opcje.

class MyController extends SysOperationServiceController
{
}

Konstruktor superklasy przyjmuje jako parametry nazwę klasy, nazwę metody i (opcjonalnie) tryb wykonywania. Nazwy klasy i metody powinny odpowiadać nazwie klasy usługi i metodzie, która ma zostać na niej uruchomiona. Możesz więc zaimplementować metodę konstruktora kontrolera w następujący sposób:

public static MyController construct()
{
    ;

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

Wówczas główna metoda klasy MyController może być tak prosta jak

public static void main(Args _args)
{
    ;

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

I w zasadzie gotowe. Powyższy przykład to oczywiście bardzo prosty przykład, a framework zawiera mnóstwo innych opcji i możliwości, ale służy on jako szybki przegląd, jeśli potrzebujesz odświeżenia, gdy nie korzystałeś z frameworka przez jakiś czas.

Dalsza lektura

Jeśli podobał Ci się ten wpis, mogą Cię zainteresować również poniższe sugestie: