Краткий обзор Dynamics AX 2012 SysOperation Framework

Опубликовано: 15 февраля 2025 г. в 22:35:39 UTC
Последнее обновление: 12 января 2026 г. в 08:39:05 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();
}

И на этом, по сути, всё. Приведённый выше пример, очевидно, очень простой, и фреймворк содержит множество других опций и возможностей, но это служит кратким обзором, если вам нужно освежить знания, если вы давно не использовали этот фреймворк.

Дополнительное чтение

Если вам понравился этот пост, вам также могут понравиться эти предложения:


Поделиться на BlueskyПоделиться на FacebookПоделиться на LinkedInПоделиться на TumblrПоделиться на XЗакрепить на PinterestПоделиться на Reddit

Миккель Кристенсен

Об авторе

Миккель Кристенсен
Миккель - создатель и владелец сайта miklix.com. Он имеет более чем 20-летний опыт работы в качестве профессионального программиста/разработчика программного обеспечения и в настоящее время работает на полную ставку в крупной европейской IT-корпорации. Когда он не ведет блог, то тратит свое свободное время на огромное количество интересов, хобби и занятий, что в некоторой степени отражается в разнообразии тем, освещаемых на этом сайте.