Webdienste und APIs sind heute ein zentraler Bestandteil moderner ERP-Infrastrukturen. Kundenportale, mobile Anwendungen, Tracking-Lösungen, externe Plattformen und individuelle Webanwendungen erwarten schnelle Antwortzeiten – und häufig greifen viele Systeme gleichzeitig auf dieselben ERP-Daten zu.
Genau deshalb haben wir die technische Architektur der MicrotronX MS800 Webdienste in mehreren Bereichen grundlegend optimiert. Mit neuem Datenbank-Connection-Pooling, intelligenten Cache-Mechanismen und einer parallelen ReportBuilder-Verarbeitung wird die vorhandene Serverinfrastruktur effizienter genutzt und gleichzeitig die Grundlage für leistungsfähigere Web- und API-Anwendungen geschaffen.
⚡ Persistente Datenbankverbindungen statt ständigem Neuaufbau
Eine der wichtigsten Neuerungen ist das neue DB-Connection-Pooling.
Bisher wurden für jeden HTTP-Request mehrere neue Datenbankverbindungen aufgebaut. Je nach Verarbeitung konnten dabei teilweise bis zu sechs Verbindungen innerhalb eines einzelnen Requests entstehen. Das kostet Zeit und verursacht zusätzlichen Netzwerk- und Datenbank-Traffic – unter anderem deshalb, weil beim Aufbau einer Verbindung auch Informationen aus dem Datenbankkatalog geladen werden müssen.
Mit der neuen Architektur hält eine bestehende HTTP-Session nun eine persistente Datenbankverbindung bereit. Für einen Request wird diese Verbindung aus dem Pool verwendet und anschließend wieder zurückgegeben.
Im normalen Dauerbetrieb bedeutet das: Bei einer bereits bestehenden Session müssen nicht für jeden einzelnen Request neue Datenbankverbindungen aufgebaut werden.
📊 Messbarer Performancegewinn
Der Unterschied ist deutlich messbar. Bei internen Tests konnte die Laufzeit eines Test-Endpunkts von zuvor etwa 400–700 Millisekunden auf rund 160 Millisekunden reduziert werden.
Neben der eigentlichen Antwortzeit reduziert sich dadurch auch die Belastung von Netzwerk und Datenbankserver. Gerade bei Anwendungen mit vielen aufeinanderfolgenden Requests kann sich dieser Effekt erheblich bemerkbar machen.
🧹 Automatische Verwaltung der Verbindungen
Persistente Verbindungen benötigen selbstverständlich eine kontrollierte Verwaltung. Deshalb enthält das neue Connection-Pooling verschiedene Mechanismen zur automatischen Bereinigung.
- Nicht verwendete Session-Verbindungen werden nach fünf Minuten Inaktivität automatisch getrennt.
- Wird eine Datenbank beispielsweise für eine Reorganisation offline gesetzt, können geparkte Verbindungen innerhalb von etwa 90 Sekunden zwangsweise beendet werden.
- Prozessweit können maximal 200 Datenbankverbindungen geparkt werden.
- Einweg-Sessions werden nach 15 Minuten automatisch bereinigt und nicht dauerhaft gespeichert.
Die Implementierung wurde unter anderem mit 2.000 API-Requests getestet. Dabei blieb die Anzahl der gehaltenen Verbindungen stabil.
🔌 Besonderheit bei REST-APIs und automatisierten Requests
Für Administratoren und Schnittstellenentwickler ist wichtig: Nicht jeder HTTP-Zugriff wird automatisch als persistente Session behandelt.
Cookie-lose Einzelrequests, wie sie typischerweise bei REST-API-Aufrufen, Bots oder automatisierten Schnittstellen auftreten können, werden weiterhin nicht dauerhaft im Connection-Pool gehalten. Für solche Requests bleibt es bei einer Datenbankverbindung pro Request.
Browser-Sessions können ihre Datenbankverbindung dagegen ab dem zweiten Request persistent weiterverwenden.
Damit wird verhindert, dass kurzlebige API-Aufrufe unnötig dauerhaft Datenbankverbindungen belegen.
📊 Neue Informationen für Administratoren
Damit Administratoren die Auslastung besser überwachen können, wurde auch die Statusanzeige des MS800 Servers erweitert.
Die Server-GUI zeigt nun zusätzliche Informationen über Benutzer und Sessions sowie über aktuell geparkte und aktive Datenbankverbindungen an.
Damit lässt sich insbesondere bei größeren Installationen wesentlich besser nachvollziehen, wie die vorhandenen Serverressourcen aktuell genutzt werden.
💾 File- und Template-Cache reduziert Datei- und Netzwerkzugriffe
Nicht nur Datenbankzugriffe kosten Zeit. Auch häufig benötigte Dateien und Templates wurden bisher bei wiederholten Anforderungen erneut vom Datenträger beziehungsweise von einem Netzwerk-Share eingelesen.
Deshalb verfügt MS800 nun über einen prozessweiten File- und Template-Cache.
Davon profitieren insbesondere die Triggerfunktion ms800_getfilecontent sowie die interne Template-Verarbeitung.
Häufig benötigte Inhalte können im Speicher zwischengespeichert und bei weiteren Requests direkt wiederverwendet werden. Ob ein Cache-Eintrag weiterhin gültig ist, wird anhand von Dateigröße und Zeitstempel kontrolliert.
Der Cache ist bewusst begrenzt:
- maximal 500 Cache-Einträge
- maximal 4 MB Gesamtgröße
- automatische Gültigkeitsprüfung anhand von Dateigröße und Zeitstempel
Besonders interessant ist diese Optimierung für Installationen, bei denen sich das htdocs-Verzeichnis auf einem Netzwerk-Share befindet. Wiederholte Datei- und Netzwerkzugriffe können dort einen erheblich größeren Einfluss auf die Antwortzeiten haben als bei rein lokalen Installationen.
🌐 Verbesserter HTML-Response-Cache
Auch der interne HTML-Response-Cache wurde überarbeitet. Unter anderem wurden ein stabiler Cache-Key, eine definierte Gültigkeitsdauer (TTL) und eine Größenbegrenzung umgesetzt.
Zusätzlich wurde ein Race-Condition-Problem bei der parallelen Anlage von Verzeichnissen behoben.
JSON-/AJAX- und XML-Endpunkte werden dabei bewusst nicht über den allgemeinen internen Cache-Mechanismus zwischengespeichert. Dynamische Schnittstelleninformationen können dadurch weiterhin unmittelbar verarbeitet werden.
📄 Reports und PDFs jetzt parallel erzeugen
Eine weitere wichtige Architekturänderung betrifft die serverseitige Erstellung von Reports, PDF-Dateien, Versandlabels und anderen ReportBuilder-Ausgaben.
Bisher wurden ReportBuilder-Aufträge innerhalb des MS800 Webservers serialisiert verarbeitet. Pro Server konnte somit immer nur ein Report gleichzeitig gerendert werden.
Bei einzelnen Anforderungen ist das normalerweise unproblematisch. Anders sieht es bei mehreren parallelen API-Requests aus – beispielsweise wenn eine externe Anwendung gleichzeitig mehrere Versandlabels oder PDF-Dokumente anfordert.
In diesem Fall konnten sich die einzelnen Requests hintereinander aufstauen.
⚙️ mxRBWorker.exe – eigene Prozesse für ReportBuilder-Aufträge
Mit der neuen Worker-Architektur kann das ReportBuilder-Rendering optional in separate Prozesse ausgelagert werden.
Für einen Render-Auftrag wird eine eigene Instanz von mxRBWorker.exe gestartet. Abhängig von der Konfiguration können dadurch mehrere Reports gleichzeitig erzeugt werden, während der Hauptprozess des Webservers weiterhin für andere HTTP-Anfragen zur Verfügung steht.
Der Worker verwendet dieselbe Codebasis wie das MS800-Modul und initialisiert die für die Report-Erstellung benötigten Komponenten wie Datenbankzugriff, Lizenzierung und ReportBuilder – jedoch ohne eigenen HTTP-Listener.
Jeder Worker verarbeitet genau einen Report-Auftrag und beendet sich anschließend wieder.
📁 Technischer Ablauf der Worker-Verarbeitung
Die Kommunikation zwischen MS800 und dem Report-Worker erfolgt über ein separates Job-Verzeichnis.
Eine job.json enthält die für den Auftrag benötigten Informationen, darunter beispielsweise:
- Report
- Drucker
- Parameter
- Session-Variablen
Als Ergebnis stellt der Worker unter anderem die erzeugte PDF-Datei sowie eine result.json bereit.
Da die job.json Session-Daten enthalten kann, wird sie nach Abschluss des Vorgangs grundsätzlich gelöscht.
Die Verarbeitung erfolgt weiterhin über den bestehenden mxhttp_PrintReport-Pfad. Damit bleiben auch vorhandene Trigger und RAP-Funktionen Bestandteil der Report-Verarbeitung.
🛡️ Mehr Stabilität durch Prozess-Isolation
Die Worker-Architektur bringt neben der Parallelisierung einen weiteren wichtigen Vorteil: Crash-Isolation.
Da das Rendering in einem separaten Prozess stattfindet, betrifft ein möglicher Absturz des ReportBuilders nicht mehr zwangsläufig den gesamten MS800 Webserver, sondern nur den jeweiligen Worker-Prozess.
Der Server begrenzt die Anzahl gleichzeitig laufender Worker über ein Semaphor. Zusätzlich werden die Prozesse über einen konfigurierbaren Timeout überwacht. Sollte ein Worker hängen bleiben, kann er nach Überschreiten des Zeitlimits beendet werden.
Damit verbessert die neue Architektur nicht nur die Geschwindigkeit bei parallelen Anforderungen, sondern auch die Robustheit des Webdienstes.
🔧 Konfiguration für Administratoren
Die neue Worker-Verarbeitung ist standardmäßig deaktiviert und kann gezielt pro Installation aktiviert und dimensioniert werden.
Die entsprechenden Parameter befinden sich unter:
ERP Administration / Einstellungen / Ordner: setup
| Parameter | Funktion | Standard |
|---|---|---|
rbworker_enabled |
Aktiviert oder deaktiviert die externe Worker-Verarbeitung | 0 (deaktiviert) |
rbworker_maxparallel |
Maximale Anzahl gleichzeitig laufender Report-Worker | 4 |
rbworker_timeoutseconds |
Maximale Laufzeit eines Worker-Prozesses | 120 Sekunden |
Wichtig für Administratoren: Änderungen an diesen Einstellungen erfordern einen Neustart des Dienstes.
🔄 Automatischer Fallback sorgt für Kompatibilität
Die neue Worker-Verarbeitung wurde bewusst so umgesetzt, dass bestehende Installationen nicht zwingend umgestellt werden müssen.
Ist die Funktion deaktiviert, fehlt die mxRBWorker.exe, kann ein Worker nicht gestartet werden oder sind bereits alle konfigurierten Worker-Slots belegt, verwendet MS800 automatisch den bisherigen serialisierten In-Process-Pfad.
Dadurch entsteht kein Funktionsverlust. Administratoren können die neue Verarbeitung gezielt aktivieren und an die Leistungsfähigkeit der jeweiligen Serverumgebung anpassen.
🔒 Hinweis zum Datenbank-Offline-Modus
Durch die persistenten Datenbankverbindungen ergibt sich für Administratoren eine wichtige Änderung beim Offline-Schalten einer Datenbank.
Der Status „Datenbank offline“ wird beim Aufbau einer neuen Verbindung geprüft. Eine bereits aktive Session besitzt jedoch möglicherweise noch eine bestehende Verbindung und kann deshalb zunächst weiterarbeiten.
Diese Verbindung wird anschließend über den Idle-Timeout beziehungsweise den Force-Drain getrennt. Bei administrativen Arbeiten wie einer Reorganisation sollte dieses Verhalten entsprechend berücksichtigt werden.
🚀 Eine technische Basis für anspruchsvollere Webanwendungen
Connection-Pooling, Caching und paralleles Report-Rendering sind auf den ersten Blick Funktionen, die ein normaler ERP-Anwender kaum sieht. Ihre Auswirkungen sind jedoch unmittelbar spürbar.
Sie bilden die technische Grundlage dafür, dass Kundenportale, mobile Anwendungen, APIs, Tracking-Lösungen und individuelle Webanwendungen auch bei steigender Nutzung schnell und zuverlässig mit dem MicrotronX ERP kommunizieren können.
Gleichzeitig erhalten Administratoren mehr Möglichkeiten, Serverressourcen gezielt zu überwachen und die Verarbeitung an die jeweilige Infrastruktur anzupassen.
Fazit
Mit den aktuellen Erweiterungen wurde die Architektur der MicrotronX MS800 Webdienste an entscheidenden Stellen weiterentwickelt.
Persistente Datenbankverbindungen reduzieren unnötige Verbindungsaufbauten, intelligente Caches vermeiden wiederkehrende Datei- und Netzwerkzugriffe und separate ReportBuilder-Worker ermöglichen die parallele Erstellung von Reports und PDF-Dokumenten.
Das Ergebnis ist eine schnellere, skalierbarere und robustere Plattform für die Integration des MicrotronX ERP in moderne digitale Prozesse – von einfachen Kundenportalen bis hin zu umfangreichen API- und Automatisierungslösungen.