async soap sender violates WSDL spec ?

[Former Member]

Hi all,

We run a SAP PI 7.10, and we integrate with a TibCo bus.

I want async communication, and since we lacked time to deploy JMS,

we decided to use async SOAP.

The SOAP FAQ covers async communications patterns from the PI side.

However, during testing it turns out that some errors can cause a soap fault back to the TibCo client.

My TibCo friends point out to me that the spec of WSDL (not SOAP) by W3C

describe "one-way communication" like this :

<wsdl:definitions .... >

<wsdl:portType .... > *

        <wsdl:operation name="nmtoken">

           <wsdl:input name="nmtoken"? message="qname"/>

        </wsdl:operation>

</wsdl:portType > </wsdl:definitions>

so, without a fault as response-possibility.

- Am I correct in concluding that this behaviour of PI is not conforming to the WSDL spec ?

- Is there a way to avoid sending faults, just send empty suppress these faults in the body of

  the soap message returned to TibCo (but not the HTTP code) ?

Also, I noted that the generated WSDL from the sender agreement (my contract with the client)

only describes the input message and does not specify that a fault can occur.

It also does not describe the empty soap reply issued as a measure of success.

Message was edited by: R. Van Aalst : add WSDL generation remark

[Former Member · Accepted solution]

Hi R. Van Aalst,

please have a look at the WSDL of an async outbound service interface. You will see that only input messages are defined which implies one-way communication pattern. No violation of WSDL spec!

<wsdl:operation name="Test_async_out">
         <soap:operation xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" soapAction="http://sap.com/xi/WebService/soap1.1" />
         <wsdl:input>
            <soap:body xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" use="literal" />
         </wsdl:input>
      </wsdl:operation>

Nevertheless SOAP is based on HTTP. HTTP requests always result in an HTTP response with information about the status, e.g.

• HTTP/1.1 200 OK: SOAP call was successfully delivered to the endpoint, which does not mean it has been processed successfully by the underlying application
  • no SOAP message has to be returned in one-way communication
• HTTP/1.1 500 Internal Server Error: server has some trouble receiving the request (often unvalid XML), in this case, TibCo has to re-deliver the message, as in one-way communication the correct delivery of the message is essential, the processing status is not of interest to the sender
  • a <SOAP:Fault> may be returned with error message from the server
• HTTP/1.1 401 Unauthorized, TibCo has to re-deliver the message
  • a <SOAP:Fault> may be returned with error message from the server

In which situations occurs the soap:fault fallback and which HTTP status is received?

TibCo only has to react if the HTTP response from the endpoint is other than 200. For these cases, the soap:fault response may contain important error information.

Best regards, Martin

[Former Member · Accepted solution]

Thanks you for responding, Mr Sommer.

The WSDL produced by my PI interface is indeed as you say.

My point is that this WSDL does not inform the client that it needs to expect to receive a response (an empty soap envelope), nor does it inform that the SAP server will in some cases return a soap fault (together with a non-200 HTTP code).

the soap adapter FAQ does tell me these responses are to be expected and dealt with by the client, but they are not in the WSDL.

I think either these soap responses should be in the WSDL,

or some button should be available in the soap adapter which will suppress any

response (on soap-level).

Otherwise the actual behaviour of the soap adapter is not in line with the WSDL contract.

Apparently the point is that TibCo regards the WSDL as a contract for implementing the client, describing what reponses and soap faults can be expected (none in our case). The behaviour upon reception of actual reponses or faults is then not defined. 

As far as I can see, this is a correct usage of the WSDL, so I must agree with them when they say the behaviour of the SAP async soap interface is not conform the standards, specifically the WSDL specification of W3C.

I hope I can obtain something, or some explanation in order to restore faith is the reliable

operation of the async soap sender, as otherwise I wil be forced to implement a high volume interface synchronously. This will undaoubtedly create much problems...

[stefan_grube · Accepted solution]

 My point is that this WSDL does not inform the client that it needs to expect to receive a response (an empty soap envelope), nor does it inform that the SAP server will in some cases return a soap fault (together with a non-200 HTTP code).
....
Apparently the point is that TibCo regards the WSDL as a contract for implementing the client, describing what reponses and soap faults can be expected (none in our case). The behaviour upon reception of actual reponses or faults is then not defined.  

Please give me the reference to W3C where you found, that the SOAP response should not be an empty SOAP envelope or fault messages are not allowed, when they are not mentioned in WSDL. I am very curious about this.

The behaviour of the SOAP adapter is the same since the very first beginning of PI, and that are 10 years now.

When I did my first scenarios with PI SOAP adapter, I thought, this is easy as SOAP is simple and easy to understand. I was wrong. To do a system integration with SOAP, it is necessary to understand the SOAP, XML and HTTP very well. Failure in system integration with SOAP are based on ignorance of basic protocal standards by development people.

To make it short: Just trust SOAP adapter to give a correct response based on SOAP protocol standards. When there is an issue, the cause is mostly the connected system. 

[Former Member · Accepted solution]

Hi again, I agree with Stefan: TibCo has to do some homework here. TibCo just has to ensure delivery of the message (HTTP status 200). Delivery is a matter of the underlying protocol used, in your case HTTP. If the message was not correctly delivered, TibCo has to react.

I suggest showing the standard to your TibCo guys, esp. section 6.2 SOAP HTTP Response:

SOAP HTTP follows the semantics of the HTTP Status codes for communicating status information in HTTP. For example, a 2xx status code indicates that the client's request including the SOAP component was successfully received, understood, and accepted etc.

In case of a SOAP error while processing the request, the SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error" response and include a SOAP message in the response containing a SOAP Fault element (see section 4.4) indicating the SOAP processing error.

This behavior is part of the standard, the WSDL does not have to define it since it is implied.

Best regards, Martin

[Former Member · Accepted solution]

Thanks for the replies again,

I agree that the HTTP reponse is the only item to use in order to determine delivery (into SAP PI in my case).

However, when two of my colleagues tested this setup they got an HTTP 200 + soap fault from SAP PI. This was cause for concern. However, I';'m not able to reproduce this on my own interface, and I suspect that the SAP PI interface they used for testing was not finished yet.

I'll investigate that.

nevertheless, for my education : if a HTTP200 is received, it is save to ignore the soap faults possibly returned ? (save in the sense that no message can fall between the cracks, i.e. AtleastOnce guarantee) 

HTTP/1.1 200 OK
set-cookie: MYSAPSSO2=AjQxMDIBABgAOAAxADIANwAwADUAIAAgACAAIAAgACACAAYAMQAwADADABAARABYAEkAIAAgACAAIAAgBAAYADIAMAAxADIAMQAxADIAOQAxADEAMAAwBQAEAAAACAYAAgBYCQACAEX%2fBFkwggRVBgkqhkiG9w0BBwKgggRGMIIEQgIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIIC%2fzCCAvswggK7AgcgEQYwCRFGMAkGByqGSM44BAMwZDELMAkGA1UEBhMCREUxHDAaBgNVBAoTE1NBUCBUcnVzdCBDb21tdW5pdHkxEzARBgNVBAsTClNBUCBXZWIgQVMxFDASBgNVBAsTC0kwMDIwMTc4MzAwMQwwCgYDVQQDEwNEWEkwHhcNMTEwNjMwMDkxMTQ2WhcNMzgwMTAxMDAwMDAxWjBkMQswCQYDVQQGEwJERTEcMBoGA1UEChMTU0FQIFRydXN0IENvbW11bml0eTETMBEGA1UECxMKU0FQIFdlYiBBUzEUMBIGA1UECxMLSTAwMjAxNzgzMDAxDDAKBgNVBAMTA0RYSTCCAbcwggEsBgcqhkjOOAQBMIIBHwKBgQD%2fy%21rRgt2A559K9P8A0ozcJgewJXjc4J9cdTeblJ57mAOy29WqUaPibt3XsOwIKtvSpGSaekAr5gg6phJHRg9KuZ7G4KqeF4L5CEE%21JLlgiX9%2fGqo3ahaD0Vzt9OCpyRgK67cZhtVwnUJvX8Io8d4X9jwwmO%21YTAKBtEun5encnwIVAI0Y697jOLD45ZSz0aeN5u9MUEU1AoGBAMmGObrEJFol5xKCP%21oYHVMbEyBzCsdFco0LhfUf1StNl3X9Ck28NHvYMeHY2UgUgpi82mBT0F6wQjVVx%21u5syTxsiwegZJHaDrP7l7uUTJQsX9GTBazNZgaUQcITD63%21r%2f750RNpMCyuDwxFGb7QVoyc4K5uYGgZ1VqdA4GEAAKBgBrEPrbBNRcEv38nTiOIp6N%2fSlalWXIeqomvrlIVkd24qHtKwtN7JjlXSUelUsvlNGgfb8tosUfi2liUU8u81zLCm0ehrqx9KB4NQEErRz7YSLlcBRtll9be0nPSfr9Ot6RYkAt0wRWEEFoJ04Tg%21LSaAh%21flbnaFClngVwseGYEMAkGByqGSM44BAMDLwAwLAIUJCtYc6l8de1TQkgAbeX05rRP1ZUCFAUjupJ%21NTqYXCPqjHs9TNqe610FMYIBHjCCARoCAQEwbzBkMQswCQYDVQQGEwJERTEcMBoGA1UEChMTU0FQIFRydXN0IENvbW11bml0eTETMBEGA1UECxMKU0FQIFdlYiBBUzEUMBIGA1UECxMLSTAwMjAxNzgzMDAxDDAKBgNVBAMTA0RYSQIHIBEGMAkRRjAJBgUrDgMCGgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTI5MTEwMDA2WjAjBgkqhkiG9w0BCQQxFgQUW4%2f4T1%21uOcheJXSTQaOdmtg3JA0wCQYHKoZIzjgEAwQvMC0CFQCDyqoWTJK4Rzs4ohBSdqZd3rw0ZwIUR4jyakZfE3Iy4pPVxUG1wbjTNJs%3d; path=/; domain=.ee.intern
content-type: text/xml;charset=utf-8
content-length: 637
x-xmb_ws_encoded: version=1%2e0&Sender.Party=%3a%3a&Sender.Service=DENCLNT100&Interface=http%3a%2f%2f%2enet%2fmarktrol%2fmetering%2fmasterdata%5eSIIA_MasterDataMeteringResponse&Receiver.Party=%3a%3a&Receiver.Service=TIBCO_MDD&To.Interface=http%3a%2f%2f%2enet%2fcdm%2fmarktrol%2fmetering%2fmasterdata%5eSIOA_MasterDataMeteringResponse&MessageClass=SE&ProcessingMode=S&ConversationId=&MessageId=50B33F80-9E11-7227-E100-00000AD53F88&RefToMessageId=50B33F7B-9E11-7227-E100-00000AD53F88&QualityOfService=BestEffort&TimeSent=2012-11-29T11%3a00%3a06Z
soapaction: 'http://sap.com/xi/XI/Message/30'
content-id: <soap-50B33F819E117227E10000000AD53F88@sap.com>
sap-xi-messageid: 00000000000000000000000000000000
server: SAP NetWeaver Application Server / ABAP 710

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
<SOAP:Fault><faultcode>SOAP:Server</faultcode><faultstring>System Error</faultstring><detail><s:SystemError xmlns:s="MAPPING.EXCEPTION_DURING_EXECUTERuntime" _mce_href="http://sap.com/xi/WebService/xi2.0"><context></c... exception occurred during application mapping com/sap/xi/tf/_mm_MasterDataMeteringResponse_MV_T~; com.sap.aii.mappingtool.tf7.IllegalInstanceException: Cannot create target element /ns1:MT_MasterDataMeteringResponse. Values missing in queue contex~</text></s:SystemError></detail></SOAP:Fault></SOAP:Body>
</SOAP:Envelope>

[Former Member · Accepted solution]

Hi again, looks perfect considering the communication pattern is asynchronous

The message was successfully delivered to the endpoint, the server accepted the message (valid XML!) and confirmed with HTTP status 200. The sending application has done its job.

Now the server started processing the message and processing failed with a mapping error. Should this concern the sender? No, since its asynchronous communication. The receiver has to investigate why the message could not be processed - this depends on your processing logic, in this case a mapping.

Regards, Martin

[stefan_grube · Accepted solution]

version=1%2e0&Sender.Party=%3a%3a&Sender.Service=DENCLNT100&Interface=http%3a%2f%2f%2enet%2fmarktrol%2fmetering%2fmasterdata%5eSIIA_MasterDataMeteringResponse&Receiver.Party=%3a%3a&Receiver.Service=TIBCO_MDD&To.Interface=http%3a%2f%2f%2enet%2fcdm%2fmarktrol%2fmetering%2fmasterdata%5eSIOA_MasterDataMeteringResponse&MessageClass=SE&ProcessingMode=S&ConversationId=&MessageId=50B33F80-9E11-7227-E100-00000AD53F88&RefToMessageId=50B33F7B-9E11-7227-E100-00000AD53F88&QualityOfService=BestEffort&TimeSent=2012-11-29T11%3a00%3a06Z

&QualityOfService=BestEffort means: a synchronous call.

it should be ExactlyOnce for asynchronous calls.

[Former Member · Accepted solution]

Good point Stefan, R. Van Aalst you have to set the "quality of service" in the SOAP sender channel to "exactly once", as well as generate and deliver a new WSDL to TibCo.

[Former Member · Accepted solution]

Thanks, this seems indeed the problem,.and why

I could not reproduce the issue in my own interface.

If anything else pops up, I'll report back for a bit more guidance.

Thanks for your replies !