Новые методы через AxaptaComConnector

[Genghis]

Здравствуйте. Прошу совета по сложившейся ситуации.
Стоит сервер аксапты, работает себе круглосуточно с редкими перезагрузками.
И вышло так, что понадобился внешний доступ через AxaptaComConnector. Все прекрасно работает, подключается, методы вызываются. Но только уже созданные. Если дописать метод и попытаться вызвать его извне, то выдается сообщение о том, что его нет "Ошибка времени выполнения. : 'имя_класса' Объект не имеет метода "имя_метода"".
Вопрос - можно как-то без перезагрузки сервера сделать этот метод доступным в коннекторе для внешних приложений? (в данном случае подключается php-скрипт).

[S.Kuskov]

На сколько я помню, в такой ситуации перезагржать можно не AOS, а connector. Если проводить аналогию с обыкновенным windows-клиентом, то в случае изменения объектов приложения старые подключённые пользователи ещё видят предыдущее закэшированное состояние приложения, а новые - уже новое.
Возможно вместо перезагрузки стоит попробовать обновлять кэш.

.NET business connector не видит изменений в коде Аксапты
Способы почистить локальный кеш всем пользователям?

[Genghis]

Хм... кеша в documents and settings не нашлось. Если пользователь переподключится, кеш обновится, но как бы так сделать, чтобы не переподключаться?

[DSPIC]

Цитата:

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

Хм... кеша в documents and settings не нашлось. Если пользователь переподключится, кеш обновится, но как бы так сделать, чтобы не переподключаться?

На 100% вам поможет следующая строка вначале кода;

connector.CallStaticClassMethod("SysFlushAOD", "doFlush");

Но это решение мне самому не очень нравится, использую как временное.

[gl00mie]

Цитата:

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

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

А у вас АОС один-единственный или же кластер? Дописывали метод именно на том АОСе, к которому подключается Business Connector? А то если АОСов несколько, то они могут очень долго не видеть изменений в приложении, сделанных на другом АОСе.

[Genghis]

На самом деле их около 8, все на разных машинах в сети. Но мы сейчас работаем с одним конкретным.
Вообще сейчас пронаблюдали, кеш обновился где-то за 20 минут. Это вполне приемлемо для наших задач, поэтому думаю можно мозг не ломать.
Спасибо вам за помощь и советы.

[jonny]

Сервис-средства разработки-объекты приложения:
-обновить словарь
-обновить данные
-обновить AOD
При работе с EP это помогает, должно и в вашем случае.

[EfimV]

Сталкивался с похожей ситуацией.
Есть ещё такая особенность. Если прошло не добавление нового метода, а изменение существующего. То уже никакие действия, кроме перезагрузки АОС не помогали.

Если вам это критично то, как вариант, можно поднять отдельный АОС для конектора.
И перезагружать только его при внесении изменений в логику.

[gl00mie]

Цитата:

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

На самом деле их около 8, все на разных машинах в сети.

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

Цитата:

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

Сервис-средства разработки-объекты приложения:
-обновить словарь
-обновить данные
-обновить AOD

И так на каждом AOS'е?..

Цитата:

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

Есть ещё такая особенность. Если прошло не добавление нового метода, а изменение существующего. То уже никакие действия, кроме перезагрузки АОС не помогали.

На самом деле не все так плачевно - в таких случаях помогает перекомпиляция соотв. объекта приложения на каждом AOS'е, в случае класса - лучше инкрементная. Понятно, что если AOS'ов много, то вручную заходить на каждый лениво. Мы для этих целей приделали классец, который висит в контекстном меню в AOT. При выборе соотв. пункта контекстного меню, скажем, для проекта, соотв. объекты приложения сначала компилируются в текущей сессии, а потом, если все прошло без ошибок, формируется xml-файлик для запуска компиляции из командной строки, и для каждого активного AOS'а из SysServerSessions, кроме текущего, последовательно запускается клиент с этим файликом, который компилит нужные объекты приложения на соот. AOS'е, за счет чего каждый из них подхватывает изменения. Последовательный запуск компиляции нужен для того, чтобы AOS'ы не конфликтовали при попытке обновить одни и те же файлы приложения. Разумеется, если меняется код, выполняемый на клиенте, изменения в той или иной клиентской сессии могут подхватиться не сразу.