Vom Grasshopper-Modell zum Web-Konfigurator: die Definition als Dienst

Ein Rechenknoten, der die Definition geladen hat, Parameter entgegennimmt und das Ergebnis zurückgibt: Geometrie in einem Austauschformat, dazu die Kennzahlen, die im Modell ohnehin berechnet werden. Fläche, Gewicht, Teilezahl, Verschnitt, Materialbedarf.

Der entscheidende Teil ist der zweite. Ein Konfigurator, der nur ein Bild liefert, ist eine Visualisierung. Einer, der zusätzlich die Stückliste und den Materialbedarf zurückgibt, ist ein Vertriebswerkzeug, und das ist der Unterschied, der ein solches Vorhaben trägt.

Die Definition bleibt dabei dieselbe Datei, mit der entworfen wird. Genau das ist der Punkt: es gibt keine zweite Nachbildung der Logik, die auseinanderlaufen kann.

Der übliche Weg zu einem Konfigurator führt über eine Neuimplementierung: Ein Entwicklungsteam bekommt die Regeln als Dokument beschrieben und baut sie in der Anwendung nach. Von diesem Tag an gibt es zwei Wahrheiten.

Sie laufen auseinander, und zwar leise. Der Entwurf bekommt eine neue Randbedingung, der Konfigurator nicht. Ein halbes Jahr später verkauft der Vertrieb eine Ausführung, die die Fertigung ablehnt, und niemand kann sagen, seit wann.

Mit der Definition als Dienst gibt es diese Klasse von Fehlern nicht. Eine Regeländerung im Entwurf ist eine Regeländerung im Verkauf, weil es dieselbe Regel ist.

Nicht jede Anfrage darf eine volle Berechnung auslösen. Bewährt hat sich eine Trennung in drei Stufen: eine sofortige Vorschau aus vorberechneten Zwischenständen, eine vollständige Berechnung auf Anforderung, und eine Ableitung der Fertigungsdaten erst nach der Auswahl.

Der Variantenraum wird dafür vorher abgetastet und die Ergebnisse werden abgelegt. Was ein Kunde im Browser bewegt, ist dann meistens eine Auswahl aus bekannten Ergebnissen und keine Live-Rechnung. Das ist der Unterschied zwischen einer Antwort in Millisekunden und einer in zwanzig Sekunden.

Für die Darstellung im Browser wird die Geometrie vereinfacht ausgeliefert. Wichtig ist, dass diese Vereinfachung automatisiert aus dem Konstruktionsmodell fällt und nicht von Hand gepflegt wird, sonst ist die zweite Wahrheit über die Hintertür wieder da.

Rechenzeit. Eine Definition, die im Entwurf zwanzig Sekunden braucht, braucht sie auch auf dem Server. Interaktiv ist das nicht. Entweder wird die Definition auf Geschwindigkeit hin überarbeitet, was oft möglich und selten beliebt ist, oder der Variantenraum wird vorberechnet.

Zustand. Entwurfsumgebungen halten Zustand zwischen Aufrufen. Ein Dienst, der viele Anfragen parallel bedient, darf das nicht. Definitionen, die sich auf zuletzt geladene Dateien oder Referenzobjekte verlassen, verhalten sich unter Last nicht reproduzierbar, und dieser Fehler tritt genau dann auf, wenn niemand zusieht.

Lizenzierung. Der Serverbetrieb einer Entwurfsumgebung ist lizenzrechtlich eine andere Frage als der Arbeitsplatzbetrieb. Das gehört vor die Architekturentscheidung und nicht danach, weil es das gesamte Betriebsmodell bestimmt.

Und Fehlerfälle. Eine unzulässige Parameterkombination darf keinen Serverfehler erzeugen, sondern muss eine begründete Ablehnung zurückgeben. Randbedingungen als Prüfungen im Modell zahlen sich hier ein zweites Mal aus.

Der gesamte Aufbau lässt sich im eigenen Haus betreiben. Das ist kein Randthema: eine Definition enthält die Konstruktionslogik eines Produkts, und für viele Hersteller ist genau das der Kern dessen, was nicht abfließen darf.

Wir bauen solche Dienste deshalb so, dass Rechenknoten, Ergebnisspeicher und Auslieferung in der Infrastruktur des Kunden stehen können, mit einer Schnittstelle als einziger Berührungsfläche nach außen.

Wenn dieselben Fragen mehrfach im Monat an dieselbe Person gehen. Wenn der Vertrieb Varianten verkaufen soll, die er selbst nicht durchrechnen kann. Wenn aus der Geometrie ohnehin Stücklisten oder Preise entstehen sollen.

Und nicht, wenn der Konfigurator vor allem hübsch sein soll. Ein 3D-Konfigurator ohne Kennzahlen dahinter ist eine Visualisierung mit Wartungsaufwand, und die gibt es billiger.