Переход с платформы 1С:Предприятие 8.2 (образца 2010 года) на современные релизы ветки 8.3 — это не просто техническое обновление, а полноценная миграция через технологическую пропасть в 11 и более лет. Для сильно кастомизированных систем, где 60% функционала написано с нуля на обычных формах, такой скачок несет в себе риски, которые могут парализовать работу предприятия. Проанализируем основные узлы системы, которые наиболее подвержены поломкам при подобном апгрейде, и разберем, как подготовиться к изменениям.
Первое, с чем мы столкнемся, — это свойство конфигурации РежимСовместимости. Даже если мы запускаем базу на платформе 8.3, конфигурация может продолжать работать в режиме эмуляции 8.2. Однако, для использования новых возможностей платформы или из-за требований современных СУБД, этот режим рано или поздно придется повышать. Рассмотрим подробнее, что при этом меняется.
Платформа 8.3 существенно изменила механизмы генерации SQL-запросов. Проанализируем ситуацию: если в версии 8.2 СУБД MSSQL прощала некоторые неоптимальные конструкции, то в 8.3 при смене режима совместимости может измениться логика индексации и использования временных таблиц. Это часто приводит к резкому падению производительности (Timeout) на тех участках кода, которые раньше работали стабильно. Посмотрим на типичный пример, где может возникнуть проблема:
// В 8.2 этот запрос мог работать быстро за счет неявных механизмов СУБД
// В 8.3 при отключении совместимости требуется явная типизация полей
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Документ.Ссылка ИЗ Документ.Реализация КАК Документ ГДЕ Документ.Дата > &Дата";
Важный момент: в 8.3 платформа стала более требовательной к типизации. Код, который ранее допускал сравнение разнородных типов данных или неявное преобразование, начнет выбрасывать исключения во время выполнения.
Для систем с множеством интеграций через веб-сервисы обновление платформы — наиболее болезненный этап. В 8.3 реализована гораздо более строгая проверка схем XML. Разберем по шагам, что именно может пойти не так:
string, а внешняя система присылает пустой тег, который 8.3 интерпретирует как NULL, возникнет ошибка разбора XDTO, хотя 8.2 могла просто пропустить это значение.Проанализируем пример кода, который часто требует проверки при переходе:
// Обратите внимание на создание фабрики XDTO
ТипОбъекта = ФабрикаXDTO.Тип("http://www.site.ru/integration", "CustomData");
// В 8.3 проверка структуры ОбъектаXDTO на соответствие схеме происходит жестче
Попытка
Объект = ФабрикаXDTO.Создать(ТипОбъекта);
Исключение
ЗаписьЖурналаРегистрации("Ошибка XDTO", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
КонецПопытки;
Многие системы 2010-х годов использовали 32-битный сервер 1С. Современные стандарты подразумевают использование 64-битных серверов (x64). Выясним причину, по которой это ломает систему: все внешние компоненты (библиотеки .dll), написанные для интеграции с оборудованием, криптографией или почтой, должны иметь 64-битную версию. Если вы переходите на 64-битную платформу 8.3, старые 32-битные ActiveX или COM-объекты просто не загрузятся.
Также не забудем про comcntr.dll. При установке нескольких версий платформ на одном сервере часто возникают конфликты регистрации COM-класса. Это приводит к ошибкам вида "Класс не зарегистрирован" при попытке внешнего подключения к базе. Рекомендуем всегда проверять регистрацию актуальной версии библиотеки через regsvr32.
При первом запуске на 8.3 платформа может инициировать реструктуризацию таблиц базы данных. Посмотрим на риски, связанные с этим процессом. В версиях платформы 8.3.15 и выше был введен механизм дискретной реструктуризации. На огромных объемах данных это может выявить скрытые проблемы — например, дублирующиеся записи в уникальных индексах, которые "накопились" в базе за 11 лет из-за сбоев в 8.2.
Особое внимание итогам: Алгоритмы хранения итогов в регистрах накопления и бухгалтерии в 8.3 оптимизированы. После обновления крайне важно выполнить полный пересчет итогов через "Тестирование и исправление". Разберем, почему это нужно: разница в алгоритмах округления или хранения моментов времени может привести к незначительным, но критичным для учета расхождениям в остатках.
В платформе 8.3 появилась концепция "Защиты от опасных действий". Рассмотрим ситуацию: пользователь или фоновое задание запускает внешнюю обработку. В 8.2 это происходило мгновенно. В 8.3 система выдаст предупреждение или заблокирует выполнение, если обработка не внесена в список доверенных. Для монолита с множеством внешних связей это может означать остановку всех регламентных заданий.
Для корректной работы в 8.3 проанализируем настройки профилей безопасности на сервере 1С. Вам может потребоваться явно разрешить расширениям или внешним обработкам доступ к файловой системе или интернет-ресурсам.
На основе опыта многих специалистов, переходить "в один прыжок" крайне рискованно. Выделим основные шаги безопасной миграции:
ВнешниеКомпоненты, COMОбъект и обращения к веб-сервисам.УстановитьПериодРассчитанныхИтогов для всех регистров.Подводя итог, можно сказать, что главная сложность — не в самой платформе 8.3, а в накопленном за десятилетие техническом долге. Тщательный анализ изменений в каждом релизе платформы (раздел "Изменения, требующие доработки в конфигурации") и поэтапный подход позволят минимизировать ущерб от обновления.