Seitenhistorie

...

Heute ist Nuclos das nur bedingt. Nuclos erlaubt es zwar prinzipiell, beliebig viele Nuclets über den Nuclet Import zu importieren, sobald aber zwei Konfigurationselemente (z.B. zwei EntitätenBusinessobjekte, zwei Layouts, zwei Statusmodelle, etc.) den gleichen Namen tragen, führt das zu einem Konflikt und der Import kann nicht erfolgreich abgeschlossen werden.

Unser erster Gedanke zur Lösung dieses Konflikts war, Konfigurationselemente beim Import im Konfliktfall einfach umzubenennen, um eine Eindeutigkeit sicherzustellen. Von der Tatsache abgesehen, dass das Verwirrung stiftet und unklar ist, wie die Umbenennung aussehen soll (Entitätsname Businessobjektsname "Auftrag2" statt "Auftrag" ?), wirft das eine Reihe weiterer schwieriger Fragen auf und erhöht die Komplexität und damit die Fehleranfälligkeit des Nuclet Transfers deutlich, weswegen wir davon Abstand genommen haben.

Wir haben uns also vor einigen Wochen einer anderen Lösung zugewandt: Jedes Konfigurationselement in Nuclos erhält eine 30-stellige, zufällig generierte, weltweit eindeutige GUID (Global Unique Identifier), zusätzlich zum bisherigen Namen. Im Kern von Nuclos findet jegliche Kommunikation und Verarbeitung dann nur noch über diese GUID statt. Die derzeitigen Umbauarbeiten bestehen im Wesentlichen darin, die Signaturen von Methoden, in denen z.B. Entitätsnamen Businessobjektsnamen oder EntitätsBusinessobjekt-IDs vorkommen, auf GUIDs umzustellen.

...

a) Jedes Nuclet, dass eine alte Regel beinhaltet, kann nicht multinucletfähig sein (da ein Aufruf wie z.B. server.getMasterdata("Auftrag") nicht mehr funktionieren kann, sobald es mehr als eine Entität ein Businessobjekt mit dem Namen "Auftrag" gibt), wir würden durch Zulassen der Nutzung alter Regeln also unsere eigene Arbeit korrumpieren.

...

e) Die Eliminierung allen Codes in Nuclos, der das alte Regelframework betrifft, macht Nuclos wartbarer, weniger fehleranfällig und nicht zuletzt auch schneller. Heute müssen für beide Regelframeworks auszuführende Regeln ermittelt, der Kontext zusammengestellt und Regeln ausgeführt werden.

Longterm Support 3.

...

15

Alte Regeln werden in Nuclos 4.0 also nicht mehr unterstützt werden.

...

Daher haben wir uns zu folgendem Vorgehen entschieden: Unabhängig von der Tatsache, dass Nuclos 4.0 alte Regeln nicht mehr unterstützen wird und wir jedem empfehlen, neue Nuclets nur noch unter Einsatz der Nuclos API zu entwickeln, werden wir Nuclos 3.12 15 noch mindestens ein bis zwei Jahre weiter supporten und warten. Auch wichtige Features werden wir sowohl in die 4.0 als auch in die 3.12 15 einbauen.

Wir werden noch ein Verfahren definieren, über das wir versuchen, den Überblick zu behalten, wie verbreitet die Nutzung von 3.12 15 ist (z.B. durch die Möglichkeit der Selbstregistrierung) und erst, wenn die Nutzung verschwindend gering wird, über eine Beendigung des Longterm Supports für 3.12 15 nachdenken.

Bei Fragen zur Portierung alter Regeln dürfen Sie sich jederzeit gern im Forum an uns wenden, wir werden nach Kräften unterstützen. Vermissen Sie Funktionen, die alte Regeln nutzen konnten, die in der Nuclos API aber (noch) nicht existieren, werden wird wir diesbezügliche Tickets auf http://support.nuclos.de priorisiert behandeln.