Autoupdate

Durch das Autoupdate Konzept wird sichergestellt, dass auf jedem OrgaMon Arbeitsplatz immer die neueste Programmversion läuft. Dazu muss der Administrator Schreibrechte auf das lokale OrgaMon-Programm-Verzeichnis (C:\Programme\OrgaMon) gewären.

Updaten auf die neueste OrgaMon Version

Der Abruf der neuesten Version aus dem Internet kann eine Arbeitsstation initiieren. Dies erfolgt durch

 Update->"neuestes Update im Internet" ausführen

Version als "schlecht" markieren

Es kann vorkommen, dass sich neu implementierte Funktionen oder Verbesserungen an bisherigen Funktionen als fehlerhaft oder sogar schädlich für den gesamtzusammenhang erweisen. Dann bietet der OrgaMon eine Funktion an, um gewisse Release Nummern als "schlecht" zu markieren. Die Verwendung dieser Versionen wird dann automatisch umgangen. Es wird entweder eine Version vorher oder nach der "schlechten" verwendet. Eventuelle Datenbank Metadaten Änderungen bleiben jedoch bestehen (Stand 19.09.2005).

Technische Details zum Update-Konzept

//  Verwirklichtes Konzept:
//
// * Ist es ein metadata relevantes Update, so wird in der Tabelle Revision ein '9999'
//   eingetragen. Dieses bleibt solange bestehen, bis der Updatevorgang abgeschlossen
//   oder fehlgeschlagen ist. Connects sollten in dieser Zeit unterbleiben!
// * Frisch connectierte OrgaMon sollten im Update-Check geparkt werden, bis
//   das db-update abgeschlossen ist. Es wird dabei im Sekundentakt immer wieder
//   nach dem Wert 9999 gesehen!
// * Sieht die Datenbank beim insert den Wert '9999' so feuert sie den event
//   post_event 'PLEASE_DISCONNECT';
// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,
//   das in wenigen Minuten heruntergefahren werden muss. z.B. Könnte so ein XMLRPC
//   Server keine neuen Verbindungen mehr annehmen! '9998'
// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen
// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet
//   sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.
//   Danach das Setup, dieses überschreibt die exe, ruft diese im Anschluss auf!
// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen können, ob Updates vorliegen!
//   spätestens bei Tagesabschluss sollte das gemacht werden!
// * Ein Updateadmin sollte das downgeloadete Update für alle freischalten können.
// * Szenario: Wenn der Updateadmin ein "mörderisches" Update wieder
//   entfernen will, er will sicherstellen dass alle wieder auf die alte Version
//   zurückstufen, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das
//   eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions
//   markieren können. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben
//   bzw. gleich die richtige Version drüber installieren (Programmversion>Datenbank-
//   Version/empfohlene Version)
// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen
//   er gibt diese Version frei oder nicht.
// * Während das Datenbank-Update noch lädt, muss verhindert werden dass sich
//   Clients mit der Datenbank verbinden. Dies könnte einfach durch eine vorhandene
//   "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-
//   geführt, bis das Update abgeschlossen ist.
// * In einer zukünftigen Version könnte das DB-Update einfach mal versucht werden,
//   dabei müsste aufgezeichnet werden, welche Update-Schritte durchliefen, und bei
//   welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem
//   Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es
//   zum kritischen Update!). Ab der ersten exception kann ja nun wieder angesetzt
//   werden!
// * Die SQL-Scripts, die von Release zu Relase die Datenbank Struktur
//   hochziehen, nach aussen transparenter machen (in der !*_Info.html!), da doch das
//   Interesse an der Datenbank-Struktur bei Siemens da zu sein scheint.
//   die Datei befindet sich im Verzeichnis "MyApplicationPath". format:
// * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im
//   hebu - Projekt nachgewiesen werden. Ev. mal einen Test-Case daraus machen!
// *
 // * Der UpdateAdmin verursacht das Signal, dass alle OrgaMon sich beenden sollten.
 //   Er wartet, bis die User-Anzahl der Datenbank auf "1" (er selbst) abgesunken
 //   ist oder max 25 Sekunden. (Es gibt ja für SYSDBA die Möglichkeit USER
 //   durch einen "shutdown" rauszuschmeissen!).