Thursday, August 9, 2018

Breaking PowerApps - Cannot Save or Edit an app

I just wrapped up about 12 hours of me wondering if I should keep trying to figure out this problem or if I should just quit and start filling out job applications.

It turns out that if you make a change to a SharePoint list that a Model PowerApp links to then it is possible your application can get in such a state that you cannot even edit or save any changes to it.  Completely unusable.  Completely broken.

Now imagine that somebody else controls the SharePoint list you are linking to...

So what happened?


I had a request from the Product Owner on our project to change a field that currently holds a Boolean value.  It's a simple Yes/No field in SharePoint (which I've mentioned in another post is in no ways "simple" in SharePoint).  The request was to change it to an option for Blank, Yes, No.  For consistency with the rest of the application (which is intended to be maintained by a non-developer) I changed the field from a Yes/No to a Choice of values: Blank(default), Yes, No.  Then I went into my app to fix the link to the altered field assuming worst case I'd need to delete the current DataSource and refresh/re-link to it.

Nope.

When I opened the application in PowerApps I immediately knew something was seriously wrong.  Colors were wrong, fields were displayed that shouldn't.  Only parts of the initialization code had run and parts hadn't.  And....I mean...Well just look at this:
Control Groups appear "corrupted"
These are two screen shots from what the Control Group "Read_Parameters" should look like.  It has 4 controls that are part of it: Start, Xfer_to_MainMenu, SetVariables, Xfer_to_.  The left is how it should look.  The right-hand side is what it looked like when I opened the app.  The control group was spread out and even an item that was not in the control group listed between the control group name and the items within it.  It was worse on pages where I had multiple control groups.  Complete anarchy.

Also, I could not edit or delete the fields that were linked to the now erroneous SharePoint list item.  And while I could delete the link to the entire DataSource, I COULD NOT SAVE THE APPLICATION!!!

In essence, nothing worked.

The application gave every indication that it was corrupted somehow.  Controls looked wrong, the screen wasn't fully responsive, most people would probably try to restore an old version at this point.

A Short Interlude...


I want you to imagine that you are a Business Analyst.  Someone who isn't specifically a developer.  Someone who is the target audience for PowerApps.

You get up all chipper in the morning and ready to do your job and someone reports that they're getting a "data error" when attempting to save records in your app.  You put down your coffee, log in, open up your app and...mayhem.

There is no indication as to what went wrong.  No pointer to tell you that the SharePoint list changed.  It just appears that your entire application is "corrupt".

So you restore to an earlier version aaaaand....that one is "corrupt" too.

You take a moment to look around your cubicle just to see if you're being punked.  Or perhaps if your supervisor has realized that you are in way over your head.  Which...you are.


Sometimes a simple fix isn't so simple in SharePoint


In my own scenario, I was lucky to be the same idiot who made the change to SharePoint's List so I knew the root cause.  I eventually stopped trying to fix the application and went back to trying to fix SharePoint.  And that...well...let me explain.

Let's say you are given a specification at the beginning which states that you should store certain data and display it in a certain way.  In my scenario, the original field names included spaces.  Which...if you're an old SharePoint person should set off alarm bells.  But I decided to see how o365 handled it and it appeared to work.

For simplicity, let's say I named my field "My Field".

While SharePoint displays this properly, it references this under the hood as something else.  It names it: "My_x200_Field".  Now this is not in and of itself a problem if you're just doing SharePoint stuff.  It looks like "My Field" to users and everything hums along, but if you are referencing this from any other application it uses the "My_x200_Field" name.

After seeing this in PowerApps and recognizing that it was a complete PiTA to guess which truncated field name was which (because it also shortens long names and similar field names cause huge problems), I renamed the field.  Cue head explosion from old SharePoint people.

SharePoint does not rename fields.  Oh it appears to, but it doesn't.  So me renaming my field as "MyField" to remove the spaces and fix this...didn't.  It just created yet another high-level UI link that displayed "MyField" but retained the original data source name "My_x200_Field".  Thanks...I guess.

So here we are again several months later.  I changed the field from a Boolean then to a Choice and blew up my application.  In the process of troubleshooting I try to change it back to Boolean.  You cannot.  So I exported the data and deleted the field.  Then I recreated the Yes/No Boolean field and named it:  "MyField".

You know where this is going.  It didn't work.

As a reminder, you cannot get into the application IDE easily to see any reference to this field so you wouldn't see that your application is actually looking for "My_x200_Field" vs. "MyField".  Despite SharePoint creating this high-level reference called "MyField", it doesn't use that for other applications.  Plus, there is no rollback in SharePoint changes like this even if you knew that the change caused it.  So you just need to know what the name the app is looking for is.  There is no other option.

Eventually, I found two ways to pull this off.  One won't help you.  I just went back to my notes from 3 months ago and read them.  However, for YOU, the solution is just to run your app.  Don't edit it, just run it.

The first time you try to save the data your app likely won't display the field that is the issue, but if you do it multiple times it will (by default - unless you've built in error handling and truly screwed yourself horribly).

The final solution for me was to create a Yes/No Boolean field, name it "My_x200_Field" then rename it to "MyField" then open my app in the IDE and everything works.

NOTE: You probably don't have to do the 2nd step (renaming the field) but when I start retracing my steps I get hyper-focused on the minutia.


Retrospective


This is a real problem for Microsoft's PowerApps IDE.  Also, it shows the kind of failing that happens when the Marketing doesn't meet with the Engineering.

PowerApps and SharePoint are directed as more of a 4GL platform intended for Business Analysts.  It is also a recognition of how Microsoft's vision ladders up into a larger business value where BA's can create business apps on top of existing data/processes and deliver value immediately.

This kind of complete failure at the UI side of the IDE shows how this vision isn't really baked into the product completely.  It makes some pretty broad assumptions that the developer of PowerApps is also the SharePoint developer.  In my case, this was true, but if the vision for this application is to be truly realized then it needs to allow the marketing hype to come true.

No comments:

Post a Comment

Because some d-bag is throwing 'bot posts at my blog I've turned on full Moderation. If your comment doesn't show up immediately then that's why.

DIAF Visualpath team