Soap fault Internal server error instead of exception
1
We published a webservice and sometimes the caller gets a soap fault: <soap:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>Server</faultcode> <faultstring>Internal server error</faultstring> </soap:Fault> </soap:Body> </soap:Envelope> This happens because the caller doesn't provide the right information, but because they get a internal server error, the caller always need us to provide them more information. We trace the error in the log and tell them why the call fails. The caller tried to fill an attribute with more characters than our attribute can handle for instance. We would like to return the exception in the soap fault, instead of the internal server error. Is this possible or is there a workaround to achieve this? I know the caller should respect our wsdl, but we would like to inform the caller proactive. Edit after reply Erwin: Erwin, I've considered your approach, but I don't think I will be able to use it. The domain model i've published in my webservice is simply too big to validate each attribute manually. Because mendix exposes a webservice, it generates a wsdl and xsd. In my opinion Mendix should validate the input and return a xsd validation error in the soap fault. It works like this in a normal xml-to-domain mapping and should also work in a published webservice. Edit after creating a ticket in the support portal: Ticket 14613 is accepted and scheduled for backlog.
asked
Samet Kaya
1 answers
0
Samet,
You could try to do the handling yourself.
For example make sure the webservice returns a string with the errors.
Have a field that is unlimited and check the length before placing it in the correct field, if length < max length for attribute.
If length > max length for attribute write this in a string variable.
Then handle other strings from the web service with the same field and add the errors to the string. Whenever an error occurs set a boolean variable to true to note that there are errors. Then at the end of the flow, based on the error boolean return either submit success or the error string. This method of course depends on the number of attributes to check for the amount of work needed.
I don't know if there are options to retrieve the real error and return this as the result, but this could be a way to workaround the issue and supply the client with proactive information. The client should of course be able to handle the returned result.