Aw: mobile Client – Nuclos

[Matthias Haake]

Hallo Jan,

da ich bereits zwei Webportale (ASP.NET / LINQ to Entities) programmiert und an Nuclos angebunden habe, konnte bereits ein paar Erfahrungen sammeln. Hier ein paar Details zu den von Dir angesprochenen Punkten:

Für die Authentication habe ich einen Membership-Provider programmiert, der im Schritt 1 über die T_MD_USER den Benutzernamen prüft und – falls ein Benutzer gefunden wurde – dann eine Authentifizierung gegenüber der ActiveDirectory (LDAP) vornimmt. Da die Anmeldung von extern erreichbar ist, sollte man noch den Zähler „BadPwdCount“ abfragen und ggf. die Prüfung unterlassen… sonst könnte man per Script alle Accounts sperren, in dem man einfach viele Anmeldeversuche unternimmt. Da der Zähler nicht in der Domäne repliziert wird, sollte für die Authentifizierung und die Abfrage des Zählers derselbe Domaincontroller verwendet werden.

Der DB-Zugriff erfolgt per LINQ mit einem separatem Account. Dafür habe ich eine neue Datenbankrolle auf dem SQL Server angelegt und nur auf die unbedingt notwendigen Attribute der entsprechenden Tabellen und Views Lesezugriff erlaubt.

Zum Speichern verwende ich ausschließlich Stored Procedures, d.h. ein Update oder Delete direkt auf den Tabellen funktioniert im Fall der Fälle über den DB-zugriff gar nicht. Die SPs sind so gehalten, dass sie selbst entscheiden, ob ein Update oder ein Insert gemacht werden muss. Für jede Entität gibt es eine eigene SP zum Speichern.

Bei Neuanlage von Objekten (Entitäten mit Statusmodell) ist zu beachten, dass die ID des Statuswerts aus T_MD_STATE ermittelt werden muss. Des Weiteren müssen eine neue System-ID und diverse INTIDs erzeugt werden, dazu bringt Nuclos bereits fertige SPs mit, die man verwendet kann (GETNEXTSEQUENTIALNUMBER und IDFACTORY).

Dann wird der Datensatz in die Entitätstabelle eingefügt (mit den 3 IDs INTID, STRNUCLOSSYSTEMID und INTID_NUCLOSSTATE). Eventuell noch INTID_NUCLOSPROCESS wenn verwendet.

Mit einem zweiten Insert wird das neue Objekt in T_UD_GENERICOBJECT „registriert“ und mit dem entsprechenden Modul (der INTID der Entität aus T_MD_ENTITY) verlinkt.

Mit einem dritten Insert wird der aktuelle Status des Objektes in die T_UD_GO_STATEHISTORY eingetragen. Dadurch funktioniert die Funktion „Statushistorie anzeigen“ in Nuclos ordnungsgemäß.

Abschließend werden alle nötigen Inserts in die T_UD_LOGBOOK gemacht. Damit geht dann auch das Logbuch in Nuclos.

Bei einem Update braucht man nur die Werte selbst aktualisieren und die neuen Werte ebenfalls in das Logbuch eintragen (vorher die alten Werte auslesen, da die im Logbuch auch aufgezeichnet werden).

Beim Löschen von Datensätzen lösche ich die entsprechenden Einträge in dieser Reihenfolge: T_UD_GO_STATEHISTORY, T_UD_LOGBOOK, T_UD_GENERICOBJECT und abschließend aus der eigentlichen Entitätstabelle.

Klingt vielleicht etwas umständlich ist aber in der Realität nicht wirklich komplex. Den Part mit dem Logbuch kann man gut in eine eigene SP auslagern, so kann man den gut wieder verwenden.

Das die ganzen Operationen in einer Transaktion ablaufen sollten, versteht sich sicher von selbst, dann hat man auch keine Probleme mit konkurrierenden Zugriffen (ggf. das Isolations Level der DB anpassen).

Die BusinessRules aus Nuclos lassen sich damit nicht integrieren, diese Logik muss dann im Service oder der SP verankert werden.

Viele Grüße,
Matthias