Как просмотреть и проанализировать XML-сообщение, формируемое 1С при вызове метода Web-сервиса?

← На главную

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

Использование внешних инструментов мониторинга трафика

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

Fiddler. Это прокси-сервер, который перехватывает весь HTTP/HTTPS трафик. Разберем алгоритм работы: если база файловая и запущена локально, Fiddler автоматически подхватит запрос. Если же работа ведется в клиент-серверном варианте, вызов WSПрокси происходит на стороне сервера 1С. В этом случае мы рекомендуем временно запустить обработку в файловой копии базы на локальном компьютере, где установлен Fiddler.
SoapUI. Этот инструмент позволяет не просто перехватывать трафик, но и полностью эмулировать поведение Web-сервиса. Мы можем импортировать WSDL-ссылку в SoapUI, создать Mock Service (заглушку) и направить вызов из 1С на адрес этого локального сервиса. Так мы увидим входящий XML во всех деталях.
Postman. Хотя он чаще используется для REST API, в нем также можно тестировать SOAP-запросы. Проанализируем ситуацию: если вы получили структуру XML через другие средства, в Postman можно вручную подставлять разные параметры, чтобы найти «битый» узел или неверное пространство имен.

Логирование средствами платформы (EnableInternetExchangeLog)

Рассмотрим малодокументированный, но крайне эффективный встроенный механизм платформы 1С. Существует специальный флаг в конфигурационном файле conf.cfg, который заставляет платформу записывать все исходящие и входящие пакеты в текстовые файлы логов. Это идеальное решение, если на сервере запрещено устанавливать стороннее ПО.

Выполним следующие шаги для настройки:

Найдем файл conf.cfg. Обычно он располагается в каталоге установки платформы (например, C:\Program Files\1cv8\conf) или в папке профиля пользователя.
Добавим в него строку: EnableInternetExchangeLog=1.
После перезапуска сеанса 1С платформа начнет создавать лог-файлы. Проанализируем их содержимое — там будет представлен «сырой» SOAP-конверт, включая HTTP-заголовки и все объявленные пространства имен (namespaces).

Важно: Не забудьте отключить этот параметр после завершения отладки, так как файлы логов могут очень быстро занять все свободное дисковое пространство при интенсивном обмене.

Настройка Технологического журнала (logcfg.xml)

Технологический журнал — это самый мощный инструмент для системного администратора и разработчика 1С. С его помощью мы можем получить данные о сетевом обмене непосредственно в момент исполнения программного кода на сервере.

Для перехвата Web-вызовов нам нужно настроить сбор событий HTTP или SCOM. Пример настройки файла logcfg.xml для сбора данных об обмене может выглядеть следующим образом:


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\Logs\WebExchange" history="24">
        <event>
            <eq property="Name" value="HTTP"/>
        </event>
        <property name="All"/>
    </log>
</config>

Проанализируем результаты: в логах появятся записи, содержащие тело запроса и ответа. Кстати, для автоматической обработки собранных данных вам может пригодиться знание о том, как убрать лишние переносы строк в технологическом журнале, что значительно упростит парсинг. Это позволит нам увидеть точно ту структуру XML, которую генерирует WSПрокси, и сопоставить её с требованиями WSDL-схемы.

Переход от WSПрокси к ручному формированию HTTP-запроса

Выясним причину, по которой многие опытные разработчики предпочитают отказываться от использования объекта WSПрокси в пользу HTTPСоединение. Если вы еще не работали с этим напрямую, рекомендуем пройти интерактивный обучающий курс для работы с HTTP-запросами для понимания основ. Когда мы работаем с прокси-объектом, мы доверяем платформе автоматическую сериализацию объектов XDTO в XML. Если в схеме WSDL есть нюансы с пространствами имен, 1С может сформировать некорректный XML.

Разберем, как реализовать «прозрачный» вызов, где мы будем видеть каждое сообщение прямо в отладчике перед отправкой:

Используем объект ЗаписьXML для создания структуры сообщения.
Используем СериализаторXDTO для преобразования объектов в XML.
Формируем SOAP-конверт вручную как обычную строку или через ЗаписьXML.

Посмотрим на пример кода, который позволяет получить XML-строку объекта XDTO:


// Предположим, у нас есть ОбъектXDTO, который мы хотим отправить
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.УстановитьСтроку();
СериализаторXDTO.ЗаписатьXML(ЗаписьXML, ДанныеXDTO, НазначениеТипаXML.Явное);
СтрокаXML = ЗаписьXML.Закрыть();
// Теперь переменная СтрокаXML доступна для анализа в отладчике

После этого мы отправляем эту строку через HTTPЗапрос. Преимущество метода очевидно: вы полностью контролируете содержимое пакета и можете логировать его в любой справочник или текстовый файл внутри 1С.

Создание собственного прокси-сервиса на 1С

Если нам нужно увидеть сообщение, которое формирует именно WSПрокси, но мы не можем использовать внешние инструменты, мы можем заставить 1С отправить запрос самой себе. Рассмотрим этот оригинальный метод:

В текущей базе 1С создаем простейший HTTP-сервис.
В методе POST этого сервиса пишем код, который считывает тело запроса и записывает его в Журнал регистрации или в текстовый файл на сервере.
В коде вызова WSПрокси временно меняем адрес точки подключения (URL) на адрес нашего нового HTTP-сервиса.

Пример кода в HTTP-сервисе для перехвата сообщения:


Функция ПерехватСообщения(Запрос)
    ТелоЗапроса = Запрос.ПолучитьТелоКакСтроку();
    ЗаписьЖурналаРегистрации("ОтладкаWebСервиса",,,, ТелоЗапроса);
    
    Ответ = Новый HTTPСервисОтвет(200);
    Возврат Ответ;
КонецФункции

Таким образом, 1С выступит в роли принимающей стороны и «сфотографирует» тот XML, который сама же и сгенерировала.

Типичные ошибки в XML-сообщениях

Проанализируем ситуацию, когда сообщение сформировано, но сервис его не принимает. Чаще всего проблема кроется в пространствах имен (namespaces). Обратите внимание на следующие моменты:

URI пространства имен: Проверьте, совпадает ли URI в вашем XDTO-пакете с тем, что ожидает сервис в WSDL. Здесь часто спасает конвертация схемы XSD в модель XDTO для точного соответствия типов.
Префиксы: Некоторые сервисы чувствительны к префиксам (например, <soap:Envelope> против <soapenv:Envelope>), хотя по стандартам XML это не должно иметь значения.
Порядок полей: В XML-схемах (XSD) часто задается строгий порядок следования элементов (<xs:sequence>). Если вы добавляете свойства в объект XDTO не в том порядке, запрос будет невалидным.

Для глубокого анализа структуры мы рекомендуем использовать Инструменты разработчика. Они позволяют визуально сопоставить структуру вашего объекта и требования схемы, а также выполнить тестовую сериализацию. А если вам нужно представить эти данные пользователю в понятном виде, можно превратить скучный XML в красивый отчет с помощью XSLT.