Writing server side code with Microsoft Dynamics 365

Server sided developments in Dynamics 365 allow us to interact with the application data and processes. Primarily we can add coded elements directly into the application itself, or communicate with 365 from our own external applications.

This article is part of a series

Within 365

We have two choices for adding server side code into the application, plugins or custom workflow activities (CWA). These are developed using assemblies from the 365 SDK. Almost every event – create, update, assign, and many more – that occurs in 365 starts an event pipeline. These events can be subscribed to by plugins or workflows. The workflows can be used to execute CWAs. The plugin or CWA can then be used edit or change the execution of the event, or perform an entirely new action.

Plugins offer the greatest control and features as they are directly plumbed into the event pipeline. You have detailed control over event behaviour using code. However, they are also require a (little) bit more effort to build and deploy.

Custom workflow activities provide reusable chunks of logic that you place in workflows. They are a little bit easier to build and deploy. They tend to be more reusable than a plugin. That said plugins can offer solutions CWA can’t achieve in some scenarios. When I can I typically go for a CWA first, and then fall back on a plugin if required.

Outside 365

Outside of the immediate context of 365 you can build a wide variety of applications. The applications you build will interact with 365 using the web services. The web services themselves have evolved and changed significantly between major CRM versions. For a .Net developer the SDK with strongly typed classes has been always available making access and development easy.

In the past non-.Net developers tended to get the short end of the stick and had to communicate directly with SOAP endpoints with little support. More recently the situation is far improved, the new Web API is specifically designed to be platform neutral, providing straight forward access to a wide range of application features from any platform.

Reporting Services

If you are so inclined, you can create reports using SRSS SQL or Fetch XML based reports. This is a bit old hat these days and I tend to recommend the use of Power BI for anything complicated.

PowerShell

More of an administration tool than anything else, 365 ships with a range of PowerShell commands you can use to manage deployments.

Original Post https://woodsworkblog.wordpress.com/2017/06/25/writing-server-side-code-with-microsoft-dynamics-365/