При вызове веб-сервиса произошла ошибка. Неизвестная ошибка. Ошибка проверки данных XDTO: Значение: '0.00' не соответствует простому типу..

Форум Программирование Интеграция и обмен данными, конвертация данных (Обмен)

Конфигурации 1cv8 Интеграция

1. EMelihoff 23.04.20 11:03 Сейчас в теме

Доброго дня! Столкнулся с проблемой при формировании запроса к веб сервису. Ситуация следующая: Фирмой подрядчиком написан сайт, поднят WS и торчат несколько SOAP методов.
Работа с 5 методами сайта не вызывала никаких проблем, забирал данные посредством функционала 1с:

Прокси  = Новый WSПрокси(Определения,"http://web.ru/schemas/web-1c-ws", "integrationPortSrv", "integratioPortSoap",,,ssl,,);
ТипXDTO = Прокси.ФабрикаXDTO.Тип("http://web.ru/schemas/web","GetXXXXXXRequest");
ОбъектXDTO = Прокси.ФабрикаXDTO.Создать(ТипXDTO);
ГСЧ = Новый ГенераторСлучайныхЧисел;
ОбъектXDTO.Idpackage = ГСЧ.СлучайноеЧисло();// номер запроса к базе данных
ОбъектXDTO.DocUid	 = Строка(СсылкаНаОбъект.УникальныйИдентификатор());
РезультатЗапросаДляПоследующейОбработки =  Прокси.GetXXXXXXRequest(ОбъектXDTO);

И тут потребовалось забирать определённые данные 6-ым методом, который был нами успешно протестирован (тестировали на различных документах).
При опытной эксплуатации была обнаружена проблема, на некоторых документах(1 из 5 логика мне непонятна) метод валился в ошибку:

