In einem Comarch-ERP-Enterprise-System wird eine Reihe von Tätigkeiten nicht interaktiv abgearbeitet, sondern in Verarbeitungswarteschlangen im Hintergrund. Dies ermöglicht zum einen dem Benutzer im Dialogbetrieb weiterzuarbeiten, während langandauernde Bearbeitungsschritte im Hintergrund weitergeführt werden. Zum anderen ist es damit möglich, ständig wiederkehrende oder Aktivitätsgetriggerte Verarbeitungsschritte automatisch ausführen zu lassen.

Dieses Dokument beschreibt, wie eine Hintergrund-Anwendung erstellt wird und wie diese in unterschiedlichen Kontexten aufgerufen wird.

1              Zielgruppe

• Entwickler
• Technische Berater

2              Begriffsbestimmung

Hintergrund-Anwendung

Anwendung die im Rahmen eines Verarbeitungsauftrages in einer Verarbeitungswarteschlange ausgeführt wird.

Verarbeitungsauftrag

Verarbeitungsaufträge werden vom Benutzer oder erfasst oder programmatisch erzeugt. Sie umfassen einen Satz von Parametern die bestimmen, wann, wie oft und in welcher Verarbeitungswarteschlange eine bestimmte Hintergrund-Anwendung mit welchen Startparametern ausgeführt werden soll. Sie durchlaufen dabei eine Abfolge von Zuständen (Status), die im Wesentlichen „erfasst“, „wird abgearbeitet“, „abgeschlossen“ oder „abgebrochen“ umfassen. Zusätzlichen zum Status können Meldungen zu Verarbeitungsaufträgen assoziiert sein.

Verarbeitungswarteschlange

Verarbeitungswarteschlangen werden im Systemcockpit erfasst. Sie beschreiben die Ressourcen (Anzahl worker, Threads, welche Applicationserver, etc.) die für die Abarbeitung von Verarbeitungsaufträgen zur Verfügung gestellt werden.

Reorganisationsanwendung

Reorganisationsanwendungen sind Hintergrund-Anwendungen die wiederkehrende Datenpflegevorgänge vornehmen. Beispiele sind das Löschen von veralteten Meldungen oder physisches Löschen von löschmarkierten Datensätzen die nicht mehr referenziert werden.

Pseudo-Vearbeitungsaufträge

Pseudo-Verarbeitungsaufträge sind Verarbeitungsaufträge die in einem besonderen Modus gestartet werden. Sie werden ausgeführt, weder in einer Verarbeitungswarteschlange noch anderweitig. Sie besitzen lediglich einen Status und es können Meldungen assoziiert werden. Sie werden programmatisch erzeugt und ihr lifecycle unterliegt komplett expliziter programmatischer Kontrolle. Aus Benutzersicht erscheinen sie wie Sub-Verarbeitungsaufträge (SubJobs).

3              Voraussetzungen

Verarbeitungsaufträge können entweder interaktiv oder programmatisch erfasst werden.

Wird ein Verarbeitungsauftrag freigegeben, so wird er in die eingetragene Verarbeitungswarteschlange eingereiht.

Je nach Auslastung der Warteschlange wird zu einem Zeitpunkt der Verarbeitungsauftrag ausgeführt, in dem die eingetragene Hintergrund-Anwendung gestartet wird. Dies geschieht losgelöst von der Benutzer Session in einer eigenen Session, die auch einem anderen Benutzer zugeordnet werden kann.

Beendet sich eine Hintergrund-Anwendung, so teilt sie der Warteschlange per Rückgabewert mit, ob der Verarbeitungsauftrag als abgearbeitet oder als abgebrochen gilt. Tritt in der Hintergrund-Anwendung eine unbehandelte Exception auf, so gilt der Verarbeitungsauftrag als abgebrochen.

4              Entwicklung

Für eine Hintergrund-Anwendung sind minimal 2 Entwicklungsobjekte notwendig, ein Entwicklungsobjekt vom Typ Anwendung und eine Java-Klasse. Je nach Komplexität und Anwendungsfall können noch eine Reihe anderer Entwicklungsobjekte hinzukommen. In diesem Dokument wird erst der Fall einer sehr einfachen Hintergrund-Anwendung dargestellt und anschließend auf die Feinheiten und komplexeren Anwendungsfälle eingegangen.

4.1        Einfache Hintergrund-Anwendungen

Für eine einfache Hintergrund-Anwendung müssen ein Entwicklungsobjekt vom Typ Anwendung und eine Java-Klasse erfasst werden. Diese beiden Objekte werden in diesem Abschnitt beschrieben.

4.1.1    Entwicklungsobjekt „Anwendung“

Für eine Hintergrund-Anwendung muss ein Entwicklungsobjekt vom Typ Anwendung erfasst werden.

Typ der Anwendung

Der Typ der Anwendung muss „Hintergrund“ sein. Wählen Sie für die Bezeichnung eine möglichst prägnante Beschreibung der Hintergrund-Anwendung.

Besondere Verwendung

Für die besondere Verwendung stehen die folgenden Einstellungen zur Auswahl:

• keine besondere Verwendung (Feld bleibt leer)

Die Hintergrund-Anwendung ist eine „normale“ Hintergrund-Anwendung, die keiner besonderen Verwendung unterliegt.

• Datenaktualisierung

Die Hintergrund-Anwendung ist eine Datenaktualisierung und wird automatisch bei der Installation einer Softwareaktualisierung, die eine neue Version der Anwendung enthält, ausgeführt. Stellen Sie sicher, dass zum Ausführungszeitpunkt dieser Hintergrund-Anwendung alle benötigten Softwareaktualisierungen bereits aktiviert sind.

• Datenaktualisierung im Hintergrund

Die Datenaktualisierung ist eine Hintergrund-Anwendung und kann von einem Benutzer in der Anwendung „Verarbeitungsaufträge“ gestartet werden.

• Reorganisation

Eine Hintergrund-Anwendung mit dieser besonderen Verwendung kann in der Anwendung „Reorganisationsaufträge“ verwendet werden. Der Name von Reorganisations-Anwendungen muss auf „Reorganization“ enden. Weitere Informationen zu Reorganisationsanwendungen finden Sie in der Dokumentation „Referenzhandbuch: Reorganisationen“.

• Wiederanlauffähige Anwendung

Die Hintergrund-Anwendung wird nach einem nicht selbst verschuldeten Abbruch beim Neustart des Application-Servers fortgesetzt.

Anzeige und Wartung

Für die Anzeige- und Wartungseinstellungen sind folgende Abhängigkeiten zur Einstellung der besonderen Verwendung zu beachten:

• Anzeige, Wartung
• Ohne besondere Verwendung

Die Hintergrund-Anwendung erscheint im Navigatormenu im Unterordner „Hintergrundverarbeitungen“ des jeweiligen Frameworks. Die Hintergrund-Anwendung kann im Benutzermenu verwendet werden.

• Datenaktualisierung

Für Datenaktualisierungen ist die Sichtbarkeits- und Wartungseinstellung bedeutungslos.

• Datenaktualisierung im Hintergrund

Die Hintergrund-Anwendungen mit der Anwendung „Verarbeitungsaufträge“ gestartet werden.

• Reorganisation

Näheres entnehmen Sie bitte der Dokumentation Reorganisationaufträge

• Keine Anzeige, Wartung

Diese Einstellung wird typischerweise genutzt, um Anwendungen nur kontextbezogen starten zu können über „Starten einer Folgeverarbeitung“, also rein programmatisch und nicht über die Anwendung „Verarbeitungsaufträge“.

• Keine Anzeige, keine Wartung

Die Einstellung „ohne Wartung“ hat keinerlei technische Konsequenzen. Sie dient lediglich als Hinweis, dass die Wartung der Anwendung nicht erfolgt und auch nicht geplant ist.

• Keine Anzeige, keine Wartung, mit Freischaltcode

Diese Einstellung entspricht der Einstellung „Keine Anzeige, keine Wartung“ und legt zusätzlich fest, dass die Anwendung nur unter Angabe eines Freischaltcodes verwendet werden kann. Im Fall von Tools kann der Freischaltcode auch nur für bestimmte Parameter erforderlich sein.
Die Freischaltcodes werden vom Comarch-ERP-Enterprise-Supportcenter vergeben.

