Update Records with the Import Wizard

I recently noticed that in version 2016, the option to export records for update (available in version 2015 as seen below) has vanished from the Export To Excel dialog.
When checked, this option allows you to update the exported data and later on use the Import Wizard tool to update existing records.

option to export records for update available in version 2015

import existing records with the Import Wizard

Consulting Faridun Kadir, a fellow MVP, I learned that exporting MSCRM records to a static worksheet exports records GUID (record unique identifier) by default as a hidden column. This GUID is later used by the Import Wizard mechanism to determine if the imported record is to be created or updated.
For this reason, the ‘Make this data available for re-importing’ checkbox was removed from the Export to Excel dialog.

image
 
As you can see above, the hidden columns title includes a warning (‘DO Not Modify’). Indeed, changing these columns data will end with an import failure. So although exposing these columns by itself will not cause any harm, you better leave it hidden to prevent an accidental change.

All you have to do in order to update existing records is to update required value in the Excel file and import via the Import Wizard. You can also add new records which will be created in the same import job.

Advertisements

Plug-in Configuration Manager Utility

Plug-in components often require external configuration settings. Maybe the Plug-in code consumes a web service which end point alternates between test and production environments or maybe you use the Plug-in configuration to turn logging on and off. Basically, any code setting which depend upon external resources is worth exporting to external configuration as it may prevent code re-compilation, additional testing etc.

There are some common approaches to implement configuration settings for Plug-in components:

  1. Configuration file: each Plug-in instance consumes a configuration file
  2. Configuration record: each Plug-in instance executes a query to retrieve a designated Microsoft Dynamics CRM configuration record
  3. Step configuration: each Plug-in instance constructor receives configuration settings from the Step secure/unsecure configuration

Performance wise, option 3 is preferred as the Step’s secure/unsecure configuration is cached alongside the Plug-in step and no additional operation is required to retrieve it. Changing the Step’s secure/unsecure configuration will automatically un-cache and reload relevant Plug-in with updated configuration. If you are not familiar with this option implementation, read this.
Options 1 and 2 require an expensive IO operation or query as each Plug-in instance explicitly consumes additional resources to retrieve configuration settings. When one of these approaches are applied in large scale (or with poor server resources), it will take a considerable toll on server performance and sometimes, the UX.

While option 3 yields better performance, it is not maintenance friendly. In enterprise scale applications, you may have to go through hundreds of Plug-in steps to update secure/unsecure configuration settings. Now think about doing this while deploying a version to the Production environment a 3 AM.

In this post, I offer a utility which allows you to enjoy Step configuration performance benefit along with simple maintenance for configuration bound Plug-in components.

WIIFM?

An unmanaged solution can be downloaded here. Use this tool as is or change the code to better suit you needs.
Although this tool was designed and built for Microsoft Dynamics CRM 2016 (Online/On-premise), the approach behind it can be implemented with previous versions, probably down to 2011.

As displayed below, the Plug-in Configuration Utility allows you select a registered Plug-in assembly, view related Steps and finally view each Step configuration details.
Clicking the ‘Update Configuration’ while a single or multiple Steps are selected will updated the respective configuration settings.

By default, Custom Work Flow Activities and System owned Plug-in assemblies are hidden, but can be revealed by unchecking the matching checkbox. You can view some interesting configuration settings under the Microsoft.Crm.ObjectModel assembly Steps, which are hidden when using the Plugin Registration Tool.
Although possible, do not change any configuration settings for these Steps.

Plugin Configuration Manager Demo

Bits & Bytes

The entities used behind the scenes here are

  1. pluginAssembly – representing registered Plug-in DLL file
  2. pluginType – representing IPlugin event handler class contained in the Plug-in DLL file
  3. sdkMessageProcessingStep – representing Step details binding the plugintype event handler to specific entity and message. Contains the unsecure configuration string
  4. sdkMessageProcessingStepSecureConfig – representing a secure configuration record related to the sdkmessageprocessingstep. Contains the secure configuration string

Plugin Configruation Entity Model

Although the Plug-in Registration Tool displays the secure configuration string as part of the Step settings (represented by the sdkMessageProcessingStep entity), this attribute actually resides in the related sdkMessageProcessingStepSecureConfig entity. Moving the secure configuration string to a different entity allows setting different privileges, as the secure configuration string may contain sensitive data like password.

This also means the in order to programmatically set new secure configuration string for a Step, it is required to create and relate a new sdkMessageProcessingStepSecureConfig  record.

Plugin Step Secure Configruation Privileges

Asynchronous Batch Process Pattern – Leveraging December 2012 Service Update (Polaris) Features

December 2012 Service Update features two new interesting capabilities:

  • Custom Activities support for Microsoft Dynamics CRM Online
  • Executing multiple requests with the ExecuteMultipleRequest class  

These capabilities allow important improvements to the Asynchronous Batch Process Pattern solution described here.

So what’s new?

The lack of Custom Activities support in Online deployment required the usage of a Plugin component to perform the Target Records query and implementing the Action Workflow to each result record.  
With December 2012 Service Update Custom Activities support for Microsoft Dynamics CRM Online, a Custom Activity can now replace the Plugin component. This implementation renders the Asynchronous Batch Process Pattern solution simple and robust. 

The new ExecuteMultipleRequest class allows sending a bulk of requests to the Organization service in one request, instead of a stream of separate requests. This feature is now used in the Asynchronous Batch Process Pattern solution In order to apply the Action Workflow Rule to multiple Target Records in a single request and to improve the solution’s performance. 

I will make the new and improved solution available for download soon.

 

Process algorithm