ERP Austria Scheduler / FlowManager

• Benutzer abmelden und Blacklist
• Installieren des PowerBI Servers über den FlowManager
• Wie kann ich alle Dienste einer Webware oder ERP-Suite beenden?
• Funktionsaufrufe im BWScheduler
• Modale Gruppen im BWScheduler
• BWScheduler über REST-API steuern
• Allgemeiner Überblick über den Scheduler

Benutzer abmelden und Blacklist

Über den Scheduler/FlowManager können über die Aufgabenart "Alle Remotedesktop-Benutzer abmelden" alle User automatisiert vom Server abgemeldet werden. So kann zB. vermieden werden, dass die Sessions immer nur getrennt und so mit der Zeit vermeidbare Probleme generiert werden.

Blacklist

Im Programmverzeichnis gibt es die Datei rds-logoff-blacklist.txt, in der die Bediener eingetragen werden, die nicht abgemeldet werden sollen:

Installieren des PowerBI Servers über den FlowManager

Der Power BI Server muss als Dienst über den FlowManager installiert werden.
Parameter: wwwin64.exe User Passwort /F
Beispiel: wwwin64.exe 510 510 /F

Es ist Folgendes zu beachten: Verzögerter Start des Dienstes: Aktivieren Berechtigungen prüfen! (Hat der Dienstuser auch genügend Berechtigungen im ERP-Suite-Ordner) Kein Neustart bei Dienstfehlern (das schlägt sich mit der NoLock.ini, wenn der Dienst aufgrund dieser beendet wird) Abhängigkeit des Dienstes zur ZEN-Datenbank einfügen!

Wie kann ich alle Dienste einer Webware oder ERP-Suite beenden?

Hierfür gibt es die Aufgabevorlagen: "Webware und alle Dienste beenden" und "ERP-Suite und alle Dienste beenden"

Beim Erstellen der Aufgabe wird eine entsprechende Konfigurationsdatei im Programmpfad erstellt, welche die zu beendenden Dienste und Prozesse enthält.
Diese Datei kann natürlich einen beliebigen Namen haben und darf auch in einem anderen Pfad liegen (mit Pfadangabe).

Diese Liste enthält alle Dienste und Prozesse, welche beendet werden sollen.
Abgearbeitet wird diese Liste von oben nach unten.

Dienste:
Dienstname oder Prozessname ohne .exe;DIENST;Wartezeit nach dem Beenden;Dienstpfad (aktuell nicht verwendet)

Beispiel:
wws;DIENST;30
WEBWARE WWS-Produktiv22;DIENST;30
Dieser Eintrag beendet den Dienst wws (idealerweise wird hier der Displayname des Dienstes angegeben!)
und wartet anschließend noch 30 Sekunden, bevor der nächste Dienst beendet wird.

Prozesse:
Prozessname ohne .exe;Programmpfad (optional)
Wenn ein Prozessname ohne Pfad angegeben wird, dann werden ALLE Prozesse im Speicher mit dieser Signatur beendet.
Wichtig: Der Programmpfad wird als Teilstring geprüft und prüft den Pfad von links beginnend!

Beispiel:
wwwin64;X:\ERPSuite --> beendet alle Prozesse auch unter X:\ERPSuite_TEST
wwwin64;X:\ERPSuite\ --> beendet nur Prozesse unter X:\ERPSuite\*... aber auch X:\ERPSuite\TEST1 und X:\ERPSuite\Test2

Wie läuft so ein Beenden ab?
Zuerst wird der Inhalt der WWProzessliste.DAT oder der angegebenen Datei ausgelesen und geprüft.
Hierbei werden die verschiedenen Parameter ausgelesen und die Dienste und Prozesse vom System geprüft, ob diese auch vorhanden sind.
Anschließend wird eine NoLock.ini im Programmpfad der in den globalen Einstellungen hinterlegten ERP-Suite erstellt.
Wenn andere Instanzen in komplett unterschiedlichen Pfaden beendet werden sollen, müsste das Anlegen der INI entweder über eine weitere Aufgabe erfolgen oder in einer Aufgabengruppe ausgeführt werden.
Dann werden alle Dienste nach einander beendet und anschließend geprüft, ob die Prozesse noch im Speicher sind.
Sollte sich ein Prozess nicht beenden lassen, wird anschließend versucht, diesen Prozess über den Kill-Befehl zu beenden.

ACHTUNG: Hierfür darf im Dienst nicht eingestellt sein, dass dieser sich im Fehlerfall neu startet!

Anschließend werden die gefundenen Prozesse beendet.

Hier kann auch zur Sicherheit z. B. als Option auch noch der Prozess "wwr" angegeben werden.

Welche Version wird hier empfohlen/benötigt?
BWScheduler/FlowManger ab Version 5.07

Wie ist ein Prozess anzugeben?
Prozesse müssen immer OHNE die Dateiendung angegeben werden.

Wie sind Dienste anzugeben?
Dienste werden am besten über den Dienstnamen beendet. Somit ist die Instanz immer korrekt zugeordnet.
Alternativ kann auch der Prozessname angegeben werden. z. B. "wwr" oder "wws"
Hierbei wird der ERSTE gefundene Dienst beendet, wo dieser Prozessname zutrifft.

Sind immer alle Parameter in der WW/BWProzesslite.dat anzugeben?
Nein, bei Diensten muss DIENST angegeben werden und bei Prozessen reicht der Prozessname ohne .exe
Das Semikolon ist nur bei angegebenen Parametern erforderlich und kann weggelassen werden.

Wichtig: Der WWS muss immer VOR dem WWR beendet werden!

wws;DIENST
SoftENGINE BWMail;DIENST;15;X:\ERPSuite\Produktiv
wws32;DIENST
wws32;DIENST
wws64;DIENST
wws64;DIENST
wwwin32;x:\BWERP.700\
wwwin64
wwin32d
wwin64d
bwwin32
bwwin64
bwwin32d
bwwin64d
wwmail
wwmail64
wwsyssrv
wwdesk
dbgdump
wwdba32
wwdba64
wwdba
wwflwsrv
wwa
wwad
wwsvc32
wwsvc64

Funktionsaufrufe im BWScheduler

Überblick

Der BWScheduler stellt integrierte Funktionen bereit, die über einen Namen mit vorangestelltem $ ausgewählt werden. Damit können beispielsweise NoLock-Dateien verwaltet, Dateien überwacht, Windows-Dienste gesteuert oder Datenimporte gestartet werden.

Diese Dokumentation richtet sich an Anwender und Administratoren. Vor dem Einsatz von Funktionen, die Dateien, Prozesse, Dienste oder Benutzersitzungen beenden, sollte die Aufgabe zuerst in einer Testumgebung geprüft werden.

Allgemeine Einrichtung

Für die nachfolgend beschriebenen Funktionen wird bei der Aufgabe grundsätzlich Folgendes eingestellt:

Einmalige tägliche Ausführung

Für eine einmalige Ausführung zu einer festen Uhrzeit:

• Intervall: 0
• Ausführungszeit: gewünschte Startzeit
• Zeit von: Beginn des erlaubten Zeitraums
• Zeit bis: Ende des erlaubten Zeitraums

Beispiel:

Die Ausführungszeit muss innerhalb des erlaubten Zeitraums liegen. Für einen Zeitraum innerhalb desselben Tages muss Zeit bis später als Zeit von sein.

Wiederkehrende Ausführung

Für eine wiederkehrende Ausführung:

• Intervall: Abstand in Minuten, beispielsweise 15
• Ausführungszeit: leer lassen
• Zeit von / Zeit bis: Zeitraum, in dem die Wiederholungen erlaubt sind

AppParameter und AppParameter2

Je nach Funktion werden zusätzliche Angaben benötigt:

• AppParameter: meistens Dateipfad, Ordnerpfad oder eine Funktionsoption
• AppParameter2: zusätzliche Angabe, beispielsweise Dateialter oder Zielaufgabe
• Dienstname: Name eines Windows-Dienstes oder Prozesses

Nicht benötigte Felder bleiben leer.

Kurzreferenz

NoLock- und Wartungsfunktionen

$CREATENOLOCKINI

Erstellt im eingestellten ERP-Suite-Programmpfad eine NoLock.ini. Dadurch werden ERP-Suite und zugehörige Dienste in den vorgesehenen Wartungszustand versetzt. Solange die NoLock-Datei vorhanden ist, werden normale Scheduler-Aufgaben angehalten.

Empfohlene Einstellungen:

Voraussetzungen:

• Der globale ERP-Suite-Pfad muss richtig eingestellt und erreichbar sein.
• Das Benutzerkonto des BWSchedulers benötigt Schreibrechte im ERP-Suite-Ordner.
• Es sollte eine passende Aufgabe zum späteren Entfernen der NoLock-Datei vorhanden sein.

$DELETENOLOCKINI

Entfernt NoLock-Dateien, die vom BWScheduler selbst erstellt wurden. Fremd oder manuell angelegte NoLock-Dateien bleiben zum Schutz erhalten.

Empfohlene Einstellungen:

Wird die NoLock-Datei für längere Wartungsarbeiten benötigt, muss die Löschaufgabe entsprechend später eingeplant werden.

$DELETEALLNOLOCKINI

Entfernt alle vom BWScheduler gefundenen NoLock-Dateien – unabhängig davon, wodurch sie angelegt wurden.

Achtung: Diese Funktion kann auch eine bewusst manuell gesetzte Wartungssperre entfernen. Sie sollte nur durch berechtigte Administratoren und nur für eindeutig definierte Wartungsabläufe verwendet werden.

Empfohlene Einstellungen:

• Aufgabenart: Funktionsaufruf
• App: $DELETEALLNOLOCKINI
• AppParameter / AppParameter2: leer
• Modale Gruppe: keine (Global)
• Zeitpunkt: nur innerhalb eines kontrollierten Wartungsfensters

$AUSLOGGEN

Erstellt eine NoLock-Datei, wartet ungefähr 30 Sekunden und entfernt sie anschließend wieder. Die Funktion ist dafür vorgesehen, laufende ERP-Suite-Module zum geordneten Beenden beziehungsweise Abmelden aufzufordern.

Empfohlene Einstellungen:

• App: $AUSLOGGEN
• AppParameter / AppParameter2: leer
• Intervall: 0
• Modale Gruppe: keine (Global)
• Ausreichend Abstand zu nachfolgenden Aufgaben einplanen

Beispiel: Ausführung um 23:00 innerhalb eines erlaubten Zeitraums von 19:30 bis 23:55.

ERP-Suite- und Prozesssteuerung

$BÜROWARE-BEENDEN

Versetzt die ERP-Suite zunächst in den Wartungszustand, wartet ungefähr 30 Sekunden und beendet danach die vorgesehenen ERP-Suite-Prozesse und Dienste. Nach einer weiteren Kontrolle werden noch vorhandene Prozesse erneut beendet. Anschließend wird die vom Scheduler erstellte NoLock-Datei entfernt.

Empfohlene Einstellungen:

• App: $BÜROWARE-BEENDEN
• AppParameter: Pfad zur vorgesehenen ERP-Suite-Prozesslistendatei oder leer für die Standardliste
• Intervall: 0
• Modale Gruppe: keine (Global)
• Zeitfenster: außerhalb der normalen Arbeitszeit

Achtung: Offene ERP-Suite-Sitzungen können beendet werden. Stimmen Sie die Ausführung mit den Anwendern ab und prüfen Sie die verwendete Prozessliste sorgfältig.

$WEBWARE-BEENDEN

Entspricht dem Ablauf von $BÜROWARE-BEENDEN, verwendet jedoch die für Webware vorgesehenen Prozesse und Dienste.

Empfohlene Einstellungen:

• App: $WEBWARE-BEENDEN
• AppParameter: Pfad zur Webware-Prozesslistendatei oder leer für die Standardliste
• Intervall: 0
• Modale Gruppe: keine (Global)
• Zeitfenster: außerhalb der normalen Nutzung

$PROZESSE-BEENDEN

Beendet die Einträge einer Prozesslistendatei. Nach einer kurzen Wartezeit wird erneut geprüft und ein zweiter Beendigungsversuch durchgeführt.

Empfohlene Einstellungen:

• App: $PROZESSE-BEENDEN
• AppParameter: vollständiger Pfad zur Prozesslistendatei; leer verwendet die allgemeine Standardliste
• Intervall: 0
• Modale Gruppe: eigene Farbgruppe für den betroffenen Arbeitsablauf oder Global

Achtung: Prüfen Sie jeden Eintrag der Prozessliste. Eine falsche Liste kann nicht vorgesehene Anwendungen oder Dienste beenden.

$PROZESSE-STARTEN

Startet die in einer Prozesslistendatei hinterlegten Prozesse und Dienste.

Empfohlene Einstellungen:

• App: $PROZESSE-STARTEN
• AppParameter: vollständiger Pfad zur Prozesslistendatei; leer verwendet die allgemeine Standardliste
• Netzwerklaufwerk verbinden: aktivieren, wenn Programme oder Dateien über ein Laufwerk im Netzwerk erreicht werden
• Modale Gruppe: dieselbe Gruppe wie die zugehörige Beendigungs- oder Wartungsaufgabe

Planen Sie den Start erst nach Abschluss aller Wartungs- und Sicherungsarbeiten ein.

$KILLPROCESS

Beendet alle laufenden Prozesse mit dem angegebenen Prozessnamen sofort.

Empfohlene Einstellungen:

Achtung: Diese Funktion ermöglicht kein geordnetes Speichern oder Beenden. Sie sollte nur verwendet werden, wenn ein normales Beenden nicht möglich oder ausdrücklich unerwünscht ist.

Windows-Dienste steuern

$STARTSERVICE

Startet den unter Dienstname angegebenen Windows-Dienst. Läuft der Dienst bereits, bleibt er unverändert.

$STOPSERVICE

Stoppt den unter Dienstname angegebenen Windows-Dienst. Ist der Dienst bereits beendet, ist keine weitere Aktion erforderlich.

$RESTARTSERVICE

Stoppt den angegebenen Windows-Dienst und startet ihn anschließend erneut. Der BWScheduler wartet auf das Beenden des Dienstes und versucht danach den Start.

Empfohlene Einstellungen für alle drei Dienstfunktionen:

Voraussetzungen:

• Der angegebene Dienst muss auf demselben Windows-System vorhanden sein.
• Das Benutzerkonto des BWSchedulers benötigt die Berechtigung zum Steuern des Dienstes.
• Bei abhängigen Diensten muss eine sinnvolle Reihenfolge und ausreichend Zeitabstand eingeplant werden.

Dateifunktionen

$CREATEFILE

Erstellt eine Datei am angegebenen Ort. Eine bereits vorhandene Datei wird ersetzt. Die Funktion eignet sich insbesondere zum Erzeugen von Steuer- oder Triggerdateien.

Empfohlene Einstellungen:

• App: $CREATEFILE
• AppParameter: vollständiger Dateipfad, beispielsweise C:\ERP\Export\run.ini
• AppParameter2: leer
• Netzwerklaufwerk verbinden: aktivieren, wenn ein hinterlegtes Netzlaufwerk verwendet wird

Der Zielordner muss bereits vorhanden sein und das verwendete Konto benötigt Schreibrechte.

