This week, I’m proud to announce that, along with the 5.0.28 release of InRule®, we released version 2.3.5 of the InRule® for Microsoft Dynamics CRM integration framework. I’m really excited to share information on some of the new features we’re introducing with this release.

This release continues our focus on sharpening end-user configuration, deployment, and administration experiences, a goal I feel we’ve been able to really deliver upon! As well, we’ve added an important new feature designed to mitigate transient failures in Dynamics’ network connectivity. The InRule for Microsoft Dynamics CRM plugin will now attempt to retry certain types of network operations that have failed. In this post, I’ll focus on mostly on the configuration changes along with a brief history of how they have evolved from concept to delivery.

Why Talk about Configuration?

Although the new configuration features may seem to steal the thunder from the plugin retry capabilities added in this release, the critical path for implementing both featured a classic priority inversion. Let me explain: the lower prioritized feature of being able to configure InRule from within Dynamics 365 blocked the much higher priority of the retry functionality. Because of this, the existing method for providing runtime configuration data to the InRule plugin wouldn’t be able to easily support the additional settings (which we also need to expose to administrators. As a result, it was necessary to define a new entity in Dynamics to store plugin retry as well as other configuration data. It’s my hope that in time, this will form the basis for a rich, low-friction way to put InRule in front of customers and prospects.

Configuration is King

In prior versions of the InRule for Microsoft Dynamics CRM integration framework, it was necessary to use the Dynamics SDK’s Plugin Registration Tool to perform a laundry list of tasks: provision and configure the InRule integration plugin, registration of an SDK Message Step, creation of an Azure Service Bus Relay Service Endpoint. If that wasn’t enough, each component has its own set of configurations that must be (correctly) entered – things like SAS credentials, SB Namespaces, Endpoint ID’s – it’s enough to make anyone’s head spin!^* An important realization I had was that by including the Service Endpoint, Plugin, and SDK Message Step Registration in the Dynamics Solution, a large swath of deployment steps would no longer be needed.

Aggregation and Consolidation leads to Simplification

Starting with the release of InRule 5.0.23, all of the Dynamics components are deployed using the Dynamics SDK’s Package Deployment Utility, allowing us more control regarding how and what is deployed to a customer’s Dynamics Organization.

This was a good start, but I knew we could do better. Moving configuration from being stored in a SDK Message Step’s unsecure config attribute into its own entity provided a lot of flexibility; the only piece of configuration a particular SDK Message step now needs is the GUID identifying the configuration record to use at runtime. An important implication of this was that I could easily “bake in” the default configuration into the deployment, leaving just the Service Bus credentials and namespace to be provided by end-users. None of these measures directly solve the problem at hand, however they do prepare the ground for solving the problem in a clean fashion. By implementing a Dynamics Solution Configuration page, we are aggregating relevant configuration information in such a way that allows users to make controlled changes to the system that minimizes the potential for human error.

Making of a UI

There are a lot of different moving parts that all must agree with each other in order for the whole to properly function. This has proven to be a major contributing factor when customers run into difficulty deploying the framework. Accordingly, efforts to reduce deployment-time component coupling obtained a great amount of focus from us.

1 Dynamics Solution configuration page for a default installation of the InRule for Microsoft Dynamics CRM integration framework

The solution configuration page is just one piece of the whole; another piece is the rule configuration entity itself. Not just a storage repository for plugin configuration, the rule configuration entity contains attributes that control the client-side behavior of rules execution. Previously, users were obligated to perform modifications to the JavaScript Web Resource(s) to accomplish what is now done by modifying a data record.

2 Rule Configuration entity from in Dynamics. Using built-in forms functionality saved lots of time creating screens for data management

Summary and Wrap-up

We’ve put a lot of work into this latest release of InRule for Microsoft Dynamics CRM to improve the framework’s reliability and flexibility for our customers. The two primary features to keep an eye on with this release are the added ability for the plugin to perform retries under certain circumstances, and the addition of an in-Dynamics means of configuring and managing the InRule integration with Dynamics CRM.

All of these new features provide customers with more and better ways to fulfill InRule’s mission of empowering organizations with the power of computing. I’m not just excited about getting this into customer’s hands, I’m also excited at what sorts of things delivering this functionality will enable our customers to achieve in the near future. If you have an idea or suggestion on how we can improve the InRule for Microsoft Dynamics CRM integration framework (or any InRule product offering), feel free to leave a comment!

^*This is all in addition to the need to deploy and configure an InRule for Microsoft Dynamics CRM Rule Execution Service and irCatalog Classic Cloud Services separately, but one step at a time!