Dynamics AX 2012. Произвольные службы

В современном мире головной системе управления предприятием требуется взаимодействовать со множеством внешних приложений. Для этого необходимо, чтобы система управления могла реализовывать произвольные службы интеграции, посредством которых будет происходит обмен данными и выполняться необходимые действия. Для большинства бизнес-процессов требуется доступ внешних приложений к информации, хранимой в Dynamics AX 2012. Ниже представлены несколько сценариев, в которых различные пользователи обращаются к информации, для выполнения задач. А также показаны примеры, когда Dynamics AX обращается к внешним приложениям. Направление доступа указано стрелками.

На схеме видно, как с левой стороны приложения обращаются к Dynamics AX, а с правой стороны, приложения, к которым обращается Dynamics AX. Вручную такие операции могут привести к появлению ошибок и требовать много времени. С использованием инфраструктуры служб Dynamics AX, можно поместить логику бизнес-процесса в службу и опубликовать ее. Инфраструктура служб Microsoft
предлагает набор инструментов для создания, управления, настройки и публикации служб Microsoft
Dynamics
AX, позволяя легко предоставить внешним приложениям бизнес-логику, реализуемую службами через их интерфейсы.

В AX 2012 различают три вида служб:

Служебные.
Произвольные.
Службы документов.

Contents

1 Произвольные службы
2 Класс реализации службы
3 Контракты служб
4 Контракт данных
5 Коллекции X++ как контракты данных
6 Регистрация службы

Произвольные службы

Произвольные службы используются для публикации необходимых методов Х++ посредствам портов интеграции. Для реализации этого вам потребуется использовать модель разработки произвольных служб, чтобы определить метаданные, задающие вид публикуемых действий служб и контрактов данных. Произвольные службы необязательно должны сопоставляться с какими-либо запросами или таблицами.

Для создания произвольной службы, требуется создать следующие классы:

Класс, реализующий службу — класс, реализующий бизнес-логику, доступную через методы Х++;
Контракт службы – относящиеся к службе метаданные (не код). Публикуются действия службы, для использования внешними приложениями и ссылки на класс Х++ реализации службы, в котором и реализованы действия службы.
Один или несколько контрактов данных – класс Х++, представляющий сложные типы параметров действий службы. Контракт данных для простых типов данных не используется.

Класс реализации службы

В этом классе содержится код, выполняющий публикуемую бизнес-логику. Таким классом может быть любой класс Х++. Он не обязан наследоваться от другого специального класса или реализовывать какие-либо интерфейсы. Пример класса представлен ниже.

public class ProstoService
{
}

Но существует ограничение, которое должно выполняться для методов класса реализации службы, которые будут опубликованы как действия службы. Такие методы должны иметь модификатор доступа public и принимать параметры типов, которые могут быть сериализованы и десериализованы. Сюда входит большая часть простых типов данных и корректные контракты данных. Также такие методы должны быть объявлены, как действия служб в контракте службы в АОТ. Ниже приведен пример метода, который может быть объявлен в АОТ как действие службы.

[SysEntryPointAttribute(true)]
public boolean HelloWorld(Name _name)
{
    boolean retVal;

    if (_name)
    {
        reVal = true;
    }

    return retVal;
}

Каждый метод, который будет опубликован как действие службы, должен быть отмечен атрибутом SysEntryPointAttribute, который указывает, что сервером приложений должны быть проведены проверки контроля доступа.

Контракты служб

Контракты служб определяют, какие методы класса реализации службы будут опубликованы как действия службы и содержат дополнительную информацию, указывающую, как эти методы будут опубликованы.

Чтобы создать новый контракт службы, требуется создать новый дочерний узел в АОТ, под узлом Services и назвать его, например, ProstoService.

Новый узел имеет несколько свойств, которые необходимо заполнить, перед публикацией методов, как действий:

Service implementation class – требуется указать класс службы, в примере это будет ProstoService. Данное свойство связывает интерфейс службы с классом ее реализации.
Namespace – можно указать пространство имен XML, которое будет использовано в WDSL. Если свойство не задано, то будет использоваться значение по умолчанию http://tempuri.org. В примере используется пространство имен http://schemas.contoso.com/ax-book/2012/services.
External name – можно задать внешнее имя каждой службе.

Далее необходимо добавить действия службы в контракт. Для этого необходимо раскрыть созданный узел в АОТ, затем в контекстом меню выбрать Operations – Добавить Operation. Опубликованы будут только те действия, которые были добавлены в контракт службы в АОТ.

Контракт данных

Контракт данных – это сложный тип данных Х++. Контракт может использоваться как в качестве входного параметра в методе, так и в качестве его результата. Необходимо создавать сериализуемый контракт. Чтобы класс определялся как контракт данных, необходимо в методе ClassDeclaration указать атрибут DataContractAttribute. А для параметров использовать атрибут DataMemeberAttribute. С помощью данных атрибутов можно управлять упаковкой и распаковкой контракта. Получается, что:

DataContractAttribute — объявляет класс X++ как контракт данных.
DataMemberAttribute — объявляет атрибут класса свойством контракта данных.

Ниже представлен пример контракта.

[DataContractAttribute]
public class ProstoDataContract
{
    int intParm;
    str strParm;
}

А следующий код показывает объявление свойства, включаемого в контракт данных:

[DataMemberAttribute]
public int parmInt(int _intParm = intParm)
{
    intParm = _intParm;

    return intParm;
}

Коллекции X++ как контракты данных

Если требуется использовать коллекции в качестве контракта данных, то требуется обеспечить, что все элементы коллекции могут быть сериализованы. Кроме того, необходимо в процессе разработки задать дополнительные метаданные на определении метода службы, использующего параметр, которые укажут точный тип данных значений в коллекции. Это можно сделать с помощью X++ атрибута AifCollectionTypeAttribute. Пример ниже показывает его использование.

[SysEntryPointAttribute(true),
AifCollectionTypeAttribute('_listParm ', Types::Integer)]
public void useListParm(List _listParm)
{
}

Два параметра, которые нужно передать конструктору атрибутов – это имя параметра, которому будут присвоены метаданные, в примере это _listParm, и тип элементов в коллекции, в примере это Types::Integer.

Если в коллекции в качестве типа элемента будет использоваться класс, то необходимо добавить еще один параметр, имя класса. Пример ниже.

[SysEntryPointAttribute(true),
AifCollectionTypeAttribute('_listParm ', Types::Class, classStr(ProstoDataContract))]
public void useListParm(List _listParm)
{
}

Если метод будет возвращать результат в качестве коллекции, то метаданные будут выглядеть, как в примере.

[SysEntryPointAttribute(true),
AifCollectionTypeAttribute('return', Types::Class, classStr(ProstoDataContract))]
public List getList(int _i)
{
}

Три параметра, переданные в конструктор AifCollectionAttribute: имя параметра — return, тип элементов в коллекции — Types::Class и указанное имя класса — ProstoDataContract. Зарезервированное название параметра return закреплено за возвращаемым значением метода.

Регистрация службы

После создания всех необходимых классов и настройки элементов в АОТ, требуется зарегистрировать службу. Для регистрации службы, необходимо на созданном контракте службы ProstoService открыть контекстное меню и выбрать Настройки – Регистрация услуг. После регистрации появиться возможность публикации действий службы.

microsoft.com