Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

Für die Regelprogrammierung müssen Informationen und Daten zu den Entitäten, den Statusmodellen und anderen Nuclos-Einheiten zur Verfügung stehen. Damit der Zugriff und die Verwendung möglichst einfach und fehlerfrei bleibt, werden diese Daten objektiviert als Java-Klassen bereit gestellt. Diese Java-Klassen können dann aus den Regeln heraus aufgerufen und benutzt werden.

...

public class ErstelleRechnungAusAuftragGEN implements Generation<Auftrag, Rechnung> { public Class<Auftrag> getSourceModule() { return Auftrag.class; } public Class<Rechnung> getTargetModule() { return Rechnung

.

class; } }

Die Handhabung des GenerationProviders wird hier erklärt.

Allgemeine Konventionen:

  • Der Name der Arbeitsschritt-Klasse entspricht dem java-tauglich überarbeiteten Namen des Arbeitsschritt. So sind weder Sonderzeichen noch Leerzeichen erlaubt.
  • Jede Arbeitsschritt-Klasse besitzt weiterhin eine Package-Angabe. Wurde ein Arbeitsschritt keinem Nuclet zugewiesen, wird als Default das Package "org.nuclet.generation" verwendenverwendet, ansonsten der Pfad des Nuclets, z.B: org.meineFirma.meinNuclet
  • Als Quell- und Zielklassen werden die BusinessObjekte der Entitäten verwendet, die im Arbeitsschritt angegeben wurden.

Beispiel der Arbeitsschritt-Klasse "ErstelleRechnungAusAuftragGEN":

TypBeschreibungSuffix
BusinessObjekt

Ein BusinessObjekt repräsentiert eine NuclosEntität wie z.B. Auftrag oder Kunde. Die dazugehörenden Felder werden aus den Meta-Informatioen glesen Informationen gelesen und als Attribute in die Klasse geschrieben. Ja nach Art des Attributts Attributs und der Zugriffsrechte werden setter und getter-MEthoden Methoden zum Setzen und Auslesen von Werten zur Verfügung gestellt.

Wird mittels EntityWizzard Entitäten-Wizzard eine neue Entität angelegt oder eine bestehende verändert oder gelöscht, werden mit erfolgreichem dem erfolgreichen Abschluss des Speichervorgangs die Ändergeun im alle Änderungen in dem dazugehörenden BusinessObjekt vorgenommen und im Classloader angelegtabgelegt. Damit stehen die Änderungen sofort zur Verfügung.

Allgemeine Konventionen:

  • Der Name des BusinessObjekts entspricht dem java-tauglich überarbeiteten Namen der Entität. So sind weder Sonderzeichen noch Leerzeichen erlaubt.
  • Jedes BusinessObjekt besitzt weiterhin eine Package-Angabe. Wurde eine Entität keinem Nuclet zugewiesen, wird als Default das Package "org.nuclet.businessentity" verwendenverwendet, ansonsten der Pfad des Nuclets, z.B: org.meineFirma.meinNuclet
  • Die Felder der Entität können mit gettern und setter befüllt, bzw. ausgelesen werden. Sondernzeichen. Beispiel: setBestelldatum(Date dat). Sonderzeichen, Leerzeichen oder auch Zahlen zu Beginn des Namens sind nicht erlaubt und werden bei der Generierung der Klassen automatisch korrigiertentfernt/ersetzt, weshalb es zu Abweichungen zwischen den Namen der Methoden/Klassen und den Meta-Informationen aus dem Entitäten-Wizzard kommen kann. Beispiel: setBestelldatum(Date dat) 
  • Für die Abfrage der Dependents stehen ebenfalls Methoden zur Verfügung, die - wenn gewünscht - mit Flags erweitert werden können und , um eine Einschränkung deren Status vornehmen zu können. Beispiel: public List<Bestellposition> getBestellposition(Flag... flags). Mögliche Flags sind: NONE, UPDATE, INSERT oder DELETE. Damit Somit kann festgelegt werden, ob nur als gelöscht markierte Dependents zurückgegeben werden sollen oder z.B. solche, die auf der Oberfläche neu hinzugefügt wurden,.
  • Das BusinessObjekt umfasst ebenfalls Konstanten, welche für die Erstellung von Abfragen im im QueryProvider verwendet werden können.

Beispiel eines BusinessObjekts "Adresse":

Codeblock
public class Adresse extends AbstractBusinessObject implements Modifiable {

public static final Attribute<java.lang.Boolean> Standard = new Attribute<java.lang.Boolean>("Standard", "org.nuclet.basistemplatebasis", "Adresse", new Long(40005905), "standard", new Long(40006275), java.lang.Boolean.class );

public static final StringAttribute<java.lang.String> Postfach = new StringAttribute<java.lang.String>("Postfach", "org.nuclet.basistemplatebasis", "Adresse", new Long(40005905), "postfach", new Long(40006271), java.lang.String.class );

public java.lang.Boolean getStandard()
{
return getField("standard", java.lang.Boolean.class); 
}
public void setStandard(java.lang.Boolean pStandard)
{
 setField("standard", pStandard); 
}
public java.lang.String getPostfach()
{
return getField("postfach", java.lang.String.class); 
}
public void setPostfach(java.lang.String pPostfach)
{
 setField("postfach", pPostfach); 
}
}

