Рассмотрим актуальный вопрос для многих системных администраторов и разработчиков 1С: целесообразность обновления версии платформы до 8.3.14 для конфигураций, которые были значительно изменены (кастомизированы) и работают в режиме совместимости с более старыми версиями (например, 8.2.16). Проанализируем ситуацию на примере «Управление торговлей 11.1», разберем возможные риски и преимущества такого перехода.
Выясним основную причину, по которой возникает необходимость такого перехода. Зачастую это не требование самой конфигурации «Управление торговлей», а необходимость унификации инфраструктуры. В современной ИТ-среде на одном сервере часто соседствуют несколько баз данных:
Содержание нескольких версий платформ на одном сервере усложняет администрирование, требует настройки разных портов для кластеров и увеличивает нагрузку на ресурсы. Поэтому желание перевести всё на единую версию 8.3.14 вполне обосновано.
Проанализируем техническую сторону вопроса. Если ваша конфигурация работает в режиме совместимости Версия 8.2.16, то переход на платформу 8.3.14 сам по себе не даст вам новых инструментов разработки автоматически. Многие механизмы платформы продолжат работать по старым алгоритмам, чтобы обеспечить работоспособность кода.
Важно понимать: без поднятия режима совместимости в самой конфигурации (в дереве метаданных) вы не получите доступ к продвинутым механизмам расширений, новым типам данных или оптимизированным методам работы с интерфейсом. Однако платформа 8.3.14 все равно вносит свои коррективы в работу системы, даже если режим совместимости не менялся.
Разберем одну из самых серьезных проблем, с которой сталкиваются пользователи при переходе на версии платформы выше 8.3.13. Речь идет об изменении механизмов XML-сериализации данных. Даже при сохранении режима совместимости методы обмена данными могут вести себя иначе.
Посмотрим на пример ситуации в РИБ. Если вы обновите платформу на центральном узле до 8.3.14, а на периферийном оставите 8.3.11, велика вероятность возникновения критической ошибки при попытке прочитать сообщение обмена. Типичная ошибка выглядит так:
// Ошибка при вызове метода ПрочитатьИзменения()
// Ошибка чтения данных: несоответствие типов или структуры XML
Это связано с тем, что в новых версиях платформы была пересмотрена логика формирования XML-пакетов. Поэтому критически важно обновлять платформу на всех узлах распределенной сети одновременно.
Проанализируем возможности расширений. Многие разработчики надеются, что переход на 8.3.14 позволит им перенести накопленные доработки из основной конфигурации в расширения, чтобы упростить будущие обновления. Однако здесь их ждет разочарование.
В режиме совместимости 8.2.16 механизм расширений крайне ограничен. Вы сможете менять только программный код и формы, но не сможете добавлять новые объекты метаданных или менять структуру существующих. Полноценная работа с расширениями (добавление справочников, документов в расширение) стала доступна только начиная с режима совместимости 8.3.11. Если ваше начальство хочет «перемен» и использования расширений, вам придется не только менять платформу, но и проводить серьезный аудит кода для повышения режима совместимости всей конфигурации.
Рассмотрим, как новая платформа взаимодействует с СУБД. На практике замечено, что платформа 8.3.14 может иначе генерировать планы запросов для SQL-сервера. Для старых запросов УТ 11.1 это иногда приводит к деградации производительности. Чтобы минимизировать риски, после установки новой платформы рекомендуется выполнить следующие действия на стороне SQL Server:
Выясним, в чем заключается неоспоримое преимущество версии 8.3.14. Старые платформы (8.3.11 и ниже) используют устаревшие библиотеки OpenSSL. Это становится критичным при интеграции с внешними веб-сервисами, банками или государственными системами (ЭДО, Честный Знак, ЕГАИС), которые требуют протоколов шифрования TLS 1.2 и выше. Платформа 8.3.14 полноценно поддерживает эти стандарты «из коробки», что избавляет от проблем с установкой сторонних компонент или «проксей» для шифрования трафика.
Посмотрим на вопрос с точки зрения конечного пользователя. Платформа 8.3.14 — это одна из первых версий, где 64-битный тонкий и толстый клиенты стали работать достаточно стабильно. Для пользователей УТ 11.1, которые часто формируют тяжелые отчеты (например, «Анализ доступности товаров» или «Ведомость по расчетам с партнерами» за большой период), это может стать спасением от ошибки Недостаточно памяти.
Подведем итог и составим план действий. Если вы решили, что переход на 8.3.14 необходим для унификации системы, действуйте по следующему алгоритму:
8.3.11. Помните, что это может потребовать переписывания некоторых участков кода, где используются устаревшие конструкции.Таким образом, переход на 8.3.14 для старой УТ 11.1 оправдан только в случае острой необходимости работы с современными веб-сервисами или при требовании системных администраторов к единообразию серверной части. В остальном — правило «работает — не трогай» для сильно допиленных систем остается золотым стандартом.