Drupal mit PIM und ERP als Quellen für Spezifikationen verbinden

Eine Produktspezifikation ändert sich, und jemand muss die Website aktualisieren, die Vergleichstabelle prüfen und jeden Absatz finden, der den alten Wert wiederholt. Eine Drupal-PIM-Integration kann diese wiederholte Pflege reduzieren, indem sie Ihre Website mit den Systemen verbindet, in denen freigegebene Produktdaten bereits liegen.

Die sinnvolle Grenze ist einfach: PIM und ERP sind für die Werte verantwortlich, Drupal für ihre Darstellung, für Erklärungen für Käufer und für die Abdeckung von Antworten (Answer Coverage). Damit diese Grenze funktioniert, sind Entscheidungen auf Feldebene nötig.

Das ist für Käufer und KI-Assistenten gleichermaßen wichtig. Beide brauchen konsistente Spezifikationen und genug Kontext, um sie richtig einzuordnen. Mit den strukturierten Feldern von Drupal bleiben diese Daten wiederverwendbar, und Sie können die Erklärungen ergänzen, die ein Produktdatensatz selten enthält.

In diesem Artikel:

• Welches System sollte für welches Produktfeld verantwortlich sein?
• Wie sollten PIM-Attribute Drupal-Feldern zugeordnet werden?
• Welches Synchronisierungsmuster passt zu welcher Art von Daten?
• Was passiert, wenn beide Systeme denselben Wert ändern?
• Was sollte Drupal tun, wenn PIM oder ERP nicht erreichbar sind?
• Wie macht die Anreicherung in Drupal aus Spezifikationen Antworten?
• Was sollten Teams vor dem Start prüfen?

Welches System sollte für welches Produktfeld verantwortlich sein?

Beginnen Sie mit der Verantwortung, nicht mit den Konnektoren. Eine funktionierende API-Verbindung verhindert nicht, dass zwei Teams dasselbe Maß in unterschiedlichen Systemen ändern.

Eine Verantwortungsmatrix gibt Redaktion und Entwicklung eine gemeinsame Referenz. Legen Sie für jedes Feld das maßgebliche System, die berechtigten Bearbeiter, die Synchronisierungsrichtung und das Verhalten bei der Veröffentlichung fest. Halten Sie auch fest, was geschieht, wenn die Quelle nicht verfügbar ist.

Hier eine beispielhafte Aufteilung. Die tatsächlichen Verantwortlichen hängen davon ab, wo Ihr Unternehmen den jeweiligen Wert freigibt.

Das System, das einen Wert liefert, ist nicht unbedingt dafür verantwortlich. Eine ERP-Kennung kann über das PIM laufen, bevor sie Drupal erreicht. Verantwortlich für diese Kennung bleibt das ERP; das PIM ist nur der Übertragungsweg.

Wenn beide Systeme dasselbe Attribut bereitstellen, wählen Sie einen maßgeblichen Importweg. Schreiben zwei Konnektoren in dasselbe Drupal-Feld, wird die Reihenfolge des Eintreffens zur Geschäftsregel.

Ziehen Sie die Grenze zur Öffentlichkeit ebenso klar. Interne Einkaufspreise, Lieferantenkonditionen und Beschaffungsnotizen gehören nicht in einen öffentlichen Produktimport, es sei denn, es gibt dafür einen ausdrücklichen, freigegebenen Grund. Verwenden Sie eine Allowlist der zu importierenden Felder und prüfen Sie separat, was jede öffentliche Ausgabe preisgibt.

Auch Übersetzungen brauchen Verantwortliche. Das PIM kann für übersetzte technische Bezeichnungen verantwortlich sein, während die Drupal-Redaktion lokalisierte Kaufberatung verantwortet. Legen Sie die Verantwortung für jedes übersetzte Feld fest, statt davon auszugehen, dass das Website-Team alles übersetzt.

Einen breiteren Blick auf die Planung solcher Verbindungen bietet der Artikel Wie führt man eine Drupal-Integration mit anderen Enterprise-Systemen durch?

Wie sollten PIM-Attribute Drupal-Feldern zugeordnet werden?

Ein klarer Zuordnungsvertrag spart Zeit bei der Fehlersuche und verhindert subtile Fehler, etwa einen Millimeterwert mit einer Zoll-Einheit.

Dokumentieren Sie für jedes importierte Attribut:

