ERP Austria Scheduler / FlowManager Der ERP Austria FlowMananger kann Aufgaben und Workflows ausführen und koordinieren 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! WWProzessliste.dat 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: Einstellung Empfohlener Wert Aktiv aktiviert Aufgabenart Funktionsaufruf App gewünschte $ -Funktion Wochentag gewünschte Ausführungstage Ausführungsintervall meistens Täglich Ausführungsbedingung keine Einschränkung, sofern keine besondere Prüfung benötigt wird Modale Gruppe passend zum betroffenen System oder Arbeitsablauf 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: Einstellung Wert Zeit von 05:30 Ausführungszeit 05:31 Zeit bis 06:00 Intervall 0 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 Funktion Zweck AppParameter AppParameter2 Dienstname $CREATENOLOCKINI NoLock.INI erstellen leer leer leer $DELETENOLOCKINI Vom Scheduler erstellte NoLock.INI entfernen leer leer leer $DELETEALLNOLOCKINI Alle gefundenen NoLock.INI entfernen leer leer leer $AUSLOGGEN NoLock.INI vorübergehend setzen leer leer leer $BÜROWARE-BEENDEN ERP-Suite-Prozesse und zugehörige Dienste beenden optional: Prozesslistendatei leer leer $WEBWARE-BEENDEN Webware-Prozesse und zugehörige Dienste beenden optional: Prozesslistendatei leer leer $PROZESSE-BEENDEN Mehrere definierte Prozesse oder Dienste beenden optional: Prozesslistendatei leer leer $PROZESSE-STARTEN Mehrere definierte Prozesse oder Dienste starten optional: Prozesslistendatei leer leer $CREATEFILE Datei erstellen oder ersetzen vollständiger Dateipfad leer leer $DELETEFILE Einzelne Datei löschen vollständiger Dateipfad leer leer $DELETEFILES Mehrere ältere Dateien löschen Pfad mit Dateimaske Alter in Tagen leer $DATEIÜBERWACHUNG Dateiänderung überwachen und Aufgabe einplanen vollständiger Dateipfad RUN(n) leer $DTAIMPORT DTA-Dateien importieren Importordner Bediener und optional Mandant leer $NETZWERKLAUFWERK-VERBINDEN Hinterlegte Netzlaufwerke verbinden leer leer leer $STARTSERVICE Windows-Dienst starten leer leer Dienstname $STOPSERVICE Windows-Dienst stoppen leer leer Dienstname $RESTARTSERVICE Windows-Dienst neu starten leer leer Dienstname $KILLPROCESS Einzelnen Prozess sofort beenden leer leer Prozessname $RDS-LOGOFF Remotedesktop-Sitzungen abmelden Option, z. B. /all leer leer $SOFTWAREAUDIT ERP-Suite Software-Audit durchführen leer leer leer 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: Einstellung Wert Aufgabenart Funktionsaufruf App $CREATENOLOCKINI AppParameter leer Intervall 0 Zeit von 05:30 Ausführungszeit 05:31 Zeit bis 06:00 Modale Gruppe keine (Global) 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: Einstellung Wert Aufgabenart Funktionsaufruf App $DELETENOLOCKINI AppParameter leer Intervall 0 Zeit von 05:30 Ausführungszeit 05:32 oder gewünschter Freigabezeitpunkt Zeit bis 06:00 oder passend zum Wartungsfenster Modale Gruppe keine (Global) 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: Einstellung Wert App $KILLPROCESS Dienstname Prozessname ohne .exe , beispielsweise bwwin32 AppParameter leer Intervall 0 Modale Gruppe passend zum betroffenen System 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: Einstellung Wert Aufgabenart Funktionsaufruf App $STARTSERVICE , $STOPSERVICE oder $RESTARTSERVICE Dienstname Anzeigename oder Dienstname des gewünschten Windows-Dienstes AppParameter / AppParameter2 leer Intervall normalerweise 0 Modale Gruppe eine gemeinsame Farbe für zusammengehörige Dienste 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: Einstellung Wert App $DELETEFILES AppParameter C:\ERP\Log\*.log AppParameter2 30 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: Einstellung Wert Aufgabenart Funktionsaufruf App $DATEIÜBERWACHUNG AppParameter vollständiger Pfad der zu überwachenden Datei AppParameter2 RUN(n) mit der Nummer der Zielaufgabe Intervall 0 Zeit von / Zeit bis Zeitraum, in dem Änderungen verarbeitet werden dürfen 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: Einstellung Wert App $DTAIMPORT AppParameter vollständiger Pfad des DTA-Importordners AppParameter2 Bedienernummer und optional Mandant, z. B. 000 000001 Intervall z. B. 15 Minuten Ausführungszeit bei Intervallausführung leer Modale Gruppe eigene Gruppe für den jeweiligen Importbereich 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. AppParameter Wirkung leer getrennte Sitzungen abmelden /all alle vorgesehenen Remotedesktop-Sitzungen abmelden /U=benutzername den angegebenen Benutzer abmelden 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: Mit $AUSLOGGEN Benutzer zum Beenden der ERP-Suite-Sitzungen auffordern. Mit $CREATENOLOCKINI den Wartungszustand aktivieren. Mit $BÜROWARE-BEENDEN , $WEBWARE-BEENDEN oder $PROZESSE-BEENDEN benötigte Komponenten beenden. Sicherung, Aktualisierung oder andere Wartungsaufgabe durchführen. Mit $PROZESSE-STARTEN oder $STARTSERVICE benötigte Komponenten wieder starten. 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: Pfade, Dateimasken, Dienstnamen und Prozessnamen kontrollieren. Berechtigungen des Kontos prüfen, unter dem der BWScheduler ausgeführt wird. Zeitfenster und Wochentage kontrollieren. Bei Intervall 0 eine gültige Ausführungszeit innerhalb des Zeitfensters eintragen. Bei Intervall größer 0 die Ausführungszeit leer lassen. Eine geeignete modale Gruppe auswählen. Kritische Funktionen zunächst manuell in einer Testumgebung ausführen. 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 Einstellung Anzeige Verhalten keine Global Sperrt sich mit allen modalen Aufgaben Rot Rot Sperrt nur andere Aufgaben der Gruppe Rot und globale Aufgaben Grün Grün Sperrt nur andere Aufgaben der Gruppe Grün und globale Aufgaben Blau Blau Sperrt nur andere Aufgaben der Gruppe Blau und globale Aufgaben Orange Orange Sperrt nur andere Aufgaben der Gruppe Orange und globale Aufgaben Gelb Gelb Sperrt nur andere Aufgaben der Gruppe Gelb und globale Aufgaben Violett Violett Sperrt nur andere Aufgaben der Gruppe Violett und globale Aufgaben Türkis Türkis Sperrt nur andere Aufgaben der Gruppe Türkis und globale Aufgaben Pink Pink Sperrt nur andere Aufgaben der Gruppe Pink und globale Aufgaben Braun Braun Sperrt nur andere Aufgaben der Gruppe Braun und globale Aufgaben Grau Grau Sperrt nur andere Aufgaben der Gruppe Grau und globale Aufgaben 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 Öffnen Sie im BWScheduler die Einstellungen der gewünschten Aufgabe. Stellen Sie sicher, dass eine modale Aufgabenart ausgewählt ist. Wählen Sie unter Modale Gruppe die gewünschte Farbe oder keine aus. Speichern Sie die Einstellung. 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: Ist die Aufgabe als modale Aufgabe eingerichtet? Ist die erwartete Farbe in der Spalte Modale Gruppe sichtbar? Läuft bereits eine Aufgabe derselben Farbe? Läuft eine Aufgabe mit der Anzeige Global ? 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: Einstellung Bedeutung Keine Für Aufgaben mit der Freigabe „Gemäß globaler Authentifizierung“ wird kein Schlüssel verlangt. API-Key Auf Server und Clients muss derselbe kundenspezifische API-Key eingestellt sein. Nur eigene Produkte Freigegebene PHX-Produkte weisen sich automatisch mit ihrer Produktkennung und ihrem internen Produktschlüssel aus. Eine Kundeneingabe ist nicht erforderlich. 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 . Einstellung Wert Aktiv aktiviert Betriebsart Server IP-Adresse des REST-Servers kann auf dem Server leer bleiben Port 9443 oder ein eigener freier Port SSL-PFX Zertifikat optional SSL-PFX Zertifikat Kennwort nur bei Verwendung einer PFX-Datei Erlaube ungültige SSL-Zertifikate auf dem Server ohne Bedeutung Authentifizierungsart empfohlen: Nur eigene Produkte API-Key nur bei Authentifizierungsart API-Key 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 . Einstellung Wert Aktiv aktiviert Betriebsart Client IP-Adresse des REST-Servers IP-Adresse oder DNS-Name des Servers Port derselbe Port wie auf dem Server SSL-PFX Zertifikat normalerweise leer SSL-PFX Zertifikat Kennwort normalerweise leer Erlaube ungültige SSL-Zertifikate nur bei Bedarf aktivieren Authentifizierungsart dieselbe Einstellung wie am Server API-Key bei Authentifizierungsart API-Key derselbe Wert wie am Server 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: Einstellung Wert Aufgabenart Funktionsaufruf App $RESTAPI-EXECUTE AppParameter Execute=22 AppParameter2 leer Intervall 0 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. Einstellung Verhalten Nicht über REST ausführbar REST-Aufrufe werden immer abgelehnt. Dies ist der Standardwert. Gemäß globaler Authentifizierung Es gilt die im Bereich REST-API eingestellte Authentifizierungsart. Nur durch BWScheduler Die Aufgabe darf ausschließlich von einem automatisch erkannten BWScheduler ausgelöst werden. Ohne Authentifizierung Die Aufgabe darf ohne Schlüssel ausgelöst werden. Diese Einstellung nur gezielt verwenden. 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 REST-API Ausführung der Zielaufgabe Globale Einstellung Ergebnis Nicht über REST ausführbar beliebig Die Aufgabe wird immer abgelehnt. Gemäß globaler Authentifizierung Keine Die Aufgabe kann ohne Schlüssel gestartet werden. Gemäß globaler Authentifizierung API-Key Ein gültiger kundenspezifischer API-Key ist erforderlich. Gemäß globaler Authentifizierung Nur eigene Produkte Ein gültig erkanntes PHX-Produkt ist erforderlich. Nur durch BWScheduler beliebig Nur ein erkannter BWScheduler darf die Aufgabe starten. Ohne Authentifizierung beliebig Die Aufgabe kann ohne Schlüssel gestartet werden. Empfohlene Konfigurationen BWScheduler mit BWScheduler verbinden Auf Server und Clients: Einstellung Wert Authentifizierungsart Nur eigene Produkte API-Key leer 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: Einstellung Wert Authentifizierungsart API-Key API-Key langer, zufälliger und geheimer Wert 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 Prüfen, ob auf allen beteiligten Systemen mindestens BWScheduler-Programmversion 5.31 installiert ist. Eine BWScheduler-Installation als Server konfigurieren. Port 9443 oder den gewählten Port in der Server-Firewall freigeben. Weitere Installationen als Clients konfigurieren. Verbindung im Protokoll kontrollieren. Auf der Gegenstelle eine ungefährliche Testaufgabe anlegen und aktivieren. Bei der Zielaufgabe die gewünschte Einstellung unter REST-API Ausführung auswählen. Auf der sendenden Seite eine $RESTAPI-EXECUTE -Aufgabe mit der entsprechenden Scheduler-ID erstellen. Auftrag zunächst manuell ausführen. Ausführung und Ergebnis auf beiden Seiten kontrollieren. 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. Einstellung Bedeutung Dienst Die Zeitsteuerung ist nur im Windows-Dienst aktiv. Applikation Die Zeitsteuerung ist nur in der manuell gestarteten Anwendung aktiv. Immer aktiv Die Zeitsteuerung darf sowohl im Dienst als auch in der Anwendung aktiv sein. 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 Aufgabenart Verwendung ERP-Suite Aufgabe Führt eine dafür vorgesehene Aufgabe in der ERP-Suite aus. Modaler Programmaufruf Startet ein Programm und wartet auf dessen Abschluss. Programmstart (nicht modal) Startet ein Programm, ohne andere nicht zusammengehörige Aufgaben bis zu dessen Ende zu blockieren. Skriptaufruf (modal) Führt ein Skript aus und berücksichtigt dabei die modale Steuerung. Funktionsaufruf Führt eine im BWScheduler bereitgestellte Funktion aus, beispielsweise eine NoLock- oder Dienstfunktion. 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 Einstellung Bedeutung Aktiv Nur aktivierte Aufgaben werden automatisch ausgeführt. Bezeichnung Frei wählbarer Name zur leichteren Erkennung. Aufgabenart Legt fest, wie die Aufgabe ausgeführt wird. Prozesspriorität Legt bei unterstützten Programmaufrufen die Windows-Prozesspriorität fest. Modale Gruppe Steuert die gleichzeitige Ausführung modaler Aufgaben. Ausführungsintervall Bestimmt den Kalendertag beziehungsweise die Wiederholung. Ausführungsbedingung Zusätzliche Bedingung, die vor dem Start erfüllt sein muss. Ausführungsdatum Tag oder Datum für datumsabhängige Ausführungen. Wochentag Erlaubte Wochentage. Ohne Wochentage erfolgt keine normale zeitgesteuerte Ausführung. Ausführungszeit Uhrzeit für eine einmalige Ausführung bei Intervall 0 . Zeit von / Zeit bis Zeitraum, innerhalb dessen die Aufgabe gestartet werden darf. Intervall Wiederholung in Minuten; 0 bedeutet Ausführung zur festen Uhrzeit. App Programm, Skript oder bereitgestellte Scheduler-Funktion. AppParameter / AppParameter2 Übergabewerte für die gewählte Aufgabe oder Funktion. Maximale Prozesslaufzeit Überwachung der zulässigen Laufzeit in Minuten. Rückgabecode Variable Optionale Auswahl einer der zehn fest vorgegebenen Variablen, in der das Ergebnis der Aufgabe gespeichert wird. Rückgabecode übernehmen Legt bei nicht-modalen Programmen fest, ob bereits der erfolgreiche Start oder erst das Prozessende ausgewertet wird. REST-API Ausführung Legt fest, ob und mit welcher Berechtigung die Aufgabe über REST ausgelöst werden darf. 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: Einstellung Wert Ausführungsintervall Täglich Wochentag MO, DI, MI, DO, FR Ausführungszeit 05:31 Zeit von 05:30 Zeit bis 06:00 Intervall 0 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: Die Aufgabe ist aktiviert. Die Zeitsteuerung ist für die aktuelle Instanz erlaubt und aktiv. Kalendertag und Wochentag passen. Die Aufgabe befindet sich im erlaubten Zeitfenster. Feste Uhrzeit oder Minutenintervall sind fällig. Die Ausführungsbedingung ist erfüllt. 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. Wert Bedeutung -1 Aufgabe wurde noch nicht beendet oder Ergebnis steht noch aus. 0 Erfolgreich beziehungsweise Selektion erfüllt. 200 Erfolgreich beziehungsweise Selektion erfüllt. jeder andere Wert Fehler beziehungsweise Selektion nicht erfüllt. 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. Interner Fehlercode Bedeutung -1001 Programm konnte nicht gestartet werden. -1002 Maximale Laufzeit überschritten; Prozess wurde beendet. -1003 Maximale Laufzeit überschritten; Prozess läuft laut Einstellung weiter. -1004 Prozessüberwachung nicht möglich. -1005 Fehler während der Aufgabenausführung. 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: Einstellung Verhalten Nach Programmstart Nach einem erfolgreichen Start wird die Variable sofort auf 0 gesetzt. Dies ist die Standardvorgabe. Nach Prozessende Die Variable bleibt während der Laufzeit auf -1 und erhält erst nach dem tatsächlichen Prozessende dessen Exitcode. 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: Kundenfunktion Unterstützte Funktionsnamen Verhalten während der Sperre NoLock.INI löschen $DELETENOLOCKINI , $DELETENOLOCK , $DELETENOLOCK.INI Darf ausgeführt werden und entfernt die vorgesehenen NoLock-Dateien. Alle NoLock.INI löschen $DELETEALLNOLOCKINI Darf ausgeführt werden und entfernt die NoLock-Dateien aus allen berücksichtigten Pfaden. Benutzer beziehungsweise ERP-Suite-Sitzungen abmelden $AUSLOGGEN , $LOGOFF , $LOGOFFMDE , $BWLOGOFF Darf ausgeführt werden, damit eine Wartung oder Abmeldung abgeschlossen werden kann. 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 Systemzustand Normale Aufgaben NoLock löschen / Abmelden Keine Sperre gemäß Aufgabenplanung erlaubt gemäß Aufgabenplanung erlaubt NoLock.ini gefunden gesperrt erlaubt, wenn die betreffende Aufgabe fällig oder gezielt angefordert ist NoLock_admin_only.ini gefunden gesperrt erlaubt, wenn die betreffende Aufgabe fällig oder gezielt angefordert ist Wartungsmodus aktiv gesperrt erlaubt, wenn die betreffende Aufgabe fällig oder gezielt angefordert ist Zeitsteuerung manuell pausiert gesperrt die ausdrücklich freigegebenen Entsperr-/Abmeldefunktionen bleiben grundsätzlich möglich Empfohlener Ablauf eines Wartungsfensters Legen Sie eine Aufgabe zum Erstellen der NoLock-Datei an. Planen Sie anschließend die benötigten Wartungs- oder Beendigungsaufgaben in einer sinnvollen Reihenfolge. Beachten Sie, dass nach Aktivierung der Sperre normale Aufgaben nicht mehr neu gestartet werden. Verwenden Sie zum Abschluss eine ausdrücklich freigegebene Aufgabe zum Löschen der NoLock-Dateien. 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 Eindeutige Bezeichnung und richtige Aufgabenart wählen. Programm beziehungsweise Funktion und Parameter prüfen. Aufgabe aktivieren. Gewünschte Wochentage festlegen. Feste Uhrzeit oder Minutenintervall einstellen. Prüfen, ob die Ausführungszeit innerhalb von Zeit von und Zeit bis liegt. Bei modalen Aufgaben die passende Gruppe wählen. Benötigte Zugriffsrechte des Scheduler-Kontos prüfen. REST-Freigabe nur bei tatsächlichem Bedarf aktivieren. Aufgabe zunächst kontrolliert testen und anschließend das Protokoll prüfen. Fehlerbehebung Eine geplante Aufgabe startet nicht Prüfen Sie in dieser Reihenfolge: Ist die Aufgabe aktiviert? Ist die Zeitsteuerung in dieser Instanz aktiv? Passt die globale Betriebsart Dienst , Applikation oder Immer aktiv ? Ist der aktuelle Windows-Benutzer zugelassen? Ist der heutige Wochentag ausgewählt? Liegt die aktuelle Zeit im erlaubten Zeitfenster? Ist die feste Uhrzeit beziehungsweise das Intervall bereits fällig? Ist die Ausführungsbedingung erfüllt? Wurde eine NoLock.ini oder NoLock_admin_only.ini gefunden? Ist der ERP-Suite-Wartungsmodus aktiv? Wartet die Aufgabe auf eine belegte modale Gruppe? 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