Dynamics CRM Online

The Great Migration: Implementation 2 : PA Event Importer

We talked about our plans for this in part 2a and in part 3, now its time to see how we actually implemented it.

The working part of this system is two Azure Webjobs, the PAEventImporter which takes data from the Press Association and imports in to Dynamics 365 custom entities and the Event_Push_Updater which takes the data from Dynamics and pushes it to the websites.  both operate on a fixed schedule.

First we setup the infrastructure by creating a new team and area in the VSTS Project and the Azure parts

  1. An App Service Plan (to host the App Service)
  2. An App Service (to host the Webjobs)
  3. A KeyVault (to hold all of the secrets – passwords and so on)
  4. A Storage Account (to hold the file shares and Webjob logs)
  5. Two File Shares (one for the downloaded files and one for the upload logs)

we only encountered one gotcha with this and that was for the Webjob logs, it seems that the connection string ‘AzureWebJobsDashboard’ has to be set against the AppService (under Application Settings) in Azure and not just in the projects Settings.setting file toget Azure to stop complaining that it is missing.  This also means that all the Webjobs write to the same logging area but in practice that has not been an issue.


The Great Migration: Implementation 1: Postcode Anywhere

We talked about our plans for this in part 2e and in part 3, now its time to see how we actually implemented it.

First we go to the implementation guide on PCA Predicts site and from there download the current version of the CRM Solution.  We are going to put all of our solutions into source control so we have already defined the folder structure for these, so we’ll save it there before importing it into the Test Instance.

In CRM go to Settings,  Solutions, click Import and import the .zip file you just downloaded.

Now we can create a new solution to link the Entities up to the PCA Predict Services using the JavaScript from their Solution.

In CRM go to Settings,  Solutions and click New


We have called this ‘System Entity Postcode Lookup’ because this solution is only going to modify the System Entities – Account and Contact initially – and it is only going to modify them as much as necessary to add the postcode lookup feature.

Now we will add the Account Entity, go to Entities and click Add Existing, then select the Account Entity from the list and click ok.

This will then ask you which parts of the Account Entity you want to customise


On the Forms Tab, select the Active Main form (called Account in our case) and click Finish.

Now expand the Entities section, the Account and select the forms area.  open the Account Form, from here you can follow the steps in their excellent guide; we also created a new key for each entity type just to help us monitor usage.

Once you have added all the entities you want to enable for address lookup, click the Publish All Customizations button and test it all works.  Assuming that it does, go back to Settings, Solutions, select your solution and click export – at this point we are putting it in the source controlled folder, replacing the existing file and committing it.

NOTE! Export your Solutions as Unmanaged or when you
import them in future you wont be able to edit them.

Now you can import the Solution into the Live Instance and test it still works as expected.

Issues we Encountered

We had a problem initially when importing the PCA Predict Solution where CRM kept saying that it was not a valid solution, this turned out to be a corrupted download and downloading the file again fixed this.

We also had a problem where opening an Account Entity caused CRM to say ‘The object does not support the blur method’  this was because in the PCS Predict solution there are 3 different JavaScript files for Accounts – they each target a different version of CRM – and we had chosen the wrong one.  As of today – 30 September 2016 – it appears the file suffixed 2015 if the one to use with CRM Online.