• den Attributcode in der Quelle und das Zielfeld in Drupal,
• Datentyp, Einheit, Genauigkeit und zulässige Werte,
• Sprache, Markt und Variante, für die es gilt,
• Validierungsregeln und das Verhalten bei fehlenden oder ungültigen Daten,
• ob eine akzeptierte Aktualisierung sofort veröffentlicht werden kann oder geprüft werden muss.

Verknüpfen Sie Datensätze über stabile externe Kennungen. Produktnamen ändern sich, und übersetzte Namen können völlig anders lauten. Auch Varianten brauchen eigene Kennungen und ausdrückliche Verknüpfungen zum übergeordneten Produkt, damit die Spezifikationen einer Variante nicht versehentlich auf Ebene der Produktfamilie erscheinen.

Werte und Darstellung getrennt halten

Angenommen, das PIM enthält eine maximale Betriebstemperatur von 80 Grad Celsius. Speichern Sie den Zahlenwert und die Einheit getrennt und setzen Sie beide erst für die Seite zusammen.

Diese Struktur ermöglicht eine einheitliche Darstellung, Vergleiche, Filter und maschinenlesbare Ausgaben. Sie macht auch die Umrechnung von Einheiten möglich, sofern Ihre Produktregeln das erlauben. Ein einzelnes Textfeld mit „bis zu 80 °C“ lässt sich schwerer validieren oder wiederverwenden.

Felder, Entities und Taxonomiebegriffe in Drupal liefern die Bausteine. Die Integration braucht trotzdem eine ausdrückliche Zuordnungs- und Validierungslogik; Drupal leitet die geschäftliche Bedeutung eines Quellattributs nicht selbst ab.

Festlegen, was ein fehlender Wert bedeutet

Teilaktualisierungen verdienen besondere Aufmerksamkeit. Diese drei Zustände können Unterschiedliches bedeuten:

• Fehlendes Attribut: Die übertragenen Daten (Payload) enthalten nichts zu diesem Feld, also bleibt der gespeicherte Wert unverändert.
• Ausdrücklich leerer Wert: Die Quelle liefert bewusst einen leeren Wert, der gemäß dem Vertrag des Feldes behandelt wird.
• Beabsichtigte Löschung: Ein definierter Vorgang in der Quelle leert oder entfernt den Wert.

Machen Sie diese Unterschiede ausdrücklich. Andernfalls kann eine unvollständige Antwort gültige Spezifikationen löschen.

Ordnen Sie auch Beziehungen und Kategorien bewusst zu. Führt das PIM eine neue Klassifizierung oder einen neuen Aufzählungswert ein, legen Sie fest, ob Drupal einen zugeordneten Begriff anlegt, die betroffene Aktualisierung zur Prüfung zurückhält oder sie mit einer Warnung ablehnt. Ein unbekannter Code, der stillschweigend veröffentlicht wird, hilft Käufern selten.

Legen Sie schließlich in Drupal eigene Felder für Inhalte an, die das PIM nicht hat: direkte Antworten, Erklärungen und Relevanz für Zielgruppen. Halten Sie diese Felder außerhalb dessen, was der Import schreiben darf. Diese Trennung schützt die redaktionelle Arbeit, ohne das PIM in ein System für Website-Inhalte zu verwandeln.

Welches Synchronisierungsmuster passt zu welcher Art von Daten?

Wählen Sie die Synchronisierung nach der Verzögerung, die Ihr Unternehmen akzeptieren kann. Eine stabile Materialangabe und eine sich schnell ändernde Verfügbarkeitsangabe brauchen selten dieselbe Behandlung.

Zeitgesteuerte Importe eignen sich für Daten, die sich selten ändern. Berücksichtigen Sie API-Ratenbegrenzungen, Paginierung und die Dauer eines Batch-Laufs. Ein stündlich gestarteter Import bedeutet nicht, dass jedes Produkt innerhalb einer Stunde aktualisiert wird, wenn der Lauf selbst länger dauert.

Ereignisgesteuerte Importe legen Änderungsbenachrichtigungen meist in einer Warteschlange ab. Worker validieren die Aktualisierungen anschließend und übernehmen sie. Planen Sie für wiederholte, verspätete und in falscher Reihenfolge eintreffende Ereignisse. Eine Benachrichtigung kann auch nur ein geändertes Produkt nennen, sodass der Worker den aktuellen freigegebenen Datensatz selbst abruft.

