Letztliche Konsistenz zwischen mehreren Power Apps-Instanzen

In diesem Artikel wird ein Szenario beschrieben, in dem der hypothetische US-Kunde Contoso kürzlich ein anderes Unternehmen mit Sitz in Europa erworben hat und dabei ist, CRM- und ERP-Systeme zwischen den beiden Unternehmen zu integrieren. Im Rahmen dieser Integration muss der Kunde einen Teil seiner Dynamics 365 Dataverse-Entitäten synchron halten, bis sie vollständig integriert werden können. Eine proprietäre Branchen-App von Contoso nutzt Daten von beiden Systemen und muss Anforderungen annehmen können, wenn die Daten auf die Synchronisierung warten oder fehlen. Im folgenden Leitfaden wird gezeigt, wie Sie die letztliche Konsistenz zwischen Power Platform Instanzen sicherstellen können.

Aufbau

Plug-In/Flow zum ständigen Upsert auf Basis der GUID oder des alternativen Schlüssels

Diagramm eines Dataverse-Plug-Ins, das die Lösung für eine fehlgeschlagene Synchronisierung mit mehreren Systemen zeigt

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Diese Lösung kann mit mehreren Plug-In-Schritten innerhalb des Plug-In-Lebenszyklus erstellt werden. Wenn die Entität, die Sie erstellen, obligatorisch ist, verwenden Sie den PreValidation-Schritt. PreValidation erfolgt, bevor Datenbanktransaktionen gestartet werden. Dies ist die bevorzugte Option, wenn das Feld obligatorisch ist. In einigen Szenarien ist jedoch ein PreCreate-Plug-In-Schritt ausreichend.

1. Die US-Instanz versucht, ein neues Konto über eine Logik-App mit der Europa-Instanz zu synchronisieren. Die Europa-Instanz ist aufgrund eines Ausfalls oder Upgrades nicht erreichbar.
2. Die Contoso-Branchenanwendung liest die Hauptkontoentitäten aus der US-Instanz. Sie beabsichtigt, einen API-Aufruf zu übermitteln, der auf eine Kontoentität verweist, die nicht in der Europa-Instanz repliziert wurde. In der jetzigen Form schlägt der API-Aufruf fehl, weil der Datensatz nicht vorhanden ist, da die Synchronisierung nicht funktioniert.
3. Ein PreValidation/PreCreate-Plug-In führt jedoch zunächst ein Upsert basierend auf der bereitgestellten Entitäts-GUID und den bereitgestellten Referenzdaten aus. Wenn dies bereits vorhanden ist, wird nichts geändert. Wenn nicht vorhanden, wird ein neues Konto erstellt, wobei die meisten Felder leer sind.
4. Der API-Aufruf ist erfolgreich, da das Konto mit der angegebenen ID im System vorhanden ist. Das Plug-In hat den Vorgang abgefangen und den fehlenden Datensatz ordnungsgemäß verarbeitet. Der Bericht aus der Branchenanwendung wurde erfolgreich generiert.

Alternativen

Das oben beschriebene Szenario verwendet eine benutzerdefinierte Logik-App als Replikationsmethode. Es gibt jedoch mehrere Möglichkeiten, Daten zwischen Dataverse-Instanzen zu replizieren. Dazu gehören u. a.:

• Logic Apps
• Funktions-Apps in Azure Functions
• Azure Data Factory
• Azure Synapse Analytics
• Power Automate

Szenariodetails

Gelegentlich müssen Organisationen zwei oder mehr Power Platform-Instanzen synchron halten, genauer gesagt, in der Regel eine Teilmenge von Dataverse-Entitäten. Diese Anforderung kann vorliegen, wenn eine Organisation absichtlich neue Instanzen zur geografischen Isolierung hinzugefügt hat, aber einen gemeinsamen Datensatz für alle Regionen benötigt. Oder es kann vorkommen, dass zwei Organisationen zusammengeführt werden, bevor die Power Platform-Konsolidierung abgeschlossen ist.

Wenn der Synchronisierungsprozess wie vorgesehen funktioniert, gibt es bei Branchenanwendungen, die von beiden Instanzen genutzt werden, keine Probleme. Synchronisierungsmechanismen sind jedoch nie fehlerfrei, Ausfälle oder unerwartete Probleme sind wahrscheinlich. In diesem Fall muss Ihre Geschäftsanwendung, die Daten aus beiden Instanzen abruft, so konzipiert sein, dass sie mit unvollständigen Daten umgehen kann.

Damit die neue europäische Niederlassung von Contoso in die Geschäftsstruktur von Contoso integriert werden kann, müssen Konten und Kontakte von einer Instanz von Power Platform mit einer anderen synchronisiert werden. In diesem Szenario synchronisiert die US-Instanz von Power Platform einen täglichen Batch von Referenzdaten über eine benutzerdefinierte Logik-App mit der europäischen Instanz. Eine proprietäre Contoso-Branchenanwendung generiert Berichte zu Problemtickets, die Benutzer erstellt haben. Zu diesem Zweck liest die Branchenanwendung Benutzerdaten aus beiden Dataverse-Instanzen, um die relevanten Daten, die primären Referenzschlüssel aus der US-Instanz und die Ticketdaten aus der Europa-Instanz zu pullen. Wenn der Synchronisierungsprozess aufgrund von Ausfällen, Wartungsarbeiten oder einem anderen Kommunikationsproblem nicht abgeschlossen wurde, führt die Anforderung zu einem Fehler, da Entitäten in der Europa-Instanz fehlen.

Mögliche Anwendungsfälle

Dieses Muster ist in den folgenden Situationen nützlich sein:

• Das System, das Verweisdaten sendet, ist ausgefallen.
• Die Synchronisierung von Daten nimmt viel Zeit in Anspruch oder der Prozess verzögert sich.
• Verarbeitende Systeme haben keine Logik für die Erstellung der Entität, die kreiert wird.

Anwendungsfälle des Ansatzes

Nutzen Sie diesen Ansatz ist in den folgenden Szenarien:

• Sie möchten sicherstellen, dass ein Datensatz mit einem bestimmten Schlüssel vorhanden ist, und es ist nicht wichtig, dass der Datensatz nicht vollständig aufgefüllt ist.
• Sie müssen die Erstellung auch dann akzeptieren, wenn die Daten noch nicht synchronisiert sind.

Dieses Muster ist im folgenden Szenario möglicherweise nicht geeignet:

• Bei der Erstellung des Datensatzes wird Logik angewendet. Da die Daten nicht aufgefüllt werden, ist es nicht sicher, sich darauf zu verlassen, dass bestimmte Eigenschaften verfügbar sind.

Beispiele

Die folgenden Beispiele zeigen die potenziellen Journeys und das Ergebnis von Synchronisierungsverzögerungen.

Beispiel 1 - Erfolgreicher Pfad ohne Ausfall oder vorübergehende Fehler

Diagramm, das eine erfolgreiche Synchronisierung mit mehreren Systemen zeigt

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Die US-Instanz synchronisiert ein neues Konto über eine Logik-App mit der Europa-Instanz. Alle funktionieren, da keine vorübergehenden Störungen oder Ausfälle aufgetreten sind.
2. Die Contoso-Branchenanwendung liest die Hauptkontoentitäten aus der US-Instanz und beabsichtigt, einen API-Aufruf zu übermitteln, der auf eine Kontoentität verweist, die auf die Europa-Instanz repliziert wurde. Es funktioniert, weil alles aktiv war und keine Ausfälle oder vorübergehenden Fehler aufgetreten sind. Der Bericht aus der Branchenanwendung wurde erfolgreich generiert.

Beispiel 2 - Nicht erfolgreicher Pfad, bei dem die Synchronisierung unterbrochen wurde oder sich verzögert

Diagramm, das eine fehlgeschlagene Synchronisierung mit mehreren Systemen zeigt

Laden Sie eine Visio-Datei dieser Architektur herunter.

1. Die US-Instanz versucht, ein neues Konto über eine Logik-App mit der Europa-Instanz zu synchronisieren. Die Europa-Instanz ist aufgrund von Ausfällen, Wartungen oder einem anderen Kommunikationsproblem nicht erreichbar.
2. Die Contoso-Branchenanwendung liest die Hauptkontoentitäten aus der US-Instanz und beabsichtigt, einen API-Aufruf zu übermitteln, der auf eine Kontoentität verweist, die nicht in der Europa-Instanz repliziert wurde. Der API-Aufruf schlägt fehl, weil das Konto mit dem angegebenen Bezeichner nicht in der Europa-Instanz erstellt wurde und der Bericht nicht generiert wird.

Überlegungen

Berücksichtigen Sie die Auswirkungen einer Geschäftslogik auf eine Entität, die noch nicht aufgefüllt ist. Stellen Sie sich ein Szenario vor, in dem die Entität noch nicht vollständig aufgefüllt und synchronisiert ist. Einige der Eigenschaften sind NULL, daher müssen Sie sicherstellen, dass alle Entscheidungen über die Daten bei diesem Ansatz berücksichtigt werden.

Nächste Schritte

• Power Platform
• Was ist Power Apps?
• Übersicht: Was ist Azure Logic Apps?
• Erste Schritte mit Power Automate

Zugehörige Ressourcen

Verwandte Architekturen:

• Bürger-KI mit Power Platform
• Power Automate-Bereitstellung im großen Stil

Leitfaden für die Webentwicklung:

• Zehn Entwurfsprinzipien für Azure-Anwendungen
• Bewährte Methoden der App Service-Bereitstellung
• Microsoft Azure Well-Architected Framework