Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren
No-Code-Automatisierungen mit einem Geokodierungsschritt brauchen einen anderen Migrationsansatz als eigener Code. So gehen Sie bei diesem Wechsel vor.
Fehlercodes zwischen Anbietern vor dem Wechsel zuordnen
Erfolgsantworten bekommen bei einer Migration die meiste Aufmerksamkeit, da sie das sind, was eine Demo zeigt und was eine erste Testrunde üblicherweise prüft. Fehlerantworten bekommen weit weniger Aufmerksamkeit, und das ist genau verkehrt herum, denn Code zur Fehlerbehandlung ist oft das, was in der Produktion zuerst und am sichtbarsten bricht, wenn sich unter einer Anwendung der Anbieter ändert.
Jeder Anbieter von Geokodierungs- und Standortdaten hat eigene Konventionen, um Fehler zu signalisieren: Manche verwenden ausschließlich HTTP-Statuscodes, manche betten ein Statusfeld in eine JSON-Antwort mit Status 200 ein, manche unterscheiden mit verschiedenen Codes zwischen „keine Ergebnisse gefunden“ und „ungültige Anfrage“, und manche fassen beides zu einem allgemeinen Fehler zusammen. Die Wiederholungslogik einer Anwendung, die für Nutzer sichtbaren Fehlermeldungen und die Monitoring-Alarme sind typischerweise alle auf die Fehlerkonventionen eines bestimmten Anbieters ausgelegt, manchmal ohne dass jemand diese Abhängigkeit ausdrücklich dokumentiert hat.
Vor einem Anbieterwechsel lohnt es sich, eine ausdrückliche Zuordnungstabelle zwischen den Fehlerantworten des alten und des neuen Anbieters anzulegen, die mindestens Folgendes abdeckt:
- Keine Ergebnisse für eine gültige, aber nicht zugeordnete Anfrage, im Unterschied zu einer fehlerhaften oder ungültigen Anfrage
- Ratenlimit überschritten, und ob die Antwort Informationen darüber enthält, wann ein erneuter Versuch möglich ist
- Authentifizierungsfehler, einschließlich abgelaufener, fehlender oder fehlerhafter Zugangsdaten
- Serverseitige Fehler beim Anbieter, im Unterschied zu clientseitigen Anfragefehlern
- Alle anbieterspezifischen Statuswerte, die Ihr Code ausdrücklich nach Name oder Nummer prüft
My Geocode dokumentiert seine Fehlerantworten und Statuskonventionen unter /docs/errors/, und jede Antwort enthält außerdem Kontingent-Header, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit und X-Quota-Reset. Sie decken eine Informationskategorie ab, nämlich Kontingent- und Ratenstatus, die manche Anbieter in den Bodys von Fehlerantworten verstecken, statt sie direkt in Headern bereitzustellen. Zu prüfen, ob Ihre aktuelle Wiederholungslogik Kontingentinformationen aus dem Antwort-Body oder aus einem Header liest, ist ein guter konkreter Punkt für eine Migrations-Checkliste, da Kontingentinformationen in Headern im Allgemeinen leichter zu lesen sind, ohne den Parsing-Pfad für die eigentlichen Daten anzufassen.
Ein praktischer Weg, die Zuordnungstabelle zu erstellen, besteht darin, jede Fehlerbedingung in einer Testumgebung bewusst bei altem und neuem Anbieter auszulösen, statt sich allein auf die Dokumentation zu verlassen, denn Dokumentation und tatsächliches Verhalten stimmen bei keinem Anbieter immer exakt überein. Senden Sie eine fehlerhafte Anfrage, schöpfen Sie absichtlich ein kleines Testkontingent aus und senden Sie einen ungültigen Schlüssel, und halten Sie dann genau fest, was jeder Anbieter in jedem Fall zurückgibt.
Diese Art der Fehlerzuordnung taucht selten im Projektplan einer Migration auf, weil sie keine sichtbare Funktion hervorbringt, sie ist aber überproportional dafür verantwortlich, wie eine Migration im Nachhinein in Erinnerung bleibt. Eine Migration, die Erfolgsantworten sauber umstellt, aber die Fehlerbehandlung kaputt lässt, erzeugt in den ersten Wochen nach der Umstellung meist weit mehr Support-Tickets als eine, die den Erfolgspfad nur teilweise richtig hinbekommen hat.