--
Statusmodell-Klasse

Eine Statusmodell-Klasse ist eine Java-Klasse, die fachlich einem in Nuclos erstellen Statusmodell entspricht. Diese  Statusmodell-Klassen werden in der Regelprogrammierung verwendet, um eine einfache und sichere Gestaltung von beispielsweise Statuswechseln zu gewährleisten.

Allgemeine Konventionen:

  • Der Name der Statusmodell-Klasse entspricht dem java-tauglich überarbeiteten Namen des Statusmodells. So sind weder Sonderzeichen noch Leerzeichen erlaubt.
  • Jede Statusmodell-Klasse besitzt weiterhin eine Package-Angabe. Wurde ein Arbeitsschritt keinem Nuclet zugewiesen, wird als Default das Package "org.nuclet.statemodel" verwendenverwendet, ansonsten der Pfad des Nuclets, z.B: org.meineFirma.meinNuclet
  • Die Statusmodell-Klasse umfasst alle ihr zugewiesenen Status als statische Konstanten mit folgender Namenskonvention: "State_[Statusnumeral]. Beipsiel: AuftragSM.State_10  

Beispiel der Statusmodell-Klasse "AuftragSM":

Codeblock
public class AuftragSM{
public static State State_10 = 
    new StateImpl(IdUtils.toLongId(40006496), "Entwurf", "Geplant", 10, IdUtils.toLongId(40006477));
public static State State_90 = 
    new StateImpl(IdUtils.toLongId(40006497), "Abgeschlossen", "Abgeschlossen", 90, IdUtils.toLongId(40006477));
public static State State_50 = 
    new StateImpl(IdUtils.toLongId(40006498), "Offen", "Offen", 50, IdUtils.toLongId(40006477));
public static State State_99 = 
    new StateImpl(IdUtils.toLongId(40006499), "Storniert", "Storniert", 99, IdUtils.toLongId(40006477));
}

Die hinterlegten Status können für manuelle Statuswechsel im im StatemodelProvider verwendet werden.

SM
Arbeitsschritt-Klasse

In Nuclos können Arbeitsschritte erstellt werden. Um auch innerhalb von Regeln solche Arbeitsxchritte auch Arbeitsschritte manuell ausführen zu können, werden nach erflogreichen Abschluss des Speicvhernvorgang einesArbeitschrittes sogenanten dem erfolgreichen Speichern eines Arbeitsschrittes sogenannte Arbeitsschritt-Klassen ider aucuh Generaotr.oder auch Generation-Klassen erstellt. Diese können dann über den GenerationProvider gestartet werden. eine Eine Arbeitsschritt-Klasse ist mittels Generics typsicher aufgebaut und legt Quell- und Zielentitäten ( als BusinessObjekte ) fest. Ein beipsielhasfter Aufbau könnte wir folgt aussehen:

Codeblock
Codeblock
public class ErstelleRechnungAusAuftragGEN implements Generation<Auftrag, Rechnung> { 
	public Class<Auftrag> getSourceModule() {
 		return Auftrag.class;
	}
	public Class<Rechnung> getTargetModule() {
		return Rechnung.class;
	}
}
GEN

Report-Klassen

 ReportReport-Klassen stellen objektivierte Datenquellen aus "Report und Formular" dar. Werden in Nuclos Quellen für Report und Formular angelegt, wird eine entsprechende Report-Klasse erstellt. Diese kann dann in der Regelprogrammierung als Quelle verwendet und über den DatasourceService aufgerufen werden.

Allgemeine Konventionen:

  • Der Name der Report-Klasse entspricht dem java-tauglich überarbeiteten Namen des Reports. So sind weder Sonderzeichen noch Leerzeichen erlaubt.
  • Jede Report-Klasse besitzt weiterhin eine Package-Angabe. Wurde ein Arbeitsschritt keinem Nuclet zugewiesen, wird als Default das Package "org.nuclet.datasource" verwendenverwendet, ansonsten der Pfad des Nuclets, z.B: org.meineFirma.meinNuclet
  • Zur weiteren Information beinhaltet eine Report-Klassen Id, Namen und Beschreibung der Datasource. Da keine Eingangsinformation, bzw. zu verarbeiten Daten angegeben werden müssen, ist eine Report-Klasse schlicht gehalten.

Beispiel der Report-Klasse "ExportRechnungsdatenDS":

Codeblock
public class ExportRechnungsdatenDS implements Datasource {
public static final Long id = new Long(40016085); 
 
public static final String name = "Export: Rechnungsdaten"; 
 
public static final String description = "Export: Rechnungsdaten - für alle Kunden"; 
public Long getId() { return new Long(40016085);}  
 
}
DS

Klassengenerierung und Regelkompilierung

...

Allgemein

