Веб-сервис 1С опубликован, но не отвечает: проверяем по шагам

Быстрее всего проверить публикацию веб-сервиса 1С так: откройте в браузере адрес http://<сервер>/<имя публикации>/ws/<имя файла публикации>?wsdl, например http://srv/buh/ws/Exchange.1cws?wsdl. Если после ввода логина и пароля пользователя 1С браузер показал XML с описанием операций — публикация работает. Если пришёл код 401, 403, 404 или 500, сам код уже подсказывает, где искать проблему.

Проверку удобно вести в одном порядке. Сначала конфигуратор и файл default.vrd, затем браузер и WSDL, потом тестовый вызов операции через SoapUI, curl или код на встроенном языке. Последними идут права пользователя и логи. Браузер отвечает на вопрос «опубликовано ли вообще», утилиты — «работает ли конкретный метод», логи — «почему нет».

1. Проверка публикации в конфигураторе и файле default.vrd

Начните с того, что веб-сервис есть в базе и он реально выставлен наружу.

Свойства самого веб-сервиса. В дереве конфигурации откройте Общие → Web-сервисы, затем свойства нужного сервиса. Для адреса важны два поля:

• 🔹 Имя файла публикации — например, Exchange.1cws. Именно оно стоит в URL после /ws/.
• 🔹 URI пространства имен — понадобится при вызове из SoapUI и из кода 1С.

Если сервис добавлен недавно, убедитесь, что конфигурация базы данных обновлена (Конфигурация → Обновить конфигурацию базы данных, клавиша F7). Сервис, который есть только в основной конфигурации, наружу не виден.

Диалог публикации. Откройте Администрирование → Публикация на веб-сервере. Здесь проверьте:

1. Каталог и имя публикации — имя станет первой частью пути (/buh).
2. Флажок «Публиковать Web-сервисы» на вкладке «Основные».
3. Список сервисов: нужный сервис отмечен галочкой.
4. Веб-сервер выбран тот, который реально работает на машине (IIS или конкретная версия Apache).

Файл default.vrd. Он лежит в каталоге публикации. Это главный источник правды: всё, что видит модуль веб-расширения, берётся отсюда. Фрагмент рабочей публикации выглядит так:

<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/buh"
       ib="Srvr=&quot;srv1c&quot;;Ref=&quot;buh&quot;;">
  <ws pointEnableCommon="true">
    <point name="Exchange" alias="Exchange.1cws" enable="true"/>
  </ws>
</point>

Что сверить в этом файле:

• ✅ base совпадает с путём в URL;
• ✅ ib указывает на нужную базу: для серверной — Srvr и Ref, для файловой — File с путём к каталогу базы;
• ✅ у нужного сервиса enable="true", а alias совпадает с именем файла публикации.

Если публикацию делали без конфигуратора (на Linux или скриптом), используют утилиту webinst из каталога bin платформы. Пример для Apache 2.4 на Windows:

"C:\Program Files\1cv8\8.3.24.1342\bin\webinst.exe" -publish -apache24 -wsdir buh -dir "C:\inetpub\wwwroot\buh" -connstr "Srvr=srv1c;Ref=buh;" -confPath "C:\Apache24\conf\httpd.conf"

Номер платформы в пути подставьте свой. После webinst откройте default.vrd и проверьте блок <ws>: в нём должны быть перечислены нужные сервисы.

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

Браузер — самый быстрый тест. Он не вызовет метод, но покажет, доходит ли запрос до 1С.

Откройте по очереди три адреса:

Если WSDL открылся, найдите в нём тег soap:address. Там записан адрес, на который клиент будет слать запросы. Если в нём localhost или внутреннее имя, а клиент снаружи — запросы не дойдут. Это частая причина, почему «в браузере всё открывается, а у партнёра не работает ».

Коды ответа и что за ними стоит:

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

3. Тестовый вызов методов: SoapUI, curl, Postman и код 1С

WSDL открылся — это половина дела. Теперь нужно вызвать конкретную операцию и получить ответ.

SoapUI

Самый наглядный способ для SOAP-сервисов:

1. Создайте проект File → New SOAP Project, вставьте адрес WSDL.
2. SoapUI спросит логин и пароль — укажите пользователя 1С. Если не спросил, задайте их на вкладке Auth запроса (тип Basic).
3. Раскройте операцию, откройте Request 1, заполните параметры вместо знаков ?.
4. Отправьте запрос. В правой панели будет ответ или soap:Fault с текстом ошибки 1С.

soap:Fault — хороший знак для диагностики: запрос дошёл до 1С, ошибка в логике модуля или в параметрах. Текст исключения из модуля веб-сервиса придёт прямо в ответе.

curl

Удобен на сервере без графики. Получить WSDL:

curl -u "WebUser:Pass123" -i "http://srv/buh/ws/Exchange.1cws?wsdl"

Ключ -i выводит заголовки ответа, в первой строке будет код. Вызов SOAP-операции методом POST:

curl -u "WebUser:Pass123" -i \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: \"http://example.org/exchange#Exchange:Ping\"" \
  --data @ping.xml \
  "http://srv/buh/ws/Exchange.1cws"

