При обновлении крупных и давно кастомизированных конфигураций, таких как 1С:Управление производственным предприятием (УПП), редакция 1.3, технические специалисты нередко сталкиваются с нехваткой ресурсов сервера или с необходимостью сократить время простоя базы данных. Из-за этого практикуется «перепрыгивание» через релизы в конфигураторе путем последовательного объединения файлов метаданных .cf без промежуточного запуска информационной базы в режиме «Предприятие».
Подобный подход таит в себе скрытые угрозы. База данных может успешно обновиться в конфигураторе, но при первом же запуске в режиме клиента выдать критические ошибки, блокирующие работу пользователей. В данной статье мы подробно разберем по шагам две взаимосвязанные проблемы, возникающие при обновлении УПП до релиза 1.3.110.3, выясним их причины и найдем несколько вариантов решения.
Рассмотрим ситуацию: при старте системы программа аварийно завершает работу, выдавая в журнал регистрации или на экран пользователя стек ошибок следующего вида:
{ОбщийМодуль.ПолныеПрава.Модуль(707)}: Ошибка при получении значения атрибута контекста (ТекущийПользователь)
Запрос.УстановитьПараметр("ТекущийПользователь", ПараметрыСеанса.ТекущийПользователь);
по причине:
{МодульСеанса(24)}: Слишком много фактических параметров
ИнтеграцияЕГАИС.УстановитьПараметрыСеанса("ИдентификаторСеансаЕГАИС", УстановленныеПараметры);
На первый взгляд ошибка кажется нелогичной: почему обращение к параметру сеанса ТекущийПользователь вызывает сбой, связанный с интеграцией ЕГАИС? Проанализируем внутренний механизм работы платформы 1С:Предприятие.
В платформе реализована так называемая отложенная (lazy) инициализация параметров сеанса. Это означает, что параметры сеанса не создаются все скопом при старте системы. Вместо этого инициализация конкретного параметра происходит в тот момент, когда к нему впервые обращается программный код (например, при попытке прочитать ПараметрыСеанса.ТекущийПользователь).
Когда система обнаруживает, что запрашиваемый параметр еще не инициализирован, она автоматически вызывает стандартное событие УстановкаПараметровСеанса в объекте МодульСеанса. Посмотрим на код этого обработчика, который вызвал ошибку:
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
Если ТребуемыеПараметры = Неопределено Тогда
// раздел "безусловной" инициализации параметров сеанса
ПолныеПрава.УстановитьПараметрыМеханизмаОграниченияПравДоступа();
Иначе
УстановленныеПараметры = Новый Структура;
Для Каждого ИмяПараметра ИЗ ТребуемыеПараметры Цикл
УстановитьЗначениеПараметраСеанса(ИмяПараметра, УстановленныеПараметры);
КонецЦикла;
КонецЕсли;
// СтандартныеПодсистемы
СтандартныеПодсистемыСервер.УстановкаПараметровСеанса(ТребуемыеПараметры);
// Конец СтандартныеПодсистемы
// ЕГАИС
ИнтеграцияЕГАИС.УстановитьПараметрыСеанса("ИдентификаторСеансаЕГАИС", УстановленныеПараметры);
// Конец ЕГАИС
ПараметрыСеанса.УдаляемыйДокумент = Неопределено;
КонецПроцедуры
Обратим внимание на строку вызова интеграции ЕГАИС. В нее передается два фактических параметра: строка "ИдентификаторСеансаЕГАИС" и структура УстановленныеПараметры.
Теперь сопоставим этот вызов с объявлением самой процедуры в общем модуле ИнтеграцияЕГАИС на стороне конфигурации поставщика:
// Выполняет установку параметров сеанса. Вызывается из модуля сеанса.
Процедура УстановитьПараметрыСеанса(ТребуемыеПараметры) Экспорт
Если ТипЗнч(ТребуемыеПараметры) <> Тип("Массив") Тогда
Возврат;
КонецЕсли;
Для Каждого ИмяПараметра Из ТребуемыеПараметры Цикл
Если ИмяПараметра = "ИдентификаторСеансаЕГАИС" Тогда
ПараметрыСеанса.ИдентификаторСеансаЕГАИС = Новый УникальныйИдентификатор;
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Процедура УстановитьПараметрыСеанса в общем модуле ожидает на входе только один параметр (массив ТребуемыеПараметры). Из-за некорректного слияния кода при обновлении конфигурации (особенно если до этого конфигурация была на поддержке с изменениями) в МодульСеанса попал устаревший или ошибочный вызов с двумя параметрами. Платформа аварийно прерывает выполнение процедуры установки параметров сеанса, что делает невозможным получение любого другого параметра, включая ТекущийПользователь.
Решение проблемы: необходимо привести вызов метода в соответствие с конфигурацией поставщика. Откроем МодульСеанса в конфигураторе, найдем строку 24 (или строку с вызовом ЕГАИС) и заменим ошибочную конструкцию:
// Было:
ИнтеграцияЕГАИС.УстановитьПараметрыСеанса("ИдентификаторСеансаЕГАИС", УстановленныеПараметры);
// Стало (правильный вызов):
ИнтеграцияЕГАИС.УстановитьПараметрыСеанса(ТребуемыеПараметры);
После этого сохраним конфигурацию базы данных и перезапустим сеанс.
После исправления первой ошибки вы можете столкнуться со следующим препятствием на этапе обновления данных информационной базы в режиме «Предприятие»:
Обновление информационной базы на версию "1.3.110.3" завершилось с ошибками:
{(1)}: Метод объекта не обнаружен (ЗаполнитьВходящиеДокументыНастроек)
Справочники.СоглашенияОбИспользованииЭД.ЗаполнитьВходящиеДокументыНастроек()
Выясним причину этого поведения. Данный сбой — классическое следствие пропуска промежуточных релизов при обновлении в режиме «Предприятие». Когда разработчик накатывает файлы конфигурации .cf один за другим (например, последовательно объединяя версии 1.3.106 -> 1.3.109 -> 1.3.110), физическая структура метаданных обновляется до финальной версии. Однако база данных «думает», что ее логическая версия все еще равна 1.3.106.1.
При первом запуске «Предприятия» на релизе 1.3.110.3 встроенный механизм БСП (Библиотеки Стандартных Подсистем) и БЭД (Библиотеки Электронных Документов) строит очередь отложенных обработчиков обновления для всех пропущенных версий (1.3.107, 1.3.108, 1.3.109). Система видит, что на этапе релиза 1.3.107 или 1.3.108 должен был выполниться обработчик Справочники.СоглашенияОбИспользованииЭД.ЗаполнитьВходящиеДокументыНастроек(), и пытается вызвать его из модуля менеджера этого справочника.
Но к моменту релиза 1.3.110.3 разработчики 1С сочли этот метод устаревшим и полностью удалили его из кода конфигурации. Механизм обновления пытается запустить процедуру, которой физически больше нет в вашей новой конфигурации, что приводит к критической ошибке и остановке процесса обновления ИБ.
Рассмотрим три способа преодоления этой проблемы, от наиболее правильного к быстрым обходным вариантам.
Для предотвращения нарушения логической целостности данных необходимо восстановить базу из бэкапа версии 1.3.106.1 и провести обновление по правилам:
Этот метод исключает риск повреждения данных, но требует значительного времени и дискового пространства.
Если разворачивать бэкапы и проводить многочасовые последовательные обновления нет возможности, мы можем временно «обмануть» механизм обновления БСП. Для этого выполним следующие действия:
СоглашенияОбИспользованииЭД, откройте его Модуль менеджера.Экспорт:
Процедура ЗаполнитьВходящиеДокументыНастроек() Экспорт
// Временная заглушка для успешного прохождения обновления информационной базы
КонецПроцедуры
Продвинутые администраторы могут воспользоваться специальными обработками (например, входящими в состав инструментов разработчика БСП) для ручного управления регламентными заданиями обновления. В этих обработках можно принудительно пометить проблемный шаг обновления как «Выполнен успешно». Это исключит обращение к удаленной процедуре, однако требует глубокого понимания структуры метаданных БСП (регистров сведений ВерсииПодсистем, служебных справочников обновлений) и не рекомендуется для начинающих специалистов.
Во время локализации подобных ошибок разработчики часто жалуются, что точки останова в конфигураторе не срабатывают, система проскакивает их и сразу выдает ошибку. Существует заблуждение, что для обычного приложения (в режиме которого работает УПП 1.3) серверная отладка не требуется.
Важно понимать: несмотря на то, что интерфейс УПП запускается в обычном режиме, такие объекты как МодульСеанса, а также фоновые и регламентные задания (в которых выполняются обработчики обновления ИБ), выполняются исключительно на стороне сервера 1С:Предприятия в клиент-серверном варианте работы.
Для того чтобы вы могли отлаживать этот код и пользоваться точками останова, на сервере приложений 1С обязательно должен быть включен режим отладки. Разберем, как его активировать:
regedit) или конфигурационный файл службы на сервере Linux.1C:Enterprise 8.3 Server Agent):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server AgentImagePath и добавьте в конец строки запуска ключ -debug.
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debugПосле включения этого режима все серверные процедуры, включая инициализацию параметров сеанса, станут доступны для пошаговой отладки в конфигураторе, что позволит вам быстро локализовать любую непредвиденную ошибку обновления.