Für die oben beschriebenen Klassen gelten bestimmte Regeln und Reihenfolgen, in der sie erstellt und bereitgestellt werden. Die Klassen werden je nach Typ compiliert kompiliert und gruppiert in einer eigenen Jar im Code Generator angelegtCodeGenerator-Verzeichnis abgelegt. Von dort aus werden die Archive in den Classloader aufgenommen und können verwendet werden.

TypKlasseReihenfolge der Generierung
BusinessObjekteBOentitiesBOEntities.jar Die BusinessObjekte können als erstes erstellt werden, da sie lediglich auf die Meta-Informationen der Entitäten zurückgreifen müssen.
Report-KlassenReportDSEntities.jar Die Report-Klassen können unabhängig von anderen Klassen erstellt werden, da sie lediglich auf die Meta-Informationen der Statusmodelle zugreifen.
Arbeitsschritt-Klasse Generation.jarDie Arbeitsschritte verwenden als Quell- und Zielentitäten BusinessObjekte. Die Arbeitsschritt-Klassen können somit erst erstellt und kompiliert werden, wenn die BusinessObjekte in der  BOEntities.jar fehlerfrei gebaut wurden und verwendet werden können. 
Statusmodell-Klasse  
Regeln und BibliothekenNuclet.jar 

 

...

statemodels.jarDie Statusmodell-Klassen können unabhängig von anderen Klassen erstellt werden, da sie lediglich auf die Meta-Informationen der Statusmodelle zugreifen.
Regeln und BibliothekenNuclet.jarDie Regeln werden immer als letztes gebaut, das sie auf alle BusinessObjekte, Report-, Statusmodel- und Arbeitsschritt-Klassen zugreifen können. Die Generierung der genannten Klassen ist somit eine notwendige Vorbedingung zur Erstellung der Nuclet.jar. Sollte es im Vorfeld Fehler geben, wird die Nuclet.jar nicht gebaut.

Zeitpunkt der Generierung

Systemstart

Bei Systemstart werden alle der genannten Klassen neu gebaut und im Classloader bereitgestellt. Dazu werden alle vorhanden Klassen und Archive aus dem Codegenerator-Verzeichnis gelöscht. Sollte es an dieser Stelle zu einem Fehler kommen, bleiben die Verzeichnisse (teilweise) leer. Der Server startet weiterhin.

Import eines Nuclets

Mit dem Import eines Nuclets ändert sich in Nuclos alles. Es werden neue Strukturen eingespielt, neue Entitäten, Statusmodelle, etc. Logischerweise müssen alle bereits erstellen Klassen gelöscht und der neuen Umgebung entsprechend generiert werden. Auch hier kann es bei ungültigen Daten zu Fehlern und somit zu Fehlermeldung bei der Kompilierung von Klassen kommen.

Laufzeit

Auch zur Laufzeit können sich Strukturen von Entitäten, Statusmodell, etc. ändern, was eine Anpassung und Neuerstellung der Java-Klassen notwendig macht. Wird eine Entität verändert, muss das entsprechende BusinessObjekt neu erstellt werden. Das Nuclet.jar und das Generation.jar mit den Arbeitsschritten im Anschluss ebenfalls, da sie mit dem betroffenen BusinessObjekt evtl. arbeiten. Für die Sicherstellung der Datenstrukturen ist das notwendig.

Report-Klassen, Arbeitsschritt-Klassen und Statusmodell-Klassen fordern ebenfalls eine Neugenerierung des Nuclet-jars, sollte im entsprechenden Editor das Modell verändert worden sein (löschen, anlegen oder aktualisieren).

Beispiel: In Nuclos wird ein Statusmodell im Editor geladen und dadurch verändert, dass ein Status hinzugefügt wird: Status 40 "Auftrag in Bearbeitung". Mit dem Speichern des Modells wird nun eine neue Statusmodell-Klasse "AuftragSM" erstellt, die diesen Status beinhaltet. Daraufhin erstellen wir eine Regel, die über den StatusmodelProvider eine gegebene Instanz eines Auftrags auf den neuen Status 40 anheben soll. Also einen Statuswechsel vornimmt. Nun muss aus nicht näher bekannten Gründen der neue Status ein anderes Numeral erhalten hat. Der Wert wird von 40 auf 50 gesetzt. Mit dem Speichern wird wie zuvor eine neue Statusmodell-Klasse erzeugt, die mit dem Status 50 aktuell ist. Dennoch erscheint jetzt eine Fehlermeldung, die besagt, dass eine Regel nicht kompiliert werden kann! Was ist passiert? Die Statusmodell-Klasse wurde zwar erfolgreich verändert und neu kompiliert. Unsere Regel möchte aber immer noch einen Auftrag auf den Status 40 anheben und findet diesen Status nun nicht mehr. Damit ist die Regel nicht mehr kompilierbar und die Nuclet.jar nicht baubar. Als Folge müssen alle Referenzen auf den Status 40 aktualisiert werden. In unseren Fall eine Regel.

Strukturell müssen alle Informationen korrekt sein und dürfen gegen keine Java-Konvention verstoßen, da sonst die Klassen nicht erstellt werden können. Weitere Informationen finden Sie unter Probleme und Lösungen.