Migration von Empfängern Magento -> Inxmail [INX-17]

[falco-knapp]

Aufgabe

Die aktuelle manuelle Synchronisation der Empfänger je Liste soll angepasst, korrigiert und optimiert werden. Hierbei sollen Seiteneffekte auf die Cronjobs und andere Funktionalität berücksichtigt werden.

Use Case

Als Marketer möchte ich die Verwaltung von Newsletter-Empfängern und Mailing-Kampagnen von Magento nach Inxmail migrieren, damit ich in Zukunft den Feature-Umfang von Inxmail ideal einsetzen kann.

Akzeptanzkriterien

• Der Text der entsprechenden Maske wurde wie folgt angepasst:
  1. "Migration der Newsletter-Empfänger an Inxmail"
  2. "Die Migration der Newsletter-Empfänger an Inxmail ist ein Prozess der je Store-View Konfiguration manuell einmal ausgeführt werden sollte. Dieser Prozess vereinigt sämtliche derzeit in Magento verwalteten Empfänger mit den Empfängern der entsprechenden Liste in Inxmail nach folgenden Regeln:
     • Wenn eine Email-Adresse eines Empfängers bereits in der Liste von Inxmail vorhanden ist, so wird der Anmeldestatus in Inxmail für diesen Empfänger nicht verändert. In diesem Fall wird in Magento der Status aus Inxmail übernommen (Anmeldestatus-Verantwortung liegt in Inxmail)
     • Ist ein in Magento angemeldeter Empfänger nicht in Inxmail vorhanden (aus unterschiedlichen Gründen), so wird er in Inxmail angemeldet (ohne Opt-In verfahren) (Anmeldestatus-Verantwortung liegt bei Magento).
     • Ein Empfänger der nach Existenzprüfung in Inxmail nicht den Status "angemeldet" hat wird nicht übertragen
  3. "Migration"
  4. "Migration jetzt durchführen"
  5. "Führt alle Empfänger aus Magento im Kontext des Store-Views mit der gegebenen Inxmail Liste zusammen"
• Die vordefinierte Anzahl der Empfänger die maximal in einem Abschnitt übertragen werden sollen (Batch-Size / Pass) ist auf 50 voreingestellt (Punkt 6 im Screenshot)
• Die Synchronisationslogik entspricht den Regeln die in Punkt 2 oben beschrieben sind
• Alle Empfänger der verwendeten Inxmail-Liste die nicht in Magento vorhanden sind sind unverändert in Inxmail vorhanden. Sie werden nicht als Empfänger in Magento angelegt.
• Ist ein Empfänger bereits in Inxmail vorhanden und angemeldet, so sollen keine Daten in Inxmail aus Magento übernommen werden. Hintergrund ist, dass zum Zeitpunkt der Migration nicht entschieden werden kann welche Daten aktueller sind, die aus Inxmail oder die aus Magento.
• Nach Ausführung der Migration soll ein Flag gesetzt werden das anzeigt, dass die Migration bereits durchgeführt wurde ("Erneute Ausführung verhindern"). Ist dieses Häkchen gesetzt, soll die Ausführung nicht erneut durchgeführt werden können (die Aktion ist deaktiviert). Es soll dann auch folgender Hinweistext dargestellt werden: "Bitte beachten Sie bei erneuter Ausführung der Migration, dass u.U. Empfänger angemeldet werden die Ihre Anmeldung noch nicht bestätigt haben bzw. aus Inxmail gelöscht wurden. Sie sollten diese Aktion nur einmalig je Liste ausführen. Danach werden Anmeldungen / Abmeldungen automatisch an Inxmail übertragen."
• Wenn der Benutzer das Häkchen entfernt kann er die Aktion erneut ausführen.
• Der BatchChannel wird korrekt verwendet:
  • Ein BatchChannel wird für die Migration nur einmal erzeugt
  • Der Befehl BatchChannel.executeBatch() wird pro pass nur 1x ausgeführt
  • Nach der Ausführung von executeBatch wird die Resultatsliste ausgelesen und Fehlerfälle entsprechend protokolliert

    Konsequenzen aus obigen Punkten

