Web-сервис 1С опубликован, но работает ли он: проверка от WSDL до мониторинга

Быстрее всего проверить публикацию web-сервиса 1С так: откройте в браузере адрес http://сервер/имя_публикации/ws/ИмяСервиса.1cws?wsdl и введите логин и пароль пользователя базы. Пришёл XML с описанием операций — публикация на веб-сервере работает, модуль 1С загружен, база доступна. Ошибка или пустая страница — по коду ответа сразу понятно, где искать.

WSDL доказывает только одно: сервис опубликован. Чтобы убедиться, что он реально отвечает на запросы, нужен тестовый вызов операции через Postman, curl или SoapUI. Всё описанное относится к платформе 8.3 и не зависит от конфигурации: БП, УТ, ERP или самописная база проверяются одинаково.

Что подготовить перед проверкой публикации web-сервиса

Соберите пять вещей. Без них проверка превращается в угадывание.

• 🌐 Адрес публикации. Имя виртуального каталога, которое вы указали при публикации (например, trade). Полный адрес: http://srv1c/trade/.
• 🏷️ Имя web-сервиса. Смотрите в Конфигураторе: ветка Общие → Web-сервисы. Там же в свойствах — URI пространства имён, он понадобится для запроса.
• 👤 Технический пользователь. Отдельная учётная запись в базе с аутентификацией 1С:Предприятия и правами только на нужные данные. Логин лучше латиницей: с кириллицей в Basic-авторизации у части клиентов бывают проблемы с кодировкой.
• 📄 Файл default.vrd. Лежит в каталоге публикации. По нему видно, какие сервисы реально опубликованы.
• 🧪 Безопасная операция. Идеально — Ping или GetVersion, которая ничего не пишет в базу. Если её нет, попросите разработчика добавить. Она отделяет проблемы инфраструктуры от ошибок в коде.

Откройте default.vrd блокнотом. Нужный фрагмент выглядит так:

<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       base="/trade"
       ib="Srvr=&quot;srv1c&quot;;Ref=&quot;trade&quot;;">
  <ws pointEnableCommon="true">
    <point name="Exchange" alias="Exchange.1cws" enable="true"/>
  </ws>
</point>

Значение alias и есть хвост адреса после /ws/. Если вашего сервиса нет в списке или у него enable="false", дальше можно не проверять: откройте в Конфигураторе Администрирование → Публикация на веб-сервере, отметьте сервис на вкладке web-сервисов и опубликуйте заново.

Какой инструмент брать на каком этапе:

Шаг 1. Проверка опубликованного web-сервиса в браузере

Откройте три адреса по очереди. Каждый проверяет свой слой.

1. http://srv1c/trade/ — если при публикации включён тонкий и веб-клиент, откроется окно входа в базу. Значит, веб-сервер видит публикацию и модуль 1С загружается.
2. http://srv1c/trade/ws/Exchange.1cws?wsdl — браузер спросит логин и пароль. После ввода должен появиться XML, который начинается с <definitions и содержит ваши операции.
3. Для HTTP-сервисов (не SOAP) адрес другой: http://srv1c/trade/hs/<корневой URL>/<шаблон>. Корневой URL задан в свойствах HTTP-сервиса. Браузер умеет только GET, поэтому так проверяется лишь метод GET.

Что означает результат:

• ✅ XML с операциями — публикация в порядке, переходите к тестовому вызову.
• 🔒 Окно авторизации появляется снова и снова — неверный логин или пароль, либо у пользователя не включена аутентификация 1С:Предприятия.
• ❌ 404 — веб-сервер не знает такого адреса: ошибка в имени публикации, в alias или сервис не опубликован.
• 💥 500 — до 1С запрос дошёл, но упал на стороне платформы. Подробности будут в логах.

Шаг 2. Тестовый вызов операции через Postman и curl

WSDL открылся — теперь вызовите операцию. Для SOAP-сервиса 1С запрос отправляется методом POST на адрес без ?wsdl.

