Monthly Archives: August 2021

Upgrading a solution vs updating a solution – what is the difference?

What exactly is the difference between solution upgrade and solution update?

It might not be quite obvious from the description of each operation when you are importing a solution:

image

Let’s do a quick test then. To start with, here is how my original solution looks like – there is nothing fancy there, it’s just a couple of tables:

image

Normally, one of the main benefits of using managed solutions is considered to be our ability to delete no longer needed components from the destination environment. Those components that are removed from the newer version of the solution, and which have no other references holding them, are expected to be removed from the destination during the upgrade operation.

And that is how it works, but only for solution “upgrades”.

Instead of the upgrade, I’m going to use “Update” this time. Here is how my new solution looks like in the source:

image

There is one new table, but, also, one of the older tables has been removed.

Once this solution is imported into the destination with “Update” option, here is what it looks like in the destination:

image

It seems this is not so much about replacing the solution as it is about adding what’s been added without removing what’s been removed.

That, of course, goes against the ALM ideas, so why would somebody want to do this? In my case, I somehow ran into an endless loop of missing dependencies when trying to do the upgrade, and, eventually, had to resort to the update option just to get the solution pushed to the destination environment.

That means, though, that some of the components which would normally be deleted are still there, and that is not good either. But that is a problem for another day, which, of course, I still have to look into.

UpGuard report on PowerApps Portals security – what have I learned?

If you read UpGuard report on PowerApps Portals security which came out a few days ago, you might start panicking, and, I’d say, rightfully so:

https://www.upguard.com/breaches/power-apps

Danish has already covered the technical side in his blog post, so there is no need to discuss the technicalities here.

But, then, on the high level, what did I actually learn from that article by UpGuard?

To put is simple, I learned a few things:

Having a low-code code platform at your disposal does not mean that you can ignore all the standard /best practices you would normally follow in the pro-code world

As in, security testing is not something you would normally ignore, so how come you would not do this kind of testing in the low-code world? The explanation is, likely, extremely simple, even if it is quite concerning: low code allows you to develop things quickly, and it’s almost encouraging you not to spend as much time on testing as you would do otherwise. It’s been mentioned many times that citizen developers are not very likely to follow the same practices pro developers would, so it’s not that surprising certain things are ignored. And it just so happens that security/vulnerability testing is one of those.

Going by analogy, you would take some precautions not to cut your finger when using a knife. And you would not saw the branch you are sitting on. And you would probably wait for the coffee to cool down a little bit before drinking it.

Of course some folks would sue coffee chains for making coffee too hot, but I will leave it to you to decide whether this makes any sense to start with.

Long story short, low-code makes it easier to develop applications for non-developers, but it does not necessarily mean you can just go wild with this and let everybody do whatever they want.

That said, I’ve also learned something else.

There is multitude of clients who are using PowerApps Portals, and there are some big names there

UpGuard has a bunch of those names in their article, so this really made me thinking. See, due to the somewhat cumbersome licensing model (per login fees? Come on, this essentially eliminates a lot of portal scenarios), and, in general, due to how portals are supposed to be developed / maintained, I have never considered them as important as model-driven or canvas apps. But, given the scale of the clients mentioned in that UpGuard post, and keeping in mind the number of records that may have leaked (and assuming that’s the smaller part), apparently portals do have an important place in the PowerPlatform ecosystem.

Of course the fallback from that post will, likely, continue for a while. Eventually, clients will learn their lessons, Microsoft will enable security by default, UpGuard will get some additional publicity, and, then, things will settle down. But, if there is anything I’m going to take away from this story it’s this:

  • This is a great example of why “pro” developers are still relevant in the Power Platform world
  • This is also a great motivation for those of us who has not spent too much time working with PowerApps Portals to start ramping up the skills
  • And, finally, this is a great list of “reference projects” we all can use now if a prospective client wanted to get some examples of the “PowerApps Portal projects”

Hunting for that elusive dependency

I’ve been hunting a missing dependency in my solution for almost two days. You’d think that should have been piece of cake – just go to the solution, and missing component, and that’s all you need to do. But, then, is it that simple?

Here is the story of one elusive relationship (all table names in this post have been adjusted to have a simple repro which is different from the original solution).

It all started like this:

image

(That’s nice how we can see solution import errors right away in the preview, isn’t it? No need to download anything)

Before I continue, let me clarify what’s in the solution.

There is a new “Contact Details” table, and there is new lookup column that’s been added to the out of the box Contact table. That lookup is referencing my new “Contact Details” table.

“Contact Details” are added to the solution with all subcomponents. For the contact table, I only have new lookup field added:

image

Although, looking at the Contact relationships, it seems that a corresponding relationship has also been added:

image

It’s exactly the relationship that gets listed under missing dependencies when I’m trying to import this solution to another environment.

Now keep in mind this is a stripped down version – I did not have it like this in the original solution. There were other tables, processes, etc. It took me a few hours of re-arranging solution components and looking at the xml files to arrive at the repro above, and, then, to finally figure out what went wrong.

And you know what the problem turned out to be? It’s the order in which those components are added to the solution.

The error happens when I do it this way:

  • Add new custom table with all subcomponents first
  • Then add Contact table and select new lookup column as the only subcomponent