• Die Status-Übergänge bei der Migration kann über folgende Tabelle verdeutlicht werden:

Beschreibung	Magento Status (vor -> nach)	Inxmail Status (vor -> nach)
angemeldeter Empfänger wird erzeugt	angemeldet -> angemeldet	nicht vorhanden -> angemeldet
abgemeldeter Empfänger wird nicht erzeugt	abgemeldet -> abgemeldet	nicht vorhanden -> nicht vorhanden
keine Änderung	angemeldet -> angemeldet	angemeldet -> angemeldet
nur in Inxmail angemeldet	nicht vorhanden -> nicht vorhanden	angemeldet -> angemeldet
nur in Inxmail abgemeldet	nicht vorhanden -> nicht vorhanden	abgemeldet -> abgemeldet
Abmeldung in Magento	angemeldet -> abgemeldet	abgemeldet -> abgemeldet
Anmeldung in Magento	abgemeldet -> angemeldet	angemeldet -> angemeldet

• der Text muss angepasst werden
• die Batch-Size Größe muss angepasst werden
• die Batch-Channel Erzeugung muss außerhalb der Methoden subscribeCustomer gelegt werden
• die Batch-Channel Ausführung muss nach der Iteration für einen Pass / Batch-Size ausgeführt und ausgewertet werden, das heißt außerhalb der "subscribeCustomer" Methode ausgeführt werden.
• die Anpassungen des Batch-Channels muss bei allen aufrufenden Methoden berücksichtigt werden
• die Inxmail Liste darf vor der Migration nicht geleert werden

[falco-knapp]

Freigabe für Geschätzter Aufwand: 12 h.

[BrocksiNet]

Hallo Falco,

wir haben hier jetzt doch ein paar Rückfragen:

1. Soll bei Punkt 3 der Tabelle also bei "keine Änderung" irgendetwas passieren? Sollen zum Beispiel Kundendaten aktualisiert werden also wenn sich z.B. die Adresse geändert hat?
2. Was soll passieren in diesem Fall passieren: Kunde meldet sich bei Magento ab und der Status in Inxmail ist "angemeldet"? Dieser Fall fehlt wohl in der Tabelle oben. Er soll dann auch in Magento abgemeldet werden oder?

3. Zu diesem Punkt:

   Wenn eine Email-Adresse eines Empfängers bereits in der Liste von Inxmail vorhanden ist, so wird der Anmeldestatus in Inxmail für diesen Empfänger nicht verändert. In diesem Fall wird in Magento der Status aus Inxmail übernommen (Anmeldestatus-Verantwortung liegt in Inxmail)

Heißt das der Abonnent soll in Magento "angemeldet" oder "abgemeldet" sein je nach Status der in Inxmail vorhanden ist? Oder soll auf Magento Seite nichts passieren? Die Tabelle Status-Änderungen ist ggf. nicht ganz klar oder ganz vollständig?

Denke das wären erstmal unsere Rückfragen. Danke schon mal für dein Feedback!

[falco-knapp]

Hallo Björn,

zu 1. wie eben besprochen: Wenn der Empfänger bereits in Inxmail vorhanden ist, sollen die Mapping-Daten nicht übertragen werden, da zu diesem Zeitpunkt nicht entschieden werden kann welche Daten aktueller sind. Die in Magento oder die in Inxmail.

zu 2. Mir ist die Frage nicht ganz klar. Hier ein Interpretationsversuch: Die Funktionalität der Migration ist, dass die Empfänger-Liste von Magento mit Inxmail vereint wird. Dabei hat der Status in Inxmail erstmal Vorrang gegenüber dem Status von Magento. D.h. ein Empfänger, der in Magento abgemeldet ist, aber in Inxmail den Status "angemeldet" hat, wird in Magento angemeldet (letzte Zeile in der Tabelle). Entspricht Regel 1 in den Anforderungen.

