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

[ax_mct]

Цитата:

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

... закладывая мину и невозможность обновления. Сходить с орбиты пора таким партнерам. Я клиентов, которым так внедряли и кто желает перейти на D365FO, стараюсь обходить стороной: малый бюджет, рутинная работа, которую все равно никто не оценит, зато масса негативных эмоций со стороны клиента.

А в чем мина?
OdbcConnection в соседнюю базу. Код сбоку, свои Staging tables сбоку.
На совместимость может влиять только как именно обновляются справочники. Но нормальный программист будет использовать для этого тот же код что и в стандартных AIF сервисах.

OdbcConnection кстати и к Azure SQL не проблема. И через интернет - не проблема.

Как понимаю ODBC connection поддерживается и изнутри D365FO. Насколько это сломано не знаю.
Но обязано быть как всеобщий стандарт.

[trud]

Цитата:

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

для меня все ясно и понятно сказал gl00mie
AX7 - data entities - sales order

А какие кстати вообще варианты для периодической загрузки sales order существуют(т.е. это будет EDI обмен)? ну т.е. стандартный DataManagement не поддерживает транзакции, остается только GER

[skuull]

Цитата:

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

А какие кстати вообще варианты для периодической загрузки sales order существуют(т.е. это будет EDI обмен)? ну т.е. стандартный DataManagement не поддерживает транзакции, остается только GER

А чо с OData'ой не так ?

[trud]

OData это же протокол. т.е. надо писать где-то на коленке програмку которая будет вызывать эту OData?

[skuull]

Цитата:

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

OData это же протокол. т.е. надо писать где-то на коленке програмку которая будет вызывать эту OData?

Ну это протокол который поддерживает транзакции. А насчет коленок, файлы сами себя не создают, чем одна коленка отличается от другой?

[ax_mct]

Цитата:

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

Ну это протокол который поддерживает транзакции. А насчет коленок, файлы сами себя не создают, чем одна коленка отличается от другой?

Цитата:

OData (Open Data Protocol) is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs. OData helps you focus on your business logic while building RESTful APIs without having to worry about the various approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats, query options, etc. OData also provides guidance for tracking changes, defining functions/actions for reusable procedures, and sending asynchronous/batch requests.

OData RESTful APIs are easy to consume. The OData metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client proxies and tools.

https://www.odata.org/

OData это по сути REST v2 мутировавший в протокол но оставшийся парадигмой. Как бы "фрэйм", но без "ворк". Новая версия ящика для инструмента. Но не сам инструмент.

А инструментом для OData может быть и SSIS и ODBC и web-service как транспорт, и соответственно код бизнес-логики.

Что интересно так это незыблемая популярность ODBC для кросс-вендорной и кросс-платформенной интеграции. Пока не видно что web-service победил ODBC, и походу скорее web-service будет мутировать дальше, а ODBC - вечен. Потому как ODBC это именно надежный и простой молоток.
https://www.cdata.com/drivers/odata/odbc/
https://marketplace.visualstudio.com...DataODBCDriver

Вопрос закладываемых мин и ODBC кстати не раскрыт.

Вот она коленка. Дураки?
When we use Dynamics 365 for Finance and Operations or Microsoft Dynamics AX 2012 and we want to integrate with Microsoft CRM, we can use the CDATA ODBC driver to integrate in an easy way
https://www.to-increase.com/business...crm-salesforce

[EVGL]

Цитата:

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

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

Т.е. вы предложили вашему клиенту создать соответствующие entity, и подключить их через ODBC, учитывая например разницу в структуре между SalesHeaderEntityV2 и SalesTable? Очень хорошо. А то я подумал, что вы напрямую к базе данных подключаетесь.

[ax_mct]

Цитата:

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

Т.е. вы предложили вашему клиенту создать соответствующие entity, и подключить их через ODBC, учитывая например разницу в структуре между SalesHeaderEntityV2 и SalesTable? Очень хорошо. А то я подумал, что вы напрямую к базе данных подключаетесь.

Если рассматривать гипотетическую возможность перехода с AX2012R3 на D365FO то
каков смысл создания своих DIXF/DMF entity в AX2012R3 при интеграции с третьей системой?

Ведь что такое это entity? Это дополнительный слой состоящий из Entity class и Staging table который отсоединяет нас от Target table.

Target table сегодня SalesTable, а завтра SalesHeaderEntityV2. В стандартных entity вендор меняет "незаметно" Target table и подразумевается что это не больно.
А в "своих" entity эта адаптация сама не случиться и тут неважно принадлежат эти свои "Entity class" и "Staging table" к DMF или нет.

Если использовать стандартные entity, к примеру DMFSalesTableEntity то в теории да, переход это облегчит. Но только в случае отсутствия кастомизаций для или около заказа чего я ни на одном проекте не встречал. Это одно из самых перегруженных в AX мест.

В качестве прослойки может прекрасно служить бизнес-логика AIF сервиса, какую пользу могут принести entity - я не понимаю. Чем моя собственная "entity" в виде моего класса и моей Staging таблицы хуже чем DMF?

Напрямую к базе данных - в этом ничего плохого нет. Даже если речь об ODBC в базу AX. Достаточно создать View для создания слоя. В моем же сценарии смотрит AX в чужую базу. И кладет в Staging. Использует внутреннее AIF "API" для работы с бизнес-сущностями. По сути это та же парадигма "DMF" только намного легче.

[EVGL]

Цитата:

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

Напрямую к базе данных - в этом ничего плохого нет. Даже если речь об ODBC в базу AX. Достаточно создать View для создания слоя. В моем же сценарии смотрит AX в чужую базу. И кладет в Staging. Использует внутреннее AIF "API" для работы с бизнес-сущностями. По сути это та же парадигма "DMF" только намного легче.

Понятно. Удачи вам и соболезнования вашему клиенту.

[ax_mct]

Цитата:

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

... закладывая мину и невозможность обновления. Сходить с орбиты пора таким партнерам. Я клиентов, которым так внедряли и кто желает перейти на D365FO, стараюсь обходить стороной: малый бюджет, рутинная работа, которую все равно никто не оценит, зато масса негативных эмоций со стороны клиента.

Цитата:

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

Понятно. Удачи вам и соболезнования вашему клиенту.

Ну коль мы уходим от существа вопроса так красиво то и я тогда про ту самую орбиту скажу.

Цитата:

Это - люди, которых я называю Астронавтами Архитектуры. Очень трудно заставить их писать код или проектировать программы, потому что они не перестают думать об Архитектуре. Они астронавты, потому что они находятся выше уровня кислорода, и я не понимаю, как они дышат. Они, как правило, работают в действительно больших компаниях, которые могут позволить себе иметь много непроизводительных людей с действительно большими учеными степенями, но, по сути, не вносящими вклада в результат.

Спасибо тем не менее.

[ax_mct]

В качестве заметки про
Data Import/Export Framework (DIXF)
https://docs.microsoft.com/en-us/dyn...guide-dixf-dmf


For import, you can use any of the following sources:

AX – Import data from another Microsoft Dynamics AX instance.
ODBC – Import data from another database, such as Microsoft SQL Server or Microsoft Access.
File – Import data from a fixed-width or delimited text file, XML file, or Microsoft Excel file.

То есть не совсем понятно насколько в принципе DMF уместно для постоянной интеграции в AX2012.
При этом нет web-service но есть ODBC. И это правильно.

А вот в D365FO использует смесь DMF с AIF и BizTalk.
Recurring integrations
https://docs.microsoft.com/en-us/dyn...g-integrations

ODBC в предлагаемых вариантах стратегии интеграции не упоминается.


https://docs.microsoft.com/en-us/dyn...d-ops/toc.json

И о дикарском остальном мире
Тот же отсталый SAP со своим убогим HANA

Цитата:

