Implementing complex logic in CRM

CRM provides several possibilities to extend the standard functionality with custom written code – Plugins, Workflow Activities and javascript libraries.  However, when it comes to complex logic, you will find great difficulties in using plugins or workflows. Let’s say you have an Use Case when you have to generate thousands of records (say invoices), map them to other records (say Accounts) and create other thousands of Activities – all in one shot (say when the user clicks a custom button on your toolbar)! Why plugin might not be the best choice?

  • Plugins are hard to debug. One of the nightmares of CRM developers is to track an exception that happened inside a complex plugin – logging is limited and debugging is cumbersome or even impossible
  • Plugins / Workflows time out. If you write complex logic in your plugin that has to read / insert / updates many records, you have no predictability about what will happen when your database will reach millions of records. It might happen that your plugin execution time will reach the timeout limit and re-engineering / optimizing your plugin would be a task that you’d want to avoid.

The reasons listed above might be enough to make you think of alternatives. What I find as a good approach (I used it in my CRM projects) is to isolate the complex logic inside a windows service and call the logic from CRM context (plugin / workflow / javascript). A step by step description follows:

  • Build your windows service. Encapsulate the complex CRM logic inside your windows service, add a lot of logging and make your code testable
  • Expose the windows service functionality via a Web Api hosted inside your windows service
  • Call the Web Api from your plugins or javascript code

CRM - complex logic

A slightly different version of the above is not to use  a windows service, instead replace it with a classical WebService that would expose the complex logic. It is just a matter of preference. I find windows service approach slightly better, because I do not need to rely on IIS (making the architecture more flexible) as first note. As second note – usually when you have to deal with complex tasks in CRM, you might be asked to create different daily or import procedures, which normally would reside inside a windows service.

Please also note that the above apply only to CRM On Premise. If you have to deal with CRM Online, then you will need to adapt your architecture to Azure ecosystem. Things become more complex with CRM Online (because you will not be in the same network, as it is mostly the case with CRM On Premise) but for sure a similar solution can be found for CRM Online.

Leave a Reply

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