User Konzept

Ein registrierter API User entspricht dem Webserver, der die Webseite für den Konfigurator hostet/ausliefert (meist CMS oder Webshop). Dieser API User hat eine fixe IP und wird durch das Tupel {Apikey;Token;IP} identifiziert. Ein API User ist über mehrere Monate gültig (expire date) und kann mit der User-Verwaltung auf davitec.de auch jeweils verlängert werden.

Der API User kann durch Aufruf von /cli-credentials temporäre SessionUser initiieren. Der SessionUser entspricht dem Client und ist nicht an eine IP gebunden. Der SessionUser kann dann das Produktmodel initiieren und Nutzerentscheidungen treffen.

Registered API Users

Erstelle Dir zunächst einen Account auf https://www.davitec.de/dvConfig. Hier kannst Du jetzt im kostenfreien Modus bis zu 3 API User erzeugen.

Um einen neuen Nutzer zu erstellen, gib einen Projektnamen ein (lesbarer Bestandteil des ApiKeys) sowie eine IP Adresse (IPv4 or IPv6).

Vertippt, IP Adresse geändert? Du kannst API User jederzeit löschen und neu erzeugen.

Der registrierte API User ist zeitlich befristet. Du kannst die Registrierung ab 4 Wochen vor Ablauf verlängern.

Der registrierte API User hat nun von der angegebenen IP Adresse aus Zugriff auf die Ressource /cli-credentials, damit werden (IP unabhängige) SessionKeys erzeugt.

Session Users

Ein Session User wird vom Registered API User durch Aufruf von /cli-credentials erzeugt. Die Ressource legt einen SessionUser an und gibt den SessionKey zurück. Der Session User ist 60 Minuten gültig (API Settings).

Mit dem SessionKey ist man nun unabhängig von einer IP berechtigt, die Ressourcen von /product und /decision aufzurufen.

Praxis-Hinweis Front-End

Das User Konzept wurde mit Hinblick auf schnelle Reaktionszeit im Browser erstellt. Wir gehen davon aus, dass ein Webserver (Content Management System oder Webshop) mit fester IP die Session erzeugt und und dem Client ein Template sowie die SessionKey ausliefert. Der Client kann dann selbständig auf die API zugreifen, um Nutzerentscheidungen zu übermitteln und den Konfigurationszustand mit GET /product abzurufen. Wir haben umfangreiche Produktmodelle mit mehreren Tausend Features & Attributewerten sowie hunderten Constraints getestet und dabei 200 ms Gesamtreaktionszeit im Client festgestellt (Klick - Übermittlung der Entscheidung - Berechnung im RestService - Abruf Modell als Json). Die reine Rechenzeit für Konsequenzen von Nutzerentscheidungen liegt bei derart komplexen Modell unter 50ms.

In unserem BoilerPlate verwenden wir im FrontEnd AngularJS und stellen dort wichtige Komponenten für die Kommunikation des Clients mit Server (Settings, SessionKey) sowie der API (ApiUtility-Layer) bereit. Zudem haben wir dort im Ordner ServerCode einige php Funktionen (LoadSettings und InitProduct) bereitgestellt, die einfach in das CMS bzw. in den Webshop integriert werden können. Das BoilerPlate liefert das XML nicht an den Client aus.

Das XML-Produktmodell kann an den Client ausgeliefert werden, das initialisieren kann aber auch vom Server aus erledigt werden, so dass der Client keinen Zugriff auf das xml hat. Der Server kann ebenso das XML erst zum Zeitpunkt der initiierten Session aus einer Datenbank erzeugen, was eine große Flexibilität für den Einsatz von dvConfig zulässt.