It’s common knowledge that Azure functions can address one of the most annoying issues in Dynamics’ plugins which is the 2-minute timeout limitation, along with others like the ability to incorporate multiple DLLs in your code or to overcome the limitations of code that runs in sandbox mode. There are plenty of posts and articles on this topic.
Nevertheless, it’s important to understand the differences between these technologies so that we can make informed decisions about whether and how to use them.
How do webhooks do the magic?
Dynamics 365 version 9 came with a new feature called webhooks, which allows making HTTP requests to launch an Azure function instead. These webhooks are registered using the provided plugin registration tool and can be associated with any of the events (create, update, etc.) a plugin would.
These webhooks would send an image of the execution context to your Azure function and it would be your job to parse it and then do whatever you need to do with it. Just like you would do with a plugin.
Here is where the similarities end. You have the execution context but that’s all you have. If you wanted to do anything with it in Dynamics like updating an entity or creating a task, you would need to get an instance of the service object (hint: Xrm.Tooling.Connector).
Event stages are just not the same
At this point, you may start to realize that the code you used to write based on which stage in the event pipeline you were, would need to be refactored.
For example, in plugins when you want to manipulate the current entity before the record is saved, you would make your plugin trigger on the Pre-Operation stage and you would just manipulate the “target” input parameter accordingly. In terms of code we could see something like this:
Entity entity = (Entity)context.InputParameters["Target"]; entity[“myAttribute”] = “myValue”;
And that’s all you would need. When the operation completes, your changes would apply without further coding.
If you use a webhook to achieve the same functionality, even if you registered it to the Pre-Operation stage of your operation, your existing code would just not work. The same syntax would not produce an error but it would just not do anything. As I mentioned earlier, you would be working on a new instance of the service object from Dynamics plus the context received in the request payload, which is just a copy of the context, not the actual context object.
Are we all out of luck?
Not really. Even if these instances of the service object don’t know about each other let alone synchronize their activities, you could refactor your code to achieve the same effects.
In this example about modifying a value on the Pre-Operation stage, we would have to do it differently. Perhaps we could use a combination of several Azure functions and a Service Bus or even a combination of several Azure durable functions.
Is there a verdict, your honor?
Azure functions definitely address some of the shortcomings of plugins, which have plagued us for years, and definitely make XRM development much easier, and in some cases even possible.
It’s important to acknowledge that they are not the same thing and if you are planning to migrate your existing code base and convert your plugins to Azure functions, you will have to understand that some cases cannot be migrated word for word and will need some refactoring.
Besides, there are certain limitations to be aware of, such as the size of the JSON payload which is currently set to 256K. This payload includes the Dynamics context, so you would need to be careful with the pre and post images passed, which could easily exceed that limit if all attributes are retrieved.
Another potential issue is performance. The mere fact of re-hydrating the context object, plus getting a new instance of the service object, does take time. So, if your existing plugin is not affected by any of the above-mentioned limitations and you have concerns about performance, you are better off staying with your plugin-based solutions.
In regards to overcoming the 2-minute plugin timeout limitation, Azure functions will offer some relief; however, we also need to understand that execution duration in Azure functions is driven by your payment plan. Basic standard plans will only give you a default timeout of 5 minutes which can be extended via configuration to 10 minutes.
Will I rush tomorrow to refactor all my plugin library? Certainly not. However, it’s always nice to have more weapons in the arsenal.