Migrationsverfahren Neu ab S 39.5.0

Ab S 39.5.11

Allgemein

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

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.

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.

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

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

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.
    • Da der Konsolenparameter defaultmässig auf false steht, kann dieser einfach weggelassen werden.

Ab S 39.5.17

Hinweise

Ab S 39.5.11

Hinweise

Ab DB 39.5.0

Hinweise

Bis DB 39.5.0

Hinweise

Technischer Ablauf

Ab S 39.5.17

Was geschieht, wenn der Server im Migrationsmodus gestartet wird
  1. NEU Die Migrationsparameter müssen in einer Parameterdatei enthalten sein.
    • 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.
    • 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"
    • Migrationsverfahren sollte nur von erfahrenen Benutzern gestartet werden.
  4. 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.
    • 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

Was geschieht, wenn der Server im Migrationsmodus gestartet wird
  1. 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.
    • 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

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.

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

Information


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  

web-bg-small 39.5 Venus Current DE

         PLANTA project









 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten