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

[George Nordic]

Ну, просто когда-то ожидалось, что обмен данными будет завязан именно на него. Даже intercompany. Интересна судьба начинания

С Уважением,
Георгий

[twilight]

Сейчас у нас на проекте планируют использовать его для аутентификации доступа к вебсервисам
Аксапты с помощью логина/пароля. Вот такое вот извращение )

[Ivanhoe]

Biztalk еще и дорогой был.

Ну и по скорости всегда интеграция на уровне бд быстрее остальных вариантов. И тот же хваленый dmf на больших объемах тормозит и ничего с этим не сделать.

[ax_mct]

Цитата:

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

Biztalk еще и дорогой был.

Ну и по скорости всегда интеграция на уровне бд быстрее остальных вариантов. И тот же хваленый dmf на больших объемах тормозит и ничего с этим не сделать.

ODBC/JDBC позиций не сдает перед web-сервисами если брать всю индустрию. То что MS не дает доступа к D365FO PROD это интересно почему. То есть понять бы эту политику так как у других такого нет.

Есть ровесник и соперник BizTalk - IBM APP Connect Enterprise (abbreviated as IBM ACE, formerly known as IBM Integration Bus or WebSphere Message Broker)
https://en.wikipedia.org/wiki/IBM_Integration_Bus

Он примерно родился в те же годы но при этом не убился об облака. То есть он еще тогда был как бы уже облачным в силу того что на Java. Интересный продукт и в полный рост использует ODBC практически ко всем существующим базам данных. При этом имеет встроенный CLR для вызова .NET кода.
https://www.ibm.com/support/knowledg...c/ah14440_.htm
https://www.ibm.com/cloud/app-connect

Движок BizTalk как я понимаю на C++ как минимум частично но все равно не понятно почему он только On-Prem. А для облаков он типа не годен. Что-то я не очень понимаю что тогда Cloud computing.

Типа все что Cloud должно иметь web-интерфейс? Ну тогда это просто хостинг web-приложений только отличающийся подпиской. Ведь еще есть и терминальный доступ которого якобы нет также как и ODBC.

P.S. PAAS, SAAS, IAAS. Резиновый хостинг и не обязательно web. Но почему тогда тот же BizTalk не может жить в Cloud?

[EVGL]

Цитата:

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

Biztalk еще и дорогой был.

Ну и по скорости всегда интеграция на уровне бд быстрее остальных вариантов. И тот же хваленый dmf на больших объемах тормозит и ничего с этим не сделать.

... притом что хваленый DMF работает через SSIS, т.е. по сути работает так близко к уровню БД, как можно, поэтому и валится с загадочными сообщениями на этапе импорта в staging.

Чтобы этап target работал быстрее, его надо запускать исключительно в асинхронном режиме и распараллеливать.

[Ivanhoe]

Цитата:

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

... притом что хваленый DMF работает через SSIS, т.е. по сути работает так близко к уровню БД, как можно, поэтому и валится с загадочными сообщениями на этапе импорта в staging.

Чтобы этап target работал быстрее, его надо запускать исключительно в асинхронном режиме и распараллеливать.

Самое быстрое - это прямое копирование через ssis . Дальше копирование через ssis в staging и заточенный код переноса в target с распараллеливанием. А dmf как не делай параллельным, вся эта универсальность кода и настраиваемость и т.п. дает достаточно значимые накладные расходы.

[EVGL]

Согласен! Однако сравним: когда я в 2015 году орудовал с виртуальными компаниями, еще не было стопроцентно известно, что их изведут. Я лишь получил дружеский совет от некоего Ларса, что лучше от них держаться подальше. Т.е. на тот момент это были лишь слухи. Тем не менее, надо было прислушаться.

В данном же случае на 100% известно, что AIF и ODBC не будет. Более того, этой поддержки нет уже как в трех "версиях":
- Dynamics 365 for Operations 7.x
- Dynamics 365 for Finance and Operations 8.x
- Dynamics 365 for Finance and Operations 10.0.x

Но нет, народ кидается на амбразуру и придумывает все новые и новые аргументы, почему клиента надо оставить у разбитого корыта.

[ax_mct]

Цитата:

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

Как это сделать в стандарте, мне не известно. Поддержку ODBC в DMF давно прибили в D365FO.
...

