Tuesday, January 15, 2019

PowerApps From A DevOps Perspective

In this post, I would like to talk about PowerApps from a DevOps perspective. When we think about DevOps we think about Source Control, Continuous Integration, Automation, Configuration Management etc. Let’s take a look into it.

No Source Control for PowerApps

When you are developing with PowerApps, there is no way to do Source Control. There are no source files. The only artifact you can version control is the .zip file that you can export. The application that you create/edit in the browser is continuously updated and whenever you feel like it is ready for publishing then you make that version of the application available to users in your organization. Lack of version control causes problems when you cannot track down which version of the application caused a particular bug. The only way to guarantee no bugs is by doing a thorough testing of the application.

Multiple Environments Beware

Creating a separate Dev, Test, UAT and Production environment is quite common for DevOps practices. In PowerApps, you can create separate environments in PowerApps but it comes with its own problems. For instance, in order to create and administer environments you need Plan 2 License in PowerApps. This is not a big deal since you can manage with one license. If you are creating application that uses On-Premises Data Gateway then only applications from the Default Environment can connect to the Gateway. Yeah! if you thought that was a bummer. Then you are right. Well all hope is not lost, if you really need it then you have to create a support ticket with Microsoft. Another limitation with multiple environments is that you cannot create as many environments as you like. Because you can only create two production environments. Another bummer. If you wanted Test, UAT and Production environment then you are toast. You will have to request another user license and then you would be able to create it. In PowerApps, having multiple environments creates more issues in my opinion from a DevOps perspective. It is not as seamless as one would come to expect from a traditional DevOps practice. If you are creating Model Driven apps only then it makes sense to create multiple environments. If you are creating only Canvas Driven apps then just create different apps with – DEV, TEST, UAT and PROD suffixes. Having multiple apps for different purposes creates it own issues as detailed below.

CI/CD Pipeline

In PowerApps, you don’t have to build your code. Any change you make to the application is live for you to test it. In that way it is very productive. To publish the application you just click on the publish button and it is live. But what if you screw an update, then you have an option of going back to a previous version of the application. The workflow of getting the application to end-users all the way to production is not seamless. Since we create different app for DEV,TEST,UAT we had to export and import every time we had to propagate a change to these apps. For one of the applications we built it was quite a lot of work every time we exported and imported into another application-dev/test/prod. For instance, we had to ensure that all the connections were pointing to environment specific connection strings, data going in accurately, perform manual checks, create a new flow every time.

Configuration Management

Well there is none. You cannot manage configuration of your PowerApps application in one place. For example, you can put app settings inside web.config file in a typical asp.net web application. In asp.net when you change environments then you can just update web.config. If you want to persist your app settings then it is better to put them inside a SQL table if you are utilizing On-Premises databases. In other words, store your app settings into an external persistent store.

Collaboration

It is very common to collaborate with brilliant team mates on different projects. If you are using any modern source control system then you can easily collaborate with Team members and work on features simultaneously. In PowerApps, only one developer can work on the application at given point of time. Good luck building your next ERP front end! One of the selling points of PowerApps is that it is very good for building quick small single purpose application that a single developer can churn out in days. But not good when you want to build a large application.

Since we are on the topic of collaboration let me add it here. If you developing application for an enterprise and think people are going to use it, then please don’t use your own personal account to develop the application. Because the user who creates the application becomes the owner of the application and guess what, you cannot change the owner of the application later on. If you are an ops guy then you want to have that ownership of the application. Please utilize a service account to develop PowerApps application.

That’s all I have for today and if you would like to share anything regarding PowerApps please let me know in the comment below.

Monday, December 17, 2018

5 Takeaways for Building PowerApps Application

In this post, I would like to share some of the pitfalls we encountered while developing an enterprise grade PowerApps Application.

First some background about the application. The key components of the application comprised of an on-premises SQL Server, Enterprise Data Gateway, Microsoft Flow and Windows Service. The SQL Server database consisted of enterprise ERP data and hence entities in this database had lots of columns just like a typical ERP system. The application we built was PowerApps Canvas application where you have more control over the look and feel of the application. We were surprised by how much you can customize the look of the application and make it look enterprizey [see I made up a new word].

Limit the number of controls
There are couple of reasons why you want to limit controls that are present on a page and in the whole application.

