Универсальный http-сервис с автоматической сериализацией выходных данных и внешним управлением настройками

Добрый день.

В связи с активным развитием вайб-кодинга внутри компании появилась потребность регулярно доставать какие-то сведения из 1С, чтобы интегрироваться с новыми появляющимися приложениями. Каждый раз писать отдельный сервис и заниматься публикацией было достаточно трудоемко. OData не подходит по своему замыслу, да и где строились такие запросы, это было достаточно медленно. В результате родился универсальный http-сервис в формате расширения. Весь необходимый функционал содержит внутри себя и специально не применяет типовые методы (в т.ч. БСП). В результате может устанавливаться на любую конфигурацию и публиковаться.

Первая версия содержала только справочник запросов (с перечнем параметров) и возможность эти сведения получать, после чего было решено сделать лазейку для создания новых запросов и правки имеющихся отдельным сервисом внутри. А для автоматического документирования построить swagger.

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

В настоящий момент является одним из ключевых элементов полной ИИ-разработки, запросы от новых созданных приложений генерируются с помощью ИИ и далее встраиваются в рабочую базу, отдавая корректно необходимые данные - тем самым специалисты 1С не отвлекаются на постоянные мелкие задачи интеграции.

Расширение содержит совсем небольшой набор объектов:

• Отдельную подсистему 
• Общий модуль с универсальными процедурами
• Роль для работы с расширением
• Константу, разрешающую запись новых настроек через сервис
• Справочник, хранящий настройки запросов с параметрами
• Набор http-сервисов

На справочнике и сервисах мы остановимся подробнее - это основные объекты для взаимодействия. Установка расширения в базу и публикация вебсервисов расширений стандартная, при публикации ставим флаг для расширений.

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

Справочник настроек

В справочнике хранятся настройки запросов: Наименование будет передаваться как параметр в POST запросе, лимит строк задаем на всякий случай, но если не требуется, то в тексте запроса не прописываем. На закладке Параметры прописываем набор параметров с именами и типами значений. Важный момент, что используются только примитивные типы, так как мы строим универсальный сервис, работающий с прямой обработкой входящего JSON

Сервис получения данных

При публикации получает адрес /hs/UniversalRequestService/urs

Для получения данных по конкретной настройке, в структуру JSON передаем имя и набор параметров. Например для такой настройки

вот такой JSON

{
  "setting": "BARCODE_BY_ITEM",
  "parameters": {
    "КодНоменклатуры": "12345"
  }
}

Swagger

В рамках сервисов так же публикуется и динамически собираемый Swagger: /hs/UniversalRequestAPI/swagger - доступ к нему можно получить через браузер, все активные настройки из справочника будут выведены с описанием входных параметров и примерами выходных - активные настройки видны в списке.

Сервис формирования новых настроек запросов

При установке константы Разрешить создание сервисов внешним запросом в значение Истина, начинает работать сервис /hs/UniversalRequestSynchro/UpdateService 

На входе принимается JSON с указанием:

• имени создаваемой или изменяемой настройки (name),
• родительской группы (parentName),
• описания (description),
• признака активности (active), 
• лимита строк (rowLimit),
• текста запроса (queryText)
• массива параметров с указанием имени, типа (Строка, Число, Дата, Булево) и обязательности применения

{
  "name": "Номенклатура",
  "parentName": "Интеграции",
  "description": "Поиск номенклатуры по фрагменту наименования",
  "active": true,
  "rowLimit": 100,
  "queryText": "ВЫБРАТЬ ПЕРВЫЕ &ЛимитСтрок ...",
  "parameters": [
    {
      "name": "ФрагментНаименования",
      "valueType": "Строка",
      "required": true
    }
  ]
}

Данный сервис генерирует или перезаписывает настройку с указанным именем. Это позволяет управлять активными настройками, менять и совершенствовать их не затрагивая код 1С

Помощь сервиса в преобразовании процесса разработки

Хочу отдельно описать как в нашем случае изменился подход к задачам интеграции с 1С при необходимости получить какие-то сведения.

Исходно процесс строился следующим образом:

1. Появляется задача на разработку внешнего (за рамками основной рабочей ERP) приложения
2. Обсуждается архитектура интеграции
3. Разрабатывается новый http-сервис или строится обмен с основной системой
4. Процесс тестирования разной длительности и сложности (в цикле этапы 2-3-4)
5. Запуск в эксплуатацию
6. Поддержка (в случае любых изменений сброс на этап 2)

Теперь, с учетом ИИ-разработки, наш процесс строится следующим образом:

1. Появляется задача на разработку приложения
2. ИИ с помощью MCP либо специалисты 1С готовят запрос для получения данных
3. Строится интеграция и автоматизированное тестирование
4. Запуск в эксплуатацию
5. Поддержка (в случае любых изменений ИИ достраивает запрос, обновляет настройку в базе и прогоняет тесты, проверкой занимается непосредственно разработчик или пользователь внешнего приложения, ресурсы отдела автоматизации 1С не задействуются)

Дополнительно

Код приложения открыт полностью. На 99% сгенерирован с помощью ИИ и немного по мелочам доведен и донастроен.

Спасибо.

Небольшие заметки по реальным запускам, соберу вместе:

1. Адрес сервиса получения данных: /hs/UniversalRequestService/urs

2. Swagger: /hs/UniversalRequestAPI/swagger

3. Обновление и создание сервисов (все поля обязательны, сначала в 1С создайте структуру с группами, куда класть запросы): /hs/UniversalRequestSynchro/UpdateService

4. На реальных тестах вытянули до 100.000 записей (укладываясь в 4 секунды), если вам нужно расширить лимит по количеству записей (по умолчанию 1000), то в модуле Сервиса УС_СервисСинхронизацииНастроек найти и поправить функцию ПолучитьЛимитСтрок(Данные, ИмяСвойства) и в модуле Сервиса УС_СервисЗапросов увеличить лимит в функции НормализоватьЛимитСтрок(ЛимитНастройки)

5. В некоторых случаях расширение при сохранении выдает ошибку, как будто не видит на сервере общий модуль, при этом корректно работает. Проявлялось не на всех базах и не на всех платформах, закономерности пока не выявил, может поправлю в будущих версиях или переделаю этот момент

6. При создании новых запросов, не забывайте про обязательность конструкции ВЫБРАТЬ ПЕРВЫЕ {ЛимитСтрок} - это некий компромисс, сделано обязательным, чтобы можно было административно контролировать размер выборки, а не получить что-то запредельное, от чего сервис начнет падать с ошибками. При необходимости вы можете отключить данные условия в коде (придется обработать в нескольких местах)