Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
It has been a school day today (hence the Grange Hill image)
Another important fact, which is possibly more mental but I’m not sure what the form or code is doing which makes the code have an abstract feel to it. It shouldn’t matter what the form is doing, but for some reason it does, it must be the nosey parker in all of us. It’s easier to understand why the code is doing certain things when you understand what the form should do and why certain fields are important.
The code was initially confusing is because the initial load script, called a bunch of other scripts and waited until they were all loaded. WHY?
To give you some background, the CRM release was CRM 2011 patch 12.
So if you had scripts A, B, C.
ERM no, that passed me by, please explain was my answer
So now I understood why the code was waiting for all the scripts to load. When you first come across methods for a first time, you wonder if this is a new best practice or something I should have been doing, why hadn’t I seen this code before?
In the form onload, it passes in a comma seperated list of scripts to load and the last one is the script and function loaded when all the scripts are loaded.
Aha I had my place to start.
In the code I found lots of OData calls which returned no value, puzzling I thought.
It was because the code was using OData to update CRM values but why it was doing it in the form load seemed rather odd.
I have never used OData to write values to CRM, why was this I wonder. Thinking about it, I guess I would usually update related entities or even the main entity with a plugin so it didn’t effect form performance.
here is an example of an odata update
and another one
This code was particularly puzzling because it was updating values on the form onload? It turned out a bit of code re use from selecting an item in the grid, was also being triggered on a grid onload. So it was updating some values for every item in the grid.
This was an excellent place to start but I had to work out what I could remove without losing any functionality.
I had find the quick wins on performance, to weasel out the worst culprits for slow form load I used fiddler to see investigate the OData calls (which there were many)
Which OData calls took the longest
Find OData calls which were not filtered
Find OData calls which were retrieving the same data multiple times
I was also on the lookout for cases of inefficient coding, but most of the time was spent on odata calls, so that was my main focus.
Business Applications communities