Slutlig konsekvens mellan flera Power Apps-instanser

Den här artikeln beskriver ett scenario där en hypotetisk usa-baserad kund, Contoso, nyligen har förvärvat ett annat företag baserat i Europa och håller på att hantera 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-företagsspecifik 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 för att alltid upsert baserat på GUID eller alternativ nyckel

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Den här lösningen kan skapas med flera steg i plugin-programmets livscykel. När entiteten som du skapar är obligatorisk använder du steget PreValidation. PreValidation sker innan databastransaktioner startas. Det är det bästa alternativet om fältet är obligatoriskt. I vissa fall räcker det dock med plugin-programmet PreCreate .

1. Den amerikanska instansen försöker synkronisera ett nytt konto med Europainstansen via en logikapp. Det går inte att nå Europe Instance på grund av driftstopp eller uppgradering.
2. Contosos LOB-app läser huvudkontottiteterna från den amerikanska instansen. Den avser att skicka ett API-anrop som refererar till en kontoentitet som inte replikerades till Europainstansen. Api-anropet misslyckas som det ser ut nu eftersom posten inte finns på grund av att synkroniseringen inte fungerar.
3. Ett PreValidation/PreCreate-plugin-program utför dock först en upsert baserat på angivet entitets-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.
4. API-anropet lyckas eftersom kontot med det angivna ID:t finns i systemet. Plugin-programmet snappade upp åtgärden och hanterade den saknade posten på ett smidigt sätt. Rapporten från LOB-programmet har genererats.

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 för alla geografiska områden. Eller så kan det hända när två organisationer slås samman innan Power Platform-konsolideringen är klar.

När synkroniseringsprocessen fungerar som den ska har verksamhetsspecifika program som används från båda instanserna inte 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 problembegäranden 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 Instansen Europa. Om synkroniseringsprocessen inte har slutförts på grund av stilleståndstid, underhåll eller något annat kommunikationsproblem, genererar begäran ett fel på grund av att entiteter saknas i Instansen Europa.

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 för 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 synkroniseras.

Det här mönstret kanske inte är lämpligt i följande scenario:

• Logik tillämpas när posten skapas. Eftersom data inte blir 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 med den här arkitekturen.

1. Den amerikanska instansen synkroniserar ett nytt konto med Europainstansen via en logikapp. Alla fungerar eftersom inga tillfälliga fel eller avbrott har inträffat.
2. Contosos LOB-app läser huvudkontottiteterna från den amerikanska instansen och avser att skicka ett API-anrop som refererar till en kontoentitet som replikerades till Europainstansen. Det fungerar eftersom allt var igång och inga avbrott eller tillfälliga fel inträffade. Rapporten från LOB-programmet har genererats.

Exempel 2 – Misslyckad sökväg där synkroniseringen är nere eller fördröjd

Ladda ned en Visio-fil med den här arkitekturen.

1. Den amerikanska instansen försöker synkronisera ett nytt konto med Europainstansen via en logikapp. Europainstansen kan inte nås på grund av driftstopp, underhåll eller något annat kommunikationsproblem.
2. Contosos LOB-app läser huvudkontottiteterna från den amerikanska instansen och avser att skicka ett API-anrop som refererar till en kontoentitet som inte replikerades till Europainstansen. API-anropet misslyckas eftersom kontot med den angivna identifieraren inte skapades i Europainstansen och rapporten inte genereras.

Ö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

• Power Platform
• Vad är Power Apps?
• Vad är Azure Logic Apps?
• Kom igång med Power Automate

Relaterade resurser

Relaterade arkitekturer:

• CI/CD för Microsoft Power Platform
• Medborgar-AI med Power Platform
• Power Automate-distribution i stor skala

Vägledning för webbutveckling:

• Tio designprinciper för Azure-program
• Design- och implementeringsmönster
• metodtips för App Service distribution
• Microsoft Azures välstrukturerade ramverk