Как обновить режим совместимости расширений при переходе на новые версии БП 3.0 и ЗУП 3.1

← На главную

При обновлении типовых конфигураций (например, Бухгалтерия предприятия 3.0.65 или Зарплата и управление персоналом 3.1.8) многие разработчики сталкиваются с ситуацией, когда платформа повышает минимальные системные требования. В частности, происходит переход с режима совместимости 8.3.10 на 8.3.12. Это изменение напрямую влияет на работу расширений: если режим совместимости расширения не соответствует режиму основной конфигурации, система может заблокировать его подключение.

В рамках этой статьи мы разберем, как правильно управлять режимами совместимости расширений, проанализируем способы автоматизации этого процесса для большого количества информационных баз и изучим инструменты программного контроля.

Понимание свойств режима совместимости в расширениях

Прежде чем переходить к действиям, проанализируем структуру свойств расширения. У каждого расширения есть два важных параметра в палитре свойств:

Режим совместимости — определяет поведение платформы для кода и метаданных внутри расширения.
Режим совместимости расширения конфигурации — технический параметр, который должен гармонировать с основной конфигурацией.

Разберем ситуацию: если в основной конфигурации установлен режим 8.3.12, а в расширении остался 8.3.10, платформа при запуске может выдать критическую ошибку. Это происходит потому, что механизмы работы с типами данных, генерация запросов и работа с XDTO в версии 8.3.12 претерпели значительные изменения. Критически важно приводить эти режимы к единообразию для обеспечения стабильности системы.

Способ 1: Ручное изменение через Конфигуратор

Если у вас в поддержке всего пара информационных баз, наиболее простым и надежным методом будет ручная корректировка. Рассмотрим последовательность действий:

Откроем информационную базу в режиме Конфигуратор.
Перейдем в меню Конфигурация — Расширения конфигурации.
Для каждого расширения в списке откроем Палитру свойств (правая кнопка мыши — Свойства).
Найдем раздел Совместимость.
Изменим значение в поле Режим совместимости на актуальное (например, 8.3.12).
Выполним команду Проверить возможность применения в контекстном меню расширения. Это позволит выявить конфликты в метаданных до запуска предприятия.

Этот метод кажется трудоемким, если баз много, однако он гарантирует, что вы сразу увидите возможные ошибки компиляции кода, которые могли возникнуть из-за ужесточения требований новой платформы.

Способ 2: Автоматизация через выгрузку в файлы

Когда количество баз исчисляется десятками, ручной труд становится неэффективным. Проанализируем методику автоматизации через пакетный режим работы конфигуратора. Мы можем выгрузить расширение в файлы, программно изменить настройки и загрузить обратно.

Рассмотрим алгоритм действий для автоматизации:

Выгружаем расширение в XML-файлы с помощью команды командной строки: /DumpConfigToFiles.
В полученном каталоге находим файл ConfigDumpInfo.xml или корневой файл описания метаданных расширения.
Используя скрипт (например, на языке OneScript или любом текстовом парсере), находим узел, отвечающий за CompatibilityMode, и меняем его значение.
Загружаем измененные файлы обратно в базу командой /LoadConfigFromFiles.
Обновляем конфигурацию базы данных.

Такой подход позволяет массово обновить расширения во всех филиалах или у всех клиентов без необходимости открывать каждое окно свойств вручную.

Способ 3: Программный контроль расширений во встроенном языке

Иногда расширения «отваливаются» незаметно для администратора. Чтобы вовремя среагировать на проблему несовпадения режимов совместимости, мы можем написать служебную обработку или добавить код в процедуру ПриНачалеРаботыСистемы. Выясним, какие инструменты нам предоставляет встроенный язык 1С.

Для анализа используем объект РасширенияКонфигурации. Посмотрим на пример кода, который проверяет возможность применения всех подключенных расширений:


ВыборкаРасширений = РасширенияКонфигурации.Получить();
Для Каждого Расширение Из ВыборкаРасширений Цикл
    Если Не Расширение.Активно Тогда
        Продолжить;
    КонецЕсли;
    
    Попытка
        Расширение.ПроверитьВозможностьПрименения();
    Исключение
        ТекстОшибки = СтрШаблон("Расширение '%1' не может быть применено: %2", 
            Расширение.Имя, КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
        ЗаписьЖурналаРегистрации("ПроверкаРасширений", 
            УровеньЖурналаРегистрации.Ошибка, , , ТекстОшибки);
    КонецПопытки;
КонецЦикла;

Использование метода ПроверитьВозможностьПрименения() крайне полезно, так как оно имитирует полную проверку платформой всех связей и свойств, включая режим совместимости. Если расширение не соответствует новой версии платформы, система сгенерирует исключение, которое мы сможем зафиксировать в журнале регистрации или вывести в виде уведомления администратору.

Дополнительные инструменты: EDT и БСП

Проанализируем современные средства разработки. Если вы используете 1C:Enterprise Development Tools (EDT), процесс массового рефакторинга значительно упрощается. EDT позволяет менять свойства проектов (включая режим совместимости) для целой группы расширений одновременно и сразу подсвечивает места в коде, которые перестанут работать в новом режиме.

Также стоит обратить внимание на механизмы Библиотеки стандартных подсистем (БСП), которые активно используются в БП 3.0 и ЗУП 3.1. В разделе «Обслуживание» — «Управление расширениями» типовые конфигурации уже содержат встроенные средства мониторинга. После обновления на 8.3.12 обязательно загляните в раздел «Известные проблемы приложений». БСП часто выводит туда детальные отчеты о том, какие расширения не смогли подключиться из-за конфликта версий или режимов совместимости.

Резюмируем: при переходе на новые релизы типовых решений автоматическая смена режима совместимости расширений платформой не предусмотрена. Вам необходимо либо вручную обновить это свойство, либо использовать скрипты для пакетной обработки XML-описаний метаданных. Не забывайте использовать метод ПроверитьВозможностьПрименения() для превентивного обнаружения проблем.