Alte Regeln in Nuclos 4.0

Multinuclet Refactoring und GUIDs

Momentan arbeitet das Nuclos Entwicklungsteam hart an Nuclos 4.0. In Nuclos 4.0 wird sich an der Oberfläche nicht viel tun, wir bauen aber unter der Motorhaube massiv um. Sinn und Zweck dieser Umbauten ist es, Nuclos vollständig "Multi-Nuclet-fähig" zu machen.

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 Businessobjekte, 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 (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. Businessobjektsnamen oder Businessobjekt-IDs vorkommen, auf GUIDs umzustellen.

Sobald diese Umstellung abgeschlossen ist, haben wir noch grosse Testaufwände vor uns, bevor wir Nuclos 4.0 veröffentlichen können. Hier werden also noch einige Wochen ins Land streichen. Auch sind zum aktuellen Zeitpunkt noch nicht alle Fragen vollständig geklärt, z.B. ist der Umgang mit DB-Objekten in Nuclos noch unklar. Vielleicht läuft es darauf hinaus, dass beim Nuclet Import ein in der Nuclos Instanz lokal eindeutiges Kürzel an die DB-Objekte angefügt wird, so würde aus T_EO_AUFTRAG z.B. C3PO_T_EO_AUFTRAG oder T_C3PO_AUFTRAG. Das Vorgehen an dieser Stelle ist noch nicht endgültig festgelegt.

Alte Geschäftsregeln, die nicht die Nuclos API nutzen

Mit den Umbauarbeiten und der damit verbundenen Änderung der Signaturen praktisch aller Methoden geht es einher, dass sämtliche Geschäftsregeln, die nicht auf der neuen Nuclos API, die seit 3.11 Bestandteil von Nuclos ist, aufsetzen, nicht mehr funktionieren werden.

Wir haben lange mit der Frage gerungen, ob wir behelfsweise eine Ersatz-API bauen sollen, die die alten Signaturen auf die neuen mappt und damit die alten Regeln weiter unterstützt, uns aber dagegen entschieden, und zwar aus folgenden Gründen:

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 ein Businessobjekt mit dem Namen "Auftrag" gibt), wir würden durch Zulassen der Nutzung alter Regeln also unsere eigene Arbeit korrumpieren.

b) Der alte Regelmechanismus ist nicht abwärtskompatibel, da er keine API hat. Man kann auf jede Methode des Kerns von Nuclos zugreifen und ist nicht davor geschützt, dass Nuclos Entwickler diese Methode im Kern verändern. Der Nuclos Entwickler kann auch nicht wissen, dass jemand in irgendeiner Regel auf der Welt diese Methode nutzt, und sich entsprechend umsichtig verhalten. Dieser Umstand ist der Grund dafür, dass wir die neue Nuclos API überhaupt erst erschaffen haben. Mit einer fest definierten Nuclos API ist die Abwärtskompatibilität von Regeln und damit von Nuclets sichergestellt.

c) Der Bau einer Ersatz-API kostet Zeit, die langfristig aufgrund der Tatsache, dass letztendlich sowieso jede Regel wegen a) und b) irgendwann auf die Nuclos API portiert werden muss, aus unserer Sicht falsch investiert ist. Diese Zeit investieren wir lieber in den Ausbau der Nuclos API und in Verbesserungen von Nuclos. Desweiteren gibt es keine Möglichkeit, festzustellen, ob und wann die Ersatz-API vollständig ist. Dazu müssten wir alle Regeln, die jemals irgendjemand erstellt hat oder erstellen wird, kennen und testen können - denn in alten Regeln kann ja potentiell jede Methode in Nuclos genutzt werden.

d) Die Beibehaltung des alten Regelframeworks erhöht die Komplexität und Fehleranfälligkeit von Nuclos enorm. Derzeit existieren in Nuclos zwei vollkommen unabhängig voneinander operierende Regelframeworks (alt und Nuclos API), die beide gewartet werden wollen. Da wir das alte Regelframework längst nicht mehr nutzen, übersehen wir Seiteneffekte, die Änderungen in Nuclos auf das alte Regelframework haben, was immer wieder zu Fehlern in alten Regeln führt. Erst nach Portierung alter Regeln ist man auf der sicheren Seite und diesen Seiteneffekten nicht mehr ausgesetzt.

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.

Wir sind uns der Tatsache bewusst, dass eine Vielzahl von auf Nuclos basierenden Anwendungen alte Regeln nutzen und eine sofortige Portierung all dieser Regeln auf die Nuclos API nicht möglich ist.

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.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.15 einbauen.

Wir werden noch ein Verfahren definieren, über das wir versuchen, den Überblick zu behalten, wie verbreitet die Nutzung von 3.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.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 wir diesbezügliche Tickets auf http://support.nuclos.de priorisiert behandeln.