Posted on 9. December 2016

Dynamic365 Data Export Service

If you've moved to Dynamics CRM/365 Online then the likelihood is that you've come up against the limitation of not being able to query the SQL database directly to perform more complex reporting or for custom integrations. Many on premises deployments rely on querying the backend databases and in the past this has been a blocker to moving to the cloud – or at least it has meant a complex and costly integration to copy the data from Dynamics 365 to a on prem SQL database.

The introduction of the Data Export Service is a real game changer with the possibility to replicate your data from Dynamics CRM/365 online to an Azure SQL database in your own Azure Subscription. Once you have your data in a SQL Database you can then using PowerBI, integrate with other systems and create a data warehouse. I've found that the speed of the replication is impressive, being minutes/seconds and not hours.

There are a number of perquisites to enabling this which you can read about in msdn: https://technet.microsoft.com/en-us/library/mt744592.aspx

  • Azure Active Directory linked to Office 365
  • Azure SQL Database and user with correct permissions
  • Azure KeyVault created (using PowerShell script provided)
  • Dynamics CRM Online 8.1 or later
  • Data Export Service solution installed from App Source
  • Change tracking enabled for custom entities you want to sync
  • You must be a System Administrator to create the export profiles

The PowerShell script requires that you install the Azure cmdlets – see https://docs.microsoft.com/en-gb/powershell/azureps-cmdlets-docs/

Here is a video that demonstrates this new service and how to set it up

Posted on 21. November 2016

Dynamics 365 Application User

What is great to see with Dynamics 365 is the concept of the Application User. This means that subscribing systems can be connected to external systems using a 'Service Account' style user rather than the previous technique of providing username and passwords.

One of the knock on effects of this is the new 'Application User' form on the User record. I've had some questions from people who see this form by default. You simply need to change the form back the standard 'User' form:

If you try to save the user record on this form you will receive the error 'You must provide a value for Application ID' since this is a mandatory field.

If you want to learn more about the Multi-tenant server to server application user integration scenarios that are used by App Source, then check out the following article:

https://msdn.microsoft.com/en-us/library/mt790170.aspx

Posted on 22. August 2016

Will the Common Data Model change my Dynamics CRM Database?

This is question on the lips of many after the recent Dynamics 365 anouncements.

Watch my short video to see how Dynamics CRM sits alongside the Common Data Model: https://youtu.be/fYIPXx9zjj8

Posted on 22. August 2016

Debugging JavaScript in the Interactive Service Hub (Part 1)

Those that read regularly my blog and follow my work with Sparkle XRM will know I'm a massive fan of using Fiddler to debug JavaScript. One of the most productive 'superpowers' that Fiddler gives us is the ability to change JavaScript on the disk and not have to upload/publish – we can simply refresh the form and the new script will be used.

The Interactive Service Hub (ISH) was first introduced in CRM2016 and has been improved with more support for customisations in CRM2016 Update 1.

I see the purpose of the ISH at this stage is not to replace the main User Interface but rather as a testing ground for the principle of bringing the MoCA mobile/tablet native client platform to the web client. I think of it similar to the introduction of the Polaris UI back in CRM2011 – there are many similarities in that they both only support a limited set of entities and have limited customisations features. The main difference is that the ISH is being incrementally improved with each release, where the Polaris UI was more of a throw away proof of concept. At this stage the ISH is only supporting 'case' oriented operations but I'm sure it'll eventually graduate to support all Sales, Service and Marketing features.

So why the new approach the UI?

Surely it would be better to improve the existing UI incrementally rather than replace it?

One of the key drivers for the Dynamics CRM Team over the last few releases has been 'configure once deploy everywhere'. This allows us to configure business rules that can be run on all devices/platforms reliably without having to perform separate testing and perhaps re-write to target different clients. The maintenance of having multiple user interface platforms is considerable so it's a natural step to try and achieve some degree of convergence between the mobile/tablet/web/outlook interfaces.

A little background on how the ISH loads metadata

