Как найти все связанные объекты и ссылки в коде при переносе функционала в 1С?

← На главную

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

Выясним причину: почему штатный поиск ссылок не видит программный код

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

Типы реквизитов и табличных частей объекта.
Состав планов обмена, подписок на события, определяемых типов.
Регистраторы для регистров и владельцев для справочников.

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

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

Способ 1. Итерационный перенос через сравнение и синтаксический контроль модулей

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

Создаем копию базы-приемника, в которую планируется перенос.
Выгружаем конфигурацию-источник (откуда берется функционал) в файл конфигурации (расширение .cf) через меню Конфигурация → Сохранить конфигурацию в файл....
В копии базы запускаем операцию Конфигурация → Сравнить, объединить с конфигурацией из файла... и выбираем только целевой объект метаданных (например, конкретный справочник). Выполняем объединение.
Запускаем синтаксический контроль: в меню выбираем Конфигурация → Проверка конфигурации.... Обязательно устанавливаем флажки Поиск синтаксических ошибок в модулях и Поиск неразрешенных ссылок.
Анализируем отчет об ошибках. Конфигуратор выдаст список всех обращений к несуществующим общим модулям, процедурам, реквизитам и сторонним объектам метаданных.
Возвращаемся в сравнение и объединение с исходным .cf, допереносим выявленные недостающие объекты (общие модули, перечисления, регистры) и повторяем проверку до тех пор, пока модули не скомпилируются без ошибок.

Способ 2. Использование 1C:Enterprise Development Tools (EDT)

Если для разработки используется среда 1C:Enterprise Development Tools (EDT), задача решается значительно быстрее. В основе EDT лежит абстрактное синтаксическое дерево (AST) и семантическая модель проекта. В отличие от стандартного Конфигуратора, EDT непрерывно индексирует и анализирует весь BSL-код.

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

Контекстное действие Найти ссылки (Find References): работает сквозным образом не только по структуре данных, но и по BSL-коду, находя все прямые вызовы менеджеров, методов и форм.
Автоматическая подсветка разорванных ссылок: среда сразу отмечает желтыми и красными маркерами все обращения к типам и объектам, которых нет в проекте.
Построение графа зависимостей объектов метаданных встроенными средствами среды.

Способ 3. Выгрузка в файлы и поиск по регулярным выражениям (RegEx)

Когда требуется быстро проанализировать объемный программный код переносимого объекта без ручной вычитки, воспользуемся выгрузкой конфигурации в файлы XML/BSL (меню Конфигурация → Выгрузить конфигурацию в файлы...).

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

Поиск вызовов менеджеров объектов в BSL-коде:


\b(Справочники|Документы|РегистрыСведений|РегистрыНакопления|РегистрыБухгалтерии|РегистрыРасчета|ПланыВидовХарактеристик|ПланыСчетов|ПланыОбменов|Перечисления|Обработки|Отчеты)\.[A-Za-zА-Яа-я0-9_]+

Этот паттерн найдет все конструкции вида Справочники.Контрагенты, Документы.Приход, РегистрыСведений.ЦеныНоменклатуры.

Поиск обращений к таблицам в текстах запросов: Помним, что в языке запросов имена таблиц пишутся в единственном числе. Для их поиска используем следующий шаблон:
```
\b(Справочник|Документ|РегистрСведений|РегистрНакопления|РегистрБухгалтерии|ПланВидовХарактеристик|Перечисление)\.[A-Za-zА-Яа-я0-9_]+
```
Такой запрос найдет строки вида Справочник.Номенклатура или Документ.ПриходнаяНакладная внутри многострочных литералов запросов.

Способ 4. Программный поиск через коллекцию метаданных

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


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

КонецПроцедуры

Скрытые зависимости, о которых важно помнить

Даже если синтаксическая проверка и поиск по менеджерам не показывают ошибок, код может содержать неявные связи, приводящие к ошибкам во время исполнения (в Runtime). Разберем, на что обратить особое внимание:

Динамическое создание типов: конструкции вида Новый ОписаниеТипов("СправочникСсылка.Организации") или вызовы Тип("ДокументСсылка.ПоступлениеТоваровУслуг"). В них имя передается строковым литералом, который не проверяется синтаксическим контролем.
Методы Библиотеки стандартных подсистем (БСП): функции вида ОбщегоНазначения.ПолучитьЗначениеРеквизита(Ссылка, "ИмяРеквизита") или вызовы ОткрытьФорму("Обработка.ПодборНоменклатуры.Форма").
Подписки на события: сам переносимый объект может не содержать ссылок на сторонний код, но в конфигурации-источнике могут существовать общие подписки на события (например, ПередЗаписью или ОбработкаПроведения), привязанные к источнику СправочникОбъект.ИмяСправочника. При переносе объекта без подписок поведение системы изменится без видимых синтаксических ошибок.
Вызовы через выполнение строк: операторы Выполнить() и Вычислить(), а также обращения через Метаданные.НайтиПоПолномуИмени().

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