ERP-Software: Gedankengänge und Diskussionen

[Ap0ll0XT]

AW: ERP-Software: HTTP(S)-Request sinnvoll oder nicht?

Sooo ...

nach vielen Unterhaltungen mit Kollegen aus der IT Welt (ob so eine Software überhaupt Netzextern genutzt wird ... Ergebnis: Sehr selten!) und einem ausführlichen schweißtreibenden Brainstorming mit mir selbst (lol) werde ich jetzt einen anderen Ansatz verfolgen. Gegen eine Webimplementierung sprachen bisher so Dinge wie PHP (Performance), die zustandslosigkeit des Protokolls und .... ach ne das wars ja schon!

Mein nächster Ansatz war dann FastCGI. Allerdings wird dadurch die Zustandslosigkeit des Protokolls nicht ausgehebelt, sondern nur die Performance der Webanwendung durch den nativen Maschinen-Code erhöht. Ist ja erst einmal nicht schlecht. Aber immernoch nicht das, was ich will. Denn wenn der Server ausfällt oder etwas abstürzt, dann bekommt der Nutzer kein direktes Feedback. Von daher wäre eine Client-Server Architektur am besten. Nur wie bekommt man das hin, ohne bei Updates die Clients auf jeden Rechner zu updaten bzw. zu überschreiben (zentrale Wartung)?! Denn das spricht eigentlich gegen eine Umsetzung einer nativen Client-Software.

Als ich gerade das ein oder andere unfertige Projekt von meiner externen Platte durchstöberte, fiel mir da mein kleiner Webchat in die Hände. Ein Chat der für jeden mit einem Browser verwendet werden kann und keine Plugins wie Java, Silverlight oder Flash benötigt. Dort habe ich mit Websockets gearbeitet und es lief sehr gut. Ich hatte es nur eingestampft, weil mein Kumpel damals den Root-Server gekündigt hatte und deswegen kein Bedarf mehr da war. Fragt mich jetzt aber nicht, warum ich das so ausführlich erzähle. Ich tu es einfach

Nun mein Ansatz. Ich werden mit Hilfe von PHP die Auslieferung der Benutzeroberfläche sowie die Authentifizierung an das System vornehmen. War der Login erfolgreich und die Benutzeroberfläche ist geladen, wird eine Socket-Verbindung zu einer nativen Server-Software aufgebaut, der die Kommunikation und den Datenaustausch zwischen Client und Server übernimmt und eben auch für den Großteil der Logik verantwortlich ist, damit auch mit billigen Thin-Clients (z.B. der Pi 2 mit Raspbian oder ähnlich ) gearbeitet werden kann. Das PHP sowie dieser Server greifen beide auf eine PostgreSQL-Datenbank zu, um so das Backup der Daten zu erleichtern. Alternativ kann das ganze in einer Einplatz-Umgebung auch mit einer SQLite-Datenbank verwendet werden. Dazu wird ein kleiner Client-Browser gebastelt, der beim starten im Hintergrund das Hochfahren des Servers übernimmt und beim schließen diesen wieder abschaltet. Somit kann man dem Nutzer den Footprint ersparen, den man bei einer vollständig PHP-Basierten Lösung auf den Arbeitsrechner installieren müsste (HTTP-Server, PHP-Modul für den Server, ggf. noch die Datenbank etc.).

Macht also die Serversoftware schlapp, reißt die Socket-Verbindung ab und der Client kann sofort reagieren. Passiert das bei einem HTTP-Server, bekommt der Client das erst beim nächsten Request mit. Außerdem können Aktualisierungen über den verbundenen Socket direkt an den Client gesendet werden und nicht erst nach dem nächten Request oder per Ajax automatisch abfragen.

Ich habe da mal kurz den Namen des Threads angepasst

 

[Ahab]

AW: ERP-Software: Gedankengänge und Diskussionen

Welches Konzept du jetzt tatsächlich verwenden willst - nativer Client oder Web Client - lese ich nicht so ganz heraus. Aber ein Web Client hat den Vorteil, dass er einfach durch einen Aufruf der Webseite sofort auf einem aktuelleren Stand ist. Das ist nämlich der Grund, warum in Unternehmensstrukturen oft mit Webanwendungen gearbeitet wird - es erleichtert den Rollout von Updates enorm.

 

