Администрирование · 10 мин
Как подключиться к веб-сервису 1С
Пошаговая инструкция: как опубликовать веб-сервис 1С на сервере, настроить права, получить WSDL и подключиться из внешнего приложения. Разбор ошибок.
Веб-сервисы 1С — это стандартный механизм обмена данными между информационной базой и внешними системами: сайтами, мобильными приложениями, другими учётными системами. Подключение строится по протоколу SOAP с описанием в формате WSDL, поэтому обращаться к сервису можно практически из любого языка программирования.
Задача решается в три этапа: публикация сервиса на веб-сервере, проверка его доступности через браузер и подключение из клиентского приложения. Каждый этап имеет свои типичные ошибки — от неправильных прав на каталог публикации до несовпадения имён в файле default.vrd.
Ниже разобран полный цикл: от подготовки веб-сервера до тестового вызова операции сервиса, а также способы диагностики, если подключение не работает.
Что нужно подготовить перед публикацией
Веб-сервис в 1С работает только через веб-сервер: напрямую «из коробки» информационная база SOAP-запросы не принимает. В качестве веб-сервера обычно используют IIS (на Windows) или Apache 2.2/2.4 (на Windows и Linux). На машине с веб-сервером обязательно должен быть установлен компонент платформы «Модули расширения веб-сервера» — он ставится из дистрибутива 1С отдельным флажком.
Второе условие — в конфигурации должен существовать сам объект «Web-сервис» с опубликованными операциями. В типовых конфигурациях часть сервисов уже есть, в собственных разработках его создают в конфигураторе: ветка «Общие» → «Web-сервисы». У сервиса задаётся пространство имён, имя и список операций с параметрами.
Третье условие — пользователь, от имени которого будет идти подключение. Этому пользователю в конфигураторе должны быть выданы права на использование веб-сервиса, и у него не должна быть снята роль, дающая доступ к данным, которые сервис читает или изменяет.
Публикация веб-сервиса на веб-сервере
Публикация выполняется из конфигуратора: меню «Администрирование» → «Публикация на веб-сервере». В открывшемся окне укажите имя публикации (оно станет частью URL), выберите веб-сервер и каталог, где будет размещён файл публикации. На вкладке «Web-сервисы» отметьте флажками сервисы, которые должны быть доступны извне, — по умолчанию они не публикуются.
После нажатия «Опубликовать» платформа создаёт в указанном каталоге файл default.vrd — это XML-файл настроек виртуального приложения. Именно в нём перечислены опубликованные веб-сервисы, путь к информационной базе и параметры подключения. Если публикация выполняется вручную или нужно поправить настройки, этот файл можно редактировать текстовым редактором.
- 1Установите веб-сервер (IIS или Apache) и модуль расширения веб-сервера 1С той же версии платформы
- 2Откройте конфигуратор от имени администратора и перейдите в «Администрирование» → «Публикация на веб-сервере»
- 3Укажите имя публикации латиницей без пробелов, выберите каталог и веб-сервер
- 4На вкладке «Web-сервисы» отметьте нужные сервисы и нажмите «Опубликовать»
- 5Проверьте, что в каталоге публикации появился файл default.vrd
- 6Перезапустите веб-сервер и проверьте доступность URL в браузере
Особенности для IIS
Для IIS проверьте, что пул приложений работает в нужной разрядности: если платформа 1С 64-разрядная, пул тоже должен быть 64-битным, иначе модуль расширения не загрузится. Учётной записи пула нужны права на чтение каталога публикации и на каталог временных файлов. Анонимную аутентификацию обычно отключают, включая базовую или Windows-аутентификацию.
Особенности для Apache
Для Apache конфигуратор автоматически добавляет секцию в файл httpd.conf. Если вы редактируете конфигурацию вручную, проверьте наличие директивы LoadModule с модулем wsap24 (для Apache 2.4) и блока <Directory> с разрешением доступа к каталогу публикации. После любых изменений httpd.conf требуется перезапуск службы Apache.
Проверка доступности сервиса
Первый тест — открыть в браузере адрес вида http://сервер/ИмяПубликации/ws/ИмяСервиса?wsdl. Если всё настроено правильно, браузер покажет XML-документ WSDL — формальное описание сервиса: его операции, типы параметров и точку подключения. Запрос WSDL обычно требует аутентификации, поэтому браузер спросит логин и пароль пользователя 1С.
Если вместо WSDL появляется ошибка, её текст — главный источник диагностики. Ошибка 404 означает, что URL неверен или публикация не создана; 401/403 — проблема с аутентификацией или правами; 500 — сбой на стороне платформы: не та версия модуля расширения, недоступна информационная база, ошибка в default.vrd.
Как проверить результат
Возвращается XML-документ с описанием сервиса
Ошибка 404, 401 или 500
Сервис возвращает SOAP-ответ с данными
SOAP Fault с текстом ошибки
Запрос выполняется под выделенной учётной записью
Ошибка доступа к данным или операции
Подключение к веб-сервису из внешнего приложения
Когда WSDL доступен, подключение из клиентского приложения сводится к созданию прокси-объекта по этому описанию. В большинстве сред разработки это автоматизировано: в Visual Studio добавляется Service Reference по URL WSDL, в Java используется wsimport, в Python — библиотеки zeep или suds. Сгенерированный прокси предоставляет методы, соответствующие операциям сервиса.
Аутентификация выполняется передачей логина и пароля пользователя 1С в HTTP-заголовках (Basic-аутентификация) или через Windows-аутентификацию, если она включена. Пароль не должен быть пустым — пустой пароль часто блокирует доступ к веб-сервисам даже при корректной настройке остального.
Пример обращения из 1С к чужому веб-сервису выглядит так: создаётся WSОпределение по URL WSDL, из него — WSПрокси с указанием пространства имён и имени сервиса, после чего вызывается нужная операция как обычный метод.
Определение = Новый WSОпределения("http://server/base/ws/Service?wsdl", "user", "password");
Прокси = Новый WSПрокси(Определение, "http://example.org/ws", "Service", "ServiceSoap");
Результат = Прокси.GetData(Параметр);Для отладки обмена удобно использовать SoapUI или Postman: они позволяют сформировать SOAP-запрос вручную, увидеть сырой XML ответа и отделить ошибки клиентского кода от ошибок самого сервиса.
Типичные ошибки и их устранение
Большинство проблем подключения относится к одной из четырёх групп: неверный URL, отсутствие прав, несовпадение версий компонентов и сетевые ограничения. Диагностику начинайте с запроса WSDL в браузере — это самый быстрый способ локализовать неисправность до обращения из кода.
Отдельный случай — файрвол и прокси. Если клиент подключается извне локальной сети, порт веб-сервера (обычно 80 или 443) должен быть открыт, а имя сервера — разрешаться в IP-адрес на стороне клиента. Проверить сетевую доступность можно простым запросом к любой странице веб-сервера с машины клиента.
Безопасность и ограничения
Веб-сервис, опубликованный без HTTPS, передаёт логин и пароль в открытом виде — при Basic-аутентификации они лишь кодируются в Base64, что не является шифрованием. Для любого обмена за пределами изолированной локальной сети настраивайте SSL-сертификат и работайте только по HTTPS.
Для интеграций заводите отдельную учётную запись с минимально необходимыми правами: только на конкретный веб-сервис и только на те данные, которые реально нужны внешней системе. Не используйте учётную запись администратора или полные права — компрометация такого пароля откроет доступ ко всей базе.
Альтернативы веб-сервисам SOAP
SOAP — не единственный способ обмена с 1С. Для новых интеграций часто удобнее HTTP-сервисы (REST-подобный обмен, обычно с JSON): они легче по трафику, проще отлаживаются и лучше подходят для мобильных приложений. Публикуются они тем же механизмом через default.vrd.
Для типовых задач интеграции с сайтами и внешними учётными системами в ряде конфигураций есть готовые механизмы: стандартный интерфейс OData (автоматический REST-доступ к объектам базы), планы обмена, подсистемы обмена данными. OData включается отдельным флажком в публикации и не требует программирования на стороне 1С.
Сравнение вариантов подключения
Строгий контракт через WSDL, подходит для интеграций с корпоративными системами; тяжеловесный формат XML
Гибкий и лёгкий обмен, удобен для сайтов и мобильных приложений; контракт нужно описывать вручную
Готовый доступ к объектам базы без кода; не подходит для сложной бизнес-логики
Асинхронная регулярная синхронизация между базами; не для запросов в реальном времени
Часто задаваемые вопросы
Как узнать точный URL опубликованного веб-сервиса?
Адрес складывается из имени сервера, имени публикации и имени сервиса: http://сервер/ИмяПубликации/ws/ИмяСервиса. Имя публикации задаётся при публикации в конфигураторе, имя сервиса — в свойствах объекта «Web-сервис». Точные значения видны в файле default.vrd в каталоге публикации.
Браузер показывает ошибку 500 при запросе WSDL. Что проверить в первую очередь?
Проверьте совпадение версии модуля расширения веб-сервера с версией платформы базы, корректность пути к информационной базе в default.vrd и доступность самой базы (не заблокирована ли она, запущен ли сервер 1С или СУБД). Текст ошибки в логах веб-сервера обычно содержит конкретную причину.
Можно ли подключиться к веб-сервису 1С без логина и пароля?
Нет, анонимный доступ к веб-сервисам 1С не предусмотрен: всегда требуется аутентификация пользователя информационной базы. Это может быть Basic-аутентификация с логином и паролем или Windows-аутентификация, если она настроена на веб-сервере.
Нужно ли перепубликовывать сервис после обновления конфигурации?
Если менялись операции, параметры или пространство имён сервиса — да, публикацию нужно обновить, чтобы default.vrd соответствовал новой структуре. При обновлении, не затрагивающем веб-сервисы, перепубликация обычно не требуется, но после обновления платформы стоит проверить версию модуля расширения веб-сервера.
Чем отличается веб-сервис от HTTP-сервиса в 1С?
Веб-сервис работает по протоколу SOAP с формальным описанием WSDL и строгим контрактом операций. HTTP-сервис обрабатывает произвольные HTTP-запросы (GET, POST и другие) и позволяет реализовать REST-подобный интерфейс с любым форматом данных, чаще всего JSON. Для новых интеграций с сайтами и мобильными приложениями HTTP-сервисы обычно удобнее.
Что важно запомнить
Подключение к веб-сервису 1С строится по схеме: публикация через конфигуратор → проверка WSDL в браузере → вызов из клиентского приложения с аутентификацией. Критичны три вещи: совпадение версий платформы и модуля веб-сервера, права пользователя на сервис и HTTPS с отдельной учётной записью для любого доступа извне.