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

[mazzy]

Цитата:

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

Просто у Сунила и его команды много других блестящих игрушек, а задачи по протаскиванию нового функционала через data entities ему не всегда вовремя ставят. Приходится пинать, в том числе через Yammer

хочешь сказать, что за Data Entity сейчас отвечает отдельная команда/человек?
не та команда, которая функционал сделала/доработала, а совершенно другая?

[Vadik]

Цитата:

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

хочешь сказать, что за 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 от кучи систем с разными схемами документов. Только интересно где такое есть. На Луне, не иначе.

[fed]

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

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

[EVGL]

Цитата:

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

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

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

[Ivanhoe]

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

[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

[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. В среднем раз в месяц оно переглюкивает.
Отсюда весь мой скептицизм по поводу этого механизма.

[George Nordic]

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

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

[EVGL]

Цитата:

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

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

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

[twilight]

Цитата:

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

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

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

[George Nordic]

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

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

[twilight]

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

[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

[Ivanhoe]

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

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