Analyzer 1C — единый граф типовой и расширений плюс инструмент обновления поставки
В крупных внедрениях типовая конфигурация 1С почти всегда дополнена одним или несколькими расширениями. Конфигуратор показывает их раздельно — аналитик вручную сопоставляет, «что фактически работает». Analyzer 1C объединяет типовую и все расширения в единый граф знаний: объекты, модули, функции, права, RLS-условия, подписки, регламенты, обработчики обновления, состав определяемых типов, запросы BSL — всё это видно сразу и снабжено пометкой о происхождении.
В линейке 2.0 анализатор стал ещё и инструментом обновления поставки: сравнивает и объединяет версии конфигурации деревом «как в Конфигураторе», загружает бинарные файлы поставки .cf/.cfe напрямую и находит скрытые конфликты обновления. На примере 1С:ERP. Управление холдингом (28 342 модуля, 699 793 функции, 2 032 роли) инструмент помогает архитектору, аналитику безопасности и разработчику ориентироваться в крупной конфигурации и получать ответы на «межсущностные» вопросы за один клик.
- Сравнение и объединение версий деревом «как в Конфигураторе» с выгрузкой готового плана решений
- Скрытые конфликты обновления: типовую функцию подменяет перехват расширения, висячие ссылки на удаляемые функции
- Сквозные пометки «Доб.» / «Заимств.» / переопределения — виден вклад каждого расширения
- Анализ влияния, запросы BSL, роли и RLS, граф вызовов, циклические зависимости модулей
- 6 форматов загрузки: ZIP-выгрузка, монорепо, отдельные репозитории, EDT-проект, EDT workspace и бинарные
.cf/.cfe
Две версии в одной поставке: Community и полная
Анализатор поставляется в двух вариантах. Community — бесплатная версия: полноценный граф одной конфигурации с расширениями, все срезы анализа (дерево типов, карточки объектов и ролей, RLS, параметры сеанса, функциональные опции, граф вызовов, циклы, запросы BSL). Полная версия снимает ограничение на число систем и добавляет инструмент обновления поставки и подключение ИИ-агентов.
Под ограничение в Community попадают именно эти возможности — всё остальное в бесплатной версии доступно без урезаний. Перейти на полную версию можно в любой момент, не переустанавливая продукт.
Что умеет инструмент
Обновление поставки — главное в линейке 2.0
Анализатор перестал быть только «смотрелкой» графа и стал инструментом обновления. Теперь он сравнивает и объединяет версии конфигурации так же, как штатное «Сравнение и объединение конфигураций» в Конфигураторе, загружает поставку напрямую из бинарных файлов и предупреждает о скрытых конфликтах, которые иначе всплыли бы уже после обновления.
Сравнение версий деревом «как в Конфигураторе»
Раньше сравнение версий показывало плоские списки изменённых объектов и функций. Теперь это дерево по образцу штатного «Сравнения и объединения конфигураций» 1С:
- Тип метаданных — Справочники, Документы, Общие модули, Роли, Регламентные задания и т.д. Общий функционал собран в папку «Общие» вверху, как в дереве типов.
- Конкретный объект — подписан синонимом, с цветным маркером статуса слева: добавлен, удалён или изменён.
- Что изменилось внутри — изменённые функции, реквизиты, формы и макеты. Функция всегда показана внутри своего объекта-владельца, а не отдельным плоским списком.
Дерево занимает треть ширины, окно просмотра изменений — остальное. Сразу видна привычная по Конфигуратору картина «что обновилось» без ручного перебора. Фильтры по категориям (конфликт, обновится само, моё сохранится, новое у вендора, удалено вендором) оставляют в дереве только нужное.
Окно кода: две и три колонки, подсветка BSL
Клик по изменённой функции открывает окно с её телом. В обычном сравнении двух версий — две колонки «моё ↔ эталон», при обновлении поставки — три колонки: Основная, Поставщик и База (трёхсторонняя сверка). Отдельной секцией показаны переопределения функции из расширений.
Код читается как в Конфигураторе: строки не переносятся (горизонтальная прокрутка, как в редакторе модуля), отличия подсвечены построчно, работает подсветка синтаксиса BSL — ключевые слова, комментарии, строки, директивы, числа и даты раскрашены привычными цветами. Внизу — редактируемая панель «Результат объединения», куда складывается итоговый вариант функции.
Рекомендации, решения и выгрузка настроек
Сравнение доведено до полноценного инструмента обновления поставки:
- для каждого изменения анализатор предлагает решение в одном из четырёх режимов Конфигуратора (взять своё, взять из поставки и т.д.), и решение можно переопределить вручную прямо в строке дерева;
- работа над объединением сохраняется на сервере — большое обновление можно вести не один день. При повторном открытии формы анализатор сам возвращает последний выбор версий и продолжает сверку с того же места, с расставленными решениями и правками кода;
- готовый набор решений выгружается файлом настроек для штатного Конфигуратора: один файл на основную конфигурацию плюс по файлу на каждое расширение. Конфигуратор подхватывает его в своём «Сравнении и объединении» и применяет решения автоматически.
Рутинную часть обновления — пройтись по сотням изменений и для каждого выбрать сторону — можно сделать в удобном дереве анализатора, а в Конфигуратор отдать уже готовый план.
Важно. Выгрузка настроек объединения пока в разработке. Используйте её только с обязательной проверкой: перед применением сверяйте предложенные решения и итоговый код в Конфигураторе. Ответственность за корректность объединения и сохранность конфигурации полностью лежит на пользователе.
Скрытый конфликт обновления из-за перехвата расширением
В дереве сравнения такое изменение помечается как конфликт: в подсказке указано, в каком расширении лежит перехват, который нужно пересмотреть перед обновлением.
Опаснее всего при обновлении «тихие» конфликты. Вендор поменял типовую функцию, а в вашей конфигурации эту же функцию подменяет перехват расширения (&Вместо или &ИзменениеИКонтроль). Обновление вендора тогда не вступит в силу, пока не обновлён сам перехват, — но в обычном сравнении это выглядело бы как спокойное «обновится само».
Анализатор распознаёт такой случай и помечает изменение как конфликт, прямо подсказывая, в каком расширении лежит перехват. Исключения учтены: если перехват &Вместо вызывает ПродолжитьВызов() (исполняет и новую логику оригинала) или это доопределение &Перед / &После — подмены нет, и обновление считается обычным, без ложной тревоги.
Проверка висячих ссылок при удалении функции
Если в новой поставке функция удаляется, а в текущей конфигурации на неё ещё ссылаются, после объединения вызовы повисли бы в пустоту. Окно кода теперь это проверяет и показывает предупреждение со списком вызывающих функций (с пометкой, если вызов идёт из расширения).
Анализатор отличает действительно опасные ссылки от безопасных: вызывающие, которые в новой поставке остаются, подсвечены красным — это и есть будущие битые ссылки; те, кого вендор удаляет заодно, показаны приглушённо и зачёркнуто. Если остающихся нет, предупреждение зелёное: можно объединять спокойно.
Загрузка из бинарных .cf / .cfe и циклы зависимостей
Ещё две крупные возможности 2.0: загрузка поставки прямо из бинарного контейнера 1С — без предварительной выгрузки в файлы — и поиск циклических зависимостей между модулями.
Бинарные .cf и .cfe — шестой способ загрузки
Достаточно отдать анализатору сам файл поставки — .cf для конфигураций и .cfe для расширений. Это покрывает и конфигурации-гиганты нового формата (поставки ERP больше гигабайта): такие контейнеры обрабатываются потоково, чтобы не упереться в память. Из бинаря извлекаются объекты метаданных и их состав, общие формы, подписки на события и регламентные задания. Вендорскую поставку теперь можно загрузить как версию и сразу сравнить с текущим состоянием системы.
Циклические зависимости между модулями
Новый раздел анализа — поиск циклов во взаимных вызовах модулей. Циклическая зависимость (модуль А зовёт Б, Б зовёт В, В снова зовёт А) усложняет сопровождение и мешает выносить код. Анализатор находит такие кольца и показывает их графом. Главное — раздел отвечает на вопрос «где и что рвать»: для каждого кольца видно самое слабое звено, разрыв которого проще всего разомкнёт цикл.
Навигация по конфигурации
Интерфейс разделён на две части: слева — дерево навигации и кнопки специализированных экранов (Парам.сеанса, Опред.типы, Крит.отбора, XDTO-пакеты, Обновление ИБ, Функц.опции, Планы ВХ, Конструктор профилей, Анализ функций, Граф вызовов, Изучение подсистем, Внешние API), справа — карточка выбранной сущности. Базовое переключение режима — через вкладки «Подсист.», «Типы», «Роли», «Инфо».
Интерфейс разделён на две части: слева — дерево навигации с переключателем режима, справа — карточка выбранной сущности. Шапка справа показывает иконку и тип объекта, его синоним и маркер расширения (если есть). В дереве слева — имена объектов всегда отображаются синонимами, символьное имя при необходимости мелким серым в скобках; счётчики на каждом узле показывают число сущностей внутри в реальном времени.
Дерево типов
Режим «Типы» группирует все объекты конфигурации по типам метаданных: общие модули, справочники, документы, регистры, отчёты, обработки и т.д. Каждая группа показывает количество объектов; заголовки групп «прилипают» к верху при прокрутке. Объекты типовой и расширений видны в одном списке: маркер Доб. — объект целиком из расширения, Заимств. — типовой, дополненный расширением.
Дерево типов 1С:ERP. Управление холдингом — 28 342 модуля в 20 типах метаданных
Дерево подсистем
Режим «Подсист.» отражает иерархию подсистем конфигурации. Для каждой подсистемы — вложенные подсистемы и типы объектов с количеством. Маркер на объекте — добавлен расширением, — типовой объект, который расширение привязало к своей подсистеме. Это позволяет увидеть, какие расширения затронули каждую подсистему.
Подсистемы ERP УХ с объектами расширения «Управление Лизинговой компании»
Поиск
Мгновенный поиск по всем сущностям одновременно: модули, справочники, документы, роли, подсистемы, параметры сеанса, функциональные опции, XDTO-типы. Поиск идёт по синониму, а не только по символьному имени (Ctrl+Shift+N в Конфигураторе ищет только по имени). Результаты группируются по типам и появляются по мере ввода. Объекты, добавленные или дополненные расширениями, помечены / с именем расширения — сразу видно, что пришло из расширения, а что из основной конфигурации.
Поиск «лизинг» — обычные объекты, заимствованные и устаревшие в одном списке
Возможности анализа: запросы BSL, безопасность и cross-cutting объекты
За последний год Анализатор закрыл весь приоритетный трек cross-cutting объектов 1С — команды объектов и общие команды, параметры сеанса с RLS, обработчики обновления информационной базы, критерии отбора, XDTO-пакеты с визуальным графом связей, определяемые типы и планы видов характеристик. На вершине этого — анализ запросов BSL (фича 10): обратный индекс «кто читает / пишет объект через язык запросов 1С» во всех источниках сразу — модули, формы (динамические списки) и макеты СКД.
Параллельно сложилась единая концепция трёх маркеров расширений, которая работает сквозь все разделы: дерево типов, карточки объектов, роли, параметры сеанса, функциональные опции, XDTO-пакеты, граф вызовов, конструктор профилей. Сценарий аудита безопасности (RLS + привилегированные установки + разделение обязанностей) собран в одном потоке работы. Этот документ — сводный обзор всего, что появилось в текущем релизе.
Анализ запросов BSL — обратный индекс
Вкладка «Запросы» в карточке документа — читатели и писатели в одной таблице
Конфигуратор показывает текст конкретного запроса в момент, когда вы открываете модуль. Но обратный вопрос — «кто читает этот документ в запросах 1С» — стандартными средствами не решается: нужен полнотекстовый поиск по всем модулям, формам и макетам СКД, и потом ручная сверка результатов.
Анализатор парсит все BSL-запросы во время загрузки конфигурации и строит обратный индекс: для каждого объекта (справочника, документа, регистра) известно, в каких функциях, формах и СКД-макетах он участвует как источник или приёмник. В карточке объекта появилась вкладка «Запросы».
Что внутри:
- Читатели — функции, формы и макеты, выбирающие данные этого объекта.
- Писатели — функции, которые записывают в объект.
- Для каждой строки: модуль, строка кода, источник (BSL, макет СКД или динамический список формы), признак СКД-фильтра, индикатор наличия параметров, число соединений в запросе.
- Текст запроса разворачивается рядом со строкой или открывается в отдельном окне.
- Дедупликация рёбер: один и тот же запрос на нескольких источниках агрегируется с указанием числа источников.
Маркеры расширений — те же / применительно к функции, содержащей запрос: видно, что чтение типового объекта идёт из BSL расширения. При обновлении типовой это критично: изменение реквизита типового документа может сломать запрос расширения, который ссылается на этот реквизит по имени.
Кейс. «Удаляем реквизит "СтавкаНДС" из документа "ОтчётКомитенту" — какие запросы конфигурации и расширений сломаются?» Карточка документа → вкладка «Запросы» → разворачиваем текст каждого запроса с reads → ищем упоминания СтавкаНДС в SELECT или WHERE. Если хоть один запрос есть в расширении — это обязательная зона рефакторинга расширения.
Параметры сеанса и точки RLS
Карточка параметра сеанса с RLS-выражениями — четыре секции в одном окне
Анализатор видит параметры сеанса как полноценные узлы графа: где они задаются, кто их читает и где они используются в RLS-выражениях ролей. Это даёт прямой ответ на вопрос «если я изменю обработчик установки параметра X, кому это сломает доступ» — без taint-анализа, чисто из статической картины.
Где смотреть. Кнопка «Парам.сеанса» в левой панели. Слева список всех параметров со счётчиками (типов в составе, BSL-функций, которые пишут и читают, RLS-выражений). Справа — карточка из четырёх секций:
- Состав типов — ссылочные типы и примитивы значения параметра; типы, добавленные расширением, помечены.
- Устанавливают — функции, которые присваивают параметр. Стандартный БСП-обработчик
УстановкаПараметровСеансавыделен красной плашкой PRIV — это привилегированный setter, в котором значение фиксируется на сеанс и подставляется в RLS. - Читают — функции, ссылающиеся на параметр в любых других позициях (правая часть присваивания, условие, текст запроса).
- Используется в RLS — таблица RLS-выражений ролей, где параметр упоминается как
&ИмяилиПараметрыСеанса.Имя. Каждая строка показывает роль, объект, право и полный текст условия — RLS можно прочесть, не открывая роль в EDT.
Масштаб. 1С:ERP. Управление холдингом — 121 параметр сеанса, 305 установок, 767 чтений, 7 002 RLS-выражения в 2 032 ролях. Из них 5 параметров одновременно задаются в УстановкаПараметровСеанса и используются в RLS — то есть ошибка в их установке может тихо изменить поведение RLS-фильтров без предупреждений со стороны платформы. На реальной 1С:ERP. Управление холдингом параметр ОграничениеДоступаНаУровнеЗаписейУниверсально устанавливается в привилегированном режиме функцией УстановкаПараметровСеанса модуля УправлениеДоступомСлужебный и используется в 6 924 RLS-выражениях. Понять «насколько это безопасно» требует архитекторской экспертизы, но сам факт обнаружения такого пути занимает один клик.
Команды объектов и общие команды
Команды объектов в карточке справочника — третья «точка входа» рядом с регламентами и HTTP-сервисами
В графе появился большой класс объектов 1С, до которого раньше анализатор не добирался — команды. И обычные пользовательские команды конкретных объектов («Создать на основании», «Печать счёта», «В отбор»), и общие команды конфигурации (CommonCommands), которые выполняются независимо от формы. Команды — это третья «точка входа» в логику конфигурации рядом с регламентными заданиями и HTTP/Web-сервисами.
Где смотреть.
- В карточке справочника, документа, регистра, отчёта или обработки — вкладка «Команды (N)» рядом со «Связями» и «Функциями». В таблице: имя команды (с синонимом), её группа (
FormCommandBarImportant,CommandGroup.усУстановитьСтатус) и счётчик ролей с правом Use (клик раскрывает список ролей). - В дереве типов слева — ветка «Общие команды N» рядом с «Общие модули» (например, 526 общих команд в 1С:ERP.УХ). В карточке общей команды виден список ролей, которым выдан Use.
Расширения маркируются прямо в строке: — команда добавлена расширением, — типовая команда переопределена расширением. Это закрывает класс вопросов аудита «эту команду добавил лизинг» / «эту команду переопределило Бюро1440».
Парсер ролей раньше выбрасывал имена прав вида <Object>.Command.<X> и CommonCommand.<X> — теперь они корректно резолвятся в рёбра grants к команде-vertex’у. На крупных типовых это десятки тысяч новых рёбер, делающих аудит безопасности полным: 1С:ERP. Управление холдингом — 1 619 команд (включая 41 от расширения «Управление лизингом»).
Карта миграций БСП: обновление ИБ
Обработчики обновления — режим «Между версиями»
Для внедренцев типовых конфигураций. Анализатор видит карту миграций между версиями БСП: полный список обработчиков ОбновлениеИнформационнойБазы.ПриДобавленииОбработчиковОбновления, разнесённый по подсистемам и версиям. Это даёт прямой ответ «что отработает при апгрейде с версии X до Y» — без чтения кода БСП и без запуска тестового обновления.
Где смотреть. Кнопка «Обновление ИБ» в левой панели. Слева список БСП-подсистем (сортировка по числу обработчиков, с поиском). Справа — два режима:
- Все обработчики — таблица, в которой каждая запись массива
Обработчики.Добавить— отдельная строка: версия с цветной подсветкой, процедура в формате<ОбщийМодуль>.<Метод>или<Документы|Справочники|Регистры…>.<Объект>.<Метод>, очередь, режим (Seamless / Deferred / Exclusively), комментарий. Имя процедуры красное с пометкой «unresolved», если функция-реализация отсутствует (сигнал об устаревших обработчиках). Правый клик на резолвленной процедуре — «Открыть в графе вызовов» и «Перейти к связям модуля». - Между версиями — два выпадающих списка «С версии» / «До версии» с числом обработчиков рядом. Результат — точный чек-лист, что отработает при апгрейде, с уже посчитанной очерёдностью. Каждая подсистема БСП имеет независимый таймлайн — это явно подсвечено плашкой, чтобы никто не пытался смешивать версии разных подсистем.
Расширения. Если расширение добавляет собственный общий модуль с процедурой ПриДобавленииОбработчиковОбновления (типичный паттерн отраслевых надстроек), его обработчики попадают в общий список с тегом. На реальной ЕРПУХ + Управление лизингом это 8 дополнительных миграций модуля лиз_ОбновлениеИнформационнойБазы.
Цифры. 1С:ERP. Управление холдингом — 903 обработчика обновления в 117 подсистемах, резолв 98,0 % (885 из 903). Остальные ссылаются на отсутствующие процедуры — кандидаты на чистку устаревших обработчиков.
XDTO-пакеты и критерии отбора
Граф связей XDTO-типа — свойства, атрибуты, фасеты, легенда
XDTO-пакеты — схемы данных Web-сервисов 1С (по сути XSD в формате 1С). Раньше у Web-операции XDTOValueType был просто строкой prefix:Local; теперь это полноценные узлы со своими свойствами и связями. Доступны: список типов пакета (объектные и valueType), наследование, кардинальности свойств, форма (Element / Attribute / Text), список Web-операций, использующих тип, обратная связь «в каких других типах текущий тип используется как тип свойства». Расширения обрабатываются единообразно тремя способами: свой пакет с уникальным targetNamespace, дополнение типового пакета новым типом, дополнение существующего объектного типа новыми свойствами — все три отмечаются маркерами / в карточке.
Кнопка «Граф связей» в карточке типа открывает визуальную карту: дерево раскрывается слева направо лесенкой, каждый узел — отдельная сущность с собственным +/−. Под корнем выбранного типа идут свойства, рядом — кардинальность ([0..1], [1..1], [0..∞]) и имя типа значения. Цветные плашки: голубая — сам XDTO-тип, жёлтая — свойство-элемент, бирюзовая — XML-атрибут, зелёная — Web-операция (со стрелками →/←/ по направлению параметра), серая — фасета valueType (значения, шаблон, длина). Можно «провалиться» в Patch → AppliedFor → SupportedConfiguration без переключения карточек.
Критерии отбора — ещё один cross-cutting объект, теперь самостоятельная вершина графа со своим составом, типом значения и BSL-использованиями. Кнопка «Крит.отбора» в левой панели открывает список со счётчиками ( типов значения, объектов в составе, резолвлено, использований в BSL). Карточка из трёх таблиц: тип значения, состав (полный список путей Document.X.Attribute.Y; элементы расширений маркируются ), использование в BSL (функции с обращением КритерииОтбора.<Имя>). Это упирает критерий в impact-граф изменений.
Перезагрузка обязательна. Все большие фичи добавляют в граф новые коллекции вершин и рёбер. Для систем, загруженных на старых версиях, нужно нажать «Перезагрузить» в шапке системы — иначе соответствующие разделы будут пустыми. Если в системе есть расширения и нужно обновить только ext-вклад, работает «Перезагрузить расширения» — все cross-cutting фичи закрывают ext-only reload корректно: числа vertex и рёбер совпадают с полной загрузкой.
Анализ функций и Граф вызовов
Самая «движковая» часть инструмента: импакт-анализ кода. Граф вызовов BSL построен на основе разбора всех модулей конфигурации и расширений. Рёбра — не только прямые вызовы, но и триггеры записи объектов, подписки на события, регламентные задания, обработчики обновления, RLS-условия и шаблоны ограничений.
Граф вызовов отвечает на вопрос «что случится, если я изменю эту функцию / удалю этот объект / отключу этот регламент». В Конфигураторе аналогичный запрос требует ручного полнотекстового поиска по коду и сверки результатов; в крупной конфигурации он занимает минуты или часы. В Анализаторе тот же запрос — это обход предварительно построенного графа в ArangoDB, и ответ появляется за доли секунды.
В графе видны не только прямые вызовы, но и косвенные — через подписки на события, регламентные задания, переопределения обработчиков в расширениях. Это даёт «полный взрыв» при изменении функции, который штатными средствами вычислить невозможно.
Анализ функций
Левая панель в режиме «Анализ функций» показывает то же дерево типов, но переключатель сверху правой панели — «Все / Пред. и выше / Монстры». Это фильтр по числу вызовов и метрикам функции: «монстр» — функция с одной из четырёх причин: более 500 строк кода, более 50 ветвлений (Если / Пока / Для / Попытка), запросы к БД внутри цикла (N+1), более 10 вызовов .Выполнить в одной функции.
В карточке модуля — таблица функций с колонками: имя, длина, число вызывающих, число вызываемых, флажки динамического вызова, триггеров BeforeWrite/OnWrite/Posting, признак has_dynamic_call (Выполнить/ВызватьМетодОбъекта — статически не раскрывается). Строки текста запросов (начинающиеся с |) исключены из подсчёта: весь текст запроса считается за одну логическую строку и не влияет на оценку сложности.
Граф вызовов от функции
Отдельный режим (кнопка «Граф вызовов» в левой панели). Вы выбираете функцию в дереве или через поиск; справа открывается граф со стрелками calls in (кто вызывает выбранную функцию) и calls out (что выбранная функция вызывает дальше). Граф интерактивный: можно зумировать, двигать узлы, кликать на узел для перехода в его карточку.
В графе видны не только прямые вызовы, но и косвенные: через подписки на события, регламентные задания, переопределения обработчиков в расширениях. Например, удаление документа «Реализация товаров и услуг» в типовой 1С:ERP вызывает не только напрямую упомянутые функции, но и пять подписок «Перед записью» на типе документа — все они появляются в графе как косвенные пути.
В каждом узле графа отображается имя функции, синоним модуля (для общих модулей — имя модуля; для модулей объекта — синоним объекта-владельца), и маркер расширения, если функция или модуль из расширения. Узлы можно фильтровать по типу метаданных и направлению связи.
Точки нагрузки и проблемные модули
Фильтр «Пред. и выше / Монстры» в разделе «Анализ функций» выделяет функции по «массе» в графе вызовов:
- Предупреждение — функции приближаются к опасным значениям: 200–500 строк, 20–50 ветвлений, 5–10 запросов. Изменение такой функции с большой вероятностью ломает существенный объём кода — рисковая зона при обновлении.
- Монстр-функция — самые «нагруженные» функции и модули-гиганты, на которые опирается большая часть конфигурации. Первые кандидаты на рефакторинг и тщательное тестирование при обновлении типовой.
В таблице функций модуля — цветная колонка «Строк» и «Ветв.», колонка «Запросов» с отметкой «N (M в цикле) при N+1». При клике на функцию — правая панель с подробным объяснением: почему именно она попала в монстры и какие числа за этим стоят.
Кейс. Общий модуль «Хозяйственные операции» (НастройкиХозяйственныхОпераций) — функция ПриНачальномЗаполненииЭлементов: 24 266 строк и 991 ветвление. Это первый кандидат на рефакторинг при следующем апгрейде, и видно это до того, как обновление поломает что-то на тестовой ИБ.
Расширения в графе вызовов
Граф объединяет вызовы из типовой и из расширений в одну сеть:
- Доб. <имя расширения> на узле — функция из расширения;
- Заимств. <имя расширения> на узле типовой функции — расширение её «перехватывает» (своя функция-перехватчик типовой через
&Перед,&После,&Вместо); - имя расширения — обработчик регламентного задания или конечной точки HTTP подменён расширением.
Для функций-перехватов считаются эффективные метрики: строки и ветвления самого перехватчика плюс оригинальной функции. Это даёт честную картину реальной нагрузки при поддержке такой связки.
Особенно ценно при обновлении типовой: видно, какие именно функции типовой используются расширениями (рисковая зона при изменении сигнатуры), и какие точки расширения зависят от изменений в типовой. Один взгляд на граф — и понятно, что именно нужно тестировать после апгрейда.
Безопасность — сводный сценарий
Программа не проверяет «правильно ли настроена безопасность» — это решает архитектор по политике организации. Зато программа собирает материал для такого решения: тексты RLS-условий, привилегированные установки параметров сеанса, сводную матрицу прав. Эти материалы разбросаны по разделам «Парам.сеанса», «Роли», «Констр.профилей»; здесь они сведены в общий поток в трёх плоскостях.
RLS — ограничения на уровне записей
Полезные выборки из карточки роли и параметра сеанса:
- Найти роли, у которых дано Изменение на чувствительный справочник без RLS-ограничения — могут менять любую запись.
- Посмотреть текст RLS-условия каждой пары «роль объект» и убедиться, что условие действительно ограничивает данные (а не сводится к
&Истина). - Найти параметры сеанса, на которые опираются RLS-условия — если такой параметр устанавливается в привилегированном режиме без обоснования, это уязвимость.
Текст RLS открывается в один клик по пометке (RLS) рядом с правом — не нужно открывать роль в EDT и листать XML.
Роль «Базовые права БСП»: право «Чтение» справочника с пометкой (RLS), в окне — текст условия (опирается на параметр сеанса)Привилегированный режим — пометка PRIV
УстановитьПривилегированныйРежим(Истина) отключает RLS и проверки прав для блока кода. Используется обоснованно (для системных операций), но злоупотребление превращает любую функцию в потенциальную лазейку обхода прав.
В карточке параметра сеанса строка таблицы «Устанавливают» помечается PRIV, если функция выставляет привилегированный режим непосредственно перед установкой параметра. Это критическая зона аудита, потому что параметр потом используется в RLS-условии — то есть «привилегированная установка → RLS пропускает любые данные».
Привилегированная установка параметра, используемого в RLSКейс. Параметр ОграничениеДоступаНаУровнеЗаписейУниверсально устанавливается в привилегированном режиме функцией УстановкаПараметровСеанса модуля УправлениеДоступомСлужебный и используется в 6 924 RLS-выражениях ролей. Насколько это безопасно — вопрос архитекторской экспертизы, но сам факт обнаружения такого пути занимает один клик.
Разделение обязанностей
В терминах безопасности «разделение обязанностей» (Segregation of Duties, SoD) — это когда в одной роли или одном профиле не должно быть прав, которые позволяют пользователю самому и создать, и одобрить, и исполнить чувствительную операцию. Классический пример: «Добавление документа "СписаниеДенежныхСредств" + Подтверждение оплаты».
Программа не проверяет такие конфликты — у каждой организации своя политика, и формализовать её здесь нельзя. Но программа даёт два материала для ручной или внешней проверки:
- Права каждой роли по объектам — в карточке роли (раздел «Роли»), с пометкой (RLS) у прав с ограничениями.
- Конструктор профилей — предпросмотр суммарных прав до создания профиля. Если в сводных правах профиля обнаружен объект, на который даётся Удаление, — это повод обсудить такое право с заказчиком до того, как профиль создан.
Связь с расширениями
Аудит безопасности обязан учитывать расширения. Часто именно в расширениях, написанных без оглядки на типовую политику доступа, появляются УстановитьПривилегированныйРежим там, где их не было.
Маркер у строки таблицы «Устанавливают» или «Читают» немедленно подсказывает: «это расширение, его правит ваша команда — проверьте обоснование».
Сценарий. «Проверить, не появилось ли в расширении нового PRIV-вызова поверх типового параметра». В карточке параметра сортируем «Устанавливают» по маркеру — видим только установщики из расширений. Если среди них есть строка с PRIV — это новая привилегированная установка, которой нет в типовой; её обоснование нужно документировать.
Расширения видны везде — три маркера
В реальном внедрении вопрос «что фактически работает» — это типовая плюс расширения, а не отдельные сущности. Без сквозной подсветки вкладов расширений аналитик тратит на каждое расследование десятки минут «открыть расширение отдельно, найти, сопоставить». Сквозные пометки / / снимают этот налог.
«Доб. имя расширения» — золотистый
Сущность создана расширением целиком. Своя роль, своя подписка, своя функциональная опция, свой регламент, свой параметр сеанса, свой XDTO-пакет, своя команда. В дереве слева помечается значком в строке объекта; в карточке справа — крупный тег в заголовке.
Подписка «Отмена проведения цепочки документов» добавлена расширением «УправлениеЛизингом»«Заимств. имя расширения» — фиолетовый
Сущность типовая, но расширение её дополнило:
- раздало дополнительные права (роль);
- добавило тип в состав определяемого типа или ПВХ;
- добавило объект в состав функциональной опции;
- добавило обработчик в подписку;
- привязало типовой объект к подсистеме расширения;
- добавило свойство в типовой XDTO-объект.
«Заимствование» помечается как на самой сущности (тег в карточке), так и на конкретной строке состава с указанием имени расширения. Это самый частый production-сценарий 1С-расширений: внедренец видит, какие именно элементы внутри типовой сущности добавлены расширением, без сравнения XML.
В модели данных это решено через origin-поля: для каждой коллекции (состав определяемого типа, элементы функциональной опции, права роли, объекты подсистемы) хранится карта «элемент → имя расширения». Аналитик видит карту целиком в одном клике.
«имя расширения» — переопределение обработчика
Применяется к сущностям, у которых есть функция-обработчик:
- регламентное задание (метод-обработчик подменён);
- конечная точка HTTP (метод-обработчик подменён);
- операция SOAP.
В карточке такой сущности виден исходный обработчик (что было до подмены) и имя расширения, которое подменило обработчик. Это важно при апгрейде: если типовой обработчик изменился, переопределение в расширении может не подцепить новую логику — и регламент / HTTP-эндпоинт будет работать «на старой версии» молча.
Также маркер виден в графе вызовов: на узле обработчика, который заменён, и на функции-перехватчике расширения (&Перед, &После, &Вместо).
Где маркеры встречаются
Маркеры расширений сквозные — они работают во всех разделах программы:
| Раздел | |||
|---|---|---|---|
| Дерево типов | — | ||
| Карточка объекта (вкладки) | — | ||
| Карточка роли | — | ||
| Параметры сеанса | — | ||
| Функциональные опции | — | ||
| Определяемые типы и ПВХ | — | ||
| Подписки на события | |||
| Регламентные задания | — | ||
| HTTP-сервисы и Web-сервисы | — | ||
| XDTO-пакеты | — | ||
| Граф вызовов | |||
| Конструктор профилей | — |
Все маркеры в интерфейсе строятся из полей графа знаний — один источник истины. Поля заполняются на этапе парсинга независимо от формата исходников (ZIP-выгрузка, EDT-проект, монорепо, отдельные репозитории, рабочая область EDT).
Зачем это при обновлении типовой
При обновлении типовой маркеры подсказывают, какие именно точки расширения зависят от изменений типовой:
- — если типовой обработчик изменился, переопределение в расширении может не подцепить новую логику. Регламентное задание или HTTP-эндпоинт нужно перепроверить.
- — если типовая роль или тип изменились, вклад расширения нужно пересмотреть. Расширение могло раздавать права на состав, который теперь другой.
- — если типовой объект, на который опирается сущность расширения, изменился, расширение нужно адаптировать. Это видно через граф вызовов: функции расширения, вызывающие изменённую типовую функцию.
Один взгляд на маркеры — и понятен полный список точек, которые нужно тестировать после апгрейда. Без сквозной подсветки каждое такое расследование занимает часы.
Чем отличается от стандартного Конфигуратора 1С
Сводная таблица «вопрос → как ответить». Включены кейсы, которые либо невозможны в Конфигураторе, либо требуют ручного обхода десятков окон. Анализатор — только анализ, без редактирования: правки кода и обновление ИБ остаются за Конфигуратором / EDT.
Структура и навигация
| Кейс | Конфигуратор | Analyzer 1C |
|---|---|---|
| Все объекты одного типа в одном списке | Ветка дерева | Дерево со счётчиками |
| Поиск по синониму, а не по имени | Только Ctrl+Shift+N по имени | Поле поиска в шапке |
| Объекты типовой и расширений вместе | Разделено | Объединено, с маркерами и |
| Счётчики в реальном времени | — | Счётчики на каждом узле |
| Переключение между загруженными конфигурациями | Две сессии | Смена системы в выпадающем списке (сравнение — только версий и поставок одной системы, в режиме «Версии») |
Зависимости и связи
| Кейс | Конфигуратор | Analyzer 1C |
|---|---|---|
| Кто ссылается на этот объект | Поиск ссылок | Вкладка «Связи» |
| Кто читает объект в запросах 1С | Полнотекстовый поиск | Вкладка «Запросы» |
| Кто вызывает эту функцию | Поиск ссылок | Входящие вызовы в графе |
| Что вызывает эта функция | Вычитывание текста | Исходящие вызовы в графе |
| Транзитивная цепочка вызовов | — | Граф с раскрытием |
| Косвенный путь через подписку | Надо помнить о подписке | Автоматически |
| Модули-гиганты и точки нагрузки | — | Фильтр « Монстры» |
Роли и безопасность
| Кейс | Конфигуратор | Analyzer 1C |
|---|---|---|
| Все RLS-выражения роли в одном месте | Каждое право вручную | Кликабельная пометка (RLS) и окно с текстом |
| Параметры сеанса в RLS | Поиск по тексту | Счётчик на параметре |
| Привилегированные установки | Вычитывание УстановитьПривилегированныйРежим |
Пометка PRIV в карточке параметра |
| Предпросмотр профиля прав | Создание тестового профиля | Конструктор профилей |
| Права роли по объектам | В окне роли | В карточке роли — дерево прав по объектам с пометкой (RLS) |
Программные проверки РольДоступна |
Поиск по коду | Видны рядом с правами роли |
Внешние API и расширения
| Кейс | Конфигуратор | Analyzer 1C |
|---|---|---|
| Все конечные точки REST в одной таблице | Дерево сервисов | Таблица «N сервисов, M конечных точек» |
| Сравнение XDTO-пакетов | Две сессии | Изменённые пакеты в срезе сверки версий (по сигнатуре: namespace + число типов/свойств + импорты) |
| Переопределение обработчика HTTP расширением | Сравнение XML | на конечной точке |
| Какие подписки расширение добавило | Открыть расширение отдельно | в карточке объекта-источника |
| Какие регламенты расширение переопределило | Сверка вручную | и исходный обработчик |
| Какие функции расширения опираются на типовую | Анализ кода | Граф вызовов с маркерами |
| Влияние расширения после обновления типовой | — | Все маркеры в одном месте |
Когда Analyzer 1C не заменяет Конфигуратор
Чтобы не создавать ложных ожиданий, Analyzer 1C — только анализ, без редактирования. Если нужно:
- править XML/BSL — Конфигуратор или EDT;
- запустить отладку — Конфигуратор;
- собрать
.cf-файл, выкатить обновление — Конфигуратор; - работать с реальной информационной базой — Конфигуратор.
Analyzer 1C показывает состояние конфигурации, не оперирует информационной базой и не выполняет код. Он отвечает на вопросы «что есть в коде» и «как это связано» — без рисков случайных изменений.
Типичная связка инструментов:
- В Analyzer 1C находите проблему (влияние изменения, конфликт прав, вклад расширения) и понимаете контекст.
- По указанному имени модуля / функции / объекта открываете его в Конфигураторе (EDT) и правите.
- Перезагружаете конфигурацию в Analyzer 1C — проверяете, что правка отражена в графе как ожидалось.
Дополнительные возможности Analyzer 1C
Карточка объекта и группа «Связи»
Карточка — центральный экран программы: с неё начинается большинство расследований («куда ссылается этот документ», «кто его читает», «какие роли дают на него права», «какие команды есть»). В шапке — иконка типа метаданных, синоним и маркер / если есть. Под шапкой — вкладки: Связи, Функции, Команды, Запросы, Роли.
Группа «Связи» — самая важная: таблица всех рёбер графа, ведущих в объект или из него. Группировка по типу, фильтр по направлению (входящие/исходящие), фильтр по типу метаданных. Каждое ребро несёт dir («Ссылается», «Подписан», «Обработчик», «Запускает», «В составе» и т.п.), что делает таблицу читаемой без перехода на каждое ребро в графе.
Документ «Реализация товаров и услуг» — 477 связей: 104 общих модуля, 69 справочников, 57 документов, 32 регистра накопленияЕсли ребро добавило расширение — оно подсвечено: например, « Источник ERP_IFRS» для подписки расширения на типовой документ. Сразу видно вклад расширения, не обходя список расширений отдельно.
Подписки на события и регламентные задания
Подписки на события (EventSubscription) — один из самых «невидимых» источников поведения 1С. При записи документа, константы или набора записей регистра срабатывают процедуры из общих модулей, перечисленные в поле Handler. Найти эти цепочки вручную сложно: нужно открыть каждую подписку и понять, какие объекты она затрагивает.
Анализатор парсит раздел EventSubscriptions основной конфигурации и расширений, извлекает событие (ПередЗаписью, ПриЗаписи, ОбработкаПроведения), список источников и обработчик, и строит двунаправленные связи в графе: от объектов-источников к подписке и от подписки к общему модулю-обработчику.
Подписка «Зарегистрировать данные первичных документов» (При записи) затрагивает 212 документов — от объектов-источников к подписке и к общему модулю-обработчикуРегламентные задания — ещё одна точка входа в логику конфигурации. В карточке регламента видны: расписание, обработчик в формате <ОбщийМодуль>.<Метод>, контекст исполнения (сервер/клиент/внешнее соединение), маркер если обработчик переопределён расширением.
Кейс. При диагностике медленной записи документа достаточно открыть его карточку и посмотреть блок «Подписки» — все подписки, срабатывающие при записи, видны как отдельные строки. Если на одном документе висит пять подписок «Перед записью», каждое сохранение последовательно вызывает пять процедур — вот и источник «тормозов».
Конструктор профилей
Профиль в БСП — это пользовательская совокупность ролей. Аналитику важно увидеть суммарные права до фактического создания профиля: какие объекты будут доступны, какие действия можно будет выполнять, нет ли неожиданных пересечений прав между выбранными ролями. В Конфигураторе профиля как сущности нет — есть роли, и проверить «что получится» можно только при тестировании в ИБ.
Конструктор профилей даёт предпросмотр прав до создания: отмечаете флажками нужные роли в левой панели, в правой сразу появляется агрегированная матрица «объект × право», список конфигурационных прав и список подсистем.
Профиль из трёх ролей (678 разрешений) — итоговые разрешения, агрегированные по объектам конфигурацииВ матрице — маркеры расширений на объектах: — объект из расширения, — типовой объект с вкладом расширения в права. Пометка (RLS) на правах с ограничением, текст условия — в том же окне, что в карточке роли. Если в матрице обнаружили объект, на который суммарно даётся Удаление, — это повод обсудить такое право с заказчиком профиля до того, как профиль создан.
Функциональные опции
В типовых на 1С — десятки и сотни функциональных опций («Использовать партионный учёт», «Учёт по складам», «Многофирменность»), которыми внедренец и архитектор управляют видимостью и поведением конфигурации. Раздел «Функц.опции» в левой панели даёт три ответа сразу: что опция отключает в интерфейсе, где её значение читается в коде, и какие опции затрагивают конкретный объект, когда вы открываете его карточку.
Сайдбар «Функц.опции» в режиме ЕРПУХ — больше тысячи опций, активные сверху, устаревшие полупрозрачные внизуВ каждой строке списка — заголовок опции и три счётчика: Состав (элементов в Content), Контролирует (объектов, реально отключаемых), Проверяется (функций BSL, где значение опции читается через ПолучитьФункциональнуюОпцию).
Если опция собственная для расширения — на ней маркер с именем расширения. Если у опции стоит «Привилегированное получение значения» — маркер. Флажок « Только затронутые расширениями» оставляет в списке только опции, чей состав или само определение правит какое-нибудь расширение. Это даёт точный ответ «что сломается при выключении опции X» до фактического выключения в ИБ.
Внешние API
Раздел «Внешние API» показывает все точки входа в конфигурацию в одном месте: HTTP-сервисы с URL-шаблонами и обработчиками методов (GET/POST/PUT/DELETE), Web-сервисы (SOAP) с операциями и привязкой к BSL-функциям, регламентные задания с расписанием и handler-методом, подписки на события и планы обмена. Для каждой записи виден контекст исполнения (сервер/клиент/внешнее соединение) и быстрая ссылка на сам обработчик в коде. Особенно полезно при аудите безопасности и интеграций: за одну страницу видно весь периметр взаимодействия системы с внешним миром.
Программный доступ к графу (MCP)
В платной версии граф конфигурации доступен не только через интерфейс, но и программно — по протоколу MCP (Model Context Protocol). Это открывает ИИ-ассистенту разработки и вашей автоматизации прямой доступ к «анатомии» системы: составу объектов, связям, анализу влияния, ролям и циклам — теми же данными, что видны в интерфейсе.
Назначение — заземление ИИ-помощника на реальное устройство конфигурации: его выводы опираются на граф, а не на догадки модели. Описание протокола и перечень доступных операций поставляются отдельным документом.
Изучение подсистем
Режим знакомства с незнакомой конфигурацией через её собственный язык: подсистемы. Слева — список всех подсистем, отсортированный по числу документов (служебные платформенные скрыты по умолчанию). Клик по любой открывает карточку процесса с двумя видами:
- Список — инициирующие документы → промежуточные → завершающие, со ссылками друг на друга через регистры и проводки;
- Граф — тот же путь визуально, с подсветкой цепочки от выбранного документа.
Это даёт прямой ответ на вопрос «как здесь устроена работа», не заставляя вручную обходить дерево объектов: за минуты видно, с чего процесс начинается, чем заканчивается, и какие документы участвуют посередине. Любую подсистему можно пометить как служебную через -меню — пометка сохраняется между сессиями.
Визуализация графа и статистика конфигурации
Переключатель «Таблица / Граф» в правой панели визуализирует зависимости выбранного объекта в виде интерактивного графа. Узлы — связанные объекты, рёбра — типы связей (вызовы, ссылки, заимствования). Правый клик по узлу — переход к зависимостям этого объекта (навигация вглубь графа).
Граф зависимостей документа «Реализация товаров и услуг»Вкладка «Инфо» показывает общую статистику загруженной конфигурации: число подсистем, модулей, функций, вызовов, ссылок реквизитов, запросов к таблицам и ролей. Удобно для быстрой оценки масштаба: 1С:ERP. Управление холдингом — 907 подсистем, 28 342 модуля, 699 793 функции, 60 470 вызовов.
Статистика 1С:ERP. Управление холдингомЗагрузка из ZIP, git и бинарных .cf (6 форматов)
Поддерживаются 6 способов загрузки конфигурации, формат определяется автоматически:
- ZIP — выгрузка 1С через «Конфигурация → Выгрузить конфигурацию в файлы» (с расширениями внутри архива).
- Монорепо —
src/cf/+src/cfe/{ext1, ext2, …}в одной git-папке. - Отдельные git-репозитории — main и каждое расширение в своём репозитории, клонируются в подпапки одной папки.
- EDT-проект — одиночный git-клон с
Configuration.xml/.mdoв корне. - EDT workspace — несколько EDT-проектов на произвольной глубине в одном git-репо (например, основная конфигурация и расширения в одном клоне).
- Бинарные
.cf/.cfe— прямой бинарный контейнер поставки 1С без предварительной выгрузки в файлы, включая конфигурации-гиганты (обрабатываются потоково).
В диалоге загрузки укажите имя папки и выберите ZIP или URL git-репозитория с веткой. Для приватных репозиториев — токен в диалоге или переменной окружения ANALYZER_GIT_TOKEN в .env. Расширения подхватываются автоматически по маркеру ConfigurationExtensionPurpose.
Диалог «Загрузить конфигурацию»: вверху — выбор источника (ZIP-файл, бинарные .cf/.cfe, git-репозиторий); на примере — клонирование из git с указанием папки, URL и веткиПри повторном клонировании того же URL делается git pull в существующей папке — без дубликатов. Разбор и загрузка ERP УХ (28 342 модуля) занимает около 15 минут. Можно загрузить несколько конфигураций и переключаться между ними через выпадающий список в шапке.
Варианты организации репозитория
Поддерживаются шесть способов загрузки конфигурации — инструмент автоматически определяет тип конфигурации и формат выгрузки. Ниже — три самых распространённых git-варианта; отдельно работают ZIP-выгрузка из Конфигуратора, EDT workspace (несколько EDT-проектов в одном git-репо) и прямая загрузка бинарных .cf/.cfe.
Монорепо
Основная конфигурация — в src/cf/, расширения — вsrc/cfe/{имя_расширения}/.- Один репозиторий — один клон, всё определяется автоматически.
Отдельные репозитории
- Основная конфигурация и каждое расширение в отдельном репозитории.
- Клонируются в подпапки одной папки (
main/,ext1/,ext2/).
EDT-проект или одиночный репозиторий
- Репозиторий содержит одну конфигурацию (основную или расширение).
- Формат (git-sync или 1C:EDT) определяется автоматически. EDT workspace с несколькими проектами в одном репо — тоже поддерживается.
Инструмент автоматически определяет, что является основной конфигурацией, а что расширением — по наличию ConfigurationExtensionPurpose в Configuration.xml или маркера mdclassExtension:ConfigurationExtension в .mdo для EDT. При повторной загрузке выполняется git pull: для монорепо — один раз, для отдельных репозиториев — в каждой подпапке, для EDT workspace — в каждом найденном git-корне.
Развёртывание
Analyzer 1C поставляется как готовый Docker-образ. Для развёртывания нужен только 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 # Перелогиньтесь, чтобы применить группу
Скопируйте на сервер файлы из архива поставки:
analyzer-1c-offline.tar— Docker-образdocker-compose.prod.yaml— конфигурация запускаdeploy.sh(Linux) илиdeploy.bat(Windows) — скрипт деплояstart.sh,stop.sh(Linux) или.bat-варианты (Windows) — повторный запуск и остановка.env.example— пример настройки переменных окружения
Поставка автономна: в одном архиве и приложение, и ArangoDB — они поднимаются вместе одной командой, отдельно базу устанавливать не нужно.
Linux:
bash deploy.sh
Windows (cmd или PowerShell):
deploy.bat
Скрипт загрузит образ, запустит контейнер и удалит архив. После запуска приложение доступно по адресу http: / localhost:8000.
Для остановки: bash stop.sh / stop.bat. Повторный запуск: bash start.sh / start.bat.
Откройте веб-интерфейс, в выпадающем списке систем выберите «Загрузить новую...» и укажите папку для загрузки и ZIP-выгрузку конфигурации либо адрес git-репозитория и ветку. Расширения должны загружаться в ту же папку, что и основная конфигурация, с другим именем архива. Разбор и загрузка ERP УХ (28 342 модуля) занимает около 15 минут. Можно загрузить несколько конфигураций и переключаться между ними.
Обновление ставится поверх текущей установки тем же способом, что и первая установка: скопируйте в ту же папку новый analyzer-1c-offline.tar из свежей поставки и запустите deploy.sh / deploy.bat ещё раз. Скрипт загрузит новый образ и пересоздаст контейнер приложения.
Данные при обновлении не теряются. Обновляется только образ приложения. База ArangoDB (она хранится в отдельном томе Docker) и папка conf/ с загруженными конфигурациями остаются на месте, поэтому после обновления сохраняются:
- все загруженные конфигурации и расширения;
- зафиксированные версии и поставки, история сверки и объединения;
- уже построенный граф знаний — он сразу доступен после обновления.
Перезагружать конфигурацию заново не требуется, если обновление не меняет логику загрузки. Но если в новой версии доработан разбор (новые поля, коллекции графа, парсеры объектов или связей), конфигурацию нужно перезагрузить кнопкой «Перезагрузить» в шапке — чтобы граф пересобрался с учётом улучшений. Что именно меняется в каждой версии, указано в её описании.
Технические требования
Работоспособность гарантируется:
-
Программа не задействует Платформу 1С.
-
Тестировалась выгрузка на 8.3.27.1719,
-
Будет одинаково работать с любой платформой 1С, где реализована выгрузка данных конфигурации в файлы. Также поддерживается формат 1С:EDT (файлы
.mdo/.rights) напрямую, без промежуточной выгрузки в XML.На слайдах 1С:ERP. Управление холдингом (3.2.8.11)
Код открыт.
Линейка 2.0 — самый большой шаг с момента появления версий: анализатор стал инструментом обновления поставки. Сравнение и объединение версий теперь идёт деревом «как в Конфигураторе» (тип метаданных → объект → функции внутри), с окном кода на две и три колонки, подсветкой синтаксиса BSL и редактируемой панелью «Результат объединения». Для каждого изменения предлагается решение в одном из четырёх режимов Конфигуратора, а готовый план выгружается файлом настроек для штатного «Сравнения и объединения». Появились проверки безопасного обновления: скрытый конфликт из-за перехвата расширением (&Вместо / &ИзменениеИКонтроль) и висячие ссылки на удаляемые вендором функции. Поставку можно загрузить напрямую из бинарных .cf/.cfe (включая гиганты больше гигабайта), добавился раздел циклических зависимостей между модулями, все формы объекта стали полноценными узлами графа, а на каждой плашке появилась контекстная справка «Как пользоваться».
Analyzer 1C 2.0.137 — теперь к анализатору могут подключаться ИИ-агенты
Главное в обновлении — анализатор научился отдавать «анатомию» конфигурации не только человеку в интерфейсе, но и ИИ-агентам: теперь они могут подключаться к нему по стандартному протоколу MCP. Вместо того чтобы догадываться об устройстве системы и придумывать имена объектов, агент обращается к анализатору и получает факт из графа: какие в системе объекты и как они связаны, кто кого вызывает, что затронет правка, какие роли дают права. Анализатору доступно десять инструментов — в том числе морфологический поиск объектов («версия таксономии» находит каталог «Версии таксономии»), структура данных с подчинённостью «Владелец» и ссылочными реквизитами, поиск функций по смыслу действия с готовой сигнатурой (имена и типы параметров, тип результата) — чтобы агент переиспользовал существующую функцию, а не писал дубль. Чтобы было видно, что именно отдаётся агенту, в интерфейсе появилась панель «MCP-инструменты» — витрина того же набора с формой вызова и ответом сервера.
Помимо этого: подчинённость «Владелец» теперь доходит до графа, у функций разбираются входы и выходы прямо из кода и комментариев ИТС (без обращения к нейросети), удобнее стала работа анализатора, встроенного в 1С:EDT (история переходов, открытие функции прямо в редакторе), а из бинарных файлов поставки .cf извлекается больше состава — определяемые типы, параметры сеанса, виды характеристик, операции веб-сервисов, типы XDTO-пакетов и команды объектов. Все возможности работают одинаково для всех шести способов загрузки, включая расширения, и проверены на поставках ERP-гигантов. Подключение агентов по MCP доступно в полной версии.
Остались вопросы?
Для получения дополнительной информации и помощи в настройке модуля под нужды вашего бизнеса — оставьте заявку
