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

[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

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

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

Цитата:

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

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