...

API-basierte Regeln stellen benutzerdefinierte Erweiterungen dar, mit deren Hilfe bestehende Nuclos Mechanismen um unternehmensspezifisches Verhalten erweitert werden können. Technisch gesehen sind Regeln Java-Klassen, die Methoden und Attribute zur Umsetzung individueller Geschäftslogik beinhalten und mit internen Nuclos-Ereignissen wie das Speichern oder Löschen eines Datenbankeintrages verknüpft werden können.

Die Regeln (API-basiert) lösen das bestehende Regelwerk ab. Letzteres bleibt funktionell erhalten, wird aber nicht weiterentwickelt.

BusinessObjekte

Ein Businessobjekt ist das, worum es in einem Unternehmen geht. Typische Businessobjekte sind z.B. der “Kunde” oder der “Auftrag” eines Kunden. Während der “Kunde” eher ein statisches Businessobjekt ist, ist der “Auftrag” dynamischer und hat einen Prozess. Möglicherweise einen, der Prozessschritte wie z.B. “Angebot”, “Bestätigt” oder “Abgeschlossen” umfasst.

Technisch gesehen handelt es sich bei einem BusinessObjekt um eine Java-Klasse, die anhand der Metadaten-Struktur einer Entität erstellt wird, und während der Laufzeit in Nuclos zur Verfügung steht. Üblicherweise wird diese in der Regelprogrammierung verwendet. Der Name des BusinessObjekts entspricht dem um Sonderzeichen bereinigten Entitätsnamen. Für die Entität "Währung (Alt)" gibt es z.B. ein BusinessObjekt mit dem Namen "WaehrungAlt".

Struktur

Da das BusinessObjekt fachlich der Entität entspricht, sind auch alle Feldattribute typisiert in der Klasse vorhanden und können mit dem get- Präfix aufgerufen werden. Die Konvention sagt, dass zuerst das "get", dann  - mit dem ersten Buchstaben groß - der restliche Attributsname folgt. Dieser ist wie der Klassennamen selbst Java-konform formiert. Bsp: getBestelldatum(). Der Rückgabewert entspricht dem angegeben Datentyp in Nuclos. Die Setter-Methoden sind analog aufgebaut.

Erzeugung

Da die BusinessObjekte den Entitäten entsprechen, ist die Generierung der Klassen an den EntityWizzard gebunden. Sollten sich Entitäten verändern oder neue Entitäten hinzugefügt werden, wird mit dem fehlerfreien Abschluss des Wizzards eine neue Generierung der Klassen angestoßen. Dies gilt auch für das Löschen bestehender Entitäten.

Sollten die Klassen zur Laufzeit einmal fehlen, hilft auch ein "änderungsfreier" Durchlauf des Wizzards.

Statusmodell-Klassen

Eine Statusmodell-Klasse ist eine Java-Klasse, die fachlich einem in Nuclos erstellen Statusmodell entspricht. Diese werden in der Regelprogrammierung verwendet, um eine einfache und sichere Gestaltung von beispielsweise Statuswechseln zu gewährleisten. Der Name der Statusmodell-Klasse entspricht dem um Sonderzeichen bereinigten Statusmodellnamen, plus der Endung "SM". Beispiel: Für das Statusmodell "Prozess Auftrag" gäbe es eine Klasse namens "ProzessAuftragSM". Hintergrund für die Endung "SM" ist, dass Statusmodell und Entität den gleichen Namen haben können. In diesem Fall wäre eine Programmierung fehleranfällig und unübersichtlich, weil die dazugehörigen Klassen (trotz unterschiedlicher Packages) gleich heißen würden.

Struktur

Da die Statusmodell-Klasse fachlich dem Statusmodell entspricht, befinden sich darin alle zum Statusmodell gehörenden Status. Diese sind als Konstanten beispielsweise beim manuellen Statuswechseln verwendbar. Die Namenskonvention sagt, dass jeder Status mit dem Präfix "State_", gefolgt vom Numeral des Status betitelt wird. Beipsiel: AuftragSM.State_20

Erzeugung

Da die Statusmodell-Klassen den Statusmodellen entsprechen, ist die Generierung der Klassen an den Statusmodell-Editor gebunden. Beim Anlegen/Ändern/Löschen eines Modells werden alle Klassen neu generiert.

Ereignisse

Jede Regel ist mit einem internen Nuclos-Ereignis wie das Speichern oder Löschen eines Datenbankeintrages verknüpft. Der Typ eines Nuclos-Ereignisses nennt man Event. In der Regelprogrammierung werden folgende Arten von Events unterschieden, wobei jede Regel mindestens einem Typ entsprechen muss.

...