Maschinenbau braucht Produktdaten, nicht Prosa
Der Mittelstand an der Donau lebt von erklärungsbedürftigen Produkten: Varianten, technische Daten, Datenblätter, oft in mehreren Sprachen. Solche Inhalte gehören selten ins CMS getippt; sie kommen aus ERP oder PIM und sollen dort gepflegt bleiben.
TYPO3 ist für diesen Fall gut aufgestellt: eigene Datenmodelle über Extbase, Schnittstellen zu bestehenden Systemen und eine Ausgabe, die sich frei gestalten lässt. Was wir dabei früh klären: Was passiert, wenn die Gegenseite nicht antwortet? Ein definiertes Verhalten im Fehlerfall ist wichtiger als der schnellste Import.
Nähe, die man merkt
Von Stuttgart nach Ulm ist es rund eine Stunde. Das klingt banal, ändert im Projektalltag aber etwas: Ein kurzfristiger Termin ist möglich, ohne dass jemand einen halben Tag verliert. Für Auftakt, Workshops und Schulungen nutzen wir das gern.
Wenn die Installation älter ist als der letzte Relaunch
Viele Auftritte in der Region sind solide gebaut und einfach in die Jahre gekommen: Die Version läuft aus dem Support, die Extensions sind teils verwaist. Der Weg dorthin ist fast immer derselbe: Bestandsaufnahme, dann die ehrliche Entscheidung zwischen Update und Relaunch, dann geordnete Umsetzung.
Schnittstellen sind der eigentliche Projektkern
Bei Maschinenbauern entscheidet sich ein Website-Projekt selten am Entwurf, sondern an der Frage, wie Produktdaten auf die Seite kommen. Varianten, Kennwerte, Datenblätter, oft mehrsprachig — all das entsteht im ERP oder PIM und soll dort bleiben.
Für TYPO3 heißt das: eigene Datenmodelle über Extbase, eine Schnittstelle, die Änderungen erkennt, und eine Ausgabe, die sich frei gestalten lässt. Der Aufwand steckt weniger im Import als in den Randfällen. Was passiert, wenn die Gegenseite nicht antwortet? Was gilt als Wahrheit, wenn beide Seiten geändert wurden? Diese Fragen klären wir vor der Umsetzung, nicht im Betrieb.
Wenn Daten regelmäßig kommen sollen
Ein Import, den jemand von Hand anstößt, wird irgendwann vergessen. Deshalb laufen solche Aufgaben über den Scheduler: geplant, protokolliert und ohne Zutun.
Der Haken daran ist bekannt und trotzdem verbreitet: Der Scheduler startet sich nicht selbst. Fehlt der Cronjob auf dem Server oder ging er bei einem Umzug verloren, laufen die Aufgaben nicht — und niemand merkt es, weil im Backend alles richtig aussieht.
Wir richten deshalb bei allem, worauf sich jemand verlässt, eine Meldung ein, die auch bei ausbleibender Ausführung anschlägt. Nur auf Fehler zu achten reicht nicht: Eine Aufgabe, die gar nicht mehr startet, meldet auch keinen Fehler.