AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.05.2017, 16:57   #1  
MazZzDaI is offline
MazZzDaI
Участник
Аватар для MazZzDaI
 
40 / 26 (1) +++
Регистрация: 19.09.2013
Адрес: Украина, Одесса
Azure Service Bus и Dynamics 365 for Operations
Помогите найти материал по теме интеграции Dynamics 365 for Operations используя Azure Service Bus.
Для Dynamics 365 CRM есть здесь
Для AX2012 есть тут и тут
Для Dynamics 365 for Operations есть только описание прямой интеграции, но используя Service Bus не могу найти
Старый 28.05.2017, 18:38   #2  
mnt_dx is offline
mnt_dx
Участник
Axapta Retail User
Лучший по профессии 2014
 
1,599 / 175 (9) ++++++
Регистрация: 17.02.2011
Адрес: К Северу через Северо-Запад
А что с чем интегрировать хотите? Для д365фо есть MS Flow, который много с чем может интегрировать АХ.
Старый 08.06.2017, 22:19   #3  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
26 / 48 (2) +++
Регистрация: 25.01.2007
Адрес: Kiev
Я сейчас делаю интеграцию 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.
Старый 12.07.2017, 09:15   #4  
MazZzDaI is offline
MazZzDaI
Участник
Аватар для MazZzDaI
 
40 / 26 (1) +++
Регистрация: 19.09.2013
Адрес: Украина, Одесса
Microsoft Flow отлично подходит для интеграции. Но таки реализовал механизм взаимодействия AX7 и Azure Service Bus. Ссылка на GitHub
За это сообщение автора поблагодарили: trud (3).
Старый 12.07.2017, 12:19   #5  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
26 / 48 (2) +++
Регистрация: 25.01.2007
Адрес: Kiev
И как эта штука работает на практике?

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

Flow триггерится когда приходит новое сообщение в Azure Service Bus?
Потом Flow парсит данные из сообщения (JSON) и запихивает данные в CRM?
Старый 12.07.2017, 13:08   #6  
MazZzDaI is offline
MazZzDaI
Участник
Аватар для MazZzDaI
 
40 / 26 (1) +++
Регистрация: 19.09.2013
Адрес: Украина, Одесса
Flow пока не умеет ловить события D365fO, как ты раньше и сказал, поэтому для решения этой задачи (как одной из N) я использую вышеизложенный класс для:
Цитата:
D365fO -> ServiceBus -> Flow (triggered) -> CRM (или любая другая система)
или так
Цитата:
D365fO -> ServiceBus -> любая система читает сообщение из очереди
или так
Цитата:
Любая система -> ServiceBus -> D365fO читает сообщение из очереди
Через Serivce Bus возможно передавать не только JSON, но и Binary, и даже стримить.
Старый 12.07.2017, 19:10   #7  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,683 / 531 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от MazZzDaI Посмотреть сообщение
Flow пока не умеет ловить события D365fO, как ты раньше и сказал, поэтому для решения этой задачи (как одной из N) я использую вышеизложенный класс для:

или так

или так


Через Serivce Bus возможно передавать не только JSON, но и Binary, и даже стримить.
Уверен что важнее новый технический навык - четкое понимание сколько та или иная реализация будет стоить в зависимости от типа и объема и еше и еще... Я тупо запутался.
Не поделитесь расчетами?
https://azure.microsoft.com/en-us/pr...s/service-bus/
За это сообщение автора поблагодарили: macklakov (5).
Старый 13.07.2017, 07:34   #8  
trud is offline
trud
Участник
 
455 / 324 (11) ++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от MazZzDaI Посмотреть сообщение
Но таки реализовал механизм взаимодействия AX7 и Azure Service Bus
Спасибо за проект
еще вопрос - а какие были причины выбора Service Bus? т.е. можно ли добиться того же самого используя к примеру SQL Azure(как типизированное хранилище) и создав там свои таблицы для интеграции(соответственно какие-то системы будут писать данные в эти таблицы, какие-то читать)
За это сообщение автора поблагодарили: ax_mct (5).
Старый 13.07.2017, 10:29   #9  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
26 / 48 (2) +++
Регистрация: 25.01.2007
Адрес: Kiev
Red face
Цитата:
Сообщение от 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)
За это сообщение автора поблагодарили: ax_mct (5).
Старый 13.07.2017, 10:35   #10  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
26 / 48 (2) +++
Регистрация: 25.01.2007
Адрес: Kiev
Цитата:
Сообщение от 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 свои таблички напишу - еще не решил.
За это сообщение автора поблагодарили: macklakov (5).
Старый 13.07.2017, 15:41   #11  
trud is offline
trud
Участник
 
455 / 324 (11) ++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от vmoskalenko Посмотреть сообщение
* Azure SQL - не имеет тригеров в Flow, стоимость около 15 USD/mo, если раз в месяц удалять все ненужное и держать БД в минимальном размере.
* CDS (Common Data Services) - даже бесплатно (включено в стоимость подписки D365Op) имеет свою БД, имеет триггеры
судя по сайту Azure SQL за 15 USD/mo вы получите 250GB. этого вроде бы должно быть достаточно с запасом
с CDS - вы уверены что нет ограничений? на сайте есть кнопка - редактировать в Excel - который не поддерживает больше 1млн строк как это будет работать?
также к примеру непонятно как сделать бекап базы CDS. или если что-то случилось, как восстановить базу CDS на заданное время.
т.е. эти вопросы возникли при ближайшем рассмотрении
Старый 13.07.2017, 16:16   #12  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,683 / 531 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от 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(как типизированное хранилище) и создав там свои таблицы для интеграции(соответственно какие-то системы будут писать данные в эти таблицы, какие-то читать)
Старый 13.07.2017, 19:35   #13  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
26 / 48 (2) +++
Регистрация: 25.01.2007
Адрес: Kiev
Цитата:
Сообщение от trud Посмотреть сообщение
судя по сайту Azure SQL за 15 USD/mo вы получите 250GB. этого вроде бы должно быть достаточно с запасом
250КБайт - это размер одного сообщения.
В моем случае, это JSON или XML текст одной записи из ДатаЭнтити. Думаю, что если не заморачиваться на МЕМО поля, то должно хватить с головой.
Иначе, передавать ссылку на какой-то большой объект, например в Azure Blob Storage

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

Относительно бекапов CDS - я так понял что их просто нет. Наверное можно сервис запрос написать в Майкрософт на восстановление. Или скрипт какой-то написать который каждую ночь будет делать экспорт во внешний файл.
Старый 13.07.2017, 19:47   #14  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
26 / 48 (2) +++
Регистрация: 25.01.2007
Адрес: Kiev
Цитата:
Сообщение от 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.
Старый 13.07.2017, 21:37   #15  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
1,683 / 531 (21) +++++++
Регистрация: 10.10.2005
Адрес: PHP
Цитата:
Сообщение от 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 или файловую систему не предвидится, не так ли? Самое разумное решение использовать интеграцию на уровне баз данных.
Старый 14.07.2017, 08:04   #16  
trud is offline
trud
Участник
 
455 / 324 (11) ++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от ax_mct Посмотреть сообщение
И замены на NoSQL или файловую систему не предвидится, не так ли?
а что не так с файловой системой? т.е. для варианта локальная программа и облачная АХ вполне подойдет Azure storage, который мапится как диск в Windows а в АХ можно написать пакетное задание которое будет читать или писать эти файлы. Микрософт правда это считает примером "неправильной" архитектуры, они предлагаю использовать промежуточный апп для этого
https://blogs.msdn.microsoft.com/axs...or-operations/
Старый 14.07.2017, 09:42   #17  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
26 / 48 (2) +++
Регистрация: 25.01.2007
Адрес: Kiev
Цитата:
Сообщение от 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. Добавляется новое поле. Что делаем? Сколько часов тратим?
Старый 14.07.2017, 10:16   #18  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 874 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от vmoskalenko Посмотреть сообщение
Не разумное решение. Уровней абстракций не хватает. Даже через файлики смотрится лучше. Особенно если файлики будут XML или JSON формата.
Да ладно! Модули внутри AX без всяких XML или JSON обходятся прекрасно. В случае когда и CRM и AX в одном и том же облаке, они могут прозрачно интегрироваться через шаренные view. Зачем этот overhead в виде сервисов?
Выставили свои данные в виде view, и шлите друг другу сообщения в смысле "я там только что клиента нового создала", "я тебя услышала, клиента вижу". Быстродействие при этом несопоставимое с любой реализацией пересылки данных через web services.
Все эти универсальные связки через ESB и сервисы лучше всего отрабатывают когда есть открытый протокол. К примеру, универсальный протокол CRM 2 ERP. В этом случае обе стороны интеграции взаимозаменяемые. Хочешь цепляешь AX к MS CRM, а хочешь к SalesForce который живет в совсем других "облаках".
А если у тебя интеграция 1 к 1, продукты одного производителя, в одном и том же облаке, в одном и том же .net и на одной и той же базе, то все эти выкрутасы это не более чем наработка новомодных записей в резюме за счет работодателя.
__________________
Isn't it nice when things just work?
За это сообщение автора поблагодарили: ax_mct (10).
Старый 14.07.2017, 11:46   #19  
AlexeyS is offline
AlexeyS
Участник
 
324 / 222 (8) ++++++
Регистрация: 15.06.2004
Адрес: москва
Цитата:
Сообщение от macklakov Посмотреть сообщение
Да ладно! Модули внутри AX без всяких XML или JSON обходятся прекрасно. В случае когда и CRM и AX в одном и том же облаке, они могут прозрачно интегрироваться через шаренные view. Зачем этот overhead в виде сервисов?
Выставили свои данные в виде view, и шлите друг другу сообщения в смысле "я там только что клиента нового создала", "я тебя услышала, клиента вижу". Быстродействие при этом несопоставимое с любой реализацией пересылки данных через web services.
Схема всем хороша, только в ней не учтен еще один стейкхолдер.
Дополнительный посредник, который за небольшую денежку будет принимать и отправлять данные, которыми вы обмениваетесь
За это сообщение автора поблагодарили: vmoskalenko (1).
Теги
azure service bus, d365o, интеграция

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
stoneridgesoftware: Dynamics 365 Roadmap, Readiness and License Renewal – What You Need to Know Blog bot DAX Blogs 0 16.03.2017 00:14
atinkerersnotebook: Creating New Customer Notifications for Dynamics 365 for Operations using Flow and the Common Data Service Blog bot DAX Blogs 0 15.12.2016 22:12
stoneridgesoftware: Microsoft Dynamics 365 – Right around the Corner Blog bot DAX Blogs 0 10.10.2016 21:13
Hotfix 2845539 is available to provide an AIF Windows Azure Service Bus Adapter for services in Microsoft Dynamics AX 2012 R2 Vadik DAX: База знаний и проекты 0 31.05.2013 11:11
Dynamics AX: WCF: The Enterprise Service Bus for Dynamics AX and the rest of the Microsoft Stack Blog bot DAX Blogs 0 10.03.2009 16:05
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 15:41.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.