One of the biggest pain points of using Powerapps Portals is "he who shall not be named". No, not Voldemort, but Mr. Cache. I'm sure if you've used the portals before you've come across some sort of caching issue, whether it be data not presenting itself right away, queries pulling back incorrect data, or updated CSS/JS not showing.
Recently I had an issue arise with a client that had not been an issue since we entered a live scenario many months ago. They are using the Powerapps Portals, alongside the Dynamics 365 for Marketing Events Portal, to manage their members and event registrations. The issue that came up was when an invoice was generated for the user registering for an event, it was not being found within the Dynamics 365 system based on the input parameters. As I said, this was working up until now, so I needed to track down what had changed recently. The funny thing is - nothing had changed. No customizations were done. No updates to the portal were completed. Nothing. I event went as far as confirming with the portals team at Microsoft that no updates had occurred (we all know how Microsoft likes to sneak things into their releases).
We had created what I like to call a service for the client using the Powerapps Portals, utilizing a Liquid Template, a fetchxml tag, and returning JSON data. This template was rendered into a page which could be called using Javascript via a GET request, passing back the retrieved data from the fetchxml liquid block. More on this topic can be found on Colin Vermander's blog.
During my testing, I had entered in the correct parameters and the service was not returning any records. Generally, this issue is because of Entity Permissions not being setup correctly for the entities, but since this was working for the longest time it was not the case. In a hail mary, I clicked the handy Clear Cache button that can be found in the /_services/about URL of the portal and wouldn't you know, the record(s) were found in the service instantly.
Now that the problem was identified, I needed to figure out the solution. After some reading and (truth be told) advice from the portals team at Microsoft, I learned something new I had not known before - you can bypass the caching of the portal in a fetchxml liquid tag. If all of the parameters are the same each time you call the service the portal will cache it, so if not all parameters are the same then it will not, which is where the fix came in.
Our resolution was to add a filter condition into our fetchxml block in our liquid template and populate it with an ever changing variable so it would be considered a new query by portal standards. The easiest parameter to pass was the current date and time, which would always be a different value when you call the service.
As shown in the fetchxml block above, I added a condition on line 19 that would filter on if the totallineitemamount field did not equal the ts parameter which is the current date and time in milliseconds. Since this parameter came across as a number value, I needed to validate it against a number attribute in CRM. This condition will always return true, as the Total Line Item Amount will never equal the current date and time in milliseconds (and if it does, that's an expensive invoice!).
Once I updated the service with this parameter, the portal interpreted it as a new query each time it was called, and thus the invoice(s) were retrieved instantly on the portal for the client. As for why this functionality seemed to be working for a long time before... well that's the mystery, but my thoughts are the client got lucky and was fortunate enough to get the lower end of the up to 15 minute cache refresh. Going forward with my liquid code implementations, I will definitely consider using a dynamic parameter to retrieve real-time data in my services, keeping in mind that this will slow it down immensely depending on the number of records that may be retrieved.
Comments