Настройка запроса в Postman:

1. Метод POST, адрес http://srv1c/trade/ws/Exchange.1cws.
2. Вкладка Authorization: тип Basic Auth, логин и пароль технического пользователя.
3. Вкладка Headers: Content-Type: text/xml; charset=utf-8. Для SOAP 1.1 добавьте SOAPAction — точное значение для операции указано в WSDL в атрибуте soapAction.
4. Вкладка Body: режим raw, вставьте конверт SOAP.

Пример конверта для операции Ping с пространством имён http://example.org/exchange:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:ex="http://example.org/exchange">
  <soap:Header/>
  <soap:Body>
    <ex:Ping/>
  </soap:Body>
</soap:Envelope>

Пространство имён в конверте должно совпадать с URI пространства имён из свойств web-сервиса. Это самая частая причина, по которой WSDL открывается, а вызов возвращает ошибку о неизвестной операции.

Тот же запрос из командной строки. curl есть в Windows 10, 11 и Windows Server 2019 и новее:

curl -u monitor:Pa55word -H "Content-Type: text/xml; charset=utf-8" ^
  --data-binary @ping.xml http://srv1c/trade/ws/Exchange.1cws

Для HTTP-сервиса всё проще — конверт не нужен:

curl -u monitor:Pa55word -i http://srv1c/trade/hs/api/ping

Ключ -i выводит заголовки ответа. Так видно код статуса, даже если тело пустое.

Шаг 3. Проверка SOAP-сервиса в SoapUI

Postman удобен для одной-двух операций. Когда операций много и в них сложные XDTO-типы, собирать конверты руками долго. SoapUI делает это сам по WSDL.

1. File → New SOAP Project.
2. В поле Initial WSDL вставьте адрес http://srv1c/trade/ws/Exchange.1cws?wsdl. Если SoapUI попросит авторизацию для загрузки WSDL — введите учётные данные.
3. SoapUI создаст дерево: привязки ExchangeSoap и ExchangeSoap12, под ними все операции с готовыми запросами Request 1.
4. Откройте запрос, внизу нажмите Auth, выберите Basic, введите логин и пароль. Включите Authenticate pre-emptively — тогда заголовок авторизации уйдёт сразу, без лишнего круга с кодом 401.
5. Замените знаки ? в теле на тестовые значения и отправьте запрос зелёной стрелкой.

Чем SoapUI полезен сверх Postman:

• 🔍 подсвечивает, если ответ не соответствует схеме из WSDL — так ловятся ошибки в типах XDTO;
• 🧩 позволяет собрать тестовый набор (TestSuite) из нескольких вызовов с проверками (Assertions) и запускать его одним кликом после каждого обновления конфигурации;
• 📊 показывает время ответа каждого вызова.

Где смотреть логи, если web-сервис 1С не отвечает

Код ответа говорит, на каком слое проблема. Логи говорят, что именно сломалось.

Apache. Логи лежат в каталоге logs внутри папки Apache, например C:\Apache24\logs:

• access.log — пришёл ли запрос и какой код вернулся;
• error.log — ошибки загрузки модуля 1С и конфигурации.

Перед перезапуском Apache проверьте синтаксис конфигурации — это сэкономит время на поисках:

C:\Apache24\bin\httpd.exe -t

Правильная публикация в httpd.conf выглядит примерно так:

LoadModule _1cws_module "C:/Program Files/1cv8/8.3.xx.xxxx/bin/wsap24.dll"
Alias "/trade" "C:/inetpub/wwwroot/trade/"
<Directory "C:/inetpub/wwwroot/trade/">
    AllowOverride All
    Options None
    Require all granted
    SetHandler 1c-application
    ManagedApplicationDescriptor "C:/inetpub/wwwroot/trade/default.vrd"
</Directory>

