Работа с веб-сервисами в 1С — это мощный инструмент интеграции, но он часто сопровождается сложностями в диагностике. В этой статье мы подробно разберем, как «заглянуть» внутрь принимающей базы при вызове метода веб-сервиса и что делать, если система выдает загадочную ошибку сериализации XML. Проанализируем типичные ситуации, когда обмен «вручную» работает, а через регламентное задание — нет.
Прежде всего, разберем ситуацию, когда точка останова в коде веб-сервиса не срабатывает. По умолчанию веб-сервисы работают в контексте веб-сервера (IIS или Apache) и серверного сеанса 1С, которые скрыты от стандартного отладчика. Чтобы исправить это, нам необходимо выполнить комплексную настройку на стороне базы-приемника.
Шаг 1. Включение режима отладки на сервере 1С. Рассмотрим параметры запуска службы сервера. Сервер 1С должен быть запущен с ключом -debug. Если это не сделано, никакие манипуляции в конфигураторе не помогут. Проверим это в реестре Windows (для службы 1C:Enterprise 8.3 Server Agent) или в настройках конфигурации в Linux.
Шаг 2. Настройка файла публикации default.vrd. Это один из самых критичных моментов, который часто упускают. Разберем структуру этого файла. Он находится в папке публикации на веб-сервере. Нам нужно убедиться, что в описании сервиса присутствует атрибут отладки. Пример корректной секции:
<wsServices>
<service name="ИмяВашегоСервиса"
alias="service.1cws"
enable="true"
debug="true" />
</wsServices>
Если используется современная отладка по протоколу HTTP, убедимся, что указан адрес сервера отладки (параметр debuggerURL). Без флага debug="true" веб-сервер просто не передаст управление отладчику 1С.
Шаг 3. Настройка Конфигуратора. Теперь перейдем в конфигуратор базы-приемника. Нам нужно выполнить следующие действия:
Проанализируем ситуацию: если всё настроено верно, то при вызове метода веб-сервиса в списке Доступные предметы отладки (меню Отладка — Подключение) должен на мгновение появиться сеанс типа «Web-сервис». Если он появляется и тут же исчезает, а точка останова не срабатывает — значит, ошибка происходит еще на этапе инициализации параметров, до входа в тело функции.
Теперь разберем вторую проблему, упомянутую в теме. При чтении данных (например, классификатора ОКОФ) возникает ошибка сериализации. Это означает, что XDTOСериализатор или встроенные механизмы 1С не могут преобразовать объект 1С в текстовый формат XML согласно заданной схеме.
Выясним причину на примере ОКОФ. В наименованиях и описаниях классификаторов часто встречаются спецсимволы: неразрывные пробелы, символы перевода строки или управляющие ASCII-символы с кодами от 0 до 31. XML 1.0 строго запрещает большинство таких символов. Чтобы решить эту проблему, проанализируем данные перед отправкой. Используем функцию НайтиНедопустимыеСимволыXML.
Рассмотрим пример кода для очистки строки:
Функция ОчиститьСтрокуДляXML(ВходнаяСтрока)
Результат = ВходнаяСтрока;
НедопустимыеСимволы = НайтиНедопустимыеСимволыXML(Результат);
Пока НедопустимыеСимволы <> Неопределено Цикл
// Можно либо удалять, либо заменять на пробелы
Результат = СтрЗаменить(Результат, Символ(НедопустимыеСимволы), "");
НедопустимыеСимволы = НайтиНедопустимыеСимволыXML(Результат);
КонецЦикла;
Возврат Результат;
КонецФункции
Проанализируем структуру XML из сообщения. Ошибка часто возникает при попытке сериализовать Неопределено, если в схеме XDTO для этого свойства не стоит признак Nillable (возможность принимать пустое значение). Также проверим реквизиты типа ЛюбаяСсылка. Если в базе-источнике есть «битая» ссылка (объект удален, а ссылка осталась), сериализатор не сможет корректно определить ее тип для XML.
Посмотрим на поле НаименованиеГруппировки в примере. Оно содержит очень длинный текст. Если в пакете XDTO для этого поля установлено ограничение по длине (facet maxLength), или тип данных не соответствует string, возникнет ошибка представления.
Рассмотрим ситуацию: почему «руками» обмен идет, а «автоматом» — нет?
Код регламентного задания всегда выполняется на сервере под учетной записью, от имени которой запущена служба 1С. При ручном запуске код может выполняться в контексте вашего клиентского сеанса.
Разберем важный нюанс: при регламентном задании отладка может «заходить не туда», так как система пытается подключиться к фоновому заданию, а не к веб-сервису. Для диагностики в таких случаях рекомендуется использовать ЗаписьЖурналаРегистрации.
Если отладчик всё же не помогает, применим метод «протоколирования». Добавим в начало функции веб-сервиса запись в журнал:
Функция uploadDataPackage(ПакетДанных, НомерПакета, Приоритет, СразуСтавитьВОчередь, ИдСообщения)
ЗаписьЖурналаРегистрации("ОбменДанными.WebСервис",
УровеньЖурналаРегистрации.Информация, , ,
"Принят пакет № " + НомерПакета + " Ид: " + ИдСообщения);
// Тело функции...
КонецФункции
Если запись в журнале регистрации базы-приемника не появляется, значит, запрос «отбивается» веб-сервером или платформой еще до передачи управления в код 1С. В этом случае стоит использовать внешние инструменты захвата трафика (например, Fiddler), чтобы увидеть сырой XML-пакет и точный HTTP-ответ сервера (например, 500 Internal Server Error с подробным описанием ошибки платформы).
Таким образом, для успешной отладки необходимо обеспечить три условия: ключ -debug на сервере, флаг в default.vrd и правильные настройки автоматического подключения в Конфигураторе. А при возникновении ошибок XML — всегда начинать с проверки данных на наличие запрещенных символов.