Softstuff Consulting
My occasional musings of a technical nature
  • Send us a message
  • About Softstuff Consulting
  • Privacy Policy
  • Main Website
C# , Dynamics365 , Thoughts

Throw exceptions in Dynamics365 workflow plugins, or don’t

by Ian Blair January 7, 2020 2 Comments

When writing workflow plugins for Dynamics365 it seems that standard practice if an exception or error appears in the code is to throw an exception which will pop up on the interface for the user, or appear in the logs if it isn’t a real time workflow.

The problem with this approach is that when the exception message is shown it can be a little scary for users as often the text is taken directly from the Exception itself. This means that users see generic system error messages like “Null Expection Value” instead of the more elegant “An error has occurred”, or something more meaningful to the user.

I would propose a simple change of adding two extra output fields to the plugin, on a simple yes/no bool field called “Success”, and the other a text field called “ErrorText”, 

[Output("Success")]
public OutArgument<bool> Success {get;set;}

[Output("ErrorText")]
public OutArgument<string> ErrorText {get;set;}

In the action code when an exception is thrown and caught within the plugin, instead of throwing an InvalidPluginExecutionException exception directly with the error text, the “Success” field should be set to false and the “ErrorText” field can be set to the error message before the plugin terminates.

protected override void Execute(CodeActivityContext ActivityContext)
{
   try
   {
     // do stuff here
     Success.Set(ActivityContext,true);    
   }
   catch(Exception ex)
   {
        Success.Set(ActivityContext,false);
        ErrorText.Set(ActivityContext,ex.message);
    }
}

Inside the plugin as there is a single main catch() block, then validation errors etc can throw an Exception which will be caught and passed out of the plugin and back to the workflow. The user can then decide how these get handled.

So instead of the plugin throwing the exception and stopping the workflow, the workflow checks for the status of the “Success” field and stops the workflow. This enables errors to be handled more gracefully than just crashing out of the workflow process.

Setting the stop workflow step to “Canceled” for a real-time workflow will cause the transactions to be rolled back in the same way that throwing an exception inside a plugin would.

This is probably most useful when writing plugins that may be used more than once to provide additional flexibility.

A possible extension to this may be to include another input field as a simple bool called “DoNotThrowExceptions”. This can be set with a default value of false so that the plugin behaves as a normal plugin with exceptions being thrown, or if the creator of the workflow sets it to true then the results will be returned via the “Success” and “ErrorText” fields. 

protected override void Execute(CodeActivityContext ActivityContext)
{
   try
   {
     
     // do stuff
     // or throw an explicit exception, perhaps for validation
      if(myval!=expected) {
           throw new Exception("validation error - field1"); }
      Success.Set(ActivityContext,true);
   }
   catch(Exception ex)
   {       
        Success.Set(ActivityContext,false);
        ErrorText.Set(ActivityContext,ex.message);
        if(!DoNotThrowExceptions){
            throw new InvalidPluginExecutionException(ex.message);
        }
    }
}

[Input("Do Not Throw Exceptions")
[Default("false")]
public InArgument<bool> DoNotThrowExceptions {get;set;}

[Output("Success")]
public OutArgument<bool> Success {get;set;}

[Output("ErrorText")]
public OutArgument<string> ErrorText {get;set;}

This way the plugin will behave normally and throw exceptions, but if you need a scenario where more control is required then the “Do Not Throw Exceptions” field can be set to true in the calling workflow step and the results will be returned to the workflow instead.

Having a single exception handler means that both runtime errors and also data validation errors can be handled with exceptions and they are all returned to the workflow. Additional logic could be included especially if legacy Dialogs (to be depreciated) are being used to provide field level validation.

  • Previous Format numbers in Javascript5 years ago
  • Next Shadowed text in CSS5 years ago

2 Replys to “Throw exceptions in Dynamics365 workflow plugins, or don’t”

  1. BigOwl says:
    January 8, 2020 at 12:50 pm

    Going to give this idea a go, have never liked the generic exception method of returning errors or even simple messages back to the user from a plugin. So simple.

    Reply
  2. TC Sharpe says:
    February 10, 2020 at 1:20 pm

    Interesting idea, especially if you have both methods for just a few extra lines of code. I might start doing this.

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • How to make your Powershell scripts more annoying
  • What motherboard is in my PC
  • A Dynamics365 plugin thought experiment
  • Registering a Dynamics365 plugin and I get an error
  • Going back in time with Dynamics365

Categories

  • Bootstrap
  • C#
  • CSS
  • Dot Net Core
  • Dynamics365
  • JavaScript
  • Powershell
  • T-SQL
  • Thoughts
  • VBScript
  • Visual Studio
  • Windows
  • Xamarin

Recent Comments

  • S0ftStuffB055 on Call a Dynamics365 workflow from JavaScript
  • Siva on Call a Dynamics365 workflow from JavaScript
  • TC Sharpe on Throw exceptions in Dynamics365 workflow plugins, or don’t
  • BigOwl on Throw exceptions in Dynamics365 workflow plugins, or don’t
  • CRMGod on Access a Dynamics365 embedded webresource

Archives

  • January 2021
  • May 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • October 2019
  • June 2019
  • May 2019
  • February 2019
2025 Softstuff Consulting. Donna Theme powered by WordPress
  • Twitter