Fortuna Entwickler Blog

Hier wird Ihnen geholfen

Scheduler updaten

Allgemein

Im derzeitigen System existieren zwei Scheduler Services, die für Web-Tasks auf dem Server WEB3 und für VWS-Tasks auf IASPROD2 laufen. Beide Scheduler Programme sind Windows Services und befinden sich in der selben Solution:

Fortuna Scheduler updaten

Um den Fortuna Scheduler zu updaten, muss man zunächst die Solution öffnen. Anschließend stellt man sicher, dass die Build-Configuration auf RELEASE steht für eine Produktivübergabe (Testübergaben finden bei Scheduler in der Regel nicht statt).

Anschließend die gesamte Solution builden. Ist dies erfolgreich, so wechselt man in das Release-Verzeichnis des Projektes "Fortuna.Scheduler.Service". Von hier kopiert man alle DLL-Dateien und die "Fortuna.Scheduler.Service.exe" in ein TEMP-Verzeichnis auf dem Server WEB3.

Nun muss man sich per Remote Desktop auf WEB3 anmelden und den Dienst zunächst stoppen


Wenn dies erledigt ist, können die DLL-Dateien aus dem TEMP-Verzeichnis in das Arbeitsverzeichnis des Scheduler Service kopiert und die vorhandenen Dateien überschrieben werden (Sicherung vorher bietet sich an). Das Arbeitsverzeichnis befindet sich auf WEB3 hier: "C:\Program Files\Fortuna Scheduler"

Sind neue Jobs hinzugekommen oder muss die Konfiguration bestehender Jobs angepasst werden, so muss dies in der Datei "jobconfig.xml" durchgeführt werden. Anschließend kann der Service wieder gestartet werden. Über das Ereignisprotokoll des Betriebssystems kann festgestellt werden, ob der Dienst fehlerfrei gestartet wurde, oder ob Fehler aufgetreten sind. Einige Fehler stellen sich aber auch erst heraus, wenn die ersten Jobs zum ersten Mal ausgeführt werden.

VWS Scheduler updaten

Bei dem VWS Scheduler läuft es ähnlich ab. Nach dem lokalen Builden auf RELEASE-Config, wechselt man in das Release-Verzeichnis des Projekts "Fortuna.Scheduler.VWS". Auch hier nimmt man alle DLL-Dateien und die "Fortuna.VWS.Scheduler.Service.exe" und kopiert sie zunächst in ein TEMP-Verzeichnis auf der Maschine IASPROD2.

Auch hier muss man sich per Remotedesktop anmelden und als erstes den Dienst stoppen. 

Nun werden die DLL-Dateien aus dem TEMP-Verzeichnis in das Arbeitsverzeichnis des Scheduler kopiert (Sicherung vorher). Das Arbeitsverzeichnis ist hier: "C:\myLife\Tools\Scheduler". Wenn Anpassungen an den Jobs durchzuführen sind, dann wird dies ebenfalls in der "jobconfig.xml" gemacht. Nun kann auch dieser Service wieder gestartet werden. Fehler werden im Ereignisprotokoll festgehalten.

Probleme mit DevArt

Hin und wieder kann es bei einer Produktivübergabe zu Problemen mit DevArt kommen. Die äußern sich dadurch, dass es bei der ersten Ausführung eines Jobs nach einer Übergabe zu Fehlern beim Zugriff auf die DB kommt:


Dies liegt daran, dass die Lizenz nicht korrekt in die Anwendung integriert wurde. Um dies zu beheben, muss man im Visual Studio in der Scheduler Solution die Lizenz neu in die Anwendung integrieren:

Bei allen fehlerhaften Assemblies muss der "Fix-Button" gedrückt werden:


Anschließend muss die Solution erneut kompiliert werden und die Dateien im Arbeitsverzeichnis des Scheduler auf WEB3 oder IASPROD2 noch einmal ausgetauscht werden (Dienst vorher beenden und nach dem Kopieren neustarten). 

SQL Statements bei Entities monitoren

Da wir meistens mit Entities arbeiten in unseren .NET-Anwendungen, kriegen wir hierbei gar nicht so mit, welche Statements eigentlich an die DB abgeschickt werden. Hierfür gibt es von DevArt ein sehr gutes Tool: DBMonitor

Mit dem DBMonitor hat man die Möglichkeit den gesamten Datenbank-Traffic, der innerhalb einer Anwendung läuft, zu beobachten.

Der DBMonitor kann ohne zusätzliche Kosten hier heruntergeladen werden:

https://www.devart.com/dbmonitor/download.html

Wenn das Tool heruntergeladen wurde, einfach lokal auf dem Entwicklungsrechner installieren und starten.

Nun muss noch der Anwendung, die man monitoren möchte, gesagt werden, dass die Daten an den DBMonitor geschickt werden. Dazu ist es erforderlich, dass man zwei Assemblies der Anwendung hinzufügt:

  • Devart.Data
  • Devart.Data.Oracle
Anschließend muss eine Instanz von OracleMonitor innerhalb des Codes der Anwendung angelegt und aktiviert werden. Dies macht am besten relativ früh in der Anwendung, aber auf jeden Fall bevor die Statements an die DB abgeschickt werden. Mehr muss man nicht im Code verändern:

var monti = new OracleMonitor() { IsActive = true };

Wenn man nun seine Anwendung ausführt, wird sämtliche Datenbank-Traffic im DBMonitor angezeigt:



Ebenso kann man dadurch sehen, welche Statements zu Fehlern geführt haben:



Durch Anklicken dieser Zeile, wird im unteren Bereich des DBMonitor eine Detailansicht generiert, die Auskunft über das Statement, die Parameter und auch den Fehler selber liefert: