Power Platform: App Maker Challenge, deel 2

Ingediend door Dirk Hornstra op 02-jun-2022 22:30

In de eerste post kun je de link naar de challenge vinden (afronden voor 21 juni 2022).

Nog even terug komend op wat ik daar zei, ik had gekozen voor "Azure Developer Challenge", maar bij de start bleek dat ik al die blokken voor mijn studie voor Azure 204 al afgerond had. Toen ik vanmorgen inlogde en mijn tussenstand controleerde... kreeg ik te zien dat ik mijn challenge al afgerond had! Maar goed, omdat ik niet zeker weet of dat nu wel of niet meegeteld gaat worden kies ik voor de veilige weg, ook de challenge "Power Platform: App Maker Challenge" ga ik dus afronden!

Vandaag is het tijd voor blok 2, create tables in Dataverse. In het eerste blok hadden we al geleerd dat tabellen de basis van Dataverse is, vandaag dus kijken hoe dat praktisch werkt.

Het tweede blok, verwachte tijd 1 uur en 20 minuten.

Dataverse biedt je een aantal standaard tabellen. Maar je kunt ook je eigen tabellen aanmaken, je data importeren uit SharePoint, Excel, PowerQuery.

Dynamics 365 applicaties maken allemaal al gebruik van Dataverse.

Het advies is om de standaard structuur/tabellen te gebruiken en alleen bij uitzonderingen extra tabellen te maken om jouw business-logica in te verwerken.

  • Business rules: je data wordt over meerdere kolommen gevalideerd en bieden waarschuwingen en foutmeldingen.
  • Business process flow: de gebruiker wordt begeleid om te zorgen dat data consistent is en dat gebruikers altijd dezelfde stappen volgen. Process flows kun je alleen bij model-driven apps gebruiken.
  • Workflows: hiermee kun je bepaalde processen automatiseren, geen gebruikers-interactie nodig.
  • Business logic with code: soms moet je zaken zelf valideren, dat kan met eigen code.


Elke tabel staat gelijk aan een database-tabel, elke kolom gelijk aan een kolom in de tabel (wordt ook als "attribuut" omschreven).

Ook is er metadata. Dat zijn tabellen met data over de structuur van je tabellen. Dus als je de tabellen aanpast, de relaties tussen de tabellen, dan pas je de metadata aan.

Ook hier weer het advies: gebruik zoveel mogelijk de standaard tabellen.
Wil je een "display name" een kolom aanpassen, dan kan dat, hier hoef je geen eigen tabel voor te maken.
Je kunt standaard tabellen niet verwijderen, maar wel verbergen. Door via de security rollen in te stellen dat er geen Read-rechten meer zijn "is de tabel uit de meeste delen van de applicatie verdwenen".

Als je hiermee jouw probleem niet kan fixen, dan moet je mogelijk een nieuwe tabel, nieuwe kolom of nieuwe relatie aanmaken. En als een standaard tabel bijna voldoet, dan kun je die als basis voor een nieuwe tabel gebruiken.

Relaties geven aan welke relatie een rij in je tabel heeft met een rij in een andere tabel (of in dezelfde tabel).
Voor die interne verwijzing wordt deze link voor meer informatie gegeven: link

  • 1 op veel relatie: 1:N, je hebt 1 regel en daar zitten veel andere regels aan gekoppeld. Je hebt een parent-child relatie.
  • veel op veel relatie: N:N, veel regels in een tabel zijn gekoppeld aan veel andere regels. Deze relatie wordt omschreven als "peers".


Met een 1:N verhouding wordt ook data aangeleverd om deze vragen te beantwoorden:

  • als ik een rij verwijder, moeten de gerelateerde rijen ook verwijderd worden?
  • als ik een nieuwe eigenaar aan een rij toewijs, moeten de gerelateerde rijen ook aan die eigenaar gekoppeld worden?
  • hoe kan ik het "data toevoegen proces" stroomlijnen, als ik een nieuwe gerelateerde rij toevoeg bij een bestaande rij?
  • hoe zouden mensen die een rij kunnen zien de gerelateerde rijen kunnen zien?

Als je een eigen tabel aanmaakt, dan kun je eigenschap toewijzen aan "User", "Team owned" of "Organization-owned".

Als een tabel aangemaakt is, kun je de eigenaar niet meer wijzigen.

  • user of team owned: acties op een rij kunnen per user ingesteld worden.
  • organization owned: acties op de data worden op organisatie-level beheerd.


Activity tables

Dit is een "kalender record". Dus deze bevat:

  • tijd dimensie (start tijd, stop tijd, over-datum tijd en duur), waarmee je definieert wanneer de actie uitgevoerd werd of uitgevoerd gaat worden
  • bevat data (onderwerp, omschrijving) zodat je kunt zien wat voor activiteit dit is
  • acties zijn openen, annuleren, afronden. Bij de Completed status kun je met sub-statuswaarden meer duiding geven "hoe" de activiteit afgerond is


