Was passiert mit Schnittstellen und externen Diensten beim TYPO3-Update?

Schnittstellen und externe Dienste gehören bei einem TYPO3-Update zu den Dingen, die man leicht übersieht, weil sie oft nicht direkt im Frontend sichtbar sind. Im Grunde zählt für mich alles dazu, was das TYPO3-System über Requests verlässt. Das können zum Beispiel Payment-Anbieter, Newsletter-Systeme, CRM- oder ERP-Systeme, Suchdienste, externe APIs, Karten, Webhooks, Importe oder Exporte sein. Eine Schnittstelle muss nach einem TYPO3-Update nicht automatisch angepasst werden. Aber sie muss geprüft und getestet werden, weil sich TYPO3, PHP, verwendete Bibliotheken oder die externe API selbst verändert haben können.

Was prüfe ich bei einer Schnittstelle zuerst?

Zuerst schaue ich mir an, wo und wie die Anbindung umgesetzt ist.

Dabei interessiert mich unter anderem:

welche API oder welches externe System verwendet wird
welche Bibliothek oder welches SDK im Projekt steckt
welche API-Version angesprochen wird
wie die Authentifizierung funktioniert
ob API-Keys oder Tokens verwendet werden
ob die verwendete Bibliothek mit der neuen PHP-Version läuft
ob die externe API noch genauso funktioniert wie vorher

Gerade bei älteren Projekten ist das wichtig, weil eine Schnittstelle oft schon viele Jahre unverändert läuft.

Nur weil sie bisher funktioniert hat, heißt das nicht automatisch, dass sie auch mit einer neuen PHP- oder TYPO3-Version unverändert weiterläuft.

Warum spielt PHP bei Schnittstellen eine so große Rolle?

Ein TYPO3-Update wird oft notwendig, weil die eingesetzte TYPO3-Version aus dem Support läuft. Es kann aber genauso gut passieren, dass der Hoster Druck macht. Wenn ein Hoster zum Beispiel ankündigt, eine alte PHP-7-Version abzuschalten, kann dadurch ein TYPO3-Update zwingend werden. Dann betrifft die neue PHP-Version nicht nur TYPO3 selbst, sondern auch alle Bibliotheken und Schnittstellen, die im Projekt verwendet werden. Wenn eine alte PHP-Library mit der neuen PHP-Version nicht mehr funktioniert, muss geprüft werden, ob es eine aktuelle Version der Library oder eine neue API-Version gibt. Dann wird die Integration entsprechend angepasst.

Eine Schnittstelle kann deshalb durchaus der Teil sein, der ein ansonsten machbares TYPO3-Update blockiert.

Auch der externe Anbieter kann sich verändert haben

Nicht jede Änderung entsteht durch TYPO3. Auch externe Anbieter entwickeln ihre Systeme weiter. Eine API kann eine neue Version bekommen, alte Endpunkte können entfernt werden oder ein Authentifizierungsverfahren kann sich ändern. Im ungünstigsten Fall wird ein alter Dienst komplett abgeschaltet. Dann reicht es nicht, nur den TYPO3-Code kompatibel zu machen. Die Integration muss auf die neue Schnittstelle umgebaut oder durch eine andere Lösung ersetzt werden. Wenn ein externer Anbieter die bisher verwendete API-Version nicht mehr unterstützt, gehört die Umstellung auf die aktuelle Variante für mich zum Update dazu.

Müssen API-Keys und Zugangsdaten geändert werden?

Nicht zwingend. Ob bestehende Zugangsdaten weiterverwendet werden können, hängt vom jeweiligen Anbieter und von der Art der Integration ab. Manche Systeme verwenden einfache API-Keys, andere OAuth-Tokens oder andere Authentifizierungsverfahren. Das lässt sich nicht pauschal beantworten und muss im konkreten Projekt geprüft werden. Wichtig ist nur, dass diese Zugangsdaten beim Testen und beim späteren Go-live sauber getrennt behandelt werden.

Wie teste ich externe Dienste?

Das hängt vom Anbieter ab. Ideal ist eine eigene Test- oder Sandbox-Umgebung. Dann lässt sich die komplette Integration testen, ohne echte Daten oder Transaktionen auszulösen. Stripe ist dafür ein gutes Beispiel. Stripe bietet eigene API-Keys für Test und Live. In einem aktuellen Projekt habe ich die komplette Payment-Integration auf dem Entwicklungssystem mit dem Test-Key umgesetzt und geprüft. Beim Go-live musste anschließend nur noch der Live-Key eingesetzt werden. Die Integration hat danach genauso funktioniert wie zuvor in der Sandbox.
So sollte ein Testsystem im Idealfall aussehen.

Was ist, wenn es keine Sandbox gibt?

Dann wird es etwas unangenehmer, aber nicht automatisch unmöglich. Es muss im Einzelfall geprüft werden, wie sich die Schnittstelle sicher testen lässt, ohne unerwünschte Aktionen im Live-System auszulösen. Manchmal lassen sich Testdatensätze verwenden, manchmal bestimmte Requests gezielt ausführen oder bestimmte Teile der Integration separat prüfen. Hier gibt es keinen Standardweg, der für jede Schnittstelle funktioniert.

Scheduler, Cronjobs und Importe sind besonders leicht zu übersehen

