Запуск p-code из пакетной сессии возможен или нет.

[Logger]

Всем привет.

Коллеги, можете подсказать.
Есть ли какой-то способ запустить из пакетной сессии на выполнение код как p-code, а не CIL ?

Ax2012 R3

[Pandasama]

Скорее всего, нет.
Но зачем?

[Logger]

В моем случае, чтобы выполнить пакет в p-code.
Как в 2009-й.

В документации сказано, что запуск пакетов из под ax32.exe (как в ax3) невозможен. Но он работает. Я подумал, может и тут такое возможно. Заставить серверный пакет отработать в p-code как в 2009.

[Logger]

Штатного способа не нашли.
Но есть обходной путь.
Делаем галочку в Batch
Если галка взведена то вместо запуска пакетной обработки класс BatchRun запускает бизнесконнектор к тому же аосу и запускает в нем пакетное задание на выполнение. Оно конечно же выполняется в p-code. Profit!
В ряде случаев, когда есть баги в CIL или надо срочно пофиксить не дожидаясь полного сбор CIL и рестарта - это очень удобно.

Из неудобств -
1. дольше запускается пакет - секундыина 2-4 (накладные расходы на логин)
2. Лог аоса на сервере флудится сообщениями при старте бизнесконнектора.
Возможно это решаемо.

Но в любом случае с этим можно мириться.

[DarkSpirit22]

Если я правильно понимаю, вам нужно запустить пакет не в среде CIL.
Для этого:
У задания Batch нужно RunType поменять на "Клиент". В этом случае пакетный сервер будет отвечать только за обработку статусов этого задания, но не за его обработку. Т.е. задание будет переведено из ожидание в выполнение штатным способом, и останется на статусе "Готово". Сама запись BatchJob перейдет в выполнение.

Далее в "Управление организацией/Периодические операции" выбираем "Пакетная обработка". Появляется форма, которая нам хорошо знакома из времен 4-ки. Выбираем группу, и наслаждаемся. Пакет будет запущен архитектурно точно так же, как и в 4-ой аксапте.

Так можно отлаживать пакетники

[Logger]

Цитата:

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

Так можно отлаживать пакетники

Да можно конечно.
Можно и CIL отлаживать через VS

Мы раньше так и запускали пакеты как вы описали. Но не с целью отладки, а пока CIL неработоспособен. Но указанный способ имеет ограничения. Неудобен он. Нужно держать клиента открытым ax32. Следить чтоб не упал. Следить чтобы число клиентов Ax32 было достаточным для параллельной обработки. Сессия RDP должна быть под которой клиент будет запущен. Работает он менее стабильно, исключения в нем не так в стандартном коде обрабатываются. В общем, много недостатков.

[Товарищ ♂uatr]

Привет.
Вроде Аксапта работает из под CLR и ядро, как раз, эмулирует работу с p-code, нет?
Ощущение, что стоит искать решение в сторону класса Microsoft.Dynamics.Ax.Services.XppBridge, только он лежит исполняемом файле, как АОСа, так и клиента, но публичный. Возможно через user32 его нужно "дергать".
Я просто "побаловался" подключив в виде reference исполняемый файл и получил, тем самым, возможность скомпилировать следующий код:

    System.Object[] array = new System.Object[0]();
    ;
    
    try
    {
        Microsoft.Dynamics.Ax.Services.XppBridge::CallStatic(Microsoft.Dynamics.Ax.Services.XppBridgeSecurityAuthSettings::Checked, "Class2", "method1", array);
    }
    catch
    {
        info(CLRInterop::getLastException().ToString());
    }

Да, он "валится" с ошибкой, но и не пишу, что это готовое решение.

[michel1971]

Цитата:

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

Но не с целью отладки

а как дебажить сессию BC?

[Logger]

Цитата:

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

а как дебажить сессию BC?

Как и любую другую неинтерактивную p-code сессию.

http://web.archive.org/web/200912181...tal-pages.aspx

http://web.archive.org/web/200908080...59(AX.10).aspx

http://web.archive.org/web/201007282...66(AX.10).aspx

https://learn.microsoft.com/en-us/dy...ectedfrom=MSDN

А чего вы все за отладку то уцепились ? Эта технология не для отладки придумана. Пакетный код и так отладить можно, просто вручную запустив или по старинке как в ax4

[Товарищ ♂uatr]

Привет.
Изучая Аксапту в поисках решения вопроса с кэшем (Как чистите глобальный кэш АОСов?) увидел библиотеку "Microsoft.Dynamics.AX.Xpp.Support.dll" - очень интересная.
Внутри неё сидит Microsoft.Dynamics.Ax.Xpp.XppObjectBase.
У меня сложилось впечатление, что это "базовая" точка вызова для всех функций.
Например в нём есть вот такая функция:

public static object StaticCall(string className, string methodName, object[] parameters, Type[] types, object[] varargs)

Но у этой библиотеки есть огромный минус - она в ссылках содержи Ax32Server.

В общем завела меня Аксапта в сторону (вообще другая библиотека)
Microsoft.Dynamics.AX.ManagedInterop.RuntimeContext::get_Current();
У которого есть всякие CallStaticClassMethod и тп.
При запуске которых из пакетного задания система не опознает их как IL код.
Можно предположить, что она считает его XPP.
Но у пакетного задания есть особенность - оно не заполняет в потоке Data - откуда по идее, должна браться сессия.
Поэтому сессию приходится инициализировать руками (это генерирует запись в активных пользователях):
new Microsoft.Dynamics.AX.ManagedInterop.Session() и нужно вызвать logon.
Microsoft.Dynamics.AX.ManagedInterop.Session это наследник от Microsoft.Dynamics.AX.ManagedInterop.RuntimeContext - приводим к родителю и вызываем нужный код.

Исходя из контекста задачи, так понимаю, что речь идёт о "hot swap" - оно кэширует где-то код. Только перезапуск АОСа актуализирует информацию.
В общем не выглядит как финальное решение, но шаг в его направлении.

[Logger]

Интересно
Надо будет проверить.