> For the complete documentation index, see [llms.txt](https://docs.onerpa.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.onerpa.ru/mcp-servery-1c/servery/code-metadata-search/podgotovka-dannyh.md).

# Подготовка данных

Актуальный основной источник CodeMetadataSearchServer — выгрузка конфигурации в файлы. Сервер читает метаданные и BSL-код напрямую из **Designer XML** или проекта **1C:EDT**. Отдельный текстовый отчёт Конфигуратора больше не обязателен и используется только в совместимом режиме `METADATA_SOURCE=report`.

## Поддерживаемые источники

| Источник        | Как распознаётся                                                                                                     | Что индексируется                                                                             |
| --------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| Designer XML    | В корне есть `Configuration.xml`; объектные файлы и каталоги `Ext` созданы командой «Выгрузить конфигурацию в файлы» | Метаданные, BSL-модули, управляемые и обычные формы, HTML-справка, XML-артефакты, зависимости |
| 1C:EDT          | Проект содержит `.project`, `DT-INF` или структуру исходников `src/`                                                 | Метаданные и код из EDT-структуры с теми же canonical identity, что у Designer XML            |
| Текстовый отчёт | Каталог `METADATA_PATH` с отчётом Конфигуратора                                                                      | Совместимый legacy-источник метаданных; код и артефакты всё равно берутся из `CODE_PATH`      |

`SOURCE_FORMAT=auto` определяет Designer XML или EDT по каталогу. Если признаки формата потерялись при переносе, задайте `SOURCE_FORMAT=designer_xml` или `SOURCE_FORMAT=edt` явно.

## Вариант 1: Designer XML (рекомендуется)

1. Откройте конфигурацию в Конфигураторе.
2. Выполните **Конфигурация → Выгрузить конфигурацию в файлы**.
3. Укажите отдельный каталог, например `E:\1C_Export\Files`.
4. Проверьте, что в корне выгрузки присутствует `Configuration.xml`.
5. Смонтируйте каталог в `/app/code` и задайте:

```
CODE_PATH=/app/code
METADATA_SOURCE=xml
SOURCE_FORMAT=auto
```

Минимальная ожидаемая структура:

```
E:\1C_Export\Files\
├── Configuration.xml
├── Catalogs\
├── Documents\
├── CommonModules\
├── Reports\
└── DataProcessors\
```

## Вариант 2: проект 1C:EDT

Смонтируйте корень EDT-проекта в `/app/code`. Оставьте `SOURCE_FORMAT=auto` либо задайте `SOURCE_FORMAT=edt` явно. Один и тот же объект в Designer XML и EDT получает одинаковый canonical UUID/FQN; физический путь сохраняется как evidence, а не становится идентификатором объекта.

```
CODE_PATH=/app/code
METADATA_SOURCE=xml
SOURCE_FORMAT=edt
```

## Вариант 3: совместимый текстовый отчёт

Используйте только для существующей установки, которая обязана читать подготовленный отчёт:

1. Выполните **Конфигурация → Отчёт из конфигурации**.
2. Включите все разделы и сохраните отчёт в отдельный каталог.
3. Смонтируйте отчёт в `/app/metadata`, а выгрузку кода — в `/app/code`.
4. Задайте:

```
METADATA_PATH=/app/metadata
CODE_PATH=/app/code
METADATA_SOURCE=report
```

{% hint style="warning" %}
Не смешивайте источники неявно. `METADATA_SOURCE=xml` (и `auto`, когда в `CODE_PATH` есть выгрузка) не даёт лежащему рядом отчёту победить; `report` требует отчёт и завершает запуск ошибкой, если его нет.
{% endhint %}

## Вложенные конфигурации поставщика

По умолчанию каталоги `Ext/ParentConfigurations` исключаются, чтобы основная конфигурация и вложенная поставляемая конфигурация не смешивались.

Для отдельной индексации вложенных конфигураций задайте:

```
INDEX_NESTED_CONFIGURATIONS=true
NESTED_CONFIGURATION_PATHS=Ext/ParentConfigurations
```

Каждая вложенная конфигурация получает отдельный `source_id` и выводится через фильтр `origin`.

## Обновление данных

При `INCREMENTAL_INDEXING=true` сервер сравнивает SHA-256 файлов и строит новое поколение только из изменившихся единиц. Старое активное поколение продолжает отвечать до завершения проверки и атомарного переключения. Полный сброс через `RESET_DATABASE=true` нужен только для осознанной полной перестройки, а не для обычного обновления выгрузки.