Обороткабаза знаний по 1С 8.3

Проверка web-сервиса 1С после публикации: WSDL, тестовый вызов, отладка

· 11 мин

Содержание

Опубликованный web-сервис 1С проверяют в два хода. Сначала открывают в браузере адрес http://сервер/имя_публикации/ws/имя_сервиса?wsdl: если после ввода логина и пароля пришёл XML с описанием операций, публикация работает. Затем делают настоящий вызов операции — из 1С через WSПрокси, из SoapUI, Postman или curl — и смотрят, что вернул модуль сервиса.

Частое заблуждение: «WSDL открылся — значит, сервис работает». Это не так. WSDL отдаёт веб-расширение 1С по метаданным, код модуля при этом не выполняется. Ошибка в модуле, нехватка прав или лицензий вылезут только при вызове операции. Поэтому проверка опубликованного web-сервиса 1С всегда заканчивается тестовым запросом.

Всё ниже относится к платформе 8.3 и не зависит от конфигурации: БП, ЗУП, УТ или своя разработка публикуют web-сервисы одинаково.

Подготовка: что проверить в публикации до первого запроса

Большая часть «не работает » решается ещё до запросов. Пройдитесь по списку.

Сервис есть в конфигурации базы данных

Web-сервис добавляют в ветке Общие → Web-сервисы дерева конфигурации. После этого конфигурацию нужно не просто сохранить, а обновить: Конфигурация → Обновить конфигурацию базы данных (F7). Пока основная конфигурация не применена к базе, веб-сервер про новый сервис не знает.

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

Публикация делается из Конфигуратора, запущенного от имени администратора Windows: Администрирование → Публикация на веб-сервере. На закладке Web-сервисы проверьте:

  • ✅ флажок публикации web-сервисов включён;
  • ✅ нужный сервис отмечен в списке;
  • ✅ в колонке адреса видно имя файла, например exchange.1cws.

Если сервис добавили в конфигурацию после публикации, откройте этот диалог заново, отметьте сервис и нажмите Опубликовать. Для Apache после каждой публикации нужен перезапуск службы веб-сервера.

Перезапуск Apache или IIS обрывает все текущие подключения через этот веб-сервер: веб-клиент, другие сервисы, мобильные приложения. Делайте это вне рабочего времени или предупредите пользователей.

Файл default.vrd

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

<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>

Здесь видно три вещи: имя публикации (base), строку подключения к базе (ib) и сервис с флагом enable. Если сервиса в списке нет или стоит enable="false", вызов не дойдёт до 1С.

Права пользователя 1С

Web-сервис вызывается от имени пользователя информационной базы. Заведите для интеграции отдельного пользователя с паролем и латинским логином, например ws_exchange. Кириллица в логине при базовой HTTP-аутентификации часто ломается на стороне внешней системы — запрос уходит в другой кодировке, и 1С пользователя не находит.

Пользователю нужны права на все объекты, которые читает или пишет код операции. Отдельного «права на web-сервис» для запуска самой операции нет, а вот на справочники и документы — есть.

Доступ веб-сервера к базе

Для файловой базы учётная запись, под которой работает веб-сервер, должна иметь права на чтение и запись каталога базы. Для IIS это обычно IUSR и пользователи пула приложений, для Apache под Windows — учётная запись службы. Для клиент-серверной базы проверьте, что с машины веб-сервера доступен сервер 1С по портам агента и менеджера кластера (по умолчанию 1540 и 1541) и диапазону портов рабочих процессов.

Шаг 1. Открываем WSDL опубликованного web-сервиса в браузере

Адрес собирается из трёх частей:

ЧастьПримерОткуда взять
Серверhttp://srv-webимя или IP машины с Apache/IIS
Имя публикации/tradeполе «Имя» в диалоге публикации, атрибут base в vrd
Сервис/ws/exchange.1cws или /ws/Exchangeадрес файла или имя сервиса в конфигурации

Полный адрес: http://srv-web/trade/ws/exchange.1cws?wsdl. Браузер спросит логин и пароль — введите пользователя 1С.

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

  • 📄 XML с корнем definitions — веб-сервер, расширение 1С и аутентификация работают;
  • 🔒 повторный запрос пароля или 401 — неверный логин, пароль или у пользователя не задан пароль, а внешняя система его передаёт;
  • ❓ 404 — неверное имя публикации или сервиса, либо сервис не отмечен при публикации;
  • 💥 500 с текстом ошибки 1С — веб-расширение не смогло подключиться к базе (права на каталог, сервер 1С недоступен, нет лицензии).

Что смотреть внутри WSDL

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

  1. targetNamespace — должно совпадать с «URI пространства имен» в свойствах сервиса. Если интегратор жалуется «не тот namespace», ответ здесь.
  2. operation — список операций. Если новой операции нет, конфигурация базы данных не обновлена.
  3. types — типы параметров и возврата. Параметр типа string вместо ожидаемой XDTO-структуры значит, что в свойствах параметра указан не тот тип.
  4. soapAction в секции binding — это значение нужно передавать в заголовке при ручном вызове по SOAP 1.1.
  5. address location в секции service — адрес, куда клиенты будут слать запросы.

