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

[ax_mct]

Цитата:

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

Касаемо интеграций. Для RealTime, более менее отлаженый и maintanble подход - через Retail Server. Он в своих кишках общается с Ax через умирющий SOAP, по прежнему, но свои задачи выполняет, модифицируется не сложно. Наружу выдаётся RetailServer API, которое всякие дот-нетчики могут поставить через Nuget пакеты. Для остальных не-RealTime задач десятки подходов которые здесь обсуждались, все имеют место быть, зависит от задачи. Из того что не обсуждалось - Azure Event Hub, Service Bus. Или самый дешевый и простой - те же Messages (Storage Account).

Достаточно типичная задача, управление номенклатурой AX в третьем приложении. То есть создание продуктов и/или изменение всех связанных настроек в другом приложении и импорт их в AX.

Ваши предложения?

Не нашел что такое Messages (Storage Account). Уж не обработка ли email?

[skuull]

Цитата:

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

. Из того что не обсуждалось - Azure Event Hub, Service Bus. Или самый дешевый и простой - те же Messages (Storage Account).

Business events из коробки работают с Azure Event Grid и Azure Service Bus ну и с Flow, только кому он нужен.

[ax_mct]

Цитата:

Picking for sales orders can be performed in a different systems, whether it’s a separate internal warehousing system or a third-party location that is not part of Finance and Operations. Upon confirmation or picking of a sales order, the line details are the event that triggers the external system to analyze and determine the picking priority and utilization.

https://docs.microsoft.com/en-us/dyn...tial-use-cases

This allows businesses with third-party warehouses to send the picking information to the system. This can also be used if the warehouse has automated picking machines that determine what is required. This approach puts the responsibility of prioritizing picking and utilization on the external system and simplifies the setup in Finance and Operations.

https://docs.microsoft.com/en-us/dyn...tial-use-cases

Судя по примерам кода мы пишем классы в X++ чтобы подписаться на имеющийся business event.
Так в чем печеньки-то?
В чем подход то? "This approach" это то что Post eventHandler раздули во фреймворк?
Как это что-то позволяет или что-то решает? Ничего не понимаю.

P.S. Ага. Вот оно. Теперь понятно более или менее. Насколько это полезно клиентам так и не понятно но понятно что платные опции в Azure subscription.
P.P.S. Интересный и загадочный мир Finance and Operations. Очень хочется остаться в примитиве c email и с файловым импортом.

Цитата:

Managing endpoints
Endpoints let you manage the destinations that Finance and Operations must send business events to. The following types of endpoints are currently supported. Therefore, endpoints can be created for these messaging and event brokers out of the box.

Azure Service Bus Queue
Azure Service Bus Topic
Azure Event Grid
Azure Event Hub
HTTPS
Microsoft Flow

[lvan]

Цитата:

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

ну и с Flow, только кому он нужен.

нужен много кому, у нас клиенты вовсю пользуются - два клика и работает
пока вы там ОДБЦ и FTP настраиваете

[EVGL]

Цитата:

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

Теперь понятно более или менее.

А что именно вы поняли? Поделитесь

P.S.
Axforum совершенно выродился. Флейм, флейм, флейм, вопросов интересных нет вообще. "Как настроить 20% НДС в 3.0"? Тьфу.
Это из-за того, что в России D365FO практически не внедряют?

[Logger]

Цитата:

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

Axforum совершенно выродился. Флейм, флейм, флейм, вопросов интересных нет вообще. "Как настроить 20% НДС в 3.0"? Тьфу.
Это из-за того, что в России D365FO практически не внедряют?

EVGL, какой ресурс сейчас, по-вашей оценке, самый информативный ?
Сами что используете в работе ?

[EVGL]

Цитата:

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

EVGL, какой ресурс сейчас, по-вашей оценке, самый информативный ?
Сами что используете в работе ?

https://community.dynamics.com/365/f...erations/f/765
Иногда stackoverflow

[fed]

Цитата:

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

Не много другая идея:
1) MS просто как обычно догоняет конкурентов, их главного конкурента AWS, с аналогом Kinesis.
2) Это BLOB хранилище, которое подразумевает хранения не только табличек а любого барахла: А - Такое хранение значитально дешевле чем в SQL. Б - На это дело натравливаются бигдатеры со своим Hadoop, которые ворочат всю эту кашу своими map-reduce алгоритмами.

Интересно - а без Hadoop туда можно малой кровью добраться ? Хотелось бы какое-то API, который бы позволял получить список таблиц (ну или каких-нить квазитаблиц) в этом data lake, потом получить список и типы полей в таблице, а потом как-нибудь эту таблицу прочитать (пусть даже чисто навигационным способом - уровня getFirst()/getNext()).
Просто все равно задача "перенести данные из D365FOE в локальную БД" остается. Вот я и интересуюсь, можно ли ее, пусть даже через Azure Data Lake решить...

