Почему не работает веб-сервис при переходе на 1С платформу 8.3.19 и выше: разбор проблемы и способы решения

← На главную

В практике администрирования и разработки на платформе 1С:Предприятие нередко возникает ситуация, когда стабильно работавший обмен через веб-сервисы внезапно прекращает функционировать после обновления одной из сторон (клиента или сервера) на версию 8.3.19 или выше. Особенность проблемы заключается в том, что внешне всё выглядит корректно: сеанс в журнале регистрации создается, аутентификация проходит успешно, но само обращение к методам сервиса «отфутболивается» с ошибкой «Сервис не найден». При этом через браузер WSDL-описание открывается без проблем.

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

Выясним причину: почему версии 18 и 19 «не понимают» друг друга

Проанализируем ситуацию с технической точки зрения. Основная сложность заключается в том, что начиная с версии 8.3.19, разработчики 1С существенно обновили внутренние библиотеки, отвечающие за сетевое взаимодействие и работу с XML. Рассмотрим основные факторы, влияющие на разрыв соединения:

Обновление OpenSSL и протоколов TLS: Платформа перешла на ветку OpenSSL 1.1.1. Это означает отказ от старых, небезопасных наборов шифров (ciphers). Если клиентская платформа (8.3.18 и ниже) использует устаревшие алгоритмы хендшейка, сервер 8.3.19 может разорвать соединение сразу после этапа аутентификации.
Изменения в генераторе WSDL: Новые версии платформы формируют XML-описание сервиса с использованием более строгих правил именования пространств имен (namespaces). Старый парсер в платформе 8.3.18 может некорректно интерпретировать эти описания, из-за чего объект WSОпределения создается, но фактически не видит доступных методов.
Строгая проверка заголовков HTTP: В версиях 19+ ужесточились требования к соответствию заголовка Content-Type. Если старый клиент отправляет запрос, в котором кодировка или версия SOAP указаны не в том формате, который ожидает новый сервер, пакет игнорируется.
Механизмы сжатия (GZIP): Платформа 8.3.19 иначе обрабатывает сжатый контент. Нередко возникает конфликт, когда клиент запрашивает данные без сжатия, а сервер принудительно пытается отдать их в GZIP, или наоборот.

Разберем способы решения проблемы

Если мы не можем мгновенно обновить платформу на всех узлах сети, нам необходимо применить обходные пути. Рассмотрим их по порядку от простого к сложному.

Способ 1. Использование статической публикации WSDL

Часто проблема кроется именно в динамическом получении описания сервиса в момент создания WSОпределения. Мы можем исключить этот этап из сетевого взаимодействия.

Откроем браузер и перейдем по адресу вашего сервиса с параметром ?wsdl.
Сохраним полученную XML-страницу как файл на диск (например, service.wsdl).
В коде 1С на стороне клиента будем обращаться не к URL-адресу публикации, а к этому локальному файлу.

Рассмотрим пример кода:


// Вместо динамического получения:
// Определения = Новый WSОпределения("http://server/base/ws/service?wsdl", Логин, Пароль);

// Используем локальный файл:
ПутьКФайлуWSDL = "C:\WS\myservice.wsdl";
Определения = Новый WSОпределения(ПутьКФайлуWSDL, Логин, Пароль);

// При создании прокси указываем целевой URL вручную
Прокси = Новый WSПрокси(Определения, "http://www.uri.org/namespace", "ServiceName", "EndpointName");
Прокси.Пользователь = Логин;
Прокси.Пароль = Пароль;

Этот метод часто помогает, так как исключает ошибки парсинга «нового» WSDL в реальном времени и позволяет старой платформе работать с заранее подготовленной структурой.

Способ 2. Тонкая настройка файла публикации default.vrd

Посмотрим на настройки веб-сервера. Файл default.vrd управляет тем, как именно база 1С публикуется на веб-сервере (IIS или Apache). В новых версиях платформы изменилось поведение пула соединений.

Попробуем добавить или изменить параметры в секции <ws> или <point>. Нам необходимо убедиться, что параметры сессий не конфликтуют со старыми клиентами. Добавьте в файл публикации следующие атрибуты для вашего сервиса:


<point name="MyWebService"
       alias="service.1cws"
       enable="true"
       reuseSessions="autouse"
       sessionMaxAge="20"
       poolSize="10"
       poolTimeout="5"/>

Обратите особое внимание на параметр reuseSessions. Иногда переключение его в значение dontuse помогает диагностировать, не в кэшировании ли сессий дело, хотя для высоконагруженных систем это может снизить производительность.

Способ 3. Проверка и корректировка заголовков Content-Type

Если мы используем HTTPСоединение для вызова веб-сервиса (ручной формирование SOAP-запроса), проанализируем заголовки, которые мы отправляем. Новая платформа очень чувствительна к указанию кодировки.

Пример правильного формирования заголовков для SOAP 1.1:


Заголовки = Новый Соответствие();
Заголовки.Вставить("Content-Type", "text/xml; charset=utf-8");
Заголовки.Вставить("SOAPAction", "http://www.uri.org/action");

Запрос = Новый HTTPЗапрос("/base/ws/service.1cws", Заголовки);
Запрос.УстановитьТелоИзСтроки(ТекстSOAPПакета, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать);

Важный момент: убедитесь, что в теле XML-пакета в первой строке <?xml version="1.0" encoding="UTF-8"?> кодировка совпадает с той, что указана в HTTP-заголовке. Любое расхождение в 19-й платформе приведет к немедленному закрытию соединения.

Способ 4. Диагностика через SOAP UI

Чтобы окончательно выяснить, виновата ли платформа 1С или настройки веб-сервера, воспользуемся внешним инструментом, например SOAP UI.

Создадим новый проект в SOAP UI и импортируем WSDL с сервера 19-й версии.
Если SOAP UI успешно вызывает методы, значит, проблема в реализации клиента на 18-й версии 1С (её внутренней реализации HTTP-клиента).
В этом случае единственным надежным способом (кроме обновления) будет переход на использование объекта HTTPСоединение вместо WSПрокси, так как он дает больше контроля над передаваемыми данными и заголовками.

Резюме

Проблема несовместимости версий 8.3.18 и 8.3.19 — это следствие глубокой модернизации сетевого стека 1С. Основной стратегией решения является либо статическая публикация WSDL, либо переход на HTTP-запросы вместо стандартных WS-объектов, что позволяет «обмануть» строгие проверки новой платформы. Помните, что безопасность (TLS 1.2+) теперь является приоритетом, поэтому проверьте также настройки вашего веб-сервера (IIS/Apache) на предмет разрешенных протоколов шифрования.