Почему WS-соединение в 1С завершается за 1 секунду без ошибок и как это исправить?

При интеграции 1С с внешними сайтами или сторонними системами через Web-сервисы разработчики нередко сталкиваются с ситуацией: сеанс создается и моментально завершается в течение одной секунды, при этом в стандартном журнале регистрации не фиксируется никаких ошибок, а управление даже не доходит до исполняемого метода веб-сервиса. Разберем причины такого поведения платформы и пошагово рассмотрим способы диагностики и устранения проблемы.

Основные причины мгновенного закрытия веб-сессии

Если в журнале регистрации появляется запись о старте и немедленном завершении сеанса без вызова целевой процедуры, проблема локализуется на уровне инициализации сессии, проверки прав или синтаксического разбора входящего пакета:

1. Ошибки XDTO-десериализации: Платформа 1С строго валидирует входящий SOAP-запрос по схеме WSDL. Если структура пакета нарушена (неверное пространство имен, некорректный тип данных, отсутствие обязательного XDTO-свойства), платформа возвращает клиенту SOAP Fault (HTTP 500 или 400). Сеанс завершается мгновенно, не передавая управление в модуль веб-сервиса, и стандартный Журнал регистрации такую ошибку не записывает.
2. Сбой в процедурах инициализации сеанса: При старте веб-сеанса вызываются процедуры УстановкаПараметровСеанса и события модуля сеанса. Если внутри этих процедур выполняется код, рассчитанный исключительно на клиентские приложения (например, обращение к несуществующим параметрам сеанса или неинициализированным переменным), соединение аварийно прерывается.
3. Недостаток прав доступа: У пользователя, под которым происходит базовая авторизация, может отсутствовать роль с правом «Использование» на данный Web-сервис или привязанные XDTO-пакеты.
4. Ограничения веб-сервера (IIS или Apache): Превышение лимитов на размер передаваемого тела запроса (директивы maxAllowedContentLength в IIS или LimitRequestBody в Apache), а также повреждения в файле публикации default.vrd.
5. Нехватка лицензий: Отсутствие свободных клиентских лицензий на сервере 1С для открытия нового веб-сеанса.

Шаг 1. Проверка доступности WSDL через браузер

Для начала проверим, корректно ли опубликован веб-сервис на веб-сервере. Откроем ссылку на WSDL-описание в браузере. Адрес формируется по следующему шаблону:

http://адрес_сервера/имя_базы/ws/ИмяВебСервиса.1cws?wsdl

Проанализируем результат обращения:

1. Если браузер запрашивает логин/пароль и после ввода отображает XML-дерево схемы WSDL — публикация выполнена успешно, права на чтение метаданных есть.
2. Если возвращаются ошибки 401 Unauthorized или 403 Forbidden — проверяем корректность логина, пароля и назначенных ролей пользователя 1С.
3. Если возвращается ошибка 404 Not Found или 500 Internal Server Error — проверяем корректность файла default.vrd и настройки обработчика модуля 1С на веб-сервере.

Шаг 2. Проверка точки входа через журнал регистрации

Чтобы точно убедиться, доходит ли выполнение до кода метода веб-сервиса, добавим явную запись в Журнал регистрации в самую первую строку исполняемой экспортной функции модуля веб-сервиса:

Функция ВыполнитьОбмен(ВходящиеДанные) Экспорт
    
    ЗаписьЖурналаРегистрации("ВебСервис.Старт", 
        УровеньЖурналаРегистрации.Информация,,, 
        "Вызов функции ВыполнитьОбмен успешно получен");
    
    // Основная логика обработки данных
    Возврат Истина;

КонецФункции

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

Шаг 3. Изолированное тестирование через SoapUI или трассировку трафика

Чтобы исключить влияние сторонней CMS или скрипта сайта, выполним прямой вызов метода через утилиту SoapUI или проанализируем сырой трафик с помощью Fiddler / Wireshark:

1. Создадим в SoapUI новый SOAP-проект, указав WSDL-ссылку сервиса.
2. Укажем авторизационные данные (Basic Auth) пользователя 1С.
3. Сформируем тестовый XML-запрос и отправим его на сервер.
4. Изучим полученный ответ: при ошибке XDTO платформа вернет подробный XML-блок <soap:Fault>, в котором будет указано конкретное поле или тип, вызвавший сбой парсинга.

Шаг 4. Настройка Технологического журнала (ТЖ) для поиска скрытых ошибок

Если SoapUI недоступен или ошибка воспроизводится только в боевом потоке данных, настроим сбор Технологического журнала. В отличие от Журнала регистрации, ТЖ перехватывает системные исключения десериализации и инициализации контекста.

Создадим или дополним файл logcfg.xml в каталоге настроек платформы 1С:

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <dump create="false"/>
    <log location="C:\Logs\1C_WS" history="24">
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <event>
            <eq property="name" value="EXCPCNTX"/>
        </event>
        <event>
            <eq property="name" value="VRSREQUEST"/>
        </event>
        <event>
            <eq property="name" value="VRSRESPONSE"/>
        </event>
        <property name="all"/>
    </log>
</config>

События VRSREQUEST и VRSRESPONSE зафиксируют точное содержимое входящего HTTP-запроса и ответ платформы, а события EXCP покажут внутреннее исключение, приведшее к мгновенному разрыву сессии.

Шаг 5. Отладка модуля сеанса

Если веб-сервер и WSDL настроены корректно, а пакет валиден, проверим процедуру инициализации сеанса:

1. В конфигураторе перейдем в меню «Отладка» -> «Подключение» и включим «Автоматическое подключение: Web-сервисы».
2. Установим точку останова в процедуре УстановкаПараметровСеанса общего модуля сеанса.
3. Повторим вызов веб-сервиса и проанализируем пошаговое выполнение инициализации параметров, обращая внимание на условия проверки типа подключения.