Migrationsverfahren Neu ab S 39.5.0

Ab S 39.5.11

Allgemein

info Informationen

  • Ab Server S 39.5.0 gibt es ein neues, in PLANTA integriertes Migrationsverfahren, welches das bisherige Hotfix-Verfahren ersetzt.
    • Statt wie bisher SQL-Dateien außerhalb vom System in die Datenbank einzuspielen, gibt es nun ein in Python geschriebenes Framework, um die Updates durchzuführen.
    • Dies geschieht mit Hilfe von sogenannten Migrationspaketen. Diese führen Änderungen an der vorhandenen PLANTA-Installation, vor allem der Datenbank, durch.
    • Um die Migration zu starten, muss der Server im Migrationsmodus gestartet werden.
      • Der Server startet eine neue interne Session mit dem PLANTA-Benutzer MIGRATION. Daher haben alle neuen Datensätze bzw. Änderungen, die im Migrationsmodus an Customizing etc. durchgeführt/angelegt werden, den Änderungs-/Anlagebenutzer MIGRATION. Sie auch den Eintrag unter Achtung weiter unten.
    • Beim Starten der Migration werden alle Pflichtpakete automatisch ausgeführt. Alle weiteren Pakete müssen manuell ausgeführt werden. Hierzu siehe Hinweise unter Migrationsmodus.

Bis S 39.5.11

Allgemein

info Informationen
  • Ab Server S 39.5.0 gibt es ein neues, in PLANTA integriertes Migrationsverfahren, welches das bisherige Hotfix-Verfahren ersetzt.
    • Statt wie bisher SQL-Dateien außerhalb vom System in die Datenbank einzuspielen, gibt es nun ein in Python geschriebenes Framework, um die Updates durchzuführen.
    • Dies geschieht mit Hilfe von sogenannten Migrationspaketen. Diese führen Änderungen an der vorhandenen PLANTA-Installation, vor allem der Datenbank, durch.
    • Um die Migration zu starten, muss der Server im Migrationsmodus gestartet werden.
      • Der Server startet eine neue interne Session mit dem PLANTA-Benutzer MIGRATION. Daher haben alle neuen Datensätze bzw. Änderungen, die im Migrationsmodus an Customizing etc. durchgeführt/angelegt werden, den Änderungs-/Anlagebenutzer MIGRATION. Sie auch den Eintrag unter Achtung weiter unten.
    • Beim Starten der Migration werden alle Pflichtpakete automatisch ausgeführt. Alle weiteren Pakete müssen manuell ausgeführt werden. Hierzu siehe Hinweise unter Migrationsmodus.

stop Achtung

Ab S 39.5.18

  • NEU Werden der Benutzer MIGRATION und die ihm zugeordnete Person gelöscht, werden sie beim nächsten Update automatisch neu angelegt.

Ab S 39.5.15

  • NEU Wird der Benutzer MIGRATION gelöscht, wird es beim nächsten Update automatisch neu angelegt. Dies gilt jedoch nicht für die dem Benutzer Migration zugeordnete Person. Diese darf nicht gelöscht werden. Wird die Person gelöscht, kann die Migration nicht durchgeführt werden.

Bis S 39.5.15

  • Der Benutzer MIGRATION und die dem Benutzer zugeordnete Person dürfen nicht gelöscht werden! Werden sie gelöscht, kann die Migration nicht durchgeführt werden.

warning Hinweise

Ab DB 39.5.7

  • Um die Performance zu verbessern, wird für MSSQL-Systeme empfohlen, vor der Migration zu dem Recovery-Modell RECOVERY SIMPLE zu wechseln:
    ALTER DATABASE SET RECOVERY SIMPLE
    Nach erfolgter Migration sollte das Recovery-Modell wieder auf das ursprünglich eingestellte Modell zurückgesetzt werden. Dies ist das Standard-Modell der Datenbank
  • Welche Migrationspakete mit dem gewünschten Server-Release ausgeliefert werden, finden Sie unter Release Notes.
  • Wenn es Probleme gibt in der Art, dass vorhandene Python-Module nicht geladen werden können (z.B. im Migrationsskript 'FillMigrationRuleTable'), kann dies durch manuelles Ausführen des Pakets CreateFolderPacket im Modul Release-übergreifende Pakete behoben werden.

Bis DB 39.5.7

  • Welche Migrationspakete mit dem gewünschten Server-Release ausgeliefert werden, finden Sie unter Release Notes.
  • Wenn es Probleme gibt in der Art, dass vorhandene Python-Module nicht geladen werden können (z.B. im Migrationsskript 'FillMigrationRuleTable'), kann dies durch manuelles Ausführen des Pakets CreateFolderPacket in den Sonderfunktionen behoben werden.

Migrationsmodus

Ab S 39.5.12

info Informationen
  • Der Server besitzt einen neuen Modus für die Durchführung der Migration, den sogenannten Migrationsmodus.
    • Im Migrationsmodus werden die vorhandenen Migrationspakete, bei denen der Parameter Bei Systemstart = checked sowie Erledigt = unchecked sind, ausgeführt.
    • Während sich der Server im Migrationsmodus befindet, kann sich kein Client mit diesem Server verbinden.
    • Nach Durchführung der Migration beendet sich der Server automatisch.
  • NEU Die Migration wird durch Aufruf von planta_migration.bat bzw. ./planta_migration.sh im Server-Installationsverzeichnis gestartet.
    • Der Parameter migrate wird fortan ignoriert.

Bis S 39.5.12