[Ap0ll0XT]

AW: ERP-Software: Gedankengänge und Diskussionen

Der Client ist komplett Webbasiert. Für die Einzelplatzlösung kommt im Grunde nur ein kleiner Selfmadebrowser zum Einsatz, der für die Einzelplatzlösung den Webserver obsolet macht. Ansonsten müsste der Kleine Unternehmer mit z.B. Schreinerbetrieb oder Werkstatt auch auf den Rechner einen Webserver + PHP und ggf. einer Datenbank installieren. Und das macht keinen Sinn, wenn der Server nur die GUI liefern muss und der Rest per Socketserver erledigt wird

 

[ofhouse]

AW: ERP-Software: Gedankengänge und Diskussionen

Also bei Webanwendungen würde man wahrscheinlich Heute eher auf REST-APIs im Backend als auf FastCGI etc. setzten.
Solche klassischen Client-Server-Lösungen kommen eigentlich nur noch bei synchronen Anwendungen wie Online-Games etc. zum tragen.

Web-Anwendungen sind ja Heutzutage meistens asynchron aufgebaut und verkraften es daher auch mal ganz locker, wenn die API mal nicht sofort antwortet.
Für deinen Fall würde ich empfehlen, serverseitig eine REST-API über JSON aufzubauen und im Frontend dann eine JS-Anwendung laufen zu lassen (z.B. über Angular.js, Ember.js oder Backbone.js).

Je nachdem wie viel Logik dein Frontend beinhaltet, kann es dann auch komplett unabhängig vom Server laufen und synchronisiert die Daten erst bei einem bestimmten Event.

 

[Ap0ll0XT]

AW: ERP-Software: Gedankengänge und Diskussionen

Also bei Webanwendungen würde man wahrscheinlich Heute eher auf REST-APIs im Backend als auf FastCGI etc. setzten.
Solche klassischen Client-Server-Lösungen kommen eigentlich nur noch bei synchronen Anwendungen wie Online-Games etc. zum tragen.

Web-Anwendungen sind ja Heutzutage meistens asynchron aufgebaut und verkraften es daher auch mal ganz locker, wenn die API mal nicht sofort antwortet.
Für deinen Fall würde ich empfehlen, serverseitig eine REST-API über JSON aufzubauen und im Frontend dann eine JS-Anwendung laufen zu lassen (z.B. über Angular.js, Ember.js oder Backbone.js).

Je nachdem wie viel Logik dein Frontend beinhaltet, kann es dann auch komplett unabhängig vom Server laufen und synchronisiert die Daten erst bei einem bestimmten Event.

Hm dann wäre ich aber auch wieder an die Zustandslosigkeit des HTTP-Protokolls gebunden. Und das wollte ich eigentlich vermeiden. Hinzu kommt dann auch, das mein serverseitiges Backend fast komplett nativ geschrieben werden soll. Das ganze bewegt sich dann dadurch wieder in Richtung PHP. Denn FastCGI bekomme ich nicht richtig mit meinen Sprachen/Compilern zum laufen und für andere Serverseitige Websprachen fehlt mir das Know-How. Und mich da jetzt wieder in etwas anderes einzuarbeiten, was selbst auch wieder ewig dauert, wollte ich eigentlich vermeiden.

 

[ofhouse]

AW: ERP-Software: Gedankengänge und Diskussionen

Hmm, das zustandsloses Protokoll brauchst du ja eigentlich nur, wenn du direkt auf dem Server arbeiten willst?
Das bringt aus meiner Sicht mehr Nach- als Vorteile.
Gerade bei einem Mehrbenutzer-System hast du dadurch dann ja auch Race-Conditions.

Bei solchen Anwendungen würde ich Daten nur Lokal bearbeiten und dann erst zum Server committen, statt die Bearbeitung direkt auf dem Server zu machen, ansonsten musst du ja auch eine Menge an undefinierten Zuständen abfangen.
Native Anwendungen sind zwar schön und gut, aber gerade bei relationalen Datenbanken macht das REST-Schema Sinn (weil Objekt-orientiert) , weil du damit eigentlich alle möglichen Datenbank-Anfragen gleich mit drin hast.

 

[Ap0ll0XT]

AW: ERP-Software: Gedankengänge und Diskussionen

Natoll. Ich musste eben feststellen, das ich den Handshake bei Websockets vollkommen übersehen habe. Dann muss ich ja trotzdem immer nen Webserver mitliefern. Verdammte Axt!

 

[Ahab]

AW: ERP-Software: Gedankengänge und Diskussionen

Ich werde irgendwie immer noch nicht daraus schlau, wie du dir das alles so vorstellst.

 

[Ap0ll0XT]

AW: ERP-Software: Gedankengänge und Diskussionen

Ich werde irgendwie immer noch nicht daraus schlau, wie du dir das alles so vorstellst.

Mehrplatz-Variante
Browser > URL aufrufen > einloggen > GUI geliefert bekommen > Per JS Socketverbindung zum Socketserver der ERP-Software aufbauen > Daten hin und her schieben

Einzelplatzvariante (Also ein PC > lokal auf den Rechner installiert)
Selfmade-Browser starten (Socketserver der ERP-Software startet mit) > Einloggen > GUI von der Platte laden > Per JS Socketverbindung zum Socketserver der ERP-Software aufbauen (Was wohl leider anscheinend über Javascript nur mit HTTP-Server geht) > Daten hin und her schieben

Das ganze besteht also aus 3 Komponente. Einmal der GUI, die in der Mehrplatz-Variante von einem HTTP-Server kommt und in der Einzelplatzvariante der Selfmadebrowser mitliefert. Dann gibt es die Geschäfftslogik bzw. die ERP-Software als Socketserver, mit der/dem die GUI kommuniziert, damit der Nutzer auch mit der Software interagieren kann. Und zuletzt eben noch die Datenbank, die entweder als Server für die Mehrplatzvariante oder eben als SQLite für die Einzelplatzvariante zur Verfügung steht. Durch den Selfmadebrowser wollte ich eigentlich umgehen, das ein HTTP-Server für die Einzelplatzvariante nötig ist. Aber anscheinend komme ich wohl doch nicht drumherum.

Die asynchrone Verbindung soll dabei bidirektionale Kommunikation ermöglichen, damit auf Seiten des Servers oder des Clients Events ausgelöst und kommuniziert werden kann.

Meine Ziele dabei sind folgende:
- Zentrale Verwaltung der Software in Mehrplatzumgebungen (Da die Software komplett auf einen Server liegt)
- Bidirektionale Kommunikation, damit der Server ebenfalls mit dem Client interagieren kann und nicht nur umgekehrt
- Eigentlich bei der Einzelplatzvariante den Workflow und die GUI der Mehrplatzvariante nutzen, ohne aber den Rechner mit Serverdiensten unnötig zu zumüllen
- PHP größtenteils vermeiden (native Anwendung bevorzugt - deswegen ja auch den Socketserver). Denn ich denke eine native Anwendung läuft schon performanter als PHP.

 

[ofhouse]

AW: ERP-Software: Gedankengänge und Diskussionen

Also wenn ich das richtig verstanden hab, willst du quasi Node.js zu Fuß machen?
Weil du ja ein Programm brauchst, was sowohl auf dem Mehrplatz-Server als auch auf dem Einzelplatz-Client läuft?

 

[Ahab]

AW: ERP-Software: Gedankengänge und Diskussionen

Stimmt, Node.js wäre eine Möglichkeit, im Prinzip bietet das, was Node bietet, aber fast jede verbreitete Sprache an - Grundkomponenten für einen Webserver.

Du solltes für dein Ziel zweigleisig fahren:

Die Mehrplatzvariante sollte/könnte als Servlet realisiert werden, mit Schnittstellen für WebSockets. Das Servlet wird dann auf einem Apache Tomcat Server gehostet, wie auch die Client-Anwendung (HTML/CSS/JS). Das ist sicherer, als sich einen eigenen Webserver zu programmieren.

Die Einzelplatzvariante hat gar keine Netzwerkfähigkeiten - die DB wird direkt über die Clientsoftware angesprochen, ohne Umwege über HTTP oder Socketverbindungen. Das geht sehr fix, einfach die DB-Treiber einbinden und schon kanns losgehen. Die GUI ist die gleiche: Java bietet zum Beispiel via JavaFX eine WebView auf WebKit-Basis - da kannst du deine HTML-Seite reinladen und wie eine GUI nutzen (das meinst du bestimmt auch mit "Selfmadebrowser", oder...?).

Diese Variante hat den Vorteil, dass beide Lösungen ihre individuellen Stärken voll ausspielen können. Der Nachteil ist aber, dass die Lösungen konzeptionell sehr verschieden sind. Gemeinsamkeiten ergeben sich erst im Rahmen der Entwicklung. GUI und ERP-Core sind zB. gleich, aber für die Schnittstellen nach außen und unterschiedlichen Architekturen musst du verschiedene Sourcen pflegen.

So würde ich es jedenfalls machen.

 

[Ap0ll0XT]

AW: ERP-Software: Gedankengänge und Diskussionen

Wenn ich Java schon lese wird mir übel



Aber vom Prinzip her kommt Node.js schon ein wenig ran. Nur so ganz check ich nicht, warum ich ein Servlet brauche. Websockets sind doch in Javascript schon drinne. Wazu dann der Umweg? <- Ahh jetzt habe ich es verstanden. Sorry ist heut noch zu früh



Ich bin sowieso bei den Sockets noch auf Probleme gestoßen. Zum einen brauch es einen Handshake über einen Webserver, weswegen ich nicht auf selbigen komplett verzichten kann (für die Einzelplatzlösung). Außerdem sind Sockets erst ab Internet Explorer 10 möglich. Das würde Probleme mit dem Selfmadebrowser machen so, wie ich ihn geplant hatte. Irgendwie habe ich mal wieder nicht zu Ende gedacht

 

[ofhouse]

AW: ERP-Software: Gedankengänge und Diskussionen

Ne, meinte bei Node.js gerade nicht die Webserver-Komponente, sondern die Möglichkeit zur modularisierten Lösung.
Im Ideal-Fall hat man ja mehrere Blöcke, die durch Anbindungen miteinander verbunden sind.

Am schlausten wäre es ja, die Logik (Datenmodell) in ein Modul zu packen und das dann an über eine Schnittstelle an einen Speicher zu koppeln (Datenbank oder Massenspeicher).
Und dann halt noch ein Modul für die Client-Anwendung, die dann über eine Schnittstelle auf das Datenmodell Zugriff hat (entweder Remote oder Lokal).

Bei Node.js hat man halt die Möglichkeit (soweit ich weiß, bin kein Node.js Experte^^), getrennte Module zu schreiben und das Logik-Modul läuft dann auf dem Server genau so wie im Client-Browser mit Node-Webkit (mittlerweile nw.js).
Node.js bräuchte dann für den Desktop z.B. keinen kompletten Webserver mit Datenbank & co.

 

[crys_]

AW: ERP-Software: Gedankengänge und Diskussionen

Die Einzelplatzvariante hat gar keine Netzwerkfähigkeiten - die DB wird direkt über die Clientsoftware angesprochen, ohne Umwege über HTTP oder Socketverbindungen

Wäre es nicht sinnvoller dann einfach einen Embedded-Server auf Localhost laufen zu lassen? Dann hätte man zwar die Netzwerkgeschichte aber man kann einfach auf einen Server umstellen indem man die IP von localhost auf die Server IP ändert.

Klar ist das erstmal mehr Aufwand als alles lokal zu machen, aber es zahlt sich später schnell aus. Server und Client kannst du beides super mit Java machen. Server z.B. jetty und Client wie gesagt Java FX

 

[Ap0ll0XT]

AW: ERP-Software: Gedankengänge und Diskussionen

Ich glaube ich präzisiere mal kurz ein wenig den Server-Teil, wie ich mir das gedacht habe.

- Das 1. Modul kommuniziert per Websocket mit der Client-Oberfläche und validiert die Gültigkeit der Informationen
- Das 2. Modul übernimmt dann die Zuweisung der Pakete (Informationen) an Hand der Headerangaben und schickt die Daten dann an die verarbeitende Logik
- Das 3. Modul beinhaltet kleine Logik-Module für die einzelnen Aufgaben
- Das 4. Modul übernimmt dann die Kommunikation mit der Datenbank, die entweder direkt mit PostgreSQL, per ODBC mit einer anderen Datenbank (z.B. MySQL oder MSSQL) oder mit SQLite arbeiten kann, wobei letzteres nur für eine Einzelplatzlösung in Frage kommt

