JonDa.Server: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Root (Diskussion | Beiträge) (→FTP) |
Root (Diskussion | Beiträge) |
||
Zeile 326: | Zeile 326: | ||
== Info zum Verzeichnisinhalt == | == Info zum Verzeichnisinhalt == | ||
=== Web === | === Web === | ||
Version vom 30. April 2020, 08:48 Uhr
- Der JonDaServer ist die "App"-Identität des cOrgaMon.exe
- Er betreibt einen XMLRPC Server im Namespace "jonda"
- Hier sieht man die beiden Server-Prozesse "App-Service" (im Vordergrund als win32 KOnsolenanwendung) und "Foto-Service" (im Hintergrund als Win32-GUI) bei der Arbeit.
- Die beiden Server-Programme für Win32-Systeme sind die Kommunikations-Partner für die Android Anwendung OrgaMon-App.
- Die Server arbeiten ohne Datenbank und Sychronisieren sich mit OrgaMon über einen gemeinsamen FTP-Ablage Bereich.
- Beiden Anwendungen werden heutzutage als Win32-Konsolenanwendungen unter wine auf Linux ausgeführt.
- Beide Server-Prozesse sind vollständig im Quelltext veröffentlicht im Rahmen des OrgaMon-Open-Source Projektes. Beide Dienste werden über cOrgaMon.exe geleistet, dieses Programm kann in der mit der Identität (Entwickler#OrgaMon-Server-Identitäten) "Foto" und der Idendität "App" gestartet werden.
Identitäten
AppServer
- Der AppServer dienstleistet die Funktionalität "jonda.proceed" hinter dem "senden" für die OrgaMon-App auf den Smartphones
- Der Server wird ohne GUI für Verwaltungs- und Rechercheaufgaben geliefert (Win32, cOrgaMon.exe)
- Im Regelbetrieb wird die Konsolenanwendung auch unter Wine eingesetzt
- Im OrgaMon lässt sich der Dienst unter "App" Verwalten
cOrgaMon.ini
; ; durch mehrere Sektionen (Name in der eckigen Klammer, im Moment System) ; kann zwischen mehreren Mandanten unterschieden werden. So ist es ; möglich mehrere Instanzen des Servers auf einer System zu betreiben. ; Und für jeden Id, für jede Sektion folgt dann andere Einstellungen. ; ; Bei Start wird dem OrgaMon-App-Server über den Kommandozeilenparameter ; --Id=Id dieser Sektionswert mitgegeben (default=System) ; [System] ; ; Optionales Feld, es muss einfach nur mit einem Wert belegt sein, ; ; wenn nicht wird der Wert "System" angenommen. Alle weiteren ; Optionen werden dann unter der Sektion [System] gesucht. ftpuser=System ; Für die Identität "App-Server" ; ; für das Script "up.php" des ./web Verzeichnisses des OrgaMon-App-Server ; ; Für die Identität "Web-Server" ; ; wird auch aus im 2. Rang aus dem Kommandozeilenparameter "-Port=" ermittelt host= port=3049 ; ; Für die Identität "App-Server". ; ; =JA ; Damit kann man ; die Datum/Uhrzeit Prüfung beim "senden" Versuch der Handys ; ausschalten ; NoTimeCheck=NEIN ; ; Für die Identität "App-Server" ; ; Für die Ausführung der XMLRPC-Funktion "senden" bei "einfacher Liste" ; Funktion @XMLRPCHost:XMLRPCPort:abu.Senden() ; XMLRPCHost=raib23 XMLRPCPort=3042 ; ; Für die Identitäten "App-Server" und "Foto-Server" ; BackUpPath=..\bak\ WebPath=..\web\ FTPPath=..\ftp\ LogPath=..\log\
- siehe auch Installation.Arbeitsplatz#OrgaMon.ini
Optionen
- Der JonDa-Server kann bestimmten Geräten bestimmte Programm-Optionen mitgeben. Dies wird mit
OPTIONEN=
in der Geräte-Einstellungsdatei gesteuert.
a
- KEINE_DOPPELEINGABE_ZAEHLERSTAND_ALT
b
- KEINE_DOPPELEINGABE_ZAEHLERNUMMER_NEU
c
- KEINE_DOPPELEINGABE_ZAEHLERSTAND_NEU
Einstellungen
- Pro Gerät kann eine .ini Datei angelegt werden, diese Datei steuert individuelle Einstellungen
- Dateiname ist
<3stellige GeräteNummer>.ini
#
# Ist das Datum/Uhr des Handys falsch einstellt unterbleibt die
# weitere Datenverarbeitung.
#
# JA | NEIN
#
ZEIT_PRÜFUNG=
#
#
#
#
OPTIONEN=
#
# für die Lager-Funktionen muss diese Option auf "JA" gesetzt werden
#
# JA | NEIN
#
EinfacheListe=
#
# Protokolle befinden sich im Verzeichnis ./dat/Protokolle
# Ist dieser Schalter gesetzt, so wird davon ausgegangen, dass es hier
# Unterverzeichnisse gibt. Der Namen der Unterverzeichnisse ist
# in dieser Einstellung angegeben. Default ist <Leer> also kein
# weiteres Unterverzeichnis.
#
# <Leer> | Unterverzeichnis\
#
ProtokollPfad=
ShopServer
Ein XMLRPC Dienst der vom Webshop ins Anspruch genommen wird.
FotoServer
Aufgaben
- sofortiges Sichern jedes Fotos, das über FTP hochgeladen wird
llll-ggg-rrrrrr-pp.jpg lll = laufende Backupnummer ggg = geräte ID rrr = Auftrags-RID pp = Foto Parameter
- das Zuordnen der Fotos in die jeweiligen Ablagen
- Umbenennen der Fotos nach bestimmen Namensmodellen
- Aufräumen in den Internet-Ablage incl. Wegsichern der Daten
Datensicherung
- Im .\bak Verzeichnis muss sich zumindest ein Unterverzeichnis befinden mit dem Namen #zzz (wobei "z" eine Ziffer "0" .. "9" sein muss)
- Der Server startet und ermittelt aus allen "#*" Unterverzeichnissen das mit der höchsten Nummer "zzz", nur in dieses wird gesichert
- Direkt wenn ein Bild im FTP- Bereich komplett hochgeladen ist, wird noch vor der Zuordnung eine Sicherungskopie nach .\bak\Fotos gemacht
- die Befüllung von ./bak/#zzz ist also kontinuierlich über den ganzen Tag zu erwarten
- Im Rahmen des "Ablagedienstes" der automatisch nach 00:00 Uhr anläuft werden zudem alte Dateien aus allen Internetablagen (./web) nach #zzz verschoben
- Nach dem Verschieben der Zips wird die Grösse des aktuell verwendeten Sicherungsverzeichnisses protokolliert
- Ist es >3,8 GB so wird ein neues Sicherungsverzeichnis angelegt (Name ist die alte Nummer + 1), die Umschaltung auf dieses Sicherungsverzeichnis erfolgt beim nächsten Dienste-Start, aber möglicherweise nicht sofort
- Sicherungsverzeichnisse, die man wegverschieben darf, werden deshalb mit der leeren Datei
./MOVE-OK
markiert - Ein externes Sicherungstool sollte also z.B. #222 erst verschieben wenn #222/MOVE-OK vorhanden ist
Entlastung
- Mit dem Programm "Flatdigger" kann ein zu groß gewordenes #zzz Unterverzeichnis entlastet werden
- das Programm verschiebt die Daten so, dass neue Unterverzeichnisse (fortlaufende Nummer) entstehen, die alle maximal 4 GB gross sind
- die 4 GB-Grenze hat historische Gründe: Diese Unterverzeichniss-Grössen konnten auf DVD-Medien gesichert werden
Installation
- Betrieb und Installation von cOrgaMon.exe auf Linux Linux.wine
Sektions-Migration
- Den Id, sprich die Sektion der .ini, sprich den Mandanten oder den Namensraum unter dem der OrgaMon-App-Server läuft kann man ändern, dies muss aber an einigen Stellen gemacht werden:
- zunächst eine Diagnose: Stellen Sie zunächst fest unter welcher Id das System im Moment läuft
systemctl status | grep cOrgaMon
- es werden alle bisherigen --Id ausgegeben
- es wird nun beschrieben wie Sie "alte-Id" auf "neue-Id" ändern können
/etc/crontab editieren
10 02 * * * root systemctl stop cOrgaMonApp@alte-Id 10 02 * * * root systemctl stop cOrgaMonFoto@alte-Id 15 02 * * * root systemctl start cOrgaMonApp@alte-Id 15 02 * * * root systemctl start cOrgaMonFoto@alte-Id
- umstellen auf
10 02 * * * root systemctl stop cOrgaMonApp@neue-Id 10 02 * * * root systemctl stop cOrgaMonFoto@neue-Id 15 02 * * * root systemctl start cOrgaMonApp@neue-Id 15 02 * * * root systemctl start cOrgaMonFoto@neue-Id
OrgaMon.ini in "Documents" editieren
[alte-Id]
- umstellen auf
[neue-Id]
- Merken Sie sich das angegebene Verzeichnis im Wert DatabaseName=, dieses Verzeichnis ist für den nächsten Schritt nötig
cOrgaMon.ini im .\dat editieren
[alte-Id]
- umstellen auf
[neue-Id]
systemctl Befehle durchführen
systemctl stop cOrgaMonApp@alte-Id systemctl disable cOrgaMonApp@alte-Id systemctl stop cOrgaMonFoto@alte-Id systemctl disable cOrgaMonFoto@alte-Id
systemctl enable cOrgaMonApp@neue-Id systemctl enable cOrgaMonFoto@neue-Id systemctl start cOrgaMonApp@neue-Id systemctl start cOrgaMonFoto@neue-Id
Neustart unter Linux
- da wine einzelne Resourcen für alle cOrgaMon.exe Prozesse teilt, muss ein Neustart immer alle Instanzen und Identitäten betreffen
- zudem verwendet wine Optimierungen die eine verzögerte Freigabe dieser Resourcen bewirkt
- somit ist nach dem Beenden der Prozesse eine Wartezeit einzuplanen
- geschieht das nicht, kann das Ergebnis sein, dass z.B. Sockets oder Dateien noch nicht freigegeben sind
- Bei gleichzeitigem Start der Idendität "App" und "Foto" kann Streit um Resourcen entstehen, wodurch der Start dann misslingt
systemctl stop cOrgaMonApp@~FirmenKurzbegriff~ systemctl stop cOrgaMonFoto@~FirmenKurzbegriff~ sleep 100 systemctl start cOrgaMonFoto@~FirmenKurzbegriff~ sleep 100 systemctl start cOrgaMonApp@~FirmenKurzbegriff~
XML-RPC Funktionen
jonda.BasePlug () : array of string; { Infos } // liefert diverse Informations-String: // 1) Datenbankname (im Moment nicht verfügbar, jonda benötigt im Moment keine Datenbank) // 2) Jonda - Server Versions-Nummer // 4) Indy Versions-Nummer //
jonda.StartTAN (GeraetID : string) : string; { TAN } // erwartet eine 3 stellige Geräte Identifiktationsnummer wie z.B. 422 // Die Funktion holt die passenden Gerätedaten von einem FTP Server // Ist das Gerät bekannt, so wird eine neue TAN Nummer gezogen, es wird // ein entsprechendes Verzeichnis geöffnet, und Upload Daten können // gezogen werden. // Format: GeraetID;_TAN;VERSION;OPTIONEN;UHR; // GeraetID : z.B. 003 // _TAN : bisherige TAN // VERSION : Programmversion z.B. 1.114 // OPTIONEN : 85 // UHR : Datum + Uhr im Format: "26.09.2005 - 07:21:05"
jonda.ProceedTAN (TAN : string) : integer; { 0=OK,Ansonsten Fehlercodes } // verarbeitet alle Eingangsdaten und stellt die Ergebnisdateien // im entsprechenden TAN Verzeichnis zur Verfügung.
Kommunikation bei "senden"
- Schritte des Skripts
- up.php zieht eine neue Transaktions-Nummer und erstellt das gleichnamige Verzeichnis
- up.php hat Zeile für Zeile Auftragsergebnisse in die Datei [] geschrieben
- Final kontaktiert up.php den XML-RPC Server und führt die Funktion "proceed" aus
# # Initialisierungsphase # up.php?id=666;50000;1.011 // GeräteID;LetzteErfolgreicheTAN;Programmversionsnummer // Antwort: liefert im BODY eine neue TAN # # Datenübertragungsphase # up.php?tan=50999&data=RID1 // lädt Daten hoch up.php?tan=50999&data=RID2 // ... up.php?tan=50999&data=RID3 // ... # # up.php?proceed=50999 // fordert zum verarbeiten auf, liefert "OK" im BODY
Diagnose
# # Test der XMLRPC-Verfügbarkeit # liefert im BODY die BasePlug-Infos # http://<deinAppServer>/up.php?info=JA # # Ausgabe der aktuellen Logs für die Idendität "Foto" # journalctl -e -nall -t cOrgaMonFoto
Info zum Verzeichnisinhalt
Web
- Verzeichnis .\web\
TTTTT.auftrag.utf-8.txt (vom Server) das neue Auftragsvolumen für die OrgaMon-App TTTTT.txt (vom Script up.php) die Eingabeergebnisse der OrgaMon-App
dat
Daten
AUFTRAG+TS.BLA Verzeichnis aller bekannten Aufträge FOTO+TS.BLA Verzeichnis aller bekannten Aufträge mit Foto-Anforderung
ftp
- Verzeichnis .\ftp\, das zentrale Up- Downloadverzeichnis des Servers
# # dynamisch (Dateien werden nach dem Verarbeiten durch den OrgaMon gelöscht) # TTTTT.DAT Meldungen der OrgaMon-App an OrgaMon (binär) TTTTT.utf-8.txt Meldungen der OrgaMon-App an OrgaMon (als Text) # # dynamisch (Dateien werden nach dem Verarbeiten durch den OrgaMon-App-Server gelöscht) # baustelle.csv # # dynamisch (Dateien werden nach dem Verarbeiten durch den OrgaMon-Foto-Server gelöscht) # GGG-RRRRRR-PP.jpg # # statisch (Dateien werden durch den OrgaMon bereitgestellt/aktualisiert und bleiben bestehen) # GGG.DAT abgearbeitet.dat abgezogen.GGG.dat # # statisch (Dateien werden durch den OrgaMon-App-Server # AUFTRAG.GGG.DAT
Verarbeitungsschritte
proceed
- Schritte der Proceed-Funktion
- Geräte Speziefische Optionen laden
- Transaktion Initialisieren (InitTRN)
- lade "abgearbeitet.dat"
- lade "unberuecksichtigt.txt"
- lade "abgezogen.GGG.dat"
- lade "GGG.dat"
- TTTTT.txt verarbeiten
- dabei allerlei Tatsachen beachten: Restanten, Stay-Liste, Abgearbeitet, Abgezogene usw.
- mit "WriteOrgaMon" den OrgaMon über Ergebnisse informieren
- TTTTT.DAT und TTTTT.utf8 wird erstellt
- Zug um Zug das neue Auftragsvolumen erstellen
- AUFTRAG.DAT und auftrag.txt erstellen
Datenabruf
- Der Client lädt die Datei TTTTT.auftrag.utf-8.txt vom .\web\ Verzeichnis
todo
- von dem binären Format des MDEREC komplett verabschieden (immer mit csv arbeiten)