Domanda

Devo sviluppare un sistema CRM che consentirà agli utenti di avere una copia locale del DB che può quindi essere sincronizzata con il sistema server principale. L'idea è che un team di vendita può recarsi in aree non abilitate per Internet e continuare a operare con informazioni relativamente aggiornate e quindi sincronizzarsi quando torna in ufficio.

Non ho mai fatto una cosa del genere prima d'ora, qualcuno può consigliare una soluzione di sincronizzazione?

È stato utile?

Soluzione

Avendo scritto anch'io un tale sistema, consiglierei di evitarlo, se possibile. I modi in cui gli utenti possono rovinare un tale sistema sono la legione, in particolare quando gli utenti sono il team di vendita. Un sistema CRM chiamato Act! (probabilmente hai familiarità) ha offerto una simile opzione di sincronizzazione in passato, e forse lo fanno ancora. Ogni volta che la mia azienda vende a una società che utilizza il sistema di sincronizzazione di Act !, la compagnia si lamenta sempre di database corrotti e mal sincronizzati.

Se hai davvero bisogno di fare una cosa del genere, allora consiglierei la replica a livello di database (che non era disponibile al momento in cui abbiamo scritto la nostra applicazione di sincronizzazione). Molti database offrono replica, incluso MS-SQL Server. Puoi eliminare molti dei problemi che abbiamo riscontrato monitorando le modifiche a livello di database e rendendo il database responsabile del trasporto di tali modifiche in un database remoto.

Altri suggerimenti

Perché reinventare la ruota? Sono disponibili molte buone applicazioni CRM che offrono questa funzionalità. Alcuni sono anche open-source, quindi puoi estenderli. Ma se hai solo bisogno di un database client con funzionalità offline e sincronizzazione, molte applicazioni CRM lo offrono. Solo per il database client Highrise sarebbe perfetto, ma penso che non ci siano funzionalità offline / di sincronizzazione. Forse guarda SugarCRM , 24SevenOffice o Salesforce ?

E la creazione di un'applicazione di sincronizzazione è difficile poiché ci sono un sacco di problemi da risolvere con l'unione dei dati. Se hai ancora bisogno di farlo, dai un'occhiata a SyncML che è uno standard aperto per la sincronizzazione . Alcuni strumenti pronti per l'installazione sono disponibili da Funambol .

Potresti dare un'occhiata al Microsoft Synch Framework . Non l'ho ancora usato, quindi non posso dare un parere personale al riguardo.

MS CRM 4.0 ha funzionalità offline se abbinato a Outlook:

http://www.microsoft.com/dynamics/crm/product /overview.mspx

Andare offline ha una propria serie di stranezze (assicurati di andare offline prima di lasciare la tua buona connessione di rete), ma nel complesso funziona bene qui. Tuttavia, le cose del client mobile non sono ancora disponibili.

Prima di tutto - se il CRM sarà un prodotto che vendi, lo costruirà sicuramente - se è per uso interno direi che lascia che altri resistano al dolore di risolvere queste domande e comprino semplicemente un CRM.

A parte la replica a livello di database, che non credo sia sufficiente per risolvere tutto, dovrai davvero "creare il tuo".

Sono entrato in un team pianificando alcuni componenti simili a un CRM di un sistema e inizialmente avevano pianificato di utilizzare la replica del database perché sembrava facile, fino a quando non si raggiungeva la risoluzione dei conflitti.

Alla fine siamo passati all'utilizzo dei GUID come identificatori univoci perché ha reso molto più semplice la gestione dei nuovi record creati dagli utenti, altrimenti si finisce con questi schemi di partizionamento ID numerici per ciascun sistema client. Road to Hell.

Nulla aiuta con la risoluzione dei conflitti in cui vengono apportate modifiche tra le sincronizzazioni, è una preoccupazione a livello di applicazione. Il database potrebbe ottenere un elenco di transazioni da riprodurre da Bob, ma se modificasse le stesse cose di Alice - quale versione dovrebbe usare? i timestamp non sono sufficienti perché cosa succede se Alice riempie il suo mentre va e ha un timestamp in anticipo, ma Bob aspetta fino a quando pranza e ottiene un timestamp successivo.

Suggerirei davvero di leggere tutti gli articoli / post di blog che puoi sulla sincronizzazione e sulla risoluzione dei conflitti - la sincronizzazione è semplice da un'altezza di 10.000 piedi in cui puoi essere tutti ondulati a mano, ma è una storia diversa quando sei giù nel fango.

Ecco la mia strategia quando ho lanciato la mia soluzione di sincronizzazione in passato.

  1. Limitazione del numero di operazioni di modifica che possono verificarsi quando il sistema è offline.
  2. Evita di utilizzare il numero intero di incremento automatico come chiave primaria in quanto ciò causerebbe un brutto problema. In passato, ho assegnato a ogni client disconnesso un ID univoco e lo utilizzo insieme al numero generato automaticamente per formare una chiave primaria piacevole e leggibile (come XXX-YYYYYYYY). Questo è facile da fare perché la creazione di un numero sequenziale è banale in un ambiente non simultaneo.
  3. Conserva un registro delle transazioni, ad esempio ogni operazione DML eseguita durante la modalità offline può essere "riprodotta". al server. È possibile ottimizzare questo registro in un secondo momento quando le esigenze di sincronizzazione di base sono state soddisfatte.
  4. Devi prendere una decisione su come preparare l'applicazione client prima che vadano offline. Una soluzione tipica è costringere l'utente a premere un pulsante per attivare l'applicazione per accedere alla modalità offline. Ho trovato questa soluzione abbastanza problematica, specialmente quando l'utente è negligente e dimentico. Un rapido schiaffo in testa dai loro manager di solito è sufficiente nelle prime fasi, ma puoi scegliere di implementare una soluzione intelligente più intelligente in seguito.
  5. Crea prima la mia soluzione dall'operazione più semplice, quindi passa a uno scenario più complesso. (Operazione a record singolo a tabella singola, operazioni a record multipli a più tabelle, serie di operazioni che devono fungere da transazione)
  6. Crea uno scenario di risoluzione dei conflitti. Assicurati che lo scenario sia approvato dai tuoi utenti.

Inutile dire che è un viaggio doloroso. Se puoi esternalizzare il dolore a un'altra parte (come l'acquisto di soluzioni CRM disponibili), questo sarà il migliore.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top