Berechtigungen neuer Datensatz

[Ferdinand Hackl]

Danke für den Hinweis.

[Matthias Haake]

Hallo nuclosian,

Die Tabellen bekommen ein neues Präfix – je Nuclet(!). So schliessen wir zukünftig Namenskonflikte zwischen Nuclets auf der DB aus. Es könnten ja z.B. zwei Nuclets eine Entität „Bank“ mitbringen. Die Präfixe werden lokal beim Nucletimport vergeben, die aus einer solchen Entität resultierenden Tabellen könnten dann z.B. X3BU_BANK und A4TZ_ BANK heissen.

Ist es möglich, dass man (auf eigene Verantwortung) das Präfix eines Nuclets beeinflussen kann? Ich meine jetzt nicht den Import, sondern das Upgrade auf Nuclos 4. Da hätte ich gerne das Präfix „T_EO_“ für die bestehenden Sachen 😉 Auf Grund mehrerer angebundener System und jeder Menge SQL-Code (keine Datenbankobjekte) würde die Migration sehr, sehr viel einfacher…

Viele Grüße,
Matthias

[Markus Glitzner]

100% Zustimmung!

Auch ich habe unmengen an SQL Code, die T_EO beinhalten.
Abgesehen davon, müsste ich dann für jedes System alle SQL Statements neu schreiben, da sich ja jedes mal das Präfix ändert. Wäre für mich absolut unmöglich zu handeln.

Gruß
Hugo

[Ramin Goettlich]

Hallo,

da die Multinucletfähigkeit ein wesentlicher Bestandteil der zukünftigen Ausrichtung von Nuclos ist, ist sie nicht „verhandlungsfähig“. Verschiedene Nuclets ggf. sogar verschiedener Hersteller können gleiche Businessobjektnamen (d.h. gleiche Tabellennamen) mit sich bringen und damit muss Nuclos umgehen können.

Es sei angemerkt, dass Nuclos die Tabellennamen in Nuclos-Datenbankobjekten mitmigriert, soweit diese eindeutig identifiziert werden können.

Auf Grund mehrerer angebundener System

Wir würden grundsätzlich empfehlen, dass für Schnittstellen eine Abstraktionsebene eingebaut wird. Dritte Systeme sollten niemals auf die Tabellenstrukturen in Nuclos gehen – die könnten ja geändert werden 😉 – sondern nur auf eine abstrahierte Sicht darauf (explizite Views für das Drittsystem). Diese Views könnten ja z.B. T_EO_* heissen. Immer wenn ein System B direkt auf interne Objekte eines Systems A zugreift, setzt sich System B der Gefahr aus, dass Änderungen in A durchgeführt werden, die B nicht mitkriegt aber davon betroffen ist. Ein Entwickler des Systems A kann ja nicht sehen, dass ein System B auf seine Objekt zugreift, wenn nicht eine explizite Schnittstellenschicht im selben Schema existiert, die nach Änderungen plötzlich nicht mehr kompilierbar o.ä. ist.

und jeder Menge SQL-Code (keine Datenbankobjekte)

Auch ich habe unmengen an SQL Code, die T_EO beinhalten.

Warum überführen Sie diesen SQL-Code nicht in Datenbankobjekte? Dann werden die entsprechenden Stellen mitmigriert.

Notfalls ginge ja auch Suchen und Ersetzen im SQL-Code…

Externe Zugriffe auf Nuclos-Tabellen ohne Indirektion sollten vermieden werden, wir können ja auch nicht garantieren, dass z.B. eine T_MD_STATE immer existieren wird und nicht einmal durch etwas anderes ersetzt werden wird.

Grüsse,
nuclosian

[Matthias Haake]

Hallo.

da die Multinucletfähigkeit ein wesentlicher Bestandteil der zukünftigen Ausrichtung von Nuclos ist, ist sie nicht „verhandlungsfähig“. Verschiedene Nuclets ggf. sogar verschiedener Hersteller können gleiche Businessobjektnamen (d.h. gleiche Tabellennamen) mit sich bringen und damit muss Nuclos umgehen können.

