max.dash ist ein read-only Operations-Cockpit für JTL-Fulfillment-Dienstleister (3PL) im DACH-Raum. Wir lesen die JTL-WaWi (eazybusiness) rein lesend und liefern SLA-Reporting pro Mandant, Versandleistung pro Mitarbeiter, ein mandantengetrenntes Kundenportal und Abrechnungs-Mengen-Export - ohne Systemwechsel.
- Die eazybusiness-Datenbank läuft auf einem MS-SQL-Server - für Reporting reicht ein reiner Lesezugriff.
- Ein Datenbank-Benutzer mit der Rolle db_datareader kann technisch nichts schreiben, ändern oder löschen.
- Kein Plugin, keine Worker-Änderung, kein Eingriff in dein Produktivsystem.
- Der Lesezugriff ist der leichte Teil - die eigentliche Arbeit steckt in der Fachlogik dahinter.
Die eazybusiness-Datenbank ist ein normaler MS-SQL-Server
Hinter jeder JTL-WaWi-Installation steckt eine eazybusiness-Datenbank auf Microsoft SQL Server. Das ist eine gewöhnliche, weit verbreitete Datenbanktechnologie mit einem seit Jahrzehnten etablierten Rechtesystem - kein JTL-Sonderweg. Für Reporting-Zwecke wird aus dieser Datenbank nur gelesen: Aufträge, Versanddaten, Artikel, Lagerbestände. Es muss nichts zurückgeschrieben werden, damit eine Auswertung entsteht. Genau deshalb lässt sich der Zugriff so einschränken, dass Schreiben technisch gar nicht erst möglich ist - unabhängig davon, welches Tool sich verbindet oder welche Abfrage läuft.
Einen sicheren, rein lesenden Datenbank-Benutzer anlegen
Der saubere Weg braucht keine exotische Konfiguration, sondern folgt einem Standardmuster, das jeder Datenbank-Administrator kennt:
- Ein eigener, neuer Benutzer wird für den Reporting-Zugriff angelegt - nicht der Benutzer, mit dem JTL selbst auf die Datenbank zugreift.
- Diesem Benutzer wird auf der eazybusiness-Datenbank ausschließlich die feste Datenbankrolle db_datareader zugewiesen. Diese Rolle erlaubt SELECT-Abfragen und sonst nichts.
- Rollen wie db_datawriter, db_owner oder Serverrollen mit weitergehenden Rechten werden bewusst nicht vergeben.
- Der Benutzer erhält Zugriff nur auf die eine benötigte Datenbank, nicht auf den gesamten SQL-Server.
Mit dieser Einstellung kann der Benutzer per Definition keine Zeile einfügen, ändern oder löschen und keine Tabellenstruktur verändern. Das ist keine Frage von Vertrauen oder Sorgfalt beim Abfragen - die Berechtigung dafür existiert auf Datenbankebene schlicht nicht. Ein falsch geschriebenes Skript, ein Bug im Reporting-Tool oder ein kompromittiertes Passwort kann in diesem Rahmen keinen Schaden an den Daten anrichten, weil der Schreibpfad fehlt.
Ein Benutzer mit ausschließlich db_datareader kann lesen, was er sehen darf - und nichts davon verändern. Das ist der ganze Trick, und er ist so alt wie relationale Datenbanken selbst.
Warum kein Plugin und keine Worker-Änderung nötig sind
Weil der Zugriff auf Datenbankebene passiert, muss nichts in der JTL-WaWi-Anwendung selbst installiert oder verändert werden. Es gibt keine Erweiterung, die im Warenwirtschaftssystem aktiviert wird, keinen Eingriff in JTL-Worker-Prozesse und keine Anpassung an bestehenden Abläufen. Die WaWi läuft exakt so weiter wie bisher - Mitarbeiter arbeiten unverändert damit, Updates und Patches von JTL laufen unabhängig davon. Der Lesezugang liegt komplett außerhalb der Anwendung, auf der Datenbank darunter. Das ist der Grund, warum ein Reporting-Projekt in der Regel ohne Downtime und ohne Rückstimmung mit dem Software-Hersteller auskommt.
Der ehrliche Pivot: Der Zugriff ist der leichte Teil
An dieser Stelle ist Ehrlichkeit angebracht: Einen read-only-Benutzer mit db_datareader anzulegen, ist eine Sache von Minuten für jeden, der schon einmal mit SQL Server gearbeitet hat. Das ist nicht das, was ein Reporting-Projekt aufwendig macht. Aufwendig - und eigentlich wertvoll - ist das, was danach kommt:
- SLA-Definition pro Mandant. Cutoff-Zeiten, Werktage, Feiertage und Ausschlüsse (Rückhalte, Storno, Backorder) müssen einmal sauber je Mandant modelliert werden, sonst rechnet die Quote am Vertrag vorbei.
- Mandantentrennung. Rohdaten aus der WaWi kennen zwar Firmen und Aufträge, aber saubere, konsistent getrennte Kennzahlen pro Mandant entstehen erst durch eine Schicht darüber, die diese Trennung durchhält - bis ins Kundenportal.
- Gepflegte Kennzahlen. Aus rohen Versand- und Auftragsdaten werden erst durch Definitionsarbeit belastbare Werte: Welches Datum zählt als Versandzeitpunkt? Wie wird eine Mehrpaket-Sendung gezählt? Wie wird Scan-Spanne von echter Stempelzeit unterschieden?
- Wartung bei Updates. JTL entwickelt eazybusiness weiter, Tabellen und Strukturen ändern sich über Versionen hinweg. Wer selbst Abfragen gegen die Datenbank pflegt, muss diese Änderungen laufend nachziehen, damit nichts stillschweigend falsch rechnet.
max.dash verbindet sich exakt so, wie oben beschrieben - rein lesend, mit einem read-only-Zugang ohne Schreibrechte. Der Unterschied liegt nicht im Zugriffsweg, sondern darin, dass die Fachlogik dahinter bereits gebaut, gepflegt und im laufenden Betrieb bei mehreren Fulfillern im Einsatz ist: SLA-Regeln pro Mandant, sauber getrennte Kennzahlen, ein mandantengetrenntes Kundenportal und der Abrechnungs-Mengen-Export. Was intern an der Anbindung technisch passiert, bleibt Teil unseres Produktivsystems - das Ergebnis ist das fertige Cockpit auf deinen Daten.
Was das für dein Onboarding bedeutet
In der Praxis heißt das: Dein Administrator legt gemeinsam mit uns einen read-only-Benutzer mit db_datareader auf deiner eazybusiness-Datenbank an, wir verbinden uns damit, und ab da läuft die Spiegelung. Kein Plugin in JTL, keine Downtime, kein Risiko für deine Live-Daten - weil der Schreibpfad von Anfang an nicht existiert. Die eigentliche Arbeit auf unserer Seite beginnt erst danach, mit der Fachlogik, die aus deinen Rohdaten das Reporting macht, das im Kundengespräch und in der Abrechnung zählt.