of the
Not so long ago we tipped about flushing your portal cache. The main advice is still valid:
Do not use cache invalidation handle
This method no longer works in online portals, and is now obsolete.
Turning your portal off and then back on still works but it’s like using a flamethrower to kill a mosquito. It takes few minutes to accomplish the task and it disrupts the availability of your portal.
Good news is there are better methods now.
- In a recent update to online service you will now see a reset portal button, which will automate the stop/start the portal for you, invalidating the entire cache.
- Updating the website record in CRM, ie change the name field will also do the job. Note: this is not a formal mechanism because it was added as a temporary measure, and the development team reserves the right to remove this behavior in the future.
- Publishing all customizations in CRM will also invalidate the portal cache.
The above methods are effective but drop the entire cache indiscriminately. Much better and recommended approach is to ensure that “Change tracking” is enabled for the entities used in the portal.
If this option is enabled, you don’t have to do any of these tricks to clear up cache. Portals use change tracking feature to intelligently refresh the portal cache for a specific entity without resorting to a big hammer.
Thanks to Tanguy “The XRM Toolbox” Touzard and Shan “Smoke ’em” McArthur for beating the issue into a pulp.
This I a great tip. Global cache reset however may still be required when CRM metadata changes, like adding-removing fields, changing option sets, etc. Sometimes the tracking does not pick such changes.
Hey Vlad,
strictly speaking, metadata changes require publishing (even if some of the changes appear immediately) and I was rest assured that publishing does, in fact, flushes the cache.
Cheers
George
When tracking is enabled the cache is flushed on any entity update/create/delete – for that particular record. AFAIK there is no reliable trigger on metadata change but that is based on my experience with ADX portals.
Vlad,
I was told that CRM Online does refresh the cache on publish.
Thanks
George
This is an awesome tip. I assume however, that this won’t work on legacy Adxstudio Portals (v7) ?
Cheers
Nick
Hi Nick,
no, this only applies to Dynamics 365 portals. For Adxstudio Portals, continue to use cache invalidation handle.
Cheers
George
Nick, in ADX you need to configure web notification URL and that would be equivalent to enabling “Change Tracking” in Dynamics 365 Portals. See here:
https://community.adxstudio.com/products/adxstudio-portals/documentation/developers-guide/cache/web-notifications/
[…] Dynamics 365 portals cache reset, please refer to this great crm tip of the day post. The main point is that you should turn on “Change Tracking” for the entities used in […]
Hi !
In my Dynamics 365 trial tenant, I’ve tried to make two portal pages with entity lists. The first entity list uses a custom entity and the second uses the Contact entity.
Both are marked with change tracking. What I have experience is that neither page shows updated information when attributes are changed in Dynamics 365.
In the portal ,sorting on the list column headers, the first time will make the list refresh. It looks like the sorting results are also cached. If I make more changes in Dynamics 365 this sorting stays the same.
Anyone with the same experience ?
Any idea what may be wrong ?
Kind Regards
Ingve
Hi Ingve,
change tracking does not mean that changes to the records immediately make it to the portal. What it means is that portal code can quickly readjust the cache when querying CRM for changes. How often does that happen? No idea, unfortunately, frequency of the updates is not documented and there are no plugins in the portal solutions to indicate that it’s push-style notifications. I wish there was a way to “nudge” the portal (as it used to be the case), web notifications urls are still there, but there is no “webhook” entry point since cache.axd has gone.
From my experience, portal data refresh can take from few seconds to couple minutes after the data changes.
Cheers
George
Hi George!
Your experience waiting for some minutes would be acceptable for us. Our experiences are that automtically refresh of the cache does not happen at all. The only ways I have managed to flush the cache are :
1) Restart portal
2) Edit/add/delete a record using the portal.
Beside checking the Change Tracking for the entity, are the any other configurations needed in the solution/portal ?
Best regards
Ingve
This is our experience as well. Entity Lists are not being refreshed within a reasonable timeframe…it can take anything up to 24 hours before changes are appearing and that’s not acceptable at all as we need these updated asap.
Front-end changes (directly in the Portal) are reflected on the front-side and the back-end immediately but anything done within Dynamics 365 isn’t being pushed out right away (or even in a couple of minutes…if only!)
Even a full Publish of Customizations doesn’t work either and we need to resort to the Restart Portal mechanism…and we can’t do this simply because the data has been updated in the CRM!
Hoping there’s some fix coming to help with this as we really need something to help with this in the next month or so.
For Dynamics Portals Add on – Entity Change Tracking is actually required for each entity that is exposed to Portal – otherwise there is no predictable way that CRM can let the Portal know there is new changes.
Does anyone have a better solution ?
Even when ‘change tracking’ is enabled the records update can takes a while to be changed on the Portal.
I most efficent solution I use is to restart the Portal – but it is not sustanable for end users.
This rescued my current project!
[…] Enable Portal cache for entities on Dynamics 365 Portals […]
Thanks for your help.