Ошибка при парсинге ответа WEB-сервиса

ceib

День добрый!

Для интеграции ERP с внешним веб-сервисом в ESR созданы необходимые интерфейсы (ERP - исходящий, Web-сервис - входящий), типы, мэпинг и т.д. Уже описывал условие задачи (а Chaser009 очень сильно помог с решением, спасибо большое) в этой теме.

На данный момент все необходимые объекты созданы в ESR, успешно сгенерирован Proxy в ERP, созданы необходимые (по аналогии с этим) объекты в Integration Repository. Сделал небольшой тест в ERP:

Code:

REPORT Z_TEST.

data: getInfoObj type ref to ZMETEO_CO_SC_GET_USER_INFO,
      exc type ref to CX_AI_SYSTEM_FAULT,
      fault type ref to ZMETEO_CX_FAULT_SOAPMESSAGE,
      request type ZMETEO_USER_INFO1,
      response type ZMETEO_USER_GET_INFO_RESPONSE.

request-user_info-user_name = 'USERNAME'.
request-user_info-user_passw = 'PASSWORD'.

try.
  create object getInfoObj.
  getInfoObj->sc_get_user_info( exporting !output = request
                                                importing !input = response ).

  write 'Success'.
catch ZMETEO_CX_FAULT_SOAPMESSAGE into fault.
  write fault->get_text( ).
catch CX_AI_SYSTEM_FAULT into exc.
  write exc->get_text( ).
endtry.

В этом тесте всегда срабатывает исключение CX_AI_SYSTEM_FAULT, выводится MESSAGE.GENERAL. В журналах мониторинга творится следующее:

Как мне представляется, ключевым здесь является сообщение второго скрина "Error during parsing body item http://schemas.xmlsoap.org/soap/envelope/^Fault using class com.sap.aii.af.sdk.xi.mo.SOAPFault at ^faultactor/ caused by --- Missing faultstring", однако как это правильно понять - ума не приложу. Сам веб-сервис прекрасно работает и прекрасно работал в моменты отправки запросов.

Подскажите, в чем может быть проблема?

Chaser009

Здравствуйте!

Возможность есть на принимающей стороне логи посмотреть?
500 Internal server error - это общее описание ошибки, сервер не смог обработать запрос, но причины могут быть разные. Проверьте еще раз правильность формирования сообщения, на всякий случай. Бывало и такое: не добавленный, например, в нужном месте неймспейс в xml приводил к ошибкам.

Я бы взял, например, SOAP UI, импортировал туда wsdl, попробовал бы отправить сообщение. Если все хорошо, взял бы сообщение в том виде, как оно у вас формируется, и отправил в этом виде. Дальше - по результату.

ceib

Chaser009 написал:

Здравствуйте!

Возможность есть на принимающей стороне логи посмотреть?
500 Internal server error - это общее описание ошибки, сервер не смог обработать запрос, но причины могут быть разные. Проверьте еще раз правильность формирования сообщения, на всякий случай. Бывало и такое: не добавленный, например, в нужном месте неймспейс в xml приводил к ошибкам.

Я бы взял, например, SOAP UI, импортировал туда wsdl, попробовал бы отправить сообщение. Если все хорошо, взял бы сообщение в том виде, как оно у вас формируется, и отправил в этом виде. Дальше - по результату.

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

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

Насчет взять сообщение в том виде, как оно формируется - что имеется ввиду? Насколько я понимаю, мне доступны только тесты преобразований в ESR, то есть я могу получить смапленное сообщение с выхода теста - эти сообщения смотрел, сообщение формируется верное, согласно схеме. Однако что именно в итоге отправляется веб-сервису - не знаю (как оно упаковывается в операцию, как преобразовывается в SOAP). Можно где то взять готовое сформированное SOAP-сообщение на выходе PI?

И насчет нейм спейсов - во внутреннем интерфейсе никакие сторонние определения имен не используются. Внешний интерфейс полностью импортирован из WSDL, в которой все необходимые имена прописаны. Насколько понимаю, они оттуда и должны браться и добавляться в исходящий запрос в теги SOAPENV. Или все же что то куда то нужно руками добавить?

Chaser009

Вот то, что у вас на выходе в тесте мэппинга, и возьмите. Само сообщение. Оно у вас должно быть в таком же виде, как и в SOAP UI структура для запроса. И именно в таком виде оно прилетит из PI на вход сервису. Его вставьте в SOAP UI и выполните запрос.

ceib

Chaser009 написал:

