Errorhandling on Asynchronous Soap-Calls

Apr 30, 2015 at 10:50 AM
Hi Jaimie,

how can I handle errors thrown in an asynchronous Soap-call?
On synchronous calls I can use a try/catch block, which doesn't work on asynchronous calls.
Coordinator
May 8, 2015 at 2:11 PM
Hi There.

I am currently reviewing the issue about asynchronous error handling. Hopefully I can have some more time to provide an update soon.

Kind Regards,
Jaimie
Nov 12, 2015 at 12:53 PM
This appears to be a bug in the current version of XrmServiceToolkit. The method "errorHandler" (around line 584) THROWS an error when it ought to just RETURN the error.

This bug appears newly introduced. In earlier versions of XrmServiceToolkit, the error is returned correctly and not thrown.
Nov 12, 2015 at 2:45 PM
Edited Nov 12, 2015 at 2:53 PM
We already fixed this bug -- among other things -- in our custom XST Version. In the case of XrmServiceToolkit.Soap.Fetch() all you have to do is adding the following lines at the end of the private function body assigned to variable "fetch":

Image

This issue actually affects most public methods of the XrmServiceToolkit.Soap which also offer an asynchronous call variant (by passing an optional callback function). To be more precise, you can identify those faulty contact points by searching for "doRequest(" and check where the provided "internalCallback" functions don't care about a second callback parameter called. However, this would also mean that the callback function semantics would change, since client code now must become aware of an optional second Parameter.
Nov 12, 2015 at 2:54 PM
Edited Nov 12, 2015 at 3:00 PM
@ClausAppel Unfortunately this bug (handling async SOAP Errors gracefully) at least exists already since 2.0.1 beta. (I didn't look further behind)
Mar 15, 2016 at 3:44 AM
Any updates on this issue? We're using the 2.2.1 version for 2015 update 1 (on 2016?)
If I get an error in a Soap request we want to be able to show something useful to the user, but I just get a 500 internal error in the console.
I notice in the doRequest function we have a call to getError(true, req) which returns "new Error(errorMessage)".. though I don't see that the doRequest function then does anything with it?

I've made this change which will return the Error object, and then I can test it using "instanceof Error" though not sure that's quite the intended result..

this:
if (req.status === 200) { // "OK"
    var doc = req.responseXML;
    try {
        setSelectionNamespaces(doc);
    } catch(e) {}
    internalCallback(doc);
}
else {
    getError(true, req);
}
to:
blah blah blah...
else {
    var err = getError(true, req);
    return !!internalCallback ? internalCallback(err) : err;
}