Aktualisierungen auf Anforderung geben dem Support eine praktische Möglichkeit, ein Produkt zu prüfen, ohne auf den nächsten Batch-Lauf zu warten. Daten beim Aufruf einer öffentlichen Seite abzurufen, ist eine andere Entscheidung: Das Verhalten der Seite hängt dann von Verfügbarkeit und Antwortzeit des Quellsystems ab.

Oft passt eine Kombination: Ereignisse übernehmen Änderungen, ein zeitgesteuerter Abgleich findet verpasste Aktualisierungen, und eine kontrollierte manuelle Aktualisierung unterstützt die Fehleranalyse. Setzen Sie sie ein, wenn die Möglichkeiten der Quelle und das Aktualisierungsvolumen den betrieblichen Aufwand rechtfertigen.

Verarbeitungsregeln vor der Wahl der Werkzeuge festlegen

Unabhängig vom Auslöser braucht der Import dieselben Schutzmechanismen:

• Idempotente Verarbeitung: Eine wiederholte Aktualisierung legt keine doppelten Produkte an und löst keine unbeabsichtigten Aktionen erneut aus.
• Revisionsprüfungen: Eine ältere Revision aus der Quelle überschreibt keine neuere, bereits akzeptierte.
• Begrenzte Wiederholungen: Vorübergehende Fehler bekommen einen weiteren Versuch, ohne die Quelle zu überlasten.
• Veröffentlichungsregeln: Das Team weiß, ob ein Import einen Entwurf, einen veröffentlichten Datensatz oder eine Revision aktualisiert, die auf Freigabe wartet.

Validieren Sie zusammengehörige Felder gemeinsam, wenn sie konsistent bleiben müssen. Ein neues Maß mit einer alten Einheit zu veröffentlichen, kann schlimmer sein, als kurzzeitig das vorherige gültige Wertepaar beizubehalten.

Der Weg zu einem KI-Konsumenten hat mehrere Schritte:

Freigegebene Änderung im PIM → Drupal-Feld → Veröffentlichung und Cache-Invalidierung → konfigurierte API oder Feed → Abruf durch den Assistenten

Ein separater Suchindex oder ein Index für Retrieval-Augmented Generation (RAG) fügt einen weiteren Aktualisierungsschritt hinzu. Legen Sie das Aktualitätsfenster für diesen gesamten Weg fest, statt nur zu messen, wann der Importjob endet.

Was passiert, wenn beide Systeme denselben Wert ändern?

Schützen Sie die Redaktion vor Arbeit, die der nächste Import rückgängig macht.

Angenommen, eine Redakteurin bemerkt ein falsches Maß und korrigiert es direkt in Drupal. Im PIM steht weiterhin der alte Wert, also stellt ihn die nächste Synchronisierung wieder her. Die Korrektur war vernünftig. Der Integration fehlte eine klare Regel, wo diese Korrektur hingehört.

Machen Sie Spezifikationsfelder, für die die Quelle verantwortlich ist, für die Drupal-Redaktion standardmäßig schreibgeschützt, und bieten Sie einen sichtbaren Weg, eine Korrektur in der Quelle anzufordern. Setzen Sie dieselbe Grenze auch in eigenen Formularen, bei Schreibzugriffen über die API und im Importcode durch; ein Feld in nur einer Bearbeitungsmaske auszublenden, reicht nicht.

Verwenden Sie Revisionen oder Sequenznummern der Quelle, um veraltete eingehende Aktualisierungen abzulehnen. Zeitstempel aus getrennten Systemen können wegen abweichender Uhren oder Verarbeitungsverzögerungen voneinander abweichen. Hat eine Quelle keine Revisionsmerkmale, legen Sie eine andere sichere Reihenfolge fest, zum Beispiel indem Sie Aktualisierungen pro Produkt nacheinander verarbeiten und den aktuellen Datensatz erneut aus der Quelle abrufen, bevor Sie eine Änderung aus der Warteschlange übernehmen.

Vorübergehende Überschreibungen sichtbar und getrennt halten

Manche Teams brauchen eine Notfall-Überschreibung, während eine Korrektur in der Quelle noch freigegeben wird. Speichern Sie diese Überschreibung getrennt vom importierten Wert, zusammen mit:

