JonDa.Server

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.

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

;
; in eckiger Klammer wird der Id des Dienstes angegeben. 
; dieser -Id=Id wird in der Regel per Kommandozeilenparameter mitgegeben
; Es werden dann die Inhalte unter [
[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

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.

Funktionsweise

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

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

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)
1. lade "abgearbeitet.dat"
2. lade "unberuecksichtigt.txt"
3. lade "abgezogen.GGG.dat"
4. lade "GGG.dat"
TTTTT.txt verarbeiten
1. dabei allerlei Tatsachen beachten: Restanten, Stay-Liste, Abgearbeitet, Abgezogene usw.
mit "WriteOrgaMon" den OrgaMon über Ergebnisse informieren
1. TTTTT.DAT und TTTTT.utf8 wird erstellt
Zug um Zug das neue Auftragsvolumen erstellen
1. 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)