Autoupdate: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
//  Verwirklichtes Konzept:
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.
//
 
// * In es ein metadata relevantes Update, so wird in der Tabelle Revision ein '9999'
== Updaten auf die neueste OrgaMon Version ==
//  eingetragen. Dieses bleibt solange bestehen, bis der Updatevorgang abgeschlossen
 
//  oder fehlgeschlagen ist. Connects sollten in dieser Zeit unterbleiben!
Der Abruf der neuesten Version aus dem Internet kann eine Arbeitsstation initiieren. Dies erfolgt durch
// * Frisch connectierte OrgaMon sollten im Update-Check geparkt werden, bis
 
//  das db-update abgeschlossen ist. Es wird dabei im Sekundentakt immer wieder
  Update->"neuestes Update im Internet" ausführen
//  nach dem Wert 9999 gesehen!
 
// * Sieht die Datenbank beim insert den Wert '9999' so feuert sie den event
== Version als "schlecht" markieren ==
//  post_event 'PLEASE_DISCONNECT';
 
// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,
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).
//  das in wenigen Minuten heruntergefahren werden muss. z.B. K?e so ein XMLRPC
 
//  Server keine neuen Verbindungen mehr annehmen! '9998'
== Technische Details zum Update-Konzept ==
// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen
 
// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet
//  Verwirklichtes Konzept:
//  sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.
//
//  Danach das Setup, dieses ?hreibt den exe, ruft diesem im Anschluss auf!
// * In es ein metadata relevantes Update, so wird in der Tabelle Revision ein '9999'
// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen k?n, ob Updates vorliegen!
//  eingetragen. Dieses bleibt solange bestehen, bis der Updatevorgang abgeschlossen
//  spä´¥stens bei Tagesabschluss sollte das gemacht werden!
//  oder fehlgeschlagen ist. Connects sollten in dieser Zeit unterbleiben!
// * Ein Updateadmin sollte das downgeloadete Update f?e freischalten k?n.
// * Frisch connectierte OrgaMon sollten im Update-Check geparkt werden, bis
// * Szenario ?gen: Wie kann der Updateadmin ein "m?risches" Update wieder
//  das db-update abgeschlossen ist. Es wird dabei im Sekundentakt immer wieder
//  entfernen will, er will sicherstellen dass alle wieder auf die alte Version
//  nach dem Wert 9999 gesehen!
//  zur?en, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das
// * Sieht die Datenbank beim insert den Wert '9999' so feuert sie den event
//  eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions
//  post_event 'PLEASE_DISCONNECT';
//  markieren k?n. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben
// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,
//  bzw. gleich die richtige Version dr?stallieren (Programmversion>Datenbank-
//  das in wenigen Minuten heruntergefahren werden muss. z.B. K?e so ein XMLRPC
//  Version/empfohlene Version)
//  Server keine neuen Verbindungen mehr annehmen! '9998'
// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen
// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen
//  er gibt diese Version frei oder nicht.
// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet
// * W䨲end das Datenbank-Update noch l䵦t, muss verhindert werden dass sich
//  sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.
//  Clients mit der Datenbank verbinden. Dies k?e einfach durch eine vorhandene
//  Danach das Setup, dieses ?hreibt den exe, ruft diesem im Anschluss auf!
//  "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-
// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen k?n, ob Updates vorliegen!
//  gef?bis das Update abgeschlossen ist.
//  spä´¥stens bei Tagesabschluss sollte das gemacht werden!
// * In einer zuk?en Version k?e das DB-Update einfach mal versucht werden,
// * Ein Updateadmin sollte das downgeloadete Update f?e freischalten k?n.
//  dabei m?aufgezeichnet werden, welche Update-Schritte durchliefen, und bei
// * Szenario ?gen: Wie kann der Updateadmin ein "m?risches" Update wieder
//  welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem
//  entfernen will, er will sicherstellen dass alle wieder auf die alte Version
//  Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es
//  zur?en, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das
//  zum kritischen Update!). Ab der ersten exception kann ja nun wieder angesetzt
//  eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions
//  werden!
//  markieren k?n. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben
// * Die SQL-Scripts, die von Release zu Relase die Datenbank Struktur
//  bzw. gleich die richtige Version dr?stallieren (Programmversion>Datenbank-
//  hochziehen, nach aussen transparenter machen (in der !*_Info.html!), da doch das
//  Version/empfohlene Version)
//  Interesse an der Datenbank-Struktur bei siemens da zu sein scheint.
// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen
//  die Datei befindet sich im Verzeichnis "MyApplicationPath". format:
//  er gibt diese Version frei oder nicht.
// * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im
// * W䨲end das Datenbank-Update noch l䵦t, muss verhindert werden dass sich
//  hebu - Projekt nachgewiesen werden. Ev. mal einen Test-Case daraus machen!
//  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!).

Version vom 19. September 2005, 08:15 Uhr

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!).