Azure Service Bus и Dynamics 365 for Operations

[MazZzDaI]

Помогите найти материал по теме интеграции Dynamics 365 for Operations используя Azure Service Bus.
Для Dynamics 365 CRM есть здесь
Для AX2012 есть тут и тут
Для Dynamics 365 for Operations есть только описание прямой интеграции, но используя Service Bus не могу найти

[mnt_dx]

А что с чем интегрировать хотите? Для д365фо есть MS Flow, который много с чем может интегрировать АХ.

[vmoskalenko]

Я сейчас делаю интеграцию AX7 <--> CRM на базе MS Flow.
Еще и через Common Data Model (CDM). Т.е. AX7 <--> CDM <--> CRM

Кроме этого CDM хорошо подходит для
* таблиц маппинга данных AX7 и CRM
* таблиц обнаружения новых записей в AX7 (из-за отсутствия триггеров)

Использовать Azure Service Bus вижу смысл только для того чтобы избегать "детских" багов в MS Flow (баг Set variable, Nested loops возможно другие, еще не изведанные баги).

Но основная беда - это отсутствие триггеров в MS Flow для Dynamics 365 for Operations Connector.

[MazZzDaI]

Microsoft Flow отлично подходит для интеграции. Но таки реализовал механизм взаимодействия AX7 и Azure Service Bus. Ссылка на GitHub

[vmoskalenko]

И как эта штука работает на практике?

AX генерирует сообщение в Azure Service Bus когда что-то поменялось в одной из её ДатаЭнтити?

Flow триггерится когда приходит новое сообщение в Azure Service Bus?
Потом Flow парсит данные из сообщения (JSON) и запихивает данные в CRM?

[MazZzDaI]

Flow пока не умеет ловить события D365fO, как ты раньше и сказал, поэтому для решения этой задачи (как одной из N) я использую вышеизложенный класс для:

Цитата:

D365fO -> ServiceBus -> Flow (triggered) -> CRM (или любая другая система)

или так

Цитата:

D365fO -> ServiceBus -> любая система читает сообщение из очереди

или так

Цитата:

Любая система -> ServiceBus -> D365fO читает сообщение из очереди

Через Serivce Bus возможно передавать не только JSON, но и Binary, и даже стримить.

[ax_mct]

Цитата:

Сообщение от MazZzDaI

Flow пока не умеет ловить события D365fO, как ты раньше и сказал, поэтому для решения этой задачи (как одной из N) я использую вышеизложенный класс для:

или так

или так


Через Serivce Bus возможно передавать не только JSON, но и Binary, и даже стримить.

Уверен что важнее новый технический навык - четкое понимание сколько та или иная реализация будет стоить в зависимости от типа и объема и еше и еще... Я тупо запутался.
Не поделитесь расчетами?
https://azure.microsoft.com/en-us/pr...s/service-bus/

[trud]

Цитата:

Сообщение от MazZzDaI

Но таки реализовал механизм взаимодействия AX7 и Azure Service Bus

Спасибо за проект
еще вопрос - а какие были причины выбора Service Bus? т.е. можно ли добиться того же самого используя к примеру SQL Azure(как типизированное хранилище) и создав там свои таблицы для интеграции(соответственно какие-то системы будут писать данные в эти таблицы, какие-то читать)

[vmoskalenko]

Цитата:

Сообщение от ax_mct

Не поделитесь расчетами?
https://azure.microsoft.com/en-us/pr...s/service-bus/

Для задачи Интеграции CRM - AX у нас в качестве сообщений будет новые записи в ДатаЭнтити или изменённые записи в ДатаЭнтити.
Предположим, что за 1 день таких сообщений будет 100.
За 1 месяц - 3000 шт.

Берем STANDARD.

Абоплата - 10 USD/mo
Включено в абонплату - 1000 сообщений - 0 USD/mo
Сверх абонплаты - 2000 сообщений - 0.03 USD * 2000 = 60 USD/mo

Итого, 70 USD/mo примерно.
(Или в разы меньше если я не разобрался с brokered connections)

[vmoskalenko]

Цитата:

Сообщение от trud

Спасибо за проект
еще вопрос - а какие были причины выбора Service Bus? т.е. можно ли добиться того же самого используя к примеру SQL Azure(как типизированное хранилище) и создав там свои таблицы для интеграции(соответственно какие-то системы будут писать данные в эти таблицы, какие-то читать)

В моём случае, интеграция AX с CRM , я рассматривал седующие компоненты
* Azure Service Bus - хорошее решение, немного денег стоит, но имеет триггеры в Flow
* Azure SQL - не имеет тригеров в Flow, стоимость около 15 USD/mo, если раз в месяц удалять все ненужное и держать БД в минимальном размере.
* CDS (Common Data Services) - даже бесплатно (включено в стоимость подписки D365Op) имеет свою БД, имеет триггеры. Скорее всего буду импользовать для маппинга значений между AX и CRM. Или в AX свои таблички напишу - еще не решил.

[trud]

Цитата:

Сообщение от vmoskalenko

