Den här artikeln beskriver ett scenario där en hypotetisk amerikansk kund, Contoso, nyligen har förvärvat ett annat företag baserat i Europa och håller på att bearbeta CRM- och ERP-system mellan de två företagen. Som en del av den här integreringen måste de hålla en del av sina Dynamics 365 Dataverse-entiteter synkroniserade tills de kan integreras helt. En conotso proprietär verksamhetsspecifik app (LOB) förbrukar data från båda systemen och måste kunna acceptera begäranden när data väntar på synkronisering eller när de saknas. Följande guide visar hur du kan ta hänsyn till eventuell konsekvens mellan Power Platform-instanser.
Arkitektur
Plugin-program/flöde till alltid upsert baserat på GUID eller alternativ nyckel
Ladda ned en Visio-fil av den här arkitekturen.
Arbetsflöde
Den här lösningen kan skapas med flera plugin- steg i plugin-livscykeln. När entiteten som du skapar är obligatorisk använder du steget PreValidation. PreValidation inträffar innan databastransaktioner startas. Det är det bästa alternativet om fältet är obligatoriskt. I vissa scenarier räcker det dock med ett Förskapa plugin-steg.
- Den amerikanska instansen försöker synkronisera ett nytt konto med Europe Instance via en logikapp. Europe Instance kan inte nås på grund av stilleståndstid eller uppgradering.
- Contosos LOB-app läser huvudkontottiteterna från US Instance. Den avser att skicka ett API-anrop som refererar till en kontoentitet som inte replikerades till Europe Instance. API-anropet misslyckas eftersom posten inte finns på grund av att synkroniseringen inte fungerar.
- Ett PreValidation/PreCreate-plugin-programmet utför dock först en upsert- baserat på den angivna entitetens GUID och tillhandahållna referensdata. Om den redan finns ändras ingenting. Om det inte finns skapas ett nytt konto med de flesta fälten tomma.
- API-anropet lyckas eftersom kontot med det angivna ID:t finns i systemet. Plugin-programmet snappade upp åtgärden och hanterade den saknade posten korrekt. Rapporten från LOB-programmet genereras.
Not
Microsoft rekommenderar att du introducerar ett kretsbrytarmönster i din anpassade kod för att säkerhetskopiera och försöka igen som en del av den här lösningen för att hantera plattformsfel när du refererar till någon av instanserna. Mer information om hur du använder en kretsbrytare finns i Circuit Breaker Pattern.
Alternativ
Scenariot som beskrivs ovan använder en anpassad logikapp som replikeringsmetod. Det finns dock flera sätt att replikera data mellan Dataverse-instanser, som omfattar, men inte är begränsade till:
- Logic Apps
- Funktionsappar i Azure Functions
- Azure Data Factory
- Azure Synapse Analytics
- Power Automate
Scenarioinformation
Organisationer upptäcker ibland behovet av att hålla två eller flera Power Platform-instanser synkroniserade, mer specifikt, vanligtvis en delmängd av Dataverse-entiteter. Det här kravet kan inträffa när en organisation avsiktligt har lagt till nya instanser för geografisk isolering men behöver en gemensam datauppsättning i alla geos. Eller så kan det inträffa när två organisationer slås samman innan Power Platform-konsolideringen är klar.
När synkroniseringsprocessen fungerar som den är utformad har verksamhetsprogram som förbrukar från båda instanserna inga problem. Synkroniseringsmekanismer är dock aldrig felsäkra, avbrott eller oväntade problem kommer sannolikt att uppstå. I så fall måste ditt verksamhetsspecifika program som använder data från båda instanserna skapas för att hantera ofullständiga data.
För att Contosos nya europeiska dotterbolag ska kunna integreras i Contosos affärsstruktur måste de synkronisera konton och kontakter från en instans av Power Platform till en annan. I det här scenariot synkroniserar den amerikanska instansen av Power Platform en daglig batch med referensdata via en anpassad logikapp till den europeiska instansen. En egenutvecklad Contoso LOB-app genererar rapportering om problembiljetter som användare har skapat. För att slutföra den här uppgiften läser LOB-appen användardata från båda Dataverse-instanserna för att hämta relevanta data, de primära referensnycklarna från den amerikanska instansen och biljettdata från Europa-instansen. Om synkroniseringsprocessen inte har slutförts på grund av stilleståndstid, underhåll eller något annat kommunikationsproblem skapar begäran ett fel på grund av att entiteter saknas i Europa-instansen.
Potentiella användningsfall
Det här mönstret kan vara användbart i följande situationer:
- Systemet som skickar referensdata är nere.
- Synkroniseringen av data tar lång tid eller så fördröjs processen.
- Att använda system har ingen logik när det gäller att skapa entiteten som skapas.
När du ska använda den här metoden
Använd den här metoden i följande scenarier:
- Du vill garantera att en post med en viss nyckel finns, och du bryr dig inte om att posten inte är helt hydratiserad.
- Du måste acceptera skapandet, även om data fortfarande inte är synkroniserade.
Det här mönstret kanske inte är lämpligt i följande scenario:
- Logik tillämpas när posten skapas. Eftersom data inte är hydratiserade är det inte säkert att förlita sig på att vissa egenskaper är tillgängliga.
Exempel
I följande exempel visas potentiella resor och resultatet av synkroniseringsfördröjningar.
Exempel 1 – Lyckad sökväg utan avbrott eller tillfälliga fel
Ladda ned en Visio-fil av den här arkitekturen.
- Den amerikanska instansen synkroniserar ett nytt konto med Europe Instance via en logikapp. Alla fungerar eftersom inga tillfälliga fel eller avbrott har inträffat.
- Contoso LOB-appen läser huvudkontottiteterna från US Instance och avser att skicka ett API-anrop som refererar till en kontoentitet som replikerades till Europe Instance. Det fungerar eftersom allt var igång och inga avbrott eller tillfälliga fel inträffade. Rapporten från LOB-programmet genereras.
Exempel 2 – Misslyckad sökväg där synkroniseringen är nere eller fördröjd
Ladda ned en Visio-fil av den här arkitekturen.
- Den amerikanska instansen försöker synkronisera ett nytt konto med Europe Instance via en logikapp. Europe Instance kan inte nås på grund av stilleståndstid, underhåll eller något annat kommunikationsproblem.
- Contosos LOB-app läser huvudkontottiteterna från US Instance och avser att skicka ett API-anrop som refererar till en kontoentitet som inte replikerades till Europe Instance. API-anropet misslyckas eftersom kontot med den angivna identifieraren inte skapades i Europe Instance och rapporten genereras inte.
Överväganden
Överväg effekten av affärslogik på en entitet som inte är hydratiserad ännu. Tänk dig ett scenario där entiteten inte är helt hydratiserad och synkroniserad ännu. Vissa av egenskaperna är null, så du måste se till att alla beslut om data beaktas när du använder den här metoden.
Nästa steg
Relaterade resurser
Relaterade arkitekturer:
Vägledning för webbutveckling: