La sincronizzazione bidirezionale richiede regole di scrittura
Se CRM ed ERP possono scrivere, ogni campo comune richiede una regola di conflitto. L’ultimo messaggio arrivato non è sempre l’ultima decisione aziendale.
Una connessione può trasferire dati in entrambe le direzioni. Ciò non significa che ogni campo debba essere sovrascritto liberamente da entrambi i lati. I campi comuni richiedono una regola che colleghi diritti di modifica, versione di partenza e gestione dei conflitti. Altrimenti un messaggio tecnicamente nuovo può riportare un valore aziendale superato.
Un arrivo tardivo può basarsi su dati vecchi
Un’azienda fittizia di software sincronizza CRM ed ERP. L’ERP conferma l’indirizzo di fatturazione, il CRM gestisce il contatto di progetto. Questa sequenza inventata mostra cosa potrebbe causare un aggiornamento globale del record:
Ora | Operazione | Versione dei dati |
|---|---|---|
| Il CRM legge il record cliente. |
|
| Il gruppo ERP conferma un nuovo indirizzo di fatturazione. |
|
| Il CRM rinvia un contatto di progetto modificato insieme al vecchio indirizzo. | Il messaggio contiene ancora |
Il messaggio arriva dopo, ma l’indirizzo proviene da una versione precedente. Se l’integrazione accettasse l’intero record senza controllo, la modifica confermata potrebbe perdersi. Qui v7 e v8 si riferiscono allo stesso record ERP; contatori locali indipendenti di sistemi diversi non sono direttamente confrontabili.
Riconoscere la versione di partenza e decidere il conflitto
Microsoft descrive la concorrenza ottimistica per Dataverse: un’applicazione può rilevare se il record sul server è cambiato tra lettura e scrittura. Il controllo disponibile e la sua attivazione dipendono dal prodotto e dall’interfaccia.
Rilevare una differenza non decide ancora quale indirizzo sia corretto per l’azienda. Nell’esempio il vecchio indirizzo deve attendere un chiarimento o essere trattato come riscrittura non consentita. Reinviare semplicemente il valore vecchio rifiutato con un nuovo identificativo di versione vanificherebbe quel controllo senza risolvere la differenza aziendale. Un singolo controllo di versione non rende inoltre atomici tutti i passaggi tra più sistemi.
Quando possono scrivere entrambi i lati
Se entrambi i gruppi devono davvero modificare le stesse informazioni, una soluzione bidirezionale può essere adatta. Campi consentiti, modifiche e decisioni sui conflitti devono allora essere espliciti. La documentazione dual-write di Microsoft mostra, per esempio, direzioni diverse per associazione di colonne; un’impostazione globale non è una necessità aziendale.
Può anche bastare trasferire campi diversi in direzioni diverse. Nell’esempio il nuovo contatto di progetto deve essere acquisito secondo la propria regola, senza riscrivere il vecchio indirizzo senza controllo. Entrambi i valori appartengono allo stesso cliente ma richiedono decisioni di scrittura differenti.
Fonti
Continuate a leggere
Tutti gli articoli
API & integrazione con ASES
ERP, CRM e negozio online collegati in modo pulito