Nicht jede Schnittstelle wird durch einen Klick im Frontend ausgelöst. Gerade ältere TYPO3-Projekte haben oft Prozesse, die komplett im Hintergrund laufen:

Scheduler-Tasks
Cronjobs
nächtliche Datenimporte
Exporte
CSV- oder XML-Feeds
Webhooks
automatische Synchronisationen
regelmäßige API-Abfragen

Das sind genau die Dinge, die sich bei einem Update besonders gut verstecken. Eine Website kann im Frontend perfekt aussehen, während im Hintergrund seit dem Update kein einziger Datensatz mehr importiert wird.

Deshalb gehören Scheduler-Tasks und andere Hintergrundprozesse immer in den Testplan.

Was ist, wenn niemand die Schnittstelle dokumentiert hat?

Dann bleibt nur Analyse. Ich lese den Code, schaue mir an, welche Requests gesendet werden, welche Bibliotheken verwendet werden und suche die Dokumentation des externen Anbieters. Das ist bei Legacy-Projekten nichts Ungewöhnliches. Im Idealfall gibt es eine saubere Dokumentation und einen Ansprechpartner, der genau weiß, was die Integration macht. Wenn das nicht der Fall ist, muss die Funktionsweise Schritt für Schritt aus dem bestehenden System heraus verstanden werden. Das kostet natürlich zusätzliche Zeit.

Der Kunde muss externe Systeme nennen

Schnittstellen gehören deshalb für mich schon in die erste Analyse. Ich frage ausdrücklich nach externen Systemen und besonderen Prozessen, weil man nicht alles sofort im TYPO3-Backend erkennen kann.

Der Kunde muss dabei keine technischen Details erklären können. Es reicht erstmal zu wissen:

Es gibt eine Verbindung zu unserem CRM.
Nachts werden Produktdaten importiert.
Bestellungen gehen an ein externes System.
Formulare übertragen Daten an einen Dienstleister.
Wir verwenden Stripe für Zahlungen.

Den technischen Rest kann ich im Projekt nachvollziehen.

Wichtig ist nur, dass bekannte externe Abhängigkeiten nicht erst nach dem Update zufällig auftauchen.

Kann eine Schnittstelle das komplette Update blockieren?

Ja. Wenn eine für den Betrieb notwendige Integration nicht mit der neuen PHP- oder TYPO3-Umgebung funktioniert, kann das ein echter Blocker sein.

Dann muss zunächst geklärt werden, wie diese Funktion künftig umgesetzt wird. Das kann bedeuten:

eine neuere API-Version verwenden
eine Bibliothek aktualisieren
die Integration selbst anpassen
auf einen anderen Anbieter wechseln
die Funktion komplett ersetzen
die Funktion entfernen, wenn sie nicht mehr benötigt wird

Welche Variante gewählt wird, entscheidet der Kunde anhand von Funktion, Aufwand und Kosten.

Wie viel Aufwand machen Schnittstellen bei einem Update?

Das kann von fast nichts bis zu einem größeren Arbeitspaket reichen. Eine einfache REST-API, deren Bibliothek weiterhin kompatibel ist und deren Endpunkte unverändert geblieben sind, kann nach kurzer Prüfung und einem Funktionstest erledigt sein. Eine alte komplexe Integration mit veralteter PHP-Library, neuer API-Version und fehlender Dokumentation kann dagegen erheblichen Aufwand verursachen. Das lässt sich nur nach einem Blick ins konkrete Projekt seriös einschätzen.

Eine vorhandene Schnittstelle ist nicht automatisch teuer. Eine unbekannte oder technisch überholte Schnittstelle kann es aber werden.

Was muss beim Go-live beachtet werden?

Auch das hängt von der jeweiligen Integration ab. Manche Systeme unterscheiden klar zwischen Development und Live. Dann müssen beim Go-live zum Beispiel API-Keys, Callback-Adressen oder Webhook-URLs auf die produktive Umgebung umgestellt werden. Bei anderen Integrationen bleibt alles unverändert. Solche Punkte werden während der Arbeit am Update normalerweise sichtbar und gehören anschließend in den Go-live-Ablauf. Gerade bei externen Diensten ist wichtig, dass nach dem Umschalten nicht nur die Website selbst getestet wird, sondern auch die Kommunikation mit den angeschlossenen Systemen.

Was passiert also mit Schnittstellen beim TYPO3-Update?

Zuerst wird geprüft, welche externen Systeme überhaupt angebunden sind und wie die Integration technisch umgesetzt wurde. Danach muss geklärt werden, ob verwendete Bibliotheken, PHP-Versionen, APIs und Authentifizierungen weiterhin funktionieren. Wenn der externe Anbieter inzwischen eine neue API verlangt, wird die Integration entsprechend modernisiert. Wenn ein Dienst komplett verschwunden ist, muss gemeinsam entschieden werden, wie die Funktion künftig gelöst wird. Und auch versteckte Prozesse wie Scheduler-Tasks, Cronjobs und automatische Importe müssen getestet werden.

Eine Schnittstelle muss nach einem TYPO3-Update nicht automatisch angepasst werden. Aber sie muss geprüft und getestet werden, weil sich TYPO3, PHP, verwendete Bibliotheken oder die externe API selbst verändert haben können.