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

Wird mittels Entitäten-Wizzard eine neue Entität angelegt oder eine bestehende verändert oder gelöscht, werden mit dem erfolgreichen Abschluss des Speichervorgangs alle Änderungen in dem dazugehörenden BusinessObjekt vorgenommen und im Classloader abgelegt. 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" verwendet, 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. Beispiel: setBestelldatum(Date dat). Sonderzeichen, Leerzeichen oder auch Zahlen zu Beginn des Namens sind nicht erlaubt und werden bei der Generierung der Klassen automatisch entfernt/ersetzt, weshalb es zu Abweichungen zwischen den Namen der Methoden/Klassen und den Meta-Informationen aus dem Entitäten-Wizzard kommen kann. 
• Für die Abfrage der Dependents stehen ebenfalls Methoden zur Verfügung, die - wenn gewünscht - mit Flags erweitert werden können, 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. 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 QueryProvider verwendet werden können.

Beispiel eines BusinessObjekts "Adresse":

public class Adresse extends AbstractBusinessObject implements Modifiable {

	// Konstanten für den QueryProvider
	public static final Attribute<Boolean> Standard = 
		new Attribute<Boolean>("Standard", "org.nuclet.basis", "Adresse", new Long(40005905), "standard", new Long(40006275), Boolean.class );

	public static final StringAttribute<String> Postfach = 
  		new StringAttribute<String>("Postfach", "org.nuclet.basis", "Adresse", new Long(40005905), "postfach", new Long(40006271), 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); 
	}
}

Eine Statusmodell-Klasse ist eine Java-Klasse, die fachlich einem in Nuclos erstellen Statusmodell entspricht. 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 Statusmodell keinem Nuclet zugewiesen, wird als Default das Package "org.nuclet.statemodel" verwendet, 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":

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 StatemodelProvider verwendet werden.

In Nuclos können Arbeitsschritte erstellt werden. Um auch innerhalb von Regeln Arbeitsschritte manuell ausführen zu können, werden nach dem erfolgreichen Speichern eines Arbeitsschrittes sogenannte Arbeitsschritt-Klassen oder auch Generation-Klassen erstellt. Diese können über den GenerationProvider gestartet werden. Eine Arbeitsschritt-Klasse ist mittels Generics typsicher aufgebaut und legt Quell- und Zielentitäten als BusinessObjekte fest.

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" verwendet, 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":

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

ReportReportDatasource-Klasse

ReportReportDatasource-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 in der Regelprogrammierung als Quelle verwendet und über den DatasourceService aufgerufen werden.

Allgemeine Konventionen:

• Der Name der ReportReportDatasource-Klasse entspricht dem java-tauglich überarbeiteten Namen des Reports. So sind weder Sonderzeichen noch Leerzeichen erlaubt.
• Jede ReportReportDatasource-Klasse besitzt weiterhin eine Package-Angabe. Wurde ein Arbeitsschritt ein Source keinem Nuclet zugewiesen, wird als Default das Package "org.nuclet.datasource" verwendet, 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 ReportReportDatasource-Klasse schlicht gehalten.

Beispiel der ReportReportDatasource-Klasse "ExportRechnungsdatenDS":

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);}  
}

Wird in Nuclos ein Report angelegt, wird eine entsprechende Report-Klasse erstellt. Diese kann in der Regelprogrammierung verwendet und über den ReportService ausgeführt werden. Innerhalb der generierten Java-Klasse werden alle Ausgabeformate als Konstanten abgelegt, die der Benutzer in Nuclos für diesen Report hinterlegt hat. Soll aus einer Regel heraus ein Report ausgeführt werden, muss das Ausgabeformat mit angegeben 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 Report keinem Nuclet zugewiesen, wird als Default das Package "org.nuclet.report" verwendet, ansonsten der Pfad des Nuclets, z.B: org.meineFirma.meinNuclet
• Zur weiteren Information beinhaltet eine Report-Klassen die dazugehörige Id.

Beispiel der Report-Klasse "MeinAuftragReportRE":

public class MeinAuftragReportRE implements Report {
	public static final OutputFormat Auftrag = new OutputFormat(new Long(40314675L));

	public Long getId() {
    	return new Long(40314673L); 
	}
}

Wird in Nuclos ein Formular angelegt, wird eine entsprechende Formular-Klasse, bzw. Printout-Klasse erstellt. Diese kann in der Regelprogrammierung verwendet und über den PrintoutService ausgeführt werden. Innerhalb der generierten Java-Klasse werden alle Ausgabeformate als Konstanten abgelegt, die der Benutzer in Nuclos für dieses Formular hinterlegt hat. Soll aus einer Regel heraus ein Formular ausgeführt werden, muss das Ausgabeformat und die Id des Datensatzes, der zur Befüllung des Formulars verwendet werden soll, mit angegeben werden.

Allgemeine Konventionen:

• Der Name der Printout-Klasse entspricht dem java-tauglich überarbeiteten Namen des Formulars. So sind weder Sonderzeichen noch Leerzeichen erlaubt.
• Jede Printout-Klasse besitzt weiterhin eine Package-Angabe. Wurde ein Formular keinem Nuclet zugewiesen, wird als Default das Package "org.nuclet.printout" verwendet, ansonsten der Pfad des Nuclets, z.B: org.meineFirma.meinNuclet
• Zur weiteren Information beinhaltet eine Report-Klassen die dazugehörige Id.

Beispiel der Printout-Klasse "AngebotPO":

public class AngebotPO implements Printout {
	public static final OutputFormat Angebot_Druck = new OutputFormat(new Long(40019472L));
	public static final OutputFormat Angebot_Email = new OutputFormat(new Long(40298009L));

	public Long getId() {
    	return new Long(40019470L); 
	}