Проверьте, что путь к wsap24.dll ведёт на установленную версию платформы. После обновления 1С старая папка удаляется, и Apache перестаёт стартовать.

IIS. Журналы — в C:\inetpub\logs\LogFiles\W3SVC<номер сайта>. В строке запроса после кода статуса идёт подстатус (например, 404 0, 500 19) — по нему ошибку IIS легко найти в документации Microsoft.

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

Технологический журнал. Когда ничего выше не помогает, включите сбор исключений. Создайте файл logcfg.xml в каталоге conf установленной платформы (например, C:\Program Files\1cv8\conf):

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

Повторите вызов и откройте свежие файлы в C:\techlog. После диагностики удалите logcfg.xml: журнал растёт быстро и может занять весь диск.

Ошибки при проверке публикации и что с ними делать

Выберите симптом — подсказка покажет причину и порядок действий.

Проверка доступа к web-сервису из внешней сети

Сервис отвечает на сервере, но партнёр его не видит. Проверяйте по цепочке, от сервера наружу.

1. С самого сервера — http://localhost/trade/ws/Exchange.1cws?wsdl. Работает — веб-сервер и 1С в порядке.
2. С другого компьютера в локальной сети — по имени и по IP. Если по IP работает, а по имени нет, это DNS. Если не работает никак — брандмауэр Windows: откройте входящий порт 80 или 443.
3. Из интернета — с телефона через мобильную сеть, не через офисный Wi-Fi. Иначе вы проверите локальную сеть ещё раз.
4. Проброс порта на роутере или межсетевом экране — внешний 443 на внутренний адрес веб-сервера.
5. Адрес в WSDL. Внутри WSDL в элементе soap:address указан адрес, по которому клиенту предлагается вызывать сервис. Если там внутреннее имя srv1c, внешний клиент, построенный по WSDL, будет стучаться туда и не достучится. Клиенту в этом случае нужно явно задать внешний адрес точки подключения.

Для публикации в интернет обязательны три вещи:

• 🔐 HTTPS. Basic-авторизация по HTTP передаёт пароль фактически открытым текстом. Сертификат — коммерческий или Let’s Encrypt.
• 🙅 Без логина и пароля в default.vrd. В элементе point можно прописать учётные данные, чтобы сервис пускал без авторизации. Наружу так публиковать нельзя: любой, кто узнал адрес, получит доступ к данным.
• 🧱 Отдельный пользователь с минимальными правами. Только чтение тех данных, которые нужны обмену.

Автоматическая проверка: скрипт мониторинга и вызов из 1С

Ручная проверка нужна один раз. Дальше сервис должен проверяться сам, иначе о падении вы узнаете от партнёра.

Скрипт PowerShell. Запрашивает WSDL и пишет в лог, если ответ не пришёл или пришёл не тот:

$url  = "http://srv1c/trade/ws/Exchange.1cws?wsdl"
$pair = "monitor:Pa55word"
$b64  = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($pair))
try {
    $r = Invoke-WebRequest -Uri $url -Headers @{ Authorization = "Basic $b64" } `
         -UseBasicParsing -TimeoutSec 15
    if ($r.Content -notmatch "definitions") { throw "Ответ не похож на WSDL" }
} catch {
    Add-Content -Path "C:\monitor\ws.log" `
        -Value "$(Get-Date -Format s) СБОЙ: $($_.Exception.Message)"
}

Повесьте его в Планировщик заданий Windows с повтором каждые 5–10 минут. Вместо записи в файл можно отправлять письмо или сообщение в мессенджер — это пара строк в блоке catch.

Проверка средствами 1С. Из другой базы или обработки сервис вызывается через WSОпределения и WSПрокси. Это заодно проверяет, что WSDL корректно читается клиентом 1С:

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

Второй и третий параметры конструктора WSПрокси — URI пространства имён и имя сервиса, четвёртый — имя точки подключения из WSDL. Оформите код в регламентное задание — и база-клиент сама будет проверять доступность сервиса.

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