Олицетворенный на сервере (RunAs) сеанс попытался вызвать метод, который доступен только на клиенте.

[Poleax]

Класс выполняется на пакетном сервере (32-разрядном) Dynamics Ax 2009 Sp1 RU7
в одном методе, ошибка валится на строке :

boolean ado_findFieldGuid(FilePath _filePath, Filename _filename)
{
    //Classes
    CCAdoConnection         adoConnection;
    CCAdoCommand            adoCommand;
    CCAdoRecordSet          adoRecordSet;
    CCAdoFields             adoFields;

    //Variables
    int                     i;
    FilePath                connectionString  = 'Driver={Microsoft dBASE Driver (*.dbf)};DriverID=277;Dbq=';
    boolean                 ret = false;
    ;

    connectionString = connectionString + _filePath + ';' ;

    new InteropPermission(InteropKind::ComInterop).assert();

    adoConnection = new CCAdoConnection();    //<-- Ошибка: Олицетворенный на сервере (RunAs) сеанс попытался вызвать метод, который доступен только на клиенте.
    adoConnection.open(connectionString);
    adoCommand       = new CCADOCommand();
    adoCommand.activeConnection(adoConnection);
    ....

У класса RunOn: Called from
Ранее выполнялось все нормально, код не менялся.
Теперь на adoConnection = new CCAdoConnection(); ошибка.

Кто подскажет куда дальше копать с проблемой?

[oip]

Поставить у CCADOConnection (а заодно и прочих CCADO*) RunOn=Called from, если там стоит Client. Плюс см.http://blogs.msdn.com/b/aeremenk/arc...1/9566049.aspx

[Poleax]

Цитата:

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

Поставить у CCADOConnection (а заодно и прочих CCADO*) RunOn=Called from, если там стоит Client. Плюс см.http://blogs.msdn.com/b/aeremenk/arc...1/9566049.aspx

Спасибо, действительно коллега на \Classes\CCADOConnection выставил RunOn=Client

[Damn]

Цитата:

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

Ранее выполнялось все нормально, код не менялся.
Теперь на adoConnection = new CCAdoConnection(); ошибка.

Как же оно раньше могло выполняться без ошибок если у класса CCADOConnection свойство RunOn = Client ? Может раньше это пакетное задание выполнялось клиентом пакетной обработки, а не АОСом ?

нашёл ответ на свой вопрос когда прочёл предыдущий пост, написанный одной минутой ранее

[DSPIC]

Потому что классы CCADO* используются только в одной, какой-то русской функциональности работающей на клиенте, в AX2009 по крайней мере.

[androzavr]

Если позволите, подниму тему.

С описанным в начале темы сообщением, когда на сервере вызывается класс с RunOn=Client и в результате получаем ошибку, вроде все понятно.
Но недавно столкнулся с интересным моментом:
имеется некий класс с RunOn=Server;
в одном из его методов вызывается метод Global::fileNameNext(), при этом класс Global имеет RunOn=Called from, а метод Global::fileNameNext() объявлен следующим образом - static client server Filename fileNameNext(Filename _filename);
однако в методе Global::fileNameNext() используется метод WinAPI::fileExists(), который в свою очередь является клиентским (RunOn=Client у класса WinAPI и модификатор client у метода fileExists()).

Для начала вопрос: как вы думаете, как будет работать такая связка при обработке файлов на сервере (пути - сетевые).

Я бы наверное сразу сказал, результатом будет ошибка "Олицетворенный на сервере (RunAs) сеанс попытался вызвать метод, который доступен только на клиенте...", но как показала практика - все работало нормально. Класс работал в пакете, проверялось наличие файлов, получались новые имена, файлы создавались/перемещались с новыми именами...
Но, тут самое интересное! Все работало до поры, до времени.
В один прекрасный момент таки появилась вышеописанная ошибка! Причем только на одном файле из нескольких сотен. Причем именно на этом файле она повторялась. Причем на всех других файлах она не проявлялась. Со временем выявился еще один такой уникальный файлик. С тех пор их только два.
Честно, говоря полез проверять места выполнения всей цепочки только после того как получил ошибку. До этого просто не обратил внимание на наличие в fileNameNext() метода WinAPI::fileExists(). И даже после этого не стал сразу исправлять, а некоторое время последил за работой класса - ошибка больше не проявлялась на новых файлах и стабильно повторялась на двух файлах, на которых появлялась и ранее.

Может кто-нибудь объяснить такое поведение Аксапты?

P.S.: Метод Global::fileNameNext() ни кем не правился - живет на sys-слое. WinAPI::fileExists() - также. Kernel version: 5.0.1500.4570, Application version: 5.0.1500.3761

[handy-comp]

Проверьте какие права есть у пользователя, под которым запущен клиент Ax, на работу с этими двумя волшебными файлами.

[androzavr]

Цитата:

Сообщение от handy-comp

Проверьте какие права есть у пользователя, под которым запущен клиент Ax, на работу с этими двумя волшебными файлами.

Честно говоря не совсем понятно как могут влиять на появление или непоявление этой ошибки права вообще, а тем более клиента, т.к. класс в пакете выполняется, но проверил. Права на файлы наследуются от родительской папки. На всех файлах одинаковые. У всех пользователей (и АОС, и клиент) есть права на изменение, чтение и выполнение, чтение, запись.
Все файлики представляют собой XML-ки, выгружаемые из внешней системы. Вроде как все они создаются одинаково, с одинаковыми правами одним и тем же сервисом (пользователем). Конечно не исключаю ,что в процессе тестирования кто-нибудь мог положить эти файлы в папку обмена с другого места или подправить руками. Но достоверно узнать это сейчас не представляется возможным)))