Das verstehe ich – es ging mir auch gar nicht darum, dies zu verhandeln. Natürlich benötigt jedes Nuclet ein eindeutiges Präfix, das wurde auch nie in Frage gestellt. Aber es leuchtet mir technisch nicht ein, warum der Präfix ausschließlich willkürlich von Nuclos vergeben werden muss. Wir haben nur ein Nuclet – und da ist es technisch doch egal, ob das Präfix nun „T_EO“ oder „XYZ_“ ist, so lange es eindeutig ist. Beim Import von neuen Nuclets kann Nuclos da ja auch gerne die Hand drüber halten; aber bei der Migration eines bestehenden Systems mit nur einem Nuclet erzeugt das mehr Arbeit als sein müsste. Es geht mir nur um den „Bestandsschutz“ langjähriger Kunden.

Und natürlich haben wir den Zugriff versucht zu kapseln. Zwischen den externen Anwendungen (mit Schreibzugriff) und der Datenbank steckt das Microsoft Entity Framework. Um da alle Features nutzen zu können, braucht es nun einmal Tabellen und keine Views.

Über das Thema Datenbank-Objekte ist schon mal gesprochen worden. Es funktioniert(e) einfach nicht zuverlässig mit dem SQL-Server bzw. war beim Einstieg in die Nuclos-Welt noch gar nicht vorhanden / funktionsfähig. Angefangen damit, dass es das Statement „CREATE OR UPDATE“ auf dem SQL-Server nicht gibt, müsste man im Quelltext immer über die „sys.objects“-Tabelle abfragen, ob es das Objekt bereits gibt, um zu entscheiden ob das Statement nun CREATE oder UPDATE sein muss. Die fehlende Codevervollständigung und Syntax-Highlighting macht die Sache auch nicht sonderlich effizient im Alltag. Somit sind u.a. alle berechneten Attribute direkt in der DB angelegt.

Das die Migration Arbeit machen wird, ist sicher allen klar. Daher ist jede Aussicht auf Aufwandminimierung sehr willkommen, um die Downtime gering zu halten und den vorangehenden Vorbereitungsaufwand auf Kundenseite (Erstellung von Migrationsskripten für SQL-Funktionen anhand der auftretenden Probleme im Testsystem) nicht unnötig aufzublähen.

Viele Grüße,
Matthias

[Ramin Goettlich]

Aber es leuchtet mir technisch nicht ein, warum der Präfix ausschließlich willkürlich von Nuclos vergeben werden muss.

Es gibt dafür ein Hintertürchen: Einfach in der Beschreibung des Nuclets irgendwo folgendes eintragen:
migration_04_00_00.nuclet.preferred.local.identifier=T_EO

Über das Thema Datenbank-Objekte ist schon mal gesprochen worden. Es funktioniert(e) einfach nicht zuverlässig mit dem SQL-Server bzw. war beim Einstieg in die Nuclos-Welt noch gar nicht vorhanden / funktionsfähig. Angefangen damit, dass es das Statement „CREATE OR UPDATE“ auf dem SQL-Server nicht gibt, müsste man im Quelltext immer über die „sys.objects“-Tabelle abfragen, ob es das Objekt bereits gibt, um zu entscheiden ob das Statement nun CREATE oder UPDATE sein muss.

Es ist unbedingt zu empfehlen, die für Nuclos relevanten DB-Objekte Nuclos auch bekannt zu machen (d.h. als Datenbankobjekte in Nuclos anzulegen). Anderenfalls werden die Objekte z.B. auch nicht durch einen Nuclet Transfer transportiert. CREATE OR UPDATE braucht es eigentlich nicht, es genügt ein CREATE und die Angabe der entsprechenden DELETE-Anweisung (dafür gibt es ein eigenes Feld im Datenbankobjekt).

Die fehlende Codevervollständigung und Syntax-Highlighting macht die Sache auch nicht sonderlich effizient im Alltag. Somit sind u.a. alle berechneten Attribute direkt in der DB angelegt.

Das fertige DB-Objekt liesse sich ja trotzdem nach Nuclos rüberpasten.

[Matthias Haake]

Es gibt dafür ein Hintertürchen: Einfach in der Beschreibung des Nuclets irgendwo folgendes eintragen:
migration_04_00_00.nuclet.preferred.local.identifier=T_EO

Vielen, vielen Dank – das ist super!

Und die Sache mit den DB-Objekten schaue ich mir noch mal mit dem aktuellen Release an, um die Empfehlung möglichst zu berücksichtigen. Vielleicht kommt man ja doch mal in die Situation, wo man ein Nuclet braucht…

Vielen Dank auf jeden Fall für dies Unterstützung mit dem Tabellen-Präfix!

VG,
Matthias

[Ramin Goettlich]

> Vielleicht kommt man ja doch mal in die Situation, wo man ein Nuclet braucht…

Wie liefern Sie denn Änderungen an Ihre Kunden aus, wenn nicht per Nuclet Transfer? Oder wie überführen Sie Änderungen aus einem Testsystem aufs Produktivsystem?

[Matthias Haake]

Das Testsystem dient mir hauptsächlich nur für das Testen von Nuclos-Updates. Ich fahre den Nuclos-Dienst runter und mounte ein aktuelles DB-Backup eines der Live-Systeme als Testdatenbank. Dann wird der Nuclos-Dienst gestartet und eine Checkliste abgearbeitet. In der Liste werden zuerst alle Nuclos-Funktionalitäten getestet und anschließend die einzelnen Nuclet-Bestandteile durchprobiert.

Neue Module werden direkt im Livesystem entwickelt und erst nach Fertigstellung über die Berechtigung freigegeben.

Bei Änderungen an bestehenden Business-Rules kommt natürlich auch das Testsystem zum Einsatz. Funktioniert dort alles, dann kopiere ich einfach den Java-Code per Zwischenablage ins Live-System.

Dieses Vorgehen hat bislang immer reibungslos geklappt.

[Ramin Goettlich]

Neue Module werden direkt im Livesystem entwickelt und erst nach Fertigstellung über die Berechtigung freigegeben.

Klingt gefährlich 🙂

Bei Änderungen an bestehenden Business-Rules kommt natürlich auch das Testsystem zum Einsatz. Funktioniert dort alles, dann kopiere ich einfach den Java-Code per Zwischenablage ins Live-System.

Der Nuclet Transfer macht dies alles auf Knopfdruck (alle Inhalte der Konfiguration übertragen, ohne dabei die Nutzdaten zu verändern.

[Matthias Haake]

Also neue Entitäten sollten auch im Live-System fehlerlos angelegt werden können. Die Gefahr ist doch bei beiden Vorgehen identisch (Entitätenwizard VS Nucletimport). Und da keine Berechtigungen eingerichtet sind, wird ja niemand davon tangiert. Da ich ein Nuclos-Release immer gründlich teste, ist es noch nie vorgekommen, dass da etwas nicht geklappt hat. Das ist auch der Grund für 3.12. Aber die aktuelle Version ist ein echter Releasekandidat – bin aber mit der Checkliste noch nicht durch.

Mag sein, dass der Nuclet-Transfer gut funktioniert. Das Vorgehen hat sich vor Jahren hier so etabliert, als von Nuclets noch nichts zu hören war 🙂 Von daher: never change a running system. Ich werde es mal bei Gelegenheit auf Testsystemen ausprobieren.

[Ramin Goettlich]

Die Gefahr ist doch bei beiden Vorgehen identisch (Entitätenwizard VS Nucletimport).

Nun ja, der Unterschied ist: Sie „basteln“ auf dem produktiven System herum und setzen dieses damit unnötigen Gefahren aus. Die Downtime entspricht insofern eigentlich genau Ihrer Entwicklungszeit.

Wir würden empfehlen, Weiterentwicklungen eines Nuclets immer nur auf einem Test- oder Entwicklungssystem vorzunehmen und erst nach Abschluss und vollständigem Test der Weiterentwicklungen (d.h. der neueren Version des Nuclets) alle Änderungen per Knopfdruck mit dem Nuclet Transfer auf das Produktivsystem zu übertragen (von dem natürlich sicherheitshalber vorher ein Backup gezogen werden muss). Die Downtime reduziert sich auf wenige Minuten.

Auch birgt das manuelle Übertragen aller Änderungen an einem Nuclet nach einer Checkliste die Gefahr, dass etwas übersehen wird oder sich Fehler einschleichen.

[Frank Pavlic]

Ich kann Matthias Vorgehen gut verstehen und voll nachvollziehen. Es gibt einfach zu viele Releases , die einfach nicht stabil sind. Stabil heisst eben auch, dass Dinge, die vorher funtionierten,beim nächsten Release nicht mehr funktionieren. Und das kommt bis heute zu oft vor. LOV, Datumsfeld, und weitere rudimentäre und elementare nuclos-Funktionalitäten und Feldtypen werden wieder und wieder gefixt, geschreddert, gefixt, usw…
Aktuelles und stellvertredendes Beispiel:
http://support.nuclos.de/browse/NUCLOS-2526 .
Diese Erfahrung mussten so ziemlich alle machen und ein Releasewechsel bzw. Update ist einfach nicht zuverlässig genug, als dass man sich darauf verlassen kann. Da muss mehr Ruhe rein. Dann würden sich solche Vorgehen, wie Sie Matthias beschreibt, erübrigen.

Das neue Funktionen mal nicht gehen oder eben nur zu 90 %
funktionieren, ist nur fair und stellen auch nicht ein Problem dar, wenn man nicht gerade darauf sehnsüchtig gewartet hat.

Und das manchmal auch funktionierende Dinge kaputt „gefixt“ werden, passiert. Aber die Frequenz bei nuclos bzgl. solcher Kaputt-„Fixe“ ist einfach zu hoch.

Bitte nicht falsch verstehen, der Beitrag dient zur Anregung und stellt meine Position dar. Wie andere darüber denken, kann ich nicht beurteilen.

Gruß
Frank

[Markus Glitzner]

Das mit „den Releas-Bugs“ ist in der Tat nicht ganz unproblematisch. Bei vielen Updates gibt es etwas was plötzlich nicht mehr oder z.T. anders als vorher funktioniert. Kritisch wird es dann, wenn dadurch Daten gelöscht werden, was schon öfters bei LOVs mir Regel vorgekommen ist.

Allerdings muss ich auch sagen, dass die aktuelle Version 3.15.x sehr stabil und auch fehlerfrei läuft! Ein Grund dafür dürften sicher die vielen Tickets sein, die in letzter Zeit abgearbeitet wurden.

Was die Entwicklung angeht, ich mache auch die meisten Sachen am Echtsystem, weil es oft nur kleine Erweiterungen sind. Größe bzw. kritische Änderungen mach ich auch erst am Testsystem, genau so wie Mathias. Diese Vorgehensweise hat sich über die Jahre so ergeben und bis jetzt ganz gut funktioniert. Mittlerweile weis ich ja was ich machen kann und was ich besser bleiben lassen soll. In letzter Zeit fang ich aber auch an, nach und nach Nuclets einzusetzen, zumindest für Sachen, die auf allen Systemen gleich sein sollen.

[Ramin Goettlich]

Hallo,

Nuclos 4.0 befindet sich aus genau diesem Grund bereits seit Monaten im Test. Die Veröffentlichung ist übrigens für nächste oder übernächste Woche vorgesehen.

Grüsse,
nuclosian

[Autor]

Beiträge