$DELETEFILE

Löscht genau die unter AppParameter angegebene Datei.

Empfohlene Einstellungen:

• App: $DELETEFILE
• AppParameter: vollständiger Dateipfad
• AppParameter2: leer
• Modale Gruppe: dieselbe Gruppe wie eine zugehörige Erstellungs- oder Verarbeitungsaufgabe

Achtung: Kontrollieren Sie den vollständigen Pfad vor der Aktivierung. Die gelöschte Datei wird nicht in den Windows-Papierkorb verschoben.

$DELETEFILES

Löscht mehrere Dateien eines bestimmten Musters, sobald sie das angegebene Alter erreicht haben.

Beispiel:

In diesem Beispiel werden passende Protokolldateien berücksichtigt, die älter als 30 Tage sind.

Hinweise:

• Verwenden Sie im AppParameter einen vollständigen Ordnerpfad mit Dateimaske.
• Prüfen Sie die Dateimaske besonders sorgfältig.
• Der Ordner muss erreichbar sein.
• Verwenden Sie möglichst ein eigenes, klar begrenztes Archiv- oder Protokollverzeichnis.

Dateiüberwachung

$DATEIÜBERWACHUNG

Überwacht eine bestimmte Datei auf Änderungen. Wird eine Änderung erkannt, plant der BWScheduler eine andere Aufgabe zur Ausführung ein.

Empfohlene Einstellungen der Überwachungsaufgabe:

Beispiel:

AppParameter:  C:\ERP\Import\auftrag.dat
AppParameter2: RUN(5)

Damit wird bei einer Änderung der Datei die Aufgabe 5 eingeplant.

Voraussetzungen für die Zielaufgabe:

• Die Zielaufgabe muss aktiviert sein.
• Die Zielaufgabe muss Intervall 0 verwenden.
• Überwachungsaufgabe und Zielaufgabe dürfen nicht dieselbe Aufgabe sein.
• Unter Mindestwartezeit bei Triggerausführung sollte ein ausreichender Abstand eingestellt werden, damit mehrere unmittelbar aufeinanderfolgende Dateiänderungen nicht zu wiederholten Starts führen.

Bei Netzwerkpfaden muss der Pfad aus dem Ausführungskonto des BWSchedulers erreichbar sein.

DTA-Datenimport

$DTAIMPORT

Importiert .dta-Dateien aus einem angegebenen Ordner. Erfolgreich verarbeitete Dateien werden in den Unterordner Importiert verschoben.

Empfohlene Einstellungen:

Alternativ können Bedienernummer, Mandantennummer und Importmodul zentral im Bereich Datenimport eingestellt werden.

Zu prüfen sind:

• Importordner ist vorhanden und beschreibbar.
• ERP-Suite-Programmpfad ist korrekt.
• Bedienernummer und Mandantennummer sind gültig.
• Gewünschtes Importmodul ist ausgewählt: WAWI, FIBU oder automatische Erkennung über den Dateinamen.
• Bei automatischer Erkennung sollte der Dateiname eindeutig WAWI oder FIBU enthalten.

Während einer aktiven NoLock-Sperre beziehungsweise Wartung wird kein DTA-Import durchgeführt.

Netzlaufwerke verbinden

$NETZWERKLAUFWERK-VERBINDEN

Verbindet die im Bereich Netzwerk hinterlegten Netzlaufwerke.

Für bis zu drei Verbindungen können eingestellt werden:

• Server-Pfad, beispielsweise \\Server\Freigabe
• Zugewiesener Laufwerksbuchstabe
• Benutzer
• Kennwort
• Persistente Verbindung

Empfohlene Aufgabeneinstellungen:

• App: $NETZWERKLAUFWERK-VERBINDEN
• AppParameter / AppParameter2: leer
• Zeitpunkt: vor allen Aufgaben, die diese Laufwerke benötigen
• Modale Gruppe: passend zu den abhängigen Aufgaben

Die Einstellung Netzwerklaufwerk verbinden innerhalb einer einzelnen Aufgabe kann zusätzlich verwendet werden, damit die hinterlegten Verbindungen unmittelbar vor dieser Aufgabe hergestellt werden.

Remotedesktop-Sitzungen abmelden

$RDS-LOGOFF

Meldet Remotedesktop-Benutzersitzungen entsprechend der gewählten Option ab.

Beispiel:

/U=m.mustermann

Empfohlene Einstellungen:

• App: $RDS-LOGOFF
• Intervall: 0
• Modale Gruppe: keine (Global)
• Zeitfenster: außerhalb der normalen Arbeitszeit

Achtung: Nicht gespeicherte Benutzerdaten können verloren gehen. Informieren Sie betroffene Benutzer vor einer automatischen Abmeldung.

Bestimmte administrative Benutzer können über die Datei rds-logoff-blacklist.txt von der automatischen Abmeldung ausgenommen werden. Änderungen an dieser Liste sollten nur durch die zuständige Administration erfolgen.

ERP-Suite Software-Audit

$SOFTWAREAUDIT

Erfasst die vorgesehenen ERP-Suite-Systeminformationen und führt den eingerichteten Datenabgleich durch.

Empfohlene Einstellungen:

• Verwenden Sie vorzugsweise die vorbereitete Aufgabe ERP-Suite Software Audit.
• Hinterlegen Sie bei der Einrichtung die korrekte Kundennummer und die vom Anbieter bereitgestellte Freigabe.
• Stellen Sie sicher, dass der ERP-Suite-Pfad korrekt ist.
• Planen Sie die Aufgabe einmal täglich außerhalb der Hauptarbeitszeit ein.
• AppParameter / AppParameter2: leer

Diese Funktion sollte nur verwendet werden, wenn der Software-Audit für das jeweilige Kundensystem eingerichtet und freigegeben wurde.

Empfohlene Reihenfolge für ein Wartungsfenster

Ein möglicher Ablauf ist:

1. Mit $AUSLOGGEN Benutzer zum Beenden der ERP-Suite-Sitzungen auffordern.
2. Mit $CREATENOLOCKINI den Wartungszustand aktivieren.
3. Mit $BÜROWARE-BEENDEN, $WEBWARE-BEENDEN oder $PROZESSE-BEENDEN benötigte Komponenten beenden.
4. Sicherung, Aktualisierung oder andere Wartungsaufgabe durchführen.
5. Mit $PROZESSE-STARTEN oder $STARTSERVICE benötigte Komponenten wieder starten.
6. Mit $DELETENOLOCKINI den Wartungszustand aufheben.

Verwenden Sie für den gesamten Ablauf dieselbe modale Farbgruppe oder keine (Global), wenn während der Wartung keine andere modale Aufgabe laufen darf. Planen Sie zwischen den einzelnen Schritten ausreichend Zeit ein.

Sicherheits- und Prüfhinweise

Vor der Aktivierung einer neuen Funktionsaufgabe:

1. Pfade, Dateimasken, Dienstnamen und Prozessnamen kontrollieren.
2. Berechtigungen des Kontos prüfen, unter dem der BWScheduler ausgeführt wird.
3. Zeitfenster und Wochentage kontrollieren.
4. Bei Intervall 0 eine gültige Ausführungszeit innerhalb des Zeitfensters eintragen.
5. Bei Intervall größer 0 die Ausführungszeit leer lassen.
6. Eine geeignete modale Gruppe auswählen.
7. Kritische Funktionen zunächst manuell in einer Testumgebung ausführen.
8. Nach der Ausführung die Aufgabenanzeige und das Protokoll kontrollieren.

Besondere Vorsicht ist bei $DELETEALLNOLOCKINI, $DELETEFILE, $DELETEFILES, $KILLPROCESS, $PROZESSE-BEENDEN, $BÜROWARE-BEENDEN, $WEBWARE-BEENDEN und $RDS-LOGOFF erforderlich.

Modale Gruppen im BWScheduler

Überblick

Modale Gruppen steuern, welche modalen Aufgaben gleichzeitig ausgeführt werden dürfen. Dadurch lassen sich Aufgaben voneinander trennen, die nicht parallel laufen sollen, während unabhängige Aufgaben weiterhin gleichzeitig gestartet werden können.

Die Zuordnung erfolgt direkt in den Einstellungen der jeweiligen Aufgabe. Zur besseren Übersicht wird die gewählte Gruppe außerdem in der Aufgabenliste mit ihrer entsprechenden Farbe angezeigt.

Grundprinzip

Für modale Aufgaben gelten folgende Regeln:

• Aufgaben derselben Farbgruppe werden nacheinander ausgeführt.
• Aufgaben unterschiedlicher Farbgruppen dürfen gleichzeitig ausgeführt werden.
• Die Einstellung keine wird als globale modale Gruppe behandelt.
• Eine globale modale Aufgabe darf nur starten, wenn keine andere modale Aufgabe läuft.
• Solange eine globale modale Aufgabe läuft, kann keine andere modale Aufgabe starten.
• Nicht-modale Aufgaben sind von der Gruppensteuerung nicht betroffen.

Die Gruppenzuordnung erfolgt anhand der Scheduler-Aufgabe. Gleichlautende Prozess- oder Aufgabennamen haben daher keinen Einfluss auf die Unterscheidung.

Verfügbare Gruppen

Beispiele

Zwei Aufgaben in derselben Gruppe

Aufgabe A und Aufgabe B sind beide der Gruppe Grün zugeordnet.

Wenn Aufgabe A bereits läuft, wartet Aufgabe B, bis Aufgabe A beendet ist. Erst danach wird Aufgabe B gestartet.

Aufgaben in unterschiedlichen Gruppen

Aufgabe A ist der Gruppe Grün und Aufgabe B der Gruppe Blau zugeordnet.

Beide Aufgaben dürfen gleichzeitig laufen, da sie unterschiedlichen Gruppen angehören.

Aufgabe ohne Farbgruppe

Aufgabe A verwendet die Einstellung keine (Global). Aufgabe B ist der Gruppe Orange zugeordnet.

• Läuft Aufgabe B bereits, wartet Aufgabe A.
• Läuft Aufgabe A bereits, wartet Aufgabe B.
• Aufgabe A startet erst, wenn keine andere modale Aufgabe aktiv ist.

Mehrere gleichnamige Aufgaben

Mehrere Aufgaben dürfen denselben Namen besitzen. Für die Steuerung ist ausschließlich die bei der jeweiligen Scheduler-Aufgabe eingestellte modale Gruppe maßgeblich.

Beispiel:

• „Datenabgleich“ in Gruppe Grün
• „Datenabgleich“ in Gruppe Blau

Diese beiden Aufgaben dürfen gleichzeitig ausgeführt werden, obwohl ihre Bezeichnungen identisch sind.

Modale Gruppe einstellen

1. Öffnen Sie im BWScheduler die Einstellungen der gewünschten Aufgabe.
2. Stellen Sie sicher, dass eine modale Aufgabenart ausgewählt ist.
3. Wählen Sie unter Modale Gruppe die gewünschte Farbe oder keine aus.
4. Speichern Sie die Einstellung.
5. Kontrollieren Sie die Zuordnung in der Spalte Modale Gruppe der Aufgabenliste.

Anzeige in der Aufgabenliste

Die Spalte Modale Gruppe zeigt die aktuelle Zuordnung jeder Aufgabe:

• Bei einer Farbgruppe enthält die Zelle den Gruppennamen und wird passend eingefärbt.
• Bei keine wird Global angezeigt.
• Bei nicht-modalen Aufgaben wird ein Gedankenstrich angezeigt.

Damit kann die Gruppenzuordnung auch bei gleichnamigen Aufgaben direkt kontrolliert werden.

Empfohlene Zuordnung

Verwenden Sie dieselbe Farbe für Aufgaben, die auf dieselben Daten, Dateien, Dienste oder sonstigen gemeinsam genutzten Ressourcen zugreifen und deshalb nicht gleichzeitig laufen sollen.

Verwenden Sie unterschiedliche Farben, wenn die Aufgaben unabhängig voneinander sind und parallel ausgeführt werden dürfen.

Verwenden Sie keine (Global) nur für Aufgaben, die während ihrer gesamten Laufzeit jede andere modale Ausführung ausschließen müssen.

Hinweise zur Ausführung

• Eine wartende Aufgabe wird gestartet, sobald ihre Gruppe wieder verfügbar ist.
• Das Warten verändert nicht die eingestellte Startzeit oder das Intervall der Aufgabe.
• Werden mehrere Aufgaben derselben Gruppe gleichzeitig fällig, werden sie nacheinander abgearbeitet.
• Die Farbgruppe ist nur bei modalen Aufgaben wirksam.
• Änderungen an der Gruppenzuordnung gelten nach dem Speichern und Aktualisieren der Einstellungen.

Kontrolle bei unerwartetem Verhalten

Prüfen Sie bei unerwarteten Wartezeiten oder parallelen Ausführungen:

1. Ist die Aufgabe als modale Aufgabe eingerichtet?
2. Ist die erwartete Farbe in der Spalte Modale Gruppe sichtbar?
3. Läuft bereits eine Aufgabe derselben Farbe?
4. Läuft eine Aufgabe mit der Anzeige Global?
5. Haben zwei gleichnamige Aufgaben möglicherweise unterschiedliche Gruppenzuordnungen?

Die Bezeichnung einer Aufgabe oder eines gestarteten Prozesses bestimmt nicht die Gruppenzugehörigkeit. Maßgeblich ist immer die Einstellung Modale Gruppe der jeweiligen Scheduler-Aufgabe.

BWScheduler über REST-API steuern

Überblick

Über die REST-API können mehrere BWScheduler-Installationen verschlüsselt miteinander verbunden werden. Eine Installation übernimmt die Rolle des Servers, die übrigen Installationen arbeiten als Clients.

Eine Installation kann immer nur eine Rolle besitzen:

• Server: Nimmt Verbindungen an und kann Aufträge für Clients bereitstellen.
• Client: Verbindet sich mit dem Server, sendet Aufträge an den Server und fragt Aufträge für sich selbst ab.

Damit können Aufgaben in beide Richtungen ausgelöst werden:

• Client startet eine Aufgabe auf dem Server.
• Server startet eine Aufgabe auf einem oder mehreren Clients.

Es werden keine SchedulerXX.RUN-Dateien benötigt.

Voraussetzungen

• Auf allen beteiligten Systemen muss BWScheduler mindestens in Programmversion 5.31 installiert sein.
• Alle beteiligten BWScheduler müssen über das Netzwerk erreichbar sein.
• Auf dem Server muss der eingestellte TCP-Port freigegeben sein. Standard ist Port 9443.
• Die Uhren der beteiligten Windows-Systeme sollten korrekt eingestellt sein.
• Die auszuführende Zielaufgabe muss auf der Gegenstelle vorhanden und aktiviert sein.
• Die Zielaufgabe muss über die Einstellung REST-API Ausführung ausdrücklich freigegeben sein.
• Zielaufgaben müssen Hauptaufgaben sein. Unteraufgaben können nicht direkt über die REST-API gestartet werden.
• Das Konto des BWSchedulers benötigt weiterhin alle Rechte, die von der Zielaufgabe benötigt werden.

Verschlüsselung und Zertifikate

Der gesamte Datenverkehr wird über TLS 1.2 verschlüsselt.

