|
<< Click to Display Table of Contents >> Navigation: PUM - Modellierung und Codeerzeugung > Strukturen und Muster > Background Task Structure |
Die Background Task Structure dient dazu, eine abstrakte Oberklasse anzubieten, von denen man im Modell Unterklassen definiert.
In diesen Unterklassen werden Methoden definiert, die für die Durchführung des Tasks notwendig sind.
Es wird ein TaskManager pro Customer angelegt (Mandatenfähigkeit) bzw. (ohne Mandantenfähigkeit) bei der Projektdatei. Jeder dieser TaskManager könnte durch einen eigenständigen GEM-Prozess abgearbeitet werden (wieder mal eine Lizenzfrage).
Es wird eine abstrakte Oberklasse definiert, von denen man im Modell Unterklassen definiert.
In diesen Unterklassen werden Methoden definiert, die für die Durchführung des Tasks notwendig sind.
Folgende Informationen hält die Oberklasse
Name des Attributes |
Beschreibung |
|---|---|
createdTS |
Timestamp, wann der Task angelegt wurde |
finishedTS |
Timestamp, wann der Task beendet wurde |
startedTS |
Timestamp, wann der Task seine Arbeit begonnen hat |
externalAbortFlag |
Flag (True, false), das definiert, daß der Task abgebrochen werden soll |
progressPercent |
Integer (0 .. 100), Progress Indikator in % |
title |
Name des Tasks |
taskCommand |
Enum, der den Typ des Hintergrundprozessen definiert |
taskCode |
Enum, der den Abschlußcode des Tasks definiert |
taskState |
Enum, der den aktuellen Zustand des Status zeigt |
resultJSON |
Ergebnisstruktur als json-String |
resultTypeName |
Klassenname des Ergebnisses |
eventsEnabled |
Flag (True, False), das definiert, ob an die Session ein Event geschcikt werden soll. |
errorString |
String, der einen eventuellen Fehler beschreibt |
Für jeden spezifischen Background Tasks muß der Entwickler eine Ergebnisstuktur definieren und auch eine Parameterstruktur.
Beim Registrieren des Background-Tasks werden die JSON-Strings für die Parameter deserialisiert und als Assoziation zu einer Instanz der Parameterklasse abgelegt. Der Background-Task zieht seine Informationen aus der Instanz der Parameterklasse. In dieser Instanz können neben offensichtlich benötigten Informationen zur Durchführung der Aufgabe auch direkte technische Parameter enthalten sein wie z.B. wieviele Objekte in einer Transaktion bearbeitet werden sollen oder ...
Weiterhin gibt es eine Assoziation zu einer eventuellen Session, die über die Fortschritte via Event benachrichtigt werden sollte. Und eine Assoziation zu dem Benutzer, der diesen Task erzeugt hat.
Folgende Methoden müssen in den jeweiligen Unterkassen implementiert werden
•checkTask - Überprüft, ob alle Parameter gesetzt sind
•runTask - startet die Bearbeitung des Tasks. Die Abarbeitung erfolgt in einem eigenen GEM-Task
•abortTask - bricht den Task ab
•finishTask - beendet den Task
Weiterhin werden die folgenden API-Calls definiert:
•AbortTask - Setzt das externalAbortFlag auf true. Benötigt als Parameter nur die GOP des Task-Objektes.
•BackgroundTaskList - CRUD Struktur, um die Liste der Tasks bearbeiten zu können. Dabei ist nur der (C),(D) und (R) Call implementiert. Der (D)-Call geht intern über die AbortTask Logik
Der TaskManager verwaltet die Arbeitsqueue. und entfernt auch alle alte Tasks aus der Liste, die älter als n-Stunden sind.
Weiterhin legt PUM eine Event-Struktur an, die zum Versenden der BG-Informationen an die Endbenutzer verschickt werden.
Wenn freigeschaltet, dann werden Events (über ServerSideEvents) an die Session gesandt. Diese Events haben die folgende Struktur:
Name des Attributes |
Beschreibung |
|---|---|
gop |
GOP des Tasks |
sessionGop |
GOP der Session |
customerGop |
GOP des Customers |
createdTs |
Timestamp, wann der Task angelegt wurde |
finishedTs |
Timestamp, wann der Task beendet wurde |
startedTs |
Timestamp, wann der Task seine Arbeit begonnen hat |
progressPercent |
Integer (0 .. 100), Progress Indikator in % |
title |
Name des Tasks |
taskCommand |
Enum, der den Typ des Hintergrundprozessen definiert |
taskCode |
Enum, der den Abschlußcode des Tasks definiert |
taskState |
Enum, der den aktuellen Zustand des Status zeigt |
resultJson |
Ergebnisstruktur als json-String |
resultTypeName |
Klassenname des Ergebnisses |
errorString |
String, der einen eventuellen Fehler beschreibt |
Hier noch eine Erklärung, wie die Events verteilt werden:
•Wenn die SessionID gesetzt ist, dann wird nur an die zu dieser Session zugehörigen Verbindung der Event geschickt
•Wenn die SessionID leer ist, aber die CustomerID gesetzt ist, dann wird der Event an alle Verbindungen von Personen des Customers geschickt
•Wenn SessionID und CustomerID nicht gesetzt sind, dann geht der Event an alle Sessions.