WEB - сервис стороннего приложения. В тупике. Ошибка при вызове метода.

вссылку обнови

Может, поднять фиддлер и посмотреть что реально приходит, а потом сравнить это со схемой? Если метод свежевнедренный, то не исключены и ошибки разработчиков сервиса...

(5) это такая штука, которая перехватывает веб-трафик (wininet.dll) и показывает его. Веб-отладчик. Можно смотреть что вы отправляете на сервис и получаете с него

Так у тебя в ответе походу приходит не то содержимое, что ожидается

Если дашь доступ к веб-сервису, то смогу посмотреть

(0) >Появился на ресурсе новый метод

WSDL-схему перезагрузи и да могут быть приколы

(13) вы обратили внимание, что у вас в теге ACTS элементов меньше чем указано в схеме? D_ISSUE и ORDERS нет. Они ненароком не обязательные? По остальным нормально все - т.е. данные примерно соответствуют типам и фасетам?

дело не в том отрабатывает запрос или нет. Дело в том что вы XDTO-пакет для разбора ответа генерируете по схеме, но во-первых, в схеме не исключены мелкие косяки, во-вторых, составные элементы в SOAP могут представляться немножко по-разному и из-за этого разные клиентские библиотеки иногда лажаются. 1Cный XDTO не исключение.

(17) на самом деле если они необязательные, то это влиять не должно. Надо проверить.

(20) минимальное количество элементов D_ISSUE=1. Т.е. как минимум один должен быть. А у вас ни одного.

+ поменяйте на ноль и посмотрите что и как будет происходить

это я и имел в виду под "мелкими косяками". Элем описан как обязательный, но в продакшене ответ идет без него.

(20) Минимальное кол-во = 1, обязательное

(26) да, конечно. SOAP так и работает - запрос в виде XML, ответ тоже в виде XML.

(28) нет. Как я понимаю, сервер отправляет ответ, XDTО-пакет его проверяет на соответствие схеме (где у вас и происходит ошибка) и затем разбирает, разбрасывая данные по полям. После чего к ним можно обращаться из программы на 1С.

* сорри, неверно вашу реплику прочитал. Все верно.

(31) навскидку сказать сложно, нужно проводить эксперименты. Как вариант, можно "сыграть" наоборот - заполнить поля в XDTO-пакете и записать XML, и сравнить получившееся с тем что возвращается сервером. Тут и вылезет косяк.

(34) да, вполне может быть в этом.

можно через httpзапрос отправить запрос и разобрать ответ вручную,но это придется пеоеписывать при каждом изменении сервиса.

и можно спросить,если на той стороне сервис писали кодом,то лучше и на этой работать кодом,тогда странных ошибок будет меньше.

Тащить WSDL схему на каждый чих - такое себе.
Закешируйте его в tmp файл при первом обращении программы и обновляй при перезапуске 1С.

(36) вот только пересмотрел я ответ (13) и не увидел там никакой зауми... Обычные вложенные элементы, чего XDTO не может там вычитать - на первый взгляд непонятно. Я бы все-таки внимательно посмотрел на пакет и элементы. Где-то что-то не соответствует скорее всего.

(40) это понятно что не 1С. Серьезные нагруженные системы такого плана пишутся на Java обычно или еще на чем-то подобном.
Имеется в виду следующее: вмешаться в механизм разбора XDTO-пакета нельзя, он - вещь в себе. У него, например, нет процедур обработки событий, которые бы позволили подправить входящие узлы перед обработкой или сделать еще что-то подобное. Поэтому если возможности по подправке XSD/WSDL исчерпаны, то остается только разбирать ответы руками, что адски неприятно для серьезных сервисов, где таких пакетов может быть много.

если вы уверены что у вас все хорошо со схемой - попробуйте платформу посвежее. Может, вам повезет и это ошибка платформы, которую со временем устранили.

Если вдруг не получится можно воспользоваться Использование классов .Net в 1С для новичков В свое время для таких случаев и писал
Не всегда сторонние схемы  соответствует 1С Wsdl. Прелесть C# в том, что всегда можно для типа реализовать IXmlSerializable и ты сам будешь контролировать сериализацию.
Ну или Скачать Wsdl и заменить тип на Any импортировать и уже  самому программно разбирать объект XDTO

(44) не видя xsd и не имея хотя бы 1-2 респонсов в виде текстовых файлов, трудно родить каких-либо идей кроме тех что уже были озвучены. Выложите - ну, можно будет попробовать выбрать время посмотреть.

Плюнул в свое время , запрашиваю и разбираю ответы ручками.

Уже вижу косяк. В XSD у вас 
  <xs:complexType name="OcInsOrderCompensationResponceDto">
    <xs:sequence>
      <!-- Номер приказа на выплату -->
      <xs:element name="NUM_PO" type="xs:string" minOccurs="0" />

а в респонсе
               <ns2:ORDERS>
                  <ns2:NUM>003/037/000012/20/1/1</ns2:NUM>

