|
25.02.2019, 14:10 | #1 |
Banned
|
Цитата:
Цитата:
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 может быть и 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 |
|
25.02.2019, 14:18 | #2 |
Banned
|
Цитата:
|
|
25.02.2019, 17:58 | #3 |
Banned
|
Цитата:
каков смысл создания своих 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" только намного легче. |
|
27.02.2019, 00:13 | #4 |
Banned
|
В качестве заметки про
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.
Пособолезнуем клиентам HANA. Бедняги, чо. |
|
27.02.2019, 05:03 | #5 |
Участник
|
Я слышал, что в планах есть что-то типа Common Data Model (CDM), но в немного другом виде.
т.е. все вендоры, типа SAP, SalesForce, Microsoft придут к единой модели ентитей, что позволит упростить все интеграции Видел даже презентацию, но забыл название, поищу про ODBC смешно вы пишете тут. я это слово уже лет 10 не слышал Последний раз редактировалось lvan; 27.02.2019 в 05:10. |
|
16.04.2019, 21:27 | #6 |
Участник
|
Цитата:
Сообщение от lvan
Я слышал, что в планах есть что-то типа Common Data Model (CDM), но в немного другом виде.
т.е. все вендоры, типа SAP, SalesForce, Microsoft придут к единой модели ентитей, что позволит упростить все интеграции Видел даже презентацию, но забыл название, поищу про ODBC смешно вы пишете тут. я это слово уже лет 10 не слышал вот нашел https://aka.ms/opendatainitiative единая открытая модель данных будет работать поверх Azure Data Lake интеграция с AX в превью уже есть https://docs.microsoft.com/en-us/dyn...tore-data-lake заменит embedded power BI релизнуть обещают осенью, причем вроде грозятся Biz Central и CE тоже успеть Последний раз редактировалось lvan; 16.04.2019 в 21:30. |
|
17.04.2019, 03:43 | #7 |
Banned
|
Почитал и понял что это data warehouse для AI прежде всего и есть симбиоз типа
Клиенты от SAP, софт AI от Adobe, облако от MS. MS будет будет доить за железо, Adobe за AI софт, SAP за адаптеры. Как все это упростит интеграцию если для интеграции не предназначено? Я даже не уверен что сама концепция data entity вообще как то относится к интеграции. То есть для чтения данных - да и для BI/AI - да. Но для записи и интеграции эти денормализованные таблицы/view как концепция не имеют смысла. Как некие Staging tables/journals, со стороны кладут, система разносит? Не ну высокие заборы дело полезное но когда все огораживают и вход по билетам, то мне пожалуйста дайте ODBC Потому как мне с тех билетов ничего не причитается. |
|
17.04.2019, 09:39 | #8 |
Moderator
|
Цитата:
Сообщение от lvan
будет работать поверх Azure Data Lake
интеграция с AX в превью уже есть https://docs.microsoft.com/en-us/dyn...tore-data-lake заменит embedded power BI релизнуть обещают осенью, причем вроде грозятся Biz Central и CE тоже успеть |
|
|
За это сообщение автора поблагодарили: Alexius (4). |
22.04.2019, 21:29 | #9 |
Участник
|
Цитата:
Сообщение от fed
Его первый раз обещали еще прошлой осенью, версии 8.0. Потом релиз перенесли на март, теперь вот на следующую осень. При этом, заметная часть клиентов просто просит read-only доступ к своей БД в Azure, чтобы оттуда переливать данные в локальный Data Warehouse. Но вместо этого клиентам опять пытаются всучить какие-то передовые (читай - глюкавые и неотлаженые) технологии, с целью поднять бабла на продаже этих самых Azure Data Lakes.
1) MS просто как обычно догоняет конкурентов, их главного конкурента AWS, с аналогом Kinesis. 2) Это BLOB хранилище, которое подразумевает хранения не только табличек а любого барахла: А - Такое хранение значитально дешевле чем в SQL. Б - На это дело натравливаются бигдатеры со своим Hadoop, которые ворочат всю эту кашу своими map-reduce алгоритмами. Касаемо интеграций. Для RealTime, более менее отлаженый и maintanble подход - через Retail Server. Он в своих кишках общается с Ax через умирющий SOAP, по прежнему, но свои задачи выполняет, модифицируется не сложно. Наружу выдаётся RetailServer API, которое всякие дот-нетчики могут поставить через Nuget пакеты. Для остальных не-RealTime задач десятки подходов которые здесь обсуждались, все имеют место быть, зависит от задачи. Из того что не обсуждалось - Azure Event Hub, Service Bus. Или самый дешевый и простой - те же Messages (Storage Account). |
|
|
За это сообщение автора поблагодарили: EVGL (3), Vadik (1). |
22.04.2019, 22:01 | #10 |
Banned
|
Цитата:
Сообщение от Jackally
Касаемо интеграций. Для RealTime, более менее отлаженый и maintanble подход - через Retail Server. Он в своих кишках общается с Ax через умирющий SOAP, по прежнему, но свои задачи выполняет, модифицируется не сложно. Наружу выдаётся RetailServer API, которое всякие дот-нетчики могут поставить через Nuget пакеты. Для остальных не-RealTime задач десятки подходов которые здесь обсуждались, все имеют место быть, зависит от задачи. Из того что не обсуждалось - Azure Event Hub, Service Bus. Или самый дешевый и простой - те же Messages (Storage Account).
Ваши предложения? Не нашел что такое Messages (Storage Account). Уж не обработка ли email? |
|
22.04.2019, 23:41 | #11 |
Участник
|
Цитата:
|
|
|
За это сообщение автора поблагодарили: ax_mct (5), Jackally (1). |
23.04.2019, 10:14 | #12 |
Moderator
|
Цитата:
Сообщение от Jackally
Не много другая идея:
1) MS просто как обычно догоняет конкурентов, их главного конкурента AWS, с аналогом Kinesis. 2) Это BLOB хранилище, которое подразумевает хранения не только табличек а любого барахла: А - Такое хранение значитально дешевле чем в SQL. Б - На это дело натравливаются бигдатеры со своим Hadoop, которые ворочат всю эту кашу своими map-reduce алгоритмами. Просто все равно задача "перенести данные из D365FOE в локальную БД" остается. Вот я и интересуюсь, можно ли ее, пусть даже через Azure Data Lake решить... |
|
27.02.2019, 10:35 | #13 |
Участник
|
Data Entity, CDM...
При текущей политике разработки внутри MS не взлетит, конечно. И дело вовсе не в технической составляющей вопроса. Entity, CDM - это частные случаи шаблона проектирования фасад. Понятный и хороший шаблон. Фасад сосредотачивает в себе знания о внутреннем устройстве системы. А следовательно любой недостаток внутри системы в первую очередь проявится как ошибка при работе с фасадом. На это свойство фасада накладывается свойство организации разработки в MS - у каждого объекта есть владелец. Владелец в своими KPI отвечает за отсутствие ошибок в объекте и должен одобрять/отклонять любые изменения объекта, которые предлагают другие команды разработчиков. Теперь представьте себя на месте тимлида команды, которая отвечает за Фасад.
Прежде чем ответить, давайте вспомним, есть ли фасады в существующей Аксапте? Конечно же есть! Навскидку это InventMovement и FormLetter. Замечательные фасады. Были когда-то. Сильно устарели три-четыре версии Аксапты назад. Вспомните как MS добавляет новые типы складских проводок или новые типы документов. Российские Выдача подотчетнику, Счет на оплату и Счет-фактура - жалкие подобия документов которые делаются в Индии и Бразилии, Испания и все испаноязычные страны с CFDI, Ирландия и даже США с Witholding tax. Суть модификаций там очень похожа на российские книги продаж/покупок MS модифицирует фасад? Нет, конечно. Конечно же в памяти тут же всплывают всякие ТОРО, интеграция с зарплатой и Human Resource... А, извините, майкрософт такого так и не сделал. Это партнеры развлекались Один из последних фасадов - AIF-DIXF. Который задумывался как О-го-го интеллектуальный! А в итоге получился еще одним транспортным уровнем. Который вдобавок отвратительно работает с локализацией. Почему? Снова представьте себя на месте тимлида, которому... Ну зачем ему становиться владельцем объекта, который будет принимать на себя ошибки других команд? А еще поддерживать апгрейд этих Entity при смене версии Аксапты. Особенно если другие команды upd - спасибо за комментарии, это утверждение устарело: В общем, любой фасад - это конечно хорошо. Для потребителя. И Последний раз редактировалось mazzy; 27.02.2019 в 11:15. |
|
27.02.2019, 10:48 | #14 |
Модератор
|
Цитата:
Цитата:
Если у кого есть доступ, то стоит почитать документ обоснование для этого решения
__________________
-ТСЯ или -ТЬСЯ ? |
|
27.02.2019, 10:55 | #15 |
Участник
|
Цитата:
и много документов уже сделали? уже покрыли весь функционал аксапты? upd: Каков механизм апгрейда Data Entity в мажорных и минорных билдах современной аксапты? (Безо всякого ёрничания. Мне в самом деле интересно) Я читал его, когда я там работал. В 2017. Последний раз редактировалось mazzy; 27.02.2019 в 11:01. |
|
27.02.2019, 11:07 | #16 |
Moderator
|
Народ в яммере регулярно жалуется, что даже в настроечных таблицах не все поля/таблицы покрыты. Кроме того - в последнее время Микрософт стал официально пользоваться в своей документации понятием "Golden Copy", которое еще год назад было, скорее, неформальным термином. Так что похоже что от идеи покрытия всего и вся data entity и быстрого переноса конфигурации через data entity - уже отказались.
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
27.02.2019, 11:20 | #17 |
Модератор
|
Просто у Сунила и его команды много других блестящих игрушек, а задачи по протаскиванию нового функционала через data entities ему не всегда вовремя ставят. Приходится пинать, в том числе через Yammer
__________________
-ТСЯ или -ТЬСЯ ? |
|
27.02.2019, 11:10 | #18 |
Модератор
|
"Давно" - понятие относительное. У нас на проектах интеграции на стандартных daily journals работают с прошлого года (7.2), заказы на продажу - с 2017. В BYOD тоже используем понемногу
Цитата:
и много документов уже сделали? уже покрыли весь функционал аксапты?
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
27.02.2019, 11:12 | #19 |
Banned
|
Счет пошел уже на тысячи, но нет, еще не все покрыли. Редко, но встречаются entity, которых не хватает. Из последнего:
https://experience.dynamics.com/idea...1-0003ff68c55f |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
27.02.2019, 11:19 | #20 |
Участник
|
Vadik, EVGL, спасибо за комментарии. Утверждение про "Data Entity для справочников и параметров в существующей версии аксапты" пометил как удаленное.
К остальным утверждениям и вопросам в моем посте замечания/дополнения есть? |
|
Теги |
#msftadvocate, aif, абстракции, закопаем стюардессу, индийская кухня, интеграция, как правильно, холивар |
|
|