JonDa.Server: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Root (Diskussion | Beiträge) |
Root (Diskussion | Beiträge) |
||
Zeile 23: | Zeile 23: | ||
; | ; | ||
; | ; durch mehrere Sektionen (Name in der eckigen Klammer, im Moment <b>System</b>) | ||
; kann | ; kann zwischen mehreren Mandanten unterschieden werden. So ist es | ||
; möglich mehrere Instanzen des Servers auf einer System zu betreiben. | ; 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 | ; Bei Start wird dem OrgaMon-App-Server über den Kommandozeilenparameter | ||
; -Id=<i>Id</i> dieser Sektionswert mitgegeben (default=System) | ; --Id=<i>Id</i> dieser Sektionswert mitgegeben (default=System) | ||
; | ; | ||
[<i>System</i>] | [<i>System</i>] |
Version vom 16. November 2019, 11:47 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\
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
- 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"
- Direkt wenn ein Bild im ftp Bereich komplett hochgeladen ist wird noch vor der Zuordnung eine Sicherungskopie nach .\bak\Fotos gemacht
- Im Rahmen des "Ablagedienstes" der automatisch um 00:00 Uhr anläuft werden zu alte Dateien aus allen Internetablagen in #zzz verschoben
- der Fotoserver protokolliert zwar die Grösse des aktuell verwendeten Sicherungsverzeichnisses aber unternimmt nichts zur Entlastung
Entlastung
- Mit dem Programm "Flatdigger" kann das #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 Unterverzeichnisse wurden auf DVD-Medien gesichert
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
systemctl stop cOrgaMonApp@~FirmenKurzbegriff~ systemctl stop cOrgaMonFoto@~FirmenKurzbegriff~ sleep 5 systemctl start cOrgaMonFoto@~FirmenKurzbegriff~ 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
up.php?info=JA // liefert im BODY die BasePlug-Infos, zum Test der XMLRPC-Verfügbarkeit
Info zum Verzeichnisinhalt
Transaktionsverzeichnis
TTTTT
ist die Transaktionsnummer- Verzeichnis .\dat\TTTTT\
GGG.DAT (vom FTP) Netto-Auftragsvolumen für dieses Gerät, wird frisch vom ftp-Bereich geholt. GGG.ZIP (vom Gerät) komplett Daten vom Gerät kommend TTTTT.DAT (zum OrgaMon) Meldenswerte Volumen für OrgaMon (Bericht Datei) TTTTT.TXT (vom Gerät) Eingaben den Monteures AUFTRAG.DAT (zum Gerät) das neue, vom Server zusammengestellte Volumen auftrag.txt (zum Gerät) das neue, vom Server zusammengestellte Volumen in Textform JONDA.DAT (vom Gerät) vom Monteur getätigte Eingaben. GERAET.DAT (vom Gerät) Geräteeinstellungen LOST.DAT (nur Zwischendatei) verschimmelte Restaten landen dort STAY.DAT (nur Zwischendatei) GGG.DAT+STAY.DAT=AUFTRAG.DAT
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
FTP
- Verzeichnis .\ftp\
# # 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)
Weitere Infos
- Betrieb und Installation von cOrgaMon.exe auf Linux Linux.wine