You’re offline. This is a read only version of the page.
In my previous post, I had some issues with having the error callback getting called in a Xrm.Page.data.save().then call after throwing an InvalidPluginExecutionException on CRM Online 2016. I had multiple 'conflicting' plugins/steps registered which apparently caused the success handler to always get called. That has been resolved and I can throw the exception and catch it in the error callback:
Share
ReportXrm.Page.data.save().then(
function() {
// handle save success
// Do post save stuff
},
function(e) {
// Catching the error now, so life is good
}
);
One would think that I would be able to take the rest of the day off, but unfortunately that isn't the case.
There are two issues that are outstanding: The 1st issue I can workaround (it's a hack, but...); The 2nd issue is from a response in my linked post mentions that this behavior can't be changed.
So issue #1.
In the C# plugin code, I am throwing an InvalidPluginExecutionException and I am using the 3rd overload of the constructor that takes the OperationStatus, error code and error message:
protected void ExecuteContact(LocalPluginContext localContext)
{
throw new InvalidPluginExecutionException(OperationStatus.Failed, -2136989695, "My Error Message");
}
In the javascript error handler, I'm expecting the errorCode property to be set to -2136989695 and the message property to be "My Error Message":
Xrm.Page.data.save().then(
function() {
},
function(e) {
e.errorCode; // -2136989695 expected
e.message; // "My Error Message" expected
}
);
Instead, my error code is lost and replaced with a different value of 214774640.
Xrm.Page.data.save().then(
function() {
},
function(e) {
e.errorCode; // 214774640 Actual What?
e.message; // "My Error Message"
}
);
As you can see, my error code has been replaced by something else (214774640 0xCCD3370). Why was this done? I mean the whole point of throwing the exception with an error code is to be able to retrieve that error code in javascript. Having the error code eaten is less than convenient. I have a workaround for that which involves putting a JSON string into the message and the JSON contains the real errorCode and the message. I prefer not to have to do this, but I can live with it.
Issue #2
Unfortunately, when I throw the InvalidPluginExecutionException and catch it, I get the "Business Process Error" dialog.
I mean I'm throwing the exception in the plugin and catching & handling it in javascript so I don't need the user to see the "Business Process Error" dialog.
I've done several different things to not have the dialog appear. I've tried changing the OperationStatus from OperationStatus.Failed to OperationStatus.Succeeded when throwing the InvalidPluginxecutionException without any luck (not that I expected that to succeed). I've also tried changing the error code to a positive number in the hopes that I would get lucky and codes would be treated like the old COM HRESULT where there are success and failure ranges. Of course, it was a no go. I drank several shots of Bourbon Whiskey in the hopes that the dialog would go away, but I ended up seeing two dialogs (sorry).
Is there an saveOption setting for Xrm.Page.data.save(saveOptions) that will suppress the dialog for this call? Is there a global settings to suppress this?
I have a workaround for this too, but's it's ugly and hacky and not guaranteed when it comes to async plugin calls. The hack would be not throw the InvalidPluginExecutionException and to add a field to the entity (or entities) that I can stuff the error info into in order to read it back after the save call. I can see the possibility of a race condition during async saves, so this doesn't seem like a very good approach. Polluting the entity with a field to handle an error has a big code smell to it as well.
At any rate, if the "Business Process Error" dialog can't be suppressed, what is Microsoft's recommended way of passing error information to the javascript client?
Thanks for taking the time to read this post and suffering through my humor.
*This post is locked for comments
I have the same question (0)
Folks, this was answered in another post. The answer was that Xrm.Page.data.save() will display the "Process Error Dialog". At present, there is no way to override the error.
I have two suggestions for Microsoft:
1) Add a parameter to the saveOptions (e.g. Xrm.Page.data.save(saveOptions)) that allows the dialog to be suppressed.
2) Update the MSDN documentation for Xrm.Page.data.save() to let folks know that the "Process Error Dialog" is displayed and can't be overridden.
All responses (
Answers (
