Neu JTL Worker 2.0 als Dienst und Ereignisanzeige

[mvh]

Hallo an Alle, die Worker als Dienst nutzen oder nutzen wollen.

Viele haben sich beschwert, dass es kein Fenster mehr erscheint (ist ja auch ein Dienst und keine GUI)
und auch sonst ist es etwas ungewöhnlich.

Ich zeige und erkläre gleich, dass die grafische Anzeige nicht notwendig ist, es gibt einen Ersatz dafür.

Der Worker als Anwendung läuft erst nach der Benutzer-Anmeldung, deswegen wird auch die Windows-GUI gestartet,
der Dienst braucht es nicht.

Für die JTL-Worker Dienstmeldungen wird die Windows-Ereignisanzeige verwendet:



einfacher wird es aber mit PowerShell:

Get-WinEvent -ProviderName "JTL-Worker" -MaxEvents 1000 |Out-GridView -Wait

Hier sind 1000 letzte Meldungen vom Worker in einer grafischen Anzeige zu sehen.

Aber wieder muss ich an dem Server angemeldet sein.
Wie wäre es damit? Wir schalten unter Firewall eine eingehende Regel an: "Remote-Ereignisprotokollverwaltung (RPC)"


und führen unser PowerShell-Befehl so aus:

Get-WinEvent -ComputerName "<Mein Server>" -Credential <Mein Server>\<Mein Benutzername> -ProviderName "JTL-Worker" -MaxEvents 1000 |Out-GridView -Wait
Beispiel:
Get-WinEvent -ComputerName "SERVERWAWI" -Credential SERVERWAWI\Administrator -ProviderName "JTL-Worker" -MaxEvents 1000 | Out-GridView -Wait

Und für die PowerShell "geübte" unter uns: Get-WinEvent kann mit allen Filtern: -FilterXPath, -FilterXML, -FilterHashtable und allen -Where match/like/etc. kombiniert werden.

Ihr könnt gerne Eure Fragen/Feedback im Thema posten.

 

[Thomas_T]

Wenn es nur um die Kontrolle geht, ob der Worker läuft, kann man sich auch einfach im Dashboard das Widget anzeigen lassen (Zu finden in der der Kategorie "Allgemein")

 

[mvh]

Wenn es nur um die Kontrolle geht, ob der Worker läuft, kann man sich auch einfach im Dashboard das Widget anzeigen lassen (Zu finden in der der Kategorie "Allgemein")
Den Anhang 91210 betrachten

Das ist trivial und hat nichts mit dem Thema "JTL Worker 2.0 als Dienst und Ereignisanzeige" zu tun.
In einem Fehlerfall bzw. für eine bessere Analyse liefert der Worker-Status nicht genügend Informationen mit,
ist ja auch nur eine "Session"-Anzeige (s. z.B. Tabelle tUniqueSession)

 

[Verkäuferlein]

Hallo an Alle, die Worker als Dienst nutzen oder nutzen wollen.

Viele haben sich beschwert, dass es kein Fenster mehr erscheint (ist ja auch ein Dienst und keine GUI)
und auch sonst ist es etwas ungewöhnlich.

Ich zeige und erkläre gleich, dass die grafische Anzeige nicht notwendig ist, es gibt einen Ersatz dafür.

Der Worker als Anwendung läuft erst nach der Benutzer-Anmeldung, deswegen wird auch die Windows-GUI gestartet,
der Dienst braucht es nicht.

Für die JTL-Worker Dienstmeldungen wird die Windows-Ereignisanzeige verwendet:
Den Anhang 91174 betrachten


einfacher wird es aber mit PowerShell:

Get-WinEvent -ProviderName "JTL-Worker" -MaxEvents 1000 |Out-GridView -Wait

Den Anhang 91177 betrachten
Hier sind 1000 letzte Meldungen vom Worker in einer grafischen Anzeige zu sehen.

Aber wieder muss ich an dem Server angemeldet sein.
Wie wäre es damit? Wir schalten unter Firewall eine eingehende Regel an: "Remote-Ereignisprotokollverwaltung (RPC)"
Den Anhang 91180 betrachten

und führen unser PowerShell-Befehl so aus:

Get-WinEvent -ComputerName "<Mein Server>" -Credential <Mein Server>\<Mein Benutzername> -ProviderName "JTL-Worker" -MaxEvents 1000 |Out-GridView -Wait
Beispiel:
Get-WinEvent -ComputerName "SERVERWAWI" -Credential SERVERWAWI\Administrator -ProviderName "JTL-Worker" -MaxEvents 1000 | Out-GridView -Wait

Und für die PowerShell "geübte" unter uns: Get-WinEvent kann mit allen Filtern: -FilterXPath, -FilterXML, -FilterHashtable und allen -Where match/like/etc. kombiniert werden.

Ihr könnt gerne Eure Fragen/Feedback im Thema posten.

Cool, danke für Deine Mühe, das hier zu erläutern!

Die Ausführung der Workflows im Detail scheint aber nochmal anders gelogt zu werden...

 

[mvh]

Cool, danke für Deine Mühe, das hier zu erläutern!

Die Ausführung der Workflows im Detail scheint aber nochmal anders gelogt zu werden...

Moin.
Bitte sehr.
Wir nutzen auch die Ereignisanzeige bzw. Logdateien für unsere Projekte,
bei den Workflows ist aber die Tabelle (heißt übrigens tWorkflowLog)
eine bessere Entscheidung.
In Log/Ereignisanzeige filtern wir nach "Fehler" oder fehlenden Ereignissen
und wenn beim Workflow ein Fehler auftritt - haben wir dafür extra einen Skript gebaut.
Wir führen fehlgeschlagene Workflows erneut und vergleichen das Endergebnis, das haben wir SecondChance genannt.



Funktioniert meistens gut.