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

[trud]

Цитата:

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

Ладно там если веб-сервисы, но вот зачем мне XSD, XML чтобы прочитать из JSON файла? Какая мне польза как программисту от AIF как инструмента при импорте из файла?

Ну в этом случае обычно пишут функции трансформации(к примеру на Azure serverless functions + еще можно LogicApps пределать). т.е. они преобразуют JSON к XML, а потом уже в дело вступает AIF.
Для вас плюсом сразу добавляется элемент Job security, т.е. заменить вас после написания такого будет непросто

[ax_mct]

Цитата:

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

Ну в этом случае обычно пишут функции трансформации(к примеру на Azure serverless functions + еще можно LogicApps пределать). т.е. они преобразуют JSON к XML, а потом уже в дело вступает AIF.
Для вас плюсом сразу добавляется элемент Job security, т.е. заменить вас после написания такого будет непросто

Как раз наоборот, поддерживать самописку/коленку другому программисту на порядок проще. Fed тоже об этом упомянул в данной теме и полностью с этим согласен. Деление на классы понятное всем даже консультанту, простота дебага и лога.

Я конечно могу завернуть все во множество паттернов так чтобы все запутать, но как-то все это уже давно перерос. Всегда пишу для маньяка с топором который знает где я живу.

А вот если прокручивать все это через мясорубку якобы стандартную то тогда как раз я такой буду один который все это безумие держит в голове. Кстати как аксаптер я уверен в том что моя самописка и есть натуральный стандарт аксапты, в то время как использовать Azure, LogicApps, AIF для того чтобы импортировать текстовый файл это полное ЛБГТ.

[lvan]

Цитата:

Сообщение от 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 тоже успеть

[ax_mct]

Цитата:

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

единой модели ентитей, что позволит упростить все интеграции

Почитал и понял что это data warehouse для AI прежде всего и есть симбиоз типа
Клиенты от SAP, софт AI от Adobe, облако от MS.
MS будет будет доить за железо, Adobe за AI софт, SAP за адаптеры.

Как все это упростит интеграцию если для интеграции не предназначено?

Я даже не уверен что сама концепция data entity вообще как то относится к интеграции.
То есть для чтения данных - да и для BI/AI - да.
Но для записи и интеграции эти денормализованные таблицы/view как концепция не имеют смысла.

Как некие Staging tables/journals, со стороны кладут, система разносит? Не ну высокие заборы дело полезное но когда все огораживают и вход по билетам, то мне пожалуйста дайте ODBC Потому как мне с тех билетов ничего не причитается.

[fed]

Цитата:

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

будет работать поверх Azure Data Lake

интеграция с AX в превью уже есть https://docs.microsoft.com/en-us/dyn...tore-data-lake
заменит embedded power BI

релизнуть обещают осенью, причем вроде грозятся Biz Central и CE тоже успеть

Его первый раз обещали еще прошлой осенью, версии 8.0. Потом релиз перенесли на март, теперь вот на следующую осень. При этом, заметная часть клиентов просто просит read-only доступ к своей БД в Azure, чтобы оттуда переливать данные в локальный Data Warehouse. Но вместо этого клиентам опять пытаются всучить какие-то передовые (читай - глюкавые и неотлаженые) технологии, с целью поднять бабла на продаже этих самых Azure Data Lakes.

[skuull]

С помощью BYOD можно экспортировать в SQL Server, проблема только в том чтобы наклепать дата энтитей, но они вам все равно нужны только на чтение и не для всех таблиц, так что давно можно было сделать. Экспортите себе инкрементео хоть каждую минуту, в чем проблема?

Data Lake можно пощупать уже сейчас, это как раз горячо любимые многими файлы в Azure Storage Account, но пока это только aggregated measurements которые мало кто и так использует.

[fed]

Цитата:

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

С помощью BYOD можно экспортировать в SQL Server, проблема только в том чтобы наклепать дата энтитей, но они вам все равно нужны только на чтение и не для всех таблиц, так что давно можно было сделать. Экспортите себе инкрементео хоть каждую минуту, в чем проблема?

Можно, но:

1. Почему бы просто не дать клиентам read-only доступ к основной БД ? Зачем умножать сущности сверх необходимости ? Также стоит вспомнить про классический "принцип биплана": Самолет с двумя парами крыльев ломается в два раза чаще чем с одной.
2. Entity для транзакционных сущностей надо еще разработать.
3. Инкрементальный экспорт работает не очень устойчиво.Если бы он устойчиво работал, вряд ли бы пришлось Микрософту писать толстый батч для перекачки из основной БД в Data Warehouse, который каждый раз с ноля данные перезаливает .
4. Клиенту надо платить за еще один Azure SQL инстанц, который реально нужен только для того чтобы перекачать данные в его собственную локальную БД. При этом - эта Azure SQL БД, это уже не второе крыло, а третье, поскольку по дороге из нее в локальную базу данных тоже что-то отсохнуть может.

Ну то есть - я могу согласиться что Power BI полезен для не очень больших клиентов (в пределах 40 рабочих мест на круг - не только для D365). Но если клиент большой, то у него наверняка стоят какие-то другие системы (типа MES или систем бюджетирование или еще чего-то подобного), наверняка есть какой-то тул для бизнес-аналитики, которому надо данные и из этих систем качать и из аксапты. Так вот - зачем заставлять клиента так мучаться,если достаточно было просто открыть R/O доступ к основной базе данных ?