Eigenaar is user of team, kan niet aan een organisatie toebehoren.

Standaard implementaties hiervan zijn:

  • appointment (afspraak)
  • email
  • fax
  • brief
  • telefoongesprek
  • herhalende afspraak
  • taak (werk wat gedaan moet worden)


Je kunt zelf een activity tabel aanmaken. De metadata van activity tabellen wijkt af van ander type tabellen, de Primary kolom staat namelijk ingesteld op Subject (onderwerp).


Business Rules

Door voorwaarden en acties te combineren, kun je met de tabellen het volgende doen:

  • waarde van een kolom instellen
  • waarde van een kolom leeg maken
  • instellen van de requirements van een kolom
  • tonen of verbergen van kolommen
  • kolommen in- of uitschakelen
  • data valideren en foutmeldingen tonen
  • business aanbevelingen tonen op basis van business intelligence


Bij canvas-apps kun je ook business rules gebruiken, deze ondersteunt echter nog niet:

  • tonen of verbergen van kolommen
  • kolommen in- of uitschakelen
  • business aanbevelingen tonen op basis van business intelligence


Dual-write

Hiermee heb je een sterke koppeling tussen Dataverse en Finance en Operations apps. Bij wijzingen in de data in 1 van deze componenten, wordt het bijna real-time bijgewerkt in de andere componenten.

Meer informatie: link
 

Virtuele tabellen (virtual tables)

Hiermee integreer je data in externe systemen alsof het tabellen in Dataverse is, zonder replicatie van data en vaak zonder "op maat gemaakte code".

Vaak wordt maatwerk gemaakt om een dergelijke combinatie werkend te krijgen, waarbij het vaak niet perfect is, veel man-uren qua ontwikkeling. Dit maakt het een stuk makkelijker en beter te beheren en configureren door beheerders en personen die de rechten hebben om systemen aan te kunnen passen.

Meer informatie: link
 

Beide manieren kunnen een oplossing zijn voor je problemen. Welke moet je kiezen?
Volgens de site kies je voor dual-write als je werkt met Dynamics 365 apps die real-time info nodig hebben (hier wordt data gedupliceerd). Virtuele tabellen gebruik je voor externe data buiten Dynamics 365. Er zijn veel connectors beschikbaar die je kunt gebruiken, maar je kunt ook zelf een "custom connector" maken.

Dataverse biedt de mogelijkheid van "auditing" aan.
Binnen een organisatie kunnen aanpassingen in tabel- en kolomdata opgeslagen worden, zodat dit later met analyse en rapportage weer te geven is. Auditing wordt ondersteund op alle "custom tabellen en kolommen" en op de meeste "aanpasbare tabellen en kolommen". Aanpassingen op tabel- of kolomdefinities wordt niet ondersteund, ook niet op acties om data op te vragen, niet op export acties en ook niet tijdens authenticatie.

Wat is de standaard werking?
Je kunt auditing aan zetten op het niveau van de organisatie, op het niveau van tabellen en op het niveau van kolommen. Maar als het op niveau van organisatie niet aan staat, dan werkt het ook niet op niveau van tabellen en kolommen.
Standaard staat het aan op basis van organisatie, niet op basis van tabellen en kolommen.

Het ophalen en bekijken van audit-data is afgeschermd, alleen mensen met de juiste rechten kunnen dat: View Audit History en View Audit Summary. Ook zijn er rechten op partities: View Audit Partitions en Delete Audit Partitions.

Het activeren van auditing op organisatie-niveau, dat doe je in het record van de organisatie.
Voor de tabel of kolom doe je dat met een property-value van die tabel of kolom (dus in de meta-data - IsAuditEnabled).

Het aan of uit zetten, daarvoor moet je System Administrator of System Customizer zijn.


Hierna volgt een voorbeeld. Omdat ik niet in kan loggen met een account volg ik dus de uitleg in dit deel, maar voer ik zelf niets uit.

Dan volgt een voorbeeld van hoe je data importeert. Ook hier zelf geen actie. Wel de uitleg volgen, dus hoe je een sjabloon aanmaakt door eerst een export te maken en die hergebruikt om data te importeren.

Hierna volgt een voorbeeld van het maken van een eigen tabel waarin je verkopen en potentiƫle klanten gaat bijhouden.

Hierna volgen de vragen. De type relaties (die heb ik hier eerder genoemd).
Maar daarna wordt gevraagd: hoeveel apps kunnen dezelfde tabel gebruiken? Ik kan me niet herinneren dat ik die ben tegen gekomen (met een bepaale harde limiet). En dan nog een vraag over welk type product je de mogelijkheid geeft om rechten op tabellen voor verschillende gebruikers te kunnen geven. Er wordt in dit hoofdstuk redelijk vaak over 1 product gesproken, dus dat zal het hier ook zijn (ja dus!).