Berechtigungsmodus

Im Feld Berechtigungsmodus können Sie angeben, ob die individuellen Berechtigungen des Benutzers bei der Ausführung der Anwendung geprüft werden sollen. Im Einzelfall kann es sinnvoll oder notwendig sein auf eine solche Prüfung zu verzichten.

Framework

Die Hintergrund-Anwendung muss einem Framework zugeteilt werden. Gegebenenfalls erscheint dann die Hintergrund-Anwendung auch im entsprechenden Navigatormenu.

Primäres Business Entity

Die Angabe des primären Business Entities entscheidet darüber, für welche Datenbanken die Hintergrund-Anwendung ausführbar ist bzw. ausgeführt wird.

Funktion

Die Hintergrund-Anwendung kann durch eine Funktion gesteuert sein.

Datenbank

Geben Sie die Datenbanken an, die zum Zeitpunkt der Ausführung bereitgestellt sein müssen.

4.1.2    Entwicklungsobjekt „Java-Klasse“

Im einfachsten Fall muss diese Klasse von der Klasse com.cisag.pgm.base.CisApplication abgeleitet sein. Die Methode run(…) muss hierzu implementiert werden.

public class SimpleBatchApplication extends CisApplication {

 

public CisParameterList run(int action, CisParameterList parms) {

}

}

4.1.3    Meldungen in Hintergrund-Anwendungen

Werden in einer Hintergrund-Anwendung Meldungen erzeugt, so müssen diese in die MessageQueue der aufrufenden Anwendung übertragen werden. Anderenfalls erscheinen diese nicht in den Meldungsprotokollen. Deshalb sollte eine der letzten Anweisungen in der run-Methode

mm.sendProgramMessages(CisMessageManager.PREVIOUS);

lauten.

4.1.4    Rückgabewerte der Hintergrund-Anwendung

Eine Hintergrund-Anwendung muss den eigenen Status an das System über den Rückgabewert ihrer run-Methode zurückgeben. Um dieses zu unterstützen gibt es die Hilfsklasse com.cisag.pgm.base.CisApplicationCallResult. Ein Objekt dieser Klasse wird mit createInstance erzeugt und der entsprechende Status mit der Methode setResult(short result) gesetzt. Über die Methode serialize() wird dann der Rückgabewert der run-Methode erzeugt. Folgende Rückgabewerte sind für eine Hintergrund-Anwendung möglich:

Wert	Bedeutung
COMPLETED	Die Hintergrund-Anwendung wurde erfolgreich beendet. Es wird empfohlen eine Informationsmeldung in die Messagequeue einzutragen
ABORTED	Die Hintergrund-Anwendung wurde abgebrochen. Es sollten entsprechende Fehlermeldungen in die Messagequeue eingetragen worden sein.

4.1.5    Beispiel

public class SimpleBatchApplication extends CisApplication {

 

public CisParameterList run(int action,

CisParameterList parms) {

 

CisApplicationCallResult result =

CisApplicationCallResult.createInstance(parms);

CisMessageManager mm =

CisEnvironment.getInstance().getMessageManager();

 

// Do something useful …

 

result.setResult(CisApplicationCallResult.COMPLETED);

mm.sendProgramMessages(CisMessageManager.PREVIOUS);

return result.serialize();

}

}

4.2        Starten einer Hintergrund-Anwendung

Hintergrund-Anwendungen können auf verschiedene Art und Weisen gestartet werden. Dies hängt zum einen von den Einstellungen im zugehörigen Entwicklungsobjekt Anwendung ab, als auch vom intendierten Verwendungszweck.

Hinweis:

