Dynamics AX 2012 SysOperation Framework Szybki przegląd

Opublikowano: 15 lutego 2025 22:35:34 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 w tym poście są oparte na Dynamics AX 2012 R3. Mogą być lub nie być ważne dla innych wersji. (Aktualizacja: Mogę potwierdzić, że informacje w tym artykule są również ważne dla Dynamics 365 for Operations)

Ten post jest tylko szybkim przeglądem i ściągawką. Jeśli jesteś nowy w frameworku SysOperation, zdecydowanie polecam Ci również przeczytanie białej księgi Microsoftu na ten temat. Informacje tutaj mogą być przydatne, jeśli potrzebujesz tylko szybkiego odświeżenia wiedzy na temat różnych klas zaangażowanych w rozwijanie operacji za pomocą tego frameworka.

Istnieją pewne warianty, ale kiedy używam tego frameworka, zazwyczaj 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 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, jeśli tego nie zrobi. Zaletą rozszerzania superklasy jest to, że dostarcza pewnych informacji o sesji, które mogą być przydatne.

[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. Umożliwia to frameworkowi automatyczne zbudowanie okna dialogowego.

[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 pokazywaniem dialogów, przetwarzaniem wsadowym ani niczym podobnym – to jest odpowiedzialność klasy kontrolera. Oddzielając to, prawdopodobnie lepiej zaprojektujesz swój kod i stworzysz kod nadający się do ponownego użycia.

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, która uruchamia operację (tj. uruchamia logikę biznesową) musi przyjmować obiekt klasy kontraktu danych jako dane wejściowe i powinna być ozdobiona 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ż, że kod jest wykonywany w CIL w celu uzyskania maksymalnej wydajności. Klasa kontrolera zazwyczaj dziedziczy po klasie SysOperationServiceController, chociaż istnieją również inne opcje.

class MyController extends SysOperationServiceController
{
}

Konstruktor superklasy przyjmuje nazwę klasy, nazwę metody i (opcjonalnie) tryb wykonywania jako parametry. Nazwy klasy i metody powinny być nazwą klasy usługi i metodą, która powinna być na niej uruchomiona. Tak więc możesz zaimplementować metodę konstrukcji kontrolera w następujący sposób:

public static MyController construct()
{
    ;

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

Następnie 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ższe jest oczywiście bardzo prostym przykładem, a framework zawiera mnóstwo innych opcji i możliwości, ale służy jako szybki przegląd, jeśli potrzebujesz odświeżenia, gdy nie korzystałeś z frameworka przez jakiś czas.