Как программно проверить наличие изменений в модуле сеанса или приложения через расширение

При разработке и сопровождении сложных конфигураций 1С программисты часто сталкиваются с необходимостью аудита расширений. Одной из специфических задач является проверка: затронуты ли расширением такие важные части системы, как модуль сеанса, модуль управляемого приложения или модуль обычного приложения. Это критично для своевременного переноса "хотфиксов" в основную конфигурацию или для контроля целостности бизнес-логики.

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

Особенности объектной модели метаданных: Почему "Неопределено"?

Проанализируем сначала причину проблемы. Когда мы пытаемся обратиться к свойству Метаданные.МодульСеанса, платформа возвращает Неопределено. Согласно справке 1С, это нормальное поведение. Дело в том, что в объектной модели метаданных эти модули не являются самостоятельными объектами (как Справочники или Документы), а являются свойствами корневого объекта конфигурации.

Поскольку во встроенном языке не предусмотрена работа со значениями этих свойств напрямую как с объектами, мы не можем получить их текст или программно сравнить версии "на лету" простым обращением. Однако платформа предоставляет другие инструменты для анализа структуры метаданных.

Использование метода ЕстьИзмененияРасширениямиКонфигурации

Начиная с версии платформы 8.3.9, для всех объектов метаданных реализован метод ЕстьИзмененияРасширениямиКонфигурации(). Этот метод позволяет определить, что объект конфигурации был расширен в текущем сеансе. Разберем, как применить его к нашей задаче.

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

// Проверка наличия изменений во всей конфигурации
Если Метаданные.ЕстьИзмененияРасширениямиКонфигурации() Тогда
    Сообщить("В текущем сеансе задействованы расширения, затрагивающие корневые свойства конфигурации.");
КонецЕсли;

Нюанс использования: Метод вернет Истина, если в расширении изменен любой элемент, относящийся к конфигурации в целом (например, изменен заголовок системы, состав префиксов или любой из корневых модулей). Точечно определить, что изменен именно модуль сеанса, этим методом невозможно, но он отлично подходит для первичного фильтра.

Анализ через коллекцию расширений конфигурации

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

Разберем пример обхода расширений:

МассивРасширений = РасширенияКонфигурации.Получить();
Для Каждого ТекущееРасширение Из МассивРасширений Цикл
    // Проверяем, активно ли расширение в данный момент
    Если ТекущееРасширение.Активно Тогда
        // Анализируем метаданные расширения
        ОбъектМетаданныхРасширения = ТекущееРасширение.Метаданные;
        
        // Внимание: прямое обращение к свойству модуля здесь также 
        // вернет Неопределено, но сам факт наличия расширения
        // дает нам повод для более глубокого аудита.
        Сообщить("Проверка расширения: " + ТекущееРасширение.Имя);
    КонецЕсли;
КонецЦикла;

Метод ПолучитьОбъектыИзмененныеРасширениямиКонфигурации (Платформа 8.3.13+)

В современных версиях платформы появился более мощный инструмент — метод ПолучитьОбъектыИзмененныеРасширениямиКонфигурации(). Он возвращает массив объектов метаданных, которые были модифицированы. Посмотрим на пример его использования для целей аудита:

ИзмененныеОбъекты = ПолучитьОбъектыИзмененныеРасширениямиКонфигурации();
Для Каждого ОбъектМетаданных Из ИзмененныеОбъекты Цикл
    Если ОбъектМетаданных = Метаданные Тогда
        Сообщить("Внимание! Расширены корневые свойства конфигурации (модули приложения, сеанса и т.д.)");
    КонецЕсли;
КонецЦикла;

Этот способ является наиболее предпочтительным, так как он позволяет быстро отсеять "тихие" расширения, которые добавляют новые объекты, от тех, что вмешиваются в работу стандартных модулей.

Рекомендации по организации аудита хотфиксов

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

1. Использование маркеров в коде: В расширяемом модуле (например, Модуле Сеанса) в процедуре &После("ПриНачалеСеанса") добавьте запись в лог или параметр сеанса, указывающий на версию расширения.
2. Выгрузка в XML для детального сравнения: Наиболее надежный способ узнать, какие строки кода были изменены — это пакетная выгрузка расширения в файлы. При выгрузке через /DumpCustomExtensionToFiles в каталоге появятся файлы типа Ext/SessionModule.bsl. Если такой файл существует и не пуст — модуль расширен.
3. Интеграция с Git: Ведение разработки расширений в системе контроля версий позволяет мгновенно видеть все изменения в модулях, не прибегая к написанию сложных программных проверок внутри самой 1С.

Таким образом, хотя прямого способа получить текст Метаданные.МодульСеанса не существует, сочетание метода ЕстьИзмененияРасширениямиКонфигурации() и анализа коллекции активных расширений позволяет эффективно решать задачи контроля и уведомления о внесенных изменениях.