1. For performance reasons, in PowerApps Canvas driven apps, if you are adding lots of controls on a given page then performance of the application degrades. We saw performance of dropdowns controls and calendar controls decrease. Dropdown would appear after a delay and calendar popup would show after a delay.

2. In PowerApps if you add any control in the application then you can access that control from anywhere unlike Windows Forms page where you can only access controls that are present on a given page. Oh! that’s powerful you might say and that is why it is called PowerApps. As you add more controls to PowerApps, it becomes difficult to keep track of all the controls and soon you will run out of creative and unique names to provide for your controls.

3. After some point when you have lots of controls, you will forget control names and make mistakes while trying to reference the right control. Why did that popup didn’t disappear when it was supposed to.

Limit the logic you put into the Functions bar
One of the SOLID principles is Separation of Concerns and when you go against it then it bites you where it hurts the most. In PowerApps, presentation layer is meant for displaying and Microsoft Flow is for handling business logic processing. The Function bar at the top is so powerful that you can accomplish a whole lot with so many functions at your disposal. So no wonder we added a ton of business logic into it and to a point that lines of code increased to 1000 lines. No kidding. In hindsight, it is always easy to point the mistake and bang on the head that it was so obvious but everyday it is not. Let’s go through the issues with putting lot of lines of code into that tiny function bar at the top. People familiar with Excel will be able to relate to this.

1. Every single time to view code you have to expand the function bar.

2. Endless scrolling of numerous lines of code.

3. As lines of code increases, error messages looked like some ancient Egyptian symbols. We were spending hours debugging the error message. Luckily we knew how to comment code :) and narrow down the issues.

4. Smallest mistake or a syntax issue can take up hours to resolve it because the error message don’t point to the the current line of code. Oh and did I tell you that there are no line numbers for the code you write in that function bar.

5. Function bar freezes when there are many lines of code. Even few characters of text can take few seconds to appear. When you try to comment out a section it takes a while to take effect.

6. Bonus! There is no source control for that code. So if you broke something then good luck. Like a good programmer you should always use source control for any type of code. If you had lot of logic associated with a button and you clicked on Associated Flow with this button then oops you just lost all that logic. Please put code into source control.

Limit the number of columns and records you display
PowerApps is not meant to create the front end of an ERP system and it should not be used for such purposes. PowerApps shines when you build an application that fulfils that last mile gap. As there are more columns on a given page, the page becomes slower to respond and UX is not the best when a user has to scroll horizontally or vertically to view the full picture.

Put application settings into external table

In PowerApps, there is no App.Config or Web.Config file where one can put application settings and change them. So it is important that you store app settings into an external table. If you hard code some key into Application then when you try to export and import PowerApps to create a new application then you will have to edit that key again. Try to do that at multiple places and this process become quickly inefficient. Again this is basic 101 if you a developer.

Do not fear Flow because of Licensing issues

Early on we wanted to be cost effective and hence avoided using Flow. The moment we found ourselves stuck with having to debug 1000 lines of code again and again we decided to give Flow a chance. What we learnt after reading the docs is that for our purposes, the Flow quota allotted for per user per month were plenty. If you have Office 365 license then you have 2000 executions allowed per user per month and it is aggregated at the tenant level. As soon as we resorted to Flow and extracted key business logic into SQL Server stored procedure, we were back to application stability.

So that’s all I have to share this Monday late night. If you have your learnings regarding PowerApps please share in the comments below.

Tuesday, December 4, 2018

A20-Upgrading to Angular 7 and ASP.NET Core

This post is a part of a series of posts that I am writing as I am building an app using Angular and ASP.NET Core 2.1. Links to previous posts –> A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, A17, A18, A19Github Repo

Due to personal issues (new job, new country, India trip), I wasn’t able to blog.

Since I posted last time, Angular came out with Angular 7 and a new SDK for .NET Core also came out. Instead of continuing on the older version of Angular I decided to update everything.

I updated

Node to latest version v11.3.0.

NPM is at 6.4.1

I updated Visual Studio to latest and VS Code to latest version.

For updating angular to 7, I followed steps outlined at https://update.angular.io/

Updated Angular-cli globally and locally

Updated Angular Core and RxJs stuff.