[fed]

Цитата:

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

Axforum совершенно выродился. Флейм, флейм, флейм, вопросов интересных нет вообще. "Как настроить 20% НДС в 3.0"? Тьфу.
Это из-за того, что в России D365FO практически не внедряют?

В России D365FO фактически не внедряют. Консов-функциональщиков, которые смогли из России/Украины уехать и на иноязычном рынке адаптироваться - почти нет. Так что тут остались одни технари (часть - эммигранты как мы, часть - сидяшие в России/Украине оффшорщики). Ну и уж поверь мне, с технической точки зрения, D365FOE по сравнению с DAX2012 - это полная катастрофа, поэтому и флейм сплошной.

[EVGL]

Цитата:

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

Ну и уж поверь мне, с технической точки зрения, D365FOE по сравнению с DAX2012 - это полная катастрофа, поэтому и флейм сплошной.

Как консу-функциональщику мне все очень нравится, кроме импорта некоторых данных.
В редкой ипостаси "технаря" становится тяжело, затраты времени x3, но работа всякая нужна и важна, "Pecunia non olet".

[Jackally]

Цитата:

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

Достаточно типичная задача, управление номенклатурой AX в третьем приложении. То есть создание продуктов и/или изменение всех связанных настроек в другом приложении и импорт их в AX.

Ваши предложения?

Если кастомизация в пределах разумного, то можно и через DMF, для номенклатуры 2-3 недели только с нуля разбирать таблички по полям, всё-таки с готовым шаблоном проще. Разумеется такая логика должна работать по рассписанию, если стоит задача RetalTime для импорта номекнлатуры, значит что-то пошло не так на самом high-level уровне архитектуры и сбора бизнес-требований.

Цитата:

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

Не нашел что такое Messages (Storage Account). Уж не обработка ли email?

Я прошу прощения, писал по памяти, я имел ввиду Storage Account Queues, в которое вкладывается объект message. Это очень топорный мехнизм обмена сообщениями с 3-rd party системами, простой как табуретка, собщений накидал, сообщения забрал. Важное допущение с моей стороны, предлагая такой подход, желательно что бы сторонняя система тоже была в Azure, не обязательно в том же регионе (сложно придумать жизненный сценарий такой интеграции, что latency между регионами ажура будет сильно влиять). С API разобраться очень просто, на моем проекте такое решение работает уже год.

Цитата:

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

Business events из коробки работают с Azure Event Grid и Azure Service Bus ну и с Flow, только кому он нужен.

Спасибо, не смотрел в сторону стандарта, как я писал выше просто использовали ажуровское API, как бы не получилась здесь та же проблема что и у DMF, очень низкий maintainable.
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 решить...

А зачем отказываться от BYOD? Откуда слухи что MS собирается избавиться это такого подхода? Это инструменты для разных задач, Data Lake это чисто для BI/AI, с ним дружит и Power BI и Tableu. А для интеграций, если смотреть к чему склоняет MS, то это Service Bus и Event Grid.

[fed]

Цитата:

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

А зачем отказываться от BYOD? Откуда слухи что MS собирается избавиться это такого подхода? Это инструменты для разных задач, Data Lake это чисто для BI/AI, с ним дружит и Power BI и Tableu. А для интеграций, если смотреть к чему склоняет MS, то это Service Bus и Event Grid.

Видишь ли, сейчас в BYOD можно выгружать только обычные entity, которые в основном для master data и open orders предназначены. MS анонсировал что можно будет Aggregate Entities выгружать в эти Data Lakes, и когда наш клиент запрашивал у MS насчет read only доступа в основную БД ему как раз и ответили что надо этот самый data lakes подождать. А теперь выясняется что ни для чего кроме работы с PowerBI и Tableau оно не подходит.

Ну то есть - наверное можно было бы использовать и обычную BYOD, но мне кажется что микрософту для этого надо было бы слегка допилить обычные Data Entities.

[ax_mct]

Цитата:

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

А что именно вы поняли? Поделитесь

P.S.
Axforum совершенно выродился. Флейм, флейм, флейм, вопросов интересных нет вообще. "Как настроить 20% НДС в 3.0"? Тьфу.
Это из-за того, что в России D365FO практически не внедряют?

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

Я понял что это не совсем та интеграция. Это прежде всего интеграция D365FO с Azure. Два брата из ларца что кушают печеньки теперь могут нежно взяться за руки.

Я понял что этот замечательный функционал (business events ) мне никогда не понадобится.
Потому как я живу в каком-то альтернативном мире чем

Цитата:

