1С как веб-сервис: публикация и настройка интеграции

Публикация 1С как веб-сервиса — это способ открыть данные и функции информационной базы для внешних систем: сайтов, мобильных приложений, CRM, складских программ и других учётных систем. Вместо обмена файлами внешняя система обращается к 1С по сети и получает ответ в реальном времени: остатки товара, статус заказа, цены или результат проведения документа.

Платформа 1С:Предприятие поддерживает два механизма: классические SOAP веб-сервисы и более гибкие HTTP-сервисы, которые обычно используют для REST-подобных API с форматом JSON. Оба варианта работают через веб-сервер (Apache или IIS), который принимает запросы и передаёт их в базу через модуль расширения веб-сервера.

Ниже разобран практический порядок: от выбора типа сервиса до публикации, проверки доступности и защиты от типичных ошибок. Материал ориентирован на администраторов и разработчиков 1С, которые настраивают интеграцию своими силами.

Когда 1С нужно публиковать как веб-сервис

Веб-сервис оправдан, когда внешней системе нужны актуальные данные в момент обращения. Типичные сценарии: интернет-магазин запрашивает остатки и цены перед оформлением заказа, мобильное приложение торгового представителя создаёт заказ прямо в 1С, транспортная система получает статусы отгрузок, сайт проверяет контрагента по ИНН в справочнике базы.

Если данные нужны с задержкой или большими порциями — например, ночная выгрузка товаров на сайт — веб-сервис не обязателен: проще и надёжнее использовать план обмена, регламентное задание с выгрузкой в файл или механизм EnterpriseData. Веб-сервис создаёт нагрузку на базу в момент обращения, и при массовых выгрузках это становится узким местом.

Важно понимать и обратную сторону: опубликованный сервис — это точка входа в базу извне. Каждый метод, который вы открываете, потенциально доступен любому, кто доберётся до адреса публикации. Поэтому публикуют только необходимый минимум операций и обязательно настраивают авторизацию.

SOAP веб-сервисы и HTTP-сервисы: что выбрать

SOAP веб-сервисы — старший механизм платформы. Объект «Web-сервис» описывает операции с типизированными параметрами, а платформа автоматически формирует WSDL-описание, по которому внешняя система может сгенерировать клиентский код. Это удобно для интеграции с корпоративными системами, где принят SOAP, но сам протокол тяжеловесен: XML-конверты, строгая схема, сложная отладка.

HTTP-сервисы появились позже и работают проще: вы описываете шаблоны URL (например, /hs/api/stock/{sku}) и обработчики методов GET, POST, PUT, DELETE. Формат запроса и ответа полностью под вашим контролем — обычно это JSON. Такой сервис легко тестировать браузером, Postman или curl, он легче по трафику и понятнее веб-разработчикам на стороне клиента.

Для новых разработок практический выбор почти всегда — HTTP-сервис. SOAP имеет смысл, только если внешняя сторона уже рассчитана на него или требует формального WSDL-контракта.

Создание HTTP-сервиса в конфигураторе

Откройте конфигуратор и в ветке «Общие → HTTP-сервисы» добавьте новый объект. Задайте имя, например ShopAPI, и корневой URL — префикс, с которого будут начинаться все адреса сервиса, например shop. Полный адрес будет выглядеть как /ИмяПубликации/hs/shop/....

Внутри сервиса создайте шаблоны URL — они определяют маршруты. Шаблон /stock/{sku} позволит принимать запросы вида /hs/shop/stock/A12345, где часть в фигурных скобках станет параметром. Для каждого шаблона добавьте методы: GET для чтения, POST для создания и изменения данных.

Обработчик метода пишется на встроенном языке. Минимальный пример возврата остатка в JSON:

Функция stockПолучить(Запрос)
Артикул = Запрос.ПараметрыURL["sku"];
Ответ = Новый HTTPСервисОтвет(200);
Ответ.Заголовки.Вставить("Content-Type", "application/json");
// ... запрос остатка по артикулу ...
Ответ.УстановитьТелоИзСтроки(СформироватьJSON(Остаток));
Возврат Ответ;
КонецФункции

