# ERP-Software: Gedankengänge und Diskussionen



## Ap0ll0XT (9. März 2015)

*ERP-Software: Gedankengänge und Diskussionen*

Halli Hallo,

ich schreibe momentan an einer ERP-Software und habe mir gerade die Frage gestellt, wie sich das ganze an bestehende Systeme wie z.B. E-Commerce-, CRM- oder direkte Datenbanklösungen anbinden lässt. Als Basis für eine Einzelplatzlösung nutze ich SQlite. Direkte Anbindung an Datenbanken wie MySQL, Postgres oder MSSQL ist auf jeden Fall geplant und wird auch in Zukunft umgesetzt. Die Grundlage für die richtige Kommunikation mit den Datenbanken werden Templates sein, die über einen Editor erstellt werden können. An Hand derer weiß die Software, wo sie welche Daten in den Datenbanken findet. Entweder werden die Templates als XML oder JSON gespeichert. Da bin ich mir noch nicht so ganz schlüssig.

Nun aber zu meiner eigentlichen Frage: Macht es Sinn oder wäre es zu empfehlen, die Software auch über HTTP(S)-Request's mit Anwendungen bzw. Datenbanken kommunizieren zu lassen? Ich stelle mir da zum Beispiel kleinere Webshops vor, dessen Betreiber nur einen klassischen Webspace nutzen und diese oftmals eine direkte Verbindung mit der Datenbank garnicht zulassen. Oder wäre das zu vernachlässigen?

Ich habe da schon ein wenig bedenken. Nicht nur wegen der Performance, sondern auch wegen der Sicherheit. Daher muss ich Pro und Kontra vergleichen und frage mal nach eurer Meinung.


----------



## DKK007 (9. März 2015)

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

Bei vertraulichen Daten sollte die Verbindung auf jeden Fall über TLS geschützt sein.


----------



## zLein (13. März 2015)

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

Warum baust du es selber? Es gibt doch genug Lösungen am Markt ... oder ist es ein Hobby-Projekt?


----------



## Ap0ll0XT (13. März 2015)

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

Hobbyprojekt

Wollte es zuerst als RIA serverbasiert in den Browser verfrachten. Aber das spare ich mir für später auf. Ich mache in dem Bereich alles als Hobby.


----------



## crys_ (14. März 2015)

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

Sobald vertrauliche oder persönliche Daten im Umlauf sind (explizit Passwörter etc.) immer HTTPS nutzen.


----------



## zLein (14. März 2015)

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



crys_ schrieb:


> Sobald vertrauliche oder persönliche Daten im Umlauf sind (explizit Passwörter etc.) immer HTTPS nutzen.


Vor allem bei Schnittstellen zum CRM.


----------



## Ap0ll0XT (14. März 2015)

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

Leute das ist mir klar, das die Verbindung gesichert sein muss. Es geht mir in erster Linie um das ob oder ob nicht HTTP/HTTPS. Es geht darum, ob eine solche Implementierung Sinn macht oder nicht


----------



## keinnick (14. März 2015)

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



Ap0ll0XT schrieb:


> Leute das ist mir klar, das die Verbindung gesichert sein muss. Es geht mir in erster Linie um das ob oder ob nicht HTTP/HTTPS. Es geht darum, ob eine solche Implementierung Sinn macht oder nicht



Widersprichst Du Dir da nicht gerade selbst?  Wenn Du Daten über das Web überträgst dann ist Verschlüsselung quasi Pflicht, Du sagst ja selbst, dass die Verbindung gesichert sein muss. 

Ich verstehe den Aufbau allerdings noch nicht so ganz:


Ap0ll0XT schrieb:


> Ich stelle mir da zum Beispiel kleinere Webshops vor, dessen Betreiber nur einen klassischen Webspace nutzen und diese oftmals eine direkte Verbindung mit der Datenbank garnicht zulassen. Oder wäre das zu vernachlässigen?



Wo läuft die ERP-Software in so einem Fall denn? Nicht auf dem Webspace des Kunden sondern irgendwo bei Dir? Das wäre noch interessant zu wissen. Wenn die Software auf dem Webspace des Kunden läuft, findet der Zugriff auf die Datenbank ja über localhost statt und geht gar nicht durchs Netz.


----------



## Ap0ll0XT (14. März 2015)

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

Das ERP soll eine Desktop-Anwendung werden. Ich hätte vielleicht das HTTP weglassen und nur HTTPS schreiben sollen. Mein Fehler. 

Die Software soll lokal und nicht auf dem Server laufen.


----------



## zLein (14. März 2015)

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

Ich würde mich auch für die Architektur deiner Anwendung interessieren. Wenn man ein Schichtenmodell hat, kann man auch gezielter Empfehlungen aussprechen...


----------



## Ap0ll0XT (15. März 2015)

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

Ich schau mal, das ich heute das Handy mal an den PC klemme und das analoge Konzept mal hochlade (Richtig gelesen. Analog! Auf Papier  ). Ohne Breitband ist das gerade etwas doof.


----------



## zLein (15. März 2015)

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



Ap0ll0XT schrieb:


> Ich schau mal, das ich heute das Handy mal an den PC klemme und das analoge Konzept mal hochlade (Richtig gelesen. Analog! Auf Papier  ). Ohne Breitband ist das gerade etwas doof.


Gegen Papier spricht rein gar nichts. Meine Grobkonzepte mach ich auch in meinem Büchlein und meist im Park  Vor allem wenn ich Datenbankkonzepte erstelle, streich ich gern durch um später Gedankengänge nochmal durchzuspielen


----------



## nay (15. März 2015)

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

Hi,
ich bin auch interessiert an deinem Projekt. Ich programmiere beruflich Anpassungen und Erweiterungen für das ERP-System Microsoft Dynamics NAV. Eventuell kann ich dir bei ein paar Problemen helfen.


----------



## Ap0ll0XT (16. März 2015)

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

Sorry das ich gestern nicht mehr geschrieben habe. Musste mich um den Aufbau unserer neuen Küche kümmern. Da war irgendwie dann keine Zeit mehr.

Ich arbeite meist mit 2 Hauptzeichnungen und dann den Flowcharts (wenn ich dann soweit komme). Die erste Zeichnung stellt den grundsätzlichen Aufbau und die 2. Zeichnung die Programmmodule dar. Ich kann auf Arbeit nachher mal beides hochladen.


----------



## Ahab (16. März 2015)

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

Die Frage wäre, welche Alternativen zu HTTPS für dich in Frage kämen.


----------



## Ap0ll0XT (16. März 2015)

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

Ignorieren und die Datenbanken ausschließlich direkt ansprechen.


----------



## Ahab (16. März 2015)

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

Das würde ich in jedem Fall ausschließlich innerhalb des Netzwerks machen. Ist aber nicht gerade best practice, diese Art der Architektur skaliert auch nicht gerade schön mit größeren Zahlen von Usern. Es müsste immer ein kompiliertes Programm auf den PCs ausgerollt werden, jedes Mal wenn ein Update eingespielt werden muss. 

Besser fährt man mit einer Server-Client-Architektur. Der Server kommuniziert mit der DB und der Anwender kommuniziert ausschließlich mit der Server-Anwendung (zB. über ein Web API). In Kombination mit HTTPS ist dieses Verfahren auch sehr sicher und wird auch allgemein sehr oft in der Form angewendet. Der Nachteil wäre, dass du zwei Anwendungen schreiben musst - Client und Server. 

Andererseits ist es ja nur ein Hobby-Projekt.


----------



## Ap0ll0XT (16. März 2015)

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



Ahab schrieb:


> Das würde ich in jedem Fall ausschließlich innerhalb des Netzwerks machen. Ist aber nicht gerade best practice, diese Art der Architektur skaliert auch nicht gerade schön mit größeren Zahlen von Usern. Es müsste immer ein kompiliertes Programm auf den PCs ausgerollt werden, jedes Mal wenn ein Update eingespielt werden muss.
> 
> Besser fährt man mit einer Server-Client-Architektur. Der Server kommuniziert mit der DB und der Anwender kommuniziert ausschließlich mit der Server-Anwendung (zB. über ein Web API). In Kombination mit HTTPS ist dieses Verfahren auch sehr sicher und wird auch allgemein sehr oft in der Form angewendet. Der Nachteil wäre, dass du zwei Anwendungen schreiben musst - Client und Server.
> 
> Andererseits ist es ja nur ein Hobby-Projekt.


Die direkte Datanbankanbindung wäre sowieso nur Netzintern vorgesehen gewesen ggf. via VPN an eine Datenbank auf einem dedicated Server. Wenn Client-ServerAnwendung, dann könnte ich ja im Grunde gleich einen Webserver nehmen und das ganze in den Browser verfrachten. Dann muss ich auch auf den Client's keine kompilierten Anwendungen ausliefern (wenn es überhaupt irgendwann einmal in einer solchen Umgebung Einsatz findet  ). Aber wenn ich das richtig verstehe, sind für solche Anwendungen HTTPS Request gängige Praxis. Oder habe ich das jetzt falsch interpretiert?

Die Wahl der Programmiersprache (bzw. dem Framework) hängt davon ab, ob ich Requests einbaue oder nicht. Denn in PureBasic gibt es keinen ordentlichen HTTP(S)-Request. Ich habe mal versucht, eine Bibliothek dafür zu schreiben und eine schon existierende OpenSource-Bibliothek (CDECL) einzubinden. Beides hat Wochen gedauert und ich bin kläglich gescheitert  Ich würde ansonsten VB.NET nehmen.

Bevor ich jetzt ein Konzept hochlade, setze ich mich dann doch nochmal ans Zeichenbrett  . Mir kam da eben eine interessante Idee. Ich könnte es ja tatsächlich im Browser und auf einem Server machen. Die Benutzeroberfläche aus dem Browser könnte  ich auch in eine Einzelplatzlösung integrieren: ObjectForScripting
Eigentlich garnicht mal so doof


----------



## Ahab (16. März 2015)

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

Wann immer sensible Daten ins Spiel kommen, wird HTTPS eingesetzt. Wenn nicht, dann auch normales HTTP. Die Datenbank bleibt dabei trotzdem gewissermaßen geschützt, da weiterhin NUR über den Webservice mit der DB kommuniziert werden kann und keine direkten Zugriffe auf die DB von Client-Seite aus möglich sind.


----------



## Ap0ll0XT (16. März 2015)

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



Ahab schrieb:


> Wann immer sensible Daten ins Spiel kommen, wird HTTPS eingesetzt. Wenn nicht, dann auch normales HTTP. Die Datenbank bleibt dabei trotzdem gewissermaßen geschützt, da weiterhin NUR über den Webservice mit der DB kommuniziert werden kann und keine direkten Zugriffe auf die DB von Client-Seite aus möglich sind.


Ich dachte immer, das dort gesicherte Direktverbindungen eingesetzt werden. Naja wieder was gelernt  Danke

*EDIT: *Ich meinte damit natürlich die Direktverbindungen zu den Datenbanken. Das die Verbindungen nach möglichkeit immer gesichert sind, ist ja klar


----------



## Ap0ll0XT (25. März 2015)

*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 (25. März 2015)

*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 (25. März 2015)

*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 (25. März 2015)

*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 (25. März 2015)

*AW: ERP-Software: Gedankengänge und Diskussionen*



ofhouse schrieb:


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


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 (25. März 2015)

*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 (25. März 2015)

*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 (25. März 2015)

*AW: ERP-Software: Gedankengänge und Diskussionen*

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


----------



## Ap0ll0XT (25. März 2015)

*AW: ERP-Software: Gedankengänge und Diskussionen*



Ahab schrieb:


> 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 (26. März 2015)

*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 (26. März 2015)

*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 (26. März 2015)

*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 (26. März 2015)

*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_ (26. März 2015)

*AW: ERP-Software: Gedankengänge und Diskussionen*



Ahab schrieb:


> 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 (26. März 2015)

*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 (26. März 2015)

*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 (26. März 2015)

*AW: ERP-Software: Gedankengänge und Diskussionen*



Ahab schrieb:


> 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 (26. März 2015)

*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 (27. März 2015)

*AW: ERP-Software: Gedankengänge und Diskussionen*



nay schrieb:


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



crys_ schrieb:


> 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 (27. März 2015)

*AW: ERP-Software: Gedankengänge und Diskussionen*



Ap0ll0XT schrieb:


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


----------



## Rho (27. März 2015)

*AW: ERP-Software: Gedankengänge und Diskussionen*

Deinen Plan, einen angepassten Browser für die Einzelplatzvariante zu entwickeln halte ich für nicht unbedingt sinnvoll. Dann würde ich schon eher den Weg gehen, einen einfachen, kleinen, angepassten HTTP-Server mitzuliefern und den Standardbrowser des Anwenders zu verwenden. Die Idee ist ja nicht neu. Gibt bereits einige Anwendungen, die diesen Weg gehen.


----------

