cancel
Showing results for 
Search instead for 
Did you mean: 

Error during parsing the received XMB message

robert_warde4
Active Participant
0 Kudos

Hi,

We have a SOAP to ABAP Proxy interface and have a very odd problem. When testing with SOAP UI it works. When testing with a third party web shop it fails. We are using the same configurations such as input payload, endpoint, PO user and password etc. My message works and their fails. Now I would understand if all messages failed but why should it make a difference who is sending the message to the SOAP web service IF everything is the same.


I have checked on SAP Support and found a number of hits regarding configuration and authorizations BUT why does the call work for one user (me via SOAPUI) and not another (developer via Web Service) when everything is the same

Error during parsing the received XMB message.

SOAP: Call failed: com.sap.aii.af.sdk.xi.srt.BubbleException: HTTP Response Received. Status Code = 500 [null "null"]

SOAP: Error occurred: com.sap.engine.interfaces.messaging.api.exception.MessagingException: com.sap.aii.af.sdk.xi.srt.BubbleException: HTTP Response Received. Status Code = 500 [null "null"]


FYI we have just upgraded to 7.31 SP14 (from SP8) and are using a single stack.

Accepted Solutions (1)

Accepted Solutions (1)

nabendu_sen
Active Contributor
0 Kudos

Hi Robert,

We had similar kind of issue and later found this was an issue with Timeout. PI has default Timeout as 3 seconds. But Sender (ARIBA) WebService had less than that. So Sender were closing the thread before PI throws exception.

You can find out the actual value of Timeout at Sender side and use the same in your SOAP UI.

More details: http://www.soapui.org/working-with-soapui/reference/preferences-and-settings.html

Regards,

Nabendu.

Answers (2)

Answers (2)

robert_warde4
Active Participant
0 Kudos

Hi

I have found the issue, It was due to the SOAP action being populated with a value ECC doesn't like. It was too long. We are now looking at changing this dyanmically.

Rob

Former Member
0 Kudos

Hi Robert,

I don't know the answer but maybe you can get some more clues about the issue using the XPI Inspector. Have you ever tried it?

Are you using HTTPS? Maybe there could be an issue of certificate trusting.

Ryan-Crosby
Active Contributor
0 Kudos

Hi Robert,

We are having a similar issue on our system but in a very specific scenario.  It is occurring when we activate principal propagation and direct messages to our ECC message server for processing.  If we direct the messages to a specific ECC instance everything works fine and when we disable principal propagation and provide the login credentials for the same user everything works as expected.  We are thinking it may also be related to some trust issue with certificates as well but the error message coming back isn't very informative - so Aaron may be onto something with the trust suggestion.

We have a message open with SAP and they are investigating the error so if I find anything out that might be helpful I'll let you know as well.

Regards,

Ryan Crosby

Former Member
0 Kudos

Same advice to you Ryan if you've never tried XPI. It can shed some light on certificate issues also. You basically start a trace, reproduce the error, and then look through all the stuff XPI collected for you during that timeframe. It highlights many potential errors.

-Aaron

Ryan-Crosby
Active Contributor
0 Kudos

Hi Aaron,

Yes, we used it and examined the trace in detail but the only message we see in the XPI trace on the PO side is the error 500 message that Robert mentioned above.  It says there was an empty payload but if we disable principal propagation and target the same system as the endpoint it works.

Regards,

Ryan Crosby