I think we are all fairly comfortable with the normal Web 2.0 paradigm of loading resources. This is where with each operation the client requests an html page and then the browser requests all the additional resources (JavaScript, CSS etc. ) that are referenced by that page. JavaScript can then make additional XHR/Ajax requests to the server to display further dynamic content. The CRM2016 UI is very similar on this front as can be seen below. I documented the CRM2013 script loading sequence which hasn't significantly changed even in CRM2016.

  • Page Load Sequence Diagram
  • Each time you open the web client, the homepage.aspx or Main.aspx has to request the metadata for the specific resource (view or form) and then combine it with the requested data. Although there is browser and server side caching in place, this is still costly in terms of the requests and rendering overhead of the browser. The 'turbo forms' update in CRM2015 Update 1 has really helped with the speed of this since it minimises the resources that requested with each navigation however fundamentally it is still limited by the page per browser request architecture.

    ISH works very differently…

    The ISH is more what we would call a 'single page application'. The sequence is very different in that there is an initial download of metadata and then subsequently all user interactions only request the actual data using the Organization.svc and OrganizationData.svc.

  • New Page Load Sequence Diagram
  • This single page approach has the advantage that it makes navigation super slick but with the rather annoying drawback that there is an initial wait each time the ISH is opened where the metadata changes are checked. The first time you open the ISH all the metadata is downloaded but from then on only the differences from the last open are downloaded. If there haven't been any changes then it's super quick because all the metadata is stored in the browsers indexed Database but if you've done a publish then the next open can take a while. Furthermore, the new metadata won't be downloaded until you close and re-open the ISH - this is different to the Web 2.0 UI and can lead to the client working with stale metadata for a time. The Indexed Database is one of the significant differences between and HTML5 single page app and a more traditional Web 2.0 architecture.

    Note: For now the ISH mostly uses the SOAP/Xml based Organization.svc rather than the new JSON based Web API.

    The speed of the metadata sync can be helped further by using the 'Prepare Client Customizations' button on the solution since this will pre-prepare the download package rather than waiting for the first person to open the ISH to detect the changes in the metadata. The difference between the MoCA client and the ISH is that the MoCA asks if the user wants to download the updates – presumably because you may be on a low bandwidth connection.

    So where does that leave us with respect to JavaScript debugging?

    If you've been keeping up so far (you have right?) then you'll realise that because the metadata (this includes JavaScript) will be all stored in the browser Indexed DB and not relying on the browser cache. As a result, we can't simply prevent the files from being cached and download the latest version with each page load as we used to do with Fiddler. We're back with the uncomfortable debug cycle of having to make a change to a JavaScript web resource, upload it to CRM, publish, close and re-start the ISH - urgh!

    To preserve our collective sanity, I've created a little debug utility solution that you can use to clear the cache of specific web resources so that you can quickly make changes to JavaScript on your local disk and then reload it in the ISH without doing a full publish cycle. Here is how:

    1. Install the latest build of SparkleXRM
    2. Install the Interactive Service Hub Debug Helper Solution
    3. Setup Fiddler's Auto Responder to point to your local webresource file as per my instructions.
    4. Start the ISH to load your JavaScript
    5. Make a local change to your JavaScript
    6. Open the ISH Debug Utility Solution configuration page and enter the name of your script name, then click 'Refresh JavaScript Webresource'
      Note: You can enter only part of the webresource name and it will use a regular expression to match.
    7. Use Ctrl-F5 on your ISH Page and when re-loaded the Web Resource will use the new version since the debug utility has forced a new download and updated the Indexed DB storage.

    Sweet – but what about the MoCA client?

    Obviously this technique is not going to work for mobile client running on an iPad, iPhone etc. The good news is that you can run the MoCA client in the Chrome browser in the same way you can run the ISH – just navigate to:

    <crmserver>/nga/main.htm?org=<orgname>&server=<crmserver>

    Note: You must be pre-authenticated for this to work.

    OnPrem

    http://dev03/nga/main.htm?org=Contoso&server=http://dev03/Contoso

    OnPrem IFD

    https://myorg.contoso.com/nga/main.htm?org=myorg&server=https:// myorg.contoso.com

    Online

    https://myorg.crm4.dynamics.com/nga/main.htm?org=myorg&server=https:// myorg.crm4.dynamics.com  

    Since the ISH and the MoCA client are build using the same platform you can now use the ISH Debug Helper from the same browser session to perform the same script refresh! This is actually an excellent way of testing out your Scripts on the MoCA client! For more information, check out the comments in this tip of the day.

    Looking forwards to the future

    I'd really encourage you to check out the ISH and use the New CRM Suggestions site to record anything you find that you would like to see in subsequent releases. Whilst I suspect that the existing 'refreshed' UI will be available for some releases to come, it is likely at some point to become the new 'legacy' UI and with on-going investment being made in the ISH style UI.

    In part 2 we'll look at some limitation of the ISH and how to get around them.

    Any comments, just tweet me! @ScottDurow

    Posted on 22. July 2016

    Install Project Service Automation (PSA) – Where’s it gone?

    If you have tried to install Project Service recently you might have found that it's disappeared from the 'preferred solution' list in the Office 365 admin portal. So where has it gone?!

    Although the CRM Online Help hasn't yet been updated to reflect the fact, it has now moved to the recently release and very exciting AppSource!

    On the 11th of July Michael Kushinsky of Microsoft helpfully posted in the dynamics community the new instructions on how to install and upgrade from a trial installation – and there will be an official blog post about it soon.

    I thought I would quickly show you how easy it is to use App Source to install PSA:

    1. Select Settings -> Dynamics Marketplace

    2. Search for 'Project Service' and click 'Try'

    3. Accept the T&Cs (you always read them in full right!)

    4. Wait for the solution to install and you're off!

    I can't wait to see AppSource grow and mature!