OrgaMon-next

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen

OrgaMon-Sprach-Basis

  • OrgaMon setzt wo immer möglich die Programmiersprache Object-Pascal ein.
  • Als Compiler werden Free Pascal (Open Source), Delphi (Kommerziell)
  • Für Remote-Codeausführung wird Pascal Script (RemObjects) verwendet (Open Source)
  • der eCommerce Kernel soll schritt für Schritt Kopplungspunkte bekommen wobei Kunden dann Anpassungen machen können. Das Customizing sollte aber auch wieder Open Source sein und auch Test Cases beinhalten dass es Release Fest bleibt. Eine IDE wäre schön ist aber nicht in Sicht.

OrgaMon-Map

  • OpenStreetview
    • Im ersten Schritt soll der /tile/ Dienst vom Web genutzt werden
    • Später soll mit mapnik ein eigener Renderer auf Linux Basis eingesetzt werden
  • Google-Mpas
    • Im ersten Schritt soll ein Google-Map Api eingesetzt werden um gerenderte Karten zu laden
    • Nachdem OpenStreetview stark genug ist soll dies wieder sterben
  • Geolokalisierung
    • Soll weiterhin mit dem xServer betrieben werden

Quellen

[1] http://delphimaps.googlecode.com/svn/trunk/
[2]
[3] mapnik
[4] http://weait.com/content/build-your-own-openstreetmap-server
[] http://DelphiFeeds.com
[] http://www.delphifeeds.com/go/f/70742?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+delphifeeds+%28DelphiFeeds.com%29

OrgaMon-Appliance

Begriffsdefinition

  • OrgaMon-Appliance ist Gesamtheit der WAN-Mandant Infrastruktur
  • Mandant ist die Datensumme aus Datenbank-Inhalt und Dateisysteminhalt
    • lokaler Mandant OrgaMon + lokales Dateisystem + embedded firebird (Einzelplatz)
    • LAN Mandant OrgaMon + Verzeichnis im NAS + firebird Server
    • WAN Mandant OrgaMon + Sync auf das NAS + OrgaMon-Ghost
  • Client ist ein vollständiger (mit GUI) laufender OrgaMon.exe
  • Ghost ist ein cOrgaMon.exe ohne GUI
  • Schrittzähler Jede echte Veränderung am Mandant hat ein inkrementieren des Schrittzählers zur Folge. Veränderte Objekte erhalten als Stempel diesen Schrittzählerwert eingestempelt. Reines Lesen oder Schreiben ohne Änderung erhöhen den Schrittzähler nicht.

Vorteile

die OrgaMon-Appliance ermöglich das Arbeiten mit einem WAN - Mandanten. Dabei wird lokal die OrgaMon-Anwendung verwendet. Über das Internet wird Kontakt zu einer OrgaMon-Appliance hergestellt. Die Datenbank und das Dateisystem liegt dabei in der Appliance. Die Dienste eMail, Tagwache, Tagesabschluss, FTP-Bereich, liegen dabei auf dem Appliance-Host. Die Datenbank-Operationen werden 100% auf einem Server durchgeführt, die Dateioperationen müssen teilweise per "save" and "send" (Lokales speichern auf dem Server UND senden an den Client) oder "save" und "replicate" (lokales speichern und replizieren wenn es die Bandbreite zu lässt).

Kopplung "Applikationsservers" und "Client"

der Client ist immer grundsätzlich funktional vollständig, das bedeutet er "könnte" auch alle Funktionen lokal mit einer eigenen Datenbank und auf dem eigenen Dateisystem ausführen. Intern im OrgaMon sind je nach Mandant (lokal oder Remote) die Ausführungswege jedoch anders gesteuert. Bei einem WAN-Mandanten deligiert der Client die Aufgaben an den Server. Dazu erzeugt der Client eine Anforderung als kleines Pascal-Script und sendet es zur Ausführung dem Server. Im Rahmen der Ausführung kann nun auch der Server seinerseits Rückfragen (inquire) oder Feedback senden. Dies erfolgt analog ebenso in Form eines Pascal-Scripts.

