Zum Hauptinhalt springen

Inhalte eines Fehlerberichts an den Support

Allgemein​

Der Fehlerbericht sollte alle Informationen enthalten, um das fehlerhafte Verhalten nachvollziehen zu können. Beschreibungen wie "funktioniert nicht" sind nicht ausreichend, da der Fehler auch in der Konfiguration des Systems oder Netzwerkproblemen und ähnlichem beim Kunden liegen kann und nicht in der Software.

Beschreibungen in dieser Form sind hilfreich:

  • Was habe ich gemacht
  • Was ist passiert (tatsächliches Ergebnis)
  • Was hätte passieren sollen (erwartetes Ergebnis)

Je mehr zusätzliche Informationen über die Konfiguration, Daten, Umgebung und Logdateien zusätzlich verfügbar sind, um so besser.

Was uns hilft 1​

  • Beschreibung der Vorgehensweise: was wird wo angeklickt und was wird wie eingegeben (Datenbank, Tabellenname, FID des betroffenen Features)
  • Was passiert genau? (Fehlermeldung, Absturz, falsches Ergebnis etc.)
  • Screenshots, Videos und Fehlermeldungen mit Stacktraces sind immer nützlich
  • Falls es einen Dump dazu gibt, hilft der auch weiter (exportieren, packen und ans Ticket anhängen)
  • die benutzten Produkte und die Versionen aller dieser Komponenten

Vorgehensweise​

  • bitte alle relevanten Daten in ein ZIP- oder 7-Zip-Archiv verpacken und an das Ticket anhängen
  • falls die Daten schon an einem anderen Ticket hängen, bitte auf dieses Ticket verweisen

Hinweis für MuM Mitarbeiter​

Dieser Anschnitt gilt nur für MuM Mitarbeiter.

Warnung

Für alle Fehlerberichte/Fragen/Probleme benutzten wir MuM intern immer Redmine, nicht Teams Chat oder EMAIL oder anderes. Fragen bitte einfach als Bug eintragen.

Warum ist das so?

  • Es kommen oft sehr viele Anfragen rein und dann ist das einfacher wenn das in einem zentralen System wie Redmine ist.
  • Wenn jemand anderes zuständig ist dann kann man das Redmine Ticket einfach demjenigen zuweisen und derjenige hat alle Informatioen zu dem Fall.
  • Wenn jemand krank ist, kann der jemand anders das Ticket bearbeiten.
  • Wenn ein anderer das gleiche Problem hat kann man so auch auf diese Ticket verweisen.
  • Wenn das im Chat oder EMail macht dann sind die Informationen für den nächsten Kollegen nicht verfügbar. Den der hat ja den Chat/Email nicht.
  • Wenn jemand heute Hotline macht und morgen macht ein anderer Kollege Hotline dann weis derjenige nicht was bereits an dem Problem geschehen ist und man müsste man demjenigen erst alle Informationen aus Chats, Emails etc auch weitergeben.
  • Aus den Redmine Tickets wird das Change Log erzeugt, dort sieht der Kunde was neu und gefixt wurde. Wenn es also nicht im Redmine steht, wandert es nicht ins Changelog.

MapEdit​

Was uns hilft 2​

  • das Repository des AppBuilders aus C:\inetpub\wwwroot\MumGeoData\Repositories\Default
  • die Systemdatenbanken aus C:\inetpub\wwwroot\MumGeoData\System
  • die Logdateien aus C:\inetpub\wwwroot\MumGeoData\Log
  • die Logdatei aus MapEdit Desktop (Menü -> Log oder Strg+F12)
  • der Name des Projektes, dass den Fehler auslöst
  • die Dumps, die von diesem Projekt referenziert werden (sonst können wir Probleme bei Suchen etc. nicht nachvollziehen), bitte gepackt anhängen
  • Kopien oder Screenshots von Fehlermeldungen (falls möglich mit Stacktrace, durch Kopierbutton bei MapEdit-Fehlermeldungen unten links)
  • falls der Fehler Karten vom TileServer betrifft: siehe TileServer unten

MapEdit Mobile Web​

Fehlersuche​

  • im Browser vorm Aufruf der Webseite von MapEdit Mobile die Entwicklertools öffnen (Strg+Shift+I im Chrome Browser)
  • in den Entwicklertools des Browsers auf den Console-Tab wechseln
  • die URL von MapEdit Mobile eingeben
  • Projekt öffnen/Aktionen die zum Fehler führen ausführen
  • in der Browser-Console auf Fehlermeldungen prüfen
    • Fehler 404 bei URLs ähnlich https://SERVER/mapedit-core/mapedit-core/rest/application/projects/PROJECTNAME/preview?token=XXX ist normal, wenn es kein Vorschaubild gibt
  • dann in den Entwicklertools auf den Network-Tab wechseln
  • angefragte URLs auf Fehler prüfen
    • bei Fehlern (rot) die URL anklicken und im Detailfenster den Tab Preview wählen
    • dort sollte dann wenn möglich eine etwas detailliertere Fehlermeldung erscheinen, z.B. file not found: Repositories/DEFAULT/Projects/PROJECTNAME.png
    • der Status canceled ist in Ordnung, wenn man sich schnell auf der Karte bewegt, da dann die Anforderung für Kacheln manchmal vom Browser abgebrochen werden (was kein Fehler ist, wenn man sich von der Kachel weiter weg bewegt)