info Informationen
  • Der Server besitzt einen neuen Modus für die Durchführung der Migration, den sogenannten Migrationsmodus.
    • Im Migrationsmodus werden die vorhandenen Migrationspakete, bei denen der Parameter Bei Systemstart = checked sowie Erledigt = unchecked sind, ausgeführt.
    • Während sich der Server im Migrationsmodus befindet, kann sich kein Client mit diesem Server verbinden.
    • Nach Durchführung der Migration beendet sich der Server automatisch.
  • Der Server kann auf zwei Arten in diesem Modus gestartet werden:
    1. Die planta_server.bat bzw. planta_server.sh wird mit dem Konsolenparameter -migrate true gestartet.
    2. Den migrate Parameter in der /config/globals.conf auf true setzen und den Server normal starten. Damit Arbeiten mit dem System möglich ist, muss der Server nach der Migration wieder im normalen Modus gestartet werden. Hierzu muss je nachdem, ob der Parameter als Konsolenparameter oder in der globals.conf gesetzt wurde, dieser auf false gesetzt und der Server neugestartet werden.
    • warning Da der Konsolenparameter defaultmässig auf false steht, kann dieser einfach weggelassen werden.

Ab S 39.5.17

warning Hinweise

Ab S 39.5.11

warning Hinweise

Ab DB 39.5.0

warning Hinweise

Bis DB 39.5.0

warning Hinweise

Technischer Ablauf

Ab S 39.5.17

info Was geschieht, wenn der Server im Migrationsmodus gestartet wird
  1. NEU Die Migrationsparameter müssen in einer Parameterdatei enthalten sein.
    • stop Die Parameterdatei sollte nur von erfahrenen Benutzern erstellt und angepasst werden.
    • Eine Beispielparameterdatei befindet sich unter config/migration/migration.par.
  2. NEU Das Script planta_nigration hat einen Pflicht-Parameter: -c / --migration-config.
    • Dieser Parameter muss der (vom Server-Verzeichnis relative) Pfad zur Migrationsparameterdatei sein.
    • warning Es dürfen keine Leerzeichen in diesem Pfad enthalten sein!
  3. NEU Um die Migration zu starten, muss das Script planta_migration im Server-Verzeichnis der erstellten Parameterdatei ausgeführt werden: planta_migration -c "Name des Parameter-Files"
    • stop Migrationsverfahren sollte nur von erfahrenen Benutzern gestartet werden.
  4. Der Server startet eine neue interne Session mit dem PLANTA-Benutzer Migration.
    • warning Daher haben alle neuen Datensätze bzw. Änderungen, die im Migrationsmodus an Customizing etc. durchgeführt/angelegt werden, den Änderungs-/Anlagebenutzer Migration.
    • stop Bitte beachten Sie, dass aus diesem Grund der Benutzer Migration nicht gelöscht werden darf.
  5. Es wird nach neuen Migrationspaketen auf dem Dateisystem gesucht, diese werden ausgeführt und Informationen darüber in der Datenbank abgespeichert.
  6. Nachdem das Dateisystem durchsucht wurde, werden die Pakete ausgeführt.

Bis S 39.5.17

info Was geschieht, wenn der Server im Migrationsmodus gestartet wird
  1. Der Server startet eine neue interne Session mit dem PLANTA-Benutzer Migration.
    • warning Daher haben alle neuen Datensätze bzw. Änderungen, die im Migrationsmodus an Customizing etc. durchgeführt/angelegt werden, den Änderungs-/Anlagebenutzer Migration.
    • stop Bitte beachten Sie, dass aus diesem Grund der Benutzer Migration nicht gelöscht werden darf.
  2. Die Datei start_migration.py aus dem Unterordner /py/planta_de/ppms/ des Server-Verzeichnisses wird ausgeführt.
  3. Die Klasse StartupRunner aus der Datei /py/ppms/migration/startup.py wird von start_migration.py initialisiert und die run() Methode aufgerufen.
  4. Es wird nach neuen Migrationspaketen auf dem Dateisystem gesucht, diese werden ausgeführt und Informationen darüber in der Datenbank abgespeichert.
  5. Nachdem das Dateisystem durchsucht wurde, werden die Pakete ausgeführt.

Ab S 39.5.17

Migrationsparameter

info Informationen

  • Die für die Migration erforderlichen Parameter werden in einer Parameterdatei angegeben.
  • Aufbau der Parameterdatei:
    --migration-components
       Server
       Customizing-Hotfix
       Customizing
       Customer
       Before DB Import
       After DB Import
    
    --abort-on-failure
       

Sektion Erklärung
migration-components Hier werden die Komponenten angegeben, die migriert werden sollen.
abort-on-failure Ist diese Option vorhanden, wird die Migration abgebrochen, sobald ein Migrationspaket fehlschlägt.
  • Die möglichen Komponenten stammen aus der __init__.py der jeweiligen Migrationsverzeichnisse
  • Die angegebenen Komponenten bestimmen den Update-Typ der Migration. So ist es z.B. möglich, nur das Customizing zu migrieren oder nur die Server-Komponente.
  • Die Parameterdatei gibt nicht nur die Komponenten vor, die migriert werden sollen, sondern auch die Reihenfolge, in der migriert wird.
  • Alle Pakete, die nicht unter die Liste der angegebenen Komponenten fallen, erhalten den Status LampeGrau.png Nicht relevant.

stop Achtung

  • In der Beispielparameterdatei unter config/migration/migration.par sind alle Komponenten aufgeführt, die theoretisch denkbar sind. Diese Komponenten müssen unbedingt vor der Migration an die tatsächlich vorliegenden Gegebenheiten angepasst und nicht relevante Komponenten entfernt werden.

Individualisierungsmöglichkeiten

info Information


index Siehe auch: Migrationspaket-Customizing, Update von 39.4 auf 39.5
Topic attachments
I Attachment Action Size Date Who Comment
pngpng LampeGrau.png manage 0.6 K 2015-07-11 - 02:24 ChristianePeter  





 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten