# 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.

[![image.png](https://bookstack.erpaustria.com/uploads/images/gallery/2025-09/scaled-1680-/slAZ4rOvVBcb5dYf-image.png)](https://bookstack.erpaustria.com/uploads/images/gallery/2025-09/slAZ4rOvVBcb5dYf-image.png)

#### Blacklist

<span style="white-space: pre-wrap;">Im Programmverzeichnis gibt es die Datei </span>*`<em class="editor-theme-code editor-theme-italic">rds-logoff-blacklist.txt</em>`*, in der die Bediener eingetragen werden, die nicht abgemeldet werden sollen:

[![image.png](https://bookstack.erpaustria.com/uploads/images/gallery/2025-09/scaled-1680-/Opr4KqiyLbgmH9mG-image.png)](https://bookstack.erpaustria.com/uploads/images/gallery/2025-09/Opr4KqiyLbgmH9mG-image.png)

# Installieren des PowerBI Servers über den FlowManager

<p class="callout info"><span style="white-space: pre-wrap;">Der Power BI Server muss als Dienst über den FlowManager installiert werden. </span>  
<span style="white-space: pre-wrap;">Parameter: wwwin64.exe User Passwort /F </span>  
Beispiel: wwwin64.exe 510 510 /F</p>

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"

[![image.png](https://bookstack.erpaustria.com/uploads/images/gallery/2025-08/scaled-1680-/mtJU4sNNmi8XchNG-image.png)](https://bookstack.erpaustria.com/uploads/images/gallery/2025-08/mtJU4sNNmi8XchNG-image.png)

![image.png](https://bookstack.erpaustria.com/uploads/images/gallery/2025-08/scaled-1680-/Ndm0WGugi5VzZkuk-image.png)  
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.

<p class="callout info">**Dienste:**  
**Dienstname oder Prozessname ohne .exe****;****DIENST****;****Wartezeit nach dem Beenden****;****Dienstpfad (aktuell nicht verwendet)**  
  
***Beispiel:***   
wws;DIENST;30  
WEBWARE WWS-Produktiv22;DIENST;30  
<span style="white-space: pre-wrap;">Dieser Eintrag beendet den Dienst wws (idealerweise wird hier der </span>**Displayname**<span style="white-space: pre-wrap;"> des Dienstes angegeben!)</span>  
und wartet anschließend noch 30 Sekunden, bevor der nächste Dienst beendet wird.</p>

<p class="callout info">**Prozesse:**  
**Prozessname ohne .exe****;****Programmpfad (optional)**  
Wenn ein Prozessname ohne Pfad angegeben wird, dann werden ALLE Prozesse im Speicher mit dieser Signatur beendet.  
<span style="white-space: pre-wrap;">Wichtig: Der Programmpfad wird als Teilstring geprüft und prüft den Pfad von links beginnend! </span>  
  
***Beispiel:***  
wwwin64;X:\\ERPSuite --&gt; beendet alle Prozesse auch unter X:\\ERPSuite\_TEST  
wwwin64;X:\\ERPSuite\\ --&gt; beendet nur Prozesse unter X:\\ERPSuite\\\*... aber auch X:\\ERPSuite\\TEST1 und X:\\ERPSuite\\Test2</p>

**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.

<p class="callout warning"><span style="white-space: pre-wrap;">ACHTUNG: Hierfür darf im Dienst nicht eingestellt sein, dass dieser sich im Fehlerfall neu startet! </span></p>

Anschließend werden die gefundenen Prozesse beendet.

<p class="callout info">Hier kann auch zur Sicherheit z. B. als Option auch noch der Prozess "wwr" angegeben werden.</p>

**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.

<p class="callout danger">Wichtig: Der WWS muss immer VOR dem WWR beendet werden!</p>

<details id="bkmrk-wwprozessliste.datww"><summary>WWProzessliste.dat</summary>

```
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
```

</details>

# 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:

```text
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:

```text
/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

| 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

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:

| 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:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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.

| 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. |
| Variable nach Ausführung auf -1 setzen | Verbraucht die für die Ausführungsbedingung verwendete Variable nach der Ausführung, damit dasselbe Ergebnis nicht nochmals verarbeitet 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:

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.

### Neue Ausführungsbedingungen

Unter **Ausführungsbedingung** stehen folgende Arten zur Verfügung:

| Auswahl | Verhalten |
|---|---|
| keine Einschränkung | Es wird keine zusätzliche Selektion geprüft. Die übrigen Zeit-, Status- und Schutzbedingungen gelten weiterhin. |
| ERP-Suite Mailserver aktiv | Die Aufgabe startet nur, wenn der ERP-Suite-Mailserver aktiv ist. |
| Nur wenn Rückgabecode-Variable 'Variable 1' den Wert 0 oder 200 enthält | Die Aufgabe startet nur, wenn Variable 1 erfolgreich ist. |
| Nur wenn Rückgabecode-Variable 'Variable 2' den Wert 0 oder 200 enthält | Die Aufgabe startet nur, wenn Variable 2 erfolgreich ist. |
| Nur wenn Rückgabecode-Variable 'Variable 3' den Wert 0 oder 200 enthält | Die Aufgabe startet nur, wenn Variable 3 erfolgreich ist. |
| Nur wenn Rückgabecode-Variable 'Variable 4' den Wert 0 oder 200 enthält | Die Aufgabe startet nur, wenn Variable 4 erfolgreich ist. |
| Nur wenn Rückgabecode-Variable 'Variable 5' den Wert 0 oder 200 enthält | Die Aufgabe startet nur, wenn Variable 5 erfolgreich ist. |
| Nur wenn Rückgabecode-Variable 'Variable 6' den Wert 0 oder 200 enthält | Die Aufgabe startet nur, wenn Variable 6 erfolgreich ist. |
| Nur wenn Rückgabecode-Variable 'Variable 7' den Wert 0 oder 200 enthält | Die Aufgabe startet nur, wenn Variable 7 erfolgreich ist. |
| Nur wenn Rückgabecode-Variable 'Variable 8' den Wert 0 oder 200 enthält | Die Aufgabe startet nur, wenn Variable 8 erfolgreich ist. |
| Nur wenn Rückgabecode-Variable 'Variable 9' den Wert 0 oder 200 enthält | Die Aufgabe startet nur, wenn Variable 9 erfolgreich ist. |
| Nur wenn Rückgabecode-Variable 'Variable 10' den Wert 0 oder 200 enthält | Die Aufgabe startet nur, wenn Variable 10 erfolgreich ist. |

Die Variablenselektion ist eine zusätzliche Bedingung. Eine Aufgabe muss weiterhin aktiviert und zeitlich fällig sein und darf nicht durch Wartungsmodus, NoLock oder eine modale Gruppe gesperrt sein.

### Ergebnisvariable einer Aufgabe zuordnen

Unter **Rückgabecode Variable** stehen **Keine Rückgabecode-Variable** sowie **Variable 1** bis **Variable 10** zur Auswahl. Wählen Sie die Variable aus, in der diese Aufgabe ihr Ergebnis bereitstellen soll. 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:

```text
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.

### Vollständiges Beispiel

Aufgabe A führt einen Datenimport aus. Aufgabe B soll danach genau einmal eine Weiterverarbeitung starten.

| Aufgabe | Einstellung | Auswahl |
|---|---|---|
| Aufgabe A | Rückgabecode Variable | Variable 1 |
| Aufgabe B | Ausführungsbedingung | Nur wenn Rückgabecode-Variable 'Variable 1' den Wert 0 oder 200 enthält |
| Aufgabe B | Variable nach Ausführung auf -1 setzen | aktiviert |

Ablauf:

1. Beim Start von Aufgabe A wird Variable 1 auf `-1` gesetzt.
2. Solange Variable 1 den Wert `-1` enthält, darf Aufgabe B nicht starten.
3. Aufgabe A beendet sich mit `0` oder `200`. Damit ist die zusätzliche Ausführungsbedingung von Aufgabe B erfüllt.
4. Sobald auch alle übrigen Bedingungen von Aufgabe B erfüllt sind, wird Aufgabe B ausgeführt.
5. Nach der Ausführung setzt Aufgabe B Variable 1 wieder auf `-1`.
6. Aufgabe B kann aufgrund dieses Ergebnisses nicht nochmals gestartet werden. Erst ein neuer erfolgreicher Lauf von Aufgabe A gibt sie wieder frei.

### 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:

```text
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

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**