Bewerken

Delen via

Uiteindelijke consistentie tussen meerdere Power Apps-exemplaren

Microsoft Power Platform
Microsoft Dataverse
Azure Logic Apps

In dit artikel wordt een scenario beschreven waarin een hypothetische amerikaanse klant, Contoso, onlangs een ander bedrijf heeft overgenomen dat in Europa is gevestigd en zich in het proces van CRM- en ERP-systemen tussen de twee bedrijven bevindt. Als onderdeel van deze integratie moeten ze een deel van hun Dynamics 365 Dataverse-entiteiten synchroon houden totdat ze volledig kunnen worden geïntegreerd. Een Lob-app (Line-Of-Business) van Conotso verbruikt gegevens van beide systemen en moet aanvragen kunnen accepteren wanneer de gegevens wachten op synchronisatie of wanneer deze ontbreken. De volgende handleiding laat zien hoe u rekening moet houden met uiteindelijke consistentie tussen Power Platform-exemplaren.

Architectuur

Invoegtoepassing/stroom om altijd upsert te maken op basis van de GUID of alternatieve sleutel

diagram met een dataverse-invoegtoepassing die de oplossing biedt voor een mislukte synchronisatie van meerdere systemen.

Download een Visio-bestand van deze architectuur.

Werkstroom

Deze oplossing kan worden gebouwd met verschillende plugin stappen, binnen de levenscyclus van de invoegtoepassing. Wanneer de entiteit die u maakt verplicht is, gebruikt u de stap PreValidation. prevalidatie plaatsvindt voordat databasetransacties worden gestart. Dit is de voorkeursoptie, als het veld verplicht is. In sommige scenario's is een PreCreate--invoegtoepassingsstap echter voldoende.

  1. Het Amerikaanse exemplaar probeert een nieuw account te synchroniseren met de Europe Instance via een logische app. De Europe Instance is onbereikbaar vanwege downtime of upgrade.
  2. De Contoso LOB-app leest de hoofdaccountentiteiten uit de amerikaanse instantie. Het is van plan een API-aanroep in te dienen die verwijst naar een accountentiteit die niet is gerepliceerd naar de Europe Instance. Zoals het is, mislukt de API-aanroep omdat de record niet bestaat, omdat de synchronisatie niet werkt.
  3. Een PreValidation/PreCreate plugin voert echter eerst een upsert- uit op basis van de opgegeven entiteit-GUID en opgegeven referentiegegevens. Als deze al bestaat, wordt er niets gewijzigd. Als dit niet bestaat, wordt er een nieuw account gemaakt, waarbij de meeste velden leeg zijn.
  4. De API-aanroep slaagt omdat het account met de opgegeven id in het systeem bestaat. De invoegtoepassing heeft de bewerking onderschept en de ontbrekende record correct verwerkt. Het rapport van de LOB-toepassing wordt gegenereerd.

Notitie

Microsoft raadt u aan een circuitonderbrekerpatroon in uw aangepaste code te introduceren om terug te keren en opnieuw te proberen als onderdeel van deze oplossing voor het afhandelen van platformstoringen bij het verwijzen naar een van beide exemplaren. Zie circuitonderbrekerpatroonvoor meer informatie over het gebruik van een circuitonderbreker.

Alternatieven

In het bovenstaande scenario wordt een aangepaste logische app gebruikt als replicatiemethode. Er zijn echter meerdere manieren om gegevens te repliceren tussen Dataverse-exemplaren, waaronder, maar zijn niet beperkt tot:

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

Scenariodetails

Organisaties vinden af en toe de noodzaak om twee of meer Power Platform-exemplaren gesynchroniseerd te houden, met name een subset van Dataverse-entiteiten. Deze vereiste kan optreden wanneer een organisatie opzettelijk nieuwe exemplaren voor geografische isolatie heeft toegevoegd, maar een algemene gegevensset voor alle geografische gebieden nodig heeft. Het kan ook gebeuren wanneer twee organisaties samenvoegen voordat Power Platform-samenvoeging is voltooid.

Wanneer het synchronisatieproces werkt zoals ontworpen, hebben line-of-business-toepassingen die van beide exemplaren gebruikmaken geen problemen. Synchronisatiemechanismen zijn echter nooit foutbestendig, storingen of onverwachte problemen zullen zich waarschijnlijk voordoen. In dat geval moet uw Line-Of-Business-toepassing die gegevens van beide exemplaren verbruikt, worden gebouwd om onvolledige gegevens te verwerken.

Om de nieuwe Europese dochteronderneming van Contoso te kunnen integreren in de bedrijfsstructuur van Contoso, moeten ze accounts en contactpersonen van het ene exemplaar van Power Platform synchroniseren met een andere. In dit scenario synchroniseert het Amerikaanse exemplaar van Power Platform een dagelijkse batch referentiegegevens via een aangepaste logische app naar het Europese exemplaar. Een eigen Contoso LOB-app genereert rapportage over probleemtickets die gebruikers hebben gemaakt. Om deze taak te voltooien, leest de LOB-app gebruikersgegevens van beide Dataverse-exemplaren om de relevante gegevens, de primaire referentiesleutels van het Amerikaanse exemplaar en de ticketgegevens van het Exemplaar van Europa op te halen. Als het synchronisatieproces niet is voltooid vanwege downtime, onderhoud of een ander communicatieprobleem, veroorzaakt de aanvraag een fout omdat er entiteiten ontbreken in het Exemplaar van Europa.

Mogelijke gebruiksvoorbeelden

Dit patroon kan handig zijn in de volgende situaties:

  • Het systeem dat referentiegegevens verzendt, is niet beschikbaar.
  • Het synchroniseren van gegevens duurt lang of het proces wordt vertraagd.
  • Het gebruik van systemen heeft geen logica bij het maken van de entiteit die wordt gemaakt.

Wanneer u deze benadering gebruikt

Gebruik deze methode in de volgende scenario's:

  • U wilt garanderen dat een record met een bepaalde sleutel bestaat en het u niet schelen dat de record niet volledig is gehydrateerd.
  • U moet het maken accepteren, zelfs als de gegevens nog steeds niet worden gesynchroniseerd.

Dit patroon is mogelijk niet geschikt in het volgende scenario:

  • Logica wordt toegepast wanneer de record wordt gemaakt. Omdat de gegevens niet worden gehydrateerd, is het niet veilig om te vertrouwen op bepaalde eigenschappen die beschikbaar zijn.

Voorbeelden

In de volgende voorbeelden ziet u de mogelijke trajecten en het resultaat van synchronisatievertragingen.

voorbeeld 1: geslaagd pad zonder storingen of tijdelijke fouten

diagram met een geslaagde synchronisatie van meerdere systemen.

Download een Visio-bestand van deze architectuur.

  1. Het Amerikaanse exemplaar synchroniseert een nieuw account met het Europe Instance via een logische app. Alles werkt omdat er geen tijdelijke fouten of storingen zijn opgetreden.
  2. De Contoso LOB-app leest de hoofdaccountentiteiten van het AMERIKAANSE exemplaar en is van plan een API-aanroep in te dienen die verwijst naar een accountentiteit die is gerepliceerd naar de Europe Instance. Het werkt omdat alles op was en er geen storingen of tijdelijke fouten zijn opgetreden. Het rapport van de LOB-toepassing wordt gegenereerd.

voorbeeld 2: mislukt pad waarbij de synchronisatie offline of vertraagd is

diagram met een mislukte synchronisatie van meerdere systemen.

Download een Visio-bestand van deze architectuur.

  1. Het Amerikaanse exemplaar probeert een nieuw account te synchroniseren met de Europe Instance via een logische app. De Europe Instance is onbereikbaar vanwege downtime, onderhoud of een ander communicatieprobleem.
  2. De Contoso LOB-app leest de hoofdaccountentiteiten uit het Amerikaanse exemplaar en is van plan een API-aanroep in te dienen die verwijst naar een accountentiteit die niet is gerepliceerd naar de Europe Instance. De API-aanroep mislukt omdat het account met de opgegeven id niet is gemaakt in de Europe Instance en het rapport niet wordt gegenereerd.

Overwegingen

Houd rekening met de impact van bedrijfslogica op een entiteit die nog niet is gehydrateerd. Overweeg een scenario waarin de entiteit nog niet volledig gehydrateerd en gesynchroniseerd is. Sommige eigenschappen zijn null, dus u moet ervoor zorgen dat beslissingen over de gegevens worden meegerekend bij het gebruik van deze benadering.

Volgende stappen

Gerelateerde architecturen:

Richtlijnen voor webontwikkeling: