Unified Service Desk for Dynamics 365 now includes a pre-fetch feature. But what does this do and when would we use it?
USD 3.0 introduces a pre-fetch feature. The idea being that you can display data faster by pre-fetching the entity data into the context before the “CRM” form finishes loading. We can also trigger related actions sooner by using a new event called “DataReady”.
Essentially your entity data is loaded into the context prior to the entity page actually loading. Say you load multiple tabs when a session starts, currently you will load the additional information in BrowserDocumentComplete or maybe as additional actions in a window navigation rule. This happens after the form is loaded. By enabling pre-fetch we should be able to speed the load of sessions by starting the load of related data earlier.
In my application, when an account session starts, I load the account and additionally I load a view of associated cases and the primary contact. The primary contact is loaded from my window navigation rule and the associated view of cases is from the BrowserDocumentComplete event on account. So by way of an example, let’s see if this new feature will speed the start of my sessions.
Before I started any changes I timed a few sessions opening and obtained an average time of 12 seconds. Giving me a target to improve on.
Next I altered my account, contact and associated case tabs to enable pre-fetch. This is simple enough simply open each hosted control and update the pre-fetch data option. (A new option with USD 3.0, if you can’t see the pre-fetch data option that you may need to upgrade your version of USD!)
I now re-tested my application with no more changes.
At this point I didn’t expect any improvement! As my actions hadn’t been revised in any way. But I seemed to consistently open my sessions 2 seconds faster. Happy with my sessions now opening in 10 seconds I decided to see what else I could improve!
I am running multiple actions from my window navigation rules. To move these to the DataReady event I would need to re-work the logic of my application. So I decided to focus on the actions being directly called in my BrowserDocumentComplete event.
In my account tab I had actions that were running on BrowserDoucmentComplete. I added a new event called DataReady. (As you can see below.) Simply use the “ADD NEW EVENT” button and add the DataReady event.
Next I removed my actions from BrowserDoucmentComplete and added them to DataReady instead. Meaning my new DataReady event looked like this;
Tip: If you are using USD configurations, don’t forget to add this new event into your configuration!
I then ran my application again and repeated my timings. I was surprised at the results. My sessions now took 15 seconds to load. So slower! These results surprised me so much that I removed all of my changes and tried again. Again my sessions with no changes took 12 seconds to load. With just the pre-fetch data option set I achieved 10 seconds. With the actions on my account moved from BrowersDocumentComplete to DataReady I achieved 15 seconds.
I also repeated my tests on opening my contact session. Again I had similar results to the start of account sessions. Meaning my results were consistent.
I can however see the DataReady event debugger and I have observed that the actions were being triggered sooner. Meaning we do have an additional event to associate to actions. In my example this didn’t give me a performance gain. BUT, I would stress that this is one example. Meaning you should probably test the application performance with actions in BrowserDocumentComplete and DataReady to see which works best for your specific circumstance.
Having said that using the DataReady event didn’t provide a benefit in my circumstance, I did see enabling the pre-fetch option achieve a 2 second improvement on my session load times. A 20% increase. Which was very nice!