Synchronisationsprozesse sind komplex. Zwei oder mehr Systeme müssen jeweils konsistent gehalten werden, wobei Änderungen in jedem System zu jeder Zeit auftreten können. Und wo Teilsysteme auch mal ausfallen können.
In Fall des von uns betreuten Unternehmens sind es zwei Systeme: ein vTiger CRM System für den Innendienst, sowie ein TYPO3 CMS als Kundenportal. Die Kunden können sich im TYPO3 System einloggen und dort ihre Daten ändern; der Innendienst kann ebenfalls Kundendaten ändern - im CRM. (Die Kunden können im TYPO3 System natürlich noch viel mehr, aber das tut hier nichts zur Sache).
Bisherige manuelle Synchronisation
Das bislang praktizierte Verfahren war ein manueller Abgleich der Daten:
- Ändert der Kunde die Daten im TYPO3, so werden diese in eine "Customer Changes" Liste in der Datenbank geschrieben
- Mitarbeiter arbeiten diese Änderungen manuell in das vTiger System ein
- Einmal täglich wird der Kundenstamm des vTigers in das TYPO3 kopiert. Um Datenverluste zu vermeiden werden dabei diejenigen Kundendatensätze ausgelassen, für die noch nicht verarbeitete Customer Changes vorliegen
Das Verfahren ist zweckmäßig, wenn nur wenige Datenänderungen im TYPO3 anfallen, und wenn diese auch zeitnah bearbeitet werden. Mit ansteigendem Datenvolumen ist dieses Verfahren nun nicht mehr praktikabel, weshalb wir eine automatische Synchronisation anstreben.
Paradigmen für eine automatische Synchronisation
Das Problem der automatischen Synchronisation besteht darin, dass zeitgleich Änderungen am selben Datensatz in beiden System erfolgen können. "Zeitgleich" ist dabei etwas weiter zu fassen: der Zeitpunkt der Datenänderung in einem Websystem ist die Zeitspanne vom Öffnen des Webformulars bis zum Klick auf den Speichern-Button. Im schlimmsten Fall überschneiden sich zwei Änderungssessions - der Sachbearbeiter bearbeitet zur selben Zeit Daten, während der Kunde Daten im TYPO3 eingibt.
Ganz so unwahrscheinlich wie es sich anhört ist es nicht - wenn der Kunde bei der Eingabe der Daten Fragen hat, ist es nicht ausgeschlossen dass er zum Telefon greift und seinen Sachbearbeiter anruft, der dann im vTiger CRM an den selben Daten arbeitet.
Wie geht man damit um? Wir haben drei Paradigmen identifiziert, die für das Konzept der Synchronisation relevant sind:
Der Kunde hat immer Recht
Bei parallel Nutzersessions in CRM und vTiger braucht man Vorfahrtsregeln. Unsere lautet: Der Kunde hat immer Recht. Wenn der Kunde seine Daten eingibt, so erteilt er damit auch die Freigabe für diese Daten. Diese Daten sind verbindlich und haben Vorfahrt.
Alles oder nichts
Bei Änderungen des Kunden im TYPO3 übertragen wir den kompletten Datensatz des Kunden an das vTiger - selbst wenn sich nur ein Feld geändert hat. Denn der Kunde gibt uns mit dem geänderten Datum auch implizit die Erklärung, dass alle Daten in dieser Form korrekt sind. Hierdurch entfällt die möglicherweise aufwändige Bestimmung der tatsächlich vom Kunden geänderten Felder. Alles oder nichts - wir brauchen keine partielle Synchronisation.
Synchronisation on Demand
Das TYPO3 benötigt in unserem Fall die Kundendaten nur, wenn der Kunde sich einloggt. Anstelle einer täglichen Synchronisation aller Daten synchronisieren wir nur die Kundendaten wenn sich ein Nutzer einloggt - und wir synchronisieren dann nur die Daten dieses Kunden. Der Kunde hat somit beim Login immer die frischsten Daten zur Verfügung: Synchronisation on Demand (Wenn der Kunde das Änderungsformular aufruft, synchronisieren wir zur Sicherheit erneut).
Verhalten bei Systemausfällen
Problematisch bei Synchronisationsvorgängen ist die Behandlung von Systemausfällen: Wenn die Gegenseite ausfällt, sind die Systeme bei Änderungsvorgängen nicht mehr synchron.
TYPO3 nicht verfügbar
Dieser Fall ist unkritisch, da dann der Nutzer sich dann auch nicht im TYPO3 einloggen kann. Wenn der Nutzer sich wieder einloggt, werden die Daten vom CRM on Demand aktualisiert. Voilá!
CRM nicht verfügbar
Wenn das CRM beim Login des Kunden nicht verfügbar ist, kann das TYPO3 die Daten nicht vom CRM holen. Das TYPO3 nutzt in diesem Fall die aktuell gespeicherten Daten.
Wenn das CRM nicht verfügbar ist während der Kunde die Daten ändert, so werden diese Daten in eine Customer Changes Liste geschrieben (konzeptionell ist dies ähnlich zum Status Quo).
- Beim Login im TYPO3 schauen wir nach, ob Customer Changes für diesen Kunden in der Liste vorliegen. Ist dies der Fall, werden die lokalen Daten des TYPO3 genommen (um Datenverluste zu vermeiden): Erst müssen die Daten ins CRM, bevor diese wieder vom CRM geholt werden können.
- Damit diese Daten nicht uralt sind (das passiert, wenn der Nutzer sich erst nach sehr langer Zeit wieder anmeldet und in der Zwischenzeit Änderungen im CRM vorgenommen wurden), synchronisieren wir einmal täglich den CRM Stand in das TYPO3. Hierbei lassen wir diejenigen Datensätze aus, für die noch Customer Changes vorliegen (auch das ist konzeptionell ähnlich zum Status Quo).
- Ein Systemdienst überwacht permanent die Customer Changes Listen und synchronisiert die Daten, sobald das CRM verfügbar ist.
Mit diesen Logiken haben wir eine ereignisgesteuerte Synchronisation geschaffen, welche partielle Ausfälle des CRM toleriert.
Technische Basis
Die Speicherung der Customer Changes erfolgt in einem CosmoCode Tool - dem EMS (Event Management System). Diese Technologie ist eine Middlewareanwendung, in welcher nutzergetriebene Ereignisse des TYPO3 in einer Mongo Datenbank gespeichert werden. Für die Ereignisse können dann spezifische Aktionen definiert werden, die ein "Action Runner" automatisch abarbeitet. (Actions sind in unserem Fall die Synchronisationsfunktionen, welche die Daten in das vTiger schreiben).
Die EMS Technologie ist seit vielen Jahren in TYPO3 Projekten im Einsatz und bietet uns
- Ereignisgesteuerte Abarbeitung
- Fehlertolerantes Verhalten
- Dokumentation von Nutzervorgängen.