Кстати, поиском по форуму не нашел ни одного упоминания fileNameNext(). Неужели, этим методом действительно никто никогда не пользовался (ну кроме формы экспорта из АОТ)?

P.S.: Забыл сказать, что я сам в мистику не верю, но ситуация имеет место быть... Очевидно, что я либо чего-то недопонимаю в механизме определения места выполнения кода, либо чего-то не учитываю. Поэтому и написал об этом на форуме, чтоб разобраться...

[gl00mie]

Чудес не бывает Запустите трассировку перед выполнением пакетного задания, использующего fileNameNext(), и потом посмотрите в TraceParcer'е, где именно какой метод выполнялся.

PS. Я так понимаю, речь о приложении AX 2009? Потому что в 2012 соотв. метод уже "различает", на клиенте он выполняется или на сервере.

[androzavr]

Цитата:

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

Чудес не бывает

Ура! Вера в несуществование чудес получила очередное подтверждение...
Не дошел я до трассировки. Пока выбирал файлы для тестирования, наконец заметил отличие в тех, что вызывали ошибку и тех, что не вызывали ошибку - ошибочные файлы уже существовали в папке назначения, а нормальные все были новые. Соответственно сразу возникла мысль, что может все-таки fileNameNext() не всегда вызывается. Полез шерстить код и таки нашел чуть раньше вызов WinApiServer::fileExists().
Косяк - детский! Стыдно даже в нем признаваться, но дабы ни у кого не возникло вдруг веры в чудеса решил стерпеть и признаться...
Все дело в невероятнейшем стечении обстоятельств! Тестировал создание дубликатов файлов на разработческом приложении без пакетника, а на тестовом сервере не попадалось одинаковых имен файлов. Удивительное совпадение.

Итак, извиняюсь за преждевременно поднятую панику и, если позволите, пока свежо, пару вопросов не совсем по теме (не знаю как здесь обозначить "оффтоп"):
1) gl00mie, можете пояснить о какой трассировке и главное "TraceParcer'е" Вы говорили? Это термины из Ax2012? Или речь все-таки о Профайлере кода в Ax2009? Ведь я правильно понял, что это точно не трассировка SQL и не трассировка, которая включается галочками на вкладке "Разработка" в параметрах пользователя?
2) Если не сложно можете выслать мне код метода fileNameNext() с Ax2012, который различает на каком уровне он выполняется. Просто интересно посмотреть как Они это сделали, потому что у самого было несколько разных идей, но остановился пока на самом простом варианте (добавил в свой класс похожий метод)). Думаю не нарушит сильно авторских прав и лицензионных соглашений...

Ответить можно в личку. Тему засорять больше не посмею...

[androzavr]

Возник еще один вопрос, касательно ошибки "Олицетворенный на сервере (RunAs) сеанс попытался вызвать метод, который доступен только на клиенте". Пока игрался с классами, вызывающими ошибку, заметил, что она не перехватывается try-catch'ем. Вместо сообщения "Произошла такая-то ошибка..." выполнение прерывается в месте вызова клиентского класса и вываливает инфолог.
Можно-ли с этим что-то поделать?
Я понимаю, конечно, что такого просто-напросто нельзя допускать. И отправлять в рабочую среду код, пусть и обрабатывающий такого рода ошибки нельзя, просто хочется понять почему она не перехватывается. Такое поведение сделано специально, чтоб горе-программисты не пытались писать кривой код? Или ошибку обработать все-таки можно?

[gl00mie]