Если сервис опубликован за прокси или NAT, в address location может оказаться внутренний адрес. Внешние клиенты, которые строят прокси по WSDL, будут стучаться туда и получать таймаут. В SoapUI и Postman адрес вызова можно поправить вручную.

Шаг 2. Тестовый вызов web-сервиса прямо из 1С

Самый быстрый способ проверить сервис изнутри — внешняя обработка с одной командой. Запускать её можно из любой базы, даже из той же самой. Код на сервере:

&НаСервере
Процедура ПроверитьСервисНаСервере()

    АдресWSDL = "http://srv-web/trade/ws/exchange.1cws?wsdl";
    Пользователь = "ws_exchange";
    Пароль = "пароль";

    Определения = Новый WSОпределения(АдресWSDL, Пользователь, Пароль);
    Прокси = Новый WSПрокси(Определения,
        "http://www.example.org/exchange", // URI пространства имен сервиса
        "Exchange",                        // имя сервиса
        "ExchangeSoap");                   // имя точки подключения
    Прокси.Пользователь = Пользователь;
    Прокси.Пароль = Пароль;

    Попытка
        Ответ = Прокси.Ping("тест");
        Сообщить("Ответ сервиса: " + Строка(Ответ));
    Исключение
        Сообщить("Ошибка вызова: " + ОписаниеОшибки());
    КонецПопытки;

КонецПроцедуры

Пояснения к коду:

  • 🔹 WSОпределения скачивает и разбирает WSDL — если здесь ошибка, проблема в публикации или авторизации, а не в операции;
  • 🔹 имя точки подключения у сервисов 1С строится как имя сервиса плюс Soap (SOAP 1.1) или Soap12; точное значение — атрибут name у элемента port в WSDL;
  • 🔹 Ping — имя операции из WSDL; параметры передаются как в обычную функцию;
  • 🔹 текст исключения содержит сообщение, которое вызвал код модуля сервиса — это первая подсказка при отладке.

Для постоянной интеграции вместо WSОпределения удобнее загрузить описание в конфигурацию: ветка Общие → WS-ссылки, команда добавления по адресу WSDL. Затем прокси создаётся одной строкой: WSСсылки.Exchange.СоздатьWSПрокси(ПространствоИмен, "Exchange", "ExchangeSoap"). Для разовой проверки внешняя обработка проще: она не меняет конфигурацию.

Шаг 3. Проверка web-сервиса 1С через SoapUI, Postman и curl

Сторонний клиент нужен, чтобы увидеть ровно то, что увидит внешняя система: сырой SOAP-конверт, заголовки, код ответа.

SoapUI

  1. Создайте проект: File → New SOAP Project.
  2. В поле Initial WSDL вставьте адрес с ?wsdl. Если WSDL закрыт паролем, сначала сохраните его из браузера в файл и укажите путь к файлу.
  3. SoapUI создаст шаблоны запросов для каждой операции. Откройте нужный, заполните параметры вместо ?.
  4. Внизу окна запроса откройте вкладку авторизации, выберите Basic, введите логин и пароль, включите упреждающую отправку (Authenticate pre-emptively).
  5. Отправьте запрос зелёной стрелкой. Справа появится ответ, на вкладке Raw — HTTP-код и заголовки.

Postman

Postman не строит запросы по WSDL так удобно, как SoapUI, зато привычен многим разработчикам.

  • метод POST, адрес без ?wsdl: http://srv-web/trade/ws/exchange.1cws;
  • вкладка Authorization → Basic Auth;
  • заголовок Content-Type: text/xml; charset=utf-8 для SOAP 1.1 или application/soap+xml; charset=utf-8 для SOAP 1.2;
  • для SOAP 1.1 добавьте заголовок SOAPAction со значением из WSDL;
  • тело — raw, тип XML, SOAP-конверт.

curl

Удобно для проверки прямо с сервера, где нет графического интерфейса. Сохраните конверт в файл ping.xml:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:ex="http://www.example.org/exchange">
  <soap:Body>
    <ex:Ping>
      <ex:Text>тест</ex:Text>
    </ex:Ping>
  </soap:Body>
</soap:Envelope>

И вызовите:

curl -i -u ws_exchange:пароль \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: <значение soapAction из WSDL>" \
  --data-binary @ping.xml \
  http://srv-web/trade/ws/exchange.1cws

Ключ -i выводит заголовки ответа: сразу видно код 200, 401 или 500. Имена элементов внутри Ping — это имена параметров операции, как они указаны в WSDL.

