Job starten oder suspendieren?

Die Entscheidungsfunktion wird mit filter.class oder filter.id, sowie den Parameterwerten filter.param.N definiert. Für N können die Kleinbuchstaben a bis z verwendet werden. Es werden nur die Parameter übergeben, die die Funktion auch erwartet.

Vorzugsweise wird die Funktion logical-condition(cnd a, val b [, c, ...]) verwendet, wenn weder filter.class noch filter.id definiert sind. Diese Funktion kann auch ein Funktions-Makro aufrufen, wenn der Name des Makros in Parameter a übergeben wird. Durch vorangestelltes not vor dem Namen kann die Logik des Makros negiert werden. Durch die Verwendung eines Makros sind auch komplexere Funktionsketten möglich.

Der Rückgabewert der Funktion bzw. Makros entscheidet, ob der Job ausgeführt oder suspendiert wird. Wert true führt den Job aus, false suspendiert ihn. Wenn der Wert nicht den Datentypen Boolean hat, wird er durch implizite Typumwandlung gewandelt. Für die implizite Typumwandlung zu Boolean gelten folgende Regeln.

Wartezeit bis zur erneuten Umgebungsprüfung

Wenn der Job suspendiert wurde, wird nach einer Wartezeit eine erneute Umgebungsprüfung ausgeführt. Vor deren Ergebnis hängt es ab, ob der Job gestartet oder weiter suspendiert wird.

Verhalten bei Exceptions im Funktionsaufruf

Das Ziel der Umgebungsprüfung ist es u.a. die Verfügbarkeit eines externen Systems zu prüfen. Dabei ist es möglich, dass diese Prüfung mit einer Exception endet, eben weil das System nicht verfügbar ist. Wenn diese Exception nicht abgefangen und ignoriert wird, wird sie an das Profil weitergegeben und jedes Mal ein Eintrag in der Fehlerliste des Control Centers erzeugt.

Mit dem Property filter.exception=ignore kann man diese Exceptions abfangen. Das führt zu folgendem Verhalten bei einer Exception.

• Für die Entscheidungsfunktion wird bei Exception das Ergebnis false angenommen, der Job wird daher suspendiert.

• Bei Exception in der Wait-Funktion scheitert die Berechnung der Wartezeit. Es wird mit der konfigurierten Wartezeit gearbeitet.

Verhalten bei manuellem Neudurchlauf

Wenn ein bereits gelaufener Job mit dem Neudurchlauf-Dialog erneut gestartet wird, muss entschieden werden, ob dafür die Umgebungsprüfung mit der Klasse EnvironmentCheckByFilter ausgeführt werden soll. Default ist: Keine Umgebungsprüfung bei Neudurchlauf.

Mit dem Property restart.execute=true kann man erreichen, dass auch bei einem Neudurchlauf die Umgebungsprüfung ausgeführt wird.

Auflösung von Variablen und Systemkonstanten

Die Umgebungsprüfung wird vor der Phase 2 ausgeführt, also bevor die eigentliche Job-Umgebung existiert. Deshalb stehen nur die auch aus Phase 1 bekannten Systemvariablen und die Variablen MSG_CALL_ zur Verfügung, wenn sie im Profil definiert sind. Damit kann bei Aufruf des Profils per Message oder bei Triggerung durch HTTP oder durch ein Profil eine Parametrisierung der Umgebungsprüfung erfolgen.

Variablen, die im Profil definiert sind und bei Aufruf einen Wert 'von außen' erhalten, können in der Konfigurationsdatei als Wert eines Properties mit der Syntax @Variablenname@ verwendet werden. Systemkonstanten können mit der Syntax %Konstantenname% als Property-Wert in der Konfigurationsdatei verwendet werden.

Achtung: Da bei erneuter Ausführung der Umgebungsprüfung nach der Wartezeit mit dem originalen Variablensatz gearbeitet wird, ändern sich die Werte bei erneuter Umgebungsprüfung nach der Suspendierung üblicherweise nicht.

Da die System-Variable VAR_FILENAME nicht zur Verfügung steht, gibt es eine Pseudo-Variable @<file>@, die den Namen der Quelldatei enthält.

Einschränkungen

Zum Zeitpunkt der Umgebungsprüfung existiert die Job-Umgebung noch nicht. Deshalb wird eine rudimentäre Ersatz-Umgebung erzeugt.

In dieser Umgebeung stehen zwar Maps und Listen, sowie Value-Splitter zur Verfügung und können innerhalb der Umgebungsprüfung verwendet werden, aber eine Übergabe der erzeugten Listen-/Map-/Splitter-Objekte an die eigentliche Job-Umgebung erfolgt nicht.

In der rudimentären Umgebung können eventuell einzelne Funktionen nicht funktionieren. Eine vollständige Prüfung aller Funktionen in allen Kombinationen wurde nicht durchgeführt.

Szenario 1

Ein Profil empfängt Daten per Email und erzeugt eine Zieldatei mit fixem Dateinamen ./temp/output/Env2Check.txt, die von einem anderen System/Prozess abgeholt und dabei gelöscht wird. Es besteht die Gefahr eines Datenverlustes, wenn die Datei durch einen späteren Job überschrieben wird, bevor sie vom Zielsystem abgeholt wurde.

Als erste Maßnahme wird das Profil auf Single-Run (Darf nur in einer Instanz laufen) eingestellt. Trotzdem kommt es gelegentlich zum Überschreiben der Datei.

Ziel: Folgejobs des Profils sollen solange zurückgestellt werden, bis die Zieldatei abgeholt und gelöscht wurde.

Lösung: Die Umgebungsprüfung erfolgt mit com.ebd.hub.datawizard.extensions.EnvironmentCheckByFilter und folgender Konfiguration.

Erklärung: Da weder Klassenname noch ID für die Entscheidungsfunktion definiert sind, wird logical-condition verwendet. Diese Funktion ruft mit dem Schlüsselwort file die Funktion file-exists( filename a, [canread b],[canwrite c],[istype d],[modified e]) auf, der die Existenz der mit filter.param.b angegebenen Datei prüft.

Durch Voranstellen von not vor file wird die Logik invertiert. Dadurch wird der Folgejob suspendiert, solange die Datei noch nicht abgeholt und gelöscht wurde.

Da keine wait.time konfiguriert ist und keine Wait-Funktion, wird die Umgebungsprüfung alle 30 Sekunden wiederholt.

Mit restart.execute=true wird garantiert, dass auch bei manuellem Neudurchlauf diese Prüfung ausgeführt wird.

Szenario 2

Während der Arbeitszeit fallen Daten an, die erst mehrere Stunden nach Arbeitsschluss verarbeitet werden sollen. Alle Jobs des Profils zwischen 06:30 und 19:45 müssen suspendiert werden. Da es sich um einen langen Zeitraum handelt, sollen unnötige Läufe der Umgebungsprüfung durch Berechnung der Wartezeit vermieden werden.

Lösung: Es werden zwei Funktions-Makros entwickelt und getestet: Makros.zip