Custom API is a great feature that was brought to the platform to replace Actions developers used to use for years. Historically, Actions heavily rely on classic workflow infrastructure, and considering Microsoft’s efforts to deprecate classic workflows – Custom API is a brilliant alternative to Action that brought a few cool features like making CustomAPI private, the possibility to allow/disallow custom processing steps, and having “privilege” that rules the availability of a rule to a user that runs it. Fellow MVP Allan De Castro wrote a great post about it so if you’re starting fresh with Custom API I would highly recommend checking his post. Unfortunately, with all the improvements we (as developers) got one disadvantage – there is no step to run profiling on anymore and no profiling means no in-VS-debugging which is really inconvenient. In this post, I will provide one trick you can use to get debugging back.
Let’s assume that the plugin’s code looks like follows and you have already registered it in a Dataverse using Plugin Registration Tool:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
using System; using Microsoft.Xrm.Sdk; using Microsoft.Xrm.Sdk.Extensions; namespace AB.Xrm.Plugins { public class CustomAPI: IPlugin { public void Execute(IServiceProvider serviceProvider) { var executionContext = serviceProvider.Get<IPluginExecutionContext>(); //the rest of your code follows } } } |
During the creation of the Custom API for “Allowed Custom Processing Step Type” choose the “Sync and Async” option:
If API was created this way, it’s possible to add custom processing steps to it so let’s use this possibility – open your Plugin Registration Tool and add a new step to your “Custom API” Plugin:
Once the plugin step is registered it becomes possible to profile the plugin’s execution and debug it using Visual Studio and Plugin Registration Tool:
Technically, once this change is done, code is executed twice – the first time as a “Core Operation” (Stage 30) and the second time as a plugin step “Post Operation” (Stage 40). In order to avoid unexpected results I recommend for the time of debug modifying the code of the plugin the following way:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
using System; using Microsoft.Xrm.Sdk; using Microsoft.Xrm.Sdk.Extensions; namespace AB.Xrm.Plugins { public class CustomAPI: IPlugin { public void Execute(IServiceProvider serviceProvider) { var executionContext = serviceProvider.Get<IPluginExecutionContext>(); if (executionContext.Stage == 30) { return; } //the rest of your code follows } } } |
The modification of the code doesn’t let the plugin code execute the first time – as a “Core Operation”. Don’t forget to remove this code and unregister the plugin once you are done with troubleshooting!
1 Comment