0: Zunaechst wir immer nachgesehen, ob das Repository bereits geklont wurde. Wenn nein, dann wird geklont. Im Master-Branch befinden sich Dateinen, die in allen anderen Branches gemeinsam genutzt werden. Das sollte wohl auf jeden Fall fuer den DeviceController gelten. 1: Anfrage bei ISMAS ob neue Daten da sind. Hier faengt die ganze Sache an. Da man nicht weiss, on ISMAS ueberhaupt antworten wird braucht es einen Timer. Man kann die Sache dann auch gleich mehrfach versuchen. Die Anfrage geht also per Signal an den Apism-Client. Im Signal wird der Zustand mitgegeben: ISMAS_UPDATE_REQUEST_PENDING und im Slot dann entsprechend uebernommen. Der Timer sollte nicht im Worker stehen, sondern im Apism-Client. Der Worker sollte damit nicht belastet sein. Der wird dann vom Apism-Client entsprechend benachrichtigt. ISMAS_UPDATE_REQUEST_FAILURE ISMAS_UPDATE_REQUEST_TIMEOUT ISMAS_UPDATE_REQUEST_SUCCESS Im 1./2.Fall wird dann ein Fehlerhandling durchgefuehrt. Insbesondere wird Apism ueber den DB-Kanal darueber informiert (U0003). Am Ende wie dann wie immer SendCmdVersion und beenden der Applikation. Im Erfolgsfall muss in der Antwort der Branch enthalten sein, fuer den das Update durchgefuhrt werden soll. Das ist auch bereits so (Location). Ein Sonderfall waere der -m-Modus, da hier niemand auf der ISMAS-Seite aktiv eingreift. Hier braucht es dann einen Ubergabeparameter an ATBUpdateTool: --branch-name Normalfall ist aber die Aktivierung via ISMAS. Dann muss der in der Antwort enthaltene Branch zunaechst ausgecheckt werden. 2: Dazu wird ein entsprechendes Signal an den GitClient gesandet. GIT_CHECKOUT_BRANCH_REQUEST Der GitClient sieht jetzt erstmal nach, ob es diesen Branch ueberhaupt gibt. Falls nein: GIT_CHECKOUT_BRANCH_REQUEST_FAILURE BRANCH_NOT_EXIST Falls ja: der GitClient versucht nun den Branch auszuchecken. Geht das gut? Falls nein: GIT_CHECKOUT_BRANCH_REQUEST_FAILURE BRANCH_CHECKOUT_ERROR Falls ja: GIT_CHECKOUT_BRANCH_REQUEST_SUCCESS -> eventl. koennte man den Namen des Branches mitgeben Signal an den Worker. Im entsprechenden Slot wird jetzt der eigentliche UpdateProzess angeworfen. 3: Mittels git fetch werden jetzt die Aenderungen ermittelt. GIT_FETCH_UPDATES_REQUEST GIT_FETCH_UPDATES_REQUEST_FAILURE -> Worker informieren damit Fehlerbehandlung aktiviert wird GIT_FETCH_UPDATES_REQUEST_SUCCESS GIT_DIFF_UPDATES Die Liste der geaenderten Dateien geht an den Worker. Der kann jetzt noch Test machen, ob das Sinn macht. Evtl. eine Statusmeldung ausgeben drueber was gleich passieren wird. 4: Mittels git merge/pull werden nun die Dateien tatsaechlich im Branch aktualisiert. GIT_PULL_UPDATES_REQUEST GIT_PULL_UPDATES_REQUEST_FAILURE -> Worker informieren damit Fehlerbehandlung aktiviert wird GIT_PULL_UPDATES_REQUEST_SUCCESS -> Worker informieren Sind die Daten vorhanden, dann werden sie mittels rsync ins Dateisystem kopiert. RSYNC_UPDATES RSYNC_UPDATES_FAILURE RSYNC_UPDATES_SUCCESS Fuer jede kopierte Datei geht eine Nachricht raus ans ISMAS. 5: Sind die Daten dann kopiert, so werden sie auf den DC kopiert (falls notwendig): hier gehen dann wieder Nachrichten an ISMAS raus: DC_UPDATE DC_UPDATE_FAILURE DC_UPDATE_SUCCESS JSON_UPDATE JSON_UPDATE_FAILURE JSON_UPDATE_SUCCESS Hier fuer jedes Json-File. Schliesslich noch eine Zusammenfasung an ISMAS: ISMAS_UPDATE_INFO_CONFIRM ISMAS_UPDATE_INFO_CONFIRM_FAILURE -> Worker informieren damit Fehlerbehandlung aktiviert wird ISMAS_UPDATE_INFO_CONFIRM_SUCCESS und schliesslich der abschliessende Status an ISMAS zurueckgemeldet: ISMAS_CURRENT_PSA_STATUS_CONFIRM ISMAS_CURRENT_PSA_STATUS_CONFIRM_FAILURE ISMAS_CURRENT_PSA_STATUS_CONFIRM_SUCCESS