Спасибо, похоже что BYOD это одна из интересных опций для импорта в другую базу из которой уже можно брать как хочешь. И да, те же веб-сервисы позволяют сделать функционально практически все что хочешь. Но повторюсь что таких ограничений на ODBC я не вижу больше нигде среди других ERP.

Цитата:

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

А как оправдываться? На Microsoft все валить, типа "не знал, что так будет"?

Пример использования виртуальных компаний это как раз использование текущего стандарта который потом отменили или изменили. Ничуть не сомневаюсь что лет через 3-5 текущий стандарт интеграции надо будет выбрасывать. Как бы паттерн развития.
В то же время как коленка с CSV и SFTP чуть ли не с версии 2.5 может быть без особых проблем использована в AX2012 и даже возможно в D365FO.

При этом с чистой совестью можно внедрять стандартные рекомендуемые решения и прятаться в тени гиганта. Типа если что то клиент сам виноват что выбрал этого вендора/продукт.

Цитата:

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

В данном же случае на 100% известно, что AIF и ODBC не будет. Более того, этой поддержки нет уже как в трех "версиях":
- Dynamics 365 for Operations 7.x
- Dynamics 365 for Finance and Operations 8.x
- Dynamics 365 for Finance and Operations 10.0.x

Но нет, народ кидается на амбразуру и придумывает все новые и новые аргументы, почему клиента надо оставить у разбитого корыта.

В моей ситуации о 365 речи не идет, AX2012. Гипотетическая возможность перехода с AX на 365 настолько гипотетическая что на нее можно не обращать внимания. И даже если и так то очень сомневаюсь что нестандартная интеграция в AX каким-то образом повлияет на стоимость и время перехода на новый продукт.

[EVGL]

Цитата:

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

В то же время как коленка с CSV и SFTP чуть ли не с версии 2.5 может быть без особых проблем использована в AX2012 и даже возможно в D365FO.

ДА! Я бы именно это и рекомендовал, помимо web-сервисов.

Цитата:

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

Гипотетическая возможность перехода с AX на 365 настолько гипотетическая что на нее можно не обращать внимания.

Это вам клиент сказал? У одного клиента в 2015 году тоже возможность была гипотетическая. А в 2018 они запросили от меня оценку по обновлению, и получили его, около 1 млн долларов*. Теперь клиент считает, что они выбрали неверный продукт и/или неправильного партнера... в чем есть большая доля правды.
Поправка: ~1,7 млн долларов. В принципе, не бог весть какая сумма для тех краев. Так, средняя стоимость дома. Но у финансового директора отвалилась челюсть.

Цитата:

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

И даже если и так то очень сомневаюсь что нестандартная интеграция в AX каким-то образом повлияет на стоимость и время перехода на новый продукт.

У другого моего клиента нестандартая интеграция электронной почты в workflow без использования entity вылилась в месяц трудозатрат после обновления с 7.1 (!) на 7.2, когда закрыли модель Application Foundation. И осадочек остался, разумеется, когда пришлось платить ровно дважды за одно и то же.

[ax_mct]

Цитата:

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

ДА! Я бы именно это и рекомендовал, помимо web-сервисов.

Так коленка же Но я рад что есть совпадение мнений.

Цитата:

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

Это вам клиент сказал? У одного клиента в 2015 году тоже возможность была гипотетическая. А в 2018 они запросили от меня оценку по обновлению, и получили его, около 1 млн долларов*. Теперь клиент считает, что они выбрали неверный продукт и/или неправильного партнера... в чем есть большая доля правды.
Поправка: ~1,7 млн долларов. В принципе, не бог весть какая сумма для тех краев. Так, средняя стоимость дома. Но у финансового директора отвалилась челюсть.

Не совсем по данной теме но я просто не вижу причин зачем клиенту on-premise AX2012 нужно переходить на новый продукт по подписке. При любом раскладе стоимость перехода будет даже выше внедрение AX2012, то есть типично не менее 1 млн долларов и кроме того через 1.5 года надо начинать платить денег чтобы возможно заплатить еще 1 млн долларов в течение 5-7 лет.
Поэтому и говорю что гипотетическая возможность.

Возможно через пару лет вопрос встанет остро если поддержка не продлится, но тем не менее какой процент с AX2012/AX2009/AX2004 будет переходить на D365FO это тот самый вопрос который не дает мне спать.

