During a recent client engagement there was a requirement to manage insurance quotations using Dynamics CRM. The client was set on using the cloud-based version, Dynamics CRM Online.
The robust and highly-configurable entity models in Dynamics CRM were more than adequate to handle the data needs for the problem. In addition, the configurable UI forms built into Dynamics CRM also offered a solid starting point for a UI that could be used by back-office call center employees. These employees could enter information about potential customers and the products those customers wanted to purchase.
So, the client quickly had a data model, a UI, and role-based security with Dynamics CRM. However, during the early design phases the customer noted that the business logic needed to make decisions regarding product and benefit eligibility were not always simple. In addition, logic required to complete the entire premium calculation for the insurance quote also involved several complicated steps. The complexity of these business problems was beyond the capability of what could be easily accomplished using CRM workflows. If no other tools or services were considered, then complex business logic would need to be hard-coded in .NET code.
Given previous experience with attempting to automate the process of insurance quotation, the customer was interested in the following:
- Executing complex logic that drives real business decisions – such as eligibility and pricing
- Having business visibility into the logic that drives eligibility and pricing calculations – business logic should be easily readable and reportable for business users, not just software developers
- Having the ability to easily version and change rules over time – the application also needed the ability to execute older versions of rules when necessary
- Changing the behavior of Dynamics CRM without having to change code – business users and subject matter experts should be empowered to make changes to the rules. Complex business logic could not be hard-coded and maintained only by software developers
- Have a completely cloud-based solution – no on premise hardware or software should be required, including management and execution of business rules
The client decided to use InRule to extend the functionality of Dynamics CRM and allow for complex business rule management and execution. InRule was capable of meeting all of the requirements in the above list. InRule also offers a series of out-of-the-box integration features and code samples for simple integration of business rules with Dynamics CRM.
However, the requirement to host everything in the cloud forced a bit of thinking. Dynamics CRM Online has the ability to host custom components, but those components must run in the highly-restricted “sandbox” environment. The “sandbox” helps ensure stability and security of the Dynamics CRM Online environment. The eligibility and quoting calculations needed the potential flexibility of connecting to other systems, and also loading libraries that are restricted in the sandbox.
After considering the constraints of Dynamics CRM Online, the decision was made to execute complex rules out-of-process with Dynamics CRM using a separate web service. Creating a web service hosted within Azure seemed like a relatively straightforward task, but it also raised some questions about potential integration issues with Dynamics CRM Online. How would the service be secured? Could the solution still make good use of the powerful eventing and workflow frameworks built into Dynamics CRM? How would calls be initiated and managed? Thanks to the Azure Service Bus and the Service Endpoint features built into the CRM SDK, the integration between the business rules service and CRM was relatively easy to accomplish.
The final design included the following components:
- Dynamics CRM Online Plugin – Rule execution to calculate the premium for the insurance quote is initiated upon “save” of a custom “Quote” entity in CRM. This save event is handled by a custom CRM plugin.
- Dynamics CRM Service Endpoint – During execution, the plugin calls into a Dynamics Service Endpoint to perform the rule execution. The Service Endpoint is designed to easily integrate with the Azure Service Bus and ACS. It offers a secure approach to marshaling calls to out-of-process services from Dynamics on-line.
- Azure Service Bus with ACS – The service bus was used to marshal calls between CRM Online and the business rules REST service.
- WCF REST Web Service for Business Rules – Rule execution is performed using a custom REST web service. The service was published using an Azure worker role. When the worker role starts, it creates a WCF host to listen for calls and registers the host with the Azure Service Bus. The classes in the WCF service implement the IWebHttpServiceEndpointPlugin interface, so they can easily accept the rich, complex types that are provided by Dynamics CRM Service Endpoints.
- Cloud-based Rule Catalog – The InRule Rule Catalog is hosted in Azure as a Web Role. The Rule database is stored in the cloud as well using SQL Azure. This allows rule authors to author, test, and publish rules directly against CRM Online and other cloud-based services. No on-premise servers were required.
The diagram below depicts the architecture for the solution:
A few additional notes about the details of the implementation:
- Based on Microsoft documentation, it was determined that data changes should be saved back to CRM using only code in the plugin. During processing the Business Rule Service queried back to CRM to load some additional data, but all final answers were passed back to the plugin for saving.
- Since the rules had to load some data from Dynamics when running, the plugin step was registered to run as a “pre-operation” instead of a “post-operation.” If a post-operation was used then some queries were blocked due to locking in Dynamics CRM.
- Since a REST service was involved, a Simple Web Token (SWT) was used with ACS as opposed to SAML.
- Setting up the ACS for the first time can be confusing. Thankfully the Plugin Registration Tool in the CRM SDK includes a button that will attempt to automatically configure ACS for a given Azure Service Bus namespace.
- The information passed across the bus using the Service Endpoint is very rich. The programming model is very similar to writing an in-process plugin for CRM, and contextual information such as the user ID for the source event is available.
- The InRule engine is capable of handling complex trees of hierarchical CRM data when making a decision. Several child collections of the quote were populated and considered during the insurance quote premium calculation. Field changes for the Quote entity itself along with field changes for child entities such as Line Items were passed back to the CRM on-line plugin for persistence in a single transaction.
This architecture, along with InRule and Dynamics CRM, allowed us to deliver an insurance quoting PoC to the client within a three-week timeframe. The design allowed for the cloud-based deployment they desired, along with the flexibility they will need over time. If there is interest, I am planning to create a few follow-up posts that dig into the code and low-level details of each piece of this solution.