Обновление данных в Ax 365

[axm2017]

Привет всем.

Возникла необходимость в связи с добавлением новых полей и логики в таблицы обновить данные на продуктовом приложении путем выполнения каких либо скриптов.

Как сейчас в 365 это делается?

На сколько помню ранее в 12 был функционал для подобных вещей ReleaseUpdate*
и вроде даже пользователь мог запускать этот функционал сам.

В 365 вижу классы данного семейства а есть какое то меню и т прочее?

ЗЫ заодно чтобы два раза не ходить + помнить
Вижу функционал Data maintenance portal который в чем то схож но это другой вроде framework.

[trud]

Ну самое простое написать класс-джоб и запустить его потом вручную.
Также что-то есть в механизме фич, там можно обрабатывать событие включения фичи

[sukhanchik]

Цитата:

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

Вижу функционал Data maintenance portal который в чем то схож но это другой вроде framework.

Функционал Data maintenance скорее предназначен для формирования регулярных периодических операций, которые нужно сделать админам. Типа кэш аналитик сбросить или комбинации перестроить.
Хотя да, данный функционал анализирует наличие новых периодических операций, которые придут в программном коде.

Если покопать классы ReleaseUpdate* и посмотреть на метод ReleaseUpdateCockpit.run(), то можно "добраться" до веб-сервиса UpgradeService и его метода ScheduleUpgrade. Он как раз все ReleaseUpdate-джобики ставит в пакетники.

Полный путь вызова веб-сервиса такой: https://<URL>/api/services/upgradeservicegroup/upgradeservice/ScheduleUpgrade

Полагаю, что сей веб-сервис надо каким-то способом вызвать и запустятся ReleaseUpdate-джобики. В интерфейсе вызовов я не нашел.
Сразу скажу - выводы сделал просто анализируя код - решение не проверял. На проектах обычно никто не заморачивается (программирование контрольных списков обычно никто не оплачивает) и запускают класс-джоб из командной строки так, как написал trud

[axm2017]

Цитата:

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

..Если покопать классы ReleaseUpdate* и посмотреть на метод..

Видел это но тоже не нашел отражения в нормальном интерфейсе + какого либо описания как и что делать.

Цитата:

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

и запускают класс-джоб из командной строки так, как написал trud

Вручную класс-джоб, это магия которую сложно объяснять порой.

Наверное методологически правильно смотреть в сторону фич. Включил новый функционал и что то проинициализировалось. Единственное как проконтролировать чтобы пользователь не баловался включением/выключением.

Но вообще по хорошему должно как то автоматически вызываться обновление при накате. Наверное даже должен быть механизм какой то...Коллеги из MS и не только не поделитесь знаниями по этой теме?!?
У нас же промышленная система а не самописка какая то

[fed]

Цитата:

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

Если покопать классы ReleaseUpdate* и посмотреть на метод ReleaseUpdateCockpit.run(), то можно "добраться" до веб-сервиса UpgradeService и его метода ScheduleUpgrade. Он как раз все ReleaseUpdate-джобики ставит в пакетники.

Полный путь вызова веб-сервиса такой: https://<URL>/api/services/upgradeservicegroup/upgradeservice/ScheduleUpgrade

Полагаю, что сей веб-сервис надо каким-то способом вызвать и запустятся ReleaseUpdate-джобики. В интерфейсе вызовов я не нашел.
Сразу скажу - выводы сделал просто анализируя код - решение не проверял. На проектах обычно никто не заморачивается (программирование контрольных списков обычно никто не оплачивает) и запускают класс-джоб из командной строки так, как написал trud

Я знаю что этот функционал используется в скриптах для апгрейда данных из DAX2012 в D365. Если этот пакет распаковать и в scripts поискать ключевое слово "upgradeServiceHelper", то можно найти много подобных вызовов (даже не через сам веб-сервис):

$command = "$webroot\bin\Microsoft.Dynamics.AX.Deployment.Setup.exe"
.....
#schedule postsync script
$upgradeParameter = " --setupmode runstaticxppmethod --classname UpgradeServiceHelper --methodname ScheduleMinorVersionPostSync"
Write-Output "schedule postsync"
Start-Process $command $($commandParameter+$upgradeParameter) -PassThru -Wait -RedirectStandardError "$LogDir\dbUpgradePostSyncScheduling.error.log"

Так что штатным сценарием использования этого механизма является крупномасштабный апгрейд с DAX2012. Может оно и может аккуратно более мелкие апгрейды внутри D365FO отработать, но надо это проверять...

[sukhanchik]

Цитата:

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

Единственное как проконтролировать чтобы пользователь не баловался включением/выключением

Есть же фичи, которые нельзя отключить после включения. Думаю, копать надо в этом направлении.
Хотя мне кажется, что если на каждое обновление данных джобиком делать свою фичу - то будет "слишком много фич". Поэтому я бы смотрел больше в сторону написания своей обертки над вызовом ReleaseUpdateCockpit, либо попытался перетащить код из 2012 (menu items)