Ошибка при вызове метода контекста (GetXXXXXXRequest)
РезультатЗапроса = Прокси.GetXXXXXXRequest(ОбъектXDTO);
по причине:
При вызове веб-сервиса произошла ошибка. Ошибка вызова операции сервиса: {http://web.ru/schemas/web-ws}:integrationPortSrv:GetXXXXXXRequest()
по причине:
При вызове веб-сервиса произошла ошибка. Неизвестная ошибка. Ошибка проверки данных XDTO:
Значение: '0.00' не соответствует простому типу: {http://web.ru/schemas/web}PositiveMoney
Несоответствие фасету MinExclusive = '0'

Естественно этот же UID копирую и вставляю в SOAPUI в запрос, чтобы понять не причина ли на "той" стороне и на моё удивление метод успешно отрабатывает и возвращает мне результат:
Ниже пример запроса в SOAP:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tsm="http:/web.ru/schemas/web-1c">
   <soapenv:Header/>
   <soapenv:Body>
      <:GetXXXXRequest>
         <:packageId>2443765981</tsm:packageId>
         <:id>8919e577-5c3b-11ea-9451-42f2e9dcc789</:id>
      </:GetXXXXXXRequest>
   </soapenv:Body>
</soapenv:Envelope>

Показать

В голове крутится два вопроса:
1. Почему программа SOAPUI отрабатывает всегда этот запрос, а 1с не всегда
2. Почему странная ошибка {http://web.ru/schemas/web}PositiveMoney ?

Почитав форумы, пришёл к ложному выводу, что тип не тот: в 1с проверил тип, в тех документах которые корректно отрабатывали тип такой же как и в том, что не отрабатывали корректно!!!

Сам устал разбираться, позвал более опытного друга, который часто пишет обмены.
С его слов узнаю, что ошибка на стороне сайта 100% и у него был опыт когда программисты со стороны сайта работали с SOAP запросами как с текстом, из-за некорректно распарсенного запроса, прилетает мне такая ошибка. Так же от другого друга узнаю, что 1с с SOAP-ом предыдущей версии работает, потому программисты сайта парсят наши запросы как текст. Ну да ладно, как решать?
Мои опытные друзья советуют делать через HTTPЗапрос, т.е. по сути тот запрос, который я делал SOAPUI, я должен установить как строку в HTTP запрос:

 
Соединение = Новый HTTPСоединение(
        "web.ru", // сервер (хост)
        443, // порт, по умолчанию для http используется 80, для https 443
        Логин, // пользователь для доступа к серверу (если он есть)
        Пароль, // пароль для доступа к серверу (если он есть)
        , // здесь указывается прокси, если он есть
        , // таймаут в секундах, 0 или пусто - не устанавливать
       Новый ЗащищенноеСоединениеOpenSSL()
    );

Запрос = Новый HTTPЗапрос("/ws/web-1c");
Запрос.Заголовки.Вставить("Content-Type", "text/xml; charset=utf-8");
//БЕЗ ЭТОГО ЗАГОЛОВКА НЕ ХОТЕЛ РАБОТАТЬ
Запрос.Заголовки.Вставить("SOAPAction", "");
	// Если бы нужна была другая страница, мы бы указали,
	// например, "/about" или "/news".
	ТелоКаСтрока = " <soapenv:Envelope xmlns:soapenv=""http://schemas.xmlsoap.org/soap/envelope/"" xmlns:tsm=""http://web.ru/schemas/web-1c"">
	|   <soapenv:Header/>
	|   <soapenv:Body>
	|      <:GetXXXRequest>
	|         <:packageId>2443765981</:packageId>
	|         <:id>8919e577-5c3b-11ea-9451-42f2e9dcc789</:id>
	|      </:GetXXXRequest>
	|   </soapenv:Body>
	|</soapenv:Envelope>";
	Запрос.УстановитьТелоИзСтроки(ТелоКаСтрока,,);
	Результат = Соединение.ОтправитьДляОбработки(Запрос);
	//Сообщить(Результат.КодСостояния);
	//Сообщить(Результат.ПолучитьТелоКакСтроку());
	
	ТелоКакСтрока = Результат.ПолучитьТелоКакСтроку();
	
	Чтение = Новый ЧтениеXML;
	//Чтение.ОткрытьФайл(ПутьКФайлу);
	
	//ОбъектXDTO = ФабрикаXDTO.ПрочитатьXML(Чтение);
	Чтение.УстановитьСтроку(ТелоКакСтрока);
	
	ОбъектXDTO = ФабрикаXDTO.ПрочитатьXML(Чтение);
        Дальше парсим ОбъектXDTO

Показать

Результат так ВСЕГДА отрабатывает во всех документах.

С такой ситуацией столкнулся в первый раз, потому интересно узнать у опытных людей, кто как решал такие проблемы если сталкивался и самое главное из-за чего они происходят?

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. Drivingblind 228 23.04.20 13:52 Сейчас в теме

Ответ должен быть только того типа, что описан в XDTO. Иначе будет вываливаться ошибка. Как вариант проблема в дробной части. Попробуйте убирать нули после точки.

Погуглив немного, нашел следующее про параметр minExclusive - определяет нижнюю границу для числовых значений (значение должно быть больше указанного здесь). Может, вообще его убрать?

3. EMelihoff 23.04.20 14:02 Сейчас в теме

(2) Скажите пожалуйста почему эти же данные в SOAP UI отрабатывают, а с помощью 1c не хотят? В SOAP UI, что тип на лету меняется?

5. Drivingblind 228 23.04.20 14:12 Сейчас в теме

(3) Потому что 1С очень привередлива к типам данным. Была некогда ситуация, когда на пхп всё отрабатывало, а 1С не хотела. Даже с разработчиками ругались по этому поводу. Проблема была схожая с вашей

9. EMelihoff 23.04.20 14:20 Сейчас в теме

(5)о!!! т.е. возврат когда идёт ко мне из сайта, там корявые типы данных? их 1с не может скушать? Это вполне живая теория

6. starik-2005 3039 23.04.20 14:12 Сейчас в теме

(3)

Скажите пожалуйста почему эти же данные в SOAP UI отрабатывают, а с помощью 1c не хотят? В SOAP UI, что тип на лету меняется?

Вы в 1С генерируете случайное число, которое может быть равно нулю, а в схеме описано, что число должно быть больше нуля. ИМХО тут и есть проблема.

В SOAP UI Вы вызываете запрос с каким-то идентификатором больше нуля. Вызовите с идентификатором, равным нулю и посмотрите, что возвратит Вам сервис.

8. EMelihoff 23.04.20 14:17 Сейчас в теме

(6) я в отладке смотрю - там число больше нуля - я его копирую вставляю в соап, я делал ограничения в ГСЧ (1,100000)

11. starik-2005 3039 23.04.20 14:23 Сейчас в теме

(8)

я делал ограничения в ГСЧ (1,100000)

В вопросе это не отражено (нет границ). В вопросе ошибка именно на "0".

13. EMelihoff 23.04.20 14:24 Сейчас в теме

(11) да, согласен - там этого нет. Но это первое что я попробовал, и только что повторил это в SOAP UI с "0"

14. starik-2005 3039 23.04.20 14:29 Сейчас в теме

(13) оберните в попытку-исключение вызов сервиса и посмотрите, какие идентификаторы вызывают ошибку (раз уж 1 из 5, при том непонятна логика, а 4 из 5 работают корректно). Если система генерирует исключение, при том не каждый раз, значит у нее есть на это сонования.

15. EMelihoff 23.04.20 14:33 Сейчас в теме

(14) Делал попытку исключение, тут возврат ко мне какой-то приходит странный, который не может поместится в XDTO, а в HTTPЗапросе отлично возвращается.
Тут если он рандомно валился было бы странно, но он валится на определённых доках, мне отправляется ответ такой, что 1с не может принять

17. starik-2005 3039 23.04.20 14:37 Сейчас в теме

(15)

но он валится на определённых доках

По всей видимости проблема не в запросе, а в ответе, который не является с точки зрения 1С валидным, т.е. не проходит проверку на соответствие XSD-схеме, описанной в типе возвращаемого значения. Дерните точку входа на предмет WSDL-файла - там будет описан тип возвращаемого значения. Предположу, что 1С считает параметр MinExclusive как ограничивающий снизу, но не включающий, а веб-сервис предполагает, что это значение может быть равно нулю и возвращает этот ноль. SOAP UI просто отображает XML-файл без валидации схемы, поэтому все ок.

minExclusive Определяет нижнюю границу для числовых значений (значение должно быть больше указанного здесь)
minInclusive Определяет нижнюю границу для числовых значений (значение должно быть больше или равно указанному здесь)

18. EMelihoff 23.04.20 14:57 Сейчас в теме

(17)

ерните точку входа на предмет WSDL-файла -

Спасибо! Это я ещё не пробовал

19. Drivingblind 228 24.04.20 11:51 Сейчас в теме

(18) ну как? Разобрались, в чем проблема была?

16. EMelihoff 23.04.20 14:37 Сейчас в теме

(14) а отправляю я корректные данные - я эти же данные сохранял на диск
вот так:
ИмяФайлаЗапрос = "C:\WS\GetXXXResult.xml";
ЗаписатьОтладочныйXMLЗапрос(ИмяФайлаЗапрос,ОбъектXDTO,Прокси.ФабрикаXDTO);

, и вставлял в Soap UI и приходил в SOAP UI корректный ответ:

10. EMelihoff 23.04.20 14:22 Сейчас в теме

(6)

Вызовите с идентификатором, равным нулю и посмотрите, что возвратит Вам сервис.

ради эксперимента попробовал - вернул ответ корректный и Soap UI и HTTPЗапрос из 1с

4. EMelihoff 23.04.20 14:10 Сейчас в теме

(2) и ещё вопрос, почему HTTPЗапрос отработал из 1с с той же схемой?

7. Drivingblind 228 23.04.20 14:13 Сейчас в теме

(4) Насколько я понимаю, потому что в http-сервисах нет XDTO, а в web-сервисах мы ограничены XDTO

12. EMelihoff 23.04.20 14:23 Сейчас в теме

(7) мне кажется Вы правы, проверить только не знаю как.

Оставьте свое сообщение

E-mail: