|
![]() |
#1 |
Участник
|
Цитата:
Цитата:
Цитата:
Сообщение от skuull
![]() Business events из коробки работают с Azure Event Grid и Azure Service Bus ну и с Flow, только кому он нужен.
Service Bus на самом деле очень удобный инструмент для работы с Messages, нужен как раз тем, кому простого Storage Queues показалось мало, где нужен хороший монитор обмена сообщениями, управление последовательностью и т.п. https://docs.microsoft.com/en-us/azu...ity-and-quotas Цитата:
Сообщение от fed
![]() Интересно - а без Hadoop туда можно малой кровью добраться ? Хотелось бы какое-то API, который бы позволял получить список таблиц (ну или каких-нить квазитаблиц) в этом data lake, потом получить список и типы полей в таблице, а потом как-нибудь эту таблицу прочитать (пусть даже чисто навигационным способом - уровня getFirst()/getNext()).
Просто все равно задача "перенести данные из D365FOE в локальную БД" остается. Вот я и интересуюсь, можно ли ее, пусть даже через Azure Data Lake решить... Последний раз редактировалось Jackally; 23.04.2019 в 11:12. |
|
![]() |
#2 |
Moderator
|
Цитата:
Ну то есть - наверное можно было бы использовать и обычную BYOD, но мне кажется что микрософту для этого надо было бы слегка допилить обычные Data Entities. |
|
![]() |
#3 |
Участник
|
Цитата:
Сообщение от fed
![]() Видишь ли, сейчас в BYOD можно выгружать только обычные entity, которые в основном для master data и open orders предназначены. MS анонсировал что можно будет Aggregate Entities выгружать в эти Data Lakes, и когда наш клиент запрашивал у MS насчет read only доступа в основную БД ему как раз и ответили что надо этот самый data lakes подождать. А теперь выясняется что ни для чего кроме работы с PowerBI и Tableau оно не подходит.
Ну то есть - наверное можно было бы использовать и обычную BYOD, но мне кажется что микрософту для этого надо было бы слегка допилить обычные Data Entities. Выгружать непосредственно транзакции, какой-нибудь InventTrans, нельзя, по крайней мере такого шаблона я не нашёл. Но это изначально не лучшее решение, выгружать нужно документы. |
|
![]() |
#4 |
Moderator
|
Цитата:
Ну вот это, как раз, очень спорное утверждение. Если клиенту нужен не обмен документами (вместо которого как раз можно Business Events привернуть или что-то подобное), а информация для внутреннего BI-портала какого-нибудь, то очень даже нужно транзакции перегонять, а не документы. |
|
![]() |
#5 |
Участник
|
Цитата:
Сообщение от fed
![]() Ну - местами разнесенные документы есть, а местами и нету. Плюс, мне кажется что Микрософту стоило бы как-то развести обычные entity для импорта и экспорта и read-only entities для выгрузки в BYOD (например - можно было бы не делать для них Staging table и отключить все методы не относящиеся к экспорту).
Ну вот это, как раз, очень спорное утверждение. Если клиенту нужен не обмен документами (вместо которого как раз можно Business Events привернуть или что-то подобное), а информация для внутреннего BI-портала какого-нибудь, то очень даже нужно транзакции перегонять, а не документы. В целом можно их понять, даже через Entities, в не умелых руках это большой риск. Можно серьезно просадить PROD чтением. Но есть ведь от "них" же другое решения, например читать из репликационной ноды, файловер кластера, она доступна только на чтение, на прод никакого влияния не оказывает. И с точки зрения МС это как раз Best Practice: https://docs.microsoft.com/en-us/azu...-elastic-pools Подобное решение я делал несколько лет назад для On-Premises, там это называется AlwaysON. Схема себя отлично показала, никто не хеодит в PROD с чтением, спокойно читаем из реплики. Для самых крайних случаев можно использовать такой сценарий, но надо как-то договариваться с MS, сейчас faiover группами рулят они... Последний раз редактировалось Jackally; 23.04.2019 в 15:54. |
|
![]() |
#6 |
Banned
|
Цитата:
Сообщение от Jackally
![]() Если кастомизация в пределах разумного, то можно и через DMF, для номенклатуры 2-3 недели только с нуля разбирать таблички по полям, всё-таки с готовым шаблоном проще.
... Я прошу прощения, писал по памяти, я имел ввиду Storage Account Queues, ... что и у DMF, очень низкий maintainable. ... Опции интеграции с использованием 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 Последний раз редактировалось ax_mct; 23.04.2019 в 12:33. |
|
![]() |
#7 |
Участник
|
Цитата:
Цитата:
Сообщение от 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 Я слышал про интеграции через 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 и всё-таки в первую очередь экономят деньги, дальше уже думать всё взвешивать и принимать решение. |
|
![]() |
#8 |
Banned
|
Цитата:
Сообщение от EVGL
![]() Ну, Azure - это не продукт, а платформа. Программе в облаке говорить с программой в облаке конечно проще. Такие монстры как Document routing agent, работают, конечно менее стабильно.
Почему не понадобится? Известить внешний склад (3rd party logistics) о том, что отгрузка готова - это совершенно типичная задача. Никакого альтернативного мира, а вполне себе реальная рутина. Для того чтобы оповестить внешний склад не нужно Azure. Как и этому складу Azure не нужен. Email, FTP, REST/SOAP. Цитата:
Сообщение от Jackally
![]() Я слышал про интеграции через Mail Server, но честно скажу опыта не было, не могу сказать про +/-. На сколько это управляемо и расширяемо при увеличении нагрузки?
.. Если под кjнтролем вы понимаете мониторинг, нет нет ничего лучше чем просто попробовать ... SaaS и PaaS, и прочие не IaaS и всё-таки в первую очередь экономят деньги, дальше уже думать всё взвешивать и принимать решение. Контроль это прежде всего контроль поведения и каждой строки кода. В части интеграции при наличии необходимости программировать aaS ни фига не экономят. То есть они экономят как готовое платье, купил и надел. Но если надо шить под заказ то у мастера все должно быть в своих руках. У крупного бизнеса всегда есть потребности изменить под себя в отличие от среднего или крупной сети среднего. А эти все сиюминутные "стандарты" сроком жизни в пару лет, они ни разу ни основа для программирования. Там нет ничего чего бы я не смог сделать клиенту за пару недель. |
|
Теги |
#msftadvocate, aif, абстракции, закопаем стюардессу, индийская кухня, интеграция, как правильно, холивар |
|
|