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

[ax_mct]

Цитата:

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

Я слышал, что в планах есть что-то типа Common Data Model (CDM), но в немного другом виде.
т.е. все вендоры, типа SAP, SalesForce, Microsoft придут к единой модели ентитей, что позволит упростить все интеграции
Видел даже презентацию, но забыл название, поищу

про ODBC смешно вы пишете тут.
я это слово уже лет 10 не слышал

Цитата:

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

Entity, CDM - это частные случаи шаблона проектирования фасад.

Один из последних фасадов - AIF-DIXF. Который задумывался как О-го-го интеллектуальный! А в итоге получился еще одним транспортным уровнем.

В том то и дело что есть еще транспортный уровень. Абстрагируясь от внутренней реализации фасадом почему то при этом намертво привязались к web-service.

Фасад в ООП это прежде всего некий код как точка входа, но в Common Data Model вообще и в частности это прежде всего de-normalized view в базе данных. И только потом код. В качестве фасада выступает физическая таблица базы данных.
Data entities
https://docs.microsoft.com/en-us/dyn.../data-entities

ODBC/JDBC никогда не устаревало. Web-service имеют смысл только тогда когда точка входа это код бизнес-логики. А тут у нас куча служебного кода и компонентов обслуживающих конкретный вид транспорта (Web-service) только для того чтобы положить данные в Staging/Entity table.

Задача - положить данные в таблицу. В чем преимущество Web-service перед ODBC?
В упор не вижу. Кроме того что ODBC делает это лучше во всех смыслах.

При этом никакого фасада не нарушается так как весь код до Staging/Entity обслуживает только Web-service причиндалы. Да потенциально есть универсальность XML и возможность принимать те же Sales orders от кучи систем с разными схемами документов. Только интересно где такое есть. На Луне, не иначе.

[EVGL]

Цитата:

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

Задача - положить данные в таблицу. В чем преимущество Web-service перед ODBC?

Вы упорно игнорируете практическую сторону вопроса. Основное преимущество в том, что Web-service в D365FO PROD есть, а ODBC к PROD DB нет! Вот и все. Речь не о преимуществах, а сугубо прагматических вопросах использования доступных инструментов. Дискутировать о преимуществах того, что нет по сравнению с тем, что есть, а также как эти премущества донести до X-го этажа корпуса Advanta в Сиэттле - это другая тема, которая изначально здесь не затрагивалась.

[ax_mct]

Цитата:

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

Вы упорно игнорируете практическую сторону вопроса. Основное преимущество в том, что Web-service в D365FO PROD есть, а ODBC к PROD DB нет! Вот и все. Речь не о преимуществах, а сугубо прагматических вопросах использования доступных инструментов..

Точно нет?

Вот к примеру
Microsoft® ODBC Driver 17 for SQL Server® - Windows, Linux, & macOS
https://www.microsoft.com/en-us/down....aspx?id=56567

Microsoft ODBC Driver 17 for SQL Server is a single dynamic-link library (DLL) containing run-time support for applications using native-code APIs to connect to Microsoft SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017, Analytics Platform System, Azure SQL Database and Azure SQL Data Warehouse. Microsoft ODBC Driver 17 for SQL Server should be used to create new applications or enhance existing applications that need to take advantage of newer SQL Server features.

А есть еще CDATA driver
Read, Write and Update D365 Finance & Operations through ODBC
https://marketplace.visualstudio.com...TASOFTWARE.dy2

P.S. Вот эти ребята даже сертифицировали свое решение. И они используют ODBC компании CDATA как я понимаю.
Не знаю насколько у них хорошее решение, но сам факт использования именно ODBC (то ли как один из вариантов то ли как основной, не так важно)
https://www.to-increase.com/business...r-dynamics-crm

Цитата:

At To-Increase, our Connectivity Studio solution, thoroughly tested and proven in many customer integration scenarios, is effective in Dynamics AX 2012 environments and is now also certified for Microsoft Dynamics 365 for Operations. By using this solution, we easily set up an integration with Salesforce CRM or Microsoft Dynamics CRM.