* Azure SQL - не имеет тригеров в Flow, стоимость около 15 USD/mo, если раз в месяц удалять все ненужное и держать БД в минимальном размере.
* CDS (Common Data Services) - даже бесплатно (включено в стоимость подписки D365Op) имеет свою БД, имеет триггеры

судя по сайту Azure SQL за 15 USD/mo вы получите 250GB. этого вроде бы должно быть достаточно с запасом
с CDS - вы уверены что нет ограничений? на сайте есть кнопка - редактировать в Excel - который не поддерживает больше 1млн строк как это будет работать?
также к примеру непонятно как сделать бекап базы CDS. или если что-то случилось, как восстановить базу CDS на заданное время.
т.е. эти вопросы возникли при ближайшем рассмотрении

[ax_mct]

Цитата:

Сообщение от vmoskalenko

Для задачи Интеграции CRM - AX у нас в качестве сообщений будет новые записи в ДатаЭнтити или изменённые записи в ДатаЭнтити.
Предположим, что за 1 день таких сообщений будет 100.
За 1 месяц - 3000 шт.

Берем STANDARD.

Абоплата - 10 USD/mo
Включено в абонплату - 1000 сообщений - 0 USD/mo
Сверх абонплаты - 2000 сообщений - 0.03 USD * 2000 = 60 USD/mo

Итого, 70 USD/mo примерно.
(Или в разы меньше если я не разобрался с brokered connections)

Присоединяюсь к вопросу причин выбора.
Смущает то что это не готовое решение за использование которого мы платим, избегая программирования, а платный компонент (как некое платное и закрытое DLL) в процессе программирования.
Смущает то что невозможно просчитать стоимость решения даже в перспективе 1- 3 года.
Я не нашел конкретных terms про изменение расценок https://azure.microsoft.com/en-gb/pr...s/service-bus/ поэтому вопрос к вам к человеку который выбрал этот компонент -
- может ли Microsoft изменить расценки?
- возможность и стоимость отказа от этого компонента, если он по каким-то причинам не устраивает?

Цитата:

Сообщение от trud

Спасибо за проект
еще вопрос - а какие были причины выбора Service Bus? т.е. можно ли добиться того же самого используя к примеру SQL Azure(как типизированное хранилище) и создав там свои таблицы для интеграции(соответственно какие-то системы будут писать данные в эти таблицы, какие-то читать)

[vmoskalenko]

Цитата:

Сообщение от trud

судя по сайту Azure SQL за 15 USD/mo вы получите 250GB. этого вроде бы должно быть достаточно с запасом

250КБайт - это размер одного сообщения.
В моем случае, это JSON или XML текст одной записи из ДатаЭнтити. Думаю, что если не заморачиваться на МЕМО поля, то должно хватить с головой.
Иначе, передавать ссылку на какой-то большой объект, например в Azure Blob Storage

Цитата:

с CDS - вы уверены что нет ограничений? на сайте есть кнопка - редактировать в Excel - который не поддерживает больше 1млн строк как это будет работать?
также к примеру непонятно как сделать бекап базы CDS. или если что-то случилось, как восстановить базу CDS на заданное время.
т.е. эти вопросы возникли при ближайшем рассмотрении

Хорошие вопросы. Но сама Flow имеет куда большие ограничения. Но для задачи *интеграции* между системами подходит.

Относительно бекапов CDS - я так понял что их просто нет. Наверное можно сервис запрос написать в Майкрософт на восстановление. Или скрипт какой-то написать который каждую ночь будет делать экспорт во внешний файл.

[vmoskalenko]

Цитата:

Сообщение от ax_mct

Присоединяюсь к вопросу причин выбора.

Причина выбора простая - мало альтернатив которые из коробки работают с D365Op. Flow он же LogicApp и вобщем-то все.

Цитата:

Смущает то что это не готовое решение за использование которого мы платим, избегая программирования, а платный компонент (как некое платное и закрытое DLL) в процессе программирования.
Смущает то что невозможно просчитать стоимость решения даже в перспективе 1- 3 года.
Я не нашел конкретных terms про изменение расценок https://azure.microsoft.com/en-gb/pr...s/service-bus/ поэтому вопрос к вам к человеку который выбрал этот компонент -
- может ли Microsoft изменить расценки?
- возможность и стоимость отказа от этого компонента, если он по каким-то причинам не устраивает?

На практике, Майкрософт меняет расценки достаточно регулярно. На VM он расценки снижает, а некоторые сервисы - поднимает. Альтернативы?
Кстати есть альтернативы. И подороже. Но как обычно, D365Op connector на чтение/запись есть потому что ODATA, а вот чтобы триггер был - скорее всего не будет такого.

Могу сказать, что Azure сервисы - это более документированная штука чем чья-то DLL с гитхаба.

Раньше вот был BizTalk сервер. Сейчас Майкрософт его деаннсировал и предложил замену в виде сервисов Azure - Service Bus, Logic App, Azure Functions,...

Теперь ты не платишь за лицензию один раз и навсегда (а на самом деле на 3-5 лет). Сейчас ты платишь ежемесячно за то что используешь. Нужны большие мощности - PREMIUM, нужен маленький проект - BASIC.