Всегда явно устанавливайте код ответа и заголовок Content-Type. Возвращайте осмысленные HTTP-коды: 200 при успехе, 400 при неверных параметрах, 404 если объект не найден, 500 при внутренней ошибке. Это сильно упрощает диагностику на стороне клиента.

Публикация на веб-сервере

Публикация требует установленного веб-сервера: Apache 2.4 или IIS — и модуля расширения веб-сервера 1С, который ставится вместе с платформой (отдельный компонент при установке). Без этого модуля веб-сервер не сможет передавать запросы в базу.

Порядок публикации через конфигуратор: меню «Администрирование → Публикация на веб-сервере». Укажите имя публикации (латиницей, без пробелов), каталог для файлов публикации, тип веб-сервера и отметьте флажки «Публиковать HTTP-сервисы» или «Публиковать Web-сервисы». После нажатия «Опубликовать» платформа создаст файл default.vrd и настройки для веб-сервера.

1. 1
   Установите веб-сервер (Apache или IIS) и модуль расширения веб-сервера 1С той же версии платформы, что и сервер 1С
2. 2
   Создайте и отладьте HTTP-сервис в конфигураторе, обновите конфигурацию базы данных
3. 3
   Откройте «Администрирование → Публикация на веб-сервере», задайте имя публикации и каталог
4. 4
   Отметьте нужные флажки публикации сервисов и нажмите «Опубликовать»
5. 5
   Перезапустите веб-сервер и проверьте доступность сервиса запросом из браузера или curl
6. 6
   Настройте HTTPS и авторизацию до открытия доступа внешним системам

Для проверки выполните GET-запрос к сервису. Ответ в виде JSON с ожидаемыми данными означает, что цепочка «веб-сервер → расширение → база» работает. Ошибка 404 указывает на неверный адрес или неопубликованный сервис, 500 — на ошибку в коде обработчика или проблему соединения с базой.

curl -u apiuser:password https://server/base/hs/shop/stock/A12345

Авторизация и безопасность

По умолчанию при обращении к сервису платформа запрашивает аутентификацию 1С: логин и пароль пользователя базы передаются в заголовке Basic-авторизации. Создайте для интеграции отдельного пользователя с минимально необходимыми правами — только чтение нужных справочников или только добавление заказов. Никогда не публикуйте сервис под полными правами.

Обязательный минимум защиты при публикации в интернет: HTTPS с действующим сертификатом (Basic-авторизация без шифрования передаёт пароль фактически открытым текстом), отдельный пользователь с узкой ролью, ограничение доступа по IP на уровне веб-сервера, если адреса вызывающих систем известны. Дополнительно в обработчике можно проверять собственный токен, передаваемый в заголовке запроса.

Проверка результата и диагностика проблем

После публикации проверьте сервис по контрольным точкам: доступность адреса, корректность ответа, поведение при ошибочных параметрах и нагрузку на базу при повторных вызовах. Тестируйте не только «успешный» сценарий, но и запросы с несуществующим артикулом, пустым телом, неверным токеном.

Если сервис недоступен, проверяйте цепочку последовательно: отвечает ли веб-сервер на простой статический запрос, существует ли файл default.vrd в каталоге публикации, совпадает ли версия модуля расширения с версией платформы, есть ли ошибки в журнале регистрации базы. Чаще всего проблема — в несовпадении версий платформы и модуля расширения или в правах доступа к каталогу публикации.

Ограничения и альтернативы

Веб-сервисы 1С — синхронный механизм: вызывающая сторона ждёт ответа, а сеанс в базе занят всё время обработки. При сотнях одновременных обращений это упирается в производительность сервера 1С и число лицензий. Для высоконагруженных сценариев (публичный API с тысячами запросов в минуту) прямую публикацию 1С обычно не используют — ставят промежуточный сервис или кэш, а 1С обновляет данные в нём по расписанию.

Альтернативы внутри экосистемы: автоматический REST-интерфейс OData для чтения данных без программирования, обмен через брокер сообщений (RabbitMQ, Kafka) для асинхронных интеграций, механизм EnterpriseData для обмена между конфигурациями 1С. Для файловых баз публикация веб-сервисов возможна, но при интенсивных вызовах файловый режим быстро становится узким местом — для серьёзных интеграций нужен клиент-серверный вариант.

Часто задаваемые вопросы