16.08.2017, 14:23 | #21 |
Участник
|
https://gist.github.com/mazzy-ax/4d4...7527623467aee8
X++: class Tables { public static void Main(Args _args) { str aosServiceBin = 'C:\AOSService\webroot\bin'; str packageDir = 'C:\AOSService\PackagesLocalDirectory'; //or var environment = Microsoft.Dynamics.ApplicationPlatform.Environment.EnvironmentFactory::GetApplicationEnvironment(); packageDir = environment.get_Aos().get_PackageDirectory(); // it's kind of magic var runtimeProviderConfiguration = New Microsoft.Dynamics.AX.Metadata.Storage.Runtime.RuntimeProviderConfiguration(packageDir); var metadataProviderFactory = New Microsoft.Dynamics.AX.Metadata.Storage.MetadataProviderFactory(); var provider = metadataProviderFactory.CreateRuntimeProvider(runtimeProviderConfiguration); // object names print provider.Tables.ListObjectsForModel('FleetManagement'); print provider.Tables.ListObjectsForModel('FleetManagementExtension'); print provider.TableExtensions.ListObjectsForModel('FleetManagement'); print provider.TableExtensions.ListObjectsForModel('FleetManagementExtension'); // single object by name var custTransMetaData = provider.Tables.Read('CustTrans'); } } https://gist.github.com/mazzy-ax/292...fc753bfca9c529 Код: #Powershell $aosServiceBin = 'C:\AOSService\webroot\bin' $packageDir = 'C:\AOSService\PackagesLocalDirectory' # or add-type -path (Join-Path $aosServiceBin 'Microsoft.Dynamics.ApplicationPlatform.Environment.dll') $environment = [Microsoft.Dynamics.ApplicationPlatform.Environment.EnvironmentFactory]::GetApplicationEnvironment() $packageDir = $environment.get_Aos().get_PackageDirectory() # it's kind of magic add-type -path (Join-Path $aosServiceBin 'Microsoft.Dynamics.Ax.Metadata.Storage.dll') $runtimeProviderConfiguration = New-Object Microsoft.Dynamics.AX.Metadata.Storage.Runtime.RuntimeProviderConfiguration $packageDir $metadataProviderFactory = New-Object Microsoft.Dynamics.AX.Metadata.Storage.MetadataProviderFactory $provider = $metadataProviderFactory.CreateRuntimeProvider($runtimeProviderConfiguration) # object names $provider.Tables.ListObjectsForModel('FleetManagement').count $provider.Tables.ListObjectsForModel('FleetManagementExtension').count $provider.TableExtensions.ListObjectsForModel('FleetManagement').count $provider.TableExtensions.ListObjectsForModel('FleetManagementExtension').count # single object by name $provider.Tables.Read('CustTrans') Последний раз редактировалось mazzy; 16.08.2017 в 14:41. |
|
|
За это сообщение автора поблагодарили: trud (5), gl00mie (5). |
16.08.2017, 17:12 | #22 |
Участник
|
Как насчёт вызова XQuery из AX7?
Понятно что проблему с мусором в каталоге АОСа это не решает, но позволяет использовать поиск по метадате как в посте №7 Об этой возможности рассказал Peter Villadsen на технической конференции 2017 года по Dynamics 365. Пример использования через GUI Годная реализация XQuery для .NET Считаю это правильным т.к. с файловой базой данных необходимо работать соответствующим инструментом. |
|
16.08.2017, 19:03 | #23 |
Участник
|
думаю, что вопрос о поиске в 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, нежели заниматься выгрузкой/синхронизацией с внешней базой. не важно где и как она будет хранить метаданные. и из-за проблем с несинхронизированными данными. и из-за того, что при изменении структуры файлов неизбежно должны измениться и запросы к этим файлам. примерно так. другими словами: использование внешней базы с метаданными на продакте должно очень и очень подробно обосновываться. обсуждение подобных способов без обоснования я бы воспринимал как косяк в работе архитектора-консультанта. хотя как программисткая задача это очень даже интересная задача. Последний раз редактировалось mazzy; 16.08.2017 в 19:23. |
|
17.08.2017, 10:30 | #24 |
NavAx
|
А как искать, если нет xml, закрытое ISV решение?
XML - не вариант, т.к. его может не быть. PS. Наткнулся вот на такую вещь: X++: var resourceObject = Microsoft.Dynamics.Ax.Xpp.MetadataSupport::GetResource(this.templateName()); Последний раз редактировалось raz; 17.08.2017 в 10:36. |
|
17.08.2017, 10:43 | #25 |
Участник
|
Ну....
Да, методов много. Они делают одно и то же. Только для разных типов объектов. Есть методы для таблиц, для классов, для ресурсов, для menuitem и так далее. |
|
Теги |
ax2012, ax7, модель |
|
|