Рассмотрим ситуацию, с которой сталкиваются многие разработчики при обновлении платформы 1С:Предприятие. Вы отправляете HTTPЗапрос к веб-сервису, получаете ответ, но вместо ожидаемых данных система выдает сообщение об ошибке: javax.xml.stream.XMLStreamException: Content is not allowed in prolog. Давайте разберем, почему это происходит и как исправить ситуацию.
Данная ошибка означает, что парсер XML на стороне сервера столкнулся с недопустимыми символами в самом начале документа. Чаще всего виновником является так называемый BOM (Byte Order Mark). Это невидимые служебные байты (в кодировке UTF-8 это последовательность EF BB BF), которые некоторые версии платформы 1С могут автоматически добавлять в начало тела запроса при использовании метода УстановитьТелоИзСтроки().
Сервер, ожидая увидеть начало тега <soapenv:Envelope>, встречает эти «лишние» байты и прерывает разбор документа, выдавая ошибку 500. В предыдущих версиях платформы 1С этот механизм работал иначе, поэтому при обновлении кода или самой платформы ранее стабильно работавшие интеграции могут внезапно дать сбой.
Самый быстрый и эффективный способ исправить проблему — это запретить 1С добавлять маркер последовательности байтов при формировании тела запроса. Для этого при вызове метода УстановитьТелоИзСтроки необходимо явно указать параметр ИспользованиеByteOrderMark.
Разберем, как изменить ваш код:
// Вместо старого вызова:
// Запрос.УстановитьТелоИзСтроки(ТекстЗапроса);
// Используем новый вариант с явным указанием параметра:
Запрос.УстановитьТелоИзСтроки(ТекстЗапроса, , ИспользованиеByteOrderMark.НеИспользовать);
После внесения этого изменения 1С отправит «чистый» XML-пакет, который будет корректно распознан любым веб-сервисом, ожидающим стандартный формат SOAP.
Если вы взаимодействуете с веб-сервисами, опубликованными через WSDL, ручное формирование HTTPЗапроса и сборка XML-строк — не самый надежный путь. Разберем более правильный подход с использованием встроенных объектов 1С: WSОпределения и WSПрокси.
Этот метод избавляет вас от необходимости вручную прописывать SOAPAction, заголовки и следить за кодировками. Платформа берет на себя всю «черную» работу по сериализации данных.
Давайте посмотрим, как организовать вызов сервиса через WSПрокси:
// 1. Создаем объект определения сервиса, указав путь к WSDL и настройки защиты
Определение = Новый WSОпределения("http://адрес_сервиса/service?wsdl", "Пользователь", "Пароль", , , Новый ЗащищенноеСоединениеOpenSSL());
// 2. Создаем прокси-объект, указав URI пространства имен, имя сервиса и имя точки подключения
Прокси = Новый WSПрокси(Определение, "urn:wsedi", "ServiceClass", "ServiceSoap");
// 3. Вызываем нужный метод сервиса напрямую
Результат = Прокси.listMBEx("123", "Admin", "ORDER", "2022-07-01", "2022-07-14");
Если после описанных правок ошибка сохраняется, рекомендуем выполнить следующие действия:
Fiddler или Wireshark. Они позволят вам перехватить «сырой» запрос, который уходит из 1С, и увидеть реальное содержимое байтов до того, как они достигнут сервера.Content-Type и SOAPAction соответствуют спецификации вашего партнера. Иногда проблема скрывается в неверно переданном типе контента.Postman. Если Postman работает, а 1С нет — значит, дело либо в невидимых спецсимволах (как BOM), либо в дополнительных заголовках, которые 1С добавляет автоматически, а Postman — нет.Помните, что использование WSПрокси — это стандарт индустрии для 1С. Постарайтесь при возможности перевести интеграции на этот метод, чтобы код стал чище, понятнее и устойчивее к обновлениям платформы.