нужен много кому, у нас клиенты вовсю пользуются - два клика и работает
пока вы там ОДБЦ и FTP настраиваете

Еще я понял как высоко может залететь A database trigger. Безумие какое-то.

[Vadik]

Цитата:

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

Axforum совершенно выродился. Флейм, флейм, флейм

Есть списки игнорирования, они работают. Я себе уже настроил

[ax_mct]

Цитата:

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

Если кастомизация в пределах разумного, то можно и через DMF, для номенклатуры 2-3 недели только с нуля разбирать таблички по полям, всё-таки с готовым шаблоном проще.
...
Я прошу прощения, писал по памяти, я имел ввиду Storage Account Queues,
...
что и у DMF, очень низкий maintainable.
...

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

Опции интеграции с использованием 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

[EVGL]

Цитата:

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

Это прежде всего интеграция D365FO с Azure. Два брата из ларца что кушают печеньки теперь могут нежно взяться за руки.

Я понял что этот замечательный функционал (business events ) мне никогда не понадобится.
Потому как я живу в каком-то альтернативном мире...

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

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

[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 и всё-таки в первую очередь экономят деньги, дальше уже думать всё взвешивать и принимать решение.

[Jackally]

Цитата:

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

Видишь ли, сейчас в BYOD можно выгружать только обычные entity, которые в основном для master data и open orders предназначены. MS анонсировал что можно будет Aggregate Entities выгружать в эти Data Lakes, и когда наш клиент запрашивал у MS насчет read only доступа в основную БД ему как раз и ответили что надо этот самый data lakes подождать. А теперь выясняется что ни для чего кроме работы с PowerBI и Tableau оно не подходит.

Ну то есть - наверное можно было бы использовать и обычную BYOD, но мне кажется что микрософту для этого надо было бы слегка допилить обычные Data Entities.

Не совсем понял почему только Open Orders, вроде бы это как раз Posted документы (см. вложение)?

Выгружать непосредственно транзакции, какой-нибудь InventTrans, нельзя, по крайней мере такого шаблона я не нашёл. Но это изначально не лучшее решение, выгружать нужно документы.

[fed]

Цитата:

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

Не совсем понял почему только Open Orders, вроде бы это как раз Posted документы (см. вложение)?

Ну - местами разнесенные документы есть, а местами и нету. Плюс, мне кажется что Микрософту стоило бы как-то развести обычные entity для импорта и экспорта и read-only entities для выгрузки в BYOD (например - можно было бы не делать для них Staging table и отключить все методы не относящиеся к экспорту).

Цитата:

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

Выгружать непосредственно транзакции, какой-нибудь InventTrans, нельзя, по крайней мере такого шаблона я не нашёл. Но это изначально не лучшее решение, выгружать нужно документы.

Ну вот это, как раз, очень спорное утверждение. Если клиенту нужен не обмен документами (вместо которого как раз можно Business Events привернуть или что-то подобное), а информация для внутреннего BI-портала какого-нибудь, то очень даже нужно транзакции перегонять, а не документы.

[Jackally]

Цитата:

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

Ну - местами разнесенные документы есть, а местами и нету. Плюс, мне кажется что Микрософту стоило бы как-то развести обычные entity для импорта и экспорта и read-only entities для выгрузки в BYOD (например - можно было бы не делать для них Staging table и отключить все методы не относящиеся к экспорту).

Ну вот это, как раз, очень спорное утверждение. Если клиенту нужен не обмен документами (вместо которого как раз можно Business Events привернуть или что-то подобное), а информация для внутреннего BI-портала какого-нибудь, то очень даже нужно транзакции перегонять, а не документы.

Я так понимаю предполагается использовать всякие InventOnHand entities для таких сценариев, т.е. моментальные скл. остатки и т.п. высчитывать что-то по InventTrans и InventSettlement снаружи - похоже что нету такой опции. И я не уверен что даже DataLake спасёт, я так полагаю что из-за "жирноты" объемов (InventTrans,InventSettlement...) выгружать их средствами Акс они не очень то хотят.
В целом можно их понять, даже через Entities, в не умелых руках это большой риск.
Можно серьезно просадить PROD чтением.

Но есть ведь от "них" же другое решения, например читать из репликационной ноды, файловер кластера, она доступна только на чтение, на прод никакого влияния не оказывает. И с точки зрения МС это как раз Best Practice:
https://docs.microsoft.com/en-us/azu...-elastic-pools

Подобное решение я делал несколько лет назад для On-Premises, там это называется AlwaysON. Схема себя отлично показала, никто не хеодит в PROD с чтением, спокойно читаем из реплики. Для самых крайних случаев можно использовать такой сценарий, но надо как-то договариваться с MS, сейчас faiover группами рулят они...