You can build a custom .NET application (using C++, C#, Visual Basic and so on) that runs in an external application environment but connects directly to an SAP HANA data model using the client ODBC interface.

https://help.sap.com/viewer/52715f71...e3.html?q=ODBC

Пособолезнуем клиентам HANA. Бедняги, чо.

[lvan]

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

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

[mazzy]

Data Entity, CDM...
При текущей политике разработки внутри MS не взлетит, конечно.
И дело вовсе не в технической составляющей вопроса.

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

Понятный и хороший шаблон.
Фасад сосредотачивает в себе знания о внутреннем устройстве системы. А следовательно любой недостаток внутри системы в первую очередь проявится как ошибка при работе с фасадом.

На это свойство фасада накладывается свойство организации разработки в MS - у каждого объекта есть владелец. Владелец в своими KPI отвечает за отсутствие ошибок в объекте и должен одобрять/отклонять любые изменения объекта, которые предлагают другие команды разработчиков.

Теперь представьте себя на месте тимлида команды, которая отвечает за Фасад.

• Ваши действия если разработчик вашей команды предлагает создать Data entity?
• Ваши действия если разработчик чужой команды предлагает добавить какую-то хрень в вашу Data entity?
• Ваши действия если разработчик чужой команды предлагает что-то изменить в вашей замечательной Data entity?
• Ваши действия если програм-менеджер (так в MS называются консультанты) предлагает расширить функционал вашей Data entity каким-то левым функционалом, который нужен одной стране (Индии там, Бразилии или Польше. Или, прости господи, России?)

Прежде чем ответить, давайте вспомним, есть ли фасады в существующей Аксапте?
Конечно же есть! Навскидку это InventMovement и FormLetter.
Замечательные фасады. Были когда-то. Сильно устарели три-четыре версии Аксапты назад.

Вспомните как MS добавляет новые типы складских проводок или новые типы документов. Российские Выдача подотчетнику, Счет на оплату и Счет-фактура - жалкие подобия документов которые делаются в Индии и Бразилии, Испания и все испаноязычные страны с CFDI, Ирландия и даже США с Witholding tax. Суть модификаций там очень похожа на российские книги продаж/покупок

MS модифицирует фасад? Нет, конечно.
Конечно же в памяти тут же всплывают всякие ТОРО, интеграция с зарплатой и Human Resource... А, извините, майкрософт такого так и не сделал. Это партнеры развлекались

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

Почему? Снова представьте себя на месте тимлида, которому... Ну зачем ему становиться владельцем объекта, который будет принимать на себя ошибки других команд? А еще поддерживать апгрейд этих Entity при смене версии Аксапты. Особенно если другие команды накосячили сделали доработки в своих таблицах.

upd - спасибо за комментарии, это утверждение устарело: Ну, и стоит подумать почему в существующей версии аксапты Data Entity созданы только для справочников и параметров. Если у кого есть доступ, то стоит почитать документ обоснование для этого решения.

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

[Vadik]

Цитата:

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

Ну, и стоит подумать почему в существующей версии аксапты Data Entity созданы только для справочников и параметров

И журналов. И ордеров (заказов). И проводок (GeneralJournalAccountEntryEntity).

Цитата:

Если у кого есть доступ, то стоит почитать документ обоснование для этого решения

А каким там годом документ датирован?

[mazzy]

Цитата:

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

И журналов. И ордеров (заказов). И проводок (GeneralJournalAccountEntryEntity).

а. таки начали делать?
и много документов уже сделали? уже покрыли весь функционал аксапты?

upd: Каков механизм апгрейда Data Entity в мажорных и минорных билдах современной аксапты?
(Безо всякого ёрничания. Мне в самом деле интересно)

Цитата:

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

А каким там годом документ датирован?

Я читал его, когда я там работал. В 2017.

[fed]

Цитата:

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

а. таки начали делать?
и много документов уже сделали? уже покрыли весь функционал аксапты?

Народ в яммере регулярно жалуется, что даже в настроечных таблицах не все поля/таблицы покрыты. Кроме того - в последнее время Микрософт стал официально пользоваться в своей документации понятием "Golden Copy", которое еще год назад было, скорее, неформальным термином. Так что похоже что от идеи покрытия всего и вся data entity и быстрого переноса конфигурации через data entity - уже отказались.

[Vadik]

Цитата:

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

а. таки начали делать?

"Давно" - понятие относительное. У нас на проектах интеграции на стандартных daily journals работают с прошлого года (7.2), заказы на продажу - с 2017. В BYOD тоже используем понемногу

Цитата:

и много документов уже сделали? уже покрыли весь функционал аксапты?

"Дяденька, я же не настоящий сварщик" (с). С такими вопросами надо к экспертам по ERP и энтерпрайзу. Я же тут так, примус починяю

[EVGL]

Цитата:

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

уже покрыли весь функционал аксапты?

Счет пошел уже на тысячи, но нет, еще не все покрыли. Редко, но встречаются entity, которых не хватает. Из последнего:
https://experience.dynamics.com/idea...1-0003ff68c55f

[mazzy]

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

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

[Vadik]

Цитата:

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

Народ в яммере регулярно жалуется, что даже в настроечных таблицах не все поля/таблицы покрыты.Так что похоже что от идеи покрытия всего и вся data entity и быстрого переноса конфигурации через data entity - уже отказались

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