Die Benutzeroberfläche war dann eben als WebUI gedacht (JQuery, JQueryUI oder Alternativen). Bei der Mehrplatzlösung stellt das auch keinerlei Probleme da. Aber bei der Einzelplatzlösung gibt es dann 2 Probleme.
1. Für den Handshake ist ein Webserver nötig, der auch den Protokol-Switch versteht
2. Websockets gibt es im Internet Explorer erst seit der Version 10
Denn der Selfmadebrowser würde dann unter Windows ein Web-Control aus dem IE seitens dem Framework bekommen. Unter Linux würde er ein Web-Control von Webkit (gtk-webkit) bekommen. Meine zweite Überlegung war dann, den Browser mit .NET zu machen und dann nicht aus Javascript mit Socket's, sondern mit der Methode ObjectForScripting das JS direkt mit dem Browser kommunizieren zu lassen, der wiederum die Socketverbindung von sich aus aufbaut. ObjectForScripting ist aber nicht mit dem Mono-Framework kompatibel und würde unter Linux nicht funktionieren. Alles Mist irgendwie!

 

[Ahab]

AW: ERP-Software: Gedankengänge und Diskussionen

Steht dem .net-Framework für WebViews denn nicht die aktuellste Browser-Engine des IE11 zur Verfügung? Auch wenn das dein Problem jetzt nicht direkt angeht...

Im App-SDK für Windows 8 und Windows Phone gibts ja auch WebViews, die basieren meines Wissens nach auch auf dem jeweils aktuellsten IE. Demnach sollte das Drumherum auch WebSockets, wie auch alle sonstigen HTML5-Features beherrschen.

 

[Ap0ll0XT]

AW: ERP-Software: Gedankengänge und Diskussionen

Steht dem .net-Framework für WebViews denn nicht die aktuellste Browser-Engine des IE11 zur Verfügung? Auch wenn das dein Problem jetzt nicht direkt angeht...

Dem WebView vom .NET steht immer die aktuell beim Nutzer installierte Version des Internet Explorers zur Verfügung. Hat der Nutzer bei Windows 7 zum Beispiel das aktuellste .NET, aber nur den IE 8 drauf, dann steht dem WebView auch nur IE 8 zur Verfügung. Ich müsste daher das Update auf IE 10 Softwareseitig vorraussetzen. Unter Windows wäre das aber auch egal, weil ich dort mit ObjectForScripting theoretisch auch kein Websocket brauche. Nur das funktioniert eben unter Linux mit dem Mono-Framework nicht, da dort das WebView über Chromium (zumindest erinnere ich mich dunkel an Chromium) realisiert wird. Dafür gehen dort Websockets, wofür ich aber auch wieder einen HTTP-Serverbenötigen würde.

Uhrsprünglich sollte der Selfmadebrowser in der selben Sprache wie der Server geschrieben werden: PureBasic Referenz-Handbuch
Dort wäre es unter Linux gtk-webkit (Sockets funktionieren) und unter Windows eben der Internet Explorer ([FONT=Verdana, sans-serif]Internet Explorer 4.0 aufwärts das ActiveX Objekt[/FONT]), was am Ende aber mit Sockets nicht funktionieren wird. Irgendwie doof alles

 

[nay]

AW: ERP-Software: Gedankengänge und Diskussionen

Ich würde mir zuerst einmal sehr sehr viele Gedanken um die Businesslogik (Buchhaltung, Logistik, Sales usw.) machen und die Frage des Frameworks so lange wie möglich hinauszögern.

Edit: Willst du einen Browser bauen oder ein ERP?

 

[Ap0ll0XT]

AW: ERP-Software: Gedankengänge und Diskussionen

Ich würde mir zuerst einmal sehr sehr viele Gedanken um die Businesslogik (Buchhaltung, Logistik, Sales usw.) machen und die Frage des Frameworks so lange wie möglich hinauszögern.

Edit: Willst du einen Browser bauen oder ein ERP?