OrgaMon Gate

soll eingehende Anfragen beantworten. Dabei muss das Gate als Router funktionieren um die Requests auf den passenden OrgaMon-Ghost weiterzugeben.


Mögliche Implementierung

Dienst-Übersicht
  • firebird
  • samba
  • memcached
  • Apache2
  • OrgaMon Instanz "Tagesabschluss"
  • OrgaMon Instanz "Tagwache"
  • OrgaMon Instanz "Kasse" (Buchen + Drucken)
  • OrgaMon Instanz "eMail"
  • JonDaServer
  • OrgaMonApp-Service
  • Instanz OrgaMonAppService "PDF Erstellung aus html"
  • 4x cOrgaMon XMLRPC fürs Web
  • hbci-Server
  • osm-Server

OrgaMon Ghosts

(1:1 instanzierung des Applikationsserver)

Mit einem OrgaMon-Client kann man auch eine extra gestartete Ghost Instanz (1:1 Beziehung) des OrgaMon über eine TCP/IP Verbindung konnektieren. Ein Dispatcher hilft dabei bei der Konnektierung zwischen Client und Ghost, ev. auch mal bei einem Re-Connect.

Buisiness-Logik Funktionen werden auf dem Migrationsweg zunehmend über "Interfaceable" Datenmodule abgewickelt. Im OrgaMon müssen nun Datenmodule entweder ...

  • lokal konnektieren, dann läuft die Funktion über die lokale CPU ab, sie operiert dabei mit der angegebenen Datenbank und dem angegebenen Dateisystem.
  • remote konnektieren, die Funktionsaufrufe werden sequenzialisiert und zum remote übertragen. Dieser führt den Code unter veränderung der dortigen Datenbank und des dortigen Dateisystems aus. Der Rückgabewert wird wiederum über TCP versendet.

File Sync

Es ist möglich dass im Rahmen der Codeausführung auf dem Server Dateien im lokalen Dateisystem des Servers auf den Client synchronisiert werden müssen. Der Server Code muss diese Dateinamen einem SynDienst melden: Dieser wird sofort eine Synchronisation durchführen. Entsprechende Anfragen muss die entsprechende Routine dem Interface mitteilen, da VOR Zurückkehren der Routine auch das Dateisystem sychronisiert sein muss! (Es sei denn auf dem Client gibt es eine ensure(FName) Funktion die Signalisiert, dass diese datei JETZT wieder gebraucht wird, ensure würde in diesem Fall warten bis die Datei da ist!) Ansonsten kann diese Aktion asynchron ablaufen. Entstehen nun auf dem Remote neue Dateien, so wir als Funktionsergebnis das initiieren eines FTP Downloades gefordert, der Client holt sich also die Ergebnisse über FTP ab, und spiegelt sie auf der lokalen Platte nun wieder.

break

der Server hat zu jeder Zeit die Möglichkeit eine Aktion abzubrechen. Dies sieht technisch nicht anders aus, als eine normale vollständige Ausführung. Der Client muss aber auch die Möglichkeit haben einen "Break" zur aktuellen Aktion zu senden.

während der Laufzeit muss eigentlich das Interface nahtlos austauschbar sein.

lokale Aktionen

weiterhin gibt es völlig lokal ausführbare Operationen. Beispiele:

  • "Was ist neu"
  • "TPicUpload"
  • Öffnen der Dokumentverzeichnisse einer Person

Caching

Die kommunizierenden Systeme (OrgaMon + OrgaMon Ghost) haben ein umfassendes Verständnis von Caching. Caching bedeutet, dass Antworten auf gewisse Fragen vom Client lokal gespeichert werden dürfen. Antworten können dabei ganze Tabellen sein, die einen beachtlichen Datenumfang haben. Ein Cache-Hit kann also umfassende Latenzvorteile bringen. Anworten werden vom Server mit einer eTag versehen. Wie bereits an anderer Stelle angedeutet spielt hier der eTag eine ganz besondere Rolle. Der Client stellt unwissend eine Frage (das eTag ist dabei noch "null") er bekommt die Antwort UND einen dazu passenden eTag. Das nächste Mal wenn er die völlig identische Frage nochmals stellt, sendet er nur den eTag im Header. Nun ist es am Server zu sagen "unchanged" oder einen neuen eTag und den neuen Content zu senden.

