Blog, Microsoft Azure

Blog - Use case: Een low-code power app maken met de Microsoft Stack

Aug 8, 1:25 PM

Introductie

Use case implementatie: een krachtige, low-code applicatie bouwen uit Microsoft Stack componenten die gemakkelijk te onderhouden is en flexibel genoeg om te reageren op de veranderende aard van de evaluatievragen.

1. Het doel van de use case: evenwicht tussen flexibiliteit en lage code

Een van onze klanten wilde een applicatie om de antwoorden op hun klantenvragenlijsten in te voeren. De belangrijkste belofte was de uniformiteit van de opgeslagen gegevens. Aangezien de gegevens worden opgeslagen in een database, is dit een grote stap vooruit ten opzichte van het gebruik van Excel-bestanden die handmatig moeten worden gestandaardiseerd. De database stelt onze klant ook in staat om conclusies te trekken op basis van de gehele dataset in plaats van per geval.

Een tweede voordeel was de gebruiksvriendelijkheid van de applicatie. Enerzijds kunnen eindgebruikers intuïtief door de schermen navigeren. Anderzijds is de interne medewerker die verantwoordelijk is voor het onderhoud van de applicatie gewend te werken met low-code applicaties. Daarom hoefden er geen nieuwe vaardigheden te worden geleerd.

Kortom, we moesten een krachtige, low-code toepassing leveren, opgebouwd uit Microsoft Stack-componenten, die zowel gemakkelijk te onderhouden als flexibel genoeg was om in te spelen op de veranderende aard van de evaluatievragen.

2. De componenten van een succesvolle oplossing: de voorgestelde architectuur

Als oplossing hebben wij de volgende architectuur voorgesteld:

Power Automate zal worden gebruikt voor :

Alle gegevens uit Excel-bestanden in SharePoint-lijsten laden. Dit maakt massale uploads van grote datasets mogelijk.

b. de machtigingen van SharePoint-lijstitems regelen.

gebruikers op de hoogte stellen van bepaalde gebeurtenissen (bv. wanneer een vragenlijst is gepland of een evenement is toegevoegd aan de agenda van de beoordelaar).

Power Apps zal worden gebruikt om de applicatie te maken. Power Apps interageert onmiddellijk met de stromen en kan bijvoorbeeld de autorisatiestroom starten. Power Apps maakt ook verbinding met SharePoint-lijsten via CRUD-bewerkingen.

Ten slotte zullen SharePoint-lijsten worden gebruikt om de gegevens op te slaan. Deze lijsten zullen later worden gebruikt door Power BI, dat de actuele gegevens uit de vragenlijst zal visualiseren.

3. De aanpak: van een uniform gegevensmodel naar dynamische schermen

3.1 Een uniform gegevensmodel

Aangezien SharePoint-lijsten zullen worden gebruikt voor gegevensopslag, is referentiële integriteit uiterst belangrijk. Wij stelden onze klant een sterrenschema voor met dimensies voor vragen en mogelijke antwoorden (meerkeuze). Wij hebben nog een dimensie toegevoegd om de rol van de gebruikers (beoordelaar, partner, enz.) bij te houden. Er werd een dimensie gecreëerd om de gegevens van alle vragenlijsten (evaluaties) te verzamelen en een dimensietabel om de feitelijke antwoorden per vragenlijst te verzamelen. Zie hieronder voor een overzicht.

3.2 Dynamische schermen

Wat de toepassing betreft, hadden we kunnen kiezen voor een vast scherm per vraag, wat de ontwikkeling veel gemakkelijker zou hebben gemaakt. Deze oplossing zou echter niet flexibel zijn geweest, want als we bijvoorbeeld het aantal vragen hadden willen wijzigen, hadden we de toepassing moeten aanpassen. Deze onderlinge afhankelijkheid moet worden vermeden. Daarom kozen wij voor dynamische schermen met navigatie in code.

De volgende stappen zijn genomen om deze flexibiliteit te bereiken:

Alle vragen werden toegevoegd aan een verzameling in het geheugen, gesorteerd en geïndexeerd.

Voor alle vragen werd één enkel scherm gebruikt. Er werden filters toegepast op basis van het regelnummer. Zo werd bij de overgang van regel 1 naar regel 2 hetzelfde scherm gebruikt, maar werd de inhoud aangepast.

De pijlen "vorige" en "volgende" verhogen de index of gaan naar het volgende/vorige scherm (bijvoorbeeld het scherm voor het definitief indienen van de vragenlijst).

4. Prioriteit voor beveiliging: toegang per rol

Onze klant heeft drie verschillende rollen gedefinieerd:

De beoordelaar, die in eerste instantie de vragenlijst afneemt

De partner, die kan kiezen of hij het eens of oneens is met de antwoorden van de recensent

De manager, die alle vragen beoordeelt

4.1 Spelen met de variabele "zichtbaarheid" in Power Apps

Dezelfde schermen werden binnen de toepassing hergebruikt, maar afhankelijk van de gebruikersrol (gedefinieerd als dim_userrole) verschilde de esthetiek. Dit hergebruik van schermen was een groot voordeel. Het heeft niet alleen de lay-out gestandaardiseerd, maar ook de code op elke pagina vereenvoudigd.

4.2 SharePoint-machtigingen: toegang tot items in plaats van hele lijsten

In de regel moet een gebruiker toegang krijgen tot de juiste items/lijsten voordat deze worden weergegeven in de Power App. Hoewel de gebruiker gewoonlijk alleen toegang heeft tot de beoordeling via de Power App, is het essentieel dat de gebruiker geen ongeautoriseerde toegang heeft wanneer hij rechtstreeks door de lijsten bladert. Zo hoeft de beoordelaar geen bewerkingsrechten te hebben zodra de vragenlijst is ingevuld. Evenmin mag de beoordelaar items in een vragenlijst bekijken die niet aan hem zijn toegewezen.

Voor een grondiger controle van de machtigingen hebben wij ervoor gekozen verschillende Power Automate-stromen te starten vanuit de toepassing. Deze geven rechten op specifieke elementen in plaats van de machtigingen op de hele lijst vast te leggen. Zie een voorbeeld hieronder.

4.3 Rapportage over eerdere vragenlijsten met behulp van Power BI

Het Power BI-rapport genereert een overzicht van eerdere vragenlijsten, inclusief verschillende cijfers om de gegevens te aggregeren. Ook hier mochten alleen de vragenlijsten van een bepaalde gebruiker worden getoond. Daartoe werd beveiliging op rijniveau geïmplementeerd, gebaseerd op een groep in Power BI (deze groep werd toegevoegd aan de beveiligingseigenschappen van de dataset) en op de rol van de gebruiker in de dimensie Dim_userrole. In dit artikel(11 augustus 2017) vindt u een gedetailleerde handleiding van Tringuyenminh92 over de toepassing van dynamische beveiliging op rijniveau.

5. De voordelen benutten

U vraagt zich misschien af waarom onze klant koos voor een low-code applicatie in plaats van een applicatie vanaf nul op te bouwen. Naast de lagere installatiekosten had deze oplossing nog andere voordelen.

5.1 SharePoint-lijsten voor gebruiksvriendelijke gegevensopslag

Hoewel SharePoint-lijsten verre van perfect zijn (zie de nadelen), zijn ze gemakkelijk te gebruiken en te manipuleren. De gebruikersinterface is intuïtief en kan door leken worden gebruikt. Hoewel een echte relationele database meer consistentie biedt, is kennis van SQL vereist of moet een andere toepassing worden gemaakt om rechtstreeks met de gegevens te interageren.

5.2 Geen inzet van de Power App nodig

De toepassing kan direct worden gepubliceerd, dus er is geen behoefte aan een hostingruimte, een implementatieprocedure of extra beveiligingsmaatregelen. Met Power Apps kan een ervaren gebruiker zijn applicatie zelfstandig ontwikkelen, is versiebeheer geïntegreerd en zijn alle benodigde componenten beschikbaar in Microsoft Stack.