Обработка такой ошибки кодом приложения не реализована, насколько я понимаю, потому что тут из-за отсутствия клиентской части среды времени выполнения как бы отсутствует кусок приложения (тот, что должен выполняться на клиенте), и при этом выполняющийся на сервере кусок приложения от него зависит, раз вызывает соотв. клиентский код. Это примерно то же, что отсутствие нужного ActiveX'а или .NET-сборки, обнаруживающееся во время выполнения: если такой компонент грузится неявно через статические привязки в приложении, то среда времени выполнения не знает, как можно продолжить выполнение приложения без него, и прерывает выполнение приложения в текущей сессии по всему стеку вызовов, без оглядки на обработчики исключений.

[d_alexe]

Цитата:

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

P.S.: Метод Global::fileNameNext() ни кем не правился - живет на sys-слое.

Ну так он видать с 3.0 так и остался, так как он ни где и не используется.

Ну а в 2009 есть 2 класса WinAPI и WinAPIServer. У которых соответственно RunOn: Client, Server. И различия между ними в том что, в-первом случае вызовы функций идут через WinApi, а во-втором уже через .Net. Связано это скорее всего с переходом серверов на WinServ2008. Из чего следует, что бы использовать Global::fileNameNext(), надо вводить условие проверки, где запускается функция и какую WinApi использовать.

ПС WinAPIServer потом тоже пришлось приглаживать, так как начались валиться ошибки такого плана "//Сбой запроса на разрешение типа "FileIOPermission"."
ПС2 Кстати с ADO* такая же беда, по-этому в новых функция, и по возможности в старых, перешёл на использование .Net.

[gl00mie]

Цитата:

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

WinAPIServer потом тоже пришлось приглаживать, так как начались валиться ошибки такого плана "//Сбой запроса на разрешение типа "FileIOPermission"."

WinAPIServer не нужно приглаживать на предмет того, что он требует разрешений на вызовы своих методов, - он специально так сделан Для тех, кому это не нравится и у кого нет интеграции со сторонними системами через BC, есть более радикальное средство - параметр ком.строки AOS'а

-caslevel=disable

См. Application Object Server (AOS) configuration commands

[RVS]

Подниму-ка тему...

Ситуация :

- из пакета, выполняющегося на сервере
- из класса "внутри" этого пакета, у которого (класса) аттрибут RunOn = Server
- вызывается InventMovement::setAutoReserving(salesLine);
- client static boolean setAutoReserving(Common buffer)

, что приводит к ошибке "Олицетворенный на сервере (RunAs) сеанс попытался вызвать метод, который доступен только на клиенте."

===

И что теперь? Поправить InventMovement::setAutoReserving() ? Зачем вообще там client static ?

Наведите на мысль, pls..

[gl00mie]

А версия приложения какая? В 2012 написано вот что:

Цитата:

This method is called from the SalesTableForm class when you enter a new sales line. If the quantity that is entered must be reserved, the method checks for the available inventory. If inventory is not found, the method returns the InventOnHandCheckReserve dialog box to the user. From here, the user can change the quantity on the order line or ignore the dialog box and continue.

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

[RVS]

Упс, виноват..

DAX2009 Kernel 5.0.1500.4570 Appl 5.0.1500.2116 EE

[gl00mie]

В 2009-й все то же самое, только без пояснительных комментариев.
А зачем, собственно, дергать этот код в пакете? Если нужно, чтобы количества в создаваемых строках автоматом зарезервировались, достаточно перед созданием строки прописать в ней SalesLine.Reservation = ItemReservation::Automatic.

[RVS]

Цитата:

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

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

Да, "слона-то я и не приметил"..

Просто - метод, который вызывает setAutoReserving() - писался задолго до меня.. и специально - для запуска в пакете, только вот "пакет" был - на клиенте, в стиле 3.0.. и товар там - хороший, сколько его не резервируй, не отгружай - он есть всегда, и его много ))

Спасибо, решение найдено.

[user_ax]

Если можно , подниму проблему:

имеется функционал, который импортирует записи из внешнего сервиса (документы, эксель файлы и т.д.), который запускается как в обычном режиме, так и в пакетном режиме.
После доработок, которые были сделаны с целью сохранять документы на сервере непосредственно после импорта их с внешнего сервиса ( ранее это делалось по нажатию кнопки на форме).
И теперь если выставить запуск пакетника с такими параметрами:


Я получаю ошибку, описанную выше.
Всем классам поставил свойство Called from , как и menu item-у , который непосредственно запускает периодическую операцию.
Согласно стека ошибок он валится на создании DictClass объекта. Хотя сам DictClass стоит Called from и это ещё более странно.
Стек ошибки ниже:

Если выставить единоразовый запуск - ошибка остается, что в принципе логично

Что можно сделать в данной ситуации, кроме как не загружать в docuref документы в пакетном режиме?

Заранее благодарю за ответы.

Ax2009
kernel 5.0.1500.6491
app version 5.0.1500.6491