Technik
Die kaufmännische Logik liegt im SQL Server – dort, wo sie seit dem Jahr 2000 liegt und wo sie geprüft ist. Darüber sitzen Schichten, die sich getrennt vervielfältigen, tauschen und überwachen lassen. Diese Seite geht so tief, wie es für eine Entscheidung nötig ist.
Der Weg einer Anfrage
Wer im Browser auf „Speichern“ drückt, löst eine Kette aus, in der jede Station eine klare Aufgabe hat. Auf dem Weg dorthin reist kein SQL mit: Browser, App und Fremdsystem sprechen ausschließlich HTTPS und rufen benannte Endpunkte auf. Erst hinter dieser Grenze, im REST-Server, entsteht die Abfrage – die kaufmännische Arbeit macht weiterhin der SQL Server. Eine Oberfläche kann also gar keine Abfrage formulieren, und untergeschobenes SQL kommt nicht bis zur Datenbank.
Warum diese Aufteilung
Preisfindung, Rabattstaffeln, Lagerbewegungen und Belegwandlung sind in Prozeduren und Sichten gekapselt. Das ist der Grund, warum die Weboberfläche rechnerisch dieselben Ergebnisse liefert wie der Windows-Client: Sie rechnet nicht selbst, sie fragt an.
Geocoding und Routenberechnung, TSE für die Kassen, ein GPS-Treiber für Ortungsdaten. Diese Dienste stehen im LAN neben der Datenbank, weil sie entweder Hardware brauchen oder viele kleine Anfragen erzeugen.
Nimmt JSON entgegen, prüft Token und Rechte, ruft die Datenbank, gibt JSON zurück. Ein bis acht Instanzen hinter einem Balancer, je Instanz bis zu 64 Arbeitsprozesse – acht sind in der Praxis der vernünftige Wert. Ausser dem TSE-Dienst arbeitet alles in 64 Bit.
Ein HTML-Bestand, drei Betriebsarten: im Browser, als Windows-Fenster mit WebView2, als installierte App auf Tablet und Telefon. Der Seitencode kennt den Unterschied nicht – das ist Sache genau einer Weiche.
Sicherheit
Der REST-Server nimmt keine SQL-Anweisungen entgegen. Es gibt keinen Parameter, in den man eine Abfrage schmuggeln könnte, weil keine Abfrage durchgereicht wird. Angriffe dieser Familie laufen ins Leere – nicht, weil sie gefiltert werden, sondern weil das Einfallstor fehlt.
POST /api/v1/addresses Authorization: Bearer … Content-Type: application/json { "match": "EISENHANDLUNG", "name1": "Eisenhandlung GmbH", "street": "Röderstraße 42", "zip": "65183", "city": "Wiesbaden", "country":"DE" }
Feldnamen sind englisch und stabil. Was der Server daraus macht – welche Tabelle, welche Prozedur, welche Prüfung – bleibt seine Sache und kann sich ändern, ohne dass ein Aufrufer bricht.
Die Schnittstelle
Die Oberfläche benutzt keine Abkürzung. Sie spricht dieselbe Schnittstelle, die auch Ihrem Shop, Ihrem Skript oder Ihrem Dienstleister offensteht. Wer sehen will, was möglich ist, klickt sich durch die interaktive Referenz.
Stammdaten lassen sich über changedSince nachziehen, gelöschte Sätze über eine eigene Liste abgleichen. Wer täglich synchronisiert, holt nicht jedes Mal alles.
Jede Antwort hat denselben Umschlag: gelungen oder nicht, Nutzlast, Fehlertext. Aufrufer müssen nicht je Route raten.
Was zu lange dauert, wird zum Hintergrund-Lauf mit Zustand, Fortschritt, Abbruch und Wiederanlauf. Der Aufrufer holt das Ergebnis später ab.
Reicht ein Server nicht mehr, kommt der zweite dazu. Der Balancer verteilt, die Datenbank bleibt die eine. Der Pilotbetrieb läuft derzeit mit mehreren hundert Geräten.
Sitzungen liegen nicht nur im Arbeitsspeicher, sondern werden in der Mandanten-Datenbank festgehalten. Ein Update kostet deshalb keine neue PIN-Eingabe an hundert Tablets.
Je Mandant eine Subdomain, dahinter ein eigener Zugang und eine eigene Datenbank. Geräte- und Anmelde-Token gelten ausschliesslich unter ihrem Mandanten – ein Token aus Haus A öffnet in Haus B gar nichts.
Ohne Konfigurationsdatei bleibt alles einmandantig; die Fähigkeit schaltet man zu, sie drängt sich nicht auf.
Ein Plugin meldet dem Server, welche Routen es mitbringt, und der Client bekommt daraus Menüpunkte, Kacheln und Aktionen. Weil das dynamisch geschieht, muss für eine neue Anbindung niemand die Suite neu bauen.
Angebunden werden kann alles, was REST oder GraphQL spricht – und serverseitig EDIFACT, ARIBA oder ein Gateway mit AS2 und SFTP.
Ein DATANORM-Import mit hunderttausend Artikeln passt in keine HTTP-Anfrage. Solche Vorgänge laufen in einem eigenen Arbeitsbereich des Servers weiter, auch wenn der Browser längst geschlossen ist.
Der Fortschritt steht in der Datenbank – deshalb sieht ihn auch der Kollege am anderen Standort.
Voraussetzungen
Nichts Exotisches. Wer heute EULANDA betreibt, hat das Meiste bereits stehen.
Wir reden gern mit Ihrer IT statt nur mit dem Einkauf. Sicherungskonzept, Netztrennung, Zertifikate, Lastverteilung – alles besprechbar.
