on 06-02-2017 12:10 AM
Hello
I'm running out of ideas on how to handle the SOAP faults. With the WSDL as in Here, there is not fault message defined
<wsdl:operation name="AnulacionLRDetOperacionIntracomunitaria">
<wsdl:input message="siiWdsl:EntradaAnulacionLRDetOperacionIntracomunitaria"/>
<wsdl:output message="siiWdsl:RespuestaAnulacionLRDetOperacionesIntracomunitarias"/>
</wsdl:operation>
The web service returns a SOAP fault for appication/data errors. Given the above definition, i'm not sure on how to handle the SOAP faults. Did try with couple of blogs from Jin Shin and others but i think that didnt help much.
Appreciate if i can get any help to get this done please.
The scenario i'm working is proxy to soap
Hi Prabhu,
If you give us some example we can help you better, for example with this example i unwrap map the fault messages:
<xsl:stylesheet version="1.0">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<ns0:RootElement xmlns:ns0="rootnamespace">
<xsl:choose>
<xsl:when test=".//faultcode">
<ns0:errorData>
<ns0:faultcode>
<xsl:value-of select=".//faultcode"/>
</ns0:faultcode>
<ns0:faultstring>
<xsl:value-of select=".//faultstring"/>
</ns0:faultstring>
</ns0:errorData>
</xsl:when>
<xsl:otherwise>
<ns0:okData>
<ns0:elementFirst>
<xsl:value-of select=".//n0:elementFirst"/>
</ns0:elementFirst>
</ns0:okData>
</xsl:otherwise>
</xsl:choose>
</ns0:RootElement>
</xsl:template>
</xsl:stylesheet>
Regards.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Prabhu!
In case of using XSLT transformation in response mapping, actually, there is no need to design any extended structures. You just check in XSLT what element exists in your response message and build response message to sender accordingly.
Regards, Evgeniy.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Prabhu!
When you call XSLT transformation against input message no schema validation is performed, so both normal response and SOAP Fault messages can be transformed. You just need to check which kind of element exists in input message: //Your_Response_Message_Type or //soap:Fault
Regards, Evgeniy.
Hi Prabhu,
When the system is throwing back SOAP fault then please see the structure of the response.
1. create a data type and message type with exact fault xml message PI is receiving from webservice. Say FaultMT
2. Create a message mapping from FaultMT to Proxy expected response . let it be called FaultMM.
3. Add FaultMM to both Outsound Service interface and Inbound service interface under fault mapping part.
4. Add FaultMM to the operation mapping in the third tab of fault mapping.
Regards
Anupam
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Prabhu,
When i have scenario with SOAP fault and i need a map to sender, i usually follow this steps:
1. On SOAP receiver i mark the check DO NOT USE SOAP ENVELOPE.
2. I do the SOAP envelope manually with XSLT, for the request.
3. I extract with XSLT the response, in this way in one XSLT i unwrap the SOAP tags and prepare for a second mapping the SOAP fault or the normal response without issues.
Regards.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for your response . That's what I have in place for (1) and (2).
But when a fault message is received I think we can have a XSLT to catch the message but the main response structures cardinality is 1...1 which fails as the source element is not found in the response. Only the fault message is provided in case of data/application errors
so how do I need to handle this?
User | Count |
---|---|
85 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.