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

[Stitch_MS]

Цитата:

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

Но как-то практически весь AX мир обошелся CSV файлами на коленке.

Цитата:

Heavy is good. Heavy is reliable.

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

[ax_mct]

Stitch_MS
Это Taken 2: Take the Fucking Elephant!

[Владимир Максимов]

Цитата:

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

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

Немножко не так.

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

Даже для простейших схем интеграции плоских таблиц-справочников "в общем случае" надо "наворочать" "километры" кода. Что бы там кто ни говорил, что вот у них сделано и работает, но если "заглянуть под капот", то это "тихий ужас" и "без поллитры не разберешься".

И ведь, зараза такая, все это оправдано! Если все-таки начать разбираться, то, да, в общем случае и это нужно, и вот то. А если вот такой вариант, то нужно еще вот здесь обойти, здесь перепрыгнуть, а вот здесь, вообще подкоп сделать

Соответственно, и встает выбор - разбираться в крайне не тривиальном коде и таком же крайне не тривиальном дизайне или "по быстрому" написать "на коленке" без всех этих универсальных "общих случаев"

---------------------

Но! Блин! Ведь при интеграции много однотипных операций! Ну как же здесь не попытаться этот самый универсальный инструмент сделать! Ну очень хочется! Однотипные же... Но не получается... Но хочется...

Так что, попытки написания универсального инструмента интеграции были, есть и будут. И все будут провальными именно для "общего случая", но вполне рабочими для каких-то "частных задач".

[EVGL]

Цитата:

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

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

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

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

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

[Ivanhoe]

Цитата:

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

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

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

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

[Raven Melancholic]

Цитата:

Сообщение от Владимир Максимов

Однотипные же... Но не получается... Но хочется...

Так что, попытки написания универсального инструмента интеграции были, есть и будут. И все будут провальными именно для "общего случая", но вполне рабочими для каких-то "частных задач".

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

[Raven Melancholic]

Цитата:

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

А как тогда работает упомянутая Connectivity Studio for Microsoft Dynamics 365 for Operations?

Попробуйте в ней сделать простейшую операцию - в поле с типом date AX вставьте значение из поле datetime MS SQL.

[ax_mct]

Цитата:

Сообщение от Владимир Максимов

Т.е. некую универсальную оболочку для интеграции реализовать невозможно. В принципе.
...
Соответственно, и встает выбор - разбираться в крайне не тривиальном коде и таком же крайне не тривиальном дизайне или "по быстрому" написать "на коленке" без всех этих универсальных "общих случаев"

Все гиганты софтвеерного бизнеса мысли и SAP и IBM и Oracle и Microsoft имеют такие реализации уже лет 15-20. И тележка всяких Mulesoft, Informatica, Adeptia за ними.

Comparison of business integration software
https://en.wikipedia.org/wiki/Compar...ation_software

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

Клиент и рад был бы заплатить здесь и сейчас $$15K за готовую интеграцию чтобы пришли и в течение нескольких дней настроили, но фиг там. Мне действительно тоже кажется что задача универсальности интеграции нерешаема. Хотя у самого и возникают мысли смотря на это дело создать такой продукт.

Цитата:

Сообщение от Raven Melancholic

Попробуйте в ней сделать простейшую операцию - в поле с типом date AX вставьте значение из поле datetime MS SQL.

Один из текущих их клиентов планирует как раз уйти от их решения к моей коленке. Не знаю в чем именно там дело в цене или подобном геморе, качестве поддержки etc.
Пример кстати хороший тем что полностью контролируя решение на коленке это приведение типов фиксится на раз. В этом смысле потенциально open source какие-то решения должны были бы быть жутко популярны но в корпоративном секторе свои законы поэтому фиг его знает.

Коленку кстати и в D365FO можно придумать. Если в нее не пускают то она же может своим батчем через ODBC другую систему читать? Тогда все хорошо

P.S. Если ты не пишешь на коленке то ты стоишь на коленях в храме вендора (с) Неизвестный программист.

[gl00mie]

Цитата:

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

А как тогда работает упомянутая Connectivity Studio for Microsoft Dynamics 365 for Operations? Они заявляют ODBC

To-Increase Connectivity Studio - это расширение для D365FO, написанное по большей части на X++ (за исключением некоторых доп.компонентов), поэтому когда там заявляется поддержка ODBC, то это означает возможность из D365FO подключаться вовне по ODBC, а не возможность волшебным образом сделать ODBC-доступ к рабочей базе самой D365FO в обход индусских админов.

Цитата:

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

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

