In preparation for moving to CRM 2013 early in 2014, we recently upgraded the Cobalt suite of software components and applications to UR 15. The cross browser compatibility beginning with UR 12 has been a long time coming and with the recent compatibility issues we’ve experienced with Internet Exporer 10+, it had become even more apparent that browser compatibility was going to continue to be a support issue. Apart from browser compatibility issues, Cobalt has primarily only supported on-premise CRM installations up until recently due to limitations in the CRM Online environment. The upgrade to UR 15, with the added support for running custom workflows in isolation, was an opportunity to begin registering our plugins in isolation in our production environment to give us the ability to fully support CRM Online installations.
Beginning with version 2.4.2 of Cobalt’s CRM based suite of products, full support for plugins run in isolation as well as cross browser compatibility has been included. This change was not made without encountering a few roadblocks along the way. Particularly, there were 3 integration points that required updates and new solutions to fully support the CRM Online model for ISVs to integrate their solutions into the cloud environment.
- Cross Domain Scripting
- Plugin Timeout and Full Trust Operations.
- Plugin Tracing and SQL Transactions
Cross Domain Scripting
For CRM onpremise installations the solution could have been as simple as creating a new website in the same domain as CRM, using a subdomain, so browsers wouldn’t be concerned with cross domain scripting. However, such a site could not be hosted in the same domain as CRM Online so that solution doesn’t work if we want to fully support CRM hosted anywhere.
Plugin Timeout and Full Trust Operations
The nature of plugins running in isolation (sandbox) is such that they can only execute partial trust operations. Access to the file system, registry, sql and external services (except HTTP / HTTPS) is prohibited. For the most part Cobalt’s products adhere to these guidelines to ensure support for plugins running in isolation and in the hosted CRM Online environment. However, there are functions of Cobalt’s system that are critical to our clients that cannot operate fully within the boundaries of the partial trust environment. The specific example I’ll use here is the data export module which was created to give users control over exporting data on a schedule and allow for uploading those exports to an external FTP site. The libraries we use to FTP files in our code use classes that are not isolatable and therefore cause runtime errors when executed in the sandbox environment.
Plugin Tracing and SQL Transactions
Apart from performing full trust operations some operations of Cobalt’s products require CRUD operations to execute outside the database transaction that plugins execute under. When running plugins that are not isolated the code has access to the file system to perform tracing operations that assist with debugging. It also has the ability to create a new proxy using the CRM SDK to save / update records in CRM in a transaction separate from the main transaction that the proxy passed into the plugin executes under. When moving our plugins to isolation it quickly became apparent that neither of these functions was any longer supported. Queue the ISV application! Again the same proxy we used above for executing full trust operations such as FTP was the most obvious candidate for executing CRUD operations outside of the plugin transaction.
Cobalt’s auto numbering module, which creates unique identifiers for custom entities in the system, relies on this functionality to ensure uniqueness of values regardless of a failure in the primary transaction. Once the auto number is incremented it should never be rolled back even if an error occurs. So, in order for this to work, the increment has to happen outside of the plugin transaction. The ISV application creates a proxy to the CRM web service to perform the CRUD operation and returns to the plugin. In this way a new transaction is created for the auto number update and any subsequent failure cannot rollback that update.
Since the file system is no longer available for logging trace information the natural alternative is to log that information as records in CRM. However, in cases where we are trying to track down a failure in a plugin operation we don’t want the transaction with all of our tracing information to rollback before we have a chance to look at it. In the same manner as the auto number we need these trace records to be created outside of the plugin transaction and to do so we employ the ISV application web service to handle creating these log entries in CRM.
So what is the takeaway from our adventures into isolatable plugins, cross browser compatibility and full CRM Online support for Cobalt’s products? Well, in my opinion what we’ve discovered from all of this is Cobalt’s architecture is adaptable to almost any environment regardless of the restrictions set out by that environment. The total amount of time spent in development to provide support for UR 15 and Plugins in Isolation was about a week and a half. In the process we’ve more than prepared ourselves for CRM 2013 support in the coming months and CRM Online support while providing our customers with new more secure functionality and more hosting options than ever before.
Not bad for a week and a couple days worth of work.