Вот то, что у вас на выходе в тесте мэппинга, и возьмите. Само сообщение. Оно у вас должно быть в таком же виде, как и в SOAP UI структура для запроса. И именно в таком виде оно прилетит из PI на вход сервису. Его вставьте в SOAP UI и выполните запрос.

Не совсем понял. В тесте у нас мэпятся только структуры сообщений. По SOAP передается операция с переданным ей сформированным сообщением. То есть после приведения сообщения в нужный формат оно должно упаковаться в соответствующую операцию (для этого мы указываем операции в мэпинге операций), после чего все это должно упаковаться в SOAPENV теги. Для всего этого и существуют мэпинг операций и адаптер SOAP. По крайней мере я так себе представлял.

По факту - у меня есть исходящий запрос с операцией на входе веб-сервиса с названием "cidiuser_GetInfo", которая принимает сообщение типа "cidiuser_GetInfoRequest". Мэпинг значений настраивается для моего типа сообщения и типа "cidiuser_GetInfoRequest". В тесте, естественно, получаем сообщение типа "cidiuser_GetInfoRequest", но только его. Нет никаких тегов SOAPENV, нет указания, что должна выполниться операция "cidiuser_GetInfo".

Но, даже если принимать, что сообщение должно отправляться голой структурой, веб сервис все равно отвечает вполне себе корректным сообщением-ошибкой на это:

Code:

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode xsi:type="xsd:int">1</faultcode>
         <faultactor xsi:type="xsd:string">CIDIUser</faultactor>
         <faultstring xsi:type="xsd:string">No rights</faultstring>
         <detail xsi:type="xsd:string"/>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
<!---->

В каком месте я не прав?

P.S. Если имелось ввиду, что нужно взять эту структуру и вставить в необходимые SOAP-теги с описанием вызываемой операции, то это делал - тут все корректно.

Chaser009

Поняли вы все правильно. Просто у вас в SOAP UI так же уже wsdl разобран по операциям, и для каждой сгенерирован request. Так? А внутри него находится структура, соответствующая входному сообщению. При выполнении запроса SOAP UI сам оборачивает это сообщение всеми дополнительными тэгами и отправляет серверу (ну точнее, у вас в request'е уже все тэги есть). Поэтому, вам надо всего лишь структуру сообщения заполнить. Вот на выходе вашего мэппинга как раз и должна получиться такая структура сообщения, уже заполненная.

Тот результат, что вы привели, - это ответ на сообщение, вставленное из мэппинга?

Давайте так:

1. выложите запрос из SOAP UI с заполненными данными и ответ сервера.
2. тот же запрос, только со вставленной из результатов мэппинга заполненной структурой и опять же ответ сервера.

ceib

Chaser009 написал:

Поняли вы все правильно. Просто у вас в SOAP UI так же уже wsdl разобран по операциям, и для каждой сгенерирован request. Так? А внутри него находится структура, соответствующая входному сообщению. При выполнении запроса SOAP UI сам оборачивает это сообщение всеми дополнительными тэгами и отправляет серверу. Поэтому, вам надо всего лишь структуру сообщения заполнить. Вот на выходе вашего мэппинга как раз и должна получиться такая структура сообщения, уже заполненная.

Тот результат, что вы привели, - это ответ на сообщение, вставленное из мэппинга?

Насчет SOAP UI. В окне отправки запроса у меня следующий текст:

Code:

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:met="[i]WEB_SERVICE_NAMESPACE_URI[/i]">
   <soapenv:Header/>
   <soapenv:Body>
      <met:cidiuser_GetInfo soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
         <user_name>MyName</user_name>
         <user_passw>MyPass</user_passw>
         <token />
         <debug />
      </met:cidiuser_GetInfo>
   </soapenv:Body>
</soapenv:Envelope>

На этот запрос я получаю корректный ответ с данными. На выходе теста мэпинга у меня следующее:

Code:

<?xml version="1.0" encoding="UTF-8"?>
<ns1:cidiuser_GetInfoRequest xmlns:ns1="[i]WEB_SERVICE_NAMESPACE_URI[/i]">
   <user_name>MyName</user_name>
   <user_passw>MyPass</user_passw>
   <token />
   <debug" />
</ns1:cidiuser_GetInfoRequest>

Вы имеете ввиду, что нужно это сообщение подставить в SOAP UI вместо тега <met:cidiuser_GetInfo > с соответствующим алиасом пространства имен? Если так, то подставлял - все работает в SOAP UI.

Цитата:

Тот результат, что вы привели, - это ответ на сообщение, вставленное из мэппинга?

Да, это ответ на запрос (без обертки SOAP):

Code:

<?xml version="1.0" encoding="UTF-8"?>
<ns1:cidiuser_GetInfoRequest xmlns:ns1="[i]WEB_SERVICE_NAMESPACE_URI[/i]">
   <user_name>MyName</user_name>
   <user_passw>MyPass</user_passw>
   <token />
   <debug" />
</ns1:cidiuser_GetInfoRequest>

Chaser009

<met:cidiuser_GetInfo - требуемое сервисом сообщение
<ns1:cidiuser_GetInfoRequest - ваше сообщение

Разницу видите?

ceib

Chaser009 написал:

<met:cidiuser_GetInfo - требуемое сервисом сообщение
<ns1:cidiuser_GetInfoRequest - ваше сообщение

Разницу видите?

met:cidiuser_GetInfo это как раз название операции, которая на вход принимает сообщение типа cidiuser_GetInfoResponse, а не сообщения. Это то, что я задаю в мапинге операций а не сообщений. Выдержка из WSDL:

Code:

<operation name="cidiuser_GetInfo">
    <documentation>read user info</documentation>
    <input message="tns:cidiuser_GetInfoRequest"/>
    <output message="tns:cidiuser_GetInfoResponse"/>
</operation>

<message name="cidiuser_GetInfoRequest">
  <part name="user_name" type="xsd:string" />
  <part name="user_passw" type="xsd:string" />
  <part name="token" type="xsd:string" />
  <part name="debug" type="xsd:int" />
</message>

Chaser009

Просто попробуйте в своем вставленном результате мэппинга GetInfoRequest поменять на GetInfo. И выполните запрос.

ceib

Chaser009 написал:

Просто попробуйте в своем вставленном результате мэппинга GetInfoRequest поменять на GetInfo. И выполните запрос.

Прошу прощения, как это сделать? В мэпинге операций я задаю операцию, из которой по нажатию кнопки "Read operations" автоматически тип и название сообщения из WSDL считывается и устанавливается на это значение (GetInfoRequest). То есть руками я поправить его не могу без правки WSDL, который предоставляет веб-сервис.

ceib

ceib написал(а):

Chaser009 написал:

Просто попробуйте в своем вставленном результате мэппинга GetInfoRequest поменять на GetInfo. И выполните запрос.

Прошу прощения, как это сделать? В мэпинге операций я задаю операцию, из которой по нажатию кнопки "Read operations" автоматически тип и название сообщения из WSDL считывается и устанавливается на это значение (GetInfoRequest). То есть руками я поправить его не могу без правки WSDL, который предоставляет веб-сервис.

Прошу прощения, поторопился с ответом. Сделал это в SOAP UI - ответ сервиса корректный, все работает. Мой запрос:

Code:

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:met="http://...">
<soapenv:Header/>
<soapenv:Body>

<ns1:cidiuser_GetInfo xmlns:ns1="http://...">
   <user_name>MyName</user_name>
   <user_passw>MyPass</user_passw>
   <token/>
   <debug>1</debug>
</ns1:cidiuser_GetInfo>
      
</soapenv:Body>
</soapenv:Envelope>

Chaser009

Вот странность как раз в том, что, судя по soap ui, у вас сервис требует один тип сообщения, а импорт wsdl в pi дает другой результат.

ceib

Chaser009 написал:

Вот странность как раз в том, что, судя по soap ui, у вас сервис требует один тип сообщения, а импорт wsdl в pi дает другой результат.

Судя по этой выдержке из WSDL:

Code:

<operation name="cidiuser_GetInfo">
    <documentation>read user info</documentation>
    <input message="tns:cidiuser_GetInfoRequest"/>
    <output message="tns:cidiuser_GetInfoResponse"/>
</operation>

<message name="cidiuser_GetInfoRequest">
  <part name="user_name" type="xsd:string" />
  <part name="user_passw" type="xsd:string" />
  <part name="token" type="xsd:string" />
  <part name="debug" type="xsd:int" />
</message>

На стороне веб сервиса все корректно - сообщение должно быть типа cidiuser_GetInfoRequest, но указываться в запросе должна операция cidiuser_GetInfo. То есть получается, что PI неправильно обрабатывает WSDL? Вместо названия операции подставляет название типа в сообщении, так? Если так, то может быть сможете подсказать, куда можно обратиться в подобных нестандартных случаях, особенно если нужно оперативаное решение проблемы (сроки начинают поджимать) ?

И еще раз огромное спасибо за помощь!

Chaser009

Ну если разбираться некогда, попробуйте у себя а в xslt подменить корневой тэг сообщения на Get_Info, как в request в soap ui, и проверьте, что получится.

Ошибка при парсинге ответа WEB-сервиса

Кто сейчас на конференции