Coerenza finale tra più istanze di Power Apps

Questo articolo descrive uno scenario in cui un ipotetico cliente statunitense, Contoso, ha recentemente acquisito un'altra società basata in Europa ed è in corso di elaborazione di sistemi CRM e ERP tra le due società. Come parte di questa integrazione, devono mantenere sincronizzate una parte delle entità Dynamics 365 Dataverse fino a quando non possono essere completamente integrate. Un'app line-of-business proprietaria di Conotso utilizza i dati di entrambi i sistemi e deve essere in grado di accettare richieste quando i dati sono in attesa di sincronizzazione o quando mancano. La guida seguente illustra come tenere conto della coerenza finale tra le istanze di Power Platform.

Architettura

Plug-in/flow per eseguire sempre l'upsert in base al GUID o alla chiave alternativa

Scaricare un file di Visio di questa architettura.

Flusso di lavoro

Questa soluzione può essere compilata con diversi passaggi del plug-in , all'interno del ciclo di vita del plug-in. Quando l'entità che si sta creando è obbligatoria, usare il passaggio PreValidation. La prevalidazione viene eseguita prima dell'avvio di tutte le transazioni di database. È l'opzione preferita, se il campo è obbligatorio. Tuttavia, in alcuni scenari, sarà sufficiente un passaggio del plug-in PreCreate .

1. L'istanza degli Stati Uniti tenta di sincronizzare un nuovo account con l'istanza europa tramite un'app per la logica. L'istanza europa non è raggiungibile, a causa di tempi di inattività o aggiornamento.
2. L'app line-of-business contoso legge le entità dell'account principale dall'istanza degli Stati Uniti. Intende inviare una chiamata API che fa riferimento a un'entità account che non è stata replicata nell'istanza di Europa. Come si verifica, la chiamata API non riesce perché il record non esiste, a causa della mancata esecuzione della sincronizzazione.
3. Tuttavia, un plug-in PreValidation/PreCreate esegue prima un upsert in base al GUID dell'entità fornito e ai dati di riferimento forniti. Se esiste già, non viene modificato nulla. Se non esiste, viene creato un nuovo account, con la maggior parte dei campi vuoti.
4. La chiamata API ha esito positivo perché l'account con l'ID specificato esiste nel sistema. Il plug-in intercetta l'operazione e ha gestito correttamente il record mancante. Il report dell'applicazione LINEB viene generato correttamente.

Alternativi

Lo scenario descritto in precedenza usa un'app per la logica personalizzata come metodo di replica. Esistono tuttavia diversi modi per replicare i dati tra istanze di Dataverse, tra cui, ma non solo:

• App per la logica
• App per le funzioni in Funzioni di Azure
• Azure Data Factory
• Azure Synapse Analytics
• Power Automate

Dettagli dello scenario

Le organizzazioni trovano occasionalmente la necessità di mantenere sincronizzate due o più istanze di Power Platform, in genere un subset di entità Dataverse. Questo requisito può verificarsi quando un'organizzazione ha aggiunto intenzionalmente nuove istanze per l'isolamento geografico, ma richiede un set di dati comune in tutte le aree geografiche. In alternativa, può verificarsi quando due organizzazioni si uniscono prima del completamento del consolidamento di Power Platform.

Quando il processo di sincronizzazione funziona come progettato, le applicazioni line-of-business che utilizzano da entrambe le istanze non presentano problemi. Tuttavia, è probabile che i meccanismi di sincronizzazione non siano mai prova di errore, interruzioni o problemi imprevisti. In tal caso, l'applicazione line-of-business che utilizza i dati di entrambe le istanze deve essere compilata per gestire dati incompleti.

