Типичная ситуация для системного администратора и начинающего разработчика 1С: после обновления платформы или переноса базы на новый сервер перестает работать автоматический обмен данными. При этом ручной запуск обмена по кнопке «Выполнить» проходит без ошибок, а в журнале регистрации фоновые задания завершаются мгновенно (время начала совпадает со временем окончания). Разберем по шагам, как диагностировать эту проблему, выявить ошибки в коде и настроить надежную репликацию данных между базами.
Когда мы видим в журнале регистрации записи о старте и завершении задания с одинаковым временем, это сигнализирует об одной из трех ситуаций: либо задание было мгновенно отклонено планировщиком, либо в самом начале выполнения произошла критическая ошибка, либо в программном коде сработало условие выхода из процедуры. Рассмотрим подробнее, как проверить эти гипотезы.
Во-первых, проанализируем настройки консоли администрирования серверов 1С. Часто при переустановке или миграции сервера в свойствах информационной базы устанавливается флаг «Блокировка регламентных заданий включена». В этом случае задания даже не начнут выполняться. Однако, если записи в журнале регистрации все же появляются, значит, блокировка снята, и проблема кроется внутри самой конфигурации или в правах доступа.
Для того чтобы понять, что происходит внутри автоматического процесса, нам необходимо подключиться к нему отладчиком. Поскольку регламентные задания выполняются в серверном контексте и в отдельном сеансе, стандартная точка останова может не сработать. Проанализируем правильный алгоритм настройки отладки:
-debug. Без этого параметра сервер не будет передавать данные отладчику. В ОС Windows это проверяется через реестр или свойства службы.Как показывает практика, часто проблема скрывается в «самописных» проверках. Например, разработчики могут добавить условие, которое проверяет имя пользователя или тип клиента. Поскольку фоновое задание выполняется от имени специального системного пользователя и имеет тип клиента «Фоновое задание», такие проверки могут некорректно срабатывать и прерывать выполнение кода командой Возврат;.
Если обмен между базами УПП реализован через COM-соединение (подключение напрямую к другой базе), то при смене ОС с Windows 2003 на Windows 2008 и обновлении платформы до версии x64 возникают специфические ошибки. Проанализируем ситуацию: ручной обмен запускается в 32-битном толстом клиенте на рабочем месте пользователя, а автоматический — в 64-битном процессе сервера 1С.
Для исправления работы V83.COMConnector выполним следующие действия:
comcntlevw.dll нужной версии платформы в системном реестре через regsvr32.USR1CV8 (от имени которого работает сервер) на доступ к папкам обмена и запуск COM-компонентов.Рассмотрим вторую задачу: организацию передачи данных из УПП в новую информационную базу. Если конфигурации разные, использование «Полного» плана обмена нецелесообразно. Разберем наиболее эффективные способы решения.
Это классический метод для 1С 8.3. Проанализируем последовательность действий:
Наименование и Код.Если вы обладаете навыками системного администрирования и программирования, рекомендуем отказаться от COM в пользу HTTP. Это избавит от проблем с регистрацией DLL и настройкой DCOM. Посмотрим на пример логики:
В новой базе создаем HTTP-сервис с методом POST. Этот метод будет принимать данные в формате JSON и записывать их в справочник. Пример кода для отправки данных из УПП:
// Пример отправки данных из УПП в новую базу через HTTP
Сервер = "192.168.1.10";
Порт = 8080;
Ресурс = "/MyBase/hs/v1/sync_data";
Соединение = Новый HTTPСоединение(Сервер, Порт, "Логин", "Пароль");
Запрос = Новый HTTPЗапрос(Ресурс);
Запрос.УстановитьТелоИзСтроки(ДанныеВФорматеJSON, КодировкаТекста.UTF8);
Попытка
Ответ = Соединение.ОтправитьДляОбработки(Запрос);
Если Ответ.КодСостояния <> 200 Тогда
ЗаписьЖурналаРегистрации("Обмен", УровеньЖурналаРегистрации.Ошибка, , , "Ошибка HTTP: " + Ответ.КодСостояния);
КонецЕсли;
Исключение
Сообщить("Не удалось связаться с сервером!");
КонецПопытки;
Данный метод работает стабильно вне зависимости от разрядности сервера и версии операционной системы. При срабатывании регламентного задания в УПП, код будет собирать измененные элементы справочника и отправлять их «пакетом» в новую базу.
Как выяснилось в ходе анализа конкретной ситуации в УПП 1.3, основной причиной сбоя стала «кривая» проверка условий выполнения в общем модуле. После того как лишние блокировки в коде были закомментированы, штатный механизм обмена заработал. Помните, что при переносе базы на новый сервер всегда стоит проверять не только настройки платформы, но и кастомный код, который может опираться на переменные окружения, изменившиеся в новой версии ОС.