// stack · schnittstelle
CADENAS steht für elektronische CAD-Produktkataloge — die Art, wie ein Industrieunternehmen seine Bauteile so bereitstellt, dass Konstrukteure sie konfigurieren und als 2D- oder 3D-Modell in ihr CAD-System übernehmen. Für siteway ist das eine Aufgabe mit zwei Ebenen: Die Produktseite gehört der Website, die CAD-Ebene gehört dem Katalog. Diese Seite beschreibt, wie wir beides zusammenbringen — und warum ein CAD-Download im Maschinenbau ein echter Lead ist.
// definition
CADENAS ist ein Softwarehersteller aus Augsburg für elektronische CAD-Produktkataloge und strategisches Teilemanagement. Hinter dem Namen steht die CADENAS GmbH in der Schernecker Straße in Augsburg, eingetragen beim Amtsgericht Augsburg. Gegründet wurde das Unternehmen 1992; 2025 wurde es Teil der KEYENCE-Gruppe.
Das Angebot zeigt in zwei Richtungen. Für Komponentenhersteller nennt CADENAS die Lösung eCATALOGsolutions, inzwischen auch als eCATALOG 3Dfindit geführt — laut Hersteller eine Softwarelösung zur Erstellung und Vermarktung von elektronischen CAD-Produktkatalogen. Für Konstruktion und Einkauf steht PARTsolutions beziehungsweise ENTERPRISE 3Dfindit für das Verwalten und Finden von Norm-, Kauf- und Eigenteilen. Dazu kommen die Portale 3Dfindit.com und PARTcommunity sowie BIMcatalogs.net für Architektur und Bauwesen.
Das Prinzip dahinter ist ein Single-Source-Ansatz: Die Produktdaten liegen in einer zentralen Datenbank, und daraus bedient der Katalog verschiedene Ausgabekanäle — der Hersteller nennt unter anderem Web, PDF, gedruckten Katalog und App. Der Web-Kanal ist damit einer von mehreren, und genau er ist der, an dem eine Website andockt.
Für eine Website zählt vor allem eine Angabe des Herstellers: Die digitalen Daten der Komponenten stehen über eCATALOGsolutions auf der eigenen Website zum Download bereit, und das Downloadportal lässt sich an das Corporate Design anpassen. Damit ist der CAD-Download keine Fremdadresse mehr, auf die man verlinkt, sondern ein Bestandteil des eigenen Auftritts — und eine Schnittstelle, um die herum sich bauen lässt.
// praxis
produktseite im cms · cad im katalog
Die wichtigste Entscheidung fällt vor der ersten Zeile Code, und sie betrifft die Aufteilung: Die Produktseite gehört der Website, die CAD-Ebene gehört dem Katalog. Für jedes Produkt oder jede Baureihe entsteht eine eigene Seite im CMS — mit Beschreibung, Anwendungsfällen, technischen Eckdaten als Tabelle, Bildern und Datenblatt. In diese Seite kommt die Katalogoberfläche dort hinein, wo der Konstrukteur konfiguriert und herunterlädt. Die Website liefert den Inhalt und die Auffindbarkeit, der Katalog die Varianten und die CAD-Daten. Beides zusammen ergibt eine Seite, die trägt.
Am Anfang steht deshalb keine Programmierung, sondern eine Klärung. Was liefert das gebuchte Katalogprodukt — nur die Oberfläche, oder auch Produktstruktur und Stammdaten in einer maschinenlesbaren Form? Unter welcher Adresse läuft die Oberfläche? Lässt sich gezielt auf eine Baureihe verlinken? Diese Punkte hängen vom konkreten Vertrag mit CADENAS ab und werden gemeinsam mit dem Hersteller festgelegt, bevor gebaut wird. Wir schreiben nichts auf eine Produktseite, was wir nicht am konkreten Katalog geprüft haben.
Steht das fest, spiegeln wir die Produktstruktur im festen Takt in das CMS: Baureihen, Kategorien, Bezeichnungen, Produktnummern. Die Produktnummer ist dabei der Schlüssel — über sie erkennt der zweite Lauf ein Produkt wieder und aktualisiert es, statt eine Dublette anzulegen, und über sie zeigt der Deep-Link später auf die richtige Stelle im Katalog. Woher diese Daten kommen, ist eine Frage des Projekts: aus dem Katalogsystem, aus einem vorgelagerten PIM oder ERP, oder aus redaktioneller Pflege. Bilder und Datenblätter ziehen wir auf den eigenen Server und schicken sie durch dieselbe Bildpipeline wie den Rest der Website — skaliert, als AVIF und WebP, mit Maßen im Markup.
Dann kommt die Einbettung selbst — und die ist mehr Handwerk, als es klingt. Sie bekommt einen eigenen Container mit definiertem Verhalten: kein horizontales Scrollen auf dem Telefon, eine nachvollziehbare Fokusreihenfolge zwischen Seite und Oberfläche, ein Ladeverhalten, das die Seite nicht ausbremst, und eine Überschrift darüber, die erklärt, was gleich passiert. Dazu die Wege in beide Richtungen: von der Produktseite gezielt in die passende Baureihe hinein, und aus dem Katalogergebnis zurück in die Anfragestrecke der Website.
Neben dem Download steht die Anfrage. Wer ein Modell herunterlädt, hat Interesse; wer eine Frage zur Auslegung hat, soll sie an derselben Stelle stellen können — mit Produkt und Baureihe vorbelegt, damit im Vertrieb sofort klar ist, worum es geht. Nachvollziehbarkeit bauen wir auf beiden Seiten: Auf der Website messen wir, was ohne Personenbezug messbar ist — Aufruf der Produktseite, Öffnen des Katalogs, abgeschickte Anfrage. CADENAS nennt für den Herstellerkatalog eigene Statistik- und Analysefunktionen; wie sich beide Bilder zusammenführen lassen, gehört in dieselbe Klärung wie alles andere.
Und schließlich das, was in Angeboten gern fehlt: der Fehlerfall. Antwortet die eingebettete Oberfläche nicht oder wird sie mangels Einwilligung gar nicht erst geladen, bleibt die Produktseite vollständig lesbar — Text, Eckdaten, Datenblatt, Kontakt. Der Katalog ist ein Baustein der Seite, nicht ihre Existenzgrundlage. Dieselbe Sorgfalt gilt für den Rückweg: Geht eine Anfrage nicht durch, wird sie zwischengespeichert, erneut versucht und geht zusätzlich per E-Mail ans Team. Details dazu in der Leistung Schnittstellenentwicklung.
// technik · 6 details
belegt aus herstellerangaben
Ein Hinweis zur Quellenlage, weil er die ganze Seite betrifft: Was hier steht, stammt aus den öffentlichen Angaben von CADENAS. Eine frei zugängliche Entwickler-Dokumentation mit Adressen und Parametern gibt es dazu nicht. Deshalb beschreiben wir den Weg bewusst allgemein und benennen an jeder Stelle, was vorab zu klären ist. Der konkrete Weg hängt vom gebuchten Katalogprodukt ab — und wird vor der Umsetzung mit dem Hersteller und mit CADENAS festgelegt, nicht geraten.
// d-01klärung
Der erste Schritt ist eine Liste von Fragen, keine Implementierung: Kommt nur die Oberfläche, oder auch Produktstruktur und Stammdaten maschinenlesbar? Unter welcher Adresse läuft die Oberfläche? Ist ein gezielter Einstieg in eine Baureihe möglich? Welche Auswertungen stehen bereit? Die Antworten hängen vom gebuchten Produkt ab und werden gemeinsam mit CADENAS geklärt.
zweck: grundlage schaffen
// d-02daten
Baureihen, Kategorien, Bezeichnungen und Produktnummern gehören in das Datenmodell des CMS — als eigene Inhaltsart mit eigenen Feldern, eigener Adresse und eigener Sortierung. Die Produktnummer ist der Schlüssel für den wiederholten Abgleich und für den Deep-Link. Bilder und Datenblätter liegen danach auf der eigenen Domain und nicht auf einer fremden.
zweck: eigene produktebene
// d-03katalog
Das ist die Ebene, die der Katalog besser kann als jedes selbstgebaute Frontend. Als Bestandteile von eCATALOGsolutions nennt CADENAS unter anderem Multi-CAD- und Multi-CAE-Daten, eine interaktive 3D-Visualisierung, einen Produktkonfigurator für technische Produkte und ein 3D-PDF-Datenblatt. Der Nutzer wählt die Variante und bekommt am Ende sein Modell.
zweck: varianten & ausleitung
// d-04formate
Für die Suchmaschine 3Dfindit gibt CADENAS 3D-CAD-Daten in über 150 nativen und neutralen CAD- und Grafikformaten an und nennt als Beispiele Autodesk Revit, Nemetschek ALLPLAN, ArchiCAD, Autodesk Inventor, NX, Solid Edge, PTC Creo Parametric, AutoCAD, CATIA und SOLIDWORKS. Welche Formate ein konkreter Katalog ausspielt, ist eine Frage seiner Konfiguration — und deshalb nichts, was wir ungeprüft auf eine Produktseite schreiben.
zweck: nur belegtes nennen
// d-05einbettung
CADENAS gibt an, dass die digitalen Daten der Komponenten auf der eigenen Website zum Download bereitstehen, dass sich das Downloadportal nahtlos an das Corporate Design anpassen lässt und dass sich ein bestehender eShop oder ein CRM-System anschließen lässt. Wie das im Einzelfall technisch umgesetzt wird, gehört in die Klärung — die Umgebung drumherum bauen in jedem Fall wir.
zweck: ein auftritt statt zwei
// d-06kanäle
Der Hersteller beschreibt einen Single-Source-Ansatz: Die Produktdaten liegen zentral, und daraus werden verschiedene Ausgabemedien bedient — genannt werden unter anderem Web, PDF, gedruckter Katalog und App. Für uns ist das eine nützliche Einordnung. Die Website bedient den Web-Kanal, macht aus ihm aber eigene Seiten statt eines Fensters in ein fremdes System.
zweck: einordnung
Im Maschinenbau ist der Download eines CAD-Modells keine Beschaffung von Informationsmaterial, sondern eine Vorentscheidung. Wer ein Bauteil in seine Konstruktion einsetzt, hat sich damit gedanklich für den Hersteller entschieden — Anschlussmaße, Bauraum und Umgebungsgeometrie richten sich anschließend nach diesem Teil. Ein Wechsel danach kostet Konstruktionszeit. Genau deshalb ist der Weg zum Modell so wichtig, und genau deshalb ist er eine Aufgabe der Website und nicht nur des Katalogs.
Die Website unterstützt diesen Weg an drei Stellen. Sichtbarkeit: Der Konstrukteur muss die Produktseite überhaupt finden — über die Suche, über die Katalogstruktur der Website, über einen Fachbegriff, den er kennt. Übergabe: Von der Produktseite in den Katalog darf keine Sackgasse werden — kein blinder Einstieg auf der Startseite eines Portals, sondern der gezielte Sprung in die richtige Baureihe. Nachvollziehbarkeit: Was auf der Seite passiert, sollte messbar sein, ohne dass dafür personenbezogene Daten nötig werden — und die Anfrage daneben sollte im Vertrieb ankommen, mit Kontext.
Hier liegt die Entscheidung, die im Industrieumfeld am häufigsten falsch getroffen wird. Liegen alle Produktdaten ausschließlich in einer eingebetteten Fremdoberfläche, hat die eigene Website an dieser Stelle wenig eigenen, indexierbaren Inhalt — die Substanz ist da, aber sie gehört dem Katalog. Deshalb entstehen bei uns eigene Produktseiten im CMS: Beschreibung, Anwendungsfälle, technische Eckdaten als Tabelle, Datenblatt und strukturierte Daten aus denselben Feldern, dazu eine dauerhafte, sprechende Adresse und eine Regel für Produkte, die aus dem Sortiment fallen.
Das ist ausdrücklich kein Argument gegen die Einbettung. Ein Konfigurator, der aus Maßen und Optionen ein exaktes Modell in Dutzenden CAD-Formaten erzeugt, ist eine erhebliche Leistung, und niemand sollte versuchen, sie im CMS nachzubauen. Die beiden Ebenen haben schlicht verschiedene Aufgaben: Die CMS-Ebene sorgt dafür, dass jemand die Seite findet und versteht. Die Katalogebene sorgt dafür, dass er mit dem richtigen Modell wieder herausgeht. Wer beides bewusst trennt, bekommt beides. Wer es dem Zufall überlässt, verliert meist die erste Hälfte.
Zwei Themen ziehen sich quer durch: Mehrsprachigkeit und Betrieb. Ein Herstellerkatalog ist selten einsprachig, und die Produktseiten daneben sollten es dann auch nicht sein — mit sauberer Sprachzuordnung, eigenen Adressen je Sprache und einer Redaktion, die weiß, welche Felder aus dem Abgleich kommen und welche sie selbst pflegt. Wie wir das aufsetzen, steht bei Mehrsprachigkeit; was daneben als eigene Komponente gebaut wird, bei Download & Mediathek und Konfiguratoren.
Beim Datenschutz gibt es zwei Punkte, die früh auf den Tisch gehören. Erstens: Verlangt der Download eine Registrierung, werden personenbezogene Daten erhoben — dann gelten Datensparsamkeit, eine benannte Zweckbindung, eine nachvollziehbar dokumentierte Einwilligung und festgelegte Löschfristen, genau wie bei jedem anderen Formular. Zweitens: Eine eingebettete Fremdoberfläche lädt von einer fremden Stelle, und dieser Aufruf gehört sauber in die Consent-Behandlung der Website — mit einer verständlichen Vorschaltung statt eines stillen Nachladens. Dazu kommen der Auftragsverarbeitungsvertrag und der Eintrag in der Datenschutzerklärung. Das ist keine Rechtsberatung, sondern eine Arbeitsliste; mehr dazu im Stack unter Sicherheit & Datenschutz.
// integration
drei systeme · ein muster
Der Weg ist in allen Systemen derselbe, weil die Arbeitsteilung dieselbe ist: Die Produktdaten und die Katalog- beziehungsweise Konfiguratoroberfläche kommen aus dem System — die Einbettung und das Drumherum baut die Website. Im CMS liegt alles, was Inhalt ist und gefunden werden soll: die Produktseite selbst, ihre Beschreibung, die Anwendungsfälle, die technischen Eckdaten als Tabelle, Bilder, Datenblatt, Übersetzungen, strukturierte Daten und die dauerhafte Adresse. Aus dem Katalog kommt, was die CAD-Ebene ausmacht: die Varianten, die Konfiguration über Maße und Optionen und die Ausleitung der 2D- und 3D-Modelle in die Formate, die der Konstrukteur braucht.
Daraus ergibt sich in jedem CMS dieselbe Kette. Ein geplanter Lauf hält die Produktstruktur nach — Baureihen, Bezeichnungen, Produktnummern —, die Produktnummer dient als Schlüssel für den wiederholten Abgleich, und ein eigenes Element im Editor setzt die Katalogoberfläche dorthin, wo die Redaktion sie haben will. Ausgeliefert wird aus dem eigenen Bestand, also aus Cache oder statisch erzeugten Seiten; die Oberfläche lädt erst, wenn sie gebraucht wird und die Einwilligung dafür vorliegt. Welches CMS darunter arbeitet, ändert an dieser Mechanik nichts — nur daran, wo die Produktseiten liegen und womit die Redaktion sie pflegt.
// cms-01typo3
Im Industrieumfeld ist TYPO3 oft gesetzt — mehrsprachige Auftritte, viele Redakteure, feine Rechte. Die Anbindung bauen wir als eigene Extension: Das TCA beschreibt die Inhaltsart „Produkt“ mit genau den Feldern aus dem Mapping, die Produkte liegen als Records in einem Systemordner, Bilder und Datenblätter in FAL. Der Abgleich der Produktstruktur läuft als Scheduler-Task. Die Katalogeinbindung wird ein eigenes Content-Element, das die Redaktion auf der Produktseite platziert und mit der Baureihe verknüpft. Sprechende Adressen kommen aus dem Site Handling, gerendert wird über Fluid, Zugangsdaten stehen in der Extension-Konfiguration und nie im Repository.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so überlebt sie jeden Theme-Wechsel. Die Produkte werden ein Custom Post Type mit Meta-Feldern für die technischen Angaben und Taxonomien für Kategorie und Baureihe. Ein geplanter Lauf hält die Stammdaten nach und erkennt bestehende Produkte an der Produktnummer wieder. Für die Katalogeinbindung kommt ein eigener Block für den Editor dazu, alternativ ein Shortcode für ältere Inhalte; beide bekommen die Baureihe als Parameter. Zugangsdaten stehen als Konstante in der wp-config.php und nie im Frontend.
// cms-03statamic
Statamic läuft auf Laravel — das macht den Datenweg besonders geradlinig. Ein Blueprint beschreibt das Produkt, die Produkte liegen als Entries in einer eigenen Collection, Bilder und Datenblätter als Assets im eigenen Container. Ein Artisan-Command holt die Produktstruktur und schreibt sie fort, der Laravel-Scheduler bestimmt den Takt. Antlers oder Blade rendern Produktseite, Eckdatentabelle und die Katalogeinbindung; Static Caching liefert das Ergebnis aus. Zugangsdaten liegen in der .env. Im Control Panel pflegt die Redaktion die Felder, die der Abgleich nicht anfasst.
// entscheidung
zuordnung statt rangliste
Fast jede Diskussion über einen CAD-Katalog auf der eigenen Website endet bei dieser einen Frage. Sie hat keine grundsätzliche Antwort, sondern eine pro Information: Was ist Inhalt, den jemand lesen und finden können soll — und was ist eine technische Ausleitung, die aus Varianten entsteht? An drei Mustern lässt sich das zuordnen.
// e-01cms
Bezeichnung, Beschreibung, Anwendungsfälle, Baureihe, Kategorie, Bilder, Datenblätter, technische Eckdaten: Das sind Inhalte, keine Ausleitungen. Sie gehören ins CMS, bekommen eine dauerhafte Adresse und strukturierte Daten. So bleibt die Seite auffindbar, lesbar und redaktionell ergänzbar — auch dann, wenn die Katalogoberfläche gerade nicht lädt.
inhalt · fester takt
// e-02katalog
Varianten über Maße und Optionen, die Regeln dahinter, die interaktive 3D-Ansicht und die Ausleitung des fertigen Modells in das Format des jeweiligen CAD-Systems: Das ist die Kernleistung des Katalogs. Sie im CMS nachzubauen, wäre eine schlechte Idee — hier bindet die Website ein, statt selbst zu rechnen.
varianten · cad-ausleitung
// e-03kombination
Der Regelfall: eine Produktseite aus dem CMS, in der die Katalogoberfläche sitzt, ein Deep-Link, der gezielt in die passende Baureihe führt, und eine Anfragestrecke direkt daneben. Eine Ebene für den Inhalt, eine für die Konfiguration — und ein einziger Auftritt, in dem der Nutzer nicht merkt, dass zwei Systeme beteiligt sind.
inhalt + konfiguration
Fünf Fragen entscheiden die Richtung, und sie lassen sich in einem Gespräch beantworten. Welches Katalogprodukt ist gebucht, und was liefert es außer der Oberfläche? Wie viele Baureihen soll die Website als eigene Seiten führen, und wer pflegt deren Texte? Kommen die Stammdaten aus dem Katalogsystem oder aus einem vorgelagerten System? Ist ein gezielter Einstieg in eine Baureihe möglich, oder landet der Nutzer immer auf der Startseite des Portals? Und verlangt der Download eine Registrierung — wenn ja, wer verarbeitet die dabei entstehenden Daten?
Danach steht die Aufteilung als Dokument, bevor gebaut wird. Dieselbe Logik greift bei den Nachbarsystemen: Ein PIM ist die saubere Quelle, wenn Produktdaten aus mehreren Systemen zusammenlaufen, SAP bringt die kaufmännische Seite mit. Welche Anbindung ein Projekt bekommt, klären wir im Konzept — vor dem Bauen, mit Begründung.
// faq
CADENAS ist ein Softwarehersteller aus Augsburg, der elektronische CAD-Produktkataloge und strategisches Teilemanagement anbietet. Hinter dem Namen steht die CADENAS GmbH mit Sitz in der Schernecker Straße in Augsburg, eingetragen beim Amtsgericht Augsburg; gegründet wurde das Unternehmen 1992, 2025 wurde es Teil der KEYENCE-Gruppe. Für Komponentenhersteller nennt CADENAS die Lösung eCATALOGsolutions, inzwischen auch als eCATALOG 3Dfindit geführt, als Softwarelösung zur Erstellung und Vermarktung von elektronischen CAD-Produktkatalogen. Für Konstruktion und Einkauf steht PARTsolutions beziehungsweise ENTERPRISE 3Dfindit für das Verwalten und Finden von Norm-, Kauf- und Eigenteilen. Dazu kommen die Portale 3Dfindit.com und PARTcommunity sowie BIMcatalogs.net für Architektur und Bauwesen.
Ein elektronischer CAD-Produktkatalog ist die digitale Ausgabe eines Bauteilsortiments für Konstrukteure. Statt eines PDF zum Blättern bekommt der Nutzer eine Oberfläche, in der er eine Baureihe auswählt, die Variante über Maße und Optionen bestimmt und das fertige Bauteil als 2D-Zeichnung oder 3D-Modell im Format seines CAD-Systems herunterlädt. Für den Hersteller liegt der Nutzen darin, dass sein Bauteil unmittelbar in fremde Konstruktionen wandert. Für die Website heißt das: Der Katalog ist eine eigene Ebene neben den Produktseiten und kein Ersatz für sie.
Ja. CADENAS gibt an, dass die digitalen Daten der Komponenten über eCATALOGsolutions auf der eigenen Website zum Download bereitstehen und dass sich das Downloadportal nahtlos an das Corporate Design anpassen lässt; ebenso nennt der Hersteller die Möglichkeit, einen bestehenden eShop oder ein CRM-System anzuschließen. Wie die Einbettung im Einzelfall technisch aussieht, hängt vom gebuchten Katalogprodukt ab und wird vor der Umsetzung geklärt. Unsere Arbeit liegt um die Einbettung herum: die Produktseite, in der sie sitzt, die Adresse, unter der sie läuft, der Deep-Link von der Produktseite auf die richtige Baureihe, das Verhalten auf kleinen Bildschirmen und der Fall, dass die Oberfläche einmal nicht antwortet.
Das entscheidet der jeweilige Katalog, nicht die Website. Für die Suchmaschine 3Dfindit nennt CADENAS 3D-CAD-Daten in über 150 nativen und neutralen CAD- und Grafikformaten und führt als Beispiele Autodesk Revit, Nemetschek ALLPLAN, ArchiCAD, Autodesk Inventor, NX, Solid Edge, PTC Creo Parametric, AutoCAD, CATIA und SOLIDWORKS an. Welche Formate ein konkreter Herstellerkatalog tatsächlich ausspielt, ist eine Frage seiner Konfiguration und gehört in die Klärung vor dem Projekt. Auf eine Produktseite schreiben wir keine Formatliste, die wir nicht am konkreten Katalog geprüft haben.
Sie schadet nicht, sie trägt an dieser Stelle nur nichts bei. Liegt der gesamte Produktinhalt in einer eingebetteten Fremdoberfläche, hat die eigene Website dort wenig eigenen, indexierbaren Text. Deshalb bauen wir die Produktebene im CMS: eine Seite je Produkt oder Baureihe mit Beschreibung, Anwendungsfällen, technischen Eckdaten als Tabelle, Bildern, Datenblatt und strukturierten Daten, dazu eine dauerhafte, sprechende Adresse. Der Katalog übernimmt daneben die CAD-Ebene, also Varianten, Konfiguration und Download. Beide Ebenen haben ihre Aufgabe, und sie kommen sich nicht in die Quere, solange die Aufteilung von Anfang an bewusst getroffen wird.
Eine frei zugängliche Entwickler-Dokumentation ist öffentlich nicht auffindbar. CADENAS beschreibt auf den Herstellerseiten, was die Katalogprodukte leisten, veröffentlicht dort aber keine offene technische Referenz mit Adressen und Parametern. Deshalb beschreiben wir den Weg auf dieser Seite bewusst allgemein und erfinden keine technischen Details. Was im Einzelfall gilt — Art der Einbettung, Form der Datenlieferung, Deep-Links, Adressen und Auswertung —, hängt vom gebuchten Katalogprodukt ab und wird vor der Umsetzung mit dem Hersteller und mit CADENAS geklärt. Erst danach steht fest, was die Website selbst übernimmt und was aus dem Katalog kommt.
Ja, und in allen drei Systemen nach demselben Muster. Die Produktdaten und die Katalogoberfläche kommen aus dem Katalogsystem, die Produktseiten und die Einbettung baut die Website. In TYPO3 entsteht dafür eine eigene Extension: Produktseiten als Records mit den Feldern aus dem Mapping, die Katalogeinbindung als Content-Element, sprechende Adressen über das Site Handling, gerendert mit Fluid. In WordPress entsteht ein eigenes Plugin statt Theme-Code, mit einem Custom Post Type für die Produkte, einem Block beziehungsweise Shortcode für die Katalogeinbindung und einem geplanten Lauf für die Stammdaten. In Statamic liegt Laravel darunter: eine Collection mit Blueprint für die Produkte, ein Artisan-Command im Scheduler und Antlers oder Blade für die Einbindung. Die Mechanik bleibt dieselbe, nur der Ort, an dem die Produktseiten liegen, ist ein anderer.
Sobald für den Download personenbezogene Daten erhoben werden, gelten dieselben Regeln wie für jedes andere Formular: nur die Felder abfragen, die wirklich gebraucht werden, den Zweck benennen, die Einwilligung nachvollziehbar dokumentieren, Löschfristen festlegen. Die eingebettete Fremdoberfläche kommt hinzu. Sie lädt von einer fremden Stelle, und dieser Aufruf gehört sauber in die Consent-Behandlung der Website — mit einer verständlichen Vorschaltung statt eines stillen Nachladens im Hintergrund. Dazu gehören ein Auftragsverarbeitungsvertrag mit dem Anbieter und ein Eintrag in der Datenschutzerklärung. Das ist keine Rechtsberatung, sondern die Liste der Punkte, die im Projekt abgearbeitet wird.
// womit das zusammenhängt
systeme, komponenten & leistung
// stack · schnittstelle
Die Quelle davor: Wo Produktdaten aus mehreren Systemen zusammenlaufen, bevor sie auf die Website und in den Katalog gehen.
zur technik →
// stack · schnittstelle
Die kaufmännische Seite daneben: Artikelstamm, Preise und Verfügbarkeit — und die Frage, was davon auf die Website gehört.
zur technik →
// stack · frontend
Was die Produktseite maschinenlesbar macht — aus denselben Feldern, die auch die Eckdatentabelle füllen.
zur technik →
// leistung · komponente
Die buchbare Komponente auf der CMS-Seite: Liste mit Facettenfilter, Produktdetailseiten und Anfrage statt Kasse.
zur leistung →
// leistung · komponente
Für alles neben den CAD-Daten: Datenblätter, Zertifikate und Anleitungen mit Kategorien, Versionierung und Zugriffsregeln.
zur leistung →
// leistung · buchen
Die Technik hier, das Angebot dort: Analyse, Mapping, Umsetzung, Monitoring und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
// CAD-Downloads auf deiner Website?
Projekt anfragen