Einleitung
Diese Checkliste unterstützt bei der Diagnose von Verbindungsproblemen mit WERBAS.blue, der Cloud-Anbindung oder Echtzeit-Funktionen auf Systemen mit einem oder mehreren BO-Server-Instanzen. Sie ist in zwei Stufen aufgebaut: Stufe 1 ist für Kunden-Administratoren geeignet, Stufe 2 richtet sich an den technischen Service. Jede BO-Instanz benötigt drei eigene, eindeutige Ports für Remoting, SignalR und Fusion API. Zusätzlich darf genau eine Instanz den gemeinsamen REST-Port 8085 halten. Läuft eine Instanz zwar, hat aber ihren SignalR- oder Fusion-Port nicht belegt, ist ihr Start unvollständig abgebrochen.
Stufe 1 – Schnellcheck
Die folgenden Schritte sollen nur ausgeführt und dokumentiert werden. Eine Bewertung ist in dieser Stufe nicht erforderlich. Die erzeugten Dateien und notierten Soll-Ports werden anschließend an den WERBAS-Service weitergegeben.
Auszuführende Befehle
Die drei folgenden Befehle werden jeweils in einer Eingabeaufforderung als Administrator ausgeführt und die Ergebnisse als Dateien gespeichert.
Schnellcheck-Befehle
Schritt |
Befehl |
Zweck |
1.1 Aktive Ports auflisten |
netstat -ano > %USERPROFILE%\Desktop\netstat.txt |
Listet alle aktiven Verbindungen und lauschenden Ports auf |
1.2 REST-Registrierung auflisten |
netsh http show servicestate view=requestq > %USERPROFILE%\Desktop\http-state.txt |
Listet aktive HTTP.SYS-Registrierungen einschließlich REST-Port 8085 |
| 1.3 SSL-Zertifikat-Bindungen auflisten | netsh http show sslcert > %USERPROFILE%\Desktop\sslcert.txt | Listet SSL-Zertifikat-Bindungen für HTTPS-Endpunkte auf |
Erwartete Ports je Instanz notieren
In der ConnectConfig.xml des Servers stehen je Instanz die konfigurierten Ports. Diese Werte werden pro Instanz notiert und zusammen mit den erzeugten Textdateien an den Service weitergegeben.
Relevante Soll-Ports pro Instanz
Port-Art |
Konfigurationsschlüssel |
Standardwert |
Remoting |
Port |
8086 |
SignalR |
SignalRServerPort |
11120 |
| Fusion API | FusionApiServerPort | 8321 |
Stufe 2 – Detaildiagnose
Die Detaildiagnose richtet sich an den technischen Service und dient der gezielten Einordnung von Portkonflikten, Startabbrüchen und fehlerhaften REST-Registrierungen.
Schritt A – Soll-Belegung ableiten
Je Instanz werden die drei konfigurierten Ports aus der ConnectConfig.xml gelesen. Der REST-Port 8085 ist global und wird nicht pro Instanz konfiguriert. Im Mehr-BO-Betrieb muss jede Instanz ihren eigenen Remoting-, SignalR- und Fusion-Port binden, während genau eine Instanz zusätzlich Port 8085 hält. Alle Portwerte müssen instanzübergreifend eindeutig sein.
Schritt B – Ist-Zustand prüfen mit netstat
Mit netstat wird geprüft, ob die erwarteten Ports tatsächlich durch die passenden Prozesse belegt werden. Fusion-Port 8321 und jeder SignalR-Port dürfen jeweils nur bei einer PID im Zustand LISTENING erscheinen. Fehlen bei einer Instanz der Fusion- und oder SignalR-Port, während ihr Remoting-Port lauscht, ist der Start dieser Instanz vorzeitig abgebrochen. Die Instanz läuft dann, ist aber für Echtzeit und Fusion nicht bereit. Ursache ist meist ein doppelt vergebener Port.
Hilfsmittel zur PID-Zuordnung
Befehl |
Zweck |
| tasklist /fi "PID eq <PID>" | Ordnet eine PID einem laufenden Prozess zu |
Schritt C – REST und Port 8085 prüfen
Mit den netsh-Befehlen wird geprüft, welche Instanz den REST-Port 8085 registriert hat und ob die passende SSL-Zertifikat-Bindung vorhanden ist. Erwartet wird, dass genau eine Instanz 8085 registriert. Wenn keine Instanz den Port hält oder weitere Instanzen beim REST-Start scheitern, muss die REST-Autostart-Konfiguration der betroffenen Instanz geprüft werden.
REST-Diagnosebefehle
Befehl |
Zweck |
netsh http show servicestate view=requestq |
Zeigt PID und registrierte URL einschließlich https://+:8085/ |
| netsh http show sslcert | Zeigt die SSL-Zertifikat-Bindung für 0.0.0.0:8085 |
Schritt D – Richtige Logquelle wählen
Die Wahl der richtigen Logquelle ist entscheidend, weil unterschiedliche Fehlerbilder an unterschiedlichen Stellen protokolliert werden.
Logquellen nach Fehlerbild
Symptom oder Frage |
Wo nachsehen |
Fusion-Port-Konflikt wie address already in use auf 8321 |
Trace\fusionapi_server_JJJJMMTT.log der betroffenen Instanz |
Normaler Server-Trace oder REST-Registrierungsfehler |
Trace\Server\ der betroffenen Instanz |
| Port-Änderungen durch Setup oder Update | Installer-Protokoll unter %programdata%\WERBAS\Werbas.Web\Log |
Schritt E – Befund einordnen
Die folgende Tabelle unterstützt bei der Einordnung typischer Befunde und den jeweils naheliegenden Maßnahmen.
Entscheidungshilfe für typische Fehlerbilder
Symptom |
Wahrscheinliche Ursache |
Maßnahme |
SignalR getrennt und Fusion- oder SignalR-Port fehlen, Remoting-Port lauscht |
Start der Instanz an Fusion-Bind abgebrochen |
fusionapi_server_*.log prüfen und doppelten Fusion-Port in ConnectConfig bereinigen |
Endpunkt nicht gefunden bei Cloud- oder Web-Zugriff über eine bestimmte Instanz |
REST-Port 8085 wird von anderer Instanz gehalten oder ist nicht registriert |
Mit netsh http show servicestate prüfen, welche Instanz 8085 hält |
| Gleicher SignalR- oder Fusion-Port bei mehreren Instanzen | Doppelt vergebene Ports | In ConnectConfig.xml je Instanz eindeutige Werte setzen und Instanzen neu starten |
Eskalation an den Service
Wenn der Befund nicht eindeutig ist oder die Ursache unklar bleibt, sollten die gesammelten Ergebnisse mit allen relevanten Anlagen an WERBAS KSR Service weitergegeben werden.
• Ausgaben aus Stufe 1: netstat.txt, http-state.txt, sslcert.txt
• Notierte Soll-Ports je Instanz aus der ConnectConfig.xml
• Bei Fusion- oder SignalR-Verdacht: betroffene fusionapi_server_*.log sowie passender Trace\Server\-Ausschnitt mit mehreren Tagen Abdeckung