Как устроены веб-сервисы 1С и как подключить к базе внешнюю систему

Веб-сервис в 1С — это объект конфигурации, который открывает часть логики базы для внешних программ по сети: сайт, мобильное приложение или другая база вызывают метод по URL и получают ответ в XML или JSON. Работает это через веб-сервер (Apache или IIS), на котором база опубликована из Конфигуратора командой Администрирование → Публикация на веб-сервере.

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

Как веб-сервис 1С связан с базой и веб-сервером

Внешняя система не подключается к базе 1С напрямую. Между ними всегда стоит веб-сервер с модулем расширения 1С. Цепочка выглядит так:

1. 🌐 Клиент отправляет HTTP-запрос на адрес вида http://server/base/ws/... или http://server/base/hs/....
2. 🧩 Веб-сервер передаёт запрос модулю 1С (wsap24 для Apache 2.4, wsisapi.dll для IIS).
3. 📄 Модуль читает файл публикации default.vrd: в нём записано, к какой базе подключаться и какие сервисы открыты.
4. ⚙️ Модуль открывает сеанс в информационной базе — файловой или на кластере серверов 1С.
5. 📤 Выполняется процедура-обработчик из модуля сервиса, ответ уходит обратно клиенту.

Отсюда важный практический вывод. Веб-сервер и платформа должны быть одной разрядности: 64-битный Apache работает только с 64-битным модулем 1С. И модули расширения веб-сервера ставятся вместе с платформой — при установке нужно отметить компонент «Модули расширения веб-сервера». Без него публикация в Конфигураторе недоступна или Apache не стартует.

Протоколы обмена в 1С — обычный HTTP или HTTPS. Поверх них идёт либо SOAP-конверт с XML, либо произвольное тело: JSON, XML, файл.

SOAP или HTTP-сервис: какой тип веб-сервиса выбрать

В платформе 8.3 есть три способа отдать данные наружу. Два из них разработчик создаёт сам, третий платформа даёт готовым.

SOAP-сервис описан WSDL-файлом. Внешняя сторона загружает WSDL и сразу видит все операции, их параметры и типы. Плюс — строгая типизация. Минус — тяжёлый XML и сложнее вызывать из скриптов.

HTTP-сервис — это свободный REST: вы сами задаёте шаблоны адресов (/orders/{id}), методы (GET, POST, PUT, DELETE) и формат тела. Для веб-разработчиков это привычнее, а JSON легче разбирать.

OData удобен, когда нужно просто читать объекты базы. Перед использованием состав объектов, доступных через OData, задают программно методом УстановитьСоставСтандартногоИнтерфейсаOData(). Бизнес-логику (проверки, расчёты) через OData не реализовать — для этого нужен свой сервис.

Публикация базы на веб-сервере и доступ к сервисам

Перед публикацией подготовьте веб-сервер. Для Windows это чаще Apache 2.4 или IIS с включённой ролью ISAPI-расширений, для Linux — Apache.

Публикация из Конфигуратора (Windows)

1. Запустите Конфигуратор от имени администратора — иначе он не сможет записать настройки Apache и каталог публикации.
2. Откройте Администрирование → Публикация на веб-сервере.
3. Укажите имя публикации латиницей, например trade. Оно станет частью адреса: http://server/trade/.
4. Выберите веб-сервер и каталог, где появится default.vrd.
5. Отметьте нужное: публикацию Web-сервисов, HTTP-сервисов, стандартного интерфейса OData. В списках ниже снимите галочки с сервисов, которые наружу открывать не надо.
6. Нажмите «Опубликовать» и согласитесь на перезапуск веб-сервера.

Публикация на Linux

На Linux используют утилиту webinst из каталога платформы:

sudo /opt/1cv8/x86_64/8.3.25.1374/webinst -publish -apache24 \
  -wsdir trade -dir /var/www/trade \
  -connstr "Srvr=srv1c;Ref=trade;" \
  -confpath /etc/apache2/apache2.conf

Номер версии в пути подставьте свой. После команды перезапустите Apache: sudo systemctl restart apache2.

Проверка, что сервис доступен

Откройте в браузере адрес WSDL:

http://server/trade/ws/Exchange?wsdl
http://server/trade/ws/exchange.1cws?wsdl

Подойдут оба варианта: по имени сервиса или по имени файла публикации из его свойств. Если браузер показал XML-описание — SOAP-сервис работает. Для HTTP-сервиса проверьте GET-метод: http://server/trade/hs/api/ping.

Разработка методов: код сервера и клиента

SOAP-сервис: операции и параметры

В дереве конфигурации добавьте объект в ветку Общие → Web-сервисы. В свойствах заполните:

• 📌 URI пространства имён — уникальная строка, например http://example.ru/exchange;
• 📦 Пакеты XDTO — схемы типов, если передаёте сложные структуры, а не строки и числа;
• 📄 Имя файла публикации — например exchange.1cws;
• 🔁 Повторное использование сеансов и время жизни сеанса — о них ниже.

Затем добавьте операцию, укажите тип возвращаемого значения (например, xs:string) и параметры с направлением «Входной». Процедура-обработчик создаётся в модуле сервиса:

Функция ПолучитьОстаток(Артикул)
	Запрос = Новый Запрос;
	Запрос.Текст =
	"ВЫБРАТЬ
	|	ЕСТЬNULL(СУММА(Остатки.КоличествоОстаток), 0) КАК Остаток
	|ИЗ
	|	РегистрНакопления.ТоварыНаСкладах.Остатки(, Номенклатура.Артикул = &Артикул) КАК Остатки";
	Запрос.УстановитьПараметр("Артикул", Артикул);
	Выборка = Запрос.Выполнить().Выбрать();
	Выборка.Следующий();
	Возврат Формат(Выборка.Остаток, "ЧГ=0");
КонецФункции

Имя регистра здесь условное — подставьте регистр своей конфигурации. Агрегатная функция без группировки всегда возвращает одну строку, поэтому Следующий() без проверки безопасен.

Вызов такого сервиса из другой базы 1С:

Определения = Новый WSОпределения("http://server/trade/ws/Exchange?wsdl", "Обмен", "Пароль");
Прокси = Новый WSПрокси(Определения, "http://example.ru/exchange", "Exchange", "ExchangeSoap");
Прокси.Пользователь = "Обмен";
Прокси.Пароль = "Пароль";
Остаток = Прокси.ПолучитьОстаток("A-1024");

Имя точки подключения платформа формирует как имя сервиса плюс Soap (для SOAP 1.2 — Soap12). Если WSDL меняется редко, вместо загрузки по адресу создайте в конфигурации объект Общие → WS-ссылки — описание сохранится в базе.

HTTP-сервис: шаблоны и методы

В ветке Общие → HTTP-сервисы создайте сервис с корневым URL, например api. Добавьте шаблон /orders/{id} и метод GET. Обработчик возвращает объект HTTPСервисОтвет:

Функция ЗаказGET(Запрос)
	Номер = Запрос.ПараметрыURL["id"];
	Данные = Новый Структура("number, status", Номер, "в работе");

	Запись = Новый ЗаписьJSON;
	Запись.УстановитьСтроку();
	ЗаписатьJSON(Запись, Данные);

	Ответ = Новый HTTPСервисОтвет(200);
	Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
	Ответ.УстановитьТелоИзСтроки(Запись.Закрыть(), КодировкаТекста.UTF8);
	Возврат Ответ;
КонецФункции

Тело POST-запроса читают через Запрос.ПолучитьТелоКакСтроку() и разбирают ПрочитатьJSON(). Сам заказ ищите в базе по номеру — в примере данные упрощены, чтобы показать каркас.

Вызов внешнего HTTP-сервиса из 1С делают через HTTPСоединение:

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

Повторное использование сеансов

Каждый вызов без повторного использования открывает новый сеанс и занимает лицензию на время работы. При частых запросах (раз в секунду и чаще) это ощутимо грузит сервер. Значение «Автоматически» позволяет платформе держать сеанс между вызовами в пределах времени жизни. Но тогда не храните состояние в переменных модуля сеанса — следующий вызов может прийти от другого клиента в тот же сеанс.

Защита веб-сервиса: пользователи, права и HTTPS

По умолчанию веб-сервис требует Basic-аутентификацию: клиент передаёт логин и пароль пользователя информационной базы. Чтобы доступ был безопасным:

1. 👤 Заведите в базе отдельного пользователя, например «Обмен», без права интерактивного входа.
2. 🔐 Создайте роль, в которой включено право «Использование» только на нужные операции веб-сервиса или методы HTTP-сервиса, и права на чтение и запись нужных объектов.
3. 🔒 Включите HTTPS на веб-сервере. По HTTP логин и пароль идут в заголовке почти открытым текстом (Base64 — это не шифрование).
4. 🚫 В публикации оставьте только нужные сервисы. Публикацию для тонкого и веб-клиента, если она не нужна, снимите.
5. 🧱 Ограничьте доступ к адресу по IP на уровне веб-сервера или файрвола, если клиентов немного.

Анонимный доступ возможен: в default.vrd прописывают логин и пароль в атрибутах usr и pwd. Тогда любой, кто знает адрес, работает с правами этого пользователя. Используйте это только во внутренней сети и с минимальной ролью.

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

Отладка и мониторинг веб-сервисов 1С

Обработчик веб-сервиса выполняется на сервере, поэтому точка останова сама по себе не сработает. Нужна отладка по протоколу HTTP:

1. На сервере 1С (или для файловой базы — при запуске) включите режим отладки по HTTP.
2. В default.vrd добавьте элемент отладки внутри корневого point:

<debug enable="true" protocol="http" url="http://localhost:1550"/>

3. В Конфигураторе откройте Отладка → Подключение, затем «Автоматическое подключение» и отметьте сеансы веб-сервисов и HTTP-сервисов.
4. Поставьте точку останова в обработчике и вызовите сервис из Postman или SoapUI.

Для наблюдения за сервисом в работе:

• 📒 Журнал регистрации — пишите туда исключения через ЗаписьЖурналаРегистрации() в блоке Попытка ... Исключение. Так вы увидите текст ошибки, а не только код 500 у клиента.
• 📈 Технологический журнал (logcfg.xml) — показывает длительность вызовов, ошибки и блокировки на сервере.
• 🗂 Логи веб-сервера — access.log и error.log Apache или журналы IIS покажут, дошёл ли запрос до 1С вообще.
• 🧪 Postman / SoapUI — проверка сервиса в отрыве от внешней системы: если тут работает, проблема на стороне клиента.

Ошибки при вызове веб-сервиса и их причины

Код ответа сразу подсказывает, на каком звене цепочки сбой.

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