Genau genommen wird eine Hintergrund-Anwendung durch die hier beschriebenen Schritte nicht zwingend sofort gestartet sondern im Normalfall lediglich in die entsprechende Warteschlange eingetragen. Wann exakt die Ausführung der Hintergrund-Anwendung beginnt hängt dann von einer Reihe anderer Parametern ab, wie z.B. die Anzahl der Worker für die Warteschlange und die aktuelle Auslastung der Warteschlange. Nur in dem Fall, dass auf dem Dialog zum Starten der Hintergrundverarbeitung der Button „sofort“ gedrückt wird, wird die Hintergrund-Anwendung auch sofort ausgeführt. In diesem Fall wird auch kein Verarbeitungsauftrag angelegt. Prüfen Sie genau, ob Sie diese Startmöglichkeit dem Benutzer wirklich anbieten möchten. Mit dieser Startmöglichkeit wird ein Thread auf einem SAS blockiert, der für die Dialogverarbeitung vorgesehen ist. Im Allgemeinen ist dies nur bei kurzlaufenden Hintergrund-Anwendungen akzeptabel.

4.2.1    Anwendung „Verarbeitungsaufträge“

Ist die Hintergrund-Anwendung als „Anzeige, Wartung“ erfasst und hat keine besondere Verwendung, so kann sie mit der Anwendung Verarbeitungsaufträge gestartet werden.

4.2.2    Der JobSubmitDialog

Mit der Klasse com.cisag.pgm.services.batch.JobSubmitDialog kann programmatisch eine Hintergrund-Anwendung gestartet werden, die eine zusätzliche Interaktion mit dem Benutzer benötigt. Dazu muss eine Instanz von JobSubmitDialog mittels eines Aufrufs von createInstance erzeugt werden.

An der erzeugten Instanz des JobSubmitDialogs muss dann der owner gesetzt werden. Dieses kann entweder eine CisUiApplication sein oder ein VisualElement.

Weiterhin kann mit dem Aufruf von setTitleFrom() der Title des Dialoges aus einem Stringtable gesetzt werden. Der erste Parameter ist dabei der path zum table, der zweite Parameter eventuell notwendige Ersetzungsparameter für im String vorhandene Platzhalter.

Mit dem Aufruf von setBatchJob(CisBatchJob) werden weitere Parameter für die Hintergrundabarbeitung gesetzt. Die direkte Erzeugung eines CisBatchjob-Objektes wird nicht empfohlen. Stattdessen gibt es eine Serviceklasse CisBatchService, die diese Aufgabe unterstützt. Die Benutzung der Klasse CisBatchService wird im nachfolgenden Kapitel beschrieben.

Abschließend wird der JobSubmitDialog durch Aufruf von show() zur Anzeige gebracht. Der Benutzer kann die entsprechenden Eingaben machen bzw. ändern und die Hintergrund-Anwendung starten oder auch den Startvorgang abbrechen.

Beispiel:

import com.cisag.pgm.services.batch.JobSubmitDialog;

JobSubmitDialog jsd = JobSubmitDialog createInstance():

// Entweder setOwner(CisUiApplication) oder setOwner(VisualElement)

jsd.setOwner(this);

jsd.setTitleFrom(String,String[]);

jsd.setBatchJob(cisBatchJob);

 

4.2.3    CisBatchService

Die Klasse com.cisag.pgm.services.batch.CisBatchService kann zum einen dafür genutzt werden um ein CisBatchJob-Objekt zu erzeugen, zum anderen auch um direkt eine Hintergrund-Anwendung ohne Benutzerinteraktion zu starten.

Beim Erzeugen des CisBatchJob-Objektes werden diverse Parameter für den Job auf Standardwerte gesetzt. Dies erleichtert das Erstellen korrekter CisBatchJob-Objekte. Anschließend können zusätzliche Werte eingetragen werden oder nicht gewünschte Einstellungen überschrieben werden.

Beispiel:

CisBatchService cbs = CisBatchService.getInstance();

CisBatchJob job = cbs.createJob(false);

 

job.setName(“Meine Hintergrundverarbeitung“);

 

// direkt starten

cbs.submitJob(job);

// alternativ mit JobSubmitDialog starten

//

// JobSubmitDialog dialog = JobSubmitDialog createInstance();

//

// … owner und title setzen …

//

// dialog.setBatchJob(cbs);

//

// dialog.show();

4.3        Parametrisieren von Hintergrund-Anwendungen

