Многие специалисты сталкиваются с ситуацией, когда после обновления платформы 1С:Предприятие 8.3 (особенно начиная с релизов 8.3.15 и выше) перестает работать синхронизация между конфигурациями «Зарплата и управление персоналом 3.1» и «Бухгалтерия предприятия 3.0». Обмен данными либо полностью зависает, либо в Журнале регистрации появляется ошибка: «Аварийно завершился рабочий процесс фонового задания». При этом данные могут успешно отправляться из одной базы, но не загружаться в другую.
Разберем подробнее, с чем связано такое поведение системы, и рассмотрим по шагам эффективные способы решения данной проблемы.
Выясним причину номер один. Чаще всего проблема кроется в зависших сессиях или неправильно зарегистрированной библиотеке comcntr.dll после установки новой версии платформы. Старые записи в реестре ОС или в службах компонентов конфликтуют с новыми файлами сервера 1С.
Решим эту задачу вместе, выполнив правильную регистрацию компоненты:
V83COMConnector и полностью удалим его, чтобы очистить кэшированные данные компоненты.
cd C:\Windows\System32
regsvr32 "C:\Program Files\1cv8\8.3.15.1700\bin\comcntr.dll"
Укажите свой релиз платформы в пути. После появления окна об успешной регистрации проверим синхронизацию баз данных. В большинстве случаев выполнение этого шага полностью восстанавливает обмен (как в примере запуска обмена через COM).
Проанализируем ситуацию глубже. В типовых конфигурациях при инициализации COM-соединения программный код платформы пытается установить безопасный режим выполнения. В этом режиме категорически запрещены любые внешние операции, включая вызовы COM-объектов. В результате процесс rphost аварийно падает, унося с собой фоновое задание.
Чтобы обойти это встроенное ограничение, мы можем создать простое расширение конфигурации (его нужно подключить и в ЗУП, и в БП), в котором отключим установку безопасного режима. Посмотрим на пример кода, который необходимо переопределить в серверном общем модуле ОбщегоНазначения (для функции ОбщийМодуль):
&Вместо("ОбщийМодуль")
Функция Расш1_ОбщийМодуль(Имя)
// УстановитьБезопасныйРежим(Истина); - эту строку мы просто комментируем
Возврат ПродолжитьВызов(Имя);
КонецФункции
Обратите внимание: в свойствах самого расширения необходимо снять флажок «Режим совместимости», чтобы исключить конфликты при загрузке расширения в конфигурациях с новым режимом совместимости.
Если перерегистрация библиотеки и расширение не принесли результата, рассмотрим дополнительные настройки безопасности. Платформа имеет механизм «Защита от опасных действий», который может блокировать запуск COM-объектов регламентными заданиями.
Для начала отключим предупреждения безопасности для служебного пользователя. Зайдем в базу данных в режиме Предприятия, откроем карточку пользователя, под которым настроено регламентное задание синхронизации, и снимем галочку «Защита от опасных действий».
Затем выполним тонкую настройку самого COM+ приложения на сервере (если мы создавали его вручную):
V83COMConnector перейдем на вкладку «Удостоверение» (Identity). Укажем в качестве удостоверения ту учетную запись, под которой работает служба сервера 1С (чаще всего это локальный пользователь сервера USR1CV8).Проанализируем стратегическое решение проблемы. Зачем постоянно бороться с нестабильным COM-соединением, зависящим от битности и версий платформы, если можно использовать современные механизмы обмена? Мы рекомендуем отказаться от прямого подключения и настроить синхронизацию через универсальный формат обмена EnterpriseData.
Перенастроим узлы обмена таким образом, чтобы базы обменивались XML-сообщениями через локальный каталог, защищенный FTP-ресурс или напрямую через опубликованный веб-сервис на веб-сервере. При таком обмене библиотека comcntr.dll не используется вообще. Это навсегда избавит нас от ошибок с безопасным режимом и аварийных падений процессов обмена. Кроме того, формат обмена EnterpriseData позволяет корректнее передавать сложные специфические объекты учета.
Если после всех манипуляций ошибка всё ещё дает о себе знать, выполним жесткую очистку серверного кэша кластера 1С. Для этого остановим службу Агента сервера 1С:Предприятия, удалим сеансовые данные в директории snccntx и полностью очистим кэш рабочих процессов в каталоге кластера srvinfo. После рестарта службы кэш сформируется заново, уже с корректными ссылками на объекты среды.
В самых сложных случаях мы рекомендуем временно запустить базу с ключом РежимОтладки или инициировать процедуру обмена интерактивно в клиентском сеансе. В отличие от фонового задания, которое скрывает ошибку за общей фразой об аварийном завершении, в клиентском сеансе мы сможем увидеть подробный стек вызовов и выяснить точную техническую причину сбоя (будь то конфликт транзакционных блокировок или банальная нехватка прав доступа).