5.3 Eenvoudige formules

Gebruikers die gewend zijn formules te schrijven in Excel of DAX in Power BI zijn gemakkelijk vertrouwd met coderen in Power Apps. Bovendien kan code rechtstreeks worden toegepast op drag-and-drop elementen die gemakkelijk te interageren zijn.

5.4 Gemak van integratie

Zoals bij alle Microsoft-producten passen de gebruikte componenten perfect bij elkaar.

6. nadelen van de gebruikte onderdelen

6.1 Minder controle over de prestaties

In Power App moeten vaak zoekopdrachten worden uitgevoerd om specifieke items op te halen, zoals de juiste vraag op basis van de index (zie dynamische schermen). Deze zoekopdrachten zijn aanzienlijk minder efficiënt op grote gegevensverzamelingen, zoals lijsten van duizenden rijen.

Er bestaan echter verschillende oplossingen om de prestaties van de toepassing te waarborgen.

Filters kunnen worden toegepast zodra de verzameling in het geheugen is geladen, om het aantal rijen dat moet worden geanalyseerd te verminderen. Om de fix uit te voeren, kunt u eerst de collectie in het geheugen repareren voordat u de SharePoint-lijst repareert.

Aan SharePoint-lijsten kunnen verschillende indexen worden toegevoegd. Als een bepaald veld vaak wordt doorzocht, is het zinvol dat veld (of velden) als index te gebruiken.

Om het aantal regels te verminderen, kunt u eerdere evaluaties die niet meer nodig zijn archiveren met een Power Automate flow.

6.2 Geen lay-outsjabloon

Een van de meest frustrerende aspecten van drag-and-drop instellingen is het onvermogen om een lay-out sjabloon vast te stellen, zoals kan worden gedaan met front-end sjablonen zoals React. De meeste elementen moeten nog steeds handmatig worden gekopieerd en geplakt, zowel in Power BI als in Power Apps. Er bestaan verschillende oplossingen om dit proces te vereenvoudigen, maar ze zijn zeker niet voldoende.

Gebruik van variabelen: kleuren, lettertypen, enz. kunnen worden opgeslagen in variabelen, zodat niet elk element hoeft te worden gewijzigd als bijvoorbeeld de interne stijl wordt veranderd.
Gebruik van componenten: Dit is een premium instelling die alleen beschikbaar is voor de betaalde Power Apps pakketten. Deze instelling doet echter alleen bepaalde dingen, want u kunt een heel onderdeel zoals een menubalk maken. Deze component kan dan op alle pagina's worden geïntegreerd en wordt automatisch aangepast als de lay-out verandert.

6.3 Beperkt hergebruik van code

Het grote nadeel van Power Apps is ook een van zijn sterke punten: code kan rechtstreeks op de elementen worden opgeslagen, wat de intuïtiviteit ten goede komt. Het is echter onmogelijk de code in afzonderlijke variabelen op te slaan om deze op verschillende elementen toe te passen. Nogmaals, dit leidt tot veel kopiëren en plakken.

Bovendien is er geen zoekfunctie om de code op te zoeken. Dit betekent dat elk item afzonderlijk moet worden aangeklikt, met het risico van menselijke fouten. Dit nadeel kan terzijde worden geschoven voor kleine toepassingen, maar voor toepassingen met enkele duizenden regels code is een evaluatiefunctie een absolute noodzaak om de code centraal in variabelen op te slaan.

Conclusie

Kortom, de aan het begin van dit artikel voorgestelde architectuur is geschikt voor kleinere bedrijven die de algehele controle over de gegevens en het ontwerp van de applicatie graag overdragen aan hun ervaren gebruikers. Afgezien van de noodzakelijke abonnementen is de installatie relatief goedkoop en het onderhoud vrij eenvoudig. Wil je meer flexibiliteit? Er moeten andere oplossingen worden overwogen.