Hintergrund-Anwendungen können zum einen über die Angabe eines action-Parameters und zum anderen über eine Werteliste parametrisiert werden. Der action-Parameter ist dabei zur Auswahl unterschiedlicher Verarbeitungsstränge vorgesehen und wird typischerweise in der run-Methode über ein switch-case-Statement ausgewertet. Die Werteliste, in Form einer CisParameterList, besteht aus Name-Typ-Wert-Tripeln, die in den Verarbeitungsprozess einfließen können. Die für die Hintergrund-Anwendung zulässigen Actions und ihre Werte-Parameter müssen im Entwicklungsobjekt Anwendung erfasst werden.

4.3.1    Hintergrund-Anwendungen mit automatischem Editor

Wird mit der Anwendung „Hintergrund-Anwendungen starten“ eine Hintergrund-Anwendung gestartet, deren Java-Klasse von CisApplication abgeleitet ist und für die im Entwicklungsobjekt Anwendung eine oder mehrere Actions mit Parametern erfasst sind, so bekommt der Benutzer eine Auswahl der erfassten Actions angeboten. Abhängig von der gewählten Action werden Eingabefelder gemäß der erfassten Parameter angeboten. Die gewählte Action und die eingegebenen Werte werden beim Start der Anwendung an die run-Methode der Hintergrund-Anwendung in Form einer CisParameterList übergeben. In der run-Methode können die Werte mit den passenden get-Methoden der CisParameterList abgefragt werden. Als Parameter dient der im Entwicklungsobjekt Anwendung erfassten Namen der action-Parameter.

4.3.2    Hintergrund-Anwendungen mit Editor

Wird eine Anwendung mit einem JobSubmitDialog gestartet, so können die in der erfassten Action deklarierten Parameter vom Benutzer eingegeben werden. Dieser Mechanismus ist allerdings nicht sehr flexibel. Es besteht die Möglichkeit einen eigenen Editor zu implementieren, um die Abläufe zwischen den Eingabefeldern programmatisch selbst steuern zu können.

Hinweis:
Diese Möglichkeit einen eigenen Editor für den SubmitJobDialog zu implementieren wird nicht mehr empfohlen. Mit dieser Verfahrensweise muss die aufrufende Anwendung Implementationsdetails, z.B. den Namen des Editor-Views, der Hintergrund-Anwendung verwenden. Die Benutzung dieser Variante ist im Besonderen für das Kontextmenu sehr schwierig, da dieses keine Kenntnisse über die Existenz eines entsprechenden Views hat. Wir empfehlen generell die Benutzung eines Batch-Editors. Näheres entnehmen sie bitte dem folgenden Kapitel.

Am JobSubmitDialog kann mit dem Aufruf der Methode setCustomTabView(Action, View) ein View hinterlegt werden, der den benötigten Editor implementiert. Dieser EditorView wird dann in einem eigenen Tab im JobSubmitDialog angezeigt. Über die Action kann das Erscheinungsbild des Tabs gesteuert werden (Label, Tooltip, etc.). Die Action wird vom JobSubmitDialog gefeuert, Aufgabe des zu registrierenden Listener ist es, die Daten zu validieren und diese der Hintergrund-Anwendung zur Verfügung zu stellen. Dabei dürfen Meldungen via Messagemanager erzeugt werden. Üblicherweise wird der View selbst als Listener registriert und die aus dem View gelesenenen Werte werden in die CisParameterListe des BatchJob-Objektes eingefügt.

Beispiel:

public class CustomView extends View implements ActionListener{

 

ShortField field;

CisParameterList pl;

 

public void init(CisParameterList pl){

 

this.pl = pl;

 

setLayout(new StandardLayout());

field =

new ShortField(Guid.AUTOGUID, “com.cisag.app.financials.batch:StartTransferBatchesDuration.lt”);

add(field);

field.setValue(pl.getShort(“StartTransferBatchesDuration”));

}

 

public void performAction(Action action) {

 

// validate field … if not ok, send some error-message

 

mm.sendMessage(“APP”,333);

 

pl.setShort(“StartTransferBatchesDuration”, field.getValue());

}

 

}

