Sonoma Partners Microsoft CRM and Salesforce Blog

Running Server Side Code from the Microsoft Portal (Online)

Today's blog post was written by Matt Dearing, Principal Developer at Sonoma Partners.

Executing server side code from the Microsoft Portal (online) has some limitations. By default CRUD plugins and asynchronous workflows can be triggered, however, if you want to add your own custom button to the portal and have it execute synchronous server side code, or if you have a liquid template where you want to execute some server side logic to determine what to render, a pattern we call "Web Service Plugins" will work.

When web resources became a part of the CRM platform (back in CRM 2011) we used a pattern we internally called "Web Service Plugins" to execute server side code. The basic idea was have an entity called prefix_webservice and make a "RetrieveMultiple" request to it with no instances persisted in CRM. The entity would have 2 fields: prefix_logicclass and prefix_data. We'd then have a plugin registered on post "RetrieveMultiple" of this entity that would look at the query's prefix_logicclass to determine what server side class to instantiate and execute, it would pass along the value in prefix_data, generally serialized JSON, to this logic class. The benefits included things like: bundling http calls, reuse of server side logic, avoiding timeouts (could batch calls from the client and make sure each could run in under 2 minutes), etc. Custom actions have replaced "Web Service Plugins" for us in CRM, but the portal does not allow direct access to executing custom actions. Luckily, we can leverage the "Web Service Plugins" pattern from the portal.

Take the following example where we will call a custom action "SomeAction" from the portal. There are a few parts we need to configure to make this happen. First the liquid template:

You'll notice this liquid template is executing fetch and writing out a result. The "Mime Type" of this template should be set to "application/json".

Next is javascript you would add to the portal to execute the liquid template:

It's a simple ajax call leveraging jquery. It is making a GET request (you could also POST) to the liquid template's web page (with a partial path of "SomeAction") passing a couple inputs and a "stopCache" value. The "stopCache" value helps to ensure the output of our liquid template won't be cached but will instead actually execute the fetch, therefore executing our plugin. When the result comes back a button could display, a grid could hide, a message could be alerted, etc.

Next is the Web Service Plugin that handles routing the request:

This plugin has a single plugin step registered for post of "RetrieveMultiple". The plugin starts by getting the prefix_logicclass and prefix_data from the query. It then dynamically instantiates the logic class by name (leveraging reflection) and calls a specific method (in this case "DoWork"). Next it JSON serializes the result for returning to the client that made the request. For this to work all of the logic classes need a common interface (in this case an abstract base class). As new logic classes are added no change needs to be made to the plugin class or the plugin steps.

Finally here is an example of a logic class:

This method executes a specific action named "prefix_SomeAction" and passes along input then returns the output. It could be made more generic to support many custom actions especially if they are using more generic string inputs and outputs that include json serialized data.

Although not as straight forward as being able to make CRM service calls directly from the portal or being able to write server side code, a pattern like the above does give us the ability to still execute logic to help extend our customer's portal implementations.

Topics: Microsoft Dynamics 365