Internes Zertifikat

Wenn unter SSL-PFX Zertifikat keine Datei angegeben wird, erstellt und verwendet der Server automatisch ein internes Zertifikat. Dieses Zertifikat dient ausschließlich zur Verschlüsselung der Verbindung zwischen den BWSchedulern.

Für die Standardverbindung zwischen BWScheduler-Installationen muss daher kein Zertifikat bereitgestellt werden.

Eigenes PFX-Zertifikat

Optional kann auf dem Server ein eigenes PFX-Zertifikat hinterlegt werden:

• SSL-PFX Zertifikat: vollständiger Pfad zur PFX-Datei
• SSL-PFX Zertifikat Kennwort: Kennwort der PFX-Datei

Das PFX-Zertifikat muss einen privaten Schlüssel enthalten. Der im Zertifikat verwendete Name sollte zur eingestellten Serveradresse passen. Bei einem von einer vertrauenswürdigen Zertifizierungsstelle ausgestellten Zertifikat ist auf den Clients keine Ausnahme erforderlich.

Ungültige Zertifikate erlauben

Die Einstellung Erlaube ungültige SSL-Zertifikate betrifft die Prüfung auf der Clientseite.

• Deaktiviert: Zertifikat und Servername müssen gültig sein. Das automatisch verwendete interne BWScheduler-Zertifikat wird ebenfalls akzeptiert.
• Aktiviert: Zertifikatsfehler werden ignoriert.

Sicherheitshinweis: Aktivieren Sie diese Option nur in einem kontrollierten und vertrauenswürdigen Netzwerk.

Authentifizierung

Unter Authentifizierungsart stehen drei Möglichkeiten zur Verfügung:

Die empfohlene Einstellung für eine Verbindung zwischen BWSchedulern ist Nur eigene Produkte.

Der kundenspezifische API-Key wird nur bei der Authentifizierungsart API-Key benötigt. Er sollte ausreichend lang und zufällig sein und darf nicht an unberechtigte Personen weitergegeben werden.

Server einrichten

Öffnen Sie die Einstellungen und wechseln Sie zum Bereich REST-API.

Speichern Sie die Einstellungen und starten Sie den BWScheduler neu beziehungsweise laden Sie die Einstellungen neu.

Der Server nimmt verschlüsselte Verbindungen auf allen lokalen Netzwerkadressen über den eingestellten Port an. Stellen Sie sicher, dass die Windows-Firewall eingehende Verbindungen für diesen Port erlaubt.

Client einrichten

Öffnen Sie auf jedem Client den Bereich REST-API.

Beispiele für die Serveradresse:

192.168.1.20
scheduler.firma.local
https://scheduler.firma.local

Der Client baut ausschließlich eine ausgehende Verbindung zum Server auf. Auf dem Client muss deshalb kein eingehender REST-Port geöffnet werden.

Als Clientname wird automatisch der Windows-Rechnername verwendet. Dieser Name wird benötigt, wenn der Server einen Auftrag nur an einen bestimmten Client senden soll.

Aufgabe auf der Gegenstelle ausführen

Erstellen Sie über Neu die Aufgabe:

REST-API Aufgabe auf Gegenstelle ausführen

Die Aufgabe wird mit folgenden Werten vorbereitet:

Passen Sie die Aufgabennummer, Ausführungszeit, Wochentage und das erlaubte Zeitfenster an den gewünschten Ablauf an.

Client startet eine Aufgabe auf dem Server

Auf dem Client wird eine Aufgabe mit folgendem AppParameter angelegt:

Execute=22

Wird diese Aufgabe auf dem Client ausgeführt, sendet er den Auftrag verschlüsselt an den Server. Der Server plant dort die aktivierte Hauptaufgabe mit der Scheduler-ID 22 ein.

Die Zielaufgabe auf dem Server muss vorhanden, aktiviert, als Hauptaufgabe eingerichtet und über REST-API Ausführung freigegeben sein.

REST-Freigabe der Zielaufgabe

Jede Zielaufgabe besitzt die Einstellung REST-API Ausführung. Standardmäßig ist eine Aufgabe nicht über REST erreichbar.

Die Freigabe wird auf der Seite eingestellt, auf der die Zielaufgabe tatsächlich ausgeführt wird. Für eine reine Sendeaufgabe mit $RESTAPI-EXECUTE ist keine eingehende REST-Freigabe erforderlich.

Zusammenspiel der Einstellungen

Empfohlene Konfigurationen

BWScheduler mit BWScheduler verbinden

Auf Server und Clients:

Bei der auszuführenden Zielaufgabe:

REST-API Ausführung: Nur durch BWScheduler

Diese Einstellung erfordert keine manuelle Schlüsselpflege durch den Kunden.

Externes System mit API-Key

Auf dem REST-Server:

Bei der auszuführenden Zielaufgabe:

REST-API Ausführung: Gemäß globaler Authentifizierung

Das externe System muss den eingestellten API-Key bei jedem Auftrag mitsenden.

Einzelne Aufgabe ohne Authentifizierung

Bei der betreffenden Zielaufgabe:

REST-API Ausführung: Ohne Authentifizierung

Diese Freigabe gilt unabhängig von der globalen Authentifizierungsart. Verwenden Sie sie nur für gezielt ausgewählte Aufgaben und begrenzen Sie den Netzwerkzugriff zusätzlich über die Windows-Firewall.

Wichtig: Verwenden Sie für sensible Wartungs-, Programmstart- oder Beendigungsaufgaben keine anonyme Freigabe.

Server startet eine Aufgabe auf allen Clients

Auf dem Server wird eine Aufgabe mit folgendem AppParameter angelegt:

Execute=22

Der Server stellt den Auftrag allen Clients bereit, die sich seit dem Start des Servers bei ihm gemeldet haben. Jeder dieser Clients plant seine lokale Aufgabe mit der Scheduler-ID 22 ein.

Die Scheduler-ID bezeichnet immer die Aufgabe auf der jeweiligen Gegenstelle. Die Aufgaben dürfen auf Server und Clients unterschiedliche Bezeichnungen oder Inhalte besitzen.

Server startet eine Aufgabe auf einem bestimmten Client

Soll nur ein bestimmter Client angesprochen werden, wird dessen Windows-Rechnername ergänzt:

Client=PC-BUCHHALTUNG&Execute=22

Damit wird die Aufgabe 22 ausschließlich für den Client PC-BUCHHALTUNG bereitgestellt.

Der Clientname muss dem Windows-Rechnernamen des Zielsystems entsprechen. Groß- und Kleinschreibung sind dabei nicht relevant.

Mehrere Clients

Mehrere Clients können denselben Server verwenden. Dabei gibt es zwei Möglichkeiten:

• Nur Execute=22: Auftrag wird an alle beim Server bekannten Clients verteilt.
• Client=RECHNERNAME&Execute=22: Auftrag wird nur für den angegebenen Client bereitgestellt.

Ein Auftrag für einen bestimmten Client kann bereits bereitgestellt werden, bevor dieser wieder verbunden ist. Er wird beim nächsten erfolgreichen Abruf übernommen, solange der Server zwischenzeitlich nicht neu gestartet wurde.

Direkter REST-Aufruf am Server

Der Server nimmt einen Ausführungsauftrag unter folgender Adresse entgegen:

https://SERVER:9443/api/scheduler/execute

Ausführungsaufträge werden ausschließlich mit der HTTP-Methode POST angenommen. Execute=22 wird dabei als formularcodierter Inhalt gesendet.

Bei der Authentifizierungsart API-Key wird der Schlüssel im HTTP-Header übergeben:

X-PHX-API-Key: IHR_API_KEY

Bei Nur eigene Produkte werden Produktkennung, Schlüsselkennung und Produktschlüssel automatisch durch das aufrufende PHX-Produkt übergeben. Eine manuelle Eingabe ist nicht vorgesehen.

Zur Verfügbarkeitsprüfung steht folgende Adresse bereit:

https://SERVER:9443/api/scheduler/status

Eine erfolgreiche Prüfung liefert OK zurück.

Sicherheitshinweis: Begrenzen Sie den Zugriff auf den REST-Port über die Windows-Firewall auf die vorgesehenen Clientsysteme beziehungsweise das interne Netzwerk.

Verhalten der Zielaufgabe

Ein angenommener REST-Auftrag verhält sich weitgehend wie ein Auftrag über eine SchedulerXX.RUN-Datei:

• Die Zielaufgabe wird beim nächsten Scheduler-Durchlauf eingeplant.
• Die Aufgabe muss aktiviert sein.
• Unteraufgaben können nicht direkt gestartet werden.
• Die eingestellte modale Gruppe und der Doppelstartschutz bleiben wirksam.
• Eine bereits laufende oder bereits eingeplante Aufgabe wird nicht nochmals parallel gestartet.
• Eine aktive Wartungs- oder NoLock-Sperre kann die Ausführung weiterhin zurückhalten.

Die Zeitplanung der sendenden $RESTAPI-EXECUTE-Aufgabe bestimmt, wann der Auftrag übertragen wird. Die feste Ausführungszeit der Zielaufgabe wird durch den angenommenen Remote-Auftrag nicht abgewartet.

Typischer Einrichtungsablauf

1. Prüfen, ob auf allen beteiligten Systemen mindestens BWScheduler-Programmversion 5.31 installiert ist.
2. Eine BWScheduler-Installation als Server konfigurieren.
3. Port 9443 oder den gewählten Port in der Server-Firewall freigeben.
4. Weitere Installationen als Clients konfigurieren.
5. Verbindung im Protokoll kontrollieren.
6. Auf der Gegenstelle eine ungefährliche Testaufgabe anlegen und aktivieren.
7. Bei der Zielaufgabe die gewünschte Einstellung unter REST-API Ausführung auswählen.
8. Auf der sendenden Seite eine $RESTAPI-EXECUTE-Aufgabe mit der entsprechenden Scheduler-ID erstellen.
9. Auftrag zunächst manuell ausführen.
10. Ausführung und Ergebnis auf beiden Seiten kontrollieren.
11. Erst danach die gewünschte Zeitplanung aktivieren.

Fehlerprüfung

Server ist nicht erreichbar

Prüfen Sie:

• REST-API ist auf beiden Seiten aktiviert.
• Server verwendet die Betriebsart Server.
• Client verwendet die Betriebsart Client.
• Serveradresse und Port stimmen überein.
• Windows-Firewall erlaubt den Port.
• Der Serverprozess läuft.

Zertifikatsfehler

Prüfen Sie:

• Stimmt der DNS-Name mit dem eigenen Zertifikat überein?
• Ist das Zertifikat noch gültig?
• Ist die Zertifikatskette auf dem Client vertrauenswürdig?
• Ist das PFX-Kennwort korrekt?

Die Option zum Ignorieren von Zertifikatsfehlern sollte nur vorübergehend zur Eingrenzung des Problems verwendet werden.

Aufgabe wird nicht ausgeführt

Prüfen Sie:

• Ist die angegebene Scheduler-ID auf der Gegenstelle vorhanden?
• Ist die Zielaufgabe aktiviert?
• Handelt es sich um eine Hauptaufgabe?
• Ist die Zielaufgabe über REST-API Ausführung passend freigegeben?
• Stimmen Authentifizierungsart und gegebenenfalls API-Key auf beiden Seiten überein?
• Läuft die Aufgabe bereits oder wartet sie auf ihre modale Gruppe?
• Ist eine Wartungs- oder NoLock-Sperre aktiv?
• Ist im AppParameter tatsächlich Execute=Zahl eingetragen?

Bestimmter Client erhält den Auftrag nicht

Prüfen Sie:

• Entspricht der Wert hinter Client= exakt dem Windows-Rechnernamen?
• Hat sich der Client bereits erfolgreich beim Server gemeldet?
• Wurde der Server nach dem Bereitstellen des Auftrags neu gestartet?

Allgemeiner Überblick über den Scheduler

Überblick

Der BWScheduler führt wiederkehrende oder gezielt ausgelöste Aufgaben automatisch aus. Typische Einsatzbereiche sind:

• Starten von ERP-Suite-Aufgaben, Programmen und Skripten
• Aufrufen vorbereiteter Wartungs- und Systemfunktionen
• Starten, Stoppen oder Neustarten von Windows-Diensten
• Überwachen von Dateien und Ordnern
• Auslösen einer Aufgabe über eine SchedulerXX.RUN-Datei
• Auslösen einer Aufgabe auf einem verbundenen BWScheduler über die REST-API

Jede Aufgabe besitzt eine eindeutige Scheduler-ID. Die Bezeichnung dient der Übersicht und darf bei mehreren Aufgaben gleich sein. Für gezielte Aufrufe ist immer die Scheduler-ID maßgeblich.

Zeitsteuerung des BWSchedulers

Die globale Einstellung Zeitsteuerung legt fest, in welcher Betriebsart geplante Aufgaben ausgeführt werden dürfen.

Optional kann die Zeitsteuerung auf einen bestimmten Windows-Benutzer eingeschränkt werden. Die Schaltfläche zum manuellen Starten der Zeitsteuerung kann eine unpassende Betriebsart oder Benutzerbeschränkung nicht übersteuern.

Wichtig: Ist die Einstellung Zeitsteuerung nicht korrekt gesetzt, bleiben geplante Aufgaben in der betreffenden Instanz inaktiv.

Aufgabenarten

Bei modalen Aufgaben kann zusätzlich eine Modale Gruppe eingestellt werden. Aufgaben derselben Farbgruppe werden nacheinander ausgeführt. Aufgaben verschiedener Farbgruppen dürfen parallel laufen. keine (Global) sperrt sich mit allen modalen Gruppen. Weitere Einzelheiten enthält die Kundendokumentation Modale Gruppen im BWScheduler.

Wichtige Einstellungen einer Aufgabe

Je nach Aufgabenart können weitere Einstellungen sichtbar oder erforderlich sein, beispielsweise Dienstname, Netzlaufwerk, Benachrichtigung oder Dateifilter.

Zeitgesteuerte Ausführung

Ausführung zu einer festen Uhrzeit

Für eine einmalige Ausführung pro passendem Tag wird Intervall auf 0 gesetzt. Die Ausführungszeit muss innerhalb von Zeit von und Zeit bis liegen.

Beispiel:

Die Aufgabe wird an den gewählten Wochentagen einmal um 05:31 Uhr ausgeführt.

Plausibilitätsprüfung: Bei einem Zeitfenster innerhalb desselben Tages muss Zeit bis später als Zeit von sein. Eine Ausführungszeit außerhalb des Fensters ist nicht zulässig.

Wiederkehrende Ausführung

Ist Intervall größer als 0, erfolgt die Wiederholung in Minuten. Der nächste Lauf richtet sich nach der letzten Ausführungszeit und muss weiterhin in einem erlaubten Zeitfenster und an einem erlaubten Wochentag liegen.

Beispiel: Bei Intervall = 15 wird die Aufgabe frühestens 15 Minuten nach dem letzten Start erneut berücksichtigt.

Kalenderintervalle

Der BWScheduler unterstützt unter anderem:

• Täglich
• bestimmter Tag oder bestimmtes Datum
• Monatsanfang und Monatsende
• Quartalsanfang und Quartalsende
• Halbjahresanfang und Halbjahresende
• Jahresanfang und Jahresende