т.е. номера обозваны по-разному. Если подправить в схеме NUM_PO на NUM и удалить из XML-файла SOAPовские обертки:

==Response_mista1.xml==

<?xml version="1.0" encoding="UTF-8"?>

         <ns2:insCompensationCurrentInfo xmlns:ns2="http://othersoft.com/oc/schemas">;

            <ns2:UID>sc105960</ns2:UID>

            <ns2:D_CLAIM>2020-03-26</ns2:D_CLAIM>

            <ns2:EL_RISK>osago-damage</ns2:EL_RISK>

            <ns2:DECL>47800.0</ns2:DECL>

            <ns2:ACTS>

               <ns2:D_ISSUE>2020-03-27T00:00:00+02:00</ns2:D_ISSUE>

               <ns2:OBJ_UID>c2021330</ns2:OBJ_UID>

               <ns2:C_INSUR>7663</ns2:C_INSUR>

               <ns2:NUM>003/037/000012/20/1</ns2:NUM>

               <ns2:SUM_ACT>47800.0</ns2:SUM_ACT>

               <ns2:ORDERS>

                  <ns2:NUM>003/037/000012/20/1/1</ns2:NUM>

                  <ns2:SUM_RECEIPT>47800.0</ns2:SUM_RECEIPT>

                  <ns2:CUSTOMER_S>Админченко Админ Админович</ns2:CUSTOMER_S>

                  <ns2:OKPO>2883334290</ns2:OKPO>

               </ns2:ORDERS>

            </ns2:ACTS>

         </ns2:insCompensationCurrentInfo>



тогда следующий код



    чОтвет = Новый ЧтениеXML ();

    чОтвет.ОткрытьФайл("D:\Response_mista1.xml");

    

    Файл = ФабрикаXDTO.ПрочитатьXML(чОтвет, ФабрикаXDTO.Создать("http://othersoft.com/oc/schemas";, "OcInsCompensationCurrentInfo").Тип());



грузит ваш файлик.

(51) > А по поводу "Соаповские" обертки - разработчики сервиса с ними тоже должны что-то подправить?
Думаю, что нет. Типы Envelope, Header, Body - служебные, они обрабатываются библиотекой SOAP-клиента, в схемах не указываются.
А тип верхнего уровня OcConsolidatedCaseInfoListResponse, по-видимому, описан в WSDL.
Все оставшееся нормально обрабатывается вашей схемой, если ее подправить.
Если у вас есть контакт с разрабами - укажите им на ошибки. А если нет - исправьте сами ручками схему под данные да и пользуйтесь, пока не исправят.
(53) так я ж вам еще неделю назад говорил - проверяйте схему и сравнивайте ее с ответом. У вас там не сотни атрибутов - с такими размерами схем безо всякого SOAPUI делается глазками за несколько минут.

как вариант - можно вообще в схеме указать оба атрибута, как необязательные:

<xs:element name="NUM" type="xs:string" minOccurs="0" />
<xs:element name="NUM_PO" type="xs:string" minOccurs="0" />

и потом обработать программно встречаемость обоих из них. Т.е. по умолчанию берем NUM, а если его вдруг нет, то проверяем NUM_PO.
В этом случае у вас программа не упадет, когда они исправят атрибут и ответ внезапно пойдет с NUM_PO вместо NUM.

(56) когда вы создаете WS-ссылку в конфигурации, вы импортируете WSDL. Также вы импортируете XSD, когда создаете XDTO-пакеты. Раз вы проимпортировали - вы фиксируете то состояние, в котором оно пребывает на момент, например когда вы скачали его у разработчика и подправили под свои нужды. Если у разработчика сервиса что-то поменяется, то придется еще раз это все проделать и еще раз передать вашу конфу пользователям - обновить там или еще как-то.

Как я понимаю, в норме разработчик сервиса должен обеспечить такие XSD и WSDL, которые позволяют все нормально импортировать куда угодно - в дельфю, в 1С, в С# и т.д. Но на практике все не так просто - есть немного различающиеся механизмы представления сложных объектов в XML, разные библиотеки web-клиентов могут по-разному это все разбирать, что-то они могут уметь, а что-то не уметь (привет, XDTO), в некоторых языках может быть даже конфликт атрибутов с зарезервированными словами. Кроме того, разработчики сервисов, как в вашем случае, могут косячить, это не редкость, и крайне долго и неохотно исправлять свои косяки. Короче, править иногда приходится. Это практически норма.

(59) в wsdl-файле может быть вот так:

   <wsdl:types>

      <xs:schema>

         <xs:import namespace="http://api.vetrf.ru/schema/cdm/application/ws-definitions";

                    schemaLocation="application_ws_definitions_v2.0.xsd"/>

         <xs:import namespace="http://api.vetrf.ru/schema/cdm/base/ws-definitions";

                    schemaLocation="base_ws_definitions_v2.0.xsd"/>

      </xs:schema>

   </wsdl:types>

но вообще этот вопрос - скорее к разработчику сервиса.