mobile Client – Nuclos

[Jan Smiesko]

Hallo,

ich würde gerne zum Testzweck über das Framework „jQuiry mobile“ von einem
Smartphone auf Nuclos zugreifen wollen. Dabei geht es im ersten Schritt
darum, statische Masken (z.B. einfache Zeiterfassung) zu gestalten und
vorerst nur auf die Daten über Nuclos zuzugreifen bzw. Daten auch schreiben.

Meine Fragen betreffen nun die Server-Seite:

– Da Nuclos auf Spring aufbaut, kann ich über Ajax auf die diversen
Nuclos-APIs (Lesen eines Datensatzes oder Lesen gewisser Datensätze …)
z.B. über RESTful-Services oder andere URL-bedingte Auflösung zugreifen?
– Wie werden die Daten übermittelt: Json od. XML?
– Gibt es dafür nähere Dokumentation?
– Anfangen würde ich mit einer Login-Maske und dem notwendigen Austausch
für das Berechtigungssystem. (Authorisierung über Cookies?)

Vielleicht gibt es aber einen besseren Zugang, evtl. wie der geplante WebClient
gelöst wird.

FG
Jan

[Ramin Goettlich]

Hallo Jan,

mit diesem Framework hat bei uns leider niemand Erfahrung.

Der geplante Webclient wird auf Basis HTML5, mit dem GWT, realisiert.
Und wird generisch sein…, d.h. die u.a. Anforderung erschlagen können.

Grüsse,
nuclosian

[Jan Smiesko]

Hallo nuclosian,

GWT produziert letztendlich auch nur Javascript (+ HTML5 und CSS), der im Browser über AJAX (async) mit dem Server kommuniziert. Die Frage ist, wie werden Sie die Server-Seite implementieren, damit der Browser mit dem Nuclos-Framework (Nuclos-Klassen) kommunizieren kann.

GWT bietet die Möglichkeiten über GWT RPC und GWT HTTP Client Classes. RPC wird über Servlet-Mapping auf der Server-Seite aufgelöst, während die GWT HTTP Client Classes üblicher Weise mit einem MVC-Framework, wie beim Spring, z.B. über Json kommunizieren. GWT RPC verwendet meines Wissens ein eigenes Protokoll für De-/Serialisierung statt XML oder Json.

Der Browser ruft eine URL auf und an Hand der URL entscheidet der Server, welche Daten dieser zurücksendet.
z.B. ..//nuclos.server/rest/Kunden
..//nuclos.server/rpc/Rechnungen
…

Wenn Server-Seitig die APIs und das Protokoll feststehen, könnte mit beliebigen Javascript-FW der Nuclos-Server angesprochen werden.

FG
Jan

[Matthias Haake]

Hallo,

wir werden auch mittelfristig damit beginnen, eine Website für einige Module zu entwickeln (ausschließlich für Mobile Clients).

Umsetzung wahrscheinlich mit ASP MVC und jQuery Mobile. Die GUI soll sehr schlicht und übersichtlich werden, so dass nicht die Masken (XML) aus Nuclos interpretiert und nachgebaut werden müssen.

Im Moment stellt sich für uns die Frage: Bietet Nuclos bereits einen eingebauten Webservice, den man konsumieren kann? Wenn ja: woher kann man eine Liste der angebotenen Funktionen beziehen? Anderenfalls müssten wir einen eigenen Webservice schreiben, der direkt auf die DB zugreift. Letzteres wäre ja auch kein großer Akt, aber wenn es einen vorhandenen Webservice gäbe, würden wir vornehmlich diesen verwenden wollen.

Wen könnten wir denn kontaktieren, um an die benötigten Infos zu kommen?

Vielen Dank und Grüße,
Matthias

[Maik Stüker]

Hallo Matthias,

Nuclos selbst bietet noch keine Webservices an, aber man kann Nuclos um Webservices erweitern. Vor einiger Zeit habe ich schon mal ein Template angelegt. Die WSDL beschreibt nur eine Funktion um den Status eines Objektes auszugeben. Die Parameter sind hierbei der Entitätsname und die Id des Objektes. Mit Apache CXF wurden die Klassen generiert und im Anschluss die TemplateWSImpl mit Leben gefüllt.
Im Anhang findest du ein Archiv mit einem Eclipse Workspace, der WSDL und dem Ergebnis der „template-server-0.1.jar“.

Zum Testen einfach die Jar in den Extensions Ordner kopieren und den Installer erneut laufen lassen, oder einfach die Jar nach webapp/WEB-INF/lib/ kopieren (Achtung, wird beim nächsten Lauf des Installers wieder gelöscht!).
Im Browser sollte der Service nun unter http://localhost:8080/nuclos/ws aufgelistet sein.