Zusätzlich müssen der eingestellte Wochentag, das Zeitfenster und eine mögliche Ausführungsbedingung passen.

Ausführungsbedingungen

Standardmäßig gilt keine Einschränkung. Je nach Aufgabe kann als zusätzliche Bedingung beispielsweise verlangt werden, dass der ERP-Suite-Mailserver aktiv ist.

Eine Aufgabe startet nur, wenn alle für sie geltenden Voraussetzungen erfüllt sind:

1. Die Aufgabe ist aktiviert.
2. Die Zeitsteuerung ist für die aktuelle Instanz erlaubt und aktiv.
3. Kalendertag und Wochentag passen.
4. Die Aufgabe befindet sich im erlaubten Zeitfenster.
5. Feste Uhrzeit oder Minutenintervall sind fällig.
6. Die Ausführungsbedingung ist erfüllt.
7. Es besteht keine Sperre durch NoLock, Wartungsmodus oder eine unpassende modale Gruppe.

Rückgabecodes und abhängige Aufgaben

Eine Aufgabe kann ihr Ergebnis in einer benannten Scheduler-Variable bereitstellen. Eine andere Aufgabe kann diese Variable anschließend als Ausführungsbedingung verwenden.

Verfügbare Rückgabecode-Variablen

Der Scheduler stellt zehn fest vorgegebene Variablen bereit:

• Variable 1
• Variable 2
• Variable 3
• Variable 4
• Variable 5
• Variable 6
• Variable 7
• Variable 8
• Variable 9
• Variable 10

Die Namen können nicht geändert werden. Dadurch bezeichnet beispielsweise Variable 3 bei der Aufgabe, die den Rückgabecode schreibt, und bei der davon abhängigen Aufgabe immer denselben Inhalt.

Ergebnisvariable einer Aufgabe zuordnen

Wählen Sie bei der Aufgabe unter Rückgabecode Variable die gewünschte Variable aus. Soll die Aufgabe keinen Rückgabewert bereitstellen, wählen Sie Keine Rückgabecode-Variable.

Beim Start der Aufgabe wird die Variable auf -1 gesetzt. Nach erfolgreichem Abschluss wird der Rückgabecode gespeichert.

Interne Scheduler-Funktionen, die keinen eigenen Exitcode liefern, setzen bei fehlerfreier Ausführung den Wert 0. Kann ein Programm nicht gestartet oder überwacht werden oder tritt eine Zeitüberschreitung auf, speichert der Scheduler einen eigenen negativen Fehlercode.

Folgeaufgabe auswählen

Bei anderen Aufgaben erscheint die Variable unter Ausführungsbedingung in folgender Form:

Nur wenn Rückgabecode-Variable 'Variable 1' den Wert 0 oder 200 enthält

Die Folgeaufgabe darf nur starten, wenn Variable 1 den Wert 0 oder 200 enthält. Bei -1 sowie bei jedem Fehlercode bleibt die Bedingung unerfüllt.

Ergebnis nach der Ausführung verbrauchen

Aktivieren Sie bei der Folgeaufgabe die Einstellung Variable nach Ausführung auf -1 setzen, wenn dasselbe Ergebnis nur einmal verarbeitet werden darf.

Nach der Ausführung der Folgeaufgabe setzt der Scheduler die in der Ausführungsbedingung ausgewählte Variable wieder auf -1. Bei einem nicht-modalen Programm erfolgt dies nach dessen erfolgreichem Start, während die Prozessüberwachung im Hintergrund weiterläuft. Dadurch ist die Bedingung anschließend nicht mehr erfüllt und die Aufgabe kann wegen desselben Rückgabewerts nicht nochmals starten. Wird der Aufgabenstart verhindert, bleibt die Variable unverändert.

Diese Einstellung wirkt ausschließlich bei einer Ausführungsbedingung mit einer Rückgabecode-Variable.

Nicht-modale Programme

Für Programmstart (nicht modal) stehen unter Rückgabecode übernehmen zwei Möglichkeiten zur Verfügung:

Unabhängig von dieser Auswahl überwacht der Scheduler den gestarteten nicht-modalen Prozess im Hintergrund:

• Andere Scheduler-Aufgaben dürfen weiterhin ausgeführt werden.
• Dieselbe Aufgabe kann nicht nochmals gestartet werden, solange ihr Prozess noch läuft.
• Die maximale Prozesslaufzeit und die Einstellung Prozess bei Zeitüberschreitung nicht Abbrechen gelten auch für nicht-modale Programme.
• Wird der Prozess wegen Zeitüberschreitung beendet, wird die Ergebnisvariable auf einen Fehlerwert gesetzt.
• Darf der Prozess nach einer Zeitüberschreitung weiterlaufen, bleibt dieselbe Aufgabe bis zu seinem tatsächlichen Ende für einen erneuten Start gesperrt.

Empfehlung: Verwenden Sie pro Variable möglichst nur eine schreibende Aufgabe. Mehrere gleichzeitig laufende Aufgaben mit demselben Variablennamen würden sich gegenseitig überschreiben.

Haupt- und Unteraufgaben

Unter einer Hauptaufgabe können Unteraufgaben angelegt werden. Wird die Hauptaufgabe gestartet, werden ihre aktivierten Unteraufgaben entsprechend der eingestellten Reihenfolge verarbeitet.

Für gezielte Aufrufe über SchedulerXX.RUN oder die REST-API sollte eine Hauptaufgabe verwendet werden. Eine Unteraufgabe ist für einen direkten externen Start nicht vorgesehen.

Möglichkeiten zum Starten einer Aufgabe

Automatische Zeitsteuerung

Der BWScheduler prüft regelmäßig, welche Aufgaben fällig sind. Eine Aufgabe wird nur einmal gleichzeitig zur Ausführung eingeplant; ein noch laufender Prüfvorgang wird nicht parallel ein zweites Mal gestartet.

Manuelle Ausführung

Eine Aufgabe kann in der Bedienoberfläche gezielt gestartet werden. Ausführungsbedingungen, modale Gruppen und aktive Schutzsperren sind weiterhin zu beachten.

SchedulerXX.RUN-Datei

Im eingestellten Überwachungsordner kann eine Datei nach folgendem Schema angelegt werden:

Scheduler22.RUN

Damit wird die Hauptaufgabe mit der Scheduler-ID 22 angefordert. Die Dateierkennung reagiert auch dann, wenn eine Datei zunächst unter einem anderen Namen erstellt und anschließend in Scheduler22.RUN umbenannt wird. Mehrere Dateiereignisse für dieselbe Datei führen nicht zu einer mehrfachen parallelen Ausführung derselben Anforderung.

Eine RUN-Datei hebt eine NoLock- oder Wartungssperre nicht auf. Während einer solchen Sperre gelten ausschließlich die weiter unten beschriebenen Ausnahmen.

Dateiüberwachung

Eine Aufgabe kann auf das Erstellen oder Ändern passender Dateien in einem überwachten Ordner reagieren. Die Überwachungsaufgabe verweist auf die auszuführende Zielaufgabe. Zielaufgabe und Überwachungsaufgabe dürfen nicht identisch sein.

REST-API

Ab Programmversion 5.31 können BWScheduler-Installationen Aufgaben verschlüsselt untereinander auslösen. Die Zielaufgabe muss dafür über REST-API Ausführung ausdrücklich freigegeben sein. Einzelheiten enthält die Kundendokumentation BWScheduler über REST-API verbinden.

Verhalten bei NoLock.ini und Wartungsmodus

Zweck der Sperre