[ax_mct]

Цитата:

Сообщение от vmoskalenko

Причина выбора простая - мало альтернатив которые из коробки работают с D365Op. Flow он же LogicApp и вобщем-то все.



На практике, Майкрософт меняет расценки достаточно регулярно. На VM он расценки снижает, а некоторые сервисы - поднимает. Альтернативы?
Кстати есть альтернативы. И подороже. Но как обычно, D365Op connector на чтение/запись есть потому что ODATA, а вот чтобы триггер был - скорее всего не будет такого.

Могу сказать, что Azure сервисы - это более документированная штука чем чья-то DLL с гитхаба.

Раньше вот был BizTalk сервер. Сейчас Майкрософт его деаннсировал и предложил замену в виде сервисов Azure - Service Bus, Logic App, Azure Functions,...

Теперь ты не платишь за лицензию один раз и навсегда (а на самом деле на 3-5 лет). Сейчас ты платишь ежемесячно за то что используешь. Нужны большие мощности - PREMIUM, нужен маленький проект - BASIC.

Спасибо. Хорошая и понятная мысль. Раньше был BizTalk за скажем $10,000 за продукт, а сейчас "pay as you go" к примеру $100 в месяц за некий сервис. Ждем Visual Studio c оплатой за количество скомпилированных строк кода

Альтернативы? На двух концах этого обмена - MS SQL Server, не так ли? AX7 и CRM. И замены на NoSQL или файловую систему не предвидится, не так ли? Самое разумное решение использовать интеграцию на уровне баз данных.

[trud]

Цитата:

Сообщение от ax_mct

И замены на NoSQL или файловую систему не предвидится, не так ли?

а что не так с файловой системой? т.е. для варианта локальная программа и облачная АХ вполне подойдет Azure storage, который мапится как диск в Windows а в АХ можно написать пакетное задание которое будет читать или писать эти файлы. Микрософт правда это считает примером "неправильной" архитектуры, они предлагаю использовать промежуточный апп для этого
https://blogs.msdn.microsoft.com/axs...or-operations/

[vmoskalenko]

Цитата:

Сообщение от ax_mct

Альтернативы? На двух концах этого обмена - MS SQL Server, не так ли? AX7 и CRM. И замены на NoSQL или файловую систему не предвидится, не так ли? Самое разумное решение использовать интеграцию на уровне баз данных.

Не разумное решение. Уровней абстракций не хватает. Даже через файлики смотрится лучше. Особенно если файлики будут XML или JSON формата.

1. Структура БД разная. Даже в рамках Аксапты она может меняться от версии к версии. - Для этого хорошо подходят ДатаЭнтити.

2. Промежуточный слой. Одна из систем может не работать (обновляется например) А другая отсылает изменения. SQL требует транзакционности. Вот уже и лишняя табличка появилась.... В SQL конечно есть Service Broker но... это уже как бы не чистый SQL. Service Bus принимает сообщение от одной системы и хранит его пока не вторая не заберет это сообщение.

3. Версии SQL разные. MS SQL и Azure SQL таки отличаются

4. Добавляется новое поле. Что делаем? Сколько часов тратим?

[macklakov]

Цитата:

Сообщение от vmoskalenko

Не разумное решение. Уровней абстракций не хватает. Даже через файлики смотрится лучше. Особенно если файлики будут XML или JSON формата.

Да ладно! Модули внутри AX без всяких XML или JSON обходятся прекрасно. В случае когда и CRM и AX в одном и том же облаке, они могут прозрачно интегрироваться через шаренные view. Зачем этот overhead в виде сервисов?
Выставили свои данные в виде view, и шлите друг другу сообщения в смысле "я там только что клиента нового создала", "я тебя услышала, клиента вижу". Быстродействие при этом несопоставимое с любой реализацией пересылки данных через web services.
Все эти универсальные связки через ESB и сервисы лучше всего отрабатывают когда есть открытый протокол. К примеру, универсальный протокол CRM 2 ERP. В этом случае обе стороны интеграции взаимозаменяемые. Хочешь цепляешь AX к MS CRM, а хочешь к SalesForce который живет в совсем других "облаках".
А если у тебя интеграция 1 к 1, продукты одного производителя, в одном и том же облаке, в одном и том же .net и на одной и той же базе, то все эти выкрутасы это не более чем наработка новомодных записей в резюме за счет работодателя.

[AlexeyS]

Цитата:

Сообщение от macklakov

Да ладно! Модули внутри AX без всяких XML или JSON обходятся прекрасно. В случае когда и CRM и AX в одном и том же облаке, они могут прозрачно интегрироваться через шаренные view. Зачем этот overhead в виде сервисов?
Выставили свои данные в виде view, и шлите друг другу сообщения в смысле "я там только что клиента нового создала", "я тебя услышала, клиента вижу". Быстродействие при этом несопоставимое с любой реализацией пересылки данных через web services.

Схема всем хороша, только в ней не учтен еще один стейкхолдер.
Дополнительный посредник, который за небольшую денежку будет принимать и отправлять данные, которыми вы обмениваетесь