Eine Schwierigkeit bei dieser Synchronsation besteht darin, dass in beiden Systemen Änderungen erfolgen können:
Im OpenEMM können Kunden sich von verschiedenen Mailinglisten an- und abmelden; im vtiger System werden diese Merkmale ebenfalls gepflegt. Zudem ist es (DSGVO lässt grüßen) im vtiger auch notwendig, eine komplette Kommunikationssperre durchzuführen.
In jedem Fall ist es zu vermeiden, dass Kunden, die keine Newsletter wünschen, weiterhin Mails bekommen.
Lösungsansatz
Wir synchronisieren die Datenbestände in beide Richtungen. Ziel ist es, dass beide Systeme synchron sind - wobei das OpenEMM Newslettersystem erst kurz dem Versand eines Newsletters mit dem vtiger synchronisiert werden muss.
vtiger -> OpenEMM Synchronisation
Wir synchronisieren die Kundendaten einmal täglich. Eine differentielle Synchronisation kommt nicht in Frage, da auch im vtiger gelöschte Kundendatensätze im OpenEMM gelöscht werden müssen. Wir übertragen also die kompletten Daten; das sind gezippt etwa 3 MB. Diese Daten werden dann mit der OpenEMM Datenbank komplett abgeglichen.
Da das vtiger System im Intranet und das OpenEMM im Internet steht, müssen die Daten vom vtiger zum OpenEMM gepusht werden. Hierzu wurde ein geschützter https Port bereitgestellt, der die Daten entgegennimmt und anschließend verarbeitet. Die Verarbeitung erfolgt in Python; es wird direkt mit der Datenbank abgeglichen. Für den komfortablen Zugriff auf die Tabellen und Felder wurde die OpenEMM Datenbank mit Django reverse engineered; somit stehen die Entitäten als ordentliche Django Models zur verfügung.
Die Verarbeitung erfolgt hierbei leichtgewichtig mittels uWSGI-Spooling.
OpenEMM -> vtiger Synchronisation
Im OpenEMM finden die An- und Abmeldungen der Nutzer statt - diese Daten müssen zurück in das vtiger synchronisiert werden. Auch hier werden die Daten vom OpenEMM Server abgeholt und direkt in die vtiger Datenbank geschrieben, die per Django Models reverse engineered wurde. OpenEMM verwaltet dabei einen eigenen Last-Modified Zeitstempel, der vom vtiger bei der Abfrage mitgegeben wird: wir holen uns differentiell nur die geänderten Daten. Die Synchronisation erfolgt minütlich; der sukzessiv inkrementierte Zeitstempel wird zudem über eine URL bereitgestellt. Unsere Überwachungs-Infrastruktur prüft über diese URL ab, ob sich dieser Zeittempel kontinuierlich ändert - falls nicht, klemmt die Synchronisation und ein Alarm wird ausgelöst.
Fazit
Die Synchronisation mit vtiger hat seine Tücken - speziell dann, wenn Datenänderungen in mehreren Systemen gleichzeitig stattfinden können. Im Falle der OpenEMM Synchronisation können wir die Tatsache nutzen, dass Newsletter nicht permanent versendet werden - dadurch muss in Richtung OpenEMM nur täglich synchronisiert werden. Das wiederum verschafft uns die Möglichkeit, komplett zu synchronisieren, um auch fehlende / gelöschte / genullte Datensätze korrekt behandeln zu können.