Viele Grüße,
slash

Attachments:

• template.zip

[Matthias Haake]

Hallo slash,

vielen Dank für die informative Antwort. Ich habe mir das Beispiel gleich angesehen. Da wir den Webservice aber selbst (weiter)entwickeln müssen, werden wir das über einen „externen“ Webservice realisieren, der direkt auf die Datenbank zugreift.

Das hat für uns folgende Vorteile:

[1] Wir können mit .NET und SQL arbeiten – unser „Tagesgeschäft“ 🙂

[2] Wir sind unabhängig von API-Änderungen im Nuclos-Kern. Diese werden ja zwangsläufig auftreten, da Nuclos ja ständig weiter entwickelt wird.

[3] Das Webservice-Protokoll (z.B. REST und JSON-Format) können wir selbst bestimmen.

Auf jeden Fall vielen Dank für die Ausführungen, das hat die Entscheidungsfindung wesentlich vorangetrieben. Ich wollte den „Aufwand“ nur nicht betreiben, wenn ein fertiger Service (Authentication, Read, Write, Delete etc.) bereits existiert hätte.

Viele Grüße,
Matthias

[Jan Smiesko]

Hallo Matthias,

auch ich habe bereits den direkten Zugriff auf die Nuclos-DB über einen separaten WebAppServer (MVC-FW in Java, PHP, …) REST/Json überlegt.

Eine einfache Authentication und der Lesezugriff scheinen ohne gröbere Probleme realisierbar(?), wenn es aber um die Write, Update oder Delete-Zugriffe geht, stellt sich die Frage, worauf bei der DB-Struktur von Nuclos zu achten ist?

Wie ist es dann mit dem konkurrizierenden Zugriff von 2 parallel laufenden Servern?

Wie ist es mit evtl. Nuclos-Regeln?

Gibt es noch andere Punkte zu bedenken/überlegen?

FG
Jan

[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

[Jan Smiesko]

Hallo Matthias,

vielen Dank für die ausführliche Darstellung!
Da steckt doch Einiges an KnowHow und Handarbeit dahinter.

Wenn im Nuclos ein Wrapper auf URL-(Rest)-Basis für die vorhandenen EJBs wie „EntityService“, „AuthenticationService“ vorhanden wäre, würde es wohl die Implementierung vereinfachen?

Habe mir auch noch „dojo.mobile“ als FW angesehen und es ist auch ein interessantes WebMobile-Werkzeug. Bin gerade beim Testen/Ausprobieren.

FG
Jan

[Jan Smiesko]

Hallo Nuclos-Team,

ich habe versuchsweise einen http-Zugang od. web-Zugang als eigene webapp in die Nuclos-Instanz integriert, um auf die Nuclos-Services über HTTP zugreifen zu können. Dabei läuft der http-Zugang parallel zum RMI-Zugang (gleiche Tomcat-Instanz) über die URL

„///rest/*“
z.B.
„//localhost:8080/nuclos/rest/*“

Noch keine Authorisierungsüberlegungen angestellt.

Erste einfache Testversuche bei einer statischen Antwort und bei nur Lesezugriff in Anlehnung an das WS-Template von „slash“ (getState) „scheinen“ den Nuclos-Server nicht zu stören. Nuclos-Client ließ sich starten und Lese-Operationen mittels Nuclos-Client brachten bei diesem ersten Gehversuch keine offensichtlichen Fehler.
getState-Beispiel über URL:
„//localhost:8080/nuclos/rest/getState/?entity=Kunde&objectid=40001464“

Bei der Versuchs-Implementierung habe ich mich des Spring-Frameworks (mvc) bedient, weil ich mir dachte, dass dadurch kein zusätzlicher Overhead an libs entsteht, da die Spring-Libs Nuclos mitliefert. Ob generell eine Implementierung auf Servlet-Basis ohne Spring besser wäre (Performance?, weniger Abhängigkeit), habe ich nicht überlegt.

Meine Fragen betreffen nun speziell die Nuclos-Klassen/Nuclos-Services:

a) Spricht etwas gegen die grundsätzliche Überlegung, über WebController die nötigen Nuclos-Klassen zu importieren (oder DI über Beans, falls möglich) und als Wrapper nativ zu nutzen?

b) Gibt es eine Beschreibung der wichtigsten Services, was diese machen bzw. wie sie anzusprechen sind?
z.B.’/RemoteAuthenticationManager‘ ‚/ParameterService‘ ‚/MasterDataService‘
‚/ServerMetaService‘ ‚/SecurityService‘ ‚/MetaDataService‘ ‚/GenericObjectService‘
‚/SearchFilterService‘ ‚/EntityService‘ …

c) Ist der Zugang über die Services der richtige Weg, oder soll direkt über die Klassen wie beim Beispiel von „slash“ gearbeitet werden? Beispiele für übliche CRUD-Operationen wären hilfreich.

FG
Jan

[Jan Smiesko]

Hallo,

Habe – glaube ich – für die CRUD Operationen den Zugang über MasterDataVO gefunden:

ServiceLocator –> MasterDataFacadeLocal

Ist das aktuell die direkte, bevorzugte API? Ein Hinweis wäre hilfreich, dass ich nicht veraltete Schnittstellen wie „MasterDataMetaVO“, die anscheinend durch [System]EntityMetaDataVO ersetzt wird, anspreche.

FG
Jan

[Ramin Goettlich]

Hallo,

auf der sicheren Seite, sind Sie nur, wenn Sie Ihre Serverzugriffe auf das RuleInterface beschränken. Für alle internen Klassen können wir keine Abwärtskompatibilität garantieren, weil es unvermeidlich ist, dass wir mit Weiterentwicklung von Nuclos Dinge im Kern umstellen müssen. Insbesondere die noch lange nicht abgeschlossene Zusammenführung von GenericObjects und Masterdata, die sich zeitlich noch über einige Releases erstrecken wird, zieht immer wieder tiefgreifende Anpassungen nach sich.

Wir sind uns aber auch bewusst, dass man mit dem RuleInterface oft nicht sehr weit kommt, und arbeiten daher auch bereits an einer neuen API für externe Zugriffe auf Nuclos, die wesentlich einfacher und intuitiver zu nutzen sein wird (Negativbeispiel für mangelnde Intuitivität im RuleInterface ist heute ja z.B. alles im Umfeld der CollectableSearchConditions) und für die wir dann ebenfalls eine Abwärtskompatibilität garantieren, bzw. bei unvermeidlichen Änderungen Methoden ggf. gezielt auf deprecated setzen und frühzeitig über alternative Implementierungen informieren.

Praktisch bedeutet das: Um eine Nutzung von Klassen ausserhalb des RuleInterfaces kommen Sie aktuell (solange die neue API nicht existiert) vermutlich häufig nicht herum, und müssen damit rechnen, dass (je nach Komplexität Ihrer Webservices) mit zukünftigen Releases einige Stunden bis Tage Codeanpassungen erforderlich werden – bei denen wir Sie dann hier im Forum natürlich unterstützen.

Grüsse,
nuclosian

[Jan Smiesko]

Hallo,

danke für die Kurzdarstellung!

Wird zukünftig EntityObjectVO die beide Klassen (GenericObjectVO und MasterDataVO) ersetzen?

Wird bei Änderungen im Source-Code bei @Deprecated darauf hingewiesen, welche Klasse(n) nun zu verwenden sind bzw. wie werden API-Änderungen od. API-Neuerungen bekannt gegeben?

FG
Jan

[Jan Smiesko]

Hallo,

in der Zwischenzeit kann ich über das Nuclos-FW auf die Daten zugreifen und auch das Schreiben von Daten in Tabellen ohne (Statusmodell) ist im Testversuch gelungen. Wenn ich aber in Tabellen mit Statusmodell Daten anlegen möchte, erhalte ich folgende Fehlermeldung:

org.nuclos.common2.exception.CommonCreateException: masterdata.error.validation.value {R40003536} {nuclos.entityfield.eo.logicaldeleted.label}
org.nuclos.server.masterdata.ejb3.MasterDataFacadeBean.create(MasterDataFacadeBean.java:753)

Code-Auszug:

MasterDataMetaVO mdmVO = mdFacade.getMetaData("Leicht");
MasterDataVO mdVONew = new MasterDataVO(mdmVO, false);
mdVONew.setField("eins", "Kunde zwei eins");
mdVONew.setField("zwei", "Landstrasse 12");
mdVONew.setField("nuclosstate", 40003566);
mdFacade.create("Leicht", mdVONew, null);


Könnte mir jmd. ein Musterbeispiel für Statusmodell-Tabellen posten. Evtl. ist es gar nicht der richtige Zugriff und es gibt einen einfacheren Weg, um Daten anzulegen bzw. zu ändern, damit die div. Verknüpfungen GenericObject, History, Logbook, usw. automatisch erledigt werden.

FG
Jan

[Autor]

Beiträge