Benutzung:

com.cisag.pgm.services.batch.JobSubmitDialog dialog = obSubmitDialog createInstance()

setOwner(…)

setTitleFrom(…,…);

dialog.setBatchJob(CisBatchJob)

 

CustomView customView = new CustomView();

 

Action customViewAction = new Action(“…“);

customViewAction.register(customView);

 

dialog.setCustomTabView(customViewAction, customView)

dialog.show();

4.3.3    Batch-Editor

Die im vorhergehenden Kapitel beschriebene Methode einen eigenen Editor zu implementieren, kann noch vereinfacht werden.

Dazu muss die Hintergrund-Anwendung von CisBatchApplication abgeleitet sein und zusätzlich die Methode createEditor() implementiert werden. Diese Methode muss ein Objekt zurückliefern, welches eine Instanz einer Klasse ist, die wiederum von CisBatchApplicationEditor abgeleitet ist.

Beispiel einer Implementation eines CisBatchEditors (Auszug):

public class BatchApplicationTest extends CisBatchApplication {

 

@Override

public CisBatchApplicationEditor createEditor() {

// TODO Auto-generated method stub

return new BatchApplicationTestEditor();

}

 

@Override

public CisParameterList run(int action, CisParameterList parms) {

 

CisApplicationCallResult result = CisApplicationCallResult.createInstance(parms);;

 

return result.serialize();

}

}

 

class BatchApplicationTestEditor extends CisBatchApplicationEditor {

 

private static final int MSG = 42;

private View contentPane;

private ShortField field;

private short actionId;

 

public boolean isOnlineSubmitEnabled() {

// online execution is not allowed, otherwise return true

return false;

}

 

public void init(int visualizationType) {

contentPane = new View(new StandardLayout());

field =

new ShortField(Guid.AUTOGUID,

“com.cisag.app.financials.batch:StartTransferBatchesDuration.lt”);

contentPane.add(field);

 

field.registerMessage(MSG);

}

 

public VisualElement getVisualElement() {

return contentPane;

}

 

public short getActionId() {

return actionId;

}

 

public void applyDefaults() {

// set defaults to fields

}

 

public void dataToUi() {

// copy data from parameterlist to fields

}

 

public void dataFromUi() {

// copy data from fields to parameterlist

}

 

public void validate() {

// validate values and send messages if necessary

}

}

 

4.4        Freischaltbare Anwendungen

Wenn für die Hintergrundanwendung die Einstellung „Keine Anzeige, keine Wartung, mit Freischaltcode“ festgelegt ist, dann ist zum Ausführen der Anwendung die Angabe eines Freischaltcodes erforderlich. Der Freischaltcode ist nur in einen bestimmten Zeitraum gültig. Die Freischaltcodes werden vom Comarch-ERP-Enterprise-Supportcenter vergeben.

Soll die Anwendung interaktiv über JobSubmitDialog gestartet werden, dann steht in dem Dialog-Fenster das Feld „Freischaltcode“ zur Verfügung, in das ein gültiger Freischaltcode eingegeben werden muss, bevor die Anwendung geöffnet werden kann.

Soll die Anwendung programmatisch, typischerweise über die Methoden CisBatchService.callJob(CisBatchJob) oder CisApplicationManager.callApplication(CisApplicationCall), gestartet werden, so muss die Parameterliste des übergebenenen Objektes den speziellen String-Parameter „UNLOCK_CODE“ mit einem gültigen Freischaltcode als Wert enthalten.

4.5        Wiederanlauffähige Anwendungen

Eine Hintergrund-Anwendung kann aus selbstverschuldeten Gründen, z.B. einer Exception, oder aus anwendungsfremden Gründen, z.B. Neustart des Applicationservers, abgebrochen werden. Wiederanlauffähige Anwendungen werden nach einem solchen nicht selbst verschuldeten Abbruch beim Neustart des Applicationservers automatisch neu gestartet. Um eine Hintergrund-Anwendung als wiederanlauffähig zu kennzeichnen, muss im Entwicklungsobjekt der Anwendung die besondere Verwendung „Wiederanlauffähige Anwendung“ oder „Dienst“ ausgewählt werden.

