Coding Practices: Workflows and Plugins

Hey!  I wanted to take a few minutes and review all the various tools and processes that I use when writing a Plugin or a Workflow for Dynamics 365.  Plugins and Workflows provide automated ways of extending the behavior of Dynamics 365.  You can trigger integrations with disparate systems when a certain action takes place.  For example when an account gets deleted or removed it will send a message to Business Central to remove that particular customer.  Basically think of them as ways to extend the functionally indefinitely.  There are differences between Plugins and Workflows as to why you would pick one over the other but I’ll save that away for a separate post.

• Code Editor
• Merge Tool
• c#
• Code Repository
• Way to register the assembled dll

• Visual Studio
• ILMerge
• c#
• Azure Devops
• Plugin Registration Tool

Most of this is obvious.  Need some sort of editor.  I know it is romantic to ‘rebel’ and use vi…  But this is real life.  We can code faster in Visual Studio than anything else; and it has all the integration with the code repositories that we use.  It also has all the integration with nuget; so all the .xrm package can stay up to date.  We use ILMerge to combine dlls.  Dynamics 365 will not allow you to upload multiple dlls or supporting dlls.  So if you are using a helper class to drive behavior of the custom code you’ll have to merge it or use shared libraries; which is terrible idea.  There’s a great write up on using ILMerge with Visual Studio here.  This document is a bit dated but nothing has changed.  Just set the properties on the assemblies/references and build away.  Keep in mind that you need to have .net framework 4.6.2 installed.

 

Dynamics 365 also requires a strong name key file for signing your Plugins/Workflows before adding them to an instance with the Plugin Registration Tool.  See this link.  It is a good idea to use a different strong name key file for each of your clients.  Think of them like a http cert; wildcard vs issuing one for each server.

Once you have written your code, merged, signed and tested it properly you can now deploy it.  The Plugin Registration Tool can be downloaded from nuget and extracted.  I would avoid this as it has failed to work.  What has worked is executing the power shell script that is provided by Microsoft and having it build the tool out.  See this location for the information on how to run the tool.

Now that we understand the fundamentals of writing a Plugin or Workflow there are a few things that should be done to make the process as simple as possible.

Put all the logic in a helper class and just pass the entity or needed pieces of data into the helper

• This will make it much easier to test out the code.  The Plugin/Workflow code is kept very simple.  Write test cases to test out the helpers.  These helpers can now be called by other applications.  This process will keep your code much more modular and keep your plugins & workflows from getting bloated.

Test Test Test

• Test all your code.  Create a test project in Visual Studio and test out your helpers.  Then, after they work appropriately, run another test by setting the needed condition in Dynamics 365 and observing the result.  This should all be done automatically.  Do not manually test as a rule.  Resist the urge.  Use asserts and make sure that your code behaves as excepted.

Document

• Each of your class files should have a link back to your task/devops/jura/etc.  Make sure that a non technical user can figure out what the system is suppose to do without reading the code.  If someone has to read your code to figure out what the system is doing then you have an issue that needs to be addressed.  Each class should link to a task that give three or four sentences about what the class is doing.

Logging

• Make liberal use of the plugin trace log.  Dynamics 365 has a wonderful, built in, logging mechanism.  You don’t need to use apache logging, file logging, create a custom entity or anything else.  Just use it.  Your code should always log.  The CRM administrator can always just shut off logging.

Catching Exceptions

• Plugins and Workflows no longer allow you to catch the exception from Dynamics 365 and continue processing.  You have to stop the process at that point.  If you try to get around this Dynamics 365 will still throw an error.  This is another reason to not write your own entity for logging.

Break your plugins/workflows into different assemblies

• As your project grows don’t be afraid to group your plugins/workflow code into different assemblies.  This make testing easier, it helps with not touching processes that have nothing do with that you are addressing and the plugins/workflows will register faster.  Remember that any change to an assembly should demand that all the processes/methods should be retested as the code has changed.  You can mitigate this risk/body of work by just breaking the plugins/workflows up.

Hopefully this gives you some good ideas on how to organize, document, write, test and deploy your plugins/workflows.  It’s really not that hard.  Happy coding!