ИнструментКогда братьОграничения
Обработка в 1Спроверка «1С — 1С», быстроне показывает сырой XML
SoapUIразбор WSDL, шаблоны запросовтяжёлый, нужна Java
Postmanесли команда уже им пользуетсяконверт пишется руками
curlпроверка с сервера, скриптывсё вручную, нужен шаблон конверта

Шаг 4. Отладка модуля web-сервиса в Конфигураторе

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

  1. Разрешите отладку в публикации. В default.vrd внутри элемента point добавьте строку и перезапустите веб-сервер:
<debug enable="true" protocol="tcp" url="tcp://srv-debug"/>

Здесь srv-debug — машина, где открыт Конфигуратор. Если отладка в базе настроена по протоколу HTTP, укажите protocol="http" и адрес сервера отладки. 2. В Конфигураторе откройте Отладка → Подключение, нажмите Автоматическое подключение и отметьте тип Сеанс Web-сервиса. 3. Поставьте точку останова в процедуре операции модуля сервиса. 4. Отправьте запрос из SoapUI или обработки. Выполнение остановится на точке, дальше — пошагово, как в обычном коде.

Не оставляйте debug enable="true" в рабочей публикации. Отладка замедляет обработку запросов, а открытый порт отладки — лишняя дверь в базу. После проверки удалите строку и перезапустите веб-сервер в нерабочее время.

Когда клиент ждёт дольше таймаута

Пока вы стоите на точке останова, внешняя система не получает ответа. SoapUI и Postman по умолчанию ждут минуту и рвут соединение. Для долгой отладки увеличьте таймаут в настройках клиента или отлаживайте через обработку из Шага 2 — у конструктора WSПрокси есть параметр Таймаут в секундах.

Шаг 5. Где искать следы вызова: журнал регистрации и логи

Отладчик подключать не всегда можно, особенно на рабочей базе. Тогда идут по логам.

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

Откройте журнал в режиме Предприятия или в Конфигураторе (Администрирование → Журнал регистрации). Отфильтруйте по пользователю интеграции и по приложению Web-сервис. Видно:

  • 🟢 события начала и завершения сеанса — вызов дошёл до базы;
  • 🔴 ошибки с текстом исключения и модулем, где оно возникло;
  • 📝 записи, которые вы сами пишете кодом через ЗаписьЖурналаРегистрации().

Последний пункт — главный приём для боевых сервисов. Пишите в журнал входящие параметры и результат каждой операции с отдельным именем события, например Обмен.Входящий. Через месяц, когда партнёр скажет «мы отправили, а у вас пусто», вы откроете журнал и увидите, приходил ли запрос.

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

Если в журнале регистрации пусто, запрос не дошёл до 1С. Смотрите логи веб-сервера:

  • Apache — error.log и access.log в каталоге logs установки Apache;
  • IIS — C:\inetpub\logs\LogFiles, а также журнал событий Windows.

В access.log видно, был ли запрос и с каким кодом ответил сервер. В error.log — ошибки загрузки модуля 1С.

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

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

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

Диагностика: выберите симптом

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

Если сервис вызывают часто, каждый вызов открывает новый сеанс 1С: это расход лицензий и времени на старт. В default.vrd у элемента ws есть атрибут reuseSessions. Значение autouse включает пул сеансов. Рядом задают sessionMaxAge — сколько секунд живёт неиспользуемый сеанс — и poolSize.

<ws pointEnableCommon="true" reuseSessions="autouse" sessionMaxAge="20" poolSize="10">

Учтите: при повторном использовании сеанс один на несколько вызовов, и значения, которые код запоминает в переменных модуля сеанса, переходят между запросами разных клиентов.

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

Можно ли проверить web-сервис 1С без веб-сервера?
Нет. Web-сервисы 1С отдаёт только веб-расширение платформы через Apache или IIS. Без публикации на веб-сервере адреса с /ws/ не существует, даже для файловой базы.
Чем проверка web-сервиса отличается от проверки HTTP-сервиса?
У HTTP-сервиса нет WSDL. Его адрес содержит /hs/ вместо /ws/, а запрос шлют обычным GET или POST с телом в JSON или XML. Проверяют так же: Postman или curl, журнал регистрации, отладка с типом «Сеанс HTTP-сервиса».
Можно ли вызывать сервис без логина и пароля?
Можно прописать пользователя и пароль в публикации, тогда веб-расширение подставит их само. Делать так стоит только во внутренней сети: любой, кто знает адрес, получит доступ к операциям сервиса.
Почему из браузера на сервере всё работает, а с другого компьютера нет?
Чаще всего мешает брандмауэр на машине веб-сервера или в WSDL указан адрес localhost. Проверьте, что порт 80 или 443 открыт снаружи, и вызывайте сервис по сетевому имени.
Нужно ли публиковать сервис заново после изменения кода операции?
Нет. Достаточно обновить конфигурацию базы данных. Повторная публикация нужна, когда добавлен новый web-сервис или меняются настройки публикации.