Einrichtung der wöchentlichen Synchronisation
Warum wurde die Synchronisation überarbeitet?
Make begrenzt die maximale Laufzeit eines Szenarios auf 45 Minuten. Bei größeren Kunden- und Vertragsbeständen konnte der bisherige vollständige Synchronisationslauf deshalb vorzeitig beendet werden.
Die neue Version verteilt die Verarbeitung auf drei Szenarien: 1.0 Dispatcher → 1.0.5 Queue Runner → 1.1 Worker. Dadurch werden Kunden schrittweise verarbeitet und ein einzelner Lauf bleibt deutlich kürzer.
Aufgabe der drei Szenarien
| Szenario | Aufgabe |
|---|
| 1.0 Main Dispatcher | Liest die Sync-Konfiguration, lädt die vorgesehenen Kunden und übergibt jeden Kunden an den Queue Runner. |
| 1.0.5 Queue Runner | Empfängt die Kundendaten über einen Webhook und startet für jeden Kunden den Worker. |
| 1.1 Weekly Sync Worker | Verarbeitet den einzelnen Kunden, seine Verträge und die dazugehörigen Dokumente. |
1. Voraussetzungen und Importreihenfolge
Richten Sie die Bestandteile in folgender Reihenfolge ein:
- Data Store 1.0.1 Sync Config einschließlich Initialdatensatz
- alle benötigten Resolver- und Mapping-Szenarien
- 3.5.1 und 3.5.2 für Dokumente
- 3.0.1 und 3.0.2 für Verträge
- 1.1 SUB – Weekly Sync Worker V2
- 1.0.5 SUB – Weekly Sync Queue Runner
- zuletzt 1.0 Main – Weekly Full Sync Dispatcher V2
Wichtig:
Verwenden Sie in einem Ziel-Account ausschließlich Verbindungen, DataStores und Szenario-Referenzen dieses Ziel-Accounts. Die neutralen Blueprints enthalten Platzhalter, die nach dem Import zugeordnet werden müssen.
2. Szenario 1.1 – Weekly Sync Worker importieren
- Erstellen Sie in Make ein neues Szenario.
- Importieren Sie 1.1 SUB Weekly Sync Worker V2 NEUTRAL.blueprint.json.
- Vergeben Sie den Namen 1.1 SUB: Weekly Sync Worker V2.
- Öffnen Sie alle Professional-Works-Module und wählen Sie die Verbindung des Ziel-Accounts.
- Ordnen Sie den Data Store 1.0.1 Sync Config zu.
- Ordnen Sie alle aufgerufenen Resolver- und Vertrags-Szenarien zu. Dazu gehören insbesondere der Vertragstyp-Resolver sowie 3.0.1 und 3.0.2.
- Prüfen Sie die Eingabefelder des SUB-Szenarios, insbesondere
run_id und client_id. - Speichern Sie jedes Modul und anschließend das gesamte Szenario.
Kein eigener Scheduler:
Der Worker wird ausschließlich vom Queue Runner aufgerufen und erhält deshalb keinen regelmäßigen Zeitplan.
3. Szenario 1.0.5 – Queue Runner importieren
- Erstellen Sie ein weiteres Szenario.
- Importieren Sie 1.0.5 SUB Weekly Sync Queue Runner NEUTRAL.blueprint.json.
- Vergeben Sie den Namen 1.0.5 SUB: Weekly Sync Queue Runner.
- Öffnen Sie das Webhook-Modul und erstellen Sie einen neuen Webhook für den Ziel-Account.
- Öffnen Sie das Modul zum Aufruf eines SUB-Szenarios und wählen Sie 1.1 SUB: Weekly Sync Worker V2.
- Kontrollieren Sie die Übergabe von
run_id, client_id, first_name, last_name und birth_date. - Aktivieren Sie beim Worker-Aufruf das Warten auf das Ausführungsende, sofern dies im Blueprint vorgesehen ist.
- Speichern Sie das Szenario und kopieren Sie die erzeugte Webhook-URL.
Webhook-URL aufbewahren:
Die Webhook-URL des Queue Runners wird anschließend im HTTP-Modul des Hauptszenarios 1.0 eingetragen.
4. Szenario 1.0 – Main Dispatcher importieren
- Erstellen Sie ein neues Szenario.
- Importieren Sie 1.0 Main- Weekly Full Sync Dispatcher V2 NEUTRAL.blueprint.json.
- Vergeben Sie einen eindeutigen Szenarionamen.
- Wählen Sie im Modul 1.0.1 Sync Config lesen den Data Store des Ziel-Accounts aus.
- Öffnen Sie das Professional-Works-Modul und wählen Sie die Professional-Works-Verbindung des Ziel-Accounts.
- Prüfen Sie im Schreibmodul erneut den Data Store 1.0.1 Sync Config.
- Öffnen Sie das HTTP-Modul am Ende des Szenarios und tragen Sie dort die Webhook-URL aus 1.0.5 ein.
- Speichern Sie alle Module und anschließend das Szenario.
5. Kundenfilter sorgfältig einrichten
Achtung:
Ein im Blueprint enthaltener Personen- oder Testfilter darf nicht ungeprüft übernommen werden. Ein Filter wie beispielsweise „Wolfgang Guntermann“ führt dazu, dass alle anderen Kunden ausgeschlossen werden. Make kann den Lauf trotzdem als erfolgreich anzeigen, obwohl die Verarbeitungskette nicht bis zum Worker ausgeführt wurde.
Empfohlene Vorgehensweise:
- Für den ersten Test einen eindeutig bekannten Musterkunden filtern.
- Nach erfolgreichem Test den Filter auf das gewünschte Kriterium umstellen.
- Ohne Filter werden alle von Professional Works gelieferten Kunden verarbeitet.
- Bei großen Datenbeständen sollte der Rollout schrittweise erfolgen.
Prüfung in der Historie:
Ein grüner Lauf mit nur wenigen Operationen kann bedeuten, dass der Filter sämtliche Bundles ausgeschlossen hat. Kontrollieren Sie deshalb, ob das HTTP-Modul im Hauptszenario sowie Queue Runner und Worker tatsächlich ausgeführt wurden.
6. Gesamtkette testen
- Wählen Sie einen bekannten Testkunden mit mindestens einem Vertrag und einem Dokument.
- Setzen Sie den Kundenfilter zunächst ausschließlich auf diesen Testkunden.
- Starten Sie 1.0 manuell mit Run once.
- Prüfen Sie in 1.0, ob das HTTP-Modul den Kunden an 1.0.5 übergibt.
- Prüfen Sie anschließend den Lauf von 1.0.5 und den Aufruf von 1.1.
- Kontrollieren Sie im Worker die Aufrufe von 3.0.1 beziehungsweise 3.0.2 sowie 3.5.1 beziehungsweise 3.5.2.
- Prüfen Sie Kunde, Verträge und Dokumente in NETZWERKZEUG.
- Kontrollieren Sie den Status und die Zähler im Data Store 1.0.1 Sync Config.
7. Scheduler aktivieren
Aktivieren Sie den Scheduler erst, wenn die gesamte Kette erfolgreich getestet wurde. Nur das Hauptszenario 1.0 ist der regelmäßig zeitgesteuerte Einstiegspunkt. Queue Runner, Worker und fachliche SUB-Szenarien benötigen keinen eigenen regelmäßigen Scheduler.
Ergebnis:
Das Hauptszenario startet den Lauf und übergibt die Kunden einzeln an den Queue Runner. Dieser startet den Worker, der Verträge und Dokumente verarbeitet. Damit bleibt die Verarbeitung in handhabbaren Einzelschritten und reduziert das Risiko, das 45-Minuten-Zeitlimit von Make zu überschreiten.