Цитата:
Сообщение от
MazZzDaI
Как насчёт вызова XQuery из AX7?
думаю, что вопрос о поиске в xml стоит разбить на три части:
1. как получить информацию из Аксапты, чтобы засунуть в xml
2. каким инструментом пользоваться для поиска внутри xml
3. а вообще как правильно искать по объектам АОТ
поехали.
============================
0.
да, раньше был универсальный подход treenode для поиска любого узла в дереве АОТ. причем искать можно было на любом уровне.
да, в акс7 я не вижу подобных универсальных енумераторов дерева. может быть, пока слишком неопытен и просто не знаю о подобных способах.
да, то, что сделали с метаданными по экстеншенами иначе как вредительство и не назовешь:
представьте, что у вас есть исходная таблица и есть несколько экстеншенов этой таблицы с полями (новые/переопределенные), с индексами (новые/переопределенные), с delete action, relation и прочей чешуей.
так вот, штатные методы позволяют работать либо с исходным определением таблицы, либо с каждый экстеншеном отдельно. но штатные методы не позволяют получить итоговое описание - какие поля, индексы и прочая чешуя получились в итоге.
либо я чего-то кардинально не знаю и не понимаю в этом механизме.
понимаю только, что разработчикам внутри майкрософта пока вполне достаточно существующего - им достаточно информации о базовой версии.
но рано или поздно и разработчики мс начнут делать патчи-сервис-паки и прочие обновления. и им придется таки вплотную заняться работой с экстеншенами.
кроме того, сейчас идет процесс digital transformation, в рамках которого большие системы раздербаниваются на маленькие сервисы. а несколько различных сервисов вполне могут быть уложены в один инстанс-тенант.
в общем, по логике вещей, я бы ожидал изменений в метаданных. каких - не знаю.
1. как получить информацию, чтобы засунуть в xml
в связи с вышеизложенным:
считаю что собирать информацию о метаданных нужно через API.
и ни в коем случае не через обращение к файлам в операционной системе.
2. каким инструментом пользоваться для поиска внутри xml
есть много инструментов для работы с отдельными XML, с наборами XML.
но не стоит забывать, что Microsoft Dynamics в большинстве случаев будет работать в облаке.
поэтому нужен такой инструмент, чтобы работал в облаке, учитывал ограничения и возможности Ажура и при этом не приводил к большим накладным расходам при тарификации.
в связи с этим, xBase нужно о-о-очень детально обосновывать.
засовывать xBase в облако? а сколько это будет стоить? какие требования к оборудованию сразу возникнут?
держать xBase за облаком? права? цена синхронизации с файловой системой в облаке? как часто придется синхронизировать? смогут ли работать какие-нибудь аксапта-аддоны с xBase, который находится за облаком?
Понятно, что xBase вполне подойдет в качестве Proof of Concept .
Но нужны очень веские обоснования, чтобы использовать продукты третьих лиц на продакте в облаке.
В то время, как MS SQL уже есть в аксапта-облаке, уже умеет работать с XML (да, у него свои тараканы) и содержит встроенные инструменты запросов к XML (о, да! у него есть тараканы). Правда и здесь нужно убедиться, что МС не зарезал эту функциональность в облачном варианте.
В любом случае, разработчик должен учитывать, что аксапта в большинстве случаев живет в облаке. и обосновывать свой выбор ПО.
3. а вообще как правильно искать по объектам АОТ
если посмотреть в аксаптовские dll, то можно увидеть
Microsoft.Dynamics.AX.Metadata.Search.dll
если посмотреть на эту dll в Object Explorer, то можно увидеть предельно запутанный API с крайне забавственными интерфейсами. Не удивлюсь, что там уже содержится не одно поколение программного кода.
Но даже при таком запутанном интерфейсе, мне кажется, что лучше пользоваться этим search API, нежели заниматься выгрузкой/синхронизацией с внешней базой. не важно где и как она будет хранить метаданные.
и из-за проблем с несинхронизированными данными.
и из-за того, что при изменении структуры файлов неизбежно должны измениться и запросы к этим файлам.
примерно так.
другими словами:
использование внешней базы с метаданными на продакте должно очень и очень подробно обосновываться.
обсуждение подобных способов без обоснования я бы воспринимал как косяк в работе архитектора-консультанта.
хотя как программисткая задача это очень даже интересная задача.