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

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

Диагностику удобно строить по цепочке: сначала проверяется доступность самого веб-сервера, затем публикация базы, потом конкретный веб-сервис и его WSDL, и только после этого — выполнение операции с тестовыми данными. Такой порядок позволяет быстро локализовать сбой: проблема может быть в сети, в настройках IIS или Apache, в файле default.vrd или в коде самого сервиса.

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

Как устроена публикация и что именно проверяем

При публикации веб-сервиса 1С на веб-сервере (IIS или Apache) создаётся виртуальный каталог, содержащий файл default.vrd с параметрами публикации: именем базы, строкой подключения, списком публикуемых сервисов. Запросы потребителей проходят путь: HTTP-клиент → веб-сервер → модуль-расширение 1С (wsisapi.dll для IIS или модуль для Apache) → сервер 1С или файловая база → код веб-сервиса в конфигурации.

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

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

Первый шаг — убедиться, что веб-сервер вообще отвечает. Откройте в браузере корневой адрес сервера, например http://servername/. Если страница не открывается, проверьте, запущена ли служба веб-сервера (W3SVC для IIS или apache2/httpd для Apache), не занят ли порт другим приложением и не блокирует ли соединение брандмауэр.

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

curl -i http://servername/base/ws/ServiceName

Команда выше покажет HTTP-код ответа и заголовки. Код 200 или 500 с SOAP-Fault в теле означает, что запрос дошёл до расширения 1С. Код 404 говорит, что публикация или виртуальный каталог не найдены, а 502/503 — что веб-сервер не может связаться с обработчиком.

Проверка WSDL-описания сервиса

Главный тест публикации — запрос WSDL. В браузере откройте адрес вида http://servername/base/ws/ServiceName?wsdl, где ServiceName — имя веб-сервиса, заданное в конфигураторе (свойство «Имя» объекта веб-сервиса, чувствительно к регистру на некоторых конфигурациях Apache).

Нормальный результат — XML-документ, начинающийся с элемента definitions, внутри которого перечислены операции сервиса, типы данных и адрес точки вызова. Если вместо XML отображается ошибка 404, сервис не включён в публикацию или имя указано неверно. Ошибка с текстом на языке 1С (например, «Ошибка инициализации библиотеки») указывает на проблему расширения веб-сервера или недоступность базы.

Проверка выполнения операции сервиса

Полученный WSDL подтверждает только факт публикации, но не гарантирует, что операции выполняются. Для полноценной проверки нужно вызвать операцию с тестовыми параметрами. Удобнее всего это делать через SOAP-клиенты: SoapUI, Postman (с телом запроса в формате SOAP-конверта) или тестовую обработку 1С, использующую WS-ссылку на опубликованный сервис.

Сформируйте запрос к одной из операций и проанализируйте ответ. Успешное выполнение вернёт SOAP-ответ с данными. Ошибка в коде сервиса вернёт SOAP-Fault с текстом исключения из модуля веб-сервиса — это тоже полезный сигнал: публикация работает, а проблема в логике. Ошибка аутентификации (401) означает, что не настроен доступ пользователя, под которым выполняется сервис.

1. 1
   Откройте корневой адрес веб-сервера и убедитесь, что служба отвечает
2. 2
   Запросите WSDL по адресу /ws/ИмяСервиса?wsdl и проверьте наличие XML-описания
3. 3
   Выполните тестовый вызов операции через SOAP-клиент с минимальными параметрами
4. 4
   Проверьте права пользователя, под которым выполняется сервис, если получена ошибка 401
5. 5
   Изучите журналы веб-сервера и журнал регистрации 1С при любых ошибках

Диагностика по журналам и файлу default.vrd

Если сервис не отвечает, проверьте содержимое файла default.vrd в каталоге публикации. В нём должны быть корректные строка подключения к базе (параметр ib), имя публикации и элемент ws, включающий веб-сервисы (атрибут enable="true" и pointEnable для конкретного сервиса). Ручные правки файла после публикации из конфигуратора могут привести к тому, что сервис исключён из списка.

Журналы веб-сервера покажут, доходят ли запросы до сервера и какой код возвращается: для IIS это файлы в каталоге логов сайта, для Apache — access.log и error.log. Журнал регистрации 1С (отфильтрованный по событию веб-сервиса или по ошибкам) покажет, дошёл ли вызов до кода конфигурации и с какой ошибкой он завершился. Сопоставление записей по времени позволяет точно локализовать сбойное звено.

Типичные ошибки и их причины

Большинство проблем публикации сводится к нескольким повторяющимся сценариям. Знание симптомов экономит время на диагностике и позволяет сразу перейти к нужному действию, а не перебирать настройки вслепую.

Отдельная группа проблем — конфликт версий платформы. Если на сервере установлено несколько версий 1С, веб-сервер может использовать модуль расширения не той версии, что обслуживает базу. Проверьте, какая версия модуля зарегистрирована (в IIS — в сопоставлениях обработчиков, в Apache — в директиве LoadModule), и при необходимости перерегистрируйте нужную.

Проверка извне и вопросы безопасности

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

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

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