| Auszug | ||
|---|---|---|
| ||
Nuclos Event-Regel Job: Interface, JobContext, Struktur, Zuweisung im Server-Regelmanager, Beispielcode (Java). |
Sprache: Deutsch · English
Ereignis-Regel „Job“: Interface, Kontext und ein Beispiel – so reagierst du auf dieses Nuclos-Ereignis.
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Panel | ||||
|---|---|---|---|---|
| ||||
Auf dieser Seite
|
...
Regeln des Typs "Job" können nur Fristen zugewiesen werden und müssen das Interface "JobRule" implementieren.
Innerhalb des Baums mit der Regelbibliothek werden sie dem Knoten "Job" zugeschrieben.
Quellcode einer Klasse des Typs "Job":
...
|
Diese serverseitige Regel wird ausgeführt zeitgesteuert durch einen Job/Timer. Sie kann einem Timer/Job zugewiesen werden.
Grundgerüst der Regelklasse (der Regeleditor legt es automatisch an):
| Codeblock | ||
|---|---|---|
| ||
package org.nuclet.lager;
import org.nuclos.api.rule.JobRule;
import org.nuclos.api.context.JobContext;
import org.nuclos.api.annotation.Rule;
import org.nuclos.api.exception.BusinessException;
/** @name
* @description
* @usage
* @change
*/
@Rule(name="Job Lager", description="Job Lager")
public class JobLager implements JobRule {
public void execute(JobContext context) {
//So werden Logs während des Ausführen in den Reiter Log Info in der Jobsteuerung geschrieben
context.joblog(e.getMessage());
context.joblogError("TEST");
context.joblogWarn("Warnung");
}
} |
...
Das entsprechende Interface schreibt die Implementierung der Methode "execute" vor und liefert als Kontext die Klasse JobContext. Darin enthalten ist die Session-Id.
Innerhalb der execute-Methode kann der Regelprogrammierer auch eine BusinessException auslösen, die zwar geloggt wird, aber nicht zum Abbruch der Jobdurchführung führt.
Die Angabe der Annotation "Rule" ist nicht zwingend notwendig, wird aber empfohlen, da die Beschreibungen (name und description) im Regelbibliotheksbaum angezeigt werden.
Normalerweise wird die gesamte Verarbeitung des Jobs in nur einer Transaktion ausgeführt. Wenn man die Verarbeitung auf mehrere Transaktionen verteilen möchte muss das Interface TransactionalJobRule zusätzlich implementiert werden. Die Methode getTransactionalObjects(JobContext context) liefert eine Liste vom Typ Object wobei nun für jedes Element in der Liste eine eigene Transaktion eröffnet wird. Dabei wird für jedes Object die Methode execute(JobContext context) aufgerufen. Das Object kann vom JobContext mittels .getTransactionalObject() abgeholt werden.
Quellcode einer Klasse des Typs "Job" mit "TransactionalJobRule":
...
| Info | ||
|---|---|---|
| ||
Der Kontext |
Im Server-Regelmanager per Drag-and-Drop dem Ziel zuweisen. Optional lässt sich die Ausführung auf einen Status oder eine Aktion einschränken; die Reihenfolge steuerst du über die Pfeil-Buttons.
Zuweisung „Job“.
Das folgende Beispiel soll den Aufbau einer Regel vom Typ „Job„ veranschaulichen.
| Codeblock | ||
|---|---|---|
| ||
package org.nuclet.company; import java.util. |
...
List;
import org.nuclos.api.annotation.Rule;
import org.nuclos.api.context.JobContext |
...
;
import org.nuclos.api.provider.QueryProvider;
import org.nuclos.api.rule.JobRule;
|
...
|
...
/** @name
* @description
* @usage
* @change
*/
|
...
@Rule(name=" |
...
JobBestellungenPruefen", description=" |
...
JobBestellungenPruefen") public class |
...
JobBestellungenPruefen implements JobRule |
...
|
...
{
|
...
public void execute(JobContext context){ |
...
// |
...
Get |
...
all |
...
Bestellungen List<Bestellung> lstBestellungen = QueryProvider.execute( QueryProvider.create(Bestellung.class)); for (Bestellung b : lstBestellungen) { // orders that are not confirmed are ok, but should be logged as infos if (Boolean.FALSE.equals(b.getBestaetigt())) { context.joblog("Info: Bestellung " + b.getNummer() + " wurde noch nicht bestätigt."); } // orders without articles are formally valid, but dont make sense if (b.getPosition().size() <= 0) { context.joblogWarn("Warnung: Bestellung " + b.getNummer() + " besitzt keine Positionen"); } // orders without an internal advisor are formally invalid if (b.getSachbearbeiter() == null) { context.joblogError("Fehler: Bestellung " + b.getNummer() + " besitzt keinen Sachbearbeiter"); } } } } |
Wird die Mandantenfähigkeit für ein BO aktiviert, werden automatisch alle objektbezogenen Regeln (Speichern, Status, etc.) im Kontext des im BO hinterlegten Mandanten ausgeführt. Damit werden z.B. Queries auf andere BOs, welche ebenfalls mandantenabhängig sind, automatisch auf den gleichen Mandanten eingeschränkt.
Da ein Job nicht objektbezogen arbeitet kann in der Jobsteuerung gepflegt werden, für welche Mandanten dieser Job laufen soll. Ein Joblauf wird dann alle eingetragenen Mandanten berücksichtigen und hintereinander die execute Methode mit einem entsprechenden mandanteneingeschränkten Kontext aufrufen.
Eine weitere Alternative bietet die TransactionalJobRule (siehe weiter oben), wenn die Liste mandantenabhängige BOs enthält. In solch einem Fall ist die neue Transaktion auch gleich auf den im BO hinterlegten Mandanten eingeschränkt. Das hat den Vorteil, dass keine zusätzliche Konfiguration im Job nötig ist.
Klassen des Typs "Job" können nur Fristen zugewiesen werden. Nach der Verknüpfung erscheint die Klasse nach Auswahl der Frist und des Typs im Zuweisungsfenster.
Mit dem Symbol des Mülleimers kann die Zuweisung der Klasse zur Frist gelöscht werden. Wichtig ist, dass damit nur die Zuweisung gelöscht wird. Weiterhin lässt sich mit Hilfe der Pfeile-Buttons die Ausführungsreihenfolge verändern.
Jede Änderung wird automatisch gespeichert.
Hier finden Sie ein Beispiel, das den Aufbau einer Regel vom Typ "Job" veranschaulicht.