Интеграция - использовать стандарт или писать на коленке ?

[Jackally]

Цитата:

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

DMF не подходит хотя бы из-за требования проверять отдельно каждое значение и показывать это в удобной форме. Опять таки в DMF entity надо еще положить данные что требует значительных усилий и при этом все равно на пол-пути в полосе препятствий.

Полностью согласен, этой проблеме 10тки лет, будеть это DMF, DIXF, AIF и т.п. (не дай бог 3rd party решение Connectivity Studio кому-то попробовать). Собственное решение разработанное под конкретного клиента значительно проще поддерживать и развивать. Золотой пули тут нет, выбирать надо от ряда условий, в том числи "политических".

Цитата:

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

Опции интеграции с использованием Azure они прекрасны, но есть ли смысл для бизнеса так зависеть от конкретного облака? Даже в FO можно послать email. Можно записывать сообщение в свою таблицу/базу (P.S. класть в FTP папку) как триггер для внешней системы. Как бы проще и надежнее, а по факту то же самое.

Вот прочитал вашу ссылку
Storage queues and Service Bus queues - compared and contrasted
https://docs.microsoft.com/en-us/azu...ity-and-quotas
Мне просто страшно такое использовать для любой интеграции. Контроля - нет. Как за такое отвечать перед клиентом?

MaaS это прекрасно но тот же SMTP mail server в AX покрывает потребности бизнеса только так.
https://docs.microsoft.com/en-us/dyn...ft-dynamics-ax

Можно сообщение и файл, да. Держать поднятую целую машину ради Windows Scheduler который по рассписанию будет разбирать файлики, тоже можно. Без шуток, главное что бы работало и никому не мешало =)
Я слышал про интеграции через Mail Server, но честно скажу опыта не было, не могу сказать про +/-. На сколько это управляемо и расширяемо при увеличении нагрузки?

На счёт ответственности, в общем и целом так и есть, MS не отвечает ни за один облачный сервис в частности. Они дают МОЛОТОК, а дальше можно всё к чертям разнести, а можно сколотить что-то приличное. Они дают SLA на каждый сервис, кол-во 9ок в год. Дальше нужно с головой подходить и понимать где нужна репликация, где бэкапирование, где Auto Scaling и т.п. Собираешь отказоустойчивое решение из конструктора.
Если на конкретном клиенте уже есть какое-то MSMQ решение, то наверное его и стоит использовать.
Если клиент боится Vendor-Locked, можно предложить поднять Kafka на виртуалке (IaaS).
Если под кjнтролем вы понимаете мониторинг, нет нет ничего лучше чем просто попробовать, благо есть пошаговые гайды, на весь пример что бы поиграться, это займёт не больше часа:
https://docs.microsoft.com/en-us/azu...ed-with-queues

SaaS и PaaS, и прочие не IaaS и всё-таки в первую очередь экономят деньги, дальше уже думать всё взвешивать и принимать решение.

[ax_mct]

Цитата:

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

Ну, Azure - это не продукт, а платформа. Программе в облаке говорить с программой в облаке конечно проще. Такие монстры как Document routing agent, работают, конечно менее стабильно.

Почему не понадобится? Известить внешний склад (3rd party logistics) о том, что отгрузка готова - это совершенно типичная задача. Никакого альтернативного мира, а вполне себе реальная рутина.

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

Для того чтобы оповестить внешний склад не нужно Azure. Как и этому складу Azure не нужен.
Email, FTP, REST/SOAP.

Цитата:

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

Я слышал про интеграции через Mail Server, но честно скажу опыта не было, не могу сказать про +/-. На сколько это управляемо и расширяемо при увеличении нагрузки?
..
Если под кjнтролем вы понимаете мониторинг, нет нет ничего лучше чем просто попробовать
...
SaaS и PaaS, и прочие не IaaS и всё-таки в первую очередь экономят деньги, дальше уже думать всё взвешивать и принимать решение.

Mail Server это конечно оповещение, для данных это довольно криво.
Контроль это прежде всего контроль поведения и каждой строки кода. В части интеграции при наличии необходимости программировать aaS ни фига не экономят. То есть они экономят как готовое платье, купил и надел. Но если надо шить под заказ то у мастера все должно быть в своих руках.

У крупного бизнеса всегда есть потребности изменить под себя в отличие от среднего или крупной сети среднего. А эти все сиюминутные "стандарты" сроком жизни в пару лет, они ни разу ни основа для программирования. Там нет ничего чего бы я не смог сделать клиенту за пару недель.