Analyzer 1C — навигация по сложным конфигурациям
Когда конфигурация содержит тысячи объектов, сотни ролей и десятки расширений — понять, «что от чего зависит», становится нетривиальной задачей. Analyzer 1C решает эту проблему: инструмент парсит выгрузку конфигурации (ZIP), строит граф зависимостей и показывает результат в удобном веб-интерфейсе.
В статье показано на примере 1С:ERP. Управление холдингом (18 780 модулей, 341 925 функций, 2 032 роли), как инструмент помогает разработчику ориентироваться в крупной конфигурации.
- Парсинг конфигурации из ZIP-выгрузки
- Построение графа зависимостей между объектами
- Анализ основной конфигурации и всех расширений
- Отображение заимствований и переопределений
- Выявление перекрёстных зависимостей
Конфигуратор 1С показывает расширение изолированно — вы видите объекты одного расширения, но не видите полной картины: какие функции основной конфигурации переопределены, какие объекты заимствованы несколькими расширениями одновременно, как расширения зависят друг от друга.
Собрать эту информацию штатными средствами платформы практически невозможно — нужно открывать каждое расширение по отдельности и вручную сопоставлять. Analyzer 1C объединяет основную конфигурацию и все расширения в единый граф, показывая заимствования, переопределения и перекрёстные зависимости в одном интерфейсе.
Что умеет инструмент
Навигация по конфигурации
Интерфейс разделён на две части: слева — дерево навигации, справа — панель деталей выбранного объекта. Переключение между режимами навигации — через вкладки «Подсистемы», «Типы», «Роли», «Инфо».
Интерфейс разделён на две части: слева — дерево навигации, справа — панель деталей выбранного объекта. Переключение между режимами навигации — через вкладки «Подсист.», «Типы», «Роли», «Инфо».
Дерево типов
Режим «Типы» группирует все объекты конфигурации по типам метаданных: общие модули, справочники, документы, регистры и т.д. Каждая группа показывает количество объектов. Заголовки групп «прилипают» к верху при прокрутке — удобно ориентироваться в длинных списках.
Дерево типов 1С:ERP. Управление холдингом — 18 780 модулей в 20 типах метаданных
Дерево подсистем
Режим «Подсист.» отражает иерархию подсистем конфигурации. Для каждой подсистемы показываются вложенные подсистемы и типы объектов с количеством. Объекты расширений помечены жёлтой меткой «Доб.», заимствованные — зелёной «Заимств.» с именем расширения-источника. Это позволяет сразу видеть, какие расширения затронули каждую подсистему.
Подсистемы ERP УХ с объектами расширения «Управление Лизинговой компании»
Поиск
Поиск работает по всем типам объектов одновременно: модулям, справочникам, документам, ролям, подсистемам. Результаты группируются по типам с цветовыми маркерами и появляются по мере ввода текста. Объекты, добавленные или изменённые расширениями, помечаются жёлтой меткой «Доб.» с именем расширения — сразу видно, что пришло из расширения, а что из основной конфигурации.
Поиск «лизинг» — обычные объекты, заимствованные (зелёная метка «Заимств.») и устаревшие в одном списке
Функциональные опции: что отключают и где проверяются
1.6.21 — Что нового
В типовых на 1С — десятки и сотни функциональных опций («Использовать партионный учёт», «Учёт по складам», «Многофирменность»), которыми внедренец и архитектор управляют видимостью и поведением конфигурации. Когда заходит вопрос «что сломается, если выключить опцию X», или наоборот «откуда у клиента взялись эти лишние команды и реквизиты», ответ обычно собирался руками: открыть опцию в конфигураторе, посмотреть состав, потом грепнуть код по ПолучитьФункциональнуюОпцию — и держать всё это в голове.
В этом релизе функциональные опции стали полноценным разделом анализатора. Видно сразу: что опция отключает, где её значение читается в коде, и какие опции затрагивают конкретный объект, когда вы открываете его карточку.
Раздел «Функциональные опции»
Список функциональных опций ЕРПУХ — сайдбар, активные сверху
Сайдбар «Функц.опции» в режиме «1С:ERP. Управление холдингом». В ЕРПУХ — больше тысячи опций; в этом кадре видны актуальные сверху списка (счётчики 📦/🎛/🔎 справа), а устаревшие («Не использовать», «удалить», «obsolete» и т.п.) автоматически уходят вниз и показываются полупрозрачными — чтобы не отвлекать.
В верхней панели появился чип режима «Функц.опции». Слева — список всех опций конфигурации, отсортированных по имени, с поиском по подстроке (имя или синоним).
В каждой строке списка — заголовок опции и три счётчика снизу:
📦 Состав — сколько элементов записано в Content опции (объекты, реквизиты, команды).
🎛 Контролирует — сколько объектов конфигурации эта опция реально отключает (после резолва путей в граф).
🔎 Проверяется — в скольких функциях BSL значение опции читается через ПолучитьФункциональнуюОпцию.
Если опция собственная для расширения — на ней маркер 🔌 с именем расширения. Если у опции стоит «Привилегированное получение значения» — маркер 🔒. Чек-бокс «🔌 Только затронутые расширениями» оставляет в списке только опции, чей состав или само определение правит какое-нибудь расширение.
Что опция отключает
Карточка опции «Использовать аналоги материалов»: состав и проверки
Карточка опции «Использовать аналоги материалов» из ЕРПУХ. Сверху — состав («3 объекта конфигурации»: 1 документ и 2 регистра сведений), все три тегом «Объект целиком». Снизу — блок «Проверяется в коде»: 3 обработки и 1 отчёт, в каждой строке справа — бейдж с числом проверок («1 проверка», «2 проверки» с правильным склонением).
Клик по опции открывает её карточку. Сверху — заголовок с маркерами 🔌/🔒, имя в техническом виде и источник значения: либо константа конфигурации, либо общий модуль с функцией расчёта, либо «По хранимому значению».
Главный блок — «Что отключает опция». Состав опции сгруппирован по типу метаданных (Справочники, Документы, Регистры…), а внутри группы — по конкретным объектам. Раскрытие двойное: можно свернуть группу целиком, можно — конкретный объект.
В каждой строке объекта правый бейдж сразу показывает, что именно опция там трогает. Категорий — восемь, и каждая со своим цветом:
- Объект целиком (бирюза) — опция убирает объект полностью.
- Реквизит (синий) — опция управляет конкретным реквизитом.
- Реквизит ТЧ (голубой) — реквизит внутри табличной части.
- Таб.часть (фиолетовый) — табличная часть объекта целиком.
- Команда (оранжевый).
- Ресурс / Измерение (розовый/жёлтый) — для регистров.
- Подсистема (серый) — вложенная подсистема в составе родительской.
Это важно, потому что разные опции воздействуют на очень разные куски данных. Раньше всё, кроме реквизита и команды, сваливалось под «объект целиком» — и пользователь думал, что опция убирает, например, весь справочник Номенклатура. На самом деле она отключала только табличную часть «ДополнительныеРеквизиты». Теперь бейдж говорит правду: «таб.часть» — значит таб.часть, «реквизит ТЧ» — значит реквизит внутри неё, и так далее.
Раскрыв строку объекта, видно поимённый список с цветными тегами категории для каждой строки.
Если в составе опции часть путей пришла из расширений — рядом с такими элементами стоит маркер 🔌 с именем расширения, чтобы было видно, что эту строку добавил не вендор типовой.
Если в графе оказалось меньше элементов, чем записано в Content опции (это нормально — реквизиты и команды хранятся не как самостоятельные узлы, а внутри своих объектов; либо ссылка указывает на объект из ещё не подгруженного расширения), под заголовком блока появляется поясняющая жёлтая плашка с числами.
Где значение опции читается из кода
Второй блок карточки — «Проверяется в коде». Это перечень функций, в теле которых вызывается чтение значения этой опции (в обычной форме или в «интерфейсной» — ПолучитьФункциональнуюОпцию и ПолучитьФункциональнуюОпциюИнтерфейса). Опции из БСП-обвязки тоже учитываются.
Перечень устроен так же, как состав, — группировка по типу метаданных и по объекту. Бейдж справа от объекта показывает, в скольких функциях этого объекта значение опции реально читается («1 проверка», «3 проверки», «12 проверок» — всё с правильным склонением). Раскрыв строку объекта, видно поимённый список функций, в которых опция читается; перед каждым именем стоит зелёный тег «Функция», чтобы не путать «функция-место проверки» с привычной «реквизит/команда зависит от опции».
Этот блок отвечает на главный практический вопрос: «если я выключу опцию, какие функции в коде вернут другое значение и где это поведение начнёт расходиться с тем, что у клиента сейчас». Карта сразу показывает все точки, которые надо проверить руками.
Связь с конкретным объектом — теперь видно из карточки «Типы»
Группа «Функц.опции» в карточке справочника Номенклатура
Карточка Catalog.Номенклатура в ЕРПУХ, режим «Типы». Прямо в общем списке связей появилась группа «Функц.опции (38)» — все опции, которые контролируют этот справочник. Колонка справа сразу говорит, что именно: «реквизит», «3 реквиз.», «целиком». То же поведение, что у привычных групп «Подписки» / «Перехваты» — никаких отдельных вкладок.
Раньше, чтобы понять «какие функциональные опции вообще трогают этот документ или справочник», приходилось перебирать опции по одной. В этом релизе ответ виден прямо на карточке объекта в режиме «Типы».
Когда вы открываете деталь любого объекта (например, Document.РеализацияТоваровУслуг или Catalog.Контрагенты), в общем списке связей появляется группа «Функц.опции» с зелёным маркером — наряду с привычными «Вызывает», «Ссылается на», «Подписки», «Перехваты». В группе — список всех опций, в чьём составе фигурирует этот объект.
В колонке «Детали» — короткое описание того, что именно опция тут отключает: «целиком» (опция убирает объект полностью), «реквизит» или «N реквиз.» (только конкретные поля), «команда» / «N команд». При наведении на текст всплывает подсказка с поимённым списком реквизитов и команд, чтобы не открывать саму опцию ради уточнения.
Если опция собственная для расширения — рядом с её заголовком маркер 🔌. Группа сортируется и группируется по тем же правилам, что и весь список связей объекта, — никаких отдельных вкладок и переключателей не появилось, всё прямо в основной таблице.
Как обновиться
Скачать нужную сборку из prod/ и развернуть по инструкции INSTALL.txt. Полный архив analyzer-1c-full.zip — приложение и ArangoDB в одном пакете для автономной установки. Вариант analyzer-1c-no-arango.zip — только приложение, для случаев, когда ArangoDB уже стоит отдельно.
Если у вас уже загружены конфигурации, после обновления нажмите «Перезагрузить» — рёбра функциональных опций и связей с объектами достроятся в графе при следующем разборе.
Два значимых раздела для работы с незнакомой конфигурацией 1С
1.5.20 — Что нового
В новой версии аналитик получил два значимых раздела для работы с незнакомой конфигурацией 1С: «Изучение подсистем» для понимания процессов и «Внешние API» для просмотра всех точек входа. Обе возможности доступны из верхнего меню.
Изучение подсистем
Когда вы открываете незнакомую конфигурацию 1С — типовую ЕРП, ЗУП, УХ или сильно кастомную — приходится тратить дни, чтобы понять «какие здесь бизнес-процессы, с чего они начинаются, чем заканчиваются». Дерево объектов слева отвечает на «что в системе есть», но не на «как процесс идёт».
Раздел «Изучение подсистем» даёт прямой ответ на этот вопрос на языке 1С — через подсистемы. Каждая подсистема становится карточкой процесса: видны инициирующие документы(с чего процесс начинается), завершающие(чем заканчивается), и весь промежуточный путь между ними.
Список подсистем как «оглавление»
Слева — все процессы клиента, отсортированные по числу документов: сверху самые «жирные»(«Зарплата 121 документ», «Продажи 53», «Кадры 79»), внизу — мелкие. Это и есть оглавление того, как устроена работа в этой конфигурации.
Служебные подсистемы платформы — «СтандартныеПодсистемы», «ИнтернетПоддержкаПользователей», «РаспознаваниеДокументов», «ПереопределяемыеОбъекты», «СлужебныеПодсистемы» и им подобные — автоматически скрыты, чтобы не отвлекать от бизнес-картины. Тумблер «Показать служебные» возвращает их в список с серым тегом «служебная», если нужно посмотреть. Любую подсистему можно вручную скрыть через Y42;-меню «Скрыть как служебную» — пометка сохраняется между сессиями.
Карточка процесса
Клик по подсистеме открывает её карточку с двумя видами — Список и Граф.
Список процесса «Продажи» в ЕРПУХ
Список — табличное представление:
три колонки Инициирующие/ Промежуточные/ Завершающие с документами процесса(длинные списки прокручиваются внутри колонки, не отжимая остальное содержимое); ниже — две таблицы регистров: Куда пишет процесс(балансовые регистры накопления, бухгалтерия) и Откуда читает справочные(регистры сведений, обороты);
две таблицы межпроцессных связей: Связи через ссылочный реквизит (например, «Кадры → Зарплата 10») и Заполняется на основании из...
Заголовки колонок остаются на месте при прокрутке внутренних списков — таблицы регистров и связи всегда видны под колонками.
Граф процесса
Вкладка Граф показывает то же содержимое визуально: четыре вертикальные колонки слева направо — инициирующие, две колонки промежуточных по «глубине» создания на основании, и завершающие.
По умолчанию отображаются только связи «создан на основании»(сплошные жирные стрелки). Тумблер Показать справочные ссылки включает дополнительные тонкие пунктирные стрелки от ссылочных реквизитов между документами.
Сверху над основным графом — серые пунктирные плашки соседних подсистем, выложенные в строку по 6 в ряд: «Зарплата(40)», «Закупки(12)» и т.п. Стрелка от документа вверх — он передаёт данные в эту подсистему; стрелка вниз — оттуда приходит. Это заменяет «обрыв» процесса на границе подсистемы наглядной сводкой межпроцессных связей.
При клике на любой узел подсвечивается полная цепочка от инициирующего документа через промежуточные до завершающего, проходящая через выбранный. Остальные узлы приглушаются, лишние рёбра скрываются — на экране остаётся ровно тот процесс, который вас интересует. Клик мимо узла снимает подсветку.
Кнопки слева сверху — стандартные для графа: приблизить, отдалить, вписать всё в экран, сохранить как PNG.
Навигация ПКМ
Правый клик на любом элементе графа даёт целенаправленный переход:
на документе — «Перейти к документу в дереве»: открывается режим «Типы», документ найден и подсвечен в дереве слева; на плашке соседней подсистемы — «Открыть процесс этой подсистемы»: вы перепрыгиваете прямо в её карточку.
Внешние API: HTTP-сервисы, Web-сервисы, регламентные задания
Все публичные точки входа конфигурации — HTTP-сервисы, Web-сервисы(SOAP) и регламентные задания — теперь видны одним списком, с URL, методами и функциями-обработчиками.
До релиза поиск точек входа был вручную: открывается конфигуратор, пробегается по папкам HTTPServices/ , WebServices/ , ScheduledJobs/ , у каждого смотрится MethodName или Handler , потом ищется функция в коде модуля. На ERP-масштабах — сотни задач и end p oint'ов, проверка занимала день.
Теперь граф конфигурации содержит отдельные коллекции для всех трёх категорий. Любая «нестандартная» точка входа — та, что исполняется в обход UI(задание по расписанию, SOAP-запрос, HTTP-клиент снаружи) — попадает в единый индекс, откуда её легко достать фильтром или экспортом.
Регламентные задания
Новая запись в дереве объектов справа от режимов «Анализ функций» и «Граф вызовов» — регламентное задание видно как отдельный узел с метаданными:
🕐 Расписание в человекочитаемом виде(«каждый день; каждые 5 мин», «Пн,Ср,Пт; 03:00», «раз в 2 дн.»).
Обработчик — полное имя функции-процедуры общего модуля, которую платформа вызовет по расписанию.
Флаги — предопределённое/пользовательское, включено/отключено, переопределено расширением.
Клик по заданию в режиме «Анализ функций» сразу открывает handler в табе «Функции» — можно провалиться в граф вызовов, перейти к исходнику в EDT через правый клик. В режиме «Граф вызовов» задание появляется над корневой функцией как отдельный узел-шестиугольник, соединённый с handler пунктирной стрелкой «триггер задания».
Вкладка «Внешние API»
Рядом с режимом «Граф вызовов» — четвёртый чип «Внешние API».
Переключатель сверху делит сервисы на HTTP и Web(SOAP). Для каждого сервиса — раскрывающаяся карточка со списком endpoint'ов или операций:
Имя сервиса, синоним, корневой URL.
Флаги 🔓 anony mous (публичный вход без аутентификации), 🔌<имя расширения> (сервис добавлен расширением), ||; отключён ; переопределено: <имя расширения>(расширение сменило handler).
Каждый endpoint — HTTP-метод, URL-шаблон, имя функции-обработчика.
Правый клик по строке endpoint — контекстное меню:
«Открыть в графе вызовов» — корень графа становится функцией handler'а, дальше обычный impact-обход.
«Открыть функцию в EDT» — если подключён EDT-мост, файл Module.bsl соответствующего сервиса открывается в редакторе с курсором на методе.
Расширения: три сценария
HTTP/Web-сервис может быть изменён расширением тремя способами, и все три видны в карточке:
- Свой сервис расширения — сервис с уникальным именем, не существующий в типовой; в карточке — тег 🔌<имя расширения>.
- Добавлен endpoint в существующий сервис — карточка сервиса остаётся типовой, а новая строка endpoint'а получает 🔌 и имя расширения.
- Переопределён handler через&Вместо — endpoint один, но у него появляется тег c98;<имя расширения>, а старый handler сохраняется в поле original_handler (видно в деталях).
То же — для регламентных заданий: собственные задания расширения видны в списке с тегом расширения, а заимствованные со сменой MethodName — с overridden_by.
Поддержка форматов загрузки
Парсеры регламентных заданий и HTTP/Web-сервисов одинаково работают для всех 5 форматов загрузки: ZIP-выгрузка, монорепо src/cf+ src/cfe/\*, отдельные git-репозитории, EDT одиночный проект и EDT workspace. В EDT плоская структура<urlTemp lates> и<op erations> переводится в cf-форму автоматически; русские имена методов(Получить, Добавить, Изменить, Удалить) без явного <htt p Method> маппятся на стандартные HTTP-глаголы GET/POST/PUT/DELETE.
Граф вызовов от функции
Версия 1.4.17
Граф вызовов от функции
Версия 1.4.17. Новый раздел «Граф вызовов» отвечает на вопрос, который раньше приходилось трассировать руками: что вообще выполнится, если я позову эту функцию?
Анализатор разворачивает forward-reachability не только по прямым вызовам, но и по подпискам на события, стандартным обработчикам модулей объекта и перехватам расширений — с явной пометкой мест, где статический анализ упирается в динамический вызов.
Граф вызовов от Претензии.ПередЗаписью демонстрирует прямые вызовы, подписку ПриУстановкеНовогоКода с обработчиком «УстановитьПрефиксИнформационнойБазы», перехват &Вместо функции «МенеджерОбъектаПоСсылке» расширением «УправлениеЛизингом» и два «тёмных» перехода через Выполнить().
Зачем это
Разработчик в типовой смотрит на процедуру и задаёт один и тот же вопрос: «что выполнится по цепочке, если её позвать?».
Прямой ответ есть только для явных вызовов — а в реальности цепочка уходит через подписки на события (OnWrite, Posting, Filling…), стандартные процедуры модуля объекта (ПередЗаписью, ОбработкаПроведения…) и перехваты расширений.
На типовой ERP с сотнями подписок и десятками расширений это часы на один анализ.
«Граф вызовов» делает BFS по всем четырём типам рёбер за один заход и показывает результат в виде кликабельного canvas на Cytoscape с dagre-раскладкой.
Что показывает граф
Один узел = одна функция или подписка. Цвет узла — тип объекта: Документ, Справочник, Общий модуль, Регистр сведений…
Рамка узла сигналит о его роли:
- Золотая — корневая функция, с которой построили обход.
- Фиолетовая — функция-перехватчик из расширения.
- Красная штриховка — функция вызывает Выполнить(...) или аналог, дальше цепочка уходит «в темноту».
- Красный пунктир — функция может не выполниться вовсе: есть &Вместо-перехват без ПродолжитьВызов().
Стрелки тоже разные — вид стрелки показывает характер перехода, а не тонет в ещё одной палитре:
Обозначения связей в графе вызововКак это работает
На каждую функцию анализатор при загрузке запоминает, над какими объектами 1С она выполняет операции, способные триггерить события: .Записать(), .Провести(), .Удалить(), .Заполнить(), движения регистров и ещё около десятка методов.
Отдельно помечаются функции с динамическими вызовами: Выполнить, ВычислитьВыражение, ВызватьМетодОбъекта.
По этим данным строятся три новые edge-коллекции: функция → подписка, функция → стандартный обработчик и функция-перехватчик → перехваченная функция типовой.
Последнее — на уровне функций, а не модулей: для каждой &Перед / &После / &Вместо в расширении анализатор находит конкретное тело, запоминает его как обычную функцию и связывает с оригиналом.
Это значит, что перехватчик — полноценный узел графа: BFS разворачивает его дальше и показывает, что на самом деле делает расширение.
Обход — BFS с ограничениями по глубине: по умолчанию 5, максимум 8, и числу узлов: 500, hard cap 2000. Дальше глубины или лимита граф обрезается, об этом явно говорится в правой панели.
Как пользоваться
Попасть в «Граф вызовов» можно двумя путями:
- из «Анализа функций» правым кликом по строке функции → пункт «Исследовать вызовы». Корнем сразу станет выбранная функция;
- через кнопку «Граф вызовов» в шапке сайдбара — открывается пустое состояние, функцию можно найти через поиск в заголовке или через хлебные крошки: Тип → Объект → Модуль → Функция. Каждый сегмент кликабельный и подтягивает следующий уровень каскадом.
В правой панели — управление обходом и статистика:
- слайдер «Глубина» от 1 до 8 — меняется налету, граф перерисовывается;
- чекбоксы «Учитывать подписки» и «Раскрывать динамические вызовы» — можно выключить, чтобы получить более «строгий» подграф без транзитивных раскрытий;
- счётчики: сколько функций, подписок и «тёмных» переходов в графе, а также флаг truncated, если попали в лимит.
Клик по любому узлу подсвечивает все пути от корня до него — помогает понять, «как сюда вообще попадают».
Честные ограничения
Это forward reachability, а не точный call stack. Инструмент отвечает на вопрос «что МОЖЕТ выполниться», а не «что ВЫПОЛНИТСЯ при таких-то параметрах»: условия в коде не интерпретируются — это осознанный компромисс статического анализа.
Динамические вызовы не раскрываются. Выполнить, обращение по имени-строке, обработчики СКД и событий форм — помечаются «тёмным переходом» без детей. Альтернатива — комбинаторный взрыв и ложная уверенность.
&Вместо без ПродолжитьВызов() блокирует оригинал. Такая функция помечается красным пунктиром: её потомков в графе видно, но рядом стоит оговорка «может не выполниться».
Объект операции определяется эвристиками. Для ЭтотОбъект.Записать() внутри модуля объекта или для Документы.Х.СоздатьДокумент().Записать() — ок. Но если объект пришёл в локальную переменную сложным путём, ребро к подписке может не построиться. Таких около 5–15% по оценке на ERP.
Транзитивность через подписки быстро растёт: запись регистра может триггернуть несколько подписок, каждая из них пишет ещё что-то. Отсюда дефолтные лимиты глубины и числа узлов — крутить их вверх имеет смысл прицельно, не по умолчанию.
Нужна перезагрузка конфигурации
Новые поля triggers и has_dynamic_call на функциях, edge-коллекции triggers_subscription, triggers_default_handler, intercepts_function и полноценная загрузка функций-перехватчиков из расширений появляются только при новой загрузке системы.
Для каждой конфигурации, которая должна использовать граф, нажмите «Перезагрузить» в интерфейсе.
До перезагрузки граф может показывать неполные данные — это ожидаемое поведение, не баг.
Анализ зависимостей объекта
При выборе объекта в дереве открывается панель деталей. Она показывает все связи объекта, сгруппированные по типам метаданных:
- Общие модули — какие модули вызываются из кода объекта
- Справочники, Документы, Регистры — ссылки на реквизиты и обращения из кода
- Перечисления, ПВХ — используемые значения
- Роли — кто имеет права на этот объект
- Расширения — какие расширения затрагивают объект
Заголовок показывает общее количество связей и путь: Документы › Реализация товаров и услуг 287/287. Фильтры «Тип», «Направление», «Права» позволяют сузить выборку.
Документ «Реализация товаров и услуг» — 287 связей: 156 общих модулей, 44 справочника, 29 документов, 27 регистров накопленияТаблица зависимостей
Каждая группа раскрывается в таблицу с колонками: имя объекта, тип метаданных, направление связи (ссылается на / используется в). Для документа «Реализация товаров и услуг» видно, с какими документами он связан — заказы клиентов, возвраты, резервирования. Клик левой кнопкой по строке таблицы показывает символьное имя объекта (программный идентификатор), правой кнопкой — переход к зависимостям выбранного объекта.
Связанные документы: заказы, возвраты, акты, резервированияАнализ запросов к таблицам
Помимо вызовов модулей и ссылок реквизитов, Analyzer 1C анализирует обращения к таблицам через запросы. Инструмент находит конструкции ИЗ и СОЕДИНЕНИЕ с указанием типа метаданных и имени объекта в трёх источниках:
- BSL-код — строковые литералы с текстом запросов в модулях объектов
- Динамические списки форм — запросы в свойствах
QueryTextи ссылки вMainTable - Макеты СКД — запросы в наборах данных схем компоновки
Для каждого найденного обращения создаётся связь «Запрос к» / «Запрос из», включая обращения к табличным частям (Справочник.Номенклатура.Штрихкоды) и виртуальным таблицам регистров (РегистрНакопления.ОстаткиТоваров.Остатки, РегистрСведений.Курсы.СрезПоследних).
Регистр сведений «Относительные курсы валют» в ERP УХ — 159 связей: 48 общих модулей и 31 документ обращаются к регистру через запросы (СрезПоследних), направление «Запрос из» показывает, кто читает данныеНагрузочный анализ: выбрав регистр сведений или накопления, можно сразу увидеть, сколько объектов читают из него данные через запросы, а сколько — пишут (через ссылки реквизитов и вызовы). Например, в регистр сведений «Курсы валют» пишет 1 документ, а читают через запросы 20 модулей — это помогает оценить нагрузку и зону влияния при изменении структуры регистра.
Дополнительные возможности Analyzer 1C
Анализ ролей
Режим «Роли» в левой панели показывает все роли конфигурации с количеством объектов в каждой. При выборе роли — видно, на какие объекты она даёт права.
При выборе объекта в панели деталей отображаются все роли, которые на него ссылаются, с детализацией прав (чтение, добавление, изменение, удаление, RLS и т.д.). Фильтр «Права» позволяет отобрать связи по конкретным видам прав — например, показать только роли, дающие право удаления. Кнопка «Права: 7 из 16» означает, что выбрано 7 видов прав из 16 доступных для фильтрации.
Помимо прав, назначенных через конфигуратор, Analyzer 1C находит программные проверки ролей в коде — вызовы РольДоступна() и Пользователи.РолиДоступны(). Это позволяет увидеть полную картину: не только где роль даёт права на объекты, но и в каких модулях от неё зависит логика выполнения кода.
Роль «Администратор системы» в ERP УХ — 298 объектов, справочники с детализацией правАнализ подписок на событие
Подписки на события (EventSubscription) — один из самых «невидимых» источников поведения 1С. При записи документа, константы или набора записей регистра срабатывают процедуры из общих модулей, перечисленные в поле Handler подписок. Найти эти цепочки вручную очень сложно: в конфигураторе нужно открыть каждую подписку по отдельности и понять, какие объекты она затрагивает.
Analyzer 1C парсит раздел EventSubscriptions основной конфигурации и расширений, извлекает событие (ПередЗаписью, ПриЗаписи, ОбработкаПроведения и так далее), список источников и обработчик, и строит двунаправленные связи в графе: от объектов-источников к подписке и от подписки к общему модулю-обработчику.
Подписки отображаются в дереве типов в папке «Общие» — так же, как в конфигураторе 1С. Если подписка добавлена расширением, в дереве и в результатах поиска она помечается меткой «Доб. <Расширение>». Если расширение заимствовало базовую подписку, на ней показывается «Заимств. <Расширение>».
Подписка «Отмена проведения цепочки документов» добавлена расширением «УправлениеЛизингом» к трём документам 1С:ERP. Управление холдингом. Обработчик — общий модуль «ЛизДопОбработчикиВызовСервера»В карточке подписки сверху выводится заголовок с русским названием события (например, [Перед записью]) и меткой расширения, ниже — две группы: объекты-источники (направление «Подписан») и общий модуль-обработчик (направление «Вызывает»). Порядок строк отражает каноническую хронологию событий 1С: сначала обработка заполнения и проверка, затем «Перед записью» → «При записи» → «Обработка проведения», в конце — «Перед удалением».
Как применять на практике. При изменении общего модуля, который является обработчиком подписок, impact analysis автоматически проходит через цепочку subscribes → handled_by → calls и показывает все объекты, запись которых будет затронута. При диагностике медленной записи документа достаточно открыть его карточку и посмотреть блок «Подписки» — все подписки, срабатывающие при записи, видны как отдельные строки с отметкой хронологии события. Если на одном документе висит пять подписок «Перед записью», каждое сохранение последовательно вызывает пять процедур в общих модулях — вот и источник «тормозов».
Анализ качества кода: монстр-функции и метрики
Длинные процедуры — главная причина «страшно менять». Процедура на 2 000 строк с 80 ветвлениями и запросами в цикле обнаруживается случайно, когда уже поздно. Analyzer 1C считает метрики по каждой функции и выделяет проблемные прямо в интерфейсе.
Режим «Анализ функций» — отдельное дерево по типам объектов, где проблемные модули подсвечены сразу при открытии:
- 🔴 Монстр-функция — хотя бы одна из четырёх причин: более 500 строк кода, более 50 ветвлений (
Если/Пока/Для/Попытка), запросы к БД внутри цикла (N+1), более 10 вызовов.Выполнить()в одной функции. - 🟡 Предупреждение — функция приближается к опасным значениям: 200–500 строк, 20–50 ветвлений, 5–10 запросов.
В таблице функций модуля — цветная колонка «Строк» и «Ветв.», колонка «Запросов» с отметкой «N (M в цикле) при N+1». Строки текста запросов (начинающиеся с |) исключены из подсчёта: весь текст запроса считается за одну логическую строку и не влияет на оценку сложности.
Функции расширений в общем контексте. Если расширение добавляет новую функцию в заимствованный модуль или переопределяет существующую через &Вместо, &Перед, &После — они тоже появляются в списке с меткой 🔌 РасширениеХ. Для функций-перехватов считаются эффективные метрики: строки и ветвления самого перехватчика плюс оригинальной функции. Это даёт честную картину реальной нагрузки при поддержке этой связки.
Фильтры в таблице функций: «Все», «Предупреждения и выше», «Монстры», «Только расширения». При клике на функцию — правая панель с подробным объяснением: почему именно она попала в монстры и какие числа за этим стоят.
Заимствованный модуль «Ввод остатков внеоборотных активов» (расширение УправлениеЛизингом) — 8 функций, первая: 1344 строки, 50 ветвлений, 275 вызовов. Правая панель объясняет, почему функция попала в монстрыКонструктор профилей
Одна из ключевых задач при настройке прав — понять, какие итоговые доступы получит пользователь с определённым набором ролей. В конфигураторе 1С для этого нужно открыть каждую роль по отдельности и вручную сопоставить права. Если роли добавлены расширениями — задача усложняется многократно.
Конструктор профилей в Analyzer 1C решает это: вы отмечаете нужные роли чекбоксами (включая роли из расширений, помеченные «Доб.»), нажимаете «Показать итоговые разрешения» — и получаете объединённую картину: на какие объекты профиль даёт доступ, с какими правами, и из какой роли каждое право пришло.
Профиль из 2 ролей (398 объектов) — итоговые разрешения на справочники с детализацией правРезультат показывает все объекты, к которым профиль даёт доступ, сгруппированные по типам: конфигурация, подсистемы, общие модули, справочники, документы, регистры. Фильтр «Права» позволяет отобрать только объекты с определёнными правами (чтение, изменение, удаление и т.д.). Помимо объектных прав, в итоговую картину включаются программные проверки ролей — вызовы РольДоступна() и Пользователи.РолиДоступны() в коде, которые могут влиять на поведение системы для пользователя с данным профилем.
Зачем это нужно: при аудите прав, при проектировании новой роли, при подключении расширения — сразу видно итоговую картину доступов. Не нужно вручную складывать права из нескольких ролей и расширений. А учёт программных проверок РольДоступна() показывает, где логика кода зависит от наличия роли — то, что невозможно увидеть в стандартном интерфейсе настройки прав.
Визуализация графа
Переключатель «Таблица / Граф» в правой панели позволяет визуализировать зависимости выбранного объекта в виде интерактивного графа. Узлы графа — связанные объекты, рёбра — типы связей (вызовы, ссылки, заимствования). Граф интерактивный: правый клик по узлу — переход к зависимостям этого объекта (навигация вглубь графа).
Граф зависимостей документа «Реализация товаров и услуг»Статистика конфигурации
Вкладка «Инфо» показывает общую статистику загруженной конфигурации:
1С:ERP. Управление холдингом: 907 подсистем, 18 780 модулей, 341 925 функций, 110 489 вызововЗагрузка конфигураций и расширений
После запуска Analyzer 1C нужно загрузить выгрузку конфигурации. Нажмите кнопку обновления (?) рядом с выбором системы — откроется меню со списком загруженных конфигураций и пунктом «Загрузить новую...».
Меню управления конфигурациями — загруженные системы, расширения и кнопка загрузки новойВ диалоге загрузки укажите имя папки (произвольное) и выберите ZIP-файл с выгрузкой конфигурации. Выгрузка создаётся в конфигураторе: Конфигурация ? Выгрузить конфигурацию в файлы (формат ZIP).
Загрузка ZIP-архива конфигурации — имя папки и выбор файлаРасширения загружаются аналогично: в конфигураторе откройте расширение, выгрузите его в файлы (ZIP), затем в Analyzer 1C загрузите в ту же папку, что и основная конфигурация. Инструмент автоматически определит расширение и привяжет его объекты к основной конфигурации — заимствования, переопределения и добавленные объекты будут отображаться с соответствующими метками.
Можно загрузить несколько конфигураций одновременно и переключаться между ними через выпадающий список в шапке.
Загрузка из Git
Если конфигурация хранится в git-репозитории, её можно загрузить напрямую. Переключите режим на «Git-репозиторий», укажите URL и при необходимости ветку (например, release или develop). Для приватных репозиториев укажите токен доступа либо в диалоге, либо в переменной окружения ANALYZER_GIT_TOKEN в файле .env — токен автоматически подставится при клонировании и последующих git pull.
Диалог клонирования git-репозитория — имя папки, URL, ветка и токен доступа
Что нового в версии 1.3.52
Что нового
Свод ключевых фич на версию 1.3.52. Три возможности, которые меняют повседневную работу с анализатором: поиск неиспользуемых экспортов, предупреждения о рантайм-багах между клиентом и сервером, и прямая работа с EDT-проектами из git без ручной выгрузки в XML.
Мёртвые экспорты
Поиск экспортных процедур и функций в общих модулях, которых никто не вызывает по графу. Типичный кандидат на удаление, унаследованная «лишняя API-поверхность», мешающая рефакторингу и обновлению типовой.
Скриншот: мёртвые экспорты в модуле ВидыПриложенийСервер (1С:ERP. Управление холдингом)Модули с мёртвыми экспортами в сайдбаре помечены жёлтым. В таблице функций буква «Э» у мёртвого экспорта оранжевая и жирная. В правой панели — отдельная секция «Мёртвый экспорт» с подсказкой, можно ли удалять безопасно или функция перехватывается расширением.
Фича учитывает вызовы из расширений: экспорт типовой, который зовёт расширение, мёртвым не считается. Экспорты в объектных модулях и модулях форм не помечаются намеренно — платформа часто обращается к ним динамически по имени-строке.
Инструмент — подсказка: перед удалением проверить вручную, не зовут ли функцию через Выполнить(), СКД или события форм.
Нарушения контекста (Сервер ↔A038; Клиент)
В управляемых формах каждая процедура исполняется в своём контексте: клиент, сервер или сервер без контекста формы. Вызов сервер → клиент — рантайм-баг: платформа кинет исключение, но обычно это ловится только при тестировании. Анализатор строит полный граф вызовов и находит такие пары заранее.
В сайдбаре модули с нарушением подсвечены красным — они попадают в фильтр «Монстры». В таблице появилась колонка «Ктх» с бейджем контекста (К — клиент, С — сервер, С* — сервер без контекста); красный маркер у функции означает исходящий вызов с конфликтом. В правой панели нарушившей функции — секция «Нарушения контекста» со списком конкретных переходов и указанием вызываемого метода.
Критерии:
- Critical (красный) — сервер или сервер без контекста вызывает клиент. Гарантированный рантайм-баг.
- Warning (жёлтый) — сервер без контекста вызывает сервер (источнику не хватает контекста формы).
Контекст берётся из аннотаций (&НаКлиенте, &НаСервере, &НаСервереБезКонтекста и их английских аналогов) и из свойств CommonModule (<Server>, <ClientManagedApplication> и т.д.) — если у функции нет явной аннотации, она наследует контекст от модуля.
Поддержка EDT-формата
Анализатор научился работать с конфигурациями напрямую в EDT-формате (1С:Enterprise Development Tools) — с файлами .mdo и .rights, без промежуточной выгрузки в XML из Конфигуратора. Это снимает лишний ручной шаг: выгрузили из git — сразу запустили загрузку.
Формат определяется автоматически, пользовательских действий не требуется. Доступно всё то же, что и для XML-выгрузки:
- основная конфигурация — подсистемы, объекты, BSL-модули, ссылки реквизитов, запросы форм и СКД;
- расширения — как соседние EDT-проекты; различаются заимствованные и новые объекты;
- роли — объектные права и RLS (из .rights), плюс права уровня конфигурации;
- подписки на события — источник, имя события, обработчик в формате CommonModule.Модуль.Метод.
Автоматическое размещение при клонировании
Основная конфигурация и каждое расширение в EDT живут в отдельных git-репозиториях. Раньше при клонировании надо было руками указывать подпапку (main, ext1…), и если ошибся — анализатор видел их как разные системы.
Теперь достаточно указать имя системы, остальное анализатор делает сам:
- основная → conf/<система>/main/
- расширение → conf/<система>/<ИмяРасширения>/ (имя берётся из самого расширения)
При повторном клонировании того же URL делается git pull в существующей папке — без дубликатов.
Фикс счётчика прав в дереве ролей
В левом сайдбаре у каждой роли теперь корректно показывается количество объектов, на которые у роли есть права. Раньше цифра всегда была нулевой из-за расхождения имён поля между бэкендом и фронтендом — особенно заметно было на конфигурациях с большим числом ролей (у ERP, например, 2000+ ролей и 44 тысячи прав). Права уровня конфигурации в счётчике не учитываются: они не привязаны к объектам и выведены в правой панели роли отдельной секцией.
Нужна перезагрузка конфигурации
Эти фичи опираются на данные, которые появляются только при новой загрузке системы. Для каждой конфигурации, которая должна использовать хотя бы одну из них, нужно нажать «Перезагрузить» в интерфейсе. До перезагрузки интерфейс может показывать неполные данные — это ожидаемое поведение, не баг.
Варианты организации репозитория
Поддерживаются три варианта организации репозитория — инструмент автоматически определяет тип конфигурации и формат выгрузки.
Монорепо
Основная конфигурация — в src/cf/, расширения — вsrc/cfe/{имя_расширения}/.- Один репозиторий — один клон, всё определяется автоматически.
Отдельные репозитории
- Основная конфигурация и каждое расширение в отдельном репозитории.
- Клонируются в подпапки одной папки (
main/,ext1/,ext2/).
Одиночный репозиторий
- Репозиторий содержит только одну конфигурацию (основную или расширение).
- Формат выгрузки (git-sync или 1C:EDT) определяется автоматически.
Инструмент автоматически определяет, что является основной конфигурацией, а что расширением — по наличию ConfigurationExtensionPurpose в Configuration.xml. При повторной загрузке выполняется git pull: для монорепо — один раз, для отдельных репозиториев — в каждой подпапке.
Развёртывание
Analyzer 1C поставляется как готовый Docker-образ (~310 МБ). Для развёртывания нужен только Docker — ни Python, ни Node.js, ни ArangoDB устанавливать отдельно не требуется. Всё упаковано в образ.
Windows 10/11:
- Скачайте Docker Desktop
- Запустите установщик, перезагрузите компьютер
- Убедитесь, что Docker запущен (иконка в трее)
Ubuntu / Debian:
sudo apt update sudo apt install -y docker.io docker-compose-plugin sudo systemctl enable --now docker sudo usermod -aG docker $USER # Перелогиньтесь, чтобы применить группу
CentOS / RHEL / Astra Linux:
sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo sudo yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin sudo systemctl enable --now docker sudo usermod -aG docker $USER
Скопируйте на сервер пять файлов (распакуйте архив):
- analyzer-1c-offline.tar — Docker-образ
- docker-compose.prod.yaml — конфигурация запуска
- deploy.sh (Linux) или deploy.bat (Windows) — скрипт деплоя
- start.sh (Linux) или start.bat (Windows) — скрипт для повторного запуска
- stop.sh (Linux) или stop.bat (Windows) — скрипт остановки
Linux:
bash deploy.sh
Скрипт использует sudo для команд Docker. Если ваш пользователь уже входит в группу docker и имеет права на запуск контейнеров без sudo — удалите sudo из команд в deploy.sh и stop.sh.
Windows (cmd или PowerShell):
deploy.bat
Скрипт загрузит образ, запустит контейнер и удалит архив. После запуска приложение доступно по адресу http://localhost:8000.
Для остановки:
Linux: bash stop.sh
Windows: stop.bat
Повторный запуск после остановки:
Linux: bash start.sh
Windows: start.bat
Откройте веб-интерфейс, в выпадающем списке систем выберите «Загрузить новую...» и укажите папку для загрузки и ZIP-выгрузку конфигурации или адрес git-репозитория и ветку, из которой надо грузить. Расширения должны загружаться в ту же папку, что и основная конфигурация, с другим именем архива. Разбор и загрузка ERP УХ (18 780 модулей) занимает около 5–10 минут. Можно загрузить несколько конфигураций и переключаться между ними.
Технические требования
Работоспособность гарантируется:
-
Программа не задействует Платформу 1С.
-
Тестировалась выгрузка на 8.3.27.1719,
-
Но будет одинаково работать с любой платформой 1С, где реализована выгрузка данных конфигурации в файлы.
На слайдах 1С:ERP. Управление холдингом (3.2.8.11)
Код открыт.
Версия 1.4.17 - новый раздел «Граф вызовов»: показывает, что реально выполнится при вызове функции — прямые вызовы, подписки на события, стандартные обработчики (ПередЗаписью, ОбработкаПроведения и т.п.) и перехваты расширений (&Перед/&После/&Вместо на уровне функций, а не модулей), с явной пометкой мест, где цепочка уходит в динамический вызов Выполнить().
Версия 1.5.20 - появился раздел «Изучение подсистем» — режим знакомства с незнакомой конфигурацией 1С через её собственный язык: подсистемы. Слева — список всех подсистем, отсортированный по числу документов (служебные платформенные скрыты по умолчанию); клик по любой открывает карточку процесса с двумя видами — Список (инициирующие документы → промежуточные → завершающие, со ссылками друг на друга через регистры и проводки) и Граф (тот же путь визуально). Это даёт прямой ответ на вопрос «как здесь устроена работа», не заставляя вручную обходить дерево объектов: за минуты видно, с чего процесс начинается, чем заканчивается, и какие документы участвуют посередине. Любую подсистему можно вручную пометить как служебную через Y42;-меню — пометка сохраняется между сессиями.
Также в релизе появился раздел «Внешние API», который показывает все точки входа в конфигурацию в одном месте: HTTP-сервисы с их URL-шаблонами и обработчиками методов (GET/POST/PUT/DELETE), Web-сервисы (SOAP) с операциями и привязкой к BSL-функциям, регламентные задания с расписанием, расширением и handler-методом, а также подписки на события и планы обмена. Для каждой записи виден контекст исполнения (сервер/клиент/внешнее соединение) и быстрая ссылка на сам обработчик в коде. Это особенно полезно при аудите безопасности и интеграций: за одну страницу видно весь периметр взаимодействия системы с внешним миром, без необходимости вручную обходить ветки HTTPServices/, WebServices/, ScheduledJobs/ и прочие в дереве метаданных.
Версия 1.6.21 - функциональные опции — карта влияния
Анализатор научился разбирать функциональные опции конфигурации — и базовые, и те, что дополняются расширениями (такие отмечаются отдельно). Для каждой опции теперь видно две вещи: какие объекты и реквизиты она скрывает в интерфейсе, и какие функции в коде её проверяют и меняют поведение в зависимости от её значения. Дополнительно строится цепочка влияния по вызовам — до четырёх уровней вглубь, — чтобы было понятно, какие ещё функции и модули в итоге зависят от опции, пусть и не напрямую. Это помогает заранее оценить, что именно изменится у пользователя при включении или отключении опции и какие участки кода стоит проверить.
Версия 1.6.62 - В графе появились два новых вида объектов 1С, которые раньше анализатор не показывал: определяемые типы и планы видов характеристик (ПВХ). Теперь видно, какие конкретные справочники и документы скрываются за определяемым типом, какие предопределённые виды есть у ПВХ, в каком справочнике или регистре хранятся их значения и в каких реквизитах всё это используется. После обновления у уже загруженных систем нужно один раз нажать «Перезагрузить», чтобы новые ветки графа наполнились.
Остались вопросы?
Для получения дополнительной информации и помощи в настройке модуля под нужды вашего бизнеса — оставьте заявку