Цитата:

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

У другого моего клиента нестандартая интеграция электронной почты в workflow без использования entity вылилась в месяц трудозатрат после обновления с 7.1 (!) на 7.2, когда закрыли модель Application Foundation. И осадочек остался, разумеется, когда пришлось платить ровно дважды за одно и то же.

Все же они уже там были в новом продукте, то есть переезд в новый дом таки состоялся.

А покупать мебель в дом из расчета чтобы ее было удобнее перевозить, пересобирать - так никто не делает. В любом случае на фоне покупки нового дома и переезда эта транспортабельность конкретного дивана это сущие мелочи жизни.

[EVGL]

Цитата:

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

Возможно через пару лет вопрос встанет остро если поддержка не продлится, но тем не менее какой процент с AX2012/AX2009/AX2004 будет переходить на D365FO это тот самый вопрос который не дает мне спать.

Великий аналитик Педро недавно утверждал, что 35% процентов клиентов уже как минимум делают практические шаги к обновлению. Этим цифрам можно верить или не верить, но причина для беспокойства у Вас определенно должна быть.
Тем более, что мы с вами не в России, а подвизаемся на более развитых рынках.

[ax_mct]

Перечитал тему с начала. Вроде бы и все сказано. Но сейчас у меня задача выбора архитектуры и создания рабочего прототипа.
Есть AX2012R3 и есть отдельная система master data management в которую должно быть передано управление номенклатурой товаров со всеми этими 30 таблицами вокруг этого.
2 совещания сегодня, есть список из 200-300 полей в 20-30 таблицах в AX которые должны обновляться из этой другой системы.

DMF и web-service отвергнуто клиентом самостоятельно.

Задача создания предельно стандартной коленки чтения из JSON файлов.
Глянул на DMF и DMFInventTableEntity. Глянул на AIF EcoResProductService и связанные классы.

Стандартно AIF EcoResProductService имеет крайне ограниченное количество полей (порядка 10-30) и полагается на product templates. Но мое предложение использовать product templates не вызвало понимания так как их понадобиться слишком много да и весь функционал управления номенклатурой должен быть в другой системе. Порядка 300 полей в 30 таблицах.

Как бы маленький AIF на коленке напрашивается. А интуитивно лучше просто голая коленка.
Но я честно продебажу AIF и посмотрю нельзя ли исхитриться c defaultRow() и подобным.
И все же наверное посмотрю нельзя ли light DMF изобразить с DMFInventTableEntity. Как бы лень просит пару строк и вуаля. Но трудоемкость всех вариантов кажется примерно равной, а спать хочется спокойно.

Чтобы вы сделали?

[trud]

Цитата:

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

Чтобы вы сделали?

Вам надо изначально создать документ который будет описывать интеграцию. Я как-то сделал шаблон для этого, на основании рекомендаций Oracle убрав оттуда все лишнее
Integration solution specification
https://github.com/TrudAX/XppTools/b...equirements.md
В этом документе вы должны ответить на все вопросы(т.е. по сути каждый ответ может кардинально изменить подход и способ интеграции), далее уже можно будет думать и обсуждать как этого достить.
Т.е. к примеру если вам нужно загрузить большое кол-во данных за небольшое время - вы не можете использовать медленные веб сервисы, если нужна доступность данных 24*7, вы не можете их получать используя подключение к АХ через AOS, т.к. AOS требует в любом варианте периодических остановок и т.п.

Я попозже планировал написать пост на эту тему

[EVGL]

Цитата:

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

DMF и web-service отвергнуто клиентом самостоятельно.

Убедить клиента, что он не прав и надо использовать DMF. Может быть, даже создать свой набор упрощенных классов, а не заморачиваться со стандартными. Импортировать текстовые файлы.

[fed]

Цитата:

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

Убедить клиента, что он не прав и надо использовать DMF. Может быть, даже создать свой набор упрощенных классов, а не заморачиваться со стандартными. Импортировать текстовые файлы.

Тут в Яммере Сунил задал вопрос "Какие Anti-patterns при работе с data entities вы знаете". В тему внесены 22 ответа за два дня. Перечислены все области функционала, кроме примитивного одноразового импорта ограниченного числа строк.

[Vadik]

Цитата:

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