• einer verantwortlichen Person und einem Grund,
• einem Freigabevermerk,
• einem Ablaufdatum,
• einer Regel, welchen Wert die Leser sehen.

Auch für den Ablauf braucht es ein festgelegtes Ergebnis. Je nach Risiko kann er den Wert aus der Quelle wiederherstellen oder das Produkt erneut zur Prüfung schicken.

Führen Sie ein Prüfprotokoll über akzeptierte Änderungen, abgelehnte Aktualisierungen und Überschreibungen. Leiten Sie abgelehnte Quelldaten an das Team weiter, das sie korrigieren kann, mit genug Details, um Produkt und Feld zu identifizieren.

Eine geänderte Spezifikation kann auch eine Erklärung in Drupal unzutreffend machen. Behandeln Sie das als redaktionelle Prüfaufgabe, nicht als Erlaubnis für den Import, die Erklärung zu überschreiben. An dieser Stelle treffen die Verantwortung der Quelle und die redaktionelle Verantwortung aufeinander.

Was sollte Drupal tun, wenn PIM oder ERP nicht erreichbar sind?

Produktseiten können während eines Ausfalls der Quelle verfügbar bleiben, wenn Drupal freigegebene Spezifikationen lokal speichert. Besucher lesen dann den in Drupal veröffentlichten Stand, statt bei jedem Seitenaufruf auf eine Live-Anfrage an das PIM zu warten.

Halten Sie die Seiten nützlich. Das bedeutet nicht, dass jede gespeicherte Angabe unbegrenzt sichtbar bleiben darf.

Legen Sie den Umgang mit veralteten Daten pro Feld fest. Eine Materialangabe kann auch bei einem längeren Ausfall veröffentlicht bleiben, während eine Verfügbarkeitsangabe viel früher einen Hinweis braucht oder ausgeblendet werden muss. Sicherheitsrelevante Informationen können noch strengere Regeln erfordern.

Erfassen Sie mindestens zwei getrennte Zeitpunkte:

• Letzte erfolgreiche Prüfung in der Quelle: wann die Integration den Datensatz zuletzt bestätigt hat.
• Letzte Änderung in der Quelle: wann sich der Wert in der Quelle zuletzt geändert hat.

Eine Spezifikation, die sich seit Monaten nicht geändert hat, kann trotzdem aktuell sein, wenn die Integration sie heute geprüft hat. Das Alter der letzten Änderung allein sagt nicht, ob ein Wert veraltet ist.

Bei einem Timeout, einem Authentifizierungsfehler oder einer unvollständigen Antwort behalten Sie den letzten gültigen importierten Stand bei. Eine fehlgeschlagene Anfrage ist keine Anweisung zum Löschen. Dasselbe Prinzip gilt für Batch-Importe: Nehmen Sie Produkte nicht vom Markt, nur weil sie in einem unvollständigen Lauf fehlten.

Planen Sie die Wiederherstellung vor dem Start. Nutzen Sie begrenzte Wiederholungen mit Backoff, eine Warteschlange für fehlgeschlagene Vorgänge, Warnungen an ein benanntes Team und einen dokumentierten Prozess für die erneute Verarbeitung. Gleichen Sie die Datensätze nach der Wiederherstellung der Quelle ab, um während des Ausfalls verpasste Änderungen zu erfassen.

Die Verantwortungsmatrix kann auch die Entscheidung für die Leser festhalten: den Wert beibehalten, ein Prüfdatum oder einen Hinweis auf veraltete Daten anzeigen oder die Angabe ausblenden. Entscheiden Sie nach dem geschäftlichen Risiko und verwenden Sie dieselbe Regel auf der Seite und in jeder zulässigen Datenausgabe.

Wie macht die Anreicherung in Drupal aus Spezifikationen Antworten?

Eine Spezifikationstabelle sagt Käufern, was ein Produkt enthält. Die Anreicherung hilft ihnen zu entscheiden, was diese Werte für ihre Situation bedeuten.

Drei in Drupal verwaltete Inhaltselemente machen diesen Unterschied greifbar:

• Direkte Antwort: eine knappe Antwort auf eine konkrete Käuferfrage.
• Erklärung für Käufer: die Spezifikationen und Bedingungen, auf denen die Antwort beruht.
• Relevanz für Zielgruppen: warum diese Fakten für eine bestimmte Anwendung oder Zielgruppe wichtig sind.

