Поиск по расширениям 1С (.cfe)

Расширения конфигурации (.cfe) это удобный механизм для доработки типовой без снятия её с поддержки. Но когда расширений в базе больше двух, разобраться где какой код становится сложно. Особенно если AI-ассистент не видит расширений и предлагает решения только на основе основной конфигурации.

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

Что индексируется

Расширения подгружаются как .cfe файлы или напрямую с подключённой базы. Из файла извлекаются BSL-модули и метаданные расширения. Каждый модуль попадает в Bleve-индекс с дополнительными полями: имя расширения и тип (общий модуль, модуль формы, модуль объекта, и так далее).

Хранение и парсинг отделены от индексации. Модуль из расширения и модуль из основной конфигурации в индексе живут на одинаковых правах: разница только в метках.

Метка [Расш]

В выдаче поиска модули из расширений получают префикс [Расш] и имя расширения. Например, при поиске процедуры ПолучитьДанные AI увидит результаты вида:

ОбщийМодуль.РаботаСДокументами.ПолучитьДанные
[Расш] МойФункционал.ОбщийМодуль.РаботаСДокументамиДополнительно.ПолучитьДанные
[Расш] КастомОтчеты.ОбщийМодуль.РаботаСДокументами.ПолучитьДанные

Видно, что в основе процедура определена один раз, и поверх неё два расширения добавили свои варианты. Без метки эту картину пришлось бы собирать вручную через Конфигуратор.

Когда обновляется

Индекс расширений обновляется при подключении расширения к базе и при изменении модуля внутри расширения. Принудительно перечитать список и пересобрать индекс можно действием refresh_extensions инструмента system ({"action": "refresh_extensions"}). Это нужно если работаешь с базой через файловое подключение и в ней появилось новое расширение в обход стандартного жизненного цикла.

Поиск только по расширениям

Если нужно сузить выдачу до расширений, в вызове code_search с action: "text" задаётся параметр category со значением Расширения:

{"tool": "code_search", "action": "text", "query": "ПолучитьДанные", "category": "Расширения", "mode": "smart"}

Слово принимается в четырёх написаниях: Расширения, Расширение, Extensions, Extension. Регистр не важен. Это то же множество написаний, которое понимает параметр filter действия code_read с action: "metadata_tree", поэтому написание, выученное на одном инструменте, работает и на другом.

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

Отбор по расширениям работает не во всех режимах поиска одинаково. Режимы smart, regex и exact спрашивают индекс про пространство имён расширений напрямую и отвечают по нему полностью. Векторные режимы Профессиональной редакции устроены иначе: они ранжируют всю конфигурацию целиком, а отбор применяется уже к их ответу.

• mode: "hybrid" вместе с category: "Расширения" не выполняется вовсе. Ответ был бы неполным, а число совпадений неверным, поэтому вызов отклоняется с объяснением и предложением повторить его с mode: "smart" и той же category.
• mode: "semantic" отвечает, но его список расширений может оказаться неполным. Когда так происходит, к ответу добавляется оговорка с тем же советом: повторить запрос с mode: "smart" и той же category.

Ограничения

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

Внешние обработки и отчёты (.epf, .erf) расширениями не считаются, для них работает отдельный механизм.

Где это полезно

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