WildFly​

  • Meldungen werden in diesen Logdateien abgelegt
    • C:\WildFly\standalone\log\MuM.log für MuM-spezifische Meldungen
    • C:\WildFly\standalone\log\server.log für alle anderen Meldungen
  • das Logging-Level lässt sich in der WildFly Console einstellen
    • WildFly Console öffnen: http://localhost:9990/
    • Configuration -> Subsystems -> Logging -> Configuration -> View wählen
    • Categories -> de.mum wählen
    • Edit klicken
    • Level stellt den Logging-Level/Detailgrad ein
      • INFO ist normal im Produktionsbetrieb und schließt Warnung und Fehler ein
      • ALL ist geeignet um Fehler nachzuvollziehen und sollte zur Erstellung von Fehlerberichten genutzt werden (Achtung: kann sehr große Dateien erzeugen!)
    • Save klicken, die Änderung wird sofort übernommen
  • Bitte das Logging-Level später wieder auf INFO oder WARN zurückstellen, um die Logdatei-Größe klein zu halten!

TileServer​

Was uns hilft​

  • GETSTATUS-Seite
  • GETEXTENDEDCONFIG-Seite
  • Konfiguration über READCONFIG
  • die Logdatei des TileServers (auf Tomcat TileServer.log, auf WildFly in der MuM.log)
  • RefSysInfo-Datei (falls verwendet)
  • die XML-Datei, die der TileUpdater erzeugt (bei Aktualisierungsproblemen)
  • Kopien oder Screenshots von Fehlermeldungen (falls möglich mit Stacktrace, durch Kopierbutton bei MapEdit-Fehlermeldungen im Client unten links)

Vorgehensweise (TileServer auf WildFly)​

  • das Logging auf TRACE einstellen, siehe hier
  • Das Verhalten auslösen, was den Fehler bewirkt (TileUpdater starten/Vorrendern etc.)
  • GETSTATUS und GETEXTENDEDCONFIG ausführen und die Ansicht als XML- bzw. HTML-Datei abspeichern
  • TileServer.properties-Datei hinzufügen
  • RefSysInfo-Datei hinzufügen
  • Aktuelle Logdatei des TileServers hinzufügen (MuM.log)
  • XML-Datei des TileUpdaters hinzufügen (bei Aktualisierungsproblemen)
  • das Logging auf INFO zurückstellen, siehe hier

Vorgehensweise (TileServer auf Tomcat)​

  • in der TileServer.log4j.xml den log-Level auf TRACE einstellen
  <?xml version="1.0" encoding="UTF-8"?>
  <Configuration>
         <Appenders>
               <!-- File that gets changed every day -->
               <RollingFile name="RF" fileName="logs/TileServer.log"
                   filePattern="logs/TileServer-%d{yyyy-MM-dd}.log">
                 <PatternLayout pattern="%d{ISO8601} [%t] %-5p %c{1} - %m%n" />
                      <Policies>
                             <TimeBasedTriggeringPolicy />
                      </Policies>
               </RollingFile>
         </Appenders>

         <Loggers>
               <!-- production (detailed/TRACE) -->
               <Root level="TRACE">
                      <AppenderRef ref="RF" />
               </Root>
         </Loggers>
  </Configuration>
  • Den Tomcat-Server neustarten
  • Das Verhalten auslösen, was den Fehler bewirkt (TileUpdater starten/Vorrendern etc.)
  • GETSTATUS und GETEXTENDEDCONFIG ausführen und die Ansicht als XML- bzw. HTML-Datei abspeichern
  • TileServer.properties-Datei hinzufügen
  • RefSysInfo-Datei hinzufügen
  • Aktuelle Logdatei des TileServers hinzufügen
  • XML-Datei des TileUpdaters hinzufügen (bei Aktualisierungsproblemen)
  • in der TileServer.log4j.xml den log-Level auf INFO zurückstellen
  <?xml version="1.0" encoding="UTF-8"?>
  <Configuration>
         <Appenders>
               <!-- File that gets changed every day -->
               <RollingFile name="RF" fileName="logs/TileServer.log"
                   filePattern="logs/TileServer-%d{yyyy-MM-dd}.log">
                 <PatternLayout pattern="%d{ISO8601} [%t] %-5p %c{1} - %m%n" />
                      <Policies>
                             <TimeBasedTriggeringPolicy />
                      </Policies>
               </RollingFile>
         </Appenders>

         <Loggers>
               <!-- production -->
               <Root level="INFO">
                      <AppenderRef ref="RF" />
               </Root>
         </Loggers>
  </Configuration>
  • RELOADCONFIG ausführen nach Abschluss des Fehlerberichts

MapEdit Mobile (bis 20.x)​

Was uns hilft bei Mobile​

  • die Konfigurationsdatei MapEdit.h2.db
  • die Logdatei von MapEdit Mobile
  • Kopien oder Screenshots von Fehlermeldungen (falls möglich mit Stacktrace, durch Kopierbutton bei MapEdit-Fehlermeldungen unten links)

Vorgehensweise für Mobile​

  • in der log4j.properties den log-Level auf TRACE einstellen log4j.rootLogger=TRACE, RF und den Tomcat-Server neustarten
  • Das Verhalten auslösen, was den Fehler bewirkt
  • falls vorhanden MapEdit.properties-Datei hinzufügen
  • Aktuelle Logdatei von MapEdit Mobile hinzufügen
  • in der log4j.properties den log Level zurück auf INFO einstellen log4j.rootLogger=INFO, RF und den Tomcat-Server neustarten nach Abschluss des Fehlerberichts