Coerenza finale tra più istanze di Power Apps

Questo articolo descrive uno scenario in cui un ipotetico cliente basato sugli Stati Uniti, Contoso, ha recentemente acquisito un'altra società basata in Europa ed è in fase di elaborazione di sistemi CRM e ERP tra le due aziende. Nell'ambito 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 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.

Workflow

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 avviene prima dell'avvio di qualsiasi transazione di database. È l'opzione preferita, se il campo è obbligatorio. In alcuni scenari, tuttavia, sarà sufficiente un passaggio preCreate plugin.

1. L'istanza degli Stati Uniti tenta di sincronizzare un nuovo account con l'istanza di Europa tramite un'app per la logica. L'istanza europa non è raggiungibile, a causa di tempi di inattività o aggiornamento.
2. L'app LOB 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 PreCreate PreValidation/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.

Alternative

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 sono limitati a:

• 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 modo più specifico, 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 usano da entrambe le istanze non presentano problemi. Tuttavia, i meccanismi di sincronizzazione non sono mai una prova di errore, interruzioni o problemi imprevisti probabilmente si verificheranno. 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, è necessario sincronizzare gli account e i 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 line-of-business di Contoso proprietaria genera report sui ticket di problema creati dagli utenti. Per completare questa attività, l'app LOB 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.
• I sistemi di utilizzo non hanno logica per la creazione dell'entità da creare.

Quando usare questo approccio

Usare questo approccio negli scenari seguenti:

• Si vuole garantire che esista un record con una determinata chiave e non importa che il record non sia completamente idratato.
• È 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 basarsi su determinate proprietà disponibili.

Esempi

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à dell'account principale dall'istanza degli Stati Uniti e intende inviare una chiamata API che fa riferimento a un'entità account replicata nell'istanza di Europa. Funziona perché tutto era operativo 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 di Europa tramite un'app per la logica. L'istanza dell'Europa non è raggiungibile, a causa di tempi di inattività, manutenzione o un altro problema di comunicazione.
2. L'app LOB Contoso legge le entità dell'account principale 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 di 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, quindi è necessario assicurarsi che le decisioni sui dati vengano prese in considerazione quando si usa questo approccio.

Passaggi successivi

• Power Platform
• Cos'è Power Apps?
• Cosa sono le app per la logica di Azure?
• Operazioni preliminari di Power Automate

Risorse correlate

Architetture correlate:

• 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