Condividi tramite

Eseguire la logica di business durante la sincronizzazione di tipo merge

Il framework del gestore della logica aziendale consente di scrivere un assembly di codice gestito che viene invocato durante il processo di sincronizzazione basato su merge. L'assembly include la logica di business che può rispondere a diverse condizioni durante la sincronizzazione: modifiche dei dati, conflitti ed errori. Il framework del gestore della logica di business fornisce un modello di programmazione semplice e i dati forniti dal processo di merge all'assembly sono sotto forma di un set di dati ADO.NET, in modo da poter sfruttare le conoscenze di ADO.NET anziché apprendere un'interfaccia proprietaria. Per altre informazioni sulla programmazione dei gestori della logica di business, vedere:

Utilizzi per la gestione della logica aziendale

Il processo di sincronizzazione di tipo merge può richiamare i gestori della logica di business per eseguire:

  • Gestione delle modifiche personalizzata

  • Risoluzione dei conflitti personalizzata

  • Risoluzione degli errori personalizzata

Annotazioni

Il gestore della logica aziendale specificato viene eseguito per ogni riga sincronizzata. La complessità della logica e le chiamate ad altre applicazioni o servizi di rete possono ridurre le prestazioni.

Gestione delle modifiche personalizzate

Il gestore della logica di business può essere richiamato durante l'elaborazione delle modifiche ai dati non in conflitto e può eseguire una delle tre azioni seguenti:

  • Rifiuta i dati

    Ciò è utile per le applicazioni che non desiderano che le modifiche vengano propagate a o da un determinato Sottoscrittore. Ad esempio, un amministratore potrebbe escludere gli inserimenti che non appartengono alla partizione del Sottoscrittore o eventualmente rifiutare le eliminazioni eseguite in un Sottoscrittore. Come un altro esempio, un'applicazione potrebbe rifiutare un ordine immesso in un Sottoscrittore perché l'inventario non è più disponibile.

  • Accetta i dati

    Ciò è utile per le applicazioni in cui è necessario esaminare le modifiche apportate ai dati nel server di pubblicazione o nel sottoscrittore prima di consentirne la propagazione. Ad esempio, un'applicazione di livello intermedio potrebbe esaminare i nuovi ordini provenienti dal campo e integrarsi con un processo del flusso di lavoro di approvvigionamento nel livello intermedio.

  • Applicare dati personalizzati

    Ciò è utile per le applicazioni che devono eseguire l'override di valori o operazioni di dati specifici. Ad esempio, un'applicazione potrebbe trasformare un'eliminazione di riga in un aggiornamento speciale che imposta una colonna di stato nella riga su un valore "eliminato" e quindi tiene traccia dell'identità del client che esegue l'eliminazione. Può essere utile per scopi di controllo o flusso di lavoro.

Risoluzione dei conflitti personalizzata

La replica di tipo merge fornisce il rilevamento e la risoluzione dei conflitti, consentendo di accettare una strategia di risoluzione predefinita o di scegliere la risoluzione personalizzata per i conflitti. Per altre informazioni, vedere Rilevamento e risoluzione avanzati dei conflitti nella replica di tipo merge. Il gestore della logica di business può essere richiamato durante l'elaborazione delle modifiche ai dati in conflitto e può eseguire una delle due azioni seguenti:

  • Accettare la risoluzione predefinita

    Ciò è utile per le applicazioni che potrebbero dover esaminare il conflitto, eseguire azioni aggiuntive ed eventualmente registrare un messaggio di log dei conflitti personalizzato.

  • Eseguire la risoluzione personalizzata

    Ciò è utile per le applicazioni che potrebbero dover selezionare valori di dati specifici per la logica di business e fornire il processo di sincronizzazione con questo set di dati personalizzato. Ad esempio, un'applicazione potrebbe fornire una nuova versione della riga vincente combinando i valori dei set di dati del server di pubblicazione e del Sottoscrittore.

Risoluzione degli errori personalizzata

È possibile richiamare la logica personalizzata durante la propagazione delle modifiche che generano errori. La logica può eseguire una delle due azioni seguenti:

  • Accettare la risoluzione degli errori predefinita

    Ciò è utile per le applicazioni che potrebbero dover esaminare l'errore ed eseguire azioni aggiuntive ed eventualmente registrare un messaggio di log degli errori personalizzato.

  • Accettare la risoluzione degli errori personalizzata

    Ciò è utile per le applicazioni che potrebbero dover selezionare valori di dati specifici per la logica di business e fornire il processo di sincronizzazione con questo set di dati personalizzato. Ad esempio, se il processo di replica rileva una violazione della chiave duplicata, il gestore della logica di business potrebbe fornire una nuova versione della modifica dei dati in cui la chiave non sarà più in conflitto. Le modifiche apportate nel server di pubblicazione e nel Sottoscrittore possono quindi essere mantenute nel database e il processo di replica non deve compensare l'inserimento non riuscito con un'eliminazione.

Scenari di distribuzione per i gestori della logica aziendale

I gestori della logica di business possono essere distribuiti in:

  • Server di distribuzione. Usare una sottoscrizione push in modo che la logica di business venga eseguita nel server di distribuzione.

  • Sottoscrittore. Usare una sottoscrizione pull in modo che la logica aziendale venga eseguita nel Sottoscrittore.

  • Un server Internet Information Services (IIS) se viene utilizzata la sincronizzazione Web. Usare una sottoscrizione pull sincronizzata con la sincronizzazione Web e il gestore della logica di business verrà eseguito nel server IIS.

Vedere anche

Replicazione di tipo merge
Sottoscrivere pubblicazioni
Sincronizzare i dati
Sincronizzazione Web per la replica di tipo merge

  • Last updated on