I’m saying “the only subcomponent”, since, in this scenario, I can’t manually add relationship for that lookup to the Contact table. It does show up in the solution, but it’s not that I’m adding it intentionally:

Here, I’ just removed “Contact” table from the solution, and I’m trying to re-add it. I’ve already selected the lookup column, now I’m looking at the relationships, and I don’t see the one which would be missing on import (the name would start with ita_…):

image

Then let’s try doing it in the other order:

  • Add Contact table, then choose lookup column, AND, also, choose that relationship from the list of subcomponents
  • Then add “Contact Details” table with all subcomponents

Surprisingly, the relationship is showing up on the list:

image

And here is my updated solution:

image

Would you even know it’s been updated just by looking at it?

But, when importing this version, the outcome is quite different:

image

Now we are talking!

As usual in such cases, I’m not sure if this was intended behavior, or if this is a possible omission/bug. But, as long as we know how it works,  we can avoid spending two more days next time playing hide and seek with those subcomponentsSmile

The last day of Internet Explorer

As of Aug 18 2021, Internet Explorer is not supported by Microsoft 365 apps and services, Microsoft Dynamics 365, and Microsoft Power Platform. So, even if, somehow, it’s still there due to the corporate polices, it’s probably the last time I see a web page in the Internet Explorer:

image

https://docs.microsoft.com/en-ca/lifecycle/announcements/internet-explorer-11-support-end-dates

From here on, there is just no reason to have it.

PS. So, for example, I can safely use classes in my javascript web resources (I guess among other things), since, even though Internet Explorer would not support those, it does not matter anymore.

Have you noticed a change in the field mapping logic?

There seems to be new mapping behavior in my environment as of this morning – it could be a feature, but it could also be a bug. But it’s something to be aware of.

Notice how, when creating a new record to populate a lookup, I’m getting one of the fields (“Feature Book”) populated automatically:

lookupmapping

This is normally supposed to happen on the 1:N relationships (so, basically, in the subgrids) where we can define mappings. And I have that mapping defined in my test solution, but that’s a different relationship:

image

In case with the lookup above (which is N:1), I could still define the mapping, but it would be from Author to Book:

image

So, apparently, since I have sort of a “circular” relationship between those two tables, the system is picking up on the “reverse” relationship mapping when I’m populating the lookup.

Now that’s interesting, and could be useful, but, it seems, I just can’t differentiate, anymore, between adding a record from the lookup and adding it from the subgrid (so can’t say, easily, if the record being created is on the “N” side of the relationship, or if it’s on the “1” side).

Performance insights for model-driven apps

With the performance insights feature available in preview now, I was wondering what is it I could possibly learn about one of my applications?

For the most part, what I found there is not, necessarily, actionable. There are a few informational messages, and there are a few warnings; however, there is one insight that I got curious about:

image

So, cold page loads are slower than warm page loads, and they can be as much as 100% slower. The difference between cold page loads and warm page loads is not, necessarily, that we would be opening our app for the first time on that day – it’s more about how we’d be opening it. As long as we are “starting” a new browser and/or using a new tab, the page load is considered to be “cold”. Otherwise, when we are using existing browser window/tab, that’s a warm load:

https://docs.microsoft.com/en-us/powerapps/maker/common/performance-insights-categories#page-load-type

image

That reminded me of the discussion I had with a colleague a couple of weeks ago. Both of us kept noticing slow load times in different applications, here and there, and those times might seem pretty significant sometimes. Unfortunately, I did not check performance insights at that time (and, besides, it might not even be available back then), but now I am wondering if having client-side only cold/warm page load details would be enough to troubleshoot or if we might also need server-side “cold/warm” information there? In reality, it’s, likely, both of those pieces that we may need?

Either way, curious to see how far Microsoft can take this tool – looking forward to this feature going GA.

Command Checker for model-driven app ribbons

I keep saying there is just no way to know everything about Power Platform these days.

Below is a a year-old news, and I just ran into it out of a sudden while trying Power FX buttons (which I am still trying). Somehow, a new item showed up on the menu which I am pretty sure I have not seen before:

image

Huh?

Turned out it’s a very useful tool that was first released more than a year ago:

https://powerapps.microsoft.com/en-us/blog/introducing-command-checker-for-model-app-ribbons/

It is normally hidden from the ribbon, and you have to add ribbondebug=true to the url for this option to even show up. I guess while I was working with all those preview features (pages, Power FX commanding, modern app designer), that parameter got added to the url at some point, so that’s how I ended up enabling command checker without even knowing about it.

So now that I know it’s there, though, I am just thinking of how useful it would be every time I were adding a new button to the ribbon, since I would have to spend a bit of time troubleshooting rules for almost each of those buttons. What if I could just open the command checker and see what’s going on?

image

Oh, the button is there… but that specific rule has evaluated to false. No need to do the guess work.

Although, it seems this tool is not, yet, completely hooked up to the Power FX command buttons, since here is what I see for one of them:

image

I’m guessing there is some kind of script behind which is not recognized by the command checker, but which is created by the app designer for the button below:

image

Ok, let’s put it this way then:

  • Command checker can be very useful when troubleshooting ribbon issues
  • However, it is not, yet, fully integrated with the Power FX commanding

It will probably be updated, though, so everything will come together.