В файле ping.xml лежит конверт SOAP. Его проще всего не писать руками, а скопировать из SoapUI. Значение SOAPAction для конкретной операции тоже берите из WSDL (атрибут soapAction у операции).

Для HTTP-сервиса всё проще — обычный POST:

curl -u "WebUser:Pass123" -i -X POST \
  -H "Content-Type: application/json" \
  -d "{\"id\": 15}" \
  "http://srv/buh/hs/api/orders"

Postman

Подходит и для REST, и для SOAP. Для SOAP выберите метод POST, на вкладке Body — raw и тип XML, вставьте конверт. На вкладке Authorization — Basic Auth с пользователем 1С. Заголовок SOAPAction добавьте вручную.

Проверка из другой базы 1С

Если веб-сервис будут вызывать из 1С, проверьте именно так — это ближе всего к боевому сценарию:

Определения = Новый WSОпределения("http://srv/buh/ws/Exchange.1cws?wsdl", "WebUser", "Pass123");
Прокси = Новый WSПрокси(Определения, "http://example.org/exchange", "Exchange", "ExchangeSoap");
Прокси.Пользователь = "WebUser";
Прокси.Пароль = "Pass123";
Результат = Прокси.Ping();
Сообщить(Результат);

Второй параметр WSПрокси — URI пространства имен из свойств сервиса. Третий — имя сервиса, четвёртый — имя точки подключения. Точные имена сервиса и точки возьмите из WSDL: теги wsdl:service и wsdl:port. Логин и пароль задаются дважды: для чтения WSDL и для самих вызовов.

Сравнение способов:

4. Пользователь веб-сервиса и права доступа

Ошибки 401 и отказ в доступе внутри ответа — это права. Проверять их нужно на двух уровнях: в 1С и в операционной системе.

Права в 1С

1. В пользовательском режиме откройте Администрирование → Настройки пользователей и прав → Пользователи и найдите пользователя для обмена.
2. Включена «Аутентификация 1С:Предприятия», задан пароль, вход разрешён.
3. В конфигураторе откройте роль, которая выдана этому пользователю. В списке объектов найдите ваш веб-сервис в ветке Web-сервисы и проверьте право «Использование».
4. Роль должна давать права и на данные, которые читает или пишет модуль сервиса. Иначе метод вызовется, но упадёт на первом запросе к справочнику.

Для обмена удобно завести отдельного пользователя с отдельной ролью. Так проще и проверять права, и отзывать доступ.

Пользователь в default.vrd

В публикации можно прописать пользователя по умолчанию атрибутами usr и pwd в теге point. Тогда клиент заходит без пароля, а 1С работает от имени этого пользователя.

Права в операционной системе

• 🔒 IIS: учётная запись пула приложений и встроенная группа IIS_IUSRS должны иметь права на чтение каталога публикации.
• 🔒 Apache на Windows: служба работает от своей учётной записи, ей тоже нужен доступ к каталогу публикации.
• 🔒 Файловая база: та же учётная запись должна иметь права на чтение и запись в каталог базы. Иначе будет 500 с ошибкой доступа к файлу.

5. Журнал регистрации, логи веб-сервера и техжурнал

Когда код ответа не объясняет проблему, переходите к логам. Их три слоя, и смотреть стоит именно в таком порядке.

Журнал регистрации 1С

Откройте Администрирование → Обслуживание → Журнал регистрации в пользовательском режиме или Администрирование → Журнал регистрации в конфигураторе. Полезные отборы:

• 📋 по пользователю — тот, от чьего имени вызывается сервис;
• 📋 по приложению — соединения веб-сервиса и HTTP-сервиса отмечаются в журнале отдельным типом приложения;
• 📋 по уровню — «Ошибка».

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

Логи веб-сервера

В логе IIS смотрите не только код, но и подкод: 404.3 и 500.19 говорят о настройке самого IIS, а не о 1С. В error.log Apache видны ошибки загрузки модуля wsap24.

Для IIS загляните ещё в «Просмотр событий» Windows, журнал «Приложение». Туда падают ошибки модуля wsisapi.dll.

Технологический журнал

Включается файлом logcfg.xml в каталоге conf платформы. Для поиска ошибок веб-сервиса достаточно событий EXCP (исключения). Техжурнал быстро растёт, поэтому включайте его на время диагностики и задавайте срок хранения.

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\v8logs" history="2">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

6. Ошибки публикации веб-сервиса 1С и их исправление

Ниже — проблемы, которые встречаются на практике чаще остальных. Выберите свой симптом.

Ещё несколько ситуаций, которые не сразу видны в логах:

• 🔁 Изменения в модуле не применились. Модуль веб-сервиса выполняется на сервере 1С. Пока конфигурация базы данных не обновлена, работает старый код.
• 🧩 Сервис из расширения не виден. Веб-сервисы расширений публикуются отдельно: проверьте, что расширение активно и в диалоге публикации сервис из него отмечен.
• 🌐 Работает по HTTP, не работает по HTTPS. Проблема в сертификате или в привязке сайта, а не в 1С. Проверьте curl -v по https-адресу: он покажет ошибку TLS.

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