on 03-26-2015 4:09 PM
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
User | Count |
---|---|
84 | |
25 | |
12 | |
9 | |
6 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.