Affinché la nuova filiale europea di Contoso sia integrata nella struttura aziendale di Contoso, deve sincronizzare account e contatti da un'istanza di Power Platform a un'altra. In questo scenario, l'istanza degli Stati Uniti di Power Platform sincronizza un batch giornaliero di dati di riferimento tramite un'app per la logica personalizzata all'istanza europea. Un'app LOB di Contoso proprietaria genera report sui ticket di problema creati dagli utenti. Per completare questa attività, l'app LINEB legge i dati utente da entrambe le istanze di Dataverse per eseguire il pull dei dati pertinenti, le chiavi di riferimento primarie dall'istanza degli Stati Uniti e i dati del ticket dall'istanza Europa. Se il processo di sincronizzazione non è stato completato a causa di tempi di inattività, manutenzione o un altro problema di comunicazione, la richiesta genererà un errore a causa di entità mancanti nell'istanza europa.

Potenziali casi d'uso

Questo modello può essere utile nelle situazioni seguenti:

• Il sistema che invia dati di riferimento è inattivo.
• La sincronizzazione dei dati richiede molto tempo o il processo viene ritardato.
• L'utilizzo dei sistemi non ha logica per la creazione dell'entità in fase di creazione.

Quando usare questo approccio

Usare questo approccio negli scenari seguenti:

• Si vuole garantire l'esistenza di un record con una determinata chiave e non è importante che il record non sia completamente idratato.You want to guarantee a record with a given key exists, and you don't care that the record isn't fully hydrated.
• È necessario accettare la creazione, anche se i dati non sono ancora sincronizzati.

Questo modello potrebbe non essere adatto nello scenario seguente:

• La logica viene applicata quando viene creato il record. Poiché i dati non verranno idratati, non è sicuro affidarsi a determinate proprietà disponibili.

Esempio

Gli esempi seguenti illustrano i possibili percorsi e il risultato dei ritardi di sincronizzazione.

Esempio 1- Percorso riuscito senza interruzioni o errori temporanei

Scaricare un file di Visio di questa architettura.

1. L'istanza degli Stati Uniti sincronizza un nuovo account con l'istanza europa tramite un'app per la logica. Tutto funziona perché non si sono verificati errori temporanei o interruzioni.
2. L'app LOB contoso legge le entità account principali dall'istanza degli Stati Uniti e intende inviare una chiamata API che fa riferimento a un'entità account replicata nell'istanza europa. Funziona perché tutto era in funzione e non si sono verificate interruzioni o errori temporanei. Il report dell'applicazione LINEB viene generato correttamente.

Esempio 2 - Percorso non riuscito in cui la sincronizzazione è inattiva o ritardata

Scaricare un file di Visio di questa architettura.

1. L'istanza degli Stati Uniti tenta di sincronizzare un nuovo account con l'istanza europa tramite un'app per la logica. L'istanza europea non è raggiungibile, a causa di tempi di inattività, manutenzione o un altro problema di comunicazione.
2. L'app LOB contoso legge le entità account principali dall'istanza degli Stati Uniti e intende inviare una chiamata API che fa riferimento a un'entità account che non è stata replicata nell'istanza di Europa. La chiamata API non riesce perché l'account con l'identificatore specificato non è stato creato nell'istanza europa e il report non viene generato.

Considerazioni

Prendere in considerazione l'impatto di qualsiasi logica di business su un'entità che non è ancora idratata. Si consideri uno scenario in cui l'entità non è ancora completamente idratata e sincronizzata. Alcune delle proprietà saranno Null, pertanto è necessario assicurarsi che le decisioni sui dati vengano prese in considerazione quando si usa questo approccio.

Passaggi successivi

• Power Platform
• Che cos'è Power Apps?
• Informazioni su App per la logica di Azure
• Introduzione a Power Automate

Risorse correlate

Architetture correlate:

• CI/CD per Microsoft Power Platform
• Intelligenza artificiale per i cittadini con Power Platform
• Distribuzione di Power Automate su larga scala

Linee guida per lo sviluppo Web:

• Dieci principi di progettazione per le applicazioni Azure
• Modelli di progettazione e implementazione
• procedure consigliate per la distribuzione di servizio app
• Microsoft Azure Well-Architected Framework