Da Datenbankabfragen mit teilweise sehr grossen Antworten "select * from" einhergehen in Verbindungs damit dass ofmals ein "Refresh" notwendig ist. Ist das Caching von Datenbank-Werten erlaubt und wird durch eine besondere Technik unterstützt. 

Client->Server: SQL-Anfrage
Server->Client: eTag & Antwort-Paket
später
Client->Server: eTag?
Server: Unchanged alternativ neuer eTag + Content

Asynchrones Arbeiten

Wichtige Fragen müssen beantwortet werden

  1. Wie verteile ich Arbeit auf viele Cores ohne den Determinismus zu verlieren
  2. Wie schaffe ich eine Infrastruktur die Nativ Parallel ist aber stur sequenziell beschrieben und designed ist

Ziel ist die Steigerung der Latenz von Verarbeitungsschritten, die Latenz hat in der IT eine viel Grössere Bedeutung als die Performance. Das Grundkonzept ist, Verarbeitungsschritte, die gemacht werden müssen "auf später" zu verschieben, und dem rufenden Prozess "Scheinergebnisse" zu liefern. Eine automatische Parallelisierung von "Schritt 1" und "Schritt 2" ist möglich wenn

  • die beiden Schritte keine W-Zugriffe auf fremdgenutzte R-Elemente machen, also wenn ein Schritt keine Datengrundlage des anderen Modifiziert
  • die beiden Schritte nicht von W-Werten des anderen abhängig sind. Also wenn "Schritt 2" eine R-Zugriff auf einen Wert macht, den "Schritt 1" beschreibt. In so einem Fall muss "Schritt 1" zumindest bis zum letzten W auf diesen Wert VORHER ausgeführt werden (Context-Block!).

Context-Freeze

Merke Dir den Schrittzähler im Eingangsmoment zu "Schritt 1". Sollten nachfolgende Schritte massiv die R-Basis von "Schritt 1" beschreiben kann immer noch ein korrektes Ergebnis erzielt werden wenn

  • nachfolgende Schritte nach R Zugriffe auf das W des ersten Schrittes machen
  • der erste Schritte alle R Zugriffe im Context des gespeicherten HBs machen

Sofortiger Rücksprung

Bei einer Read-Only Operation ohne Rückgabewert kann sofort zurückgesprungen werden. Anstelle des Rückgabewertes kann ein "Call Back Token" zurückgegeben werden, das sicherstellt dass wenn etwas auf das Ergebnis zurückgreift dass er erst Einblick erhält wenn die Verarbeitung abgeschlossen ist. Der Zugriff auf R-Objekte muss im aktuellen Heartbeat-Kontext erfolgen, also alle Objekte müssen im Moment des Verarbeitungsbeginnes eingefrohren werden. Ev. kann die Funktion selbst ein "R-Lock" auf Objekte setzen, die es braucht. Wenn andere Prozesse auf diese Objekte nun schreiben wollen muss die Verarbeitung vorrangig abgeschlossen werden. Vor Rücksprung sollten immer Vorbedingungen der Operation geprüft werden, ist also die Durchführung der Aktion möglich und es kann eine Exception ausgeschlossen werden kann dem rufenden der Erfolg gemeldet werden, was er nicht weis ist, dass die Aktion noch gar nicht "wirklich" durchgeführt ist.

Paralleles Arbeiten

  • Intel Parallel Building Blocks (PBB)
  • OpenMP

Interface-Ablauf

Call

Der Client iniziiert einen Call über http. Es sendet seinen Cache ID im etag mit. Dem Server seht es frei diesen eTag zu bestätigen oder ihn zuverwerfen.

Feedback

Zusammen mit dem Client-Call wird ein Feedback Callback (optionales) installiert. Dies ist nur sinnvoll für Routinen die während ihres Ablaufes Infos an den rufenden zurückgeben wollen oder müssen. Damit liefert der Server Zwischen Infos seiner Bearbeitung ab. Dies ist für das Logging wichtig. Bei langdauernden Aktionen des Servers dient das Feedback Interface zum Bewegen der Fortschrittsanzeige. Dabei achtet der Server darauf nicht zu oft feedback zusenden. Eine Variante des Feedback-Interfaces ist einfach eine "Diagnose.txt" die nach Abschluss der Funktion üder den Dateisystem-Sync übertragen ist.

Das feedback Interface ist analog zur XMLRPC Schnittstelle definiert. Sie kann also auch "remote" ablaufen: 

feedback :     TXMLRPC_Method;

TXMLRPC_Method = function(sParameter: TStringList): TStringList of object;


  • Log(s) gibt s als Log aus
  • Info(s) gibt s als aktuelle Aktion aus
  • Progress(BarName,)
  • Inquire (s) Rückfrage

Im Rahmen der Ausführung eines Aufgabe (oder auch einfach so?!), sollte der Server die Möglichkeit haben eine kurze Rückfragen an den Client zu stellen. Die Ausführung stoppt so lange beim Server bis die Nachfrage beantwortet ist. Dies könnte durch das normale Feedback INterface abgewickelt werden.

Interface-Caching

sagen wir mal, wir haben: 

type
 DataModuleeCommerce = class(GhostAbleInterface)
 
 published
  TodaySettings : TStringList;
 end;

wir sagten ja ein lokaler OrgaMon kann auf TodayStrings zugreifen, als wäre das lokal

OrgaMon-GUI

Benutzer Rechte

Im Zentrum einer GUI müssen unverhandelbare Grundrechte des Benutzers stehen. Auswüchse die es im Moment gibt (Wir sind immer noch in der IT-Steinzeit) müssen verhindert werden.

§1 Fokus

Der Eingabefokus darf niemals programmgesteuert dem aktuell sichbaren Eingabefeld entzogen werden. Das Einblenden eines Meldungsfensters während der Benutzer eine Eingabe tätigt ist ein solcher Fokusentzug. Ein Notifikationsbereich ist erlaubt.

§2 Sichtbarkeit

Eingabebereiche dürfen nicht unmotviert überdeckt oder verschoben werden. Bei einer Grössenänderung muss das Zentrum (=Position des Eingabe-Cursors) beibehalten werden.

§3 Verfälschen

Direktes Abändern der Eingabe, also automatisches vervollständigen, automatisches Setzen eines Punktes usw. ist nicht erlaubt.

§4 Klicksichtbarkeit

Ein Klick auf Controls, die erst wenige ms sichtbar sind, darf nicht als eingabe gewertet werden.

§5 Reaktivität

Die GUI darf niemals auf Ergebnisse des Arbeitsprozesses warten, der Job wird an der Theke abgegeben, die GUI ist sofort wieder aktiv.

§6 Feedback

Ausgelöste Aktionen muss ein Feedback auf der GUI erzeugen

§7 Pausen

Jede Eingabe muss zurückgestellt werden können. Eingaben auf anderen Formularen müssen dann möglich sein

§8 Variante

Jedes Formular muss dupliziert werden können. Es muss Testeingabe / Versuche verkraften ohne dass eine Aktion durchgeführt wird, erst anschließendes "Buchen" führt zur Aktion oder eben "Abbruch"

§9 Rückgängig

Jede lokale Eingabe die noch nicht "abgeschickt" ist, muss rückgängig gemacht werden können

UI Ideen

ein Projekt, das zum Ziel hat den OrgaMon mit einer Plattform-übergreifenden GUI anzubieten

