Как безопасно повысить версию платформы и режим совместимости в 1С:Управление торговлей 11.1

Процесс обновления технологической платформы и изменения режима совместимости конфигурации — это не просто формальная процедура. Для таких зрелых решений, как Управление торговлей 11.1, изначально разработанных под старые стандарты платформы (например, 8.3.2), такой переход может стать причиной серьезных технических сбоев. В данной статье мы подробно разберем, с какими трудностями можно столкнуться при переходе на платформу 8.3.8 и режим совместимости 8.3.6 или 8.3.7, и как минимизировать риски.

Зачем менять режим совместимости и на что это влияет?

Режим совместимости — это свойство конфигурации, которое заставляет новую платформу имитировать поведение старых версий. Если мы повышаем этот режим, мы «развязываем руки» платформе, позволяя ей использовать новые механизмы работы с базой данных, интерфейсом и кодом. Однако код, написанный под старые стандарты, может оказаться не готов к новым правилам игры.

Рассмотрим основные области, которые попадают под удар при повышении режима до 8.3.6 и выше:

• Отрисовка управляемых форм: Изменяются алгоритмы расчета размеров элементов.
• Механизмы блокировок: Платформа по-другому управляет доступом к таблицам СУБД.
• Работа распределенных баз (РИБ): Меняются форматы сериализации данных в сообщениях обмена.
• Безопасный режим: Усиливаются ограничения на работу с файлами и внешними компонентами.

Проблемы интерфейса: почему «съезжают» формы?

Одной из самых заметных проблем при переходе на режим совместимости 8.3.6 и выше является визуальное искажение интерфейса «Такси». Проанализируем, почему это происходит. Начиная с режима 8.3.7, 1С ввела понятие плотности интерфейса. Появились варианты «Компактный» и «Обычный».

Если конфигурация УТ 11.1 проектировалась под режим 8.3.2, то при включении 8.3.7 многие поля ввода, кнопки и группы могут изменить свои отступы. Практика показывает, что в режиме 8.3.6 формы часто выглядят хуже, чем в 8.3.7, так как именно в 8.3.7 были добавлены механизмы адаптации, которые частично исправляют огрехи отрисовки. Если вы заметили, что элементы управления наложились друг на друга или «уехали» за границы видимости, приготовьтесь к ручной корректировке наиболее важных форм документов продаж и справочников.

Особенности работы распределенных информационных баз (РИБ)

Работа с РИБ при смене платформы требует особой осторожности. Рассмотрим ключевые риски:

1. Несовпадение версий на узлах: Крайне не рекомендуется работать в ситуации, когда на центральном узле стоит платформа 8.3.8, а на периферийном — 8.3.5. Разные версии могут по-разному интерпретировать блокировки при загрузке данных, что приведет к «зависанию» сеансов обмена.
2. Структура XML-сообщений: При повышении режима совместимости меняется логика сериализации некоторых системных объектов. Если вы обновите режим только в центре, периферийный узел может просто не «понять» файл обмена, выдав ошибку чтения XML.
3. Критическая ошибка платформы 8.3.8: В некоторых релизах ветки 8.3.8 была замечена ошибка, при которой невозможно штатно отвязать периферийный узел от центрального (сделать базу автономной). Если ваша технология обслуживания базы подразумевает частые отвязки узлов, протестируйте этот функционал заранее.

Изменения в работе с кодом и СУБД

Выясним, какие изменения происходят «под капотом» платформы при переходе на режим 8.3.6. Рассмотрим наиболее важные аспекты для разработчика.

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

// Если используется профиль безопасности, 
// необходимо явно разрешить доступ к внешним ресурсам.
УстановитьБезопасныйРежим(Ложь); 
// В новых версиях платформы это может потребовать 
// настройки в консоли администрирования сервера.

Временные таблицы в запросах. В режиме совместимости 8.3.6 меняется алгоритм работы с временными таблицами. Платформа начинает более эффективно использовать возможности SQL-сервера. Однако на неоптимизированных запросах это может привести к изменению планов запросов и неожиданным блокировкам Range в MS SQL Server. Если база файловая, вы этого не заметите, но при переходе на клиент-сервер проблема может стать критичной.

Уникальность объектов. В обсуждениях часто упоминается проблема «неуникальности картинок». Это связано с тем, что в новых режимах изменился внутренний алгоритм сравнения ссылок для некоторых системных перечислений и объектов. При обновлении метаданных платформа может запустить реструктуризацию, которая займет длительное время.

Пошаговый алгоритм перехода

Разберем последовательность действий, которая позволит избежать простоя системы:

1. Создание полной копии: Это касается не только основной базы, но и хотя бы одного узла РИБ.
2. Поэтапное повышение: Не прыгайте сразу с 8.3.2 на 8.3.7. Рекомендуется сначала обновить платформу до нужной версии (например, 8.3.8.2137), сохранив старый режим совместимости. Проверьте работоспособность. Затем повышайте режим до 8.3.3, и только потом до 8.3.6 или 8.3.7.
3. Тестирование под нагрузкой: Поскольку в файловом варианте сложно воспроизвести многопользовательские блокировки, используйте специализированные инструменты, такие как «Тест-центр».
4. Проверка фоновых заданий: В новых режимах ужесточена проверка параметров, передаваемых в фоновые задания. Убедитесь, что все передаваемые структуры данных поддерживают сериализацию.

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

Подводя итог, можно сказать: повышение режима совместимости в УТ 11.1 до 8.3.6 допустимо и часто необходимо для работы современных подсистем. Основное внимание следует уделить проверке внешнего вида форм и стабильности обменов РИБ. Если есть возможность избежать повышения режима совместимости (например, переписав часть кода подсистемы), лучше воспользоваться этим вариантом, обновив только саму платформу.