Мне кажется, все просто: а как иначе продавать свои Data Lake и прочие PowerBI? Эдак вы, чего доброго, свой BI прикрутите и свои интеграции. Как говорится, "где ж я буду харчеваться"? Кроме того, ODBC-доступ к базе рушит напрочь все заморочки с правами доступа и XDS на пару. В этом плане тот же Query Service в AIF был хорош: вроде как можно делать запросы, какие хочешь, но при этом контроль доступа оставался на месте и фильтровал результаты.

Цитата:

Сообщение от Raven Melancholic

Попробуйте в ней сделать простейшую операцию - в поле с типом date AX вставьте значение из поле datetime MS SQL.

О какой версии AX и Connectivity Studio речь? И расскажите, в чем подвох в этой постановке задачи? Я с Connectivity Studio сталкивался, на чиная с AX2012, и сходу не припомню каких-то подводных камней в этом плане.

[EVGL]

Цитата:

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

Коленку кстати и в D365FO можно придумать. Если в нее не пускают то она же может своим батчем через ODBC другую систему читать? Тогда все хорошо

Как это сделать в стандарте, мне не известно. Поддержку ODBC в DMF давно прибили в D365FO.
В стандарте есть только экспорт: https://docs.microsoft.com/en-us/dyn...r-own-database

Вообще это стремно, выставлять свою базу данных напоказ в WAN, особенно нынче во времена GDPR.

Зато есть https://docs.microsoft.com/en-us/dyn...al-web-service.

Так что повторюсь по поводу прагматизма. Плыть против течения ("Если ты не пишешь на коленке то ты стоишь на коленях в храме вендора") - это далеко не доблесть, а для клиента - моральная травма на этапе обновления. Проходили все это с виртуальными компаниями. Я тоже думал что самый умный и подобрал наилучшее на тот момент решение. Только уже через год писали SQL скрипты, чтобы это разрушить, а клиент заплатил в итоге 3 раза за одно и то же. Вас, похоже, это не останавливает. Желание дополнительного дохода через пару лет? А как оправдываться? На Microsoft все валить, типа "не знал, что так будет"?

[fed]

Цитата:

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

Так что повторюсь по поводу прагматизма. Плыть против течения ("Если ты не пишешь на коленке то ты стоишь на коленях в храме вендора") - это далеко не доблесть, а для клиента - моральная травма на этапе обновления. Проходили все это с виртуальными компаниями. Я тоже думал что самый умный и подобрал наилучшее на тот момент решение. Только уже через год писали SQL скрипты, чтобы это разрушить, а клиент заплатил в итоге 3 раза за одно и то же. Вас, похоже, это не останавливает. Желание дополнительного дохода через пару лет? А как оправдываться? На Microsoft все валить, типа "не знал, что так будет"?

Напомню, что вся эта тема стартовала с того, что Vadik жаловался на отсутствие поддержки AIF в D365 (тогда кажется еще New Dynamics Ax). Я просто замечу что при нынешней глубине планирования продукта в MS, к проблемам в будущем может привести как использование стандартных функций, так и их не использование.
P.S. И вообще есть интересный подход к принятию решений в условиях высокой неопределенности: Учитывать только известные текущие ограничения и обстоятельства.Даже если есть ощущение что "потом что-нибудь накроется", "потом когда-нибудь будут проблемы". Пока эти самые проблемы и их характер неизвестны - можно их просто игнорировать.

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

Цитата:

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

Великий аналитик Педро

Он реально великий аналитик. Начинает поиск от написанной на заборе вакансии чтобы найти пересечение описания компании с наличием в ней специалистов.
Смотрит на профиль человека перешедшего в компанию и если у него там было 365 (причем непонятно что это CRM или FO) то делает вывод о том что компания вероятно переходит c AX на FO.

Вот к примеру Coloplast. На основании того что Head of ERP (1.5 года) пришел с должности руководителя проектов Columbus (1.25 года), где в опыте у того руководство двумя проектами AX2012 и Microsoft Dynamics 365 (без указания конкретного продукта), он делает вывод что

Цитата:

Perfect, Coloplast ist a $2,5 billion company probably moving to Microsoft Dynamics 365

Published on January 19, 2019
https://www.linkedin.com/pulse/how-d...dro-rodriguez/

В то время как Coloplast это более вероятно SalesForce и JDEdwards.
Я даже совсем не уверен что у них есть AX2012.
https://www.coloplast.com/career/wel...o/global-jobs/
https://www.linkedin.com/in/slawomir-kowalski-602287

[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 требует в любом варианте периодических остановок и т.п.

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