Wenn eine Liste nicht ausreicht: Ein Fall für Dataverse und Model-Driven Apps
Ich arbeite gerne mit Microsoft Lists. Sie sind einfach zu erstellen und auszufüllen und bieten viele Möglichkeiten, die Benutzerfreundlichkeit mit Funktionen wie Spaltenformatierung und Funktionserweiterung durch Dienste wie die Power Platform zu verbessern.
Es gibt jedoch Situationen, in denen eine Liste nicht die richtige Wahl für die Datenspeicherung ist. Einfache Datenbeziehungen können in einer Liste mit Hilfe von Lookup-Spalten implementiert werden, aber hochkomplexe Beziehungen (many-to-many) sind schwierig zu implementieren. Die Standard-Sicherheitsoptionen in Lists sind auf den Ersteller des Elements oder jeden, der Zugriff darauf hat, beschränkt. Die Implementierung komplexer Sicherheitsmodelle, bei denen z. B. Abteilung “A” alle von Mitgliedern der Abteilung “A” erstellten Elemente einsehen kann, ist nicht möglich.
Viele wenden sich in diesen Situationen an Azure SQL Database oder Dataverse. Beides sind hervorragende Plattformen, die leistungsfähig, sicher und skalierbar sind, aber sie erfordern eine Front-End-Investition, die viele Nicht-Entwickler nicht bereit sind zu tätigen. Im Fall von Dataverse ist das logischste Front-End PowerApps als benutzerdefinierte Canvas-App oder eine sofort einsatzbereite Model-Driven-App.
Canvas vs. Model-Driven Apps
Wie der Name schon sagt, bieten Ihnen Canvas-Apps eine leere Leinwand, auf der Sie eine benutzerdefinierte Schnittstelle für die Interaktion mit Ihren Anwendern entwickeln können.
Model-Driven-Apps bieten eine konsistente Nutzererfahrung für die Interaktion mit Ihren Daten, indem sie es Ihnen ermöglichen, Listen, Formulare, Diagramme und Berichte unter Verwendung Ihres Datenmodells zu erstellen. Sie erhalten automatisch Funktionen, die Sie sonst in einer Canvas-Anwendung von Grund auf neu schreiben müssten (z. B. Suche, Sortierung, Filterung, Geschäftslogik, Durchsetzung von Geschäftsregeln, Export zu Excel, Dokumentenerstellung usw.), sodass Sie viel schneller mit Ihren Daten interagieren können.
Der Nachteil ist, dass man zwar gebrauchsfertige Funktionen erhält, aber nicht die Möglichkeit hat, präzise Anwendungen zu erstellen, wie es bei Canvas der Fall ist.
Ich nehme an, dass dies einer der Gründe ist, warum ich Microsoft Lists so sehr mag: Ich kann mich auf die Implementierung einer Struktur konzentrieren, die den jeweiligen Geschäftsprozess widerspiegelt, ohne mich in der Front-End-Entwicklung zu verzetteln.
Ein weiterer Vorteil von Dataverse ist der Zugriff auf das Common Data Model, eine Sammlung von vordefinierten Schemata (Tabellen, Attribute, Metadaten und Beziehungen), die häufig verwendete Objekte wie Konten und Kontakte repräsentieren. Dieser À-la-carte-Ansatz für die Datenmodellierung verkürzt unsere Time-to-Value. Außerdem wird durch gemeinsame Entitäten (Tabellen) und Daten ein höheres Maß an Wiederverwendbarkeit in unsere Lösungen eingeführt.
Ansatz
Es gibt viele Lösungen, die über Microsoft Lists hinausgewachsen sind und auf Dataverse und Model-Driven Anwendungen umsteigen, um diese Anforderungen zu erfüllen. Mein Ansatz bei diesen Umstellungen ist es, Überschneidungen in den Listenspalten und Daten zu finden, die besser dafür geeignet sind, eine gemeinsame Einheit zu werden. Ich habe zum Beispiel Kundendaten in vielen Listen. Wenn ich die Kundendaten zu einer einzigen Entität zusammenführe, muss ich nur auf eine einzige Quelle der Wahrheit verweisen und diese verwalten.
Der nächste Schritt besteht darin, festzustellen, ob eine bestehende Entität im gemeinsamen Datenmodell meine Anforderungen für die Speicherung der Kundendaten erfüllt. Die Entität “Konto” verfügt über die meisten Spalten, die ich benötige, und ermöglicht es mir, alle erforderlichen geschäftsspezifischen Spalten hinzuzufügen. Die Entität “Account” enthält wie alle Entitäten des Common Data Model alle Formulare und Ansichten, die ich benötige, um das Frontend meiner Anwendung zu starten.
Sobald die sich überschneidenden Daten zentralisiert sind und andere Common Data Model-Entitäten gefunden wurden, werden wir benutzerdefinierte Entitäten erstellen, um die Verfolgung unserer Geschäftsprozesse zu unterstützen. Es ist sehr wichtig, dass wir bei der Erstellung unserer neuen Entitäten die richtigen Tabellenbeziehungen zur Unterstützung der Geschäftsprozesse einrichten. In vielen Fällen werden wir unsere benutzerdefinierten Entitäten (für die Prozessverfolgung) mit unseren Common Data Model-Entitäten verbinden – wie z. B. Konto.
Schließlich werde ich auch die Datenimportoptionen wie Daten in Excel bearbeiten und Datenflüsse verwenden, um meine Daten in meine neue Datenbank zu migrieren und Power Automate hinzufügen, um all die alltäglichen Aufgaben zu automatisieren.
Schlussgedanken
Wie ich bereits erwähnt habe, gibt es Situationen, in denen Microsoft Lists nicht die richtige Lösung sind. Dataverse in Verbindung mit Model-Driven Anwendungen ist eine großartige Möglichkeit, ein Datenmodell zu entwickeln, das die Anforderungen der aktuellen und zukünftigen Geschäftsprozesse eines Unternehmens widerspiegelt. Ich hoffe, dass ich mit meinem Ansatz, von Lists auf Dataverse umzusteigen, einen Bezugspunkt liefern und andere, die den gleichen Schritt erwägen, bestärken konnte. Vielen Dank furs Lesen und ein besonderes Dankeschön an Hugo Bernier von Microsoft für seine Hilfe bei diesem Beitrag.
Bleiben Sie zu Microsoft 365 auf dem Laufenden, indem Sie unseren Blog abonnieren.