Angenommen, ein Käufer fragt, ob ein Gerät in einen 590 mm breiten Einbauraum passt. In diesem Beispiel beträgt die freigegebene Produktbreite 560 mm, und die Montageanleitung verlangt auf jeder Seite 20 mm Abstand.

Die direkte Antwort kann lauten: „Nein. Der Raum ist zu schmal, wenn man den erforderlichen seitlichen Abstand einrechnet.“

Die Erklärung zeigt die Rechnung: 560 + 20 + 20 = 600 mm erforderliche Breite. Der Kontext für eine Zielgruppe kann erklären, warum Installateure die Abstände vor der Bestellung prüfen sollten. Das ist nützlicher, als Käufer mit einem bloßen Maß allein zu lassen.

Halten Sie die Aussage eng. Die Breite allein belegt nicht, dass der Einbau insgesamt möglich ist; auch Tiefe, Höhe, Zugänglichkeit, Belüftung und weitere Anforderungen können eine Rolle spielen. Fehlt in der Quelle eine Angabe zum erforderlichen Abstand, sagen Sie, dass die Datenlage unvollständig ist, statt eine Anforderung zu erfinden.

Antworten mit den zugrunde liegenden Fakten verknüpfen

Wo es praktikabel ist, verweisen Sie über eine kontrollierte Darstellung auf strukturierte Spezifikationen, statt Zahlen manuell in mehrere Absätze zu kopieren. Die Redaktion pflegt die Erklärung, und Drupal fügt den freigegebenen Wert ein.

Halten Sie fest, welche Quellattribute jede Antwort stützen. Eine geänderte Breite oder ein geänderter Mindestabstand kann dann eine Prüfung der Montageantwort auslösen, ohne jede Produktseite erneut in die redaktionelle Prüfung zu schicken.

Bei Aussagen mit höherem Risiko können Sie die betroffene Antwort bis zur Prüfung ausblenden. Bei Erklärungen mit geringerem Risiko kann eine Prüfaufgabe genügen. Vereinbaren Sie dieses Verhalten, bevor die Änderung aus der Quelle eintrifft.

Drupal kann freigegebene Fakten und Anreicherungen in Seitendarstellungen und zulässigen maschinenlesbaren Ausgaben wiederverwenden. JSON-LD, JSON:API, Feeds oder Markdown brauchen jeweils eine eigene Konfiguration, Zugriffsprüfungen und Veröffentlichungsregeln. Das gemeinsame Inhaltsmodell hilft, sie konsistent zu halten; es macht aber nicht jedes gespeicherte Feld sicher für die Veröffentlichung.

Wie Sie vergleichbare Werte in Felder überführen, zeigen wir im Artikel Drupal Content Modeling für Answer Coverage: Felder statt Fließtext. Wie Daten über APIs bereitgestellt werden, beschreibt der Artikel Headless CMS. Wie können Daten mithilfe von REST API und JSON API Modulen offengelegt werden?

Eine gepflegte Produktquelle für KI-Assistenten

Wird Drupal mit freigegebenen PIM- und ERP-Datensätzen verbunden, erhalten KI-Integrationen eine gepflegte Produktquelle statt eines weiteren manuell kopierten Katalogs. Ändert sich die Breite des Geräts im PIM, sollte ein angebundener Assistent den aktualisierten Wert zusammen mit Produktkennung, Einheit, Variante und Marktkontext abrufen.

Dieser Vorteil hängt vom gesamten Abrufweg ab. Ein Assistent, der zulässige API-Daten nutzt, kann die Aktualität prüfen; öffentliche KI-Suchsysteme steuern Abruf und Indexierung nach eigenem Zeitplan. Eine Aktualisierung in Drupal ändert weder die Trainingsdaten eines Modells noch garantiert sie, dass seine Antwort die Änderung berücksichtigt.

Für die Montagefrage braucht der Assistent außerdem die Anforderungen an die Abstände und relevante Einschränkungen. Schlägt der Abruf fehl oder ist das Aktualitätsfenster abgelaufen, sollte die Integration die Unsicherheit offenlegen oder auf eine Aussage zum aktuellen Wert verzichten, statt alte Daten als aktuell darzustellen.

Was sollten Teams vor dem Start prüfen?

