Короткий огляд Dynamics AX 2012 SysOperation Framework

Опубліковано: 15 лютого 2025 р. о 22:35:47 UTC
Останнє оновлення: 12 січня 2026 р. о 08:39:12 UTC

У цій статті наведено короткий огляд (або шпаргалку) щодо впровадження класів обробки та пакетних завдань у платформі SysOperation у Dynamics AX 2012 та Dynamics 365 for Operations.

Ця сторінка була перекладена з англійської мови машинним перекладом, щоб зробити її доступною для якомога більшої кількості людей. На жаль, машинний переклад ще не є досконалою технологією, тому можуть траплятися помилки. Якщо ви бажаєте, ви можете переглянути оригінальну англійську версію тут:

Dynamics AX 2012 SysOperation Framework Quick Overview

Інформація в цій публікації базується на Dynamics AX 2012 R3. Вона може бути дійсна для інших версій, а може й ні. (Оновлення: Можу підтвердити, що інформація в цій статті також дійсна для Dynamics 365 for Operations)

Ця публікація призначена лише для короткого огляду та шпаргалки. Якщо ви новачок у фреймворку SysOperation, я також наполегливо рекомендую вам прочитати офіційний документ Microsoft на цю тему. Інформація тут може бути корисною, якщо вам просто потрібно швидко ознайомитися з різними класами, що беруть участь у розробці операцій за допомогою цього фреймворку.

Існують варіації, але коли я використовую цей фреймворк, я зазвичай реалізую три класи:

Контракт даних (має розширювати SysOperationDataContractBase)
Сервіс (має розширювати SysOperationServiceBase)
Контролер (має розширювати SysOperationServiceController)

Крім того, я також можу реалізувати клас UIBuilder (повинен розширити SysOperationUIBuilder), але це необхідно лише в тому випадку, якщо діалог з якоїсь причини має бути складнішим, ніж те, що фреймворк генерує автоматично.

Договір на передачу даних

Контракт даних містить елементи даних, необхідні для вашої операції. Його можна порівняти з типовим макросом CurrentList, визначеним у фреймворку RunBase, але реалізованим як клас. Контракт даних повинен розширювати SysOperationDataContractBase, але працюватиме навіть якщо це не так. Перевага розширення суперкласу полягає в тому, що він надає деяку інформацію про сеанс, яка може бути корисною.

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

У цьому прикладі itemId є членом даних. Вам потрібно реалізувати метод parm для кожного члена даних і позначити його тегом DataMemberAttribute, щоб фреймворк знав, що це таке. Це дозволить фреймворку автоматично створювати діалогове вікно для вас.

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

    itemId = _itemId;
    return itemId;
}

Сервіс

Клас сервісу – це клас, який містить фактичну бізнес-логіку. Він не займається відображенням діалогів, пакетною обробкою чи чимось подібним – це відповідальність класу контролера. Відокремивши його, ви з більшою ймовірністю зможете добре спроектувати свій код та створити більше коду для повторного використання.

Як і клас контракту даних, клас сервісу не потребує успадкування від чогось конкретного, але він повинен успадковуватися від класу SysOperationServiceBase, принаймні, якщо ви очікуєте, що сервіс буде запущено як пакетне завдання, оскільки суперклас надає певну інформацію про пакетний контекст. Метод, який запускає операцію (тобто запускає бізнес-логіку), повинен приймати об'єкт вашого класу контракту даних як вхідні дані та має бути оформлений за допомогою [SysEntryPointAttribute]. Наприклад:

class MyService extends SysOperationServiceBase
{
}

За допомогою методу під назвою run:

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

Контролер

Клас контролера керує виконанням та пакетною обробкою вашої операції. Він також гарантує, що код виконується в CIL для максимальної продуктивності. Клас контролера зазвичай успадковується від класу SysOperationServiceController, хоча є й інші варіанти.

class MyController extends SysOperationServiceController
{
}

Конструктор суперкласу приймає як параметри назву класу, назву методу та (необов'язково) режим виконання. Назви класу та методу повинні бути назвою вашого класу служби та методу, який має бути запущений на ньому. Отже, ви можете реалізувати метод конструкції вашого контролера так:

public static MyController construct()
{
    ;

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

Тоді головний метод класу MyController може бути таким простим, як

public static void main(Args _args)
{
    ;

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

І ви, в принципі, закінчили. Вищезазначений приклад, очевидно, дуже простий, і фреймворк містить безліч інших опцій та можливостей, але це служить для короткого огляду, якщо вам потрібно освіжити свої знання, коли ви деякий час не користувалися фреймворком.

Додаткова література

Якщо вам сподобався цей пост, вам також можуть сподобатися ці пропозиції: