Azure Service Bus и Dynamics 365 for Operations

[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.

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