Тут в Яммере Сунил задал вопрос "Какие Anti-patterns при работе с data entities вы знаете". В тему внесены 22 ответа за два дня. Перечислены все области функционала, кроме примитивного одноразового импорта ограниченного числа строк.

И есть реально что-то интересное кроме паттернов которые сам MS настоятельно просит не использовать во всех techtalks, вроде объемного data management и Power BI через OData? Что для упоротых эти рекомендации не указ, в общем и так было понятно

P.S. суд по количеству лайков под постом trud о том, что подбирать надо не лучшую технологию "вообще", а технологию под конкретную задачу - прочитали его многие, поняли и оценили не все. Ничего личного, просто мысли вслух

[ax_mct]

Цитата:

Импорт JSON текстовых файлов. А подойдет DMF для update? Все изменения (246 полях из 39 таблиц) должны приниматься AX.
И AIF тоже выглядит вкусно как готовый шаблон который можно местами расширить, местами сдублировать.

JSON не поддерживается, в вот почему: https://www.mssqltips.com/sqlservert...tion-services/
Для update подойдет. Там, где это можно, entity работают в режиме UPSERT, пользуемся этим каждый день.
Про AIF уже все было сказано.

Извините, в который раз отредактировал вместо того, чтобы ответить.

[ax_mct]

Цитата:

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

И есть реально что-то интересное кроме паттернов которые сам MS настоятельно просит не использовать во всех techtalks, вроде объемного data management и Power BI через OData? Что для упоротых эти рекомендации не указ, в общем и так было понятно

P.S. суд по количеству лайков под постом trud о том, что подбирать надо не лучшую технологию "вообще", а технологию под конкретную задачу - прочитали его многие, поняли и оценили не все. Ничего личного, просто мысли вслух

Сначала размер задницы и только потом памперс. Просто брать тот же DMF и его пилить потому что он лучший выбор вообще, конечно же нет. Скорость разработки и надежность работы важнее правильности. Даже если это будет 246 копи-пастов c прямой работой с табличными буферами и вызовом .modifiedField(). Никто не осудит.
Но конечно этого хочется избежать. Продебажу стандартный AIF сервис и копну DMF. А там задница подскажет без оглядки на рекомендации MS.

P.S. Прикольно я сам с собой разговариваю. Cпасибо!

[fed]

Цитата:

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

И есть реально что-то интересное кроме паттернов которые сам MS настоятельно просит не использовать во всех techtalks, вроде объемного data management и Power BI через OData? Что для упоротых эти рекомендации не указ, в общем и так было понятно

1. Глюки change tracking и interactive push (сам сталкивался при работе data integrator)
2. Очень медленная выгрузка больших объемов в BYOD
3. Отстутствие параллелизма для многих типов Entity. (Да - я знаю что некоторые из них на number sequence завязаны, но грузить-то их как-то надо).
Не из темы, а из собственного опыта:
1. Вчера внезапно у клиента перестал работать тупой экспорт из Customers в excel. Диагностики нету, есть только код ошибки от SSIS. Удалось победить заменив экспорт в excel на экспорт в CSV. Это Tier-2 окружение, в котором я точно никакого странного постороннего софта не ставил.
2. Несколько раз видел когда один и тот же набор данных грузился в обычном режиме и выдавал какую-то загадочную диагностику от SQL в Set Based update. (Хотя ok, Set Based update - это экстрим. Но с другой стороны - он заявлен и галочка не скрыта...)

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

[ax_mct]

Есть такой интересный посыл от евангелиста (Martin Dráb)

Цитата:

D365FO doesn't come with it's own way for handling these things; simply take a .NET API of your choice and use it as in any other .NET application. It also means that you'll find a plenty of information on internet - tutorials, code samples and so on.

Just wrap the logic in a .NET class library, add a reference to your X++ project and call classes in the library when needed.

https://community.dynamics.com/365/f...f/765/t/300455

В связи с чем у меня вопрос. Если при вызове со стороны D365 все понятно что можно все, тот же TCP WCF (к сожалению .NET Remoting прибили для кросс-платформенности).

А вот как стучаться в D365 из .NET сборки на том же сервере? ODATA если вставка записей или custom service JSON/SOAP если обращение к коду? То есть только через Active Directory и IIS?

И чем им .NET/Business Connector помешал? При чем тут кросс-платформенность не понимаю.