Normalerweise sollte die Anwendung beim Wiederanlauf nicht von vorne beginnen, sondern die Abarbeitung am Abbruchspunkt, bzw. dem letzten erfolgreichen Commit fortsetzen. Zur Unterstützung dieses Verhaltens bietet die Klasse CisBatchApplication eine Schnittstelle, mit derer der aktuelle Zustand der Anwendung transaktionsgebunden gespeichert werden kann.

4.6        Statusdaten

Die Klasse CisBatchApplication stellt eine Schnittstelle zur Verfügung, die Daten über den aktuellen Zustand der Abarbeitung speichern kann. Die folgenden Methoden können dazu aufgerufen werden:

protected final void putStatusData(CisParameterList statusData)

protected final CisParameterList getStatusData()

 

Durch Aufruf von putStatusData können Informationen über die bereits erledigten Arbeitsschritte als CisParamterList in der Datenbank gespeichert werden. Diese werden erst mit einem Commit der zugehörigen Toplevel Transaktion persistent. Sinnvollerweise wird die Methode also in der gleichen Transaktion aufgerufen, die auch die eigentlichen Verarbeitungsschritte klammert. Durch Aufruf von getstatusData können die Statusdaten wieder gelesen werden.

Dieser Mechanismus funktioniert in der beschriebenen Art und Weise nur, wenn die Hintergrund-Anwendung auch in einer Warteschlange ausgeführt wird. Wird die Anwendung in einer Dialog Session ausgeführt, z.B. durch Drücken des Buttons „Sofort“ in der Anwendung „Hintergrundverabeitung“, so liefert getStatusData immer eine leere CisParameterList zurück.

4.7        Sub-jobs (Unterverarbeitungsaufträge)

Eine Hintergrund-Anwendung kann selbst wieder Hintergrund-Anwendungen starten. Im Allgemeinen wird die startende Hintergrund-Anwendung (parent) auf die Ergebnisse ihrer sub-jobs (children) warten, z.B. weil die Ergebnisse benötigt werden.

Mehrere sub-jobs zu starten ermöglicht prinzipiell eine Parallelisierung der Ausführung der Arbeitsschritte. Allerdings schafft die Benutzung der sub-jobs nur die Möglichkeit der Parallelisierung, um diese auch zur Laufzeit nutzen zu können, muss die Verarbeitungwarteschlange entsprechend konfiguriert werden. Werden der Warteschlange mehrere Worker zugeordnet, so können mehrere sub-jobs auf einem SAS abgearbeitet werden. Ist die Warteschlange als verteilte Warteschlange konfiguriert, so können die sub-jobs auch auf mehreren SAS verteilt abgearbeitet werden.

Werden die sub-jobs von einer Hintergrund-Anwendung gestartet, so wird die Hintergrund-Anwendung zunächst vorläufig beendet. Bei Bedarf ist einstellbar, dass die Hintergrund-Anwendung wieder gestartet werden soll, nachdem alle sub-jobs beendet sind. Soll die Hintergrund-Anwendung nicht erneut gestartet werden, wird der Status der Hintergrund-Anwendung erst dann auf finished gesetzt, wenn alle sub-jobs erfolgreich beendet worden sind. Soll die Hintergrund-Anwendung wieder gestartet werden, so wird der Status der Hintergrund-Anwendung erst dann auf finished gesetzt, wenn dieser Status über den Rückgabewert der run-Methode der Hintergrund-Anwendung entsprechend gesetzt wurde.

Beispiel (Auszug):

public class SubJobTest extends CisApplication {

 

private final static int RESTART = 999;

 

public CisParameterList run(int action, CisParameterList parms) {

CisApplicationCallResult result = CisApplicationCallResult.createInstance(parms);

 

CisBatchService cbs = CisBatchService.getInstance();

 

switch(action) {

case RESTART:

 

// do something with the results of the subjob ….

 

result.setResult(CisApplicationCallResult.COMPLETED);

break;

 

default:

 

CisBatchJob subJob = cbs.createSubJob(parms);

 

// make other settings for subJob …

 

short state = cbs.submitJob(subJob);

byte[] subJobGuid = subJob.getGuid();

 

CisList batchJobGuids = new CisArrayList();

CisList failed = new CisArrayList();

if(state == CisBatchService.SUCCESS) {

batchJobGuids.add(subJobGuid);

} else {

failed.add(subJobGuid);

}

 

result.setWaitForBatchJobs(batchJobGuids, RESTART, parms);

result.setResult(CisApplicationCallResult.COMPLETED);

}

 

return result.serialize();

}

 

}

