JonDa.Server
- 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.
AppServer
- Der AppServer dienstleistet die Funktionalität 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 "" Verwalten
Neustart unter Linux
systemctl restart cOrgaMonApp@~FirmenKurzbegriff~
ShopServer
Ein XMLRPC Dienst der vom Webshop ins Anspruch genommen wird.
FotoServer
Dienstleistet
- das Zuordnen der Fotos in die jeweiligen Ablagen
- Umbenennen der Fotos nach bestimmen Namensmodellen
- Aufräumen in den Internet-Ablage incl. Wegsichern der Daten
Neustart unter Linux
systemctl restart cOrgaMonFoto@~FirmenKurzbegriff~
Unter Wine
#!/bin/bash # # JonDaServer - wine - Startup Script # sleep 25 export LANG=de_DE.UTF-8 mount //~NAS-Host~/web$ /root/.wine/drive_w --verbose -o guest wine "C:\\Program Files\\JonDaServer\\cJonDaServer.exe"
- Offenes Problem: Nutzt wine ein lokales SMB-Share so werden die ("DOS"-) Dateien mit den falschen Rechten angelegt.
Konfiguration
Port des XML-RPC Services
Default ist 3049
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.
von JonDa erwartet php Funktionen:
up.php?id=666;50000;1.011 // GeräteID;LetzteErfolgreicheTAN;Programmversionsnummer
// Antwort: liefert im BODY eine neue TAN
up.php?tan=50999&data=part1 // lädt Daten hoch
up.php?tan=50999&data=part2 // ...
up.php?tan=50999&data=part3 // ...
up.php?proceed=50999 // fordert zum verarbeiten auf, liefert "OK" im BODY
up.php?info // liefert im BODY die BasePlug-Infos,
zum Test der XMLRPC-Verfügbarkeit
Ablagebereich für das php Script:
./JonDaServer/<TAN>/.
2) Verzeichnis-Replikation via FTP
Der Kunde erhält über ein html-Dokument auf seiner Internet-Domain die aktuelle IP des
Linux Workgroup Servers(2) von "Andreas Filsinger, Softwareentwicklung". Mit
Hilfe der IP-Adresse und einer Benutzername/pwd Kombination kann sich der Dienstleister
via passiven ftp-client auf den ftp-Server-Dienst auf dem ISDN-Server verbinden.
Nun müssen 2 lokale DL-Verzeichnisse (wiederum IN/OUT) synchronisiert werden.
Dazu können Standard-Verzeichnis Replikations-Dienste verwendet werden. Man sollte
vorsehen, dass das OrgaMon-Team diesen Replikations-Prozess selbst anstossen kann.
Ansonsten läuft dieser etwa alle 30 Minuten automatisiert.
3) Kopplung von OrgaMon an IN / OUT
OrgaMon(4) liesst und beschreibt im Rahmen des Tagesabschlusses oder auf manuelle
Anforderung die beiden Verzeichnisse und bereitet alle Dateien auf. IN und OUT
müssen für alle OrgaMon-Arbeitsplätze sichtbare Verzeichnisse sein.
4) Ausfall-Konzept
Situation: Totalausfall des "filsinger-Servers"
JonDa-Server wird auf CD-R als installierbares Tool für win32 geliefert. Der Rechner
auf dem installiert wird muss auch eine OrgaMon-Client Installation besitzen. Beim Dienstleister
wird ein Handy mit V24-Schnitstelle an diesen Arbeitsplatz gekoppelt.
Den Monteuren wird mitgeteilt, dass der "ALTERNATIV-SERVER" angewählt werden muss
(Das ist ein Menü-Punkt in der JonDa-Software). Der Anruf des Monteur-Handys
landet auf dem Handy des Dienstleisters.
5) Sicherheits-Schlagworte
- Der Linux-Server besitzt eine Firewall
- Das Filsinger Netzwerk besitzt eine DMZ dem der ISDN-Server zugeordnet ist
- JonDa-Server und OrgaMon benutzen starke Verschlüssellung für alle Dateien in In/Out
dadurch ist ein abhören im Internet wenig sinnvoll
- Die Anwahlnummern bleiben geheim
- Die Anwahl der MDEs ist durch täglich wechselnde pwds gesichert
- JonDa-Server hat kein bekanntes Sicherheitsloch seit ca. 1991
wichtige Infos zur Installation unter Windows 2000
- Die FRITZ! PCI Card Treiber MÜSSEN auf den neuesten Stand gebracht werden. Sonst
gibt es Übertragungsfehler.
- Der CAPI-Port Treiber muss auf custom-Config unter der Verwendung des ersten
nicht physikalischen Ports installiert werden sonst gehts nicht!
JonDaServer.ini
Im [Default]-Bereich werden alle Einstellungen gespeichert, falls der Rechnername nicht gefunden wird.
[Default] ComPort=3 InitString=ATS50=966208;S49=966208;S31=2;S51=0;S35=9600
Ansonsten muss der Rechnername als Sektionsname in eckige Klammern gesetzt werden.
[fred] ComPort=3 InitString=ATS50=966208;S49=966208;S31=2;S51=0 ftppwd=????? ftpuser=?????
Konzepte und Tatsachen
- heute abgearbeitete Termin bleiben auf dem Gerät
- Man kann mit der Geräte-Nummer "000" anrufen lassen. Dabei wird der
aktuellen Bestand des Gerätes gelöscht. Es wird eine leere Auftragsdatei übertragen. Die "alten" Daten, die sich auf dem Gerät befanden sind zwar auf dem JonDaServer gesichert, werden aber nicht an OrgaMon über- tragen.
- Man kann Auftragsoptionen in den Server eintragen. Beim nächsten Anruf wird
dann bei passender Gerätenummer diese Option ausgeführt!
Ideen
ACTIDX.DAT könnte man zumindest auf "1" setzen. Noch besser: erster nach den
Restaten, noch besser
Lizenz
MPL 1.1 für alle mitgelieferten Sourcen.
Es werden jedoch nicht freie Komponenten verwendet, diese sind nicht Teil der
Distribution, können jedoch durch freeware-tools ersetzt werden.
tserial4, http://www.rjc.org.uk/sharewar.htm
capi2han, http://www.isdn-tools.de
Verzeichnisinhalt einer Transaktion
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
JonDaServer (Ausblick)
der JonDaServer könnte auch in PHP / Python oder in Java (Java-Server Pages Tomcat) implementiert werden. Wichtig ist auch wieder dass durch eine kleine GUI Diagnose-Fragen an das System gestellt werden können. Ev. wird dazu weiter Delphi verwendet.
Einzelprobleme sind hier:
- FTP-Komponente für UP- und DOWN- Load
- Ev. von dem binären Format des MDEREC verabschieden, sondern immer mit csv arbeiten