thinking in rules

Running Business Logic On Demand with Dynamics CRM 2013 Action Processes

John Hauppa | 2/24/2014

Dynamics CRM 2013 supports a new feature that allows developers and configurators to run custom business logic on demand using server-side events. In previous versions of CRM, the server-side event model was restricted to out-of-the-box events such as insert, update and delete events. With CRM 2013, custom events can now be added to the farm to accommodate many new types of custom business processes.

These custom events are defined using “Actions” which are created as “Processes” in CRM. In earlier versions of CRM, Processes could be used to execute asynchronous business logic with workflows. In CRM 2013, a Process can run synchronously if it has been marked as an Action.

Action Processes may prove useful whenever business rules must run synchronously, and on-demand. This new feature provides system integrators a clear path to providing custom behaviors in Dynamics without using some of the painful workarounds required by CRM 2011.

Executing Custom Business Logic on Demand

Once an Action has been defined, it can be used to execute InRule rule requests on demand in two different ways:

  • A custom plugin can be created that calls out to the rule engine. This plugin can be registered to trigger on the new custom event that has been defined in the Action.
  • A custom CodeActivity can be created that calls out to the rule engine. This CodeActivity can appear as a “step” that is authored by a system configurator when creating the Process.

ActionStep900

WorkflowStep900

Triggering Your Business Rules

After the Action Process has been authored and activated in CRM, it can be triggered on-demand using an HTTP call to the Organization Web Service published by Dynamics. Dynamics 2013 includes a new SOAPAction on the Organization Service called “Execute”. The Execute signature takes an event name and a list of input parameters. When this service is invoked, it will trigger any plugins that have subscribed to the custom Action event, as well as trigger workflow steps that may have been authored in the Action Process. Either the plugin or the workflow steps can in turn execute rules and then populate output parameters that will be returned to the caller. Any output parameters are returned to the caller as XML inside of a SOAP envelope response.

A few details to look out for during your implementation:

  • Since the Execute action can be invoked using HTTP, it can be called from the CRM web UI using javascript. However, the javascript will need to handle the complexity of forming and parsing SOAP envelopes.
  • When using plugins with Actions, the output parameters cannot be populated unless the plugin is set to run during a “post-operation”.
  • When using workflow code activities, the output properties for a custom CodeActivity can be set to CRM entity references but cannot be set to output the entire CRM entity.

Software Architecture for Actions Processes with InRule

The following diagrams describe possible software architectures for Process Actions that execute business rules on-demand. Other architectures may also prove useful.

Using Dynamics CRM Online with InRule

This example depicts integration with CRM Online. This approach uses a CRM Online Plugin or CodeActivity to call a Service Endpoint registered with Dynamics CRM. The Service Endpoint is used to marshal a call to a custom Azure listener using the Azure Service Bus.

ActionCloud900

Integration Approach for On Premise Dynamics CRM Servers

This example depicts integration with CRM on premise. This approach uses a Plugin or CodeActivity to call a WCF REST Service to execute rules.

ActionOnPrem900


comments powered by Disqus