SharePoint-liste eller Dataverse

Det sædvanlige svar er, at SharePoint er til dokumenter og Dataverse til data. Det hjælper ikke meget, for de fleste Power Apps bygget på SharePoint har slet ingen dokumenter. De har en liste med rækker, og spørgsmålet er, om listen er god nok. Det er lettere at se på en app end i det abstrakte, så her er en. Den er konstrueret til formålet og ikke en sag, men den er af den slags, valget normalt står om.

Appen#

Tag en kvalitetsafdeling på 25 personer, der registrerer afvigelser i en Power App: hvad skete der, hvor, hvem opdagede det, hvor alvorligt, og om det er lukket. Bagved ligger én SharePoint-liste med en kolonne for hver ting. I eksemplet kommer der et par hundrede afvigelser om året.

Her er der intet, der taler for Dataverse. En app på en SharePoint-liste bruger SharePoint-connectoren, som er en standardconnector og dækket af brugernes Microsoft 365-licens. Filteret på de åbne afvigelser er Status = "Åben", og = sendes videre til SharePoint for alle kolonnetyper (Microsoft). Listen kan have 30 millioner elementer (Microsoft), og appen når aldrig i nærheden. Det eneste, der er værd at gøre den første dag, er at sætte indeks på de kolonner, der filtreres på, for et indeks kan kun tilføjes, så længe listen har under 20.000 elementer (Microsoft).

Appen bliver en succes#

Så vil resten af virksomheden have den. I eksemplet bliver det 300 brugere i seks afdelinger, og med dem kommer fire nye ønsker: hver afvigelse skal have handlinger, der hver har en ansvarlig og en frist; hver afdeling må kun se sine egne afvigelser, mens kvalitetsafdelingen ser alle; ledelsen vil have et tal for, hvor mange afvigelser der har stået åbne i mere end 30 dage; og med nogle tusinde afvigelser om året passerer listen 5.000 elementer inden for et par år.

Hvert ønske rammer listen et bestemt sted.

Tallet til ledelsen. Power Apps sender kun en del af formlerne videre til SharePoint. På datoer virker < og >, så filteret på gamle, åbne afvigelser kan godt sendes videre. Men CountRows og CountIf kan SharePoint ikke, og heller ikke Not eller IsBlank på tekst (Microsoft, Microsoft). Det, der ikke delegeres, regnes på de første 500 rækker, højst 2.000 (Microsoft). Over det svarer appen forkert uden at fejle. Tallet kan stadig laves, men ikke med én formel i appen.

De 5.000. Visningsgrænsen på 5.000 gælder for forespørgsler på kolonner uden indeks (Microsoft). Blev indekset sat den første dag, er det ikke et problem. Blev det ikke, og har listen nået 20.000, kan det ikke rettes på listen selv.

Handlingerne. De bliver en ny liste med en opslagskolonne til afvigelsen, og SharePoint kan håndhæve relationen med Restrict delete eller Cascade delete (Microsoft). Men hvert opslag i en visning er en join, og SharePoint Server tillader tolv pr. forespørgsel. SharePoint Onlines side om grænser nævner ikke tallet, men Microsofts Power Query-side henviser til det for SharePoint Online (Microsoft). Personkolonner tæller med, så den ansvarlige for hver handling koster også. At gemme i en opslagskolonne fra Power Apps er heller ikke bare at sende teksten, se Gem valg fra en combobox i en opslagskolonne med Patch. Og en afvigelse med tre handlinger bliver gemt som fire elementer hver for sig. Går det tredje galt, står de to første. Dataverse’ Web API kan gemme flere ændringer som én transaktion, så alt rulles tilbage, hvis én fejler (Microsoft). Noget tilsvarende for en SharePoint-liste har jeg ikke fundet.

Afdelingerne. Det er det ønske, der gør mest ondt. I en app på en SharePoint-liste er det listens rettigheder, der bestemmer. Den, der skal kunne rette i appen, skal kunne rette i listen, også uden om appen (Sikkerheden i en Power App sidder i datakilden). Et filter i appen skjuler andre afdelingers afvigelser, men beskytter dem ikke. Skal de beskyttes, bliver det unikke rettigheder pr. element, typisk sat af et flow, hver gang en afvigelse oprettes. En liste kan have 50.000 unikke rettigheder, men Microsoft anbefaler højst 5.000 (Microsoft). Med nogle tusinde afvigelser om året er anbefalingen overskredet på et par år, og grænsen står længere fremme.

I Dataverse er det samme ønske en indstilling. Hver afdeling bliver en forretningsenhed, afvigelserne ejes af den, og en sikkerhedsrolle med læseadgang på forretningsenhedens niveau lader brugerne se deres egen afdelings rækker og ikke andres. Kvalitetsafdelingen får adgang på organisationsniveau (Microsoft). Rækkerne kan ses efter regler, ikke efter rettigheder sat en for en. Relationerne er en del af modellen, med regler for, hvad der sker med handlingerne, når afvigelsen slettes eller skifter ejer (Microsoft). Og CountRows og CountIf sendes videre til Dataverse, så tallet til ledelsen kan komme fra appen (Microsoft).

Licensen afgør det#

Teknisk peger alt nu på Dataverse. Men en app på Dataverse kræver, at hver bruger har en licens til Power Apps, pr. app eller pr. bruger, eller at appen betales med pay-as-you-go gennem et Azure-abonnement (Microsoft). At den, der byggede appen, har en licens, dækker ikke dem, der bruger den. Til 25 personer i én afdeling kunne det have været til at bære. Til 300 er det en ny post på budgettet hver måned, betalt for en app, der indtil nu har været gratis. Undtagelsen er Dataverse for Teams, der er med i Microsoft 365, men den bor i ét team og kan højst have omkring en million rækker og 2 GB (Microsoft), og et team er ikke hele virksomheden.

Så eksemplet ender ét af to steder, og det er licensen, der vælger.

Har virksomheden i forvejen Power Apps-licenser til de 300, fordi andre apps kræver dem, er Dataverse det rigtige valg, og det er værd at flytte, før listen bliver stor. En flytning fra en liste til Dataverse er en ny app med en ny datamodel, og den bliver ikke billigere af at vente.

Har den ikke, bliver appen på listen, og så skal listen bygges til det: indeks fra den første dag, filtre, der kan delegeres, tallet til ledelsen regnet uden for appen, og afdelingerne adskilt af noget andet end rettigheder pr. element, for eksempel en liste pr. afdeling. Det kan lade sig gøre. Det er bare mere arbejde, og sikkerheden bliver ved med at sidde i listen og ikke i regler.

Så#

En SharePoint-liste er det rigtige valg, indtil en af fire ting gør ondt: licensen er betalt alligevel, appen skal regne på flere rækker, end den kan delegere, data hænger sammen i flere lag, der skal gemmes samlet, eller sikkerheden skal følge regler i stedet for elementer. Afvigelsesappen rammer de tre tekniske, og alligevel er det licensen, der afgør den. Det er værd at spørge om alle fire, før den første kolonne oprettes, og om licensen først.

Microsofts egen sammenligning af Lists, Dataverse for Teams og Dataverse står på Compare data sources.