Der Fall der in dieser Frage dargestellt wird ist durch die bestehende Logik schon abgedeckt und hat mit der Migration (manuelle Synchronisation) nichts zu tun. Wenn ein Benutzer sich in Magento Abmeldet, greift der Observer ein und meldet den Benutzer auch in Inxmail ab.

zu 3. Genau diese Fälle sind in den letzten 2 Zeilen der Tabelle abgebildet.

Heißt das der Abonnent soll in Magento "angemeldet" oder "abgemeldet" sein je nach Status der in Inxmail vorhanden ist?

Ja, genau so ist es gemeint.

Klärt das die Fragen? Ansonsten lass uns kurz telefonieren.

Danke und Gruß,

Falco

[BrocksiNet]

Hallo Falco,

wir haben noch zwei Rückfragen zu der Batch-Size:

Sollen wir die neue Batch-Size von 500 auch auf die anderen Synchronisationen anwenden (z.B. im Observer)?

Reicht es aus wenn die Batch-Size von 500 auf jeden pass angewendet wird anstatt auf den kompletten Prozess? Es geht um diese Definition hier:

Ein BatchChannel wird für die Migration nur einmal erzeugt Der Befehl BatchChannel.executeBatch() wird pro pass nur 1x ausgeführt

Wir würden als pro pass maximal 500 user senden aber mehrere pass senden bis alle synchronisiert sind. Die Umsetzung mit nur einem pass / request wäre wesentlich aufwendiger.

Grüße Björn

[falco-knapp]

Zu Frage 1: Meines Erachtens gibt es nur noch ein Cronjob bei dem eine "echte" Batch-Übertragung stattfindet (also viele Daten) und das ist der Gruppen-Cronjob. Hier würde ich aber erstmal keine weiteren Änderungen herbeiführen, es sei denn dass dies weniger Aufwand verursacht als wenn man diese Änderung "verhindern" würde.

Zu 2. Die grundlegende Funktionalität braucht nicht geändert zu werden. Die Aufgabe ist also nicht die Passes/Requests zu verhindern, sondern lediglich die Anzahl der übertragenen Einträge je pass zu erhöhen. Im alten Code wird ja "executeBatch" mit jedem Empfänger durchgeführt was den Vorteil des Batch-Channels nahezu vollkommen zunichte macht.

[falco-knapp]

Lasttest bei Gast-Kunden: Verschlechterung um 20 % im Vergleich zu 3.1.0.6. Bei 200k Empfängern dauert der Import 3h gegenüber 2h 23m bei 3.1.0.6.

Das verwundert mich dann doch etwas. Ich hätte erwartet, dass durch die korrekte Nutzung des Batch-Channels der Import beschleunigt werden kann - zumindest aber nicht schlechter wird - da ja auch die Funktionalität komplexer geworden ist.

[falco-knapp]

@bjoern-flagbit Funktionalität ist soweit korrekt, aber könnt Ihr bitte dennoch evaluieren ob am Code im Hinblick auf die Laufzeit etwas optimiert werden könnte?

[BrocksiNet]

Hallo Falco,

wir haben hier noch eine weitere Optimierung vorgenommen. Änderungen sind im Branch INX-25 bzw. in diesem Commit zu finden: https://github.com/Inxmail/inx_magento1/commit/e8b3304b21d3ac285e5b499eabe608bc995510e9

Kannst du den Performance-Test mit dem geänderten Code nochmals ausführen?

Grüße Björn

[falco-knapp]

Hi Björn,

das hat wohl etwas genutzt.

3.1.0.6 Durschnittliche Ladezeit für 50k Einträge: 29 s

3.2.0.0 Durschnittliche Ladezeit für 50k Einträge: 19 s

Die Differenz zwischen 3.1.0.6 und 3.2.0.0 bleibt nahezu bei 10s. Je mehr Einträge übertragen werden wird die Differenz aber scheinbar auch leicht größer:

Sieht an sich gut aus (abgesehen davon, dass es linear in beiden Fällen wächst, aber das lässt sich wohl ohne weiteres nicht vermeiden :()

Könnt Ihr ein neues Release bitte entsprechend vorbereiten?

Vielen Dank und Gruß,

Falco