farbige Tabs

  • Tab sind erst mal nicht da, können aber aus einem Suchbegriff oder einem Befehl frisch erzeugt werden. Wird z.B. ein Vertrag angewendet entstehen ev. ganz viele neue Beleg, ein Beleg wir als ein einzelner Tab angezeigt.
  • Standard-Aktionen sind auf Tabs anwendbar und können als transaktion auf Gruppen von TAbs angewendet werden.
  • Eine aktuell eingerichtete Tab-Gruppe (3 Personen und 2 Beleg und 1 Vertrag) kann in einer Tab-Historie gespeichert werden.
  • Tab-Favoriten gibt es auch, auf die "Umgeschaltet" werden kann aber auch "dazugeladen" werden kann.
  • man kann mehrere Belege öffnen und gleichzeitig bearbeiten. Dazu "Zieht" man sich einen neuen Tab. Tabs aus der selben Gruppe haben die gleiche Farbe und sind immer zusammen angeordnet (Gruppe schliessen).
  • Es gibt einen Neu Tab.
  • Ein Langer gehaltener Klick auf einen Tab erzeugt einen "Drag"-Event

Tab-Funktionen

Anklicken: Der Tab-Inhalt kommt nach vorne, jetzt erst wenn der TabInhalt sichtbar ist wird das kleine "close" sichtbar.

Progressbereich

  • zeigt zentral aktuelle Wartezeiten an, im Hilfehinweis oberhalb laufen Log meldungen
  • ich bin unsicher, ob dies durchführbar ist, aber ich will eine Unstoppable GUI die einfach nur Anforderungen an eine Exekutive weitergibt. In dem Progressbereich stapeln sich einfach Aufgaben, die im Moment am laufen sind und noch nicht abgeschlossen (Beispiele Dafür: Tagwache auf einem Server, Tagesabschluss auf einem Server, Anwendung von Verträgen usw.)

Suchbereich

OrgaMon ist (wieder) über Hotkeys steuerbar: <ctrl>PN macht "Person" "neu" der Focus steht beim Vornamen usw.

blauer Aqua-Button

der Start-knopf des OrgaMon, hier kommen die ganzen früheren Menü Möglichkeiten

Technologie Review

aktuelle Tendenz

OrgaMon versucht wie OpenOffice eine ganz normale Anwendung zu sein die für verschiedene Plattformen compiliert werden kann. Ev. macht sie auch Gebrauch von den jeweiligen Möglichkeiten des Betriebssystems ...

UI Implementierungen

Browser-Technologie

GUI ist immer im Browser als Web 3.0 Anwendung (HTML 5.0, jquery, JetPack), es gibt einen passiven Content-Provider, ev. eine PHP Apache-Kombination. Aktuelle Formulare sollen jedoch rein aus einem JSON Interface gewonnen werden, die Kommunikation erfolgt direkt zwischen XMPRequest und dem aufgebohrten cOrgaMon (der ja auch mal unter Linux laufen soll).

  • Wie das lokale Dateisystem angesprochen werden soll weiss ich noch nicht
  • Wie das Design der Fomulare erfolgen soll weiss ich noch nicht (also mit welcher IDE, XML Definitionen, ...)
  • Die Bedienelemente sollen ganz einfach beginnen und dann Schritt für Schritt mächtiger werden
  • In einer Übergangsphase soll ein Webkit in den OrgaMon.exe integriert werden (der OrgaMon wird z.B. auch einen Magnetstreifen scannen müssen, oder Datensicherung machen, oder den Computernamen abfragen, oder?)
HTML5-
Client  <--https/2--> systemd Socket Activation <---sd_listen_fds()---> hOrgaMon Web Server    <--fbclient----> FirebirdSQL
                                                                        (links libsystemd.so)   +--file I/O---> .\OrgaMon\

OrgaMon

Ein vollständiger OrgaMon.exe läuft beim Kunden. Die wesentlichen Funktionen laufen jedoch über remoteable APIs. dabei wird das caching Projekt mit der etag Technologie verknüpft. Auf Server-Seite läuft ein eigener Webserver mit ETAG Funktionalität