There are two main ways to achieve this integration. We can use the services technology directly, which involves some critical details and requires a higher level of technical expertise. Or, we can build the integration by means of an ODBC connection, which is extremely simple to set up. Instead of spending days on development and resolving technical challenges, you can have a new integration done within minutes.

Most of us working in complex Dynamics ERP environments are used to ODBC—it’s a well-known interface, designed for optimal interoperability, easy to understand and implement. In the background, ODBC accesses the available services, which means it is safe and predictable. It’s not a hack that bypasses existing functionality.

https://appsource.microsoft.com/en-u...d-c3c385c80fb2
https://www.to-increase.com/business...io-integration

В Release notes - Connectivity Studio for Microsoft Dynamics 365 for Operations упоминается ремарка

Цитата:

This release not yet contains the new feature to initialize fields on the ODBC document using the CDATA or
the DEVART ODBC driver. The initialize fields feature only works for SQL ODBC driver only.

https://gallery.azure.com/artifact/2...3728377e4f.pdf

[gl00mie]

Цитата:

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

Цитата:

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

Основное преимущество в том, что Web-service в D365FO PROD есть, а ODBC к PROD DB нет!

Точно нет? Вот к примеру Microsoft® ODBC Driver 17 for SQL Server® - Windows, Linux, & macOS

Microsoft ODBC Driver 17 for SQL Server is a single dynamic-link library (DLL) containing run-time support for applications using native-code APIs to connect to Microsoft SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017, Analytics Platform System, Azure SQL Database and Azure SQL Data Warehouse.

Тут, наверно, возникла некоторая путаница в понятиях: ODBC к D365FO PROD DB в Azure нет не в техническом смысле, а в организационном - не дают индусские админы прямой доступ к рабочей базе D365FO в Azure, даже если Microsoft ODBC Driver 17 себе поставить.

[fed]

Проблемы Data Entity не в только в том, как именно данные в Staging Table кладутся, но и с дальнейшей их перекачкой в реальные таблицы.
То есть - разработчики очень пытались создать иллюзию виртуальной таблицы. То есть - ты в момент дизайна как-то какие-то таблицы заджойнил и отфильтровал, а дальше система сама разбирается, как данные из Staging по разным таблицам растащить. В теории, система должна при этом проверять ограничения целостности, вызывать всякие стандартные ValidateWrite или ValidateDelete. Оно и в самом деле работает - по крайней мере для 95% случаев, может даже для 99%. В оставшемся одном проценте тебе придется мучительно трассироваться в авто-сгененированном коде и пытаться понять что же именно не работает.
Не помогает ситуации и тот факт, что отдокументированы все стандартные методы data entity очень поверхностно.
Так что я вполне могу согласиться с одноразовым использованием data entity для импорта данных в начале проекта. Вероятно - можно рискнуть использовать все это для регулярных интеграций с невысоким потоком данных (типа закачки какой-нибудь платежной ведомости раз в месяц). Но вот для ежедневных интеграций по критическим потокам данных - я бы не рискнул все это использовать. Просто страшно...

[Vadik]

Цитата:

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

Так что я вполне могу согласиться с одноразовым использованием data entity для импорта данных в начале проекта. Вероятно - можно рискнуть использовать все это для регулярных интеграций с невысоким потоком данных (типа закачки какой-нибудь платежной ведомости раз в месяц). Но вот для ежедневных интеграций по критическим потокам данных - я бы не рискнул все это использовать. Просто страшно...

Так сказать, day in life нашего клиента. Не совсем типичный, обычно процессим 1-5К строк журналов в 10 компаниях (странах) ежедневно. В общем, не так все страшно

[fed]

Цитата:

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

Так сказать, day in life нашего клиента. Не совсем типичный, обычно процессим 1-5К строк журналов в 10 компаниях (странах) ежедневно. В общем, не так все страшно

Видишь ли, у нас на основании такого же подхода работает Микрософтовский Data Integrator. Он время от времени выгружает из CRM текстовые файлы (в CSV-формате насколько я помню) и шлет через Recurrent Integrations в Ax. В среднем раз в месяц оно переглюкивает.
Отсюда весь мой скептицизм по поводу этого механизма.

[fed]

Цитата:

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