Eine gefundene NoLock.ini, eine NoLock_admin_only.ini oder ein aktiver ERP-Suite-Wartungsmodus hält die normale Programmausführung des BWSchedulers an. Dadurch sollen während Wartungsarbeiten keine normalen ERP-, Programm-, Skript-, Datei- oder Importaufgaben neu gestartet werden.

Der BWScheduler berücksichtigt die NoLock-Dateien in den dafür vorgesehenen ERP-Suite- und Mandantenpfaden. Der Wartungsstatus wird regelmäßig neu geprüft. Sobald keine Sperre mehr besteht, kann die normale Zeitsteuerung fortgesetzt werden.

Welche Aufgaben trotz Sperre ausgeführt werden dürfen

Während einer gefundenen NoLock-Datei oder eines aktiven Wartungsmodus sind ausschließlich folgende Funktionsaufrufe freigegeben:

Alle anderen Aufgaben bleiben gesperrt. Das betrifft insbesondere:

• ERP-Suite-Aufgaben
• modale und nicht-modale Programmaufrufe
• Skripte
• normale Datei- und Importfunktionen
• Start, Stopp und Neustart von Diensten
• das Erstellen einer NoLock-Datei mit $CREATENOLOCKINI
• Prozessstart- und Prozessbeendigungsfunktionen, sofern sie nicht zu den oben ausdrücklich freigegebenen Abmeldefunktionen gehören
• über RUN-Datei, Dateiüberwachung oder REST-API angeforderte normale Aufgaben

Wichtig: „Darf trotz Sperre ausgeführt werden“ bedeutet nicht „wird sofort und bedingungslos ausgeführt“. Bei einem normalen Zeitplan muss die Aufgabe aktiviert sein; außerdem müssen Wochentag, Zeitfenster, Ausführungszeit beziehungsweise Intervall und Ausführungsbedingung passen. Für einen gezielten Aufruf gelten dessen eigene Freigabe- und Aktivierungseinstellungen. Ein gezielter Aufruf kann die zeitliche Fälligkeit ersetzen, aber nicht die NoLock-Freigabeliste erweitern.

Zusammenfassung

Empfohlener Ablauf eines Wartungsfensters

1. Legen Sie eine Aufgabe zum Erstellen der NoLock-Datei an.
2. Planen Sie anschließend die benötigten Wartungs- oder Beendigungsaufgaben in einer sinnvollen Reihenfolge.
3. Beachten Sie, dass nach Aktivierung der Sperre normale Aufgaben nicht mehr neu gestartet werden.
4. Verwenden Sie zum Abschluss eine ausdrücklich freigegebene Aufgabe zum Löschen der NoLock-Dateien.
5. Prüfen Sie nach dem Wartungsfenster die Statusanzeige und das Protokoll.

Hinweis: Eine Aufgabe, die nach dem Erstellen der NoLock-Datei noch als normale separate Scheduler-Aufgabe starten soll, wird durch die Sperre verhindert. Solche Abläufe müssen als zusammengehöriger Wartungsablauf vorbereitet oder vor Eintritt der Sperre gestartet werden.

Anzeige und Statuskontrolle

Die Aufgabenliste zeigt unter anderem:

• Aktivstatus
• Bezeichnung und Scheduler-ID
• letzte und nächste Ausführung
• aktuellen Laufstatus
• die kompakte Spalte Gruppe mit dem Namen und der Farbe einer ausgewählten Farbgruppe

Bei keine (Global) und bei nicht-modalen Aufgaben bleibt die Zelle in der Spalte Gruppe leer. Die globale Sperrwirkung der Einstellung keine bleibt davon unberührt.

Bei unerwartetem Verhalten sollte zusätzlich das BWScheduler-Protokoll geprüft werden. Dort werden beispielsweise folgende Zustände festgehalten:

• Zeitsteuerung aktiv oder nicht aktiv
• Aufgabe fällig oder nicht fällig
• nicht erfüllte Ausführungsbedingung
• erkannte NoLock-Datei oder Wartungsmodus
• Warten auf eine modale Gruppe
• Start und Ende einer Aufgabe
• fehlende Programme, Pfade oder Berechtigungen
• Änderung einer Rückgabecode-Variable
• geändertes Ergebnis einer Variablenselektion
• verhinderter Doppelstart eines noch laufenden nicht-modalen Programms

Benachrichtigungen und Laufzeitüberwachung

Je nach Konfiguration kann der BWScheduler über Aufgabenstart, Aufgabenende, Fehler, NoLock-Erkennung oder ungewöhnlich lange Laufzeiten informieren.

Für lang laufende oder geschäftskritische Aufgaben empfiehlt sich:

• eine realistische maximale Prozesslaufzeit
• ein Warnungszeitpunkt vor oder bei Überschreitung
• aktivierte Benachrichtigungen
• die Kennzeichnung als kritischer Prozess, sofern zutreffend

Ein automatischer Abbruch sollte nur verwendet werden, wenn das betreffende Programm gefahrlos beendet werden kann.

Checkliste für eine neue Aufgabe

1. Eindeutige Bezeichnung und richtige Aufgabenart wählen.
2. Programm beziehungsweise Funktion und Parameter prüfen.
3. Aufgabe aktivieren.
4. Gewünschte Wochentage festlegen.
5. Feste Uhrzeit oder Minutenintervall einstellen.
6. Prüfen, ob die Ausführungszeit innerhalb von Zeit von und Zeit bis liegt.
7. Bei modalen Aufgaben die passende Gruppe wählen.
8. Benötigte Zugriffsrechte des Scheduler-Kontos prüfen.
9. REST-Freigabe nur bei tatsächlichem Bedarf aktivieren.
10. Aufgabe zunächst kontrolliert testen und anschließend das Protokoll prüfen.

Fehlerbehebung

Eine geplante Aufgabe startet nicht

Prüfen Sie in dieser Reihenfolge:

1. Ist die Aufgabe aktiviert?
2. Ist die Zeitsteuerung in dieser Instanz aktiv?
3. Passt die globale Betriebsart Dienst, Applikation oder Immer aktiv?
4. Ist der aktuelle Windows-Benutzer zugelassen?
5. Ist der heutige Wochentag ausgewählt?
6. Liegt die aktuelle Zeit im erlaubten Zeitfenster?
7. Ist die feste Uhrzeit beziehungsweise das Intervall bereits fällig?
8. Ist die Ausführungsbedingung erfüllt?
9. Wurde eine NoLock.ini oder NoLock_admin_only.ini gefunden?
10. Ist der ERP-Suite-Wartungsmodus aktiv?
11. Wartet die Aufgabe auf eine belegte modale Gruppe?
12. Sind Programm, Pfad, Dienstname und Parameter korrekt?

Aufgaben verschiedener Farben warten trotzdem

Prüfen Sie, ob eine laufende modale Aufgabe die Gruppe keine (Global) verwendet. Eine globale modale Aufgabe sperrt alle Farbgruppen. Zwei unterschiedliche Farbgruppen dürfen nur dann parallel laufen, wenn keine globale modale Aufgabe aktiv ist.

Eine Aufgabe wurde beim Programmstart unerwartet ausgeführt

Prüfen Sie besonders:

• ob Zeit von und Zeit bis ein gültiges Zeitfenster bilden,
• ob die Ausführungszeit innerhalb dieses Fensters liegt,
• ob ein Intervall größer als 0 eingestellt ist,
• ob noch eine SchedulerXX.RUN-Datei oder ein anderer externer Auftrag vorhanden war,
• ob die Aufgabe als Unteraufgabe einer gerade gestarteten Hauptaufgabe ausgeführt wurde.

Weiterführende Kundendokumentationen

• Modale Gruppen im BWScheduler
• Funktionsaufrufe im BWScheduler
• BWScheduler über REST-API verbinden