Цитата:
Сообщение от
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 отработать, но надо это проверять...