Так сказать, day in life нашего клиента. Не совсем типичный, обычно процессим 1-5К строк журналов в 10 компаниях (странах) ежедневно. В общем, не так все страшно

Кстати, а как вы диагностируете проблемы, если что-то ломается на стадии загрузки в staging ? В таких ситуациях обычно только в event log полная информация об ошибке есть,а event log в prod не доступен. Вроде бы часть информации из event log в environment diagnostics тянется, но лога именно интеграции SSIS и D365FOE я там не нашел. (Возможно - плохо искал).

[Vadik]

Цитата:

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

Кстати, а как вы диагностируете проблемы, если что-то ломается на стадии загрузки в staging ?

У нас ломалось только на битых файлах "с той стороны". Тогда - View execution log \ Staging log details. Уже не помню когда в телеметрию последний раз заглядывал

Цитата:

Глюки change tracking и interactive push (сам сталкивался при работе data integrator)
Очень медленная выгрузка больших объемов в BYOD

Я за коммунизм агитировать не буду, просто напишу что у меня есть клиент который в BYOD проводки ГК (GeneralJournalAccountEntry) выгружает инкрементально несколько раз в час - отчеты из BYOD и TB сходятся

[ax_mct]

Судя по предлагаемым сценариям весь импорт в D365FO это использование entities.
https://docs.microsoft.com/en-us/dyn...d-ops/toc.json
То есть если импорт обходя entities то это уже "на коленке".

JSON формата {key, value, type} кстати не видно. Тот же SQL Server 2016 уже умеет OPENJSON.
Прикрутят, не удержаться. Как еще один слой между чем-нибудь. XML -> CSV -> JSON -> Entity -> JSON просто напрашивается.

К слову у меня сейчас клиент предлагает именно JSON файлы в AX читать. Как бы хайп XML прошел, сейчас время JSON

[belugin]

Энтити поддерживают ODATA в формате JSON, по крайней мере, на вывод.

Цитата:

[Your organization's root URL]/data/Customers?$format=json List all the customers in a JSON format that can be used to interact with JavaScript clients.

[Ivanhoe]

Т.е. еще одна тема, в которой пора разделять аксу на две версии: облачную и он-прем.

[George Nordic]

Простите что вмешиваюсь в интересную дискуссию, а как там BizTalk поживает? Или уже не поддерживается сие чудо? Или Data Integrator - его часть?

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

[EVGL]

Цитата:

Сообщение от George Nordic

Простите что вмешиваюсь в интересную дискуссию, а как там BizTalk поживает? Или уже не поддерживается сие чудо? Или Data Integrator - его часть?

Вопрос о какой-то специфической поддержке не идет. Надо поставить ODATA адаптор.

[twilight]

Цитата:

Сообщение от George Nordic

Простите что вмешиваюсь в интересную дискуссию, а как там BizTalk поживает?

Да вроде работает. Это же полностью независимый продукт.

[ax_mct]

Цитата:

Сообщение от George Nordic

Простите что вмешиваюсь в интересную дискуссию, а как там BizTalk поживает? Или уже не поддерживается сие чудо? Или Data Integrator - его часть?

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

BizTalk ползет на кладбище. Сейчас вместо него облачный Logic Apps. https://azure.microsoft.com/en-gb/services/logic-apps/

BizTalk вообще интересная тема в контексте интеграции и энтерпрайз в том смысле что интеграция всегда у нас нужна, а это такая супер-пупер мощная и гибкая штука. Обязана была завоевать мир.
Но как-то практически весь AX мир обошелся CSV файлами на коленке. Очень хороший пример что при наличии выбора между сложным инструментом и коленкой, выбирается коленка. Но эта земная физика наверно неприменима к облакам (*aaS, “as-a-Service”), там небесные законы и божий промысел.

Вот неплохая статья про то что полагается использовать (уже была эта ссылка несколько постов назад)
Choose a data integration (import/export) strategy
https://docs.microsoft.com/en-us/dyn...d-ops/toc.json

[Stitch_MS]

Цитата:

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

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

Цитата:

Heavy is good. Heavy is reliable.

[ax_mct]

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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

[Raven Melancholic]

Цитата:

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

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

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

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