Wenn Sie ein komplexeres, praxisnahes Beispiel benötigen, bitte betrachten Sie die Java-Klasse com.cisag.app.sales.invoice.log.Invoicing, die mit dem Standard bereitgestellt wird.

4.8        Pseudo-Verarbeitungsaufträge

Die Kopplung von Verarbeitungsaufträgen und deren Meldungen ist ein im System fest eingebauter Mechanismus um Verarbeitungsschritte zu protokollieren. Der Benutzer kann auf elegante Weise sämtliche erzeugten Meldungen zu einem Verarbeitungsauftrag einsehen. Manchmal ist jedoch die Menge der Meldungen nicht angemessen strukturiert. Dies könnte man durch das Erzeugen von SubJobs für kleinere Verarbeitungseinheiten besser strukturieren. Dies bedeutet allerdings einen drastisch erhöhten technischen Verwaltungsaufwand mit zugehörigem Ressourcenverbrauch.

Für diesen Anwendungsfall können Hintergrund-Anwendungen mit einem speziellen Startmode gestartet werden. Die Hintergrund-Anwendung wird dann von den „normalen“ Verarbeitungswarteschlangen ignoriert. Stattdessen muss es eine Anwendung geben, die sowohl die eigentliche Funktionalität implementieren als auch den Status der Hintergrund-Anwendung steuert. Die startende Anwendung muss den Status der Hintergrund-Anwendung initial auf „released“ setzen durch Aufruf der Methode setRelease(java.lang.Boolean) am CisBatchJob Objekt. Die abarbeitende service Anwendung muss den Status während der Abarbeitung auf active setzen und nach der Abarbeitung auf completed. Erst dann kann die Hintergrundverarbeitung aus der Warteschlange entfernt werden.

Eine Hintergrund-Anwendung dieser Art kann Fehlermeldungen ausgeben, muss dann jedoch seinen Status zu aborted ändern. Die startende Anwendung wird über den finalen Status der Hintergrund-Anwendung informiert. Die Art der Benachrichtigung kann mit CisBatchJob#setNotificationMode(short) festgelegt werden. Entweder wird der Benutzer per Dialog benachrichtigt oder ein Workflow-Ereignis ausgelöst. Beide Varianten können für alle Meldungen gewählt werden oder nur für Fehlermeldungen.

Beispiel (Ausschnitt):

CisBatchService cbs = CisBatchService.getInstance();

 

CisBatchJob cbj = cbs.createJob(params);

 

cbj.setStartMode(com.cisag.pgm.services.batch.BatchJobStartMode.APPLICATION);

 

// set other values for the job,

// especially set an user readable name

 

cbs.changeJobState(JobStateAction. RELEASE_JOB);

 

cbs.callJob(cbj);

 

cbs.changeJobState(JobStateAction. ACTIVATE_JOB);

 

// do something useful

 

// if error, or anything other to report …

cbs.sendMessage(CisMessageManager.PROGRAM, cbj.getGuid());

 

cbs.changeJobState(JobStateAction. COMPLETE_JOB);

 

Hinweis:

Im Unterschied zu „normalen“ Verarbeitungsaufträgen beinhaltet die Parameterliste nur die Werte, die beim Erzeugen des CisBatchJob-Objektes hinzugefügt wurden. Dementsprechend werden auch nur diese Werte an der Oberfläche angezeigt. Es hat sich, insbesondere für die Fehlersuche, als günstig erwiesen, weitere Informationen in der Parameterliste zu hinterlegen. Diese sollten im Allgemeinen in benutzerlesbarer Form vorliegen.