Github warns you of vulnerabilities and everytime you run npm commands it shows you issues with packages. There were lot of package vulnerabilities so one by one I removed all of them and npm audit is not complaining anymore. 

After updating all the packages and running ng update for angular packages, I was getting errors when running dotnet run.

image

I had to update nuget package Microsoft.AspNetCore.SpaServices.Extensions. After updating it, I had to fix package.json scripts section’s start and build command to remove –extract-css flags.

Last issue I had to fix was related to certain rxjs operator usages in the application, eg. of, map, catch.

image

After fixing those I was able to compile and run the command dotnet run to view the application in the browser as I used to do before.

Thursday, July 12, 2018

A19–Building App using Angular and ASP.NET Core 2.1–Review Order Details

This post is a part of a series of posts that I am writing as I am building an app using Angular and ASP.NET Core 2.1. Links to previous posts –> A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, A17, A18 Github Repo

On training front, I finished Angular Reactive Forms course by Deborah Kurata on Pluralsight and I am watching Angular Services course by Brice Wilson.

Today, I was able to accomplish following.

1. Create a Review Order Page.

2. Create relevant server side API methods to return data

3. On submit button show confirmation page.

image

image

image

One of the things I had to change was make model names to be camelCase so when retrieving nested object they would display appropriately.

While there are many many issues with the app, I am able to do accomplish one workflow of being able to checkout products in a wizard style format. Notice that I am returning hard coded data for order review page. Once we figure out persistent store we can then return data from data store. There is also an issue with user identity. We want to associate orders with a person and we want to associate orders with unique id. All of that complexity can be handled piece by piece.

Next I want to tackle authentication piece.

That’s all I have for today. Checkout latest changes on github and website.

Tuesday, July 10, 2018

A18–Building App using Angular and ASP.NET Core 2.1–Reactive Forms, Submitting data

This post is a part of a series of posts that I am writing as I am building an app using Angular and ASP.NET Core 2.1. Links to previous posts –> A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16, A17 Github Repo

So I was able to accomplish following

1. Created classes to collect data from Form into Model for Shipping and Payment Pages.

2. Create CheckoutService to call Checkout controller methods

3. Created Controller methods for insert of shipping info and payment info

That’s all I have for today. Checkout latest changes on github and website.

Sunday, July 8, 2018

A17–Building App using Angular and ASP.NET Core 2.1–Reactive Forms Validation

This post is a part of a series of posts that I am writing as I am building an app using Angular and ASP.NET Core 2.1. Links to previous posts –> A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16 Github Repo

I am currently watching Angular Reactive Forms course on Pluralsight by Deborah Kurata. I like Reactive Forms.

Today, I added form validation to shipping info page and payment info page.

image

image

Couple of things to note regarding behavior

1. Validation occurs as soon as you tab our or touch a control.

2. If you click on Next button then validation messages will be shown

3. Simple Regex pattern matching used for phone, card number, security code

4. Added dropdown for selecting card type and expiration month and year

5. Custom group validation implemented for validation Expiration month.

image

Special thanks to Loiane Groner for sharing code @ repo to show validation on button click. This trick and using a method to display validation messages saved a ton of repetitive code for me. I like it a lot.

Thanks to Debora Kurata for sharing code @ repo.

That’s all I have for today. Checkout latest changes on github and website.

Wednesday, July 4, 2018

A16–Building App using Angular and ASP.NET Core 2.1–Reactive Forms

This post is a part of a series of posts that I am writing as I am building an app using Angular and ASP.NET Core 2.1. Links to previous posts –> A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15 Github Repo

I finished watching Angular Routing course and I think that it is very powerful. I like multiple router-outlet, child routes and route guard concept. Route resolver is a good concept too but I am running into issues when implementing in another child route.

Today using reactive forms I have added forms to collect shipping and payment information. There is no validation logic in there right now.

Shipping Info Form

image

Payment Info Form

image

One of my pet peeve with Angular is dependency injection. I ran into an issue with a child route resolver using a service and I couldn’t figure out why it won’t resolve the service. I wish there was a better way to let us know about why it couldn’t resolve the service. Can we have Angular Dependency Injection best practice guide?

Alright everyone, that’s all I have for today. Checkout latest changes on github and website.