Критическая ошибка RunAs

[Corel]

Аксапта 4.0 (4.0.2501)
При запуске пакетной обработки вылезает сообщение в инфолог: "Критическая ошибка RunAs".
Возникает здесь: \Classes\BatchRun\runJob

        if (batchClass.runsImpersonated())
        {
            // Ok to assert here because the user name comes from
            // the batch table
            runAsPermission = new RunAsPermission(batch.CreatedBy);
            runAsPermission.assert();
            // BP Deviation Documented
            runas(batch.CreatedBy,
                classnum(BatchRun),
                staticmethodstr(BatchRun, runJobStatic),
                [batchId]);

            CodeAccessPermission::revertAssert();
        }

А точнее - тут: runas(batch.CreatedBy,
classnum(BatchRun),
staticmethodstr(BatchRun, runJobStatic),
[batchId]);

Вроде бы стандартный класс, написан на sys и syp слоях, незадолго до этого пакетная обработка тестировалась и работала, а тут на тебе.
Нет идей, как это можно вылечить?

[glibs]

Я бы сделал следующее.

1. Научился гарантировано воспроизводить на разработческой базе или на копии базы.
2. Временно убрал бы RunAs и попытался воспроизвести ошибку без него (возможно, залогонившись под пользователем-автором пакета, добавив ему прав на разработку аккуратно, но не полные админские, т.к. причиной ошибки могут быть и права доступа).
3. Дебагером добрался бы до сути ошибки.

Дальше, как говорится, it depends...

[Corel]

Дебаггер туда не залезает.
Ошибка возникает так:
1) Запускается пакетная обработка. Она находит класс, в котором вылетает в трассировку стерка (в данном случае - нашёлся класс, у которого был некорректно определён unpack() ).
2) После этого любая пакетная обработка даёт критическую ошибку RunAs, описанную выше.
Вылечилось рестартом АОС. Более мягкого способа не нашёл.

[Corel]

Чёрт, третий день шаманю вокруг этого...
При запуске пакетной обработки (класс BatchRun) или же просто изменения основных оповещений (класс EventJobCUD) вылетает на runAs...
Заменил на обычный вызов методов - работает, но думаю, что это не совсем корректно. Но отчего же runAs-то не отрабатывают?

[wojzeh]

столкнулся с точно такой же проблемой.

если в методе класса BatchRun

    if (batchClass.runsImpersonated())
        {
            // Ok to assert here because the user name comes from
            // the batch table
            runAsPermission = new RunAsPermission(batch.CreatedBy);
            runAsPermission.assert();
            // BP Deviation Documented
            runas(batch.CreatedBy,
                classnum(BatchRun),
                staticmethodstr(BatchRun, runJobStatic),
                [batchId]);

            CodeAccessPermission::revertAssert();
        }
        else
        {
            BatchRun::runJobStatic([batchId]);
        }

сделать так, чтоб переходили на ветку else, то в её недрах виден некий лишенец в поле Event.UserId, из-за которого и происходит исключительная ситуация.

проблему поборол очисткой таблицы EventCUD, но какая связь между ид пользователя, породившим событие и пакетной обработкой, я так и не понял.

[wojzeh]

коллега, удалось ли забороть проблему?

[Maximin]

Я заметил, что у меня подобная ошибка возникает только на пакетной группе, обрабатывающей оповещения и только если АОС, на котором работает клиент с этой пакетной группой, закрыт для новых подключений.
Могу также предположить, что так же это связано с какими-то неполадками в настройке домена/службах аутентификации, либо необходимостью доаствить оповещение пользователю, который уже не имеет прав в домене для входа в Аксапту/либо вообще отключен. Неплохо было бы в системный лог посмотреть.

[Maximin]

Расшифровывая вышесказанное мной, хочется написать чуть подробней.

Это еще зависит от того, кто создал пакетное задание, обрабатывающее оповещения и того, что пакетный класс EventJobCUD имеет перекрытый метод runsImpersonated с ret=-true. Это указывает запускать пакет на сервере от имени создавшего его пользователя. Если с этим пользователем на сервере плохо то выполнение пакета обломится.