My Geocode

Migration

Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren

· 3 Min. Lesezeit · My Geocode · #zapier#make#automation#no-code#geocoding#migration

In Zapier oder Make erstellte Automatisierungen enthalten oft einen Geokodierungsschritt, der in einem größeren Workflow steckt: Ein neuer Lead kommt über ein Formular herein, seine Adresse wird geokodiert, um die Gebietszuordnung zu prüfen, und das Ergebnis löst weiter hinten in der Kette eine Routing-Entscheidung aus. Solche Workflows werden häufig von Menschen ohne Hintergrund in der Softwareentwicklung gebaut, mit dem vorgefertigten App-Connector oder dem generischen HTTP-Modul, das die Plattform damals anbot, und das verändert, wie eine Migration im Vergleich zu einer eigenen Codebasis tatsächlich aussieht.

Wenn Ihr aktueller Geokodierungsschritt einen dedizierten App-Connector verwendet, also eine offizielle Integration, die Zapier oder Make speziell für den betreffenden Anbieter gebaut hat, bedeutet die Migration zu einem Anbieter ohne entsprechenden dedizierten Connector, dass Sie diesen Schritt auf ein generisches HTTP- oder Webhook-Modul umstellen, das so konfiguriert ist, dass es die API des neuen Anbieters direkt aufruft. Das ist eine echte Änderung am Aufbau der Automatisierung, nicht nur ein Austausch der Zugangsdaten, und es lohnt sich, den Ersatzschritt gründlich in einem isolierten Testszenario zu prüfen, bevor Sie eine laufende Produktivautomatisierung anfassen, von der andere Teile eines Unternehmens abhängen.

Konkrete Schritte für diesen Wechsel:

  1. Duplizieren Sie die bestehende Automatisierung im Editor der Plattform, statt sie direkt zu bearbeiten, damit die funktionierende Version weiterläuft, bis die Ersatzversion vollständig getestet ist
  2. Ersetzen Sie den Geokodierungsschritt durch ein generisches HTTP-Modul, konfiguriert mit dem Endpunkt und der Authentifizierung des neuen Anbieters, da sich ein Schlüssel als Query-Parameter oder ein Authorization: Bearer-Header (beides wird hier unterstützt) in einem generischen HTTP-Modul einfach einrichten lässt, ohne einen dedizierten Connector zu benötigen
  3. Ordnen Sie die Antwortfelder manuell zu, im Schritt zur Datenzuordnung der Automatisierung, da ein generisches HTTP-Modul rohe Antwortdaten liefert, die ausdrücklich den Feldern zugeordnet werden müssen, die spätere Schritte der Automatisierung erwarten, anders als ein dedizierter Connector, der diese Zuordnung oft automatisch vornimmt
  4. Testen Sie mit einer Reihe echter Eingaben, einschließlich Randfällen wie unvollständigen Adressen oder ungewöhnlicher Formatierung, denn genau diese Art von Test wird in einem No-Code-Tool leicht übersprungen, in dem der „Code“ selbst nicht so zur Prüfung sichtbar ist wie bei einem Skript
  5. Stellen Sie den Trigger von der Testversion auf die duplizierte, geprüfte Automatisierung um und deaktivieren Sie das Original erst, wenn Sie sich vergewissert haben, dass die neue Version eine kurze Zeit lang mit Live-Daten korrekt läuft

Da ein Kompatibilitätshost die exakte Antwortform eines bekannten Anbieters nachbildet, kann die Feldzuordnung in Schritt 3 oben der Zuordnung, die Ihr ursprünglicher Connector intern bereits verwendet hat, sehr ähnlich sein, falls der Geokodierungsschritt Ihrer ursprünglichen Automatisierung einen Anbieter aufgerufen hat, für den es hier einen passenden Kompatibilitätshost gibt. Das kann diese Migration deutlich verkürzen. Die vollständige Liste der Kompatibilitätshosts finden Sie unter /compatibility/; ein Blick darauf lohnt sich, bevor Sie davon ausgehen, dass eine Feldzuordnung von Grund auf nötig ist.

Bei einer geschäftskritischen Automatisierung ist die zusätzliche Vorsicht, in einem Duplikat zu testen statt live zu bearbeiten, den geringen zusätzlichen Einrichtungsaufwand wert, denn eine defekte Automatisierung für das Lead-Routing fällt meist schnell auf, und zwar Menschen außerhalb des technischen Teams.

Mehr zu Migration