Analyzer 1C: как увидеть всю конфигурацию как на ладони через граф знаний
Давайте, дорогие коллеги, вместе разберемся, чем "граф знаний" конфигурации 1С в инструменте "Analyzer 1C" отличается от плоского «Поиска ссылок» в Конфигураторе: карточки объектов, интерактивный граф вызовов, поиск циклических зависимостей и программный доступ к тому же графу для ИИ-агента через MCP.
Целевая аудитория: разработчики и архитекторы 1С, тимлиды, специалисты по аудиту и сопровождению крупных конфигураций.
Ключевые технологии: 1С:Предприятие 8, BSL, граф знаний конфигурации, Model Context Protocol (MCP).
- Почему граф, а не таблица?
- Как устроен граф знаний Analyzer 1C
- Как загрузить конфигурацию
- Как оценить влияние изменения
- Граф знаний доступен и ИИ-агенту
- Визуализация: увидеть связи своими глазами
- Практические сценарии использования
- Ограничения и подводные камни
- Демо-конфигурация «Нано-УТ»: код прилагается
- Как начать прямо сейчас
Коллеги, каждый из нас, кому "посчастливилось" пройти этот "путь посвященных" легко представит себе типичный день разработчика 1С. Вы открываете конфигурацию, которая росла и менялась годами. В ней сотни справочников, документов, регистров, отчетов и общих модулей. Вы пытаетесь понять, почему после изменения одной строки в общем модуле перестал работать конкретный отчет. Вы запускаете «Поиск ссылок» в Конфигураторе. Ждёте. Получаете плоский список из сотен позиций. Вы смотрите на него и не видите картины целиком. Вы видите только список, из которого еще предстоит вручную собирать пазл.
А теперь представьте другой подход. Вы открываете веб-интерфейс Analyzer 1C и видите перед собой дерево типов и подсистем, а рядом - карточку объекта. Кликаете на общий модуль - и во вкладке «Связи» видите все входящие и исходящие связи: другие модули, документы, подписки на события, регламентные задания. Переключаетесь в режим «Граф вызовов» - и видите интерактивную схему: кто вызывает выбранную функцию и что вызывает она сама, вплоть до косвенных путей через подписки и обработчики обновления. Перед глазами вся структура зависимостей, и риск правки можно оценить за пять минут вместо пяти часов.
За этим стоит граф знаний, который Analyzer 1C строит по загруженной конфигурации: объекты, модули, функции, формы, права, подписки, регламентные задания, обработчики обновления, состав типов, RLS-условия, вызовы между функциями и многое другое. В этой статье разберем, как это работает, чем отличается от «Поиска ссылок» в Конфигураторе и какие сценарии эта разница реально закрывает.
🔍 Диагностика: почему граф, а не таблица?
Большинство разработчиков 1С привыкли мыслить таблицами. Структура метаданных в конфигурации - это иерархия, но связи между объектами на разных уровнях этой иерархии образуют сложную сеть. Справочник может использоваться в десятке документов, документ ссылается на несколько справочников, общий модуль вызывается из форм и отчетов, а регистр сведений заполняется движениями документов.
Когда Вы ищете ссылки в Конфигураторе, Вы получаете плоскую таблицу. Вы видите, что объект А используется в объекте Б, но не видите, что объект Б, в свою очередь, используется в объекте В, а тот - в объекте Г. Чтобы понять полную цепочку, Вам нужно делать несколько последовательных поисков, запоминать результаты и мысленно выстраивать связи.
Граф решает эту проблему иначе. В графе знаний Analyzer 1C у объектов и функций есть связи - «ссылается», «вызывает», «подписан», «обработчик», «запускает», «в составе» и другие, у каждой подписан её вид, поэтому смысл связи понятен сразу, без перехода куда-то еще. Режим «Граф вызовов» строит цепочку вызовов на несколько уровней сразу: направление выбирается переключателем «Что вызывает» / «Кто вызывает», и в эту же схему автоматически подмешиваются косвенные пути - через подписки на события, регламентные задания и переопределения обработчиков в расширениях.
Сравните два подхода:
- Табличный поиск. Вы получаете двести строк. Вы видите, что общий модуль используется в двадцати объектах. Чтобы узнать, какие из этих объектов сами используются где-то еще, Вы должны сделать еще двадцать поисков. Через час у Вас будет стопка вкладок с результатами, которые Вы будете пытаться сопоставить руками.
- Графовый поиск. Вы открываете карточку общего модуля, а в ней - функцию, которая Вас интересует, и переключаетесь в «Граф вызовов». На экране сразу видно, кто вызывает эту функцию и что вызывает она сама, а под графом в режиме «Кто вызывает» - таблица прямых вызывающих со сводкой охвата: сколько их всего, в скольких модулях и подсистемах они лежат. Раскрывать цепочку по одному шагу не нужно.
Граф показывает структуру, а в сложной конфигурации она часто важнее самого факта связи.
📂 Обзор: как устроен граф знаний Analyzer 1C
Analyzer 1C - это веб-интерфейс, который читает конфигурацию 1С и строит по ней граф знаний. В нем в одном окне доступны объекты, модули, функции, формы, права, подписки, регламентные задания, обработчики обновления, состав типов, RLS-условия и вызовы между функциями. Этот граф позволяет задавать межсущностные вопросы, на которые в Конфигураторе либо нельзя ответить совсем, либо нужно вручную обходить десятки форм.
Под капотом граф хранится в ArangoDB - её Analyzer 1C держит в памяти вместе с образом на своем сервере (в инструкции по развертыванию указано, что на крупной конфигурации это 6-8 ГБ памяти). Пользователь с ней напрямую не работает: ArangoDB не выставлена наружу, никаких AQL-запросов писать не нужно - весь доступ к графу идет через готовый интерфейс Analyzer 1C или через MCP-протокол для ИИ-агентов.
Узкая полоса значков у левого края окна переключает режимы: «Подсистемы», «Типы объектов», «Роли», «Обзор системы», «Версии», «Конструктор профилей», «Анализ функций», «Граф вызовов», «Циклы», «Изучение подсистем», «Внешние API», «Функциональные опции», «Определяемые типы», «Виды характеристик», «Параметры сеанса», «Обновление ИБ», «Критерии отбора», «XDTO-пакеты», «Код-ревью», «MCP-инструменты». Рядом - единое поле «Поиск объекта…» (Ctrl+K), которое ищет по всему дереву сразу, а не в каждом разделе отдельно.
Клик по любому объекту открывает его карточку - центральный экран программы, с которого начинается большинство расследований. У карточки есть базовые вкладки: «Связи» (все входящие и исходящие связи объекта - ссылки реквизитов, регистраторы, источники подписок, обработчики, функциональные опции, критерии отбора, владельцы команд), «Функции» (все функции и процедуры модулей объекта - модуля объекта, модуля менеджера, модулей всех форм и команд, с числом вызовов), «Команды», «Запросы» (все BSL-запросы, в которых объект участвует как источник или приемник) и «Роли» (какие роли имеют право на объект, с пометкой RLS).
На рис. 1 - вкладка «Связи» у документа «Заказ клиента» из демо-конфигурации, о которой рассказано в конце статьи.
Рис. 1. Карточка документа «Заказ клиента»: 1 вкладка «Связи» - три связи, сгруппированные по типу объекта; 2 документ вызывает общий модуль «Продажи сервер»; 3 ссылается на справочники «Контрагенты» и «Номенклатура». Вид связи подписан в каждой строке.
В реальных внедрениях типовая конфигурация почти всегда дополнена одним или несколькими расширениями. Конфигуратор показывает их раздельно, и сопоставление «что фактически работает» аналитик делает вручную. В Analyzer 1C любая сущность на экране сопровождается пометкой о происхождении - тремя маркерами: 🔌 «Доб.» (сущность создана расширением целиком - своя роль, своя подписка, свой регламент), стрелка «Заимств.» (типовая сущность, к которой расширение раздало права, добавило элемент в состав или привязало подсистему) и карандаш «имя расширения» (расширение подменило обработчик - регламентного задания, конечной точки HTTP или операции SOAP, а исходный обработчик остается видимым). Эти маркеры проходят сквозь все разделы программы.
💻 Практика: как загрузить конфигурацию
Строить граф знаний вручную не нужно - Analyzer 1C разбирает конфигурацию сам при загрузке. Загрузить её можно шестью способами: выгрузка Конфигуратора (zip), монорепозиторий, отдельные git-репозитории, EDT-проект, EDT рабочая область (несколько проектов в одном репозитории) и, начиная с линейки 2.0, напрямую из бинарного файла поставки .cf (конфигурация) или .cfe (расширение), без предварительной выгрузки в файлы. Бинарная загрузка покрывает и конфигурации-гиганты нового формата - поставки ERP больше гигабайта обрабатываются потоково.
Без лицензии доступен анализ одной загруженной системы - зато к этой одной системе можно подключить неограниченное число расширений. Лицензия задает число одновременно загружаемых и сравниваемых систем и дополнительно открывает сравнение и объединение версий, код-ревью, разграничение доступа пользователей и программный доступ для ИИ-агентов через MCP.
Если система загружена из git, Analyzer 1C умеет держать её в актуальном состоянии сам: переключаться между ветками, догружать только новые коммиты и обновляться по расписанию - вручную ничего не нужно перезаливать.
🎯 Решение: как оценить влияние изменения
Допустим, Вы хотите понять, что произойдет, если Вы измените функцию или удалите объект. В Analyzer 1C для этого не нужно писать запрос - достаточно открыть функцию и переключиться в режим «Граф вызовов». Он показывает связи в обе стороны, переключателем «Что вызывает» / «Кто вызывает»: что вызывает выбранная функция дальше и кто вызывает ее саму, на настраиваемую глубину. В графе видны не только прямые вызовы, но и косвенные - через подписки на события, регламентные задания и переопределения обработчиков в расширениях, а прямо на узлах видны переопределения из расширений и переходы между клиентской и серверной частью.
Динамические вызовы (Выполнить, Вычислить, вызов метода по имени) статически не раскрываются - такая стрелка ведет в отдельный узел «?», и неразобранное место видно на схеме сразу. Для функций, у которых вызывающих не сотни, а тысячи, под графом в режиме «Кто вызывает» есть отдельная сводка охвата: сколько прямых вызывающих всего, сколько из них поместилось на схему, в скольких модулях и подсистемах они лежат.
На рис. 2 - режим «Что вызывает» для обработки проведения того же документа «Заказ клиента».
Рис. 2. «Что вызывает» для ЗаказКлиента.ОбработкаПроведения: 1 корень графа - обработка проведения документа; 2 она вызывает ПродажиСервер.ВыполнитьКонтрольЗаказа, откуда цепочка идет через склад к ценам; 3 обратная стрелка из ЦеныСервер.ПолучитьЦену возвращает вызов в модуль продаж. Это кольцо разобрано на рис. 4.
В режиме «Кто вызывает» таблица под графом перечисляет уже вызывающих, а справа появляется сводка охвата (рис. 3).
Рис. 3. «Кто вызывает» для ПродажиСервер.ВыполнитьКонтрольЗаказа: 1 выбранная функция; 2 среди вызывающих есть ЦеныСервер.ПолучитьЦену - функция по кругу через склад и цены вызывает сама себя; 3 сводка охвата: 2 прямых вызывающих в 2 модулях. Таблица внизу перечисляет их с объектом и модулем.
Отдельный раздел «Анализ функций» помечает «нагруженные» функции и модули-гиганты фильтром «🔴 Монстры» - это первые кандидаты на рефакторинг и тщательное тестирование при апгрейде. Там же видно, сколько раз функция обращается к базе данных внутри цикла - частая причина того, что операция, быстрая на десяти строках, встает на десяти тысячах.
📊 Автоматизация: граф знаний доступен и ИИ-агенту
У Analyzer 1C есть MCP-сервер (Model Context Protocol) - программный интерфейс к тому же графу для ИИ-агента. Агент получает состав объектов, связи данных, связи вызовов, влияние правок, листинги и сигнатуры функций, подписки на события, роли и права с текстом RLS-условий, читателей объекта в запросах и кольца циклических зависимостей - и опирается на реальное устройство конфигурации, а не на догадки модели.
Лицензирование: программный доступ через MCP - это возможность полной версии. В Community эндпоинт отвечает HTTP 402.
Среди инструментов сервера - find_object (поиск по имени и синониму), get_structure (реквизиты, владельцы, ссылочные цели), impact (кто и что затронет правка объекта), who_calls (прямые и транзитивные вызывающие функции), roles_of_object и get_role (права и тексты RLS-условий), query_readers (кто читает объект в BSL-запросах) и cycles (кольца циклических зависимостей между модулями).
Важно: оговорка из документации сервера: инструмент impact обходит только граф вызовов, ребра подписок на события и регламентных заданий в этот обход не входят, для них есть отдельный инструмент object_subscriptions.
💻 Практика: визуализация - увидеть связи своими глазами
Граф вызовов в Analyzer 1C интерактивный: можно зумировать колесиком, перетаскивать узлы, кликать на узел для перехода в его карточку, а по правому клику на узле - открыть окно с телом функции и подсветкой синтаксиса BSL, не открывая модуль отдельно. Полотно строится по уровням вызова, поэтому даже сотня узлов читается без мешанины пересечений.
Флажок «Скрыть типовые» убирает с полотна вендорские общие модули, которые заведомо никто не будет править, и сразу говорит цену нажатия - сколько узлов исчезнет; появляется он только тогда, когда для системы назначен эталон поставщика. Готовый граф можно забрать двумя способами: картинкой PNG и текстом диаграммы Mermaid - такой текст можно вставить в описание задачи или в документацию, и через год его получится прочитать и поправить, в отличие от снимка экрана.
Отдельный раздел «Циклы» ищет кольца во взаимных вызовах модулей - когда модуль А вызывает Б, Б вызывает В, а В снова вызывает А. Такие кольца усложняют сопровождение и мешают выносить код в отдельные модули и расширения. Для каждого кольца Analyzer 1C показывает его самое слабое звено - связь, разрыв которой проще всего размыкает цикл, и это отвечает на вопрос «где и что рвать», а не просто «что где связано». На рис. 4 - кольцо из той же демо-конфигурации.
Рис. 4. Раздел «Циклы»: 1 найдено одно кольцо из трех общих модулей весом 5 вызовов; 2 пунктиром отмечено самое слабое ребро, ЦеныСервер → ПродажиСервер с одним вызовом; 3 оно же стоит первым в списке «Где разорвать» со значком 💡. Разорвать кольцо дешевле всего здесь.
🎯 Решение: практические сценарии использования
- Оценка влияния изменений. Вы собираетесь изменить функцию общего модуля. Вместо того чтобы гадать, какие объекты придется проверить, Вы открываете граф вызовов этой функции и видите не только прямых вызывающих, но и транзитивные цепочки, включая косвенные пути через подписки и регламентные задания. Вы можете оценить объем работ за несколько минут.
- Поиск циклических зависимостей. Прежде чем выносить общий модуль в отдельную библиотеку или расширение, раздел «Циклы» покажет, не тянет ли он за собой кольцо обратных вызовов - и подскажет, где кольцо проще всего разорвать.
- Понимание архитектуры. Незнакомая конфигурация, доставшаяся в наследство, перестает быть черным ящиком: «Обзор системы» дает размер конфигурации в цифрах - подсистемы, модули, функции, вызовы, роли, - а «Анализ функций» с фильтром «🔴 Монстры» показывает, какие функции и модули являются центральными хабами, на которые опирается большая часть конфигурации.
- Аудит безопасности. В разделе «Роли и RLS» видно не только права каждой роли, но и полный текст RLS-условия по клику, с подсветкой параметров сеанса. Отдельно подсвечивается установка параметра сеанса в привилегированном режиме (
УстановитьПривилегированныйРежим) - если такой параметр потом используется в RLS-условии, это прямой кандидат в риск-лист. - Обновление типовой при своих доработках. Раздел «Версии» (доступен по лицензии) сравнивает и объединяет конфигурацию так же, как штатное «Сравнение и объединение конфигураций» в Конфигураторе - деревом по типам метаданных, с рекомендацией по каждому изменению, проверкой скрытых конфликтов из-за перехватов расширений и выгрузкой готового файла настроек объединения.
🔍 Аудит: ограничения и подводные камни
У графа знаний есть ограничения, и их лучше знать заранее.
Во-первых, граф строится на основе статического анализа. Он показывает вызовы, которые видны в коде и связях метаданных, но динамические вызовы через Выполнить() или вызов метода по имени, сформированному в рантайме, статически не раскрываются - такие места помечены отдельно, а не выдаются за проверенные.
Во-вторых, у инструмента импакт-анализа impact в MCP-протоколе есть ограничение: он обходит только граф вызовов функций, а не рёбра подписок на события и регламентных заданий - для полной картины «что сработает при записи объекта» нужно смотреть подписки отдельно.
В-третьих, граф нужно поддерживать в актуальном состоянии. Для баз, загруженных из архива или бинарной поставки, обновление делается вручную кнопкой «Перезагрузить»; для git-систем это можно настроить по расписанию, и тогда Analyzer 1C сам подтягивает новые коммиты.
В-четвертых, визуализация большой конфигурации (тысячи узлов и десятки тысяч ребер) может быть перегруженной. Придется использовать фильтры вроде «Скрыть типовые» или «🔴 Монстры», чтобы граф оставался читаемым.
📦 Материалы: демо-конфигурация «Нано-УТ» - код прилагается
Снимки Analyzer 1C выше (рис. 1-4) - не иллюстрация из чужой презентации и не выгрузка чьей-то боевой базы. Специально для этой статьи мы написали крошечную конфигурацию «Нано-УТ»: 2 справочника, документ и 3 общих модуля, всего шесть прикладных объектов. Такого масштаба достаточно, чтобы за пару минут показать «Граф вызовов» и «Циклы» в деле - и не нужно ни лицензии, ни памяти сервера про запас: у по-настоящему больших конфигураций разбор упирается в память сервера (в инструкции по развертыванию Analyzer 1C для крупной конфигурации прямо указано 16-32 ГБ ОЗУ), а на шести объектах загрузка укладывается в пару секунд.
Состав конфигурации:
- справочники «Контрагенты» и «Номенклатура»;
- документ «Заказ клиента» - реквизит-ссылка на контрагента, табличная часть по номенклатуре, обработка проведения;
- общие модули «ПродажиСервер», «СкладСервер» и «ЦеныСервер» - пять функций, из них две вспомогательные (
ЗарезервироватьТовариПолучитьОстаток, они видны на рис. 3), с намеренной кольцевой зависимостью:ПродажиСервер.ВыполнитьКонтрольЗаказавызываетСкладСервер.ПроверитьДоступность, та вызываетЦеныСервер.ПолучитьЦену, а она замыкает круг обратно наПродажиСервер- ровно тот случай, который ищет раздел «Циклы»:
Сама конфигурация - не абстракция: на рис. 5 она в списке баз 1С:Предприятия, в дереве Конфигуратора (со всеми перечисленными объектами) и в запущенном клиенте.
Рис. 5. Нано-УТ - обычная база 1С: (а) в списке информационных баз; (б) в дереве Конфигуратора - три общих модуля, два справочника и документ «ЗаказКлиента»; (в) форма заказа клиента с тестовыми данными: 1 реквизит «Контрагент» - ссылка на справочник, 2 табличная часть со ссылками на «Номенклатуру», 3 кнопка «Провести» запускает ОбработкаПроведения - ту самую цепочку с рис. 2.
Во вложении к статье - архив nano-ut-demo.zip с этой конфигурацией в двух видах: готовый бинарный nano-ut.cf (самый быстрый вариант - загрузите его в Analyzer 1C напрямую, без выгрузки в файлы, способом из раздела «Как загрузить конфигурацию» выше) и XML-исходники nano-ut-xml/ для тех, кто хочет прочитать код до загрузки или подключить конфигурацию через git. Разверните архив, откройте Analyzer 1C (лицензия не нужна - бесплатной версии достаточно) и посмотрите на «Граф вызовов» и «Циклы» своими глазами, на том же самом примере, что и в статье. Одно предупреждение: не проводите заказ в самой демо-базе. Кольцо вызовов в ней настоящее, и проведение уйдет в бесконечную рекурсию - на практике это ровно то, о чем раздел «Циклы» предупреждает заранее.
🤝 Итоги: как начать прямо сейчас
Если Вы хотите попробовать этот подход, Вам не нужно сразу разворачивать инфраструктуру самостоятельно и писать собственные парсеры. Загрузите конфигурацию в Analyzer 1C одним из шести способов - проще всего через выгрузку из Конфигуратора или напрямую из бинарного файла поставки .cf. Без лицензии Вам уже доступен весь разбор устройства конфигурации: дерево метаданных, карточки объектов, роли и RLS, параметры сеанса, функциональные опции, граф вызовов, анализ влияния и циклические зависимости, а также неограниченное число расширений для этой системы.
На каждой плашке анализа есть кнопка «Как пользоваться» - она открывает боковую справку именно по текущему разделу: что показано, зачем нужно и как читать данные. Пояснение всегда под рукой, в контексте открытого экрана.
Уже на этом шаге видно, чем граф удобнее плоского списка ссылок: Вы увидите, как быстро можно получить ответ на вопрос «что сломается, если я это изменю». Дальше можно подключить сравнение версий для апгрейда типовой, код-ревью команды и программный доступ для ИИ-агентов через MCP.
Граф знаний конфигурации пригодится не только продвинутым разработчикам. Он меняет порядок работы: сначала видна структура, потом детали, и архитектурные решения опираются на то, как конфигурация устроена на самом деле.
А как вы сегодня оцениваете влияние правки в незнакомой конфигурации - «Поиском ссылок», собственными скриптами или уже пробовали графовый подход? Делитесь опытом в комментариях.
Теги: Analyzer 1C, граф знаний, Конфигуратор, поиск ссылок, граф вызовов, статический анализ, BSL, MCP, Model Context Protocol, ИИ-агент, циклические зависимости, RLS, рефакторинг, аудит безопасности, git, EDT, сравнение конфигураций, расширения 1С
Analyzer 1C
Структура конфигурации целиком: граф вызовов, зависимости объектов, циклы и влияние изменений – в одном интерфейсе.
Вступайте в нашу телеграмм-группу Инфостарт