[skuull]

Цитата:

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

[*]Клиенту надо платить за еще один Azure SQL инстанц, который реально нужен только для того чтобы перекачать данные в его собственную локальную БД. При этом - эта Azure SQL БД, это уже не второе крыло, а третье, поскольку по дороге из нее в локальную базу данных тоже что-то отсохнуть может.

Я писал об экспорте в SQL Sever, а не Azure SQL, т.е.напрямую, зачем вам прослойка?

Нет смысла спорить, что с доступом в базу было бы проще, но его нет. entity надо разработать, но за 2 года любой партнёр уже мог их наразрабатывать и продавать пачкой. Список будет примерно одинаковый.

Итак у вас есть entities и выгрузка в локальный SQL, что вам ещё не хватает ?

[fed]

Цитата:

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

Я писал об экспорте в SQL Sever, а не Azure SQL, т.е.напрямую, зачем вам прослойка?

Может быть он напрямую и работает (не пробовал), но поддерживается ли он ? Во вторых - не факт что клиент захочет свой основной Data Warehouse в интернет открывать, так что скорее всего придется отдельный сервер БД ставить (и лицензию покупать), через который все равно придется данные протягивать.
Я пожалуй добавлю, что я это все написал просто по мотивам вопросов пары клиентов. То есть - можно мне долго чего-то доказывать, но клиенты просто спрашивают - почему им надо платить дополнительные деньги, за что-то заведомо менее надежное чем был бы простой прямой доступ к БД? И я в общем не могу ничего другого ответить кроме как "Потому что это - Microsoft". Вопрос - хорошо ли это для самого Микрософта в долгосрочной перспективе?

[lvan]

сюда напшите, или в яммер https://experience.dynamics.com/idea...d%20Operations

[ax_mct]

Цитата:

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

Почему бы просто не дать клиентам read-only доступ к основной БД ?

Самое базовая причина полагаю это сдвинутость на защите информации клиента ото всех включая клиента как sales point (security compliance certifications, HIPAA etc )
https://docs.microsoft.com/en-us/azu...urity-overview

Думаю что варианты с тем же ODBC тоже можно реализовать с этим всем compliance но оно им зачем. То есть для них одни минусы.

[skuull]

Цитата:

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

Самое базовая причина полагаю это сдвинутость на защите информации клиента ото всех включая клиента как sales point (security compliance certifications, HIPAA etc ).

MS говорит, что это производительность, типа не надо отчёты гонять по продакшен базе, а потом говорить что все медленно.

[ax_mct]

Цитата:

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

MS говорит, что это производительность, типа не надо отчёты гонять по продакшен базе, а потом говорить что все медленно.

Очень может быть так как статистика использования портится. Да и тот же ODBC в целом к Azure SQL не запрещен и это только особенность D365FO. Скорее всего производительность настолько больное место у продукта что не хотят хоть как-то еще ухудшать.

[fed]

Цитата:

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

MS говорит, что это производительность, типа не надо отчёты гонять по продакшен базе, а потом говорить что все медленно.

Гм. Насколько я помню, у микрософта нету никаких SLA по производительности D365FO. То есть - даже если у клиента медленно, им сейчас в целом - все равно. Соответственно - не понятно почему их в таком случае производительность беспокоит...

[trud]

Цитата:

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

Скорее всего производительность настолько больное место у продукта что не хотят хоть как-то еще ухудшать.

Обращаясь к DataEntity через OData можно также положить систему. и даже хуже, ибо DataEntity может содержать расчеты. я думаю им просто нужно продавать Flow и прочие LogicApps. поэтому MVP и слагают поэмы и доступ ограничивают(чтобы народ стал использовать флоу)

[fed]

Цитата:

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

Обращаясь к DataEntity через OData можно также положить систему. и даже хуже, ибо DataEntity может содержать расчеты. я думаю им просто нужно продавать Flow и прочие LogicApps. поэтому MVP и слагают поэмы и доступ ограничивают(чтобы народ стал использовать флоу)

Ну судя по последнему маркетинговому пушу в сторону Flow и PowerApps, народ как раз все понял и покупает все это очень неважно. "Скажи мне какой продукт MS маркетит, и я скажу тебе какой продукт они скоро закроют в связи с убыточностью и низкой adoption rate"

[ax_mct]

Цитата:

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

Обращаясь к DataEntity через OData можно также положить систему. и даже хуже, ибо DataEntity может содержать расчеты. я думаю им просто нужно продавать Flow и прочие LogicApps. поэтому MVP и слагают поэмы и доступ ограничивают(чтобы народ стал использовать флоу)

Ну все же все что за DataEntity стенкой не меняет и не создает сами запросы то есть можно заранее создавать табличные индексы. А c ODBC нужно создавать табличные индексы по факту использования ODBC наружным приложением, то есть уже индивидуальное администрирование, а не всех разом. Они же смотрят на потенциальные сотни тысяч D365FO клиентов и конечно не могут себе такого позволить

[fed]

Цитата:

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

А c ODBC нужно создавать табличные индексы по факту использования ODBC наружным приложением, то есть уже индивидуальное администрирование, а не всех разом.

Automatic tuning in Azure SQL Database.

[ax_mct]

Цитата:

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

Automatic tuning in Azure SQL Database.

continuous performance tuning based on AI and machine learning.

Как же я отстал от прогресса

[Jackally]

Цитата:

Сообщение от 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).