http://developer.yahoo.com/performance/rules.html

OrgaMon Gimp

Idee

Für die OrgaMon-Kasse benutzt OrgaMon Touch-Folien. So eine Folie könnte so aussehen:

Media:enbw.jpg

Aber: Ein mal zeichnen und fertig ist nicht. Da Position und Farbe und Texte der "buttons" sind ändern. Die Idee ist die, die Anwendung Gimp zu benutzen um Touch-Folien auszubelichten. Also das Ergebnis soll eine fertige Folie sein, ohne dass ein Benutzer Gimp überhaupt starten muss. Dazu erzeugt OrgaMon aus dem Artikel-Stamm ein grosses Skript (Bei Gimp heisst das "Script Fu"), pro Folie ein Skript, das nun durch GIMP ausgeführt wird: 

gimp-console -b kasse-001.scm


Wie man manuell einen Button macht, wird hier http://www.youtube.com/watch?v=QqSR2mgye8Y beschrieben. Diese manuellen Schritte gilt es nun in ein "Script Fu" zu verwandeln, wenn wir diese Technik einmalig haben kann der OrgaMon das mulitplizieren. Hm, ich will natürlich auf die angegebene Fläche sehr viele Buttons zaubern! Wo die Knöpfe hinkommen, das weiss der OrgaMon natürlich ...

erstes Skript "Hallo Welt"

;
; "Hallo Welt" als "script fu"
;

(define (fils-hallo-welt)

 (let*
  (
     (das-bild 0)
     (text-layer 0)
     (ergebnis-layer 0)
  )
;  Ein Bilder erstellen
  (set! das-bild (car (gimp-image-new 1366 768 RGB)))

; Einen Text auf einen neuen Layer schreiben
  (set! text-layer (car(gimp-layer-new das-bild 1366 768 RGB-IMAGE "Text" 100 NORMAL)))
  (gimp-image-add-layer das-bild text-layer 0)
  (gimp-context-set-background '(255 255 255) )
  (gimp-context-set-foreground '(0 0 0))
  (gimp-drawable-fill text-layer BACKGROUND-FILL)
  (gimp-text-fontname das-bild text-layer 15 15 "Hallo Gimp!" 0 TRUE 250 PIXELS "Sans")

; Alle Layer in das Bild schreiben
  (set! ergebnis-layer (car(gimp-image-merge-visible-layers das-bild CLIP-TO-BOTTOM-LAYER)))

; Das Bild speichern
  (file-bmp-save RUN-NONINTERACTIVE das-bild ergebnis-layer "1.bmp" "")
  
 )
)

Skript

; /usr/share/gimp/2.0/scripts/kasse.scm

; test
(define (kasse) 

 (gimp-image-new 1366 768 RGB)
 (file-bmp-save 1 1 1 "1.bmp" "")
 (gimp-quit 0)
)



; kasse.scm
; Erstelle neues Bild 1366 768 RGB
(gimp-image-new 1366 768 RGB)

 Fülle das Bild mit einem angenehmen Gradienten
  Zeiche Button 1 mit Text 1 an Position 0,0
  Zeiche Button 2 mit Text 2 an Position 0,1
  Zeiche Button 3 mit Text 3 an Position 0,2
  Zeiche Button 4 mit Text 4 an Position 0,3
  Zeiche Button 5 mit Text 5 an Position 1,0
  Zeiche Button 6 mit Text 6 an Position 1,1
  ...
  ...
 Speichere das Bild nun als 24 Bit BMP ab

(file-bmp-save 1 1 1 "C:\\1.bmp" "1.bmp")



gimp-console --batch="(kasse)"


also das "echte" Skript wird später aus den Artikeldaten des OrgaMon erstellt. OrgaMonKasse.scm soll nur die Technologie entwickeln.

http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/473/t/47313.aspx

Abgerufen von „https://wiki.orgamon.org/index.php?title=OrgaMon-next&oldid=25605“