Testen Sie die Grenze, nicht nur die Verbindung. Der erfolgreiche Import eines einzigen vollständigen Produkts sagt wenig darüber aus, wie sich die Integration bei alltäglichen Änderungen verhält.

Verwenden Sie repräsentative Produkte, Varianten, Übersetzungen und auslaufende Artikel. Prüfen Sie dann, ob Folgendes zutrifft:

• Die Verantwortung ist eingehalten. Jedes importierte Feld hat ein maßgebliches System, jedes Anreicherungsfeld eine redaktionelle Verantwortung, und Importe lassen die in Drupal verwalteten Inhalte unverändert.
• Wiederholte und vertauschte Aktualisierungen bleiben sicher. Doppelte Ereignisse erzeugen keine doppelten Datensätze, und ältere Revisionen ersetzen keine neueren Werte.
• Zuordnungsfehler bleiben sichtbar. Nicht passende Einheiten, unbekannte Kategorien und fehlende Übersetzungen folgen vereinbarten Regeln, statt stillschweigend irreführende Seiten zu erzeugen.
• Teilaktualisierungen erhalten gültige Daten. Fehlende Attribute, ausdrücklich leere Werte, beabsichtigte Löschungen und unvollständige Antworten führen zu jeweils eigenen Ergebnissen.
• Die Veröffentlichung erreicht die Leser. Korrekturen in der Quelle erscheinen nach den erwarteten Veröffentlichungsschritten und der Cache-Invalidierung auf den öffentlichen Seiten.
• Die Wiederherstellung nach einem Ausfall funktioniert. Beibehaltene Werte, Hinweise auf veraltete Daten, ausgeblendete Angaben, Warnungen und die erneute Verarbeitung verhalten sich wie geplant.
• Antworten bleiben mit ihren Belegen verknüpft. Ändert sich eine zugrunde liegende Spezifikation, entsteht eine Prüfaufgabe für die richtige Person in der Redaktion.
• Öffentliche Ausgaben stimmen überein. Seiten und bereitgestellte Daten verwenden dieselben freigegebenen Werte und schließen interne Felder aus.

Testen Sie auslaufende Produkte ausdrücklich. Ein ausgelaufener Artikel braucht vielleicht einen Link zum Nachfolger, die Entfernung aus Feeds oder eine beibehaltene Referenzseite. Das richtige Verhalten hängt von Ihren Käufern und Geschäftsprozessen ab, sollte aber nicht zufällig durch einen fehlgeschlagenen Import entstehen.

Gehört ein angebundener KI-Konsument zum Umfang, prüfen Sie nach einer Korrektur in der Quelle seine tatsächliche Abrufausgabe. Beziehen Sie zwischengeschaltete Caches und Suchindizes ein. Testen Sie veraltete Datensätze und ausgelaufene Produkte ebenso wie erfolgreiche Aktualisierungen.

Schließen Sie mit messbaren Abnahmekriterien ab: dem vereinbarten Aktualitätsfenster, den berechtigten Bearbeitern für jedes Feld, dem Verhalten bei der Wiederherstellung nach einem Ausfall und dem Prozess zur Prüfung betroffener Antworten. Diese Kriterien geben dem Team eine gemeinsame Definition davon, wann die Integration startbereit ist.

Probleme, die oft erst bei alltäglichen Änderungen sichtbar werden, beschreibt der Artikel 5 Probleme, auf die Sie stoßen könnten, wenn Sie Drupal mit Drittanbietersoftware integrieren.

Bereit loszulegen?

Eine klare Verantwortung für jedes Feld reduziert wiederholte Pflege und schützt die Arbeit, die Ihr Content-Team ergänzt. PIM und ERP bleiben für die freigegebenen Produktwerte verantwortlich, während Drupal diese Werte für Käufer nützlich macht und zulässigen maschinellen Konsumenten bereitstellt.

Bringen Sie eine Beispiel-Payload aus Ihrem PIM oder ERP und eine repräsentative Produktseite mit und sprechen Sie mit Droptica. Gemeinsam legen wir die Verantwortung für die Felder, die Synchronisierungsregeln und die Anreicherungsfelder in Drupal fest, die Ihre Käufer brauchen. So haben Sie einen praktischen Ausgangspunkt für die Integration. Mehr über unsere Arbeit erfahren Sie auf der Seite zu unseren Drupal-Entwicklungsdiensten.