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

[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 как не делай параллельным, вся эта универсальность кода и настраиваемость и т.п. дает достаточно значимые накладные расходы.