Mir geht es momentan vordergründig um die technische Umsetzbarkeit mit den Fähigkeiten, die ich mir angeeignet habe. In allererster Linie ist es noch immer ein Hobbyprojekt und die technische Umsetzbarkeit mit meinen Mitteln so wie ich mir das vorstelle muss abgeklärt sein. Wenn das nicht der Fall ist habe ich am Ende das ERP in seiner Businesslogik fertig, bekomme es dann aber nicht zu den Bedingungen ans laufen, die ich gesetzt habe.

Und um auf deine Frage zurückzukommen: Es soll ein ERP werden. Das sollte eigentlich klar sein (zumindest den jenigen, die bevor sie etwas schreiben auch die Seiten vorher betrachten ). Der "Browser" soll im Grunde dafür sorgen, das die Einzelplatzvariante 1 zu 1 die gleiche Benutzeroberfläche bekommt wie die Mehrplatzlösung über einen normalen handelsüblichen Browser. Außerdem soll der Browser nach Möglichkeit einen Webserver obsolet machen, der den Handshake für die Socketverbindung übernehmen würde. Denn bei einer Einzelplatzlösung sollte der Nutzer nicht noch zusätzlich einen Webserver installieren müssen. Der soll das ganze installieren, einrichten und loslegen, ohne nach zusätzlicher Software greifen zu müssen.

Mir ist es vollkommen wurst, wer das ganze nachher (wenn es dann mal nutzbar sein sollte) auch wirklich nutzt. Entweder wird es genutzt oder nicht. Zwingen kann man keinen. Aber mein Ziel ist es, egal ob Einzelplatz- oder Mehrplatzversion, der Workflow mit der Software identisch ist und das vor allem die Einzelplatzvariante so angenehm wie möglich zu verwenden ist.

Wäre es nicht sinnvoller dann einfach einen Embedded-Server auf Localhost laufen zu lassen? Dann hätte man zwar die Netzwerkgeschichte aber man kann einfach auf einen Server umstellen indem man die IP von localhost auf die Server IP ändert.

Klar ist das erstmal mehr Aufwand als alles lokal zu machen, aber es zahlt sich später schnell aus. Server und Client kannst du beides super mit Java machen. Server z.B. jetty und Client wie gesagt Java FX

Das ERP ist im Grunde ein Modul für den Socketserver. Der wird in beiden Varianten genutzt. Ich versuche bei der Einzelplatzversion dem Nutzer nur den zusätzlichen HTTP-Server zu ersparen. Außerdem brauch man bei dieser Version auch nicht zwangsläufig einen Datenbankserver, da das ganze dann mit SQLite gemacht wird.

Von daher verfolgt das ganze ja schon diesen Ansatz. In der Mehrplatzversion wird auf dem Server ein HTTP-Server, ein Datenbankserver und das ERP (mit Socketserver) installiert und ist über den Browser im Netzwerk normal erreichbar. Aber wenn die Software nur auf einen Rechner verwendet wird, ist der HTTP-Server sowie der Datenbankserver nicht nötig.

@Topic:
Momentan scheint es darauf hinnauszulaufen, das ich die Oberfläche plattformübergreifend nicht über ein Webcontrol realisieren kann. Entweder habe ich Probleme auf Windows oder auf Linux. Ich habe mal geschaut, ob man plattformübergreifend eine Browser-Engine verwenden kann, die ebenfalls so etwas wie ObjectForScripting beinhaltet. Chromium scheint da ein geeigneter Kandidat zu sein. Blöderweise ist das Ding in C++ geschrieben und lässt sich so nur schwer bzw. kaum in eine PB-Anwendung einbauen. Es gibt zwar .NET und Mono-Lösungen. Aber da muss ich mich noch hinneinbohren.

 

[nay]

AW: ERP-Software: Gedankengänge und Diskussionen

Mir geht es momentan vordergründig um die technische Umsetzbarkeit mit den Fähigkeiten, die ich mir angeeignet habe.

Hat die Architektur des ERPs nicht eine höhere Priorität als der Übertragungsmechanismus? Bevor ich mir überlegen würde, welche Werkzeuge ich benutze, würde ich erst einmal klären was ich überhaupt bauen möchte.