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

[mazzy]

Vadik, EVGL, спасибо за комментарии. Утверждение про "Data Entity для справочников и параметров в существующей версии аксапты" пометил как удаленное.

К остальным утверждениям и вопросам в моем посте замечания/дополнения есть?

[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 себе поставить.

[ax_mct]

Цитата:

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

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

А как тогда работает упомянутая Connectivity Studio for Microsoft Dynamics 365 for Operations?
Они заявляют ODBC. Хотя, да, возможно и не работает именно в силу конкретных чисто организационных полиси.

Смысла таких ограничений не понимаю, но им там виднее конечно.
Однако в том же облачном SAP таких ограничений нет.

Цитата:

Access cloud databases via JDBC/ODBC
Access your cloud databases as if they're running locally in your network, using your existing database or replication tools.

SAP Cloud Platform Connectivity
https://cloudplatform.sap.com/capabi...97926b024.html

[Raven Melancholic]

Цитата:

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

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

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