Since InRule first began adding enhanced product support for Dynamics CRM over three years ago, our services team has had the opportunity to integrate the rule engine across several complex Dynamics implementations. Dynamics CRM offers a high degree of flexibility for implementation approaches, including plugins, workflows, custom services, and web resources. With all the options that are available, our clients often ask us – which approach is best?
After looking back through the progress made by both InRule and Dynamics CRM over the years, the InRule services team has improved upon initial designs, and now has a solution architecture that clearly stands out as the best choice for most implementations.
Per the diagram below, InRule provides code samples which use a light-weight Dynamics CRM plugin that can run during server-side events (ex: Create, Update, Delete or a Custom Action). Rule execution is performed “out-of-process” with Dynamics using a WCF REST web service. The suggested approach for integrating InRule with an on premise Dynamics installation is now this REST service, combined with the plugin that runs in the Dynamics CRM Sandbox to initiate rule requests and persist changes. As noted further below, this architecture also provides a clear path for migrating to a cloud-based implementation that uses CRM Online.
This out-of-process rule execution scenario requires that a separate web service application is deployed, a service that is not included out-of-the-box with Dynamics CRM. However, once this service is configured, it can be called to execute rules against CRM entities from many disparate sources and for many different business problems. InRule provides a code sample for this web service.
Calls to the web service are managed by a plugin containing a minimal amount of code. The plugin code is only responsible for serializing entity images, initiating an HTTP request, deserializing results, and then persisting results using the Dynamics SDK.
The diagram below notes the logical components and steps in a typical rule execution call.
Below are a few key benefits of working with this architecture:
Support for Larger Implementations – Many larger Dynamics implementations have server topologies that include multiple servers with specialized roles. By running the rules out of process, the solution can make use of the highly stable and secure CRM Sandbox process. Rules do not need to execute on Web Front End (WFE) servers, but can instead be initiated from Dynamics Application Servers.
Scalable Rule Execution – The out-of-process approach enables rule execution to scale out at a different rate than Dynamics servers. This allows for optimization of software and hardware costs, while making best use of the deployment tools are that included with Dynamics CRM.
Stable and Secure – The light-weight plugin is compatible with the Dynamics Sandbox, executing components in a restricted process that is not the front-end web application. This increases the security of the Dynamics integration points, and lowers the chance that high loads or unanticipated defects will compromise the stability of the Dynamics user interface.
Optimize Wire Traffic and Persistence – The sample web service code provided by InRule will intelligently scan trees of Dynamics entities and return a list of entities that have been modified by rules. Often a complex business decision will require that 100 or more entities are loaded into memory. However, if only a few of those entities are updated as part of the decision, then only those entities will be passed across process boundaries and be submitted for persistence using the Dynamics SDK.
Stay Close to the Event by Using the Plugin Transaction – In this design, all persistence is performed by the Dynamics CRM server using the plugin code. This allows the persistence changes to be registered with the same data context that is initially presented by the plugin.
Handle Security Errors Due to Sandbox Serialization – Since the Sandbox runs as a highly restrictive process, a natural instinct may be to run complex operations out-of-process. However, during implementation your developers may discover that loosely-typed Dynamics entities do not always serialize properly in the Sandbox environment using formatters such XmlSerializer or DataContractFormatter. The InRule code sample includes wrapper classes for both the plugin and REST service that work around show-stopping Sandbox security exceptions.
A Smooth Move from On Premise to Cloud – The Sandbox approach allows for rules and integration code to be reused when moving from an on premise to a cloud based implementation. Below is a reference architecture for executing rules with Dynamics CRM online and Microsoft Azure. The approach is similar to the on premise diagram, but with the REST service running as a Worker Role and the plugin marshalling calls through the Azure Service Bus using a Service Endpoint.
For more information about integration patterns for Dynamic CRM and InRule business rules, please contact the InRule services team. More information about Rules Oriented Application Development (ROAD) can be found here.
