Autoupdate

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen

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:
//
// * In 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?e 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 ?hreibt den exe, ruft diesem im Anschluss auf!
// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen k?n, ob Updates vorliegen!
//   spä´¥stens bei Tagesabschluss sollte das gemacht werden!
// * Ein Updateadmin sollte das downgeloadete Update f?e freischalten k?n.
// * Szenario ?gen: Wie kann der Updateadmin ein "m?risches" Update wieder
//   entfernen will, er will sicherstellen dass alle wieder auf die alte Version
//   zur?en, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das
//   eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions
//   markieren k?n. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben
//   bzw. gleich die richtige Version dr?stallieren (Programmversion>Datenbank-
//   Version/empfohlene Version)
// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen
//   er gibt diese Version frei oder nicht.
// * W䨲end das Datenbank-Update noch l䵦t, muss verhindert werden dass sich
//   Clients mit der Datenbank verbinden. Dies k?e einfach durch eine vorhandene
//   "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-
//   gef?bis das Update abgeschlossen ist.
// * In einer zuk?en Version k?e das DB-Update einfach mal versucht werden,
//   dabei m?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. (Gibt es f? SYSDBA die M?chkeit USER
 //   ja durch einen "shutdown" rauszuschmeissen!).