Как вызвать веб-сервис 1С

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

Технически вызов сводится к трём шагам: сервис должен быть опубликован на веб-сервере (IIS или Apache), вызывающая сторона должна знать адрес и параметры операции, а аутентификация должна пропускать запрос. Большинство проблем возникает не в коде, а именно в публикации и правах доступа.

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

Какие виды веб-сервисов есть в 1С и что выбрать

Платформа 1С:Предприятие поддерживает два механизма. Первый — классические SOAP-сервисы: они описываются в конфигураторе в ветке «Общие — Web-сервисы», автоматически генерируют WSDL-описание и подходят для интеграций, где внешняя система умеет работать с SOAP. Второй — HTTP-сервисы (ветка «Общие — HTTP-сервисы»): лёгкий вариант в стиле REST, где вы сами определяете шаблоны URL, методы (GET, POST и другие) и формат данных, обычно JSON.

Отдельно стоит стандартный OData-интерфейс: он публикуется без программирования и даёт доступ к данным объектов конфигурации через HTTP. Он удобен для чтения справочников и документов, но не заменяет полноценную бизнес-логику.

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

Без публикации веб-сервис недоступен извне: база 1С сама по себе не принимает HTTP-запросы. Публикация выполняется на веб-сервере IIS (Windows) или Apache и требует установленных компонентов веб-доступа платформы 1С.

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

1. 1
   Убедитесь, что веб-сервер (IIS или Apache) установлен и работает
2. 2
   Установите компоненты веб-доступа платформы 1С той же версии, что и сервер 1С
3. 3
   В конфигураторе откройте «Администрирование — Публикация на веб-сервере»
4. 4
   Задайте имя публикации, каталог и отметьте нужные типы сервисов
5. 5
   Нажмите «Опубликовать» и проверьте, что файл default.vrd создан
6. 6
   Откройте в браузере URL сервиса и убедитесь в ответе

Для SOAP-сервиса проверочный адрес выглядит так: http://сервер/ИмяПубликации/ws/ИмяСервиса?wsdl. Если в ответ браузер показывает XML-описание WSDL — сервис опубликован и доступен. Для HTTP-сервиса адрес формируется по шаблону: http://сервер/ИмяПубликации/hs/ШаблонURL.

Как вызвать веб-сервис 1С из внешней системы

Внешняя система обращается к опубликованному сервису как к обычному сетевому ресурсу. Для SOAP-сервиса клиент формирует XML-конверт по WSDL-описанию и отправляет его POST-запросом на адрес сервиса. Большинство языков (C#, Java, PHP, Python) умеют генерировать клиентский код по WSDL автоматически.

Для HTTP-сервиса достаточно обычного HTTP-запроса. Например, проверить сервис можно прямо из командной строки:

curl -u Пользователь:Пароль -X POST "http://server/base/hs/exchange/orders" -H "Content-Type: application/json" -d "{\"number\": \"0001\"}"

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

Как вызвать внешний веб-сервис из 1С

Обратная задача — когда 1С сама выступает клиентом. Для SOAP-сервисов удобнее всего использовать WS-ссылки: в конфигураторе добавьте объект в ветке «Общие — WS-ссылки», укажите URL WSDL-описания, и платформа создаст типизированное описание операций.

Вызов в коде выглядит так:

Определение = Новый WSОпределения("http://server/service?wsdl", "Логин", "Пароль");
Прокси = Новый WSПрокси(Определение,
"http://namespace", "ИмяСервиса", "ИмяТочкиПодключения");
Результат = Прокси.ИмяОперации(Параметр1, Параметр2);

Для произвольных HTTP-API (REST) используются объекты HTTPСоединение и HTTPЗапрос — они дают полный контроль над методом, заголовками и телом запроса:

Соединение = Новый HTTPСоединение("api.example.com", 443,,,,,
Новый ЗащищенноеСоединениеOpenSSL);
Запрос = Новый HTTPЗапрос("/v1/orders");
Запрос.Заголовки.Вставить("Authorization", "Bearer токен");
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
Данные = Ответ.ПолучитьТелоКакСтроку();
КонецЕсли;

WS-ссылка или ручное создание прокси

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

Как проверить, что вызов прошёл успешно

Признак успешного вызова SOAP-сервиса — корректный XML-ответ без блока fault. Для HTTP-сервиса ориентир — код состояния 200 (или иной, предусмотренный вашей логикой) и ожидаемое тело ответа. Коды 401 и 403 указывают на проблемы аутентификации и прав, 404 — на неверный URL или отсутствие публикации, 500 — на ошибку в коде сервиса.

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

Типичные ошибки и как их избежать

Самая частая причина неработающего вызова — несовпадение версий платформы и компонентов веб-доступа после обновления. Вторая по частоте — неправильный URL: путают имя публикации, регистр букв в имени сервиса или забывают сегмент /ws/ либо /hs/.

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

Ограничения и безопасная работа

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

Передаваемые объёмы тоже стоит ограничивать: большие двоичные данные лучше передавать частями или через отдельный обмен файлами. Для защиты от перегрузки базы полезно ограничивать частоту запросов на стороне веб-сервера и логировать обращения.

Частые вопросы