© 2026 WIIKOРазработка · Собственные продукты · Дистрибуция
Расширение 1С:Предприятия, которое добавляет базе интерфейс OData версии 4: Power BI и Excel читают данные нативно, агрегация и пакетные запросы работают, доступ выдаётся токенами. Открытый код, лицензия MIT.
- Год
- 2026
- Направления
- Собственные продукты, веб-сервисы и API
- Стек
- 1С:Предприятие 8.3, язык 1С, Rust, OData v4, Native API, Apache, IIS
- Исходники
- GitHub, лицензия MIT
Задача
Power BI и Excel
Канал OData у них рассчитан на четвёртую версию. К третьей подключаются с оговорками, и половина типов приезжает строками.
Считать на стороне 1С
$apply в третьей версии нет. Чтобы получить десять итогов, отчёт выкачивает миллион строк и складывает их у себя.
Несколько операций разом
На $batch штатный интерфейс отвечает 501. Каждая запись — отдельный запрос, и собрать их в одну транзакцию нечем.
Запись без гонок
Нет ETag и If-Match: два клиента, изменившие один объект, молча затирают правки друг друга.
| Что сравниваем | standard.odata | OData4 |
|---|---|---|
| Протокол | v3 | v4.0 и 4.01, JSON и CSDL XML/JSON |
| Power BI и Excel, «Из канала OData» | с оговорками | нативно, вход по токену без пароля 1С |
| Агрегация на сервере ($apply) | — | groupby, aggregate, filter, topcount |
| Пакетные запросы ($batch) | 501 | да, набор изменений — одна транзакция |
| Запись | без защиты от гонок | ETag и If-Match, безопасный повтор, проведение, движения |
| Доступ | пользователь 1С | профили: объекты, поля, отборы строк, лимиты, частота |
| Токены доступа | — | срок, отзыв, ограничение по IP |
| Журнал запросов и CORS | — | да |
| $metadata в тёплом сеансе | ~400 мс | ~25 мс, кэш между сеансами |
Решение
Не доработка конфигурации, а расширение: база получает второй интерфейс, штатный остаётся на месте и работает рядом.
Имена наборов совпадают со штатными — Catalog_…, Document_…, AccumulationRegister_…, ключ Ref_Key. Для готовых отчётов переход сводится к смене адреса. Сервис строится по метаданным, поэтому работает в любой конфигурации: с БСП и без неё.
- 10 минут
- на установку расширения
- 0 правок
- в конфигурации базы
- 2 203 набора
- в составе публикации демобазы
- MIT
- исходники открыты
GET /base/hs/odata/v4/Document_РеализацияТоваровУслуг ?$filter=Date ge 2026-01-01T00:00:00Z and Контрагент/Description eq 'Ромашка' &$select=Number,Date,СуммаДокумента &$expand=Товары($select=Номенклатура_Key,Количество,Сумма) &$orderby=Date descЧто показало разложение
93–97%
времени запроса уходило на сборку JSON средствами 1С.
Сам запрос к базе и выгрузка результата занимают единицы миллисекунд. Оптимизировать запросы было бы бесполезно: платили не за них. Разложение сделано на странице из тысячи документов с 44 тысячами строк табличных частей.
Сериализация JSON
7 816 мсСборка строк табличных частей
427–1 002 мсФормирование ответа
81 мсВыгрузить()
11 мсЗапрос к базе
3 мс
Компонента на Rust
Сериализацию вынесли из 1С во внешнюю компоненту. Главным решением оказался не сам Rust, а способ передать ему строки.
Сто тысяч строк по 24 колонки: по одному значению — 13 207 мс, строкой с разделителями — 7 892, через JSON — 6 465, внутренним форматом таблицы значений — 1 316. Неудачный способ съедал весь выигрыш компоненты целиком. Сама компонента необязательная: если её нет, сервис работает на языке 1С и отвечает теми же ответами, только медленнее.
Страница документов с табличными частями
9 088 → 1 450 мс
6,3 ×Документы целиком, 3,5 ГБ
992 → 161 с
6,2 ×Документы, три поля
10,5 → 2,5 с
4,2 ×Справочник целиком, 154 МБ
47,9 → 11,7 с
4,1 ×Записи регистра накопления, 1,5 ГБ
853 → 471 с
1,8 ×
Во сколько раз быстрее стало по сравнению с выдачей на языке 1С, ступень 100 тыс. документов.
- 13 207 → 1 316
- миллисекунд на передачу 100 тыс. строк в компоненту, когда способ передачи выбрали правильно
- 28 мс
- $metadata в тёплом сеансе против 402 мс у штатного интерфейса: модель строится лениво и кэшируется между сеансами
Результат
На больших выгрузках расширение обходит штатный интерфейс, а ответ отдаёт вдвое компактнее.
Замеры 27 сентября 2026: файловая база, 100 тыс. документов и миллион записей в регистрах, веб-сервер на той же машине.
Полная выгрузка, секунды
Документы с табличными частями
100 тыс. документов, ответ 3,5 ГБ
OData4161–199 сstandard.odata257–263 сЗаписи регистра накопления
1,09 млн записей
OData4134 сstandard.odata147 сЗаписи регистра бухгалтерии
1,12 млн записей — здесь мы медленнее
OData4199 сstandard.odata124 сСправочник целиком
100 тыс. элементов, ответ 154 МБ
OData411,2 сstandard.odata10,7 с
Объём ответа, гигабайты
Записи регистра накопления
1,09 млн записей
OData41,5 ГБstandard.odata3,3 ГБЗаписи регистра бухгалтерии
1,12 млн записей
OData41,1 ГБstandard.odata2,2 ГБДокументы с табличными частями
100 тыс. документов
OData43,5 ГБstandard.odata3,8 ГБ
Где мы медленнее
Это не везде выигрыш, и прятать такое в сноску нечестно.
Одиночные мелкие запросы медленнее штатного интерфейса: 28 мс против 14.
Записи регистра бухгалтерии на миллион строк страницами по умолчанию отстают: 199 с против 124.
Мерено на файловой базе с веб-сервером на той же машине — клиент-серверная не замерена.
Одновременная работа многих клиентов не замерена.
Установка
Пять шагов, десять минут и ни одной правки в конфигурации.
- 01
Скачать расширение
Файл OData4-<версия>.cfe со страницы релизов на GitHub.
- 02
Загрузить в базу
Конфигуратор → «Конфигурация → Расширения конфигурации → Добавить из файла», затем обновить конфигурацию базы данных.
- 03
Разрешить HTTP-сервисы
В публикации базы на веб-сервере включить «Публиковать HTTP-сервисы расширений по умолчанию».
- 04
Назначить роли
Пользователям — OData4_Пользователь, администратору — OData4_Администратор. На БСП роли выдаются через профили групп доступа.
- 05
Открыть корень сервиса
http://сервер/база/hs/odata/v4/ от имени администратора. Первый такой запрос запоминает состав стандартного интерфейса, после чего сервис доступен остальным.
Где посмотреть
