Zwei PIM-Systeme, ein Frontend: Produktdaten-Integration in Drupal
B2B-Produktdaten liegen selten in einem System. Was passiert, wenn zwei PIMs parallel eine Drupal-Plattform bedienen müssen? Ein Tech-Insight aus einem echten Enterprise-Projekt – mit Architektur, Stolpersteinen und dem, was wir heute anders machen würden.
Wenn du im B2B-Umfeld Produktkataloge oder Produktseiten baust, kennst du das: Die Produktdaten liegen nie da, wo du sie brauchst. Und selten nur an einem Ort. Gewachsene Konzernstrukturen, Zukäufe, unterschiedliche Produktlinien – am Ende hast du zwei PIM-Systeme, zwei APIs, zwei Datenmodelle. Und ein Frontend, das davon nichts wissen soll.
Genau diese Ausgangslage hatten wir in einem Enterprise-Projekt. In diesem Artikel zeigen wir, wie wir zwei PIM-Quellen in eine Drupal-Plattform integriert haben – und welche Entscheidungen sich im Nachhinein als die wichtigsten herausgestellt haben. Spoiler: Es waren nicht die technischen.
Die Ausgangslage
Unser Kunde (nennen wir ihn Kunde A) betreibt eine mehrsprachige Enterprise-Website auf Drupal-Basis. Drupal dient dabei als zentrale Content- und Datendrehscheibe: Redaktionelle Inhalte werden direkt gepflegt, Produktdaten kommen von außen – aus zwei getrennten PIM-Systemen. Wichtig fürs Verständnis: Es geht nicht um einen Shop. Die Produkte werden nicht verkauft, sondern präsentiert – Produktlisten und Detailseiten (PLP/PDP) als Marketing-Informationen. Das klingt nach der einfacheren Variante. An die Datenqualität stellt es aber dieselben Anforderungen wie E-Commerce: Was auf der Seite steht, muss stimmen – in jeder Sprache.
Warum zwei? Weil die Realität in gewachsenen Unternehmen so aussieht. Zwei Produktbereiche, historisch unterschiedlich aufgestellt, jeweils mit eigenem PIM. Eine Konsolidierung auf ein System stand nicht zur Debatte – zu teuer, zu riskant, zu viele interne Abhängigkeiten. Die Anforderung an uns war klar: Das Frontend darf von dieser Zweiteilung nichts mitbekommen. Ein Produkt ist ein Produkt, egal aus welcher Quelle es kommt.
Klingt simpel. Ist es nicht. Denn die beiden PIMs unterschieden sich in fast allem: Feldstruktur, Attributsystematik, Sprachhandling, API-Qualität und – besonders unangenehm – in dem, was sie nicht liefern.
Schema-Mapping: Ein Zielmodell statt zwei Übersetzungen
Der naheliegende Reflex bei Integrationen: Quelldaten 1:1 übernehmen und im Frontend zurechtbiegen. Das funktioniert genau so lange, bis die zweite Quelle dazukommt. Dann biegst du an zwei Stellen – und jede Frontend-Komponente muss wissen, mit welcher Datenvariante sie es zu tun hat.
Wir sind den anderen Weg gegangen: ein gemeinsames Zieldatenmodell in Drupal, auf das beide Quellen gemappt werden. Das Zielmodell orientiert sich nicht an den PIMs, sondern an dem, was die Produktseiten tatsächlich brauchen – Produktname, technische Attribute, Medien, Varianten, jeweils sauber pro Sprache.
Vereinfacht sieht das so aus:
Jede Quelle bekommt einen eigenen Mapping-Layer, der die Eigenheiten des jeweiligen PIMs kapselt. Dahinter existiert nur noch das Zielmodell. Neue Frontend-Features müssen nie wieder wissen, woher ein Produkt stammt.
Der unbequeme Teil dabei: Lücken in den Quell-APIs. Ein PIM lieferte bestimmte Attribute nur in der Hauptsprache, das andere hatte keine verlässlichen Änderungszeitstempel. Solche Lücken kann man nicht wegmappen – man muss sie sichtbar machen und pro Fall entscheiden: Fallback-Wert, Ableitung aus anderen Feldern oder bewusste Auslassung im Frontend. Wichtig ist, dass diese Entscheidungen dokumentiert im Mapping-Layer liegen und nicht als Sonderfälle über die Codebasis verstreut sind.
Sync-Architektur: Partiell, robust, mit Fallback
Vollimporte über Nacht sind bequem zu bauen und im Enterprise-Kontext fast immer die falsche Antwort. Bei fünfstelligen Produktzahlen und mehreren Sprachen dauert ein Vollimport zu lange, belastet die Quell-APIs und macht aus jedem kleinen Datenfehler ein großes Zeitfenster-Problem.
Unsere Architektur setzt deshalb auf partielle Syncs: Es wird nur übertragen, was sich geändert hat. Wo das Quell-PIM verlässliche Änderungsinformationen liefert, nutzen wir sie direkt. Wo nicht, arbeiten wir mit Checksummen über die relevanten Felder – ändert sich der Hash, wird das Produkt aktualisiert.
Zwei Entscheidungen haben sich dabei besonders bewährt:
1. Deterministische IDs statt Lookup-Tabellen. Jedes Produkt braucht eine stabile Identität in Drupal, unabhängig von Quelle und Sync-Zeitpunkt. Statt Zuordnungstabellen zu pflegen, leiten wir die Document-ID deterministisch aus der SKU ab:
$documentId = hash('sha256', $source . ':' . $sku . ':' . $langcode);
Gleiche SKU, gleiche Quelle, gleiche Sprache → immer dieselbe ID. Damit sind Syncs idempotent: Ein Import kann jederzeit wiederholt werden, ohne Duplikate zu erzeugen. Das klingt nach einem Detail, erspart aber eine ganze Klasse von Fehlern – gerade wenn Syncs abbrechen und neu anlaufen.
2. Manueller Import als Fallback. APIs fallen aus, Quellsysteme haben Wartungsfenster, und manchmal muss ein einzelnes Produkt sofort korrigiert werden. Dafür gibt es einen manuellen Importpfad, der dieselbe Mapping- und Validierungslogik durchläuft wie der automatische Sync. Gleiche Pipeline, anderer Trigger. So bleibt auch der Notfall-Weg konsistent zum Regelbetrieb.
Dazu gehört auch ein sauberes Fehlerverhalten: Ein einzelnes fehlerhaftes Produkt darf nicht den kompletten Sync-Lauf abbrechen. Fehler werden pro Produkt geloggt und gesammelt gemeldet, der Rest läuft durch. Klingt selbstverständlich – in der Praxis sehen wir aber regelmäßig Integrationen, bei denen ein kaputter Datensatz aus dem Quellsystem nachts den ganzen Import stoppt und morgens niemand weiß, warum die Hälfte der Produkte fehlt.
Qualitätssicherung: Daten-Äquivalenz über alle Sprachen
Bei zwei Quellen und mehreren Sprachen reicht "der Sync ist durchgelaufen" als Erfolgskriterium nicht aus. Durchgelaufen heißt nicht korrekt.
Wir haben deshalb Daten-Äquivalenz-Tests aufgesetzt: automatisierte Prüfungen, die Quelldaten und Zielzustand feldweise vergleichen – über alle Sprachen hinweg. Stichprobenartig im Regelbetrieb, vollständig nach größeren Änderungen am Mapping. Die Tests beantworten eine einfache Frage: Steht in Drupal für jedes Produkt in jeder Sprache das, was das PIM liefert – beziehungsweise das, was unser Mapping daraus machen soll?
Gerade der Sprachaspekt hat sich als kritisch erwiesen. Fehler wie "die französische Variante hängt auf einem alten Stand" fallen manuell praktisch nie auf – kein Redakteur prüft systematisch alle Sprachversionen von tausenden Produkten. Automatisiert sind sie eine Query.
Ein Nebeneffekt, den wir nicht eingeplant hatten: Die Äquivalenz-Tests haben mehrfach Fehler in den Quellsystemen aufgedeckt – inkonsistente Übersetzungen, verwaiste Attribute, Produkte, die im PIM als publiziert markiert waren, aber unvollständige Daten hatten. Aus dem QS-Werkzeug wurde damit ein Frühwarnsystem für die Datenqualität des Kunden. Das hat mehr Vertrauen geschaffen als jedes Status-Meeting.
Lessons Learned
Klärungstickets als eigener Workflow. Bei Datenintegrationen entstehen laufend fachliche Fragen, die kein Entwickler allein beantworten kann: "Welches der beiden Gewichtsfelder ist führend?" Statt solche Fragen in Chats versanden zu lassen, haben wir einen eigenen Ticket-Typ eingeführt – mit klarem Ansprechpartner auf Kundenseite und Sichtbarkeit im Projektboard. Das hat die Durchlaufzeit fachlicher Klärungen massiv verkürzt und macht sichtbar, wo das Projekt auf Entscheidungen wartet statt auf Code.
API-Lücken früh sichtbar machen. Verlass dich nicht auf API-Dokumentation – verlass dich auf echte Responses. Wir haben früh im Projekt beide APIs systematisch gegen die Anforderungen des Zielmodells geprüft und jede Lücke dokumentiert, bevor die erste Zeile Sync-Code entstand. Jede dieser Lücken wurde zur bewussten Entscheidung statt zur Überraschung im Livegang. Der halbe Tag Analyse pro API hat uns Wochen an Nacharbeit erspart.
Das Zielmodell ist die eigentliche Architekturentscheidung. Sync-Jobs kann man umbauen, Mapping-Regeln anpassen. Aber das Zieldatenmodell sitzt unter allem – Frontend, Suche, Tests. Die Zeit, die wir zu Projektbeginn in dieses Modell investiert haben, war die am besten angelegte im ganzen Projekt.
Fazit
Zwei PIMs und ein Frontend sind kein Sonderfall, sondern Enterprise-Alltag. Die Technik dafür ist beherrschbar – entscheidend ist die Architektur: ein quellenunabhängiges Zielmodell, idempotente Syncs, automatisierte Datenprüfung. Und ein Prozess, der fachliche Klärungen genauso ernst nimmt wie Code.
Fachlich geprüft von Manuel
Manuel hat an diesem Projekt selbst mitentwickelt und diesen Artikel auf technische Richtigkeit geprüft. KI-gestützt geschrieben, von Menschen verantwortet.
Zum Profil von Manuel
