Die API-Version, die in 90 Tagen abgeschaltet wird, und niemand hat die Mail gelesen
Anbieter kündigen alte API-Versionen mit Monaten Vorlauf an, meist per Mail an ein Postfach, das niemand mehr abruft. Warum funktionierende Automatisierungen ohne Ihr Zutun ausfallen und wie Sie den Termin vor dem Kunden erfahren.
Am ersten Oktober hörte der Versand auf
Ein Großhändler rief uns an einem Dienstagvormittag an. Seit sieben Uhr wurden keine Versandlabels mehr erzeugt. Die Bestellungen kamen weiter im Shop an, der Workflow startete pünktlich, holte sie ab und scheiterte dann bei jedem einzelnen Aufruf an den Versanddienstleister. Im Protokoll stand eine Zahl, die im Alltag selten auftaucht: 410. Die Ressource ist weg, und zwar dauerhaft.
Im Haus hatte niemand etwas geändert. Der Workflow lief seit vierzehn Monaten unverändert, zuletzt angefasst hatte ihn ein externer Dienstleister, der längst raus war. Die Erklärung lag in einem Postfach, das seit anderthalb Jahren niemand mehr geöffnet hatte. Der Versanddienstleister hatte die alte API-Version neun Monate vorher abgekündigt, dreimal daran erinnert und am ersten Oktober abgeschaltet. Alle vier Mails gingen an die Adresse, mit der damals das technische Konto angelegt worden war.
Ihre Automatisierung altert, auch wenn Sie nichts anfassen
Der teuerste Irrtum im Betrieb von Automatisierungen ist die Annahme, ein Workflow sei fertig, sobald er läuft. Tatsächlich ist er eine Abmachung zwischen Systemen, die anderen Firmen gehören. Diese Firmen entwickeln ihre Schnittstellen weiter, räumen alte Versionen ab und halten sich dabei an ihren eigenen Zeitplan.
Wie eng dieser Zeitplan ist, unterscheidet sich stark. Manche Anbieter datieren ihre API-Versionen, veröffentlichen viermal im Jahr eine neue und sichern jeder Version zwölf Monate Laufzeit zu. Andere kündigen an, wenn es in ihre Roadmap passt, mit ein paar Monaten Vorlauf. Bei Carriern hängt der Termin gelegentlich an einem regulatorischen Datum, das der Anbieter selbst nicht verschieben kann. Für Sie heißt das: Jede Automatisierung, die eine fremde API verwendet, hat ein Verfallsdatum. Sie kennen es nur nicht.
Bei unseren Kunden im Großhandel und in der Logistik hängt ein einzelner Bestellprozess schnell an fünf bis acht externen Schnittstellen. Shop, ERP, Carrier, Zollportal, Buchhaltung, Mailversand, dazu ein bis zwei Datendienste. Wenn jede davon alle zwölf Monate eine Version abräumt, liegt statistisch alle sechs bis acht Wochen irgendwo eine Abkündigung im Postfach.
Warum die Ankündigung nie bei den Richtigen landet
Anbieter kündigen ihre Abschaltungen fast immer sauber an. Sie schreiben Mails, führen ein Changelog, setzen bei manchen Diensten sogar `Deprecation`- und `Sunset`-Header in jede Antwort. Woran es scheitert, ist der Empfänger.
Das technische Konto beim Carrier läuft auf eine Sammeladresse oder auf den Kollegen, der die Verbindung vor zwei Jahren eingerichtet hat und heute in einer anderen Abteilung sitzt. Kommt die Mail dann doch bei einem Menschen an, liest sie jemand aus dem Vertrieb, für den "Version 2 der Shipment API wird zum 01.10. eingestellt" keine Handlung auslöst. Der Satz beschreibt nichts, was diese Person tun könnte, und wandert in den Papierkorb.
Dazu kommt das fehlende Inventar. Selbst wenn die richtige Person die Mail liest, kann sie die Frage nicht beantworten, die als Nächstes käme: Welche unserer Automatisierungen verwendet diese Version überhaupt? In den meisten Firmen, die uns rufen, existiert diese Liste nicht. Also passiert nichts, und das ist nachvollziehbar, denn niemand handelt auf Verdacht.
Die stille Variante ist die schlimmere
Ein 410 ist unangenehm, aber ehrlich. Der Workflow steht, jemand merkt es, spätestens der Kunde. Gefährlicher sind die Änderungen, die keinen Fehler auslösen.
Verschwindet ein Feld aus der Antwort, schreibt Ihr Workflow ab sofort leere Lieferzeiten ins ERP. Bekommt ein Statuswert eine neue Ausprägung, die Ihre Verzweigung nicht kennt, fallen alle Sendungen mit diesem Status in den Else-Zweig. Sinkt der Standardwert für die Seitengröße von hundert auf fünfzig, sieht Ihre Automatisierung die Hälfte des Tagesgeschäfts schlicht nicht mehr. Der Aufruf gibt weiterhin brav 200 zurück, das Protokoll bleibt grün, und der Schaden wächst still, bis am Monatsende die Zahlen nicht stimmen.
Diese Fälle finden Sie über keinen Fehleralarm. Sie finden sie, wenn Sie die Änderungshinweise Ihrer Anbieter lesen, bevor die Änderung wirksam wird.
"Wir reparieren das, wenn es bricht"
Der Einwand kommt in fast jedem Gespräch, und er ist nicht dumm. Warum Aufwand in eine Liste stecken, wenn der Ausfall ohnehin auffällt und die Umstellung einen halben Tag dauert?
Die Rechnung geht auf, solange der Ausfall billig ist. Beim Großhändler standen an diesem Dienstag vierhundert Sendungen. Bis der Zugang zur neuen Version eingerichtet, die Felder gemappt und der Workflow getestet war, vergingen zwei Tage. In dieser Zeit haben zwei Mitarbeiter die Labels von Hand im Portal des Carriers erzeugt und die Sendungsnummern per Copy und Paste ins ERP zurückgeschrieben, mit den Fehlern, die dabei entstehen. Die reine Umstellung hätte im September drei Stunden gekostet, auf einem leeren Schreibtisch. Der Aufwand für die Migration war in beiden Fällen derselbe. Bezahlt wurde der Rest: zwei Tage Handarbeit, verspätete Lieferungen, Reklamationen.
Dazu kommt ein Effekt, den wir regelmäßig sehen. Unter Druck wird schlecht migriert. Wer am Ausfalltag umstellt, nimmt das erstbeste Mapping, überspringt den Test und baut sich dabei den nächsten stillen Fehler ein.
Was wir bei jedem Betriebsübergang festlegen
Der Aufwand, um dieses Problem loszuwerden, ist überschaubar. Er besteht aus einer Liste, zwei Postfächern und einem Kalendereintrag.
Das Inventar ist eine Tabelle mit einer Zeile pro Verbindung: welcher Workflow, welches System, welcher Endpunkt, welche Version, welches Konto, welche Zugangsdaten, welches bekannte Abschaltdatum. Sie zu bauen dauert bei einem mittleren Stack einen halben Tag und beantwortet danach in zwei Minuten, was ohne sie eine Woche Sucherei ist.
Die Versionen selbst stehen an drei Stellen. In den URLs Ihrer HTTP-Schritte, meist als `/v2/` im Pfad. In Headern wie `API-Version`, die beim Bauen einmal gesetzt und danach vergessen wurden. Und in den Verbindungseinstellungen der fertigen Module, die die Version gar nicht erst zeigen. Der letzte Fall ist der unangenehme, weil Sie dort nicht selbst entscheiden, welche Version gerufen wird. Ihr Termin hängt dann an zwei Zeitplänen: dem des Anbieters und dem Ihrer Automatisierungsplattform, die nachziehen muss. Bei den großen Plattformen passiert das meist rechtzeitig, aber eben ohne Ihr Zutun und ohne Ankündigung an Sie.
Technische Konten gehören auf eine Verteileradresse, hinter der mindestens zwei Menschen sitzen, von denen einer die Automatisierung betreut. Persönliche Postfächer und info@ scheiden beide aus, das eine wegen Fluktuation, das andere wegen Betriebsblindheit.
Wo ein Anbieter versionierte Endpunkte anbietet, tragen wir die Version fest ein, statt auf die jeweils aktuelle zu zeigen. Wer immer auf "latest" läuft, bekommt jede Änderung über Nacht und ohne Vorwarnung. Eine feste Version verschiebt den Zeitpunkt der Überraschung dorthin, wo Sie ihn kontrollieren.
Schickt der Anbieter `Deprecation`- oder `Sunset`-Header mit, werten wir sie aus. Ein kleiner Schritt im Workflow prüft, ob der Header gesetzt ist, und meldet einmalig in den Betriebskanal, wenn ein Datum auftaucht. Das kostet zehn Minuten Bauzeit und liefert die Warnung an genau die Stelle, an der jemand sie sieht.
Bekannte Abschaltdaten stehen bei uns im Kalender wie Wartungstermine, mit einem Vorlauf von acht Wochen. Die Migration selbst gehört auf einen normalen Arbeitstag lange vor dem Stichtag, getestet gegen die Testumgebung des Anbieters. Wer am Tag der Abschaltung migriert, macht aus einer geplanten Änderung einen Vorfall.
Der Kalender gehört zum Betrieb
Automatisierung wird oft als Projekt verkauft, mit Anfang, Ende und Abnahme. Der Versandworkflow des Großhändlers zeigt, warum das nicht trägt. Er war korrekt gebaut, hat vierzehn Monate zuverlässig gearbeitet und ist trotzdem an einem Dienstag um sieben Uhr gestorben, ohne dass jemand einen Fehler gemacht hätte. Es hat nur niemand mitgelesen, was der Anbieter seit Januar angekündigt hatte.
Wenn Sie heute nicht sagen können, welche Ihrer Automatisierungen an welcher API-Version hängt, fangen Sie dort an. Das Inventar schafft für sich genommen keinen Wert, aber es macht die Frage vor dem Ausfall beantwortbar statt mittendrin.