Wozu JOBG?

Der Einsatz von Jobgruppen wird oft vermieden, da ihr Nutzen nicht offensichtlich ist. Dabei ist ihre Verwendung recht einfach: JOBG erlauben es, die Anzahl gleichzeitig laufender Objekte zu begrenzen und ihren Returncode zurückzumelden.

Damit  kann in JOBP mittels JOBG auf das Ende einer variablen Anzahl von Objekten, die z.B. aus einem Script oder Job generiert wurden, reagiert werden. Voraussetzung hierfür ist, daß die JOBG nicht als Warteschlange angelegt wurde. (Dies ist seit UC4 V10 der Fall - Warteschlangen werden seither mit QUEUEs umgesetzt).

Ähnliche Wirkungen lassen sich auch mit SYNC Objekten erstellen. Allerdings gibt es mehrere entscheidende Unterschiede zwischen den beiden, die sich auf die Situationen, in denen JOBG oder SYNC sinnvoll einsetzbar sind, auswirken:

1. JOBG lassen sich gezielt aktivieren, bspw. in einem JOBP. Sie haben daher immer einen Parent, der von den Objekten, die sie für die Serialisierung verwenden, unterschieden ist. Dies ist bei SYNC nicht. der Fall - sie laufen direkt in den Objekten, die serialisiert werden sollen
2. bricht ein UC4 Objekt in einen SYNC Objekt ab, so richtet sich der Status des SYNC Objektes nach der Aktion, die im abbrechenden Objekt für den Fall des Abbruches hinterlegt wurde. Bricht ein UC4 Objekt in einer JOBG ab, geht die ganze JOBG auf Fehler. In einem Batchablauf kann daher auf Fehler in JOBG unterschiedlich reagiert werden .
3. bei JOBG läßt sich die Anzahl der in der Gruppe gleichzeitig laufenden Objekte dynamisch während der Laufzeit der Gruppe steuern. Dies kann bspw. durch ein Script erfolgen, das abhängig von der Last auf einem Server die Anzahl der parallel laufenen Jobs in einer Gruppe ändert. Bei einem SYNC ist dies nicht ohne weiteres möglich: hier läßt sich die Anzahl parallel laufender Jobs nur durch die im SYNC hinterlegten Regeln steuern.