Как правильно выполнить запрос к веб-сервису 1С:Документооборота без использования 1С?

← На главную

Интеграция со сторонними системами через веб-сервисы 1С:Документооборота (1С:ДО), особенно когда речь идет о механизме «бесшовной интеграции», часто вызывает трудности у разработчиков. Основная сложность заключается в том, что типовой сервис DMService (Seamless Integration Service) построен на принципах полиморфизма и требует строгого соблюдения структуры XML-пакетов, которые не всегда очевидны из стандартной WSDL-схемы. В этой статье мы разберем, как успешно отправить запрос к 1С:ДО, используя обычный curl или другие инструменты тестирования API.

Особенности архитектуры веб-сервиса DMService

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

Критически важный нюанс: при формировании тела запроса необходимо явно указывать атрибут xsi:type. Это позволяет парсеру 1С понять, в какой именно внутренний объект метаданных нужно преобразовать входящий XML. Без этого атрибута система не сможет сопоставить данные, что и приводит к ошибкам разбора.

Настройка окружения и авторизация

Для взаимодействия с сервисом нам понадобится адрес публикации веб-сервиса. Обычно он выглядит так: http://server/base/ws/DMService?wsdl. Для выполнения запросов мы будем использовать curl с базовой авторизацией. Рассмотрим основные параметры:

-u user:password — учетные данные пользователя 1С.
--header 'Content-Type: text/xml; charset=utf-8' — обязательный заголовок для SOAP 1.1.
--data — тело SOAP-конверта.

Пример 1: Получение версии сервиса (GetVersion)

Начнем с самого простого запроса — проверки версии. Рассмотрим, как должен выглядеть XML-пакет. Обратите внимание на определение пространств имен xmlns:dm и использование xsi:type="dm:DMGetVersionRequest".

Выполним следующую команду в терминале:


curl -u user:password --location --request POST 'http://ваша_база/ws/DMService' \
--header 'Content-Type: text/xml' \
--data '<x:Envelope xmlns:x="http://schemas.xmlsoap.org/soap/envelope/" xmlns:dm="http://www.1c.ru/do/seamless/integration/1.0">
    <x:Header/>
    <x:Body>
        <dm:execute>
            <dm:request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="dm:DMGetVersionRequest"/>
        </dm:execute>
    </x:Body>
</x:Envelope>'

В данном случае мы вызываем метод execute, передавая в него объект request, тип которого уточняем через xsi:type. Это универсальный подход для всех запросов бесшовной интеграции.

Пример 2: Получение данных текущего пользователя

Теперь разберем более сложную ситуацию — получение информации о пользователе, под которым выполняется запрос. Структура запроса аналогична, меняется только тип объекта в xsi:type.


curl -u user:password --location --request POST 'http://ваша_база/ws/DMService' \
--header 'Content-Type: text/xml' \
--data '<x:Envelope xmlns:x="http://schemas.xmlsoap.org/soap/envelope/" xmlns:dm="http://www.1c.ru/do/seamless/integration/1.0">
    <x:Header/>
    <x:Body>
        <dm:execute>
            <dm:request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="dm:DMGetCurrentUserRequest"/>
        </dm:execute>
    </x:Body>
</x:Envelope>'

Пример 3: Работа с изменениями (GetChanges)

Для синхронизации данных часто требуется получать список измененных объектов. Для этого используется запрос DMGetChangesRequest. Проанализируем структуру пакета:


curl -u user:password --location --request POST 'http://ваша_база/ws/DMService' \
--header 'Content-Type: text/xml' \
--data '<x:Envelope xmlns:x="http://schemas.xmlsoap.org/soap/envelope/" xmlns:dm="http://www.1c.ru/do/seamless/integration/1.0">
    <x:Header/>
    <x:Body>
        <dm:execute>
            <dm:request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="dm:DMGetChangesRequest"/>
        </dm:execute>
    </x:Body>
</x:Envelope>'

Структура идентификаторов объектов (Object ID)

При работе с более сложными запросами (например, получение данных конкретного документа) выясним, как передавать ссылки на объекты. В 1С:Документообороте идентификатор объекта — это не просто строка с GUID. Это структура, которая должна содержать следующие поля:

ID — уникальный идентификатор (GUID) объекта.
Type — внутреннее имя типа объекта в метаданных 1С (например, Справочник.ВнутренниеДокументы).
Description — строковое представление объекта (необязательно, но полезно для отладки).

Если вы передадите только ID, система не сможет определить, в какой таблице искать объект, так как GUID уникален только в рамках одного типа данных.

Почему не получается отследить трафик?

Часто разработчики пытаются использовать Fiddler или Wireshark, чтобы подсмотреть, как 1С общается с 1С, но не видят пакетов. Разберем причины этой ситуации:

Сервер-серверное взаимодействие: Если запросы идут между двумя серверами 1С (например, из БП в ДО), сниффер нужно запускать непосредственно на сервере, где крутится служба rphost, или на стороне веб-сервера (Apache/IIS).
Локальный трафик: Многие инструменты по умолчанию не перехватывают запросы на localhost или 127.0.0.1. В этом случае стоит использовать полное доменное имя (FQDN) сервера.
HTTPS: Если база опубликована с использованием SSL, трафик будет зашифрован. Для отладки рекомендуется временно опубликовать базу по протоколу HTTP на тестовом контуре.

Отладка и логирование

Если запросы по-прежнему возвращают ошибки, проанализируем состояние системы через Журнал регистрации в самой 1С:ДО. Часто там фиксируются детальные причины падения веб-сервиса, которые не передаются наружу в целях безопасности. Ищите события с типом «Веб-сервис» или ошибки выполнения кода. Для отслеживания сбоев синхронизации также можно использовать отчет для анализа сообщений обмена с 1С:Документооборот.

Также помните, что DMService — это достаточно тяжелый универсальный механизм. Если ваша задача ограничивается созданием одного типа документа из внешней системы, иногда гораздо эффективнее написать свой упрощенный SOAP или HTTP сервис внутри 1С:ДО, который будет принимать только нужные вам поля. Это значительно сократит время на разработку и отладку интеграции. В качестве примера реализации собственного API можно рассмотреть разработку HTTP-сервиса для 1С:Документооборот.