Vergleichsreport

Allgemeines

Jobs dienen als periodisch laufende Hilfsprogramme der Synchronisation und Bearbeitung von Daten. 

Beispiele:

• Erstellung von Gruppen anhand bestimmter Kriterien
• die Synchronisation von Abteilungs- und Personendaten aus dem Zeitwirtschaftssystem oder
• die Synchronisation von Kalenderdaten aus dem Groupware-System.
• Filterung definierter Unregelmäßigkeiten im Zeitwirtschaftssystem und in folge daraus
• Automatische Generierung bestimmte Workflow-Anträge..

Die Jobs können automatisch, mit Hilfe eines sogenannten Triggers gestartet werden. Mit dem Trigger wird ein Zeitplan erstellt, so dass die Jobs beliebig gestartet werden können (stündlich, täglich, wöchentlich oder monatlich, ...). Die Einstellung kann auf den Tag, Stunde und Minute genau konfiguriert werden.
Bei Bedarf können die Jobs auch jederzeit manuell gestartet werden.

Weiters können die Jobs einen aktiven oder inaktiven Status haben. Bei einem aktiven Status werden die Jobs gemäß dem eingestellten Trigger gestartet. Sind diese jedoch inaktiv, können sie lediglich manuell gestartet werden. Der Status kann jederzeit geändert werden.

Ein Monitoring der Jobs wird durch die Ansicht "Aktive Jobs" ermöglicht, wo alle aktiven Jobs auf einen Blick zu sehen sind. Weiters kann, bei entsprechender Parametrierung, der Verlauf des Jobs mit Hilfe der Logeinträge nachvollzogen werden. So wird anhand des parametrierten Log-Levels (definierter Status während des Jobverlaufes, wie z.B. Fehler, Warnung, ...) ersichtlich, ob ein Job problemlose durchgelaufen ist, oder ob bestimmte Probleme aufgetreten sind.
Bei Bedarf kann hier auch ein Mailversand konfiguriert werden. Die Mail wird an eine definierte Person verschickt, falls ein Logeintrag mit einem angegebenen Level existiert.

Begriffsdefinitionen

• Ein Job ist ein periodisch laufendes Hilfsprogramm, welches für den korrekten Ablauf des Kundensystems notwendig ist. Dabei werden Systemtätigkeiten abgearbeitet, welche im Hintergrund durchgeführt werden können.
• Ein konfigurierter Job ist ein Webdesk Standard-Job mit einer parametrierten kundenspezifischen Konfiguration. Dieses Parametrierung wird über den Reiter 'Job-Konfiguration' im Formular Job durchgeführt. Ein konfigurierter Job verwendet also die Funktionen eines Standardjobs, jedoch mit den Einstellungen, die für den Kunden sinnvoll sind.
• Ein Jobtrigger ist eine Planungsinformation pro Job, welche angibt, in welchen Zeitabständen der Job gestartet werden soll. Pro Job können mehrere Jobtrigger definiert werden.
• Ein Standard-Job der konfigurierbar ist, stellt ein eigene Konfigurationsformular zur Verfügung und ist per se noch nicht ablauffähig. Erst wenn eine neue Jobkonfiguration angelegt ist, kann diese dann gestartet werden. Ein "nicht konfigurierbarer" Job hingegen taucht sofort in der Liste der Jobs auf, ist also sofort ausführbar (und auch planbar), stellt aber keine weiteren Parametrierungsmöglichkeiten mehr zur Verfügung.

Durch die flexible Konfigurationsmöglichkeit kann ein Standard-Job in mehreren "Variationen" in einem System ablaufen. Jeder konfigurierte Job bildet nämlich eine neue Einheit, die seperat geplant werden kann.

Jedes Modul kann neue Jobs (sowohl konfigurierbare als auch nicht konfigurierbare) Jobs "beisteuern" und somit den "Werkzeugkasten" des Webdesk-Systems im Job-Bereich erweitern.

Relevante Menüpunkte / Aktionen

Die folgenden Menüpunkte im Full System Administrator enthalten die relevanten Funktionen zur Verwaltung und zur Überwachung von Jobs:

• System -> Jobs
• Monitoring -> Aktive Jobs
• Monitoring -> Logeinträge

Monitoring

Für das Monitoring von Jobs ist es ungeheuer wichtig, dass die implementierenden Job-Klassen auch entsprechend Loggen. Diese Logging-Informationen werden dann üblicherweise in die Webdesk-Datenbank-Logs geschrieben und sind dann somit über die Ansicht Monitoring->Logeinträge auswertbar.

Empfohlene Log-Einstellungen

Grundsätzlich sollte der Loglevel of Jobs in den Log-Einstellungen (Full System Administrator: System--> Log-Einstellungen) zumindest auf INFO stehen. Damit ist gewährleistet, dass alle Log-Informationen, welche vom Programmierer als INFO oder höherwertig qualifiziert wurden, ins Datenbank-Log geschrieben werden. Hiermit sollte z.b. bei einer Batchverarbeitung üblicherweise z.b. die Anzahl der verarbeiteten Datensätze gelogged werden. Jedenfalls werden damit Fehler (Exceptions) auf jeden Fall gelogged!

Treten Fehler im Job auf, so ist es mitunter sinnvoll, den Logging-Level für Jobs auf DEBUG zu erhöhen!

Mailversand von Log-Infos

Im Reiter "Mailversand" des Job-Formulars kannn automatisch ein Mail mit Logging-Informationen an eine bestimmte Benutzer-Gruppe geschickt werden. Als Auslösekriterium sind hier Suchbegriffe oder das Erreichen eines bestimmten Log-Levels (z.b ERROR) möglich. Das Mail kann direkt alle Logging-Informationen enthalten oder aber nur einen Link auf die entsprechende Logging-Page enthalten.

Best Practises

Jobs im Modul Portal & Organisation

Jobs, welche für das Modul Portal & Organisation relevant sind:

• Import OrgData
  Dieser konfigurierbare Job importiert Organisationsdaten (z.B. Hierarchie und Vorgesetzte) z.B. aus anderen Systemen.
• Start Connector Link Sync
  Mit diesem konfigurierbaren Job können ein oder mehrere Konnektor-Synchronisation(en) gestartet werden.

Best Practice

Werden viele Jobs in einem System verwendet, sollte man folgende Grundregeln beachten:

• Man sollte eine kundenspezifische Namenskonvention bei der Vergabe des Jobnamens einhalten, um später den Sinn des Jobs schnell erfassen zu können.
• Das Beschreibungsfeld sollte auch wirklich genutzt werden, um das Ziel des Jobs für den Administrator zu beschreiben (z.bB. Import von Personenstammdaten aus IF6020)
• Läuft Webdesk in einem Clusterverbund (mehr als ein Server), so macht es Sinn, die Jobs auf einen Server zu konzentrieren. Ein nebenläufiges paralleles (gleichzeitiges) Ausführen desselben Jobs auf unterschiedlichen Cluster-Nodes kann zu unvorhersehbaren Ergebnissen - im schlimmsten Fall zu Datenbank-Inkonsistenzen - führen.
• Rechenintensive Jobs sollten am Abend oder in der Nacht laufen, um die Serverhardware während der "Hauptverkehrszeit" nicht unnötig zu belasten. Bei nächtlichen Jobs muss aber die Planung der Jobs unbedingt im Einklang mit den Plänen der DB-Sicherung erfolgen, um Probleme zu vermeiden!
• Das regelmässige Zusenden von Log-Infos per Mail ermöglicht frühzeitig auf bestimmte Fehler bei den Jobs zu reagieren.

Log-Einträge in der Webdesk-DB sollten regelmässige gelöscht werden (hierzu gibt es einen eigenen Job!), ansonsten kann die Webdesk-DB zu voll werden und daraus können in weitere Folge Performance-Probleme entstehen.

Jobs im Modul Portal & Organisation

Jobs, welche für das Modul Portal & Organisation relevant sind:

Best Practice

Werden viele Jobs in einem System verwendet, sollte man folgende Grundregeln beachten:

• Man sollte eine kundenspezifische Namenskonvention bei der Vergabe des Jobnamens einhalten, um später den Sinn des Jobs schnell erfassen zu können.
• Das Beschreibungsfeld sollte auch wirklich genutzt werden, um das Ziel des Jobs für den Administrator zu beschreiben (z.B. Hierarchie und Vorgesetzte) z.B. aus anderen Systemen. Start Connector Link Sync Mit diesem konfigurierbaren Job können ein oder mehrere Konnektor-Synchronisation(en) gestartet werdenImport von Personenstammdaten aus IF6020)
• Läuft Webdesk in einem Clusterverbund (mehr als ein Server), so macht es Sinn, die Jobs auf einen Server zu konzentrieren. Ein paralleles (gleichzeitiges) Ausführen desselben Jobs auf unterschiedlichen Cluster-Nodes kann zu unvorhersehbaren Ergebnissen - im schlimmsten Fall zu Datenbank-Inkonsistenzen - führen.
• Rechenintensive Jobs sollten am Abend oder in der Nacht laufen, um die Serverhardware während der "Hauptverkehrszeit" nicht unnötig zu belasten. Bei nächtlichen Jobs muss aber die Planung der Jobs unbedingt im Einklang mit den Plänen der DB-Sicherung erfolgen, um Probleme zu vermeiden!
• Das regelmässige Zusenden von Log-Infos per Mail ermöglicht frühzeitig auf bestimmte Fehler bei den Jobs zu reagieren.
• Log-Einträge in der Webdesk-DB sollten regelmässige gelöscht werden (hierzu gibt es einen eigenen Job!), ansonsten kann die Webdesk-DB zu voll werden und daraus können in weitere Folge Performance-Probleme entstehen.