In dit artikel wordt een scenario beschreven waarin een hypothetische klant in de VS, Contoso, onlangs een ander bedrijf in Europa heeft overgenomen en bezig is met CRM- en ERP-systemen tussen de twee bedrijven. Als onderdeel van deze integratie moeten ze een deel van hun Dynamics 365 Dataverse-entiteiten gesynchroniseerd houden totdat ze volledig kunnen worden geïntegreerd. Een bedrijfseigen 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 houdt met uiteindelijke consistentie tussen Power Platform-exemplaren.
Architectuur
Invoegtoepassing/stroom om altijd upsert te maken op basis van de GUID of alternatieve sleutel
Een Visio-bestand van deze architectuur downloaden.
Werkstroom
Deze oplossing kan worden gebouwd met verschillende stappen voor invoegtoepassingen , binnen de levenscyclus van de invoegtoepassing. Wanneer de entiteit die u maakt verplicht is, gebruikt u de stap PreValidation. PreValidatie vindt plaats voordat er databasetransacties worden gestart. Dit is de voorkeursoptie als het veld verplicht is. In sommige scenario's is een stap voor de invoegtoepassing PreCreate echter voldoende.
- Het Amerikaanse exemplaar probeert een nieuw account te synchroniseren met het Exemplaar van Europa via een logische app. Het Exemplaar van Europa is onbereikbaar vanwege downtime of upgrade.
- De Contoso LOB-app leest de hoofdaccounttiteiten van het Amerikaanse exemplaar. Het is de bedoeling om een API-aanroep in te dienen die verwijst naar een accountentiteit die niet is gerepliceerd naar het Exemplaar van Europa. Zoals het er nu uit ziet, mislukt de API-aanroep omdat de record niet bestaat, omdat de synchronisatie niet werkt.
- Een PreValidation/PreCreate-invoegtoepassing voert echter eerst een upsert uit op basis van de opgegeven entiteits-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.
- 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 probleemloos verwerkt. Het rapport van de LOB-toepassing is gegenereerd.
Notitie
Microsoft raadt aan om een circuitonderbrekerpatroon in uw aangepaste code te introduceren om het als onderdeel van deze oplossing opnieuw te proberen om platformstoringen te verwerken wanneer er naar een van beide exemplaren wordt verwezen. Zie Circuitonderbrekerpatroon voor meer informatie over het gebruik van een circuitonderbreker.
Alternatieven
In het hierboven beschreven scenario wordt een aangepaste logische app als replicatiemethode gebruikt. Er zijn echter meerdere manieren om gegevens te repliceren tussen Dataverse-exemplaren, waaronder, maar niet beperkt tot:
- Logic Apps
- Functie-apps in Azure Functions
- Azure Data Factory
- Azure Synapse Analytics
- Power Automate
Scenariodetails
Organisaties vinden soms de noodzaak om twee of meer Power Platform-exemplaren gesynchroniseerd te houden, meer specifiek, meestal een subset van Dataverse-entiteiten. Deze vereiste kan optreden wanneer een organisatie opzettelijk nieuwe exemplaren voor geografische isolatie heeft toegevoegd, maar een gemeenschappelijke gegevensset nodig heeft voor alle geografische gebieden. Het kan ook gebeuren wanneer twee organisaties samenvoegen voordat de consolidatie van Power Platform 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 ervoor te zorgen dat de nieuwe Europese dochteronderneming van Contoso kan worden geïntegreerd in de bedrijfsstructuur van Contoso, moeten ze accounts en contactpersonen synchroniseren van het ene exemplaar van Power Platform naar het andere. In dit scenario synchroniseert het Amerikaanse exemplaar van Power Platform een dagelijkse batch met 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 uit beide Dataverse-exemplaren om de relevante gegevens, de primaire referentiesleutels uit het Amerikaanse exemplaar en de ticketgegevens uit het Exemplaar van Europa op te halen. Als het synchronisatieproces niet is voltooid vanwege downtime, onderhoud of een ander communicatieprobleem, produceert de aanvraag een fout vanwege ontbrekende entiteiten in het Europe-exemplaar.
Potentiële gebruikscases
Dit patroon kan handig zijn in de volgende situaties:
- Het systeem dat referentiegegevens verzendt, is niet beschikbaar.
- De synchronisatie van gegevens duurt lang of het proces is vertraagd.
- Het gebruik van systemen heeft geen logica voor het maken van de entiteit die wordt gemaakt.
Wanneer gebruikt u deze methode?
Gebruik deze methode in de volgende scenario's:
- U wilt garanderen dat er een record met een bepaalde sleutel bestaat en u vindt het niet belangrijk dat de record niet volledig is gehydrateerd.
- U moet het maken accepteren, zelfs als de gegevens nog steeds niet zijn 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 storing of tijdelijke fouten
Een Visio-bestand van deze architectuur downloaden.
- Het Amerikaanse exemplaar synchroniseert een nieuw account met het Exemplaar van Europa via een logische app. Alle werken omdat er geen tijdelijke fouten of storingen zijn opgetreden.
- De Contoso LOB-app leest de hoofdaccounttiteiten van het Amerikaanse exemplaar en is van plan een API-aanroep in te dienen die verwijst naar een accountentiteit die is gerepliceerd naar het Exemplaar van Europa. Het werkt omdat alles in werking was en er geen storingen of tijdelijke fouten zijn opgetreden. Het rapport van de LOB-toepassing is gegenereerd.
Voorbeeld 2: mislukt pad waarbij synchronisatie niet is uitgevoerd of vertraagd
Een Visio-bestand van deze architectuur downloaden.
- Het Amerikaanse exemplaar probeert een nieuw account te synchroniseren met het Exemplaar van Europa via een logische app. Het Exemplaar van Europa is onbereikbaar vanwege downtime, onderhoud of een ander communicatieprobleem.
- De Contoso LOB-app leest de hoofdaccountentiteiten van het Amerikaanse exemplaar en is van plan een API-aanroep te verzenden die verwijst naar een accountentiteit die niet is gerepliceerd naar het Exemplaar Van Europa. De API-aanroep mislukt omdat het account met de opgegeven id niet is gemaakt in het Exemplaar van Europa 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 eventuele beslissingen over de gegevens worden meegerekend wanneer u deze methode gebruikt.
Volgende stappen
Gerelateerde resources
Verwante architecturen:
- CI/CD voor Microsoft Power Platform
- Citizen AI met het Power Platform
- Implementatie van Power Automate op schaal
Richtlijnen voor webontwikkeling: