Server-Update von 39.4.4.0 auf S 39.5.x

warning Hinweis
  • Dieses Topic betrifft das Update des PLANTA-Servers von 39.4.4.0 auf S 39.5.x. Für das Update des PLANTA-Servers von S 39.5.x auf S 39.5.y wechseln Sie bitte zum Topic UpdateServer395.

Ab S 39.5.19

Allgemein

info Informationen
  • Das PLANTA-Server-Update von 39.4.4.0 auf S 39.5.x beinhaltet das Update des PLANTA-Servers inkl. der erforderlichen Anpassungen an der Datenbank mittels des neuen, in S 39.5.0 eingeführten Migrationsverfahrens.
warning Hinweise
  • Das Update beinhaltet keine Migration der fachlichen Daten. Bei Fragen hierzu wenden Sie sich bitte an Ihren PLANTA-Consultant.
  • Um den Aufwand für den Umstieg von 39.4.4.0 auf 39.5.x möglichst gering zu halten, wird ein möglichst früher Umstieg empfohlen.

Voraussetzungen

info Die folgenden Komponenten müssen auf dem Ziel-System installiert sein:

  • Java-Version (JDK / Server JRE) 1.7.x 64-bit NEU oder 1.8.x 64-bit (sonst kann der PLANTA-Server nicht gestartet werden)
    • Bei Verwendung von Server JRE sowie auf Linux-Systemen müssen zudem die folgenden Umgebungsvariablen gesetzt sein:
      • JAVA_HOME (z.B. /usr/java/jdk1.7.0_80)
      • CLASSPATH (z.B. /usr/java/jdk1.7.0_80/bin)
      • PATH (z.B. /usr/java/jdk1.7.0_80/bin:/usr/java/jdk1.7.0_80/jre/bin:$PATH)
    • Für Java JDK außerdem erforderlich:
      • JAVA_HOME (z.B. C:\java\jdk1.7.0_80)
    • In Linux-Systemen muss rsync vorhanden sein.
  • eine Oracle- oder MSSQL-Datenbank

warning Hinweise

  • Bei Verwendung von Server JRE (Java SE Runtime Environment) muss die Installation exakt nach Vorgabe von Oracle erfolgen.
  • Auch die im Topic Systemvoraussetzungen beschriebenen Voraussetzungen müssen erfüllt sein, z.B. die dort beschriebenen PLANTA Project-User-Rechte für die Oracle-Datenbank.
  • Der ausführende Benutzer muss fundierte Kenntnisse in den erforderlichen Fachbereichen aufweisen und als Administrator (Windows) bzw. root (Linux) am Server angemeldet sein.

Vorgehensweise beim Update

info Information

Schritt 1: Neues Release herunterladen

Die aktuellen Releases stehen Kunden im Kundenbereich des PLANTA-Transfer-Servers zum Download zur Verfügung.

more Vorgehensweise

  • Laden Sie das gewünschte Release, auf das Sie updaten möchten, herunter.
  • Das heruntergeladene ZIP-Archiv muss auf dem System abgelegt und entpackt werden, auf dem der PLANTA-Server installiert ist und upgedatet werden soll.

Schritt 2: Notwendige Schritte vor der Migration

Die aktuellen Releases stehen Kunden im Kundenbereich des PLANTA-Transfer-Servers zum Download zur Verfügung. Logon-Trigger erstellen (nur für Oracle) info Information
  • Überprüfen Sie bitte, ob es in Ihrer Oracle-Datenbank einen Trigger mit dem Namen ON_LOGON_PLANTA_<DB_USER> gibt.
  • Falls nicht, legen Sie bitte solch einen Trigger an:

CREATE OR REPLACE TRIGGER ON_LOGON_PLANTA_<DB_USER>
AFTER LOGON ON SCHEMA WHEN ( USER = 'DB_USER')
  BEGIN
  execute immediate('alter session set nls_date_format="DD.MM.RRRR"');
  EXCEPTION
  WHEN OTHERS THEN
  NULL;
  END; 

warning <DB_USER> ist durch den Namen des DB-Users zu ersetzen.

more Vorgehensweise

  • Laden Sie das gewünschte Release, auf das Sie updaten möchten, herunter.
  • Das heruntergeladene ZIP-Archiv muss auf dem System abgelegt und entpackt werden, auf dem der PLANTA-Server installiert ist und upgedatet werden soll.

Schritt 3: Installation des Servers

more Vorgehensweise
  • Den PLANTA-Server-Dienst des Systems, das Sie updaten möchten, beenden.
  • Starten Sie mit Hilfe des automatischen Installers das Update, wobei Sie für das Update auf 39.4 die Option "Migrieren von 39.5 mit DB 39.4 zu 39.5 mit DB 39.5" (GUI-Installation) bzw. voeToVenus (Konsoleninstallation) wählen.
    • Das Verzeichnis des bestehenden PLANTA-Servers darf nicht als Zielverzeichnis für den neuen Server angegeben werden. Wählen Sie stattdessen ein neues Verzeichnis für den Server und geben Sie das alte Verzeichnis als Bestehendes Server-Verzeichnis an.
    • Geben Sie mit Hilfe des Parameters Migration ausführen? an, ob beim Update des PLANTA-Servers die von PLANTA mitgelieferten Migrationspakete mit der Einstellung Bei Systemstart = checked automatisch ausgeführt werden sollen oder nicht. Welche Migrationspakete für das Update ausgeführt werden müssen, ermittelt das Migrationsverfahren aus Ihrem bestehenden System. Nachdem die Migrationspakete ausgeführt wurden, wird der PLANTA-Server-Dienst, der für das Ausführen der Migrationspakete gestartet wurde, wieder beendet.
      • warning Die Migrationspakete mit der Einstellung Bei Systemstart = checked können auch manuell durch Ausführen des Skripts planta_migration.bat bzw. planta_migration.sh ausgeführt werden.

stop Stopp

  • Stellen Sie sicher, dass die Datenbankverbindung dem vorhandenen System entspricht. Der Installer prüft momentan die Datenbankverbindung nicht, bevor er mit dem Update beginnt, das bedeutet, dass das Update fehlschlägt, wenn eine falsche Datenbankverbindung eingetragen ist, ohne, dass explizit darauf hingewiesen wird.
  • Im installierten Server-Verzeichnis finden sich unter /sql/migration/ im Ordner für die jeweilige Datenbank eine Anzahl von SQL-Files, die während der Installation automatisch ausgeführt werden. Diese Skripte dürfen nicht manuell (etwa in SqlPlus) ausgeführt werden!

warning Hinweise

  • Bei dem Update wird das Customizing automatisch auf 39.5 angehoben. Dies geschieht durch Ausführen von Migrationsskripten sowie durch Migrationspakete.
  • Nach der Serverinstallation sollen die Logfiles auf mögliche Fehler geprüft werden, bevor mit dem Schritt 3 (Bereitstellen der individuellen Python-Dateien) begonnen wird.

Schritt 4: Überprüfen der Migrationsergebnisse

more Vorgehensweise
  • Nach dem Starten des PLANTA-Server-Dienstes muss der Status der Migrationspakete, d.h. ob diese korrekt durchgelaufen sind, im Panel Migrationspakete geprüft werden.
    • Ist ein Paket nicht korrekt durchgelaufen, muss das Logfile des Migrationspakets geprüft und ggf. entsprechende Maßnahmen ergriffen werden. Weitere Informationen finden Sie im Topic Übersicht über alle bisherigen Läufe.
  • Zusätzlich können in diesem Modul Migrationspakete mit der Einstellung Bei Systemstart = unchecked manuell ausgeführt werden, die in Schritt 2 aufgrund ihrer Einstellung nicht automatisch ausgeführt wurden.
  • Wurden individuelle Pythondateien im Verzeichnis /py/api/ppms/wrapper/customer angelegt, muss das Migrationspaket CreateFolderPacket im Panel Migrationspakete aufgerufen und der PLANTA-Server-Dienst neugestartet werden, bevor die individuellen Pythondateien verfügbar sind.

Schritt 5: Notwendige Schritte nach der Migration

info Information
  • Nach der Migration müssen die folgenden Schritte durchgeführt werden.

Entfernen von builtins aus Python-Code

info Informationen
  • Durch die Veränderungen am PLANTA-Server dürfen __builtins__ nicht mehr verwendet werden, da Änderungen eines Benutzers in einer Session sofort alle Sessions anderer Benutzer betreffen!
  • Damit globale Variablen in Python jeder Session zur Verfügung stehen, ist es notwendig, alle Verweise auf __builtins__ und mögliche andere, globale Python-Konstrukte im Python-Code (sowohl in externen .py-Files, als auch in internen PLANTA-Modulen) durch ppms.get_session_dict() zu ersetzen. Diese Funktion stellt ein session-spezifisches Dictionary zur Verfügung, in dem dann globale Variablen gespeichert werden können, die nur dieser Session gelten.
  • stop Die Verwendung von eigenen __builtins__ wurde bereits ab 39.4.3.0 (Hotfix 8) als obsolet definiert, die Entfernung ist nun aber zwingend notwendig.
  • Das Migrationspaket FindBuiltinsUsagePacket findet die Verwendung von __builtins__. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixBuiltins korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

Entfernen von cmp(x, y) aus Python-Code

info Informationen

  • Die Funktion cmp(x, y) existiert ab Python-Version 3.1 nicht mehr. Da ab S 39.5.0 Python v3.2.2 verwendet wird, muss diese Funktion aus dem Python-Code entfernt werden.
  • Das Migrationspaket FindCmpUsagePacket zeigt die Verwendung der Funktion auf. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixCmpPacket korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

UUID-Spalten hinzufügen

info Information

  • Ab Release DB 39.5 muss jede Datenbanktabelle eine Spalte namens UUID vom Typ UUID besitzen. Diese Spalten dienen dazu, Datensätze eindeutig zu identifizieren. Standard-PLANTA-Tabellen besitzen dieses Feld bereits.

note Details

  • Sie müssen Ihren existierenden customer-spezifischen Tabellen diese Spalte hinzufügen. Führen Sie dazu bitte einmal das Migrationspaket CreateUUIDColumnsPacket aus, nachdem Sie alle Ihre Tabellen importiert haben. Danach sind Ihre Tabellen initialisiert und Ihre Datensätze besitzen gültige UUID-Werte.
warning Hinweis

Dateien aus Vorgänger-System übernehmen

info Informaion
  • Nach einem Update müssen die folgenden Dateien aus dem Vorgänger-System übernommen werden:
    • SAP dlls
    • Kerberos- und Stunnel-Konfigurationen

Ab S 39.5.18

Allgemein

info Informationen
  • Das PLANTA-Server-Update von 39.4.4.0 auf S 39.5.x beinhaltet das Update des PLANTA-Servers inkl. der erforderlichen Anpassungen an der Datenbank mittels des neuen, in S 39.5.0 eingeführten Migrationsverfahrens.
warning Hinweise
  • Das Update beinhaltet keine Migration der fachlichen Daten. Bei Fragen hierzu wenden Sie sich bitte an Ihren PLANTA-Consultant.
  • Um den Aufwand für den Umstieg von 39.4.4.0 auf 39.5.x möglichst gering zu halten, wird ein möglichst früher Umstieg empfohlen.

Voraussetzungen

info Die folgenden Komponenten müssen auf dem Ziel-System installiert sein:

  • NEU Java-Version (JDK / Server JRE) 1.7.x 64-bit (sonst kann der PLANTA-Server nicht gestartet werden)
    • Bei Verwendung von Server JRE sowie auf Linux-Systemen müssen zudem die folgenden Umgebungsvariablen gesetzt sein:
      • JAVA_HOME (z.B. /usr/java/jdk1.7.0_80)
      • CLASSPATH (z.B. /usr/java/jdk1.7.0_80/bin)
      • PATH (z.B. /usr/java/jdk1.7.0_80/bin:/usr/java/jdk1.7.0_80/jre/bin:$PATH)
    • Für Java JDK außerdem erforderlich:
      • JAVA_HOME (z.B. C:\java\jdk1.7.0_80)
      • JAVA_JAR (z.B. /usr/java/java_jar)
    • In Linux-Systemen muss rsync vorhanden sein.
  • eine Oracle- oder MSSQL-Datenbank

warning Hinweise

  • Bei Verwendung von Server JRE (Java SE Runtime Environment) muss die Installation exakt nach Vorgabe von Oracle erfolgen.
  • Auch die im Topic Systemvoraussetzungen beschriebenen Voraussetzungen müssen erfüllt sein, z.B. auch die dort beschriebenen PLANTA Project-User-Rechte für die Oracle-Datenbank.
  • Der ausführende Benutzer muss fundierte Kenntnisse in den erforderlichen Fachgebieten aufweisen sowie Administrator-Rechte besitzen (in Windows) bzw. als root-User konfiguriert sein (Linux).

Vorgehensweise beim Update

info Information

Schritt 1: Neues Release herunterladen

Die aktuellen Releases stehen Kunden im Kundenbereich des PLANTA-Transfer-Servers zum Download zur Verfügung.

more Vorgehensweise

  • Laden Sie das gewünschte Release, auf das Sie updaten möchten, herunter.
  • Das heruntergeladene ZIP-Archiv muss auf dem System abgelegt und entpackt werden, auf dem der PLANTA-Server installiert ist und upgedatet werden soll.

Schritt 2: Installation des Servers

more Vorgehensweise
  • Den PLANTA-Server-Dienst des Systems, das Sie updaten möchten, beenden.
  • Mit Hilfe des automatischen Installers das Update starten.
    • Das Verzeichnis des bestehenden PLANTA-Servers darf nicht als Zielverzeichnis für den neuen Server angegeben werden. Wählen Sie stattdessen ein neues Verzeichnis für den Server und geben Sie das alte Verzeichnis als Bestehendes Server-Verzeichnis an.
    • Geben Sie mit Hilfe des Parameters Migration ausführen? an, ob beim Update des PLANTA-Servers die von PLANTA mitgelieferten Migrationspakete mit der Einstellung Bei Systemstart = checked automatisch ausgeführt werden sollen oder nicht. Welche Migrationspakete für das Update ausgeführt werden müssen, ermittelt das Migrationsverfahren aus Ihrem bestehenden System. Nachdem die Migrationspakete ausgeführt wurden, wird der PLANTA-Server-Dienst, der für das Ausführen der Migrationspakete gestartet wurde, wieder beendet.
      • warning Die Migrationspakete mit der Einstellung Bei Systemstart = checked können auch manuell durch Ausführen des Skripts planta_migration.bat bzw. planta_migration.sh ausgeführt werden.

stop Stopp

  • Stellen Sie sicher, dass die Datenbankverbindung dem vorhandenen System entspricht. Der Installer prüft momentan die Datenbankverbindung nicht, bevor er mit dem Update beginnt, das bedeutet, dass das Update fehlschlägt, wenn eine falsche Datenbankverbindung eingetragen ist, ohne dass explizit darauf hingewiesen wird.
  • Im installierten Server-Verzeichnis finden sich unter /sql/migration/ im Ordner für die jeweilige Datenbank eine Anzahl von SQL-Files, die während der Installation automatisch ausgeführt werden. Diese Skripte dürfen nicht manuell (etwa in SqlPlus) ausgeführt werden!

warning Hinweise

  • Bei dem Update wird das Customizing automatisch auf 39.4 angehoben. Dies geschieht durch Ausführen von Migrationsskripten sowie durch Migrationspakete.
  • Nach der Serverinstallation sollen die Logfiles auf mögliche Fehler geprüft werden, bevor mit dem Schritt 3 (Bereitstellen der individuellen Python-Dateien) begonnen wird.

Schritt 3: Bereitstellen der individuellen Python-Dateien

info Information
  • Im Server-Verzeichnis findet sich unter dem Ordner /py/ nun die neue Ordnerstruktur von 39.5.

more Vorgehensweise

  • NEU Dateien, die im bestehenden System mit Release 39.4 durch einen Customizer angepasst wurden, müssen nun in den Unterordner /py/api/ppms/wrapper/customer verschoben werden.

Schritt 4: Starten des Server-Dienstes

more Vorgehensweise
  • Um den PLANTA-Server-Dienst zu starten, führen Sie entweder die Datei yajsw\bat\startService.bat (Windows) oder yajsw\bat\startDaemon.sh (Linux) aus.

Schritt 5: Überprüfen der Migrationsergebnisse

more Vorgehensweise
  • Nach dem Starten des PLANTA-Server-Dienstes muss der Status der Migrationspakete, d.h. ob diese korrekt durchgelaufen sind, im Panel Migrationspakete geprüft werden.
    • Ist ein Paket nicht korrekt durchgelaufen, muss das Logfile des Migrationspakets geprüft und ggf. entsprechende Maßnahmen ergriffen werden. Weitere Informationen finden Sie im Topic Übersicht über alle bisherigen Läufe.
  • Zusätzlich können in diesem Modul Migrationspakete mit der Einstellung Bei Systemstart = unchecked manuell ausgeführt werden, die in Schritt 2 aufgrund ihrer Einstellung nicht automatisch ausgeführt wurden.
  • NEU Wurden individuelle Pythondateien im Verzeichnis /py/api/ppms/wrapper/customer angelegt, muss das Migrationspaket CreateFolderPacket im Panel Migrationspakete aufgerufen und der PLANTA-Server-Dienst neugestartet werden, bevor die individuellen Pythondateien verfügbar sind.

Schritt 6: Notwendige Schritte nach der Migration

info Information
  • Nach der Migration müssen die folgenden Schritte durchgeführt werden.

Entfernen von builtins aus Python-Code

info Informationen
  • Durch die Veränderungen am PLANTA-Server dürfen __builtins__ nicht mehr verwendet werden, da Änderungen eines Benutzers in einer Session sofort alle Sessions anderer Benutzer betreffen!
  • Damit globale Variablen in Python jeder Session zur Verfügung stehen, ist es notwendig, alle Verweise auf __builtins__ und mögliche andere, globale Python-Konstrukte im Python-Code (sowohl in externen .py-Files, als auch in internen PLANTA-Modulen) durch ppms.get_session_dict() zu ersetzen. Diese Funktion stellt ein session-spezifisches Dictionary zur Verfügung, in dem dann globale Variablen gespeichert werden können, die nur dieser Session gelten.
  • stop Die Verwendung von eigenen __builtins__ wurde bereits ab 39.4.3.0 (Hotfix 8) als obsolet definiert, die Entfernung ist nun aber zwingend notwendig.
  • Das Migrationspaket FindBuiltinsUsagePacket findet die Verwendung von __builtins__. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixBuiltins korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

Entfernen von cmp(x, y) aus Python-Code

info Informationen

  • Die Funktion cmp(x, y) existiert ab Python-Version 3.1 nicht mehr. Da ab S 39.5.0 Python v3.2.2 verwendet wird, muss diese Funktion aus dem Python-Code entfernt werden.
  • Das Migrationspaket FindCmpUsagePacket zeigt die Verwendung der Funktion auf. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixCmpPacket korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

UUID-Spalten hinzufügen

info Information

  • Ab Release DB 39.5 muss jede Datenbanktabelle eine Spalte namens UUID vom Typ UUID besitzen. Diese Spalten dienen dazu, Datensätze eindeutig zu identifizieren. Standard-PLANTA-Tabellen besitzen dieses Feld bereits.

note Details

  • Sie müssen Ihren existierenden customer-spezifischen Tabellen diese Spalte hinzufügen. Führen Sie dazu bitte einmal das Migrationspaket CreateUUIDColumnsPacket aus, nachdem Sie alle Ihre Tabellen importiert haben. Danach sind Ihre Tabellen initialisiert und Ihre Datensätze besitzen gültige UUID-Werte.
warning Hinweis

Dateien aus Vorgänger-System übernehmen

Nach einem Update müssen die folgenden Dateien aus dem Vorgänger-System übernommen werden:
  • SAP dlls
  • Kerberos- und Stunnel-Konfigurationen

Ab S 39.5.12

Allgemein

info Informationen
  • Das PLANTA-Server-Update von 39.4.4.0 auf S 39.5.x beinhaltet das Update des PLANTA-Servers inkl. der erforderlichen Anpassungen an der Datenbank mittels des neuen, in S 39.5.0 eingeführten Migrationsverfahrens.
warning Hinweise
  • Das Update beinhaltet keine Migration der fachlichen Daten. Bei Fragen hierzu wenden Sie sich bitte an Ihren PLANTA-Consultant.
  • Um den Aufwand für den Umstieg von 39.4.4.0 auf 39.5.x möglichst gering zu halten, wird ein möglichst früher Umstieg empfohlen.

Voraussetzungen

note Die folgenden Komponenten müssen auf dem Ziel-System installiert sein:

  • Java Version (JDK) 1.7.x 64-bit (sonst kann der PLANTA-Server nicht gestartet werden)
    • Auf Linux-Systemen müssen zudem die folgenden Umgebungsvariablen gesetzt sein:
      • JAVA_HOME (z.B. /usr/java/jdk1.7.0_21)
      • CLASSPATH (z.B. /usr/java/jdk1.7.0_21/bin)
      • PATH (z.B. /usr/java/jdk1.7.0_21/bin:/usr/java/jdk1.7.0_21/jre/bin:$PATH)
    • Für Java JDK außerdem erforderlich:
      • JRE_HOME (z.B. /usr/java/jdk1.7.0_21/jre)
      • JAVA_JAR (z.B. /usr/java/java_jar)
  • eine Oracle- oder MSSQL-Datenbank

warning Hinweise

  • Die im Topic Systemvoraussetzungen beschriebenen Voraussetzungen müssen erfüllt sein, z.B. auch die dort beschriebenen PLANTA Project-User-Rechte für die Oracle-Datenbank.
  • Der ausführende Benutzer muss fundierte Kenntnisse in den erforderlichen Fachgebieten aufweisen sowie Administrator-Rechte besitzen (in Windows) bzw. als root-User konfiguriert sein (Linux).

Vorgehensweise beim Update

info Information

Schritt 1: Neues Release herunterladen

Die aktuellen Releases stehen Kunden im Kundenbereich des PLANTA-Transfer-Servers zum Download zur Verfügung.

more Vorgehensweise

  • Laden Sie das gewünschte Release, auf das Sie updaten möchten, herunter.
  • Das heruntergeladene ZIP-Archiv muss auf dem System abgelegt und entpackt werden, auf dem der PLANTA-Server installiert ist und upgedatet werden soll.

Schritt 2: Installation des Servers

more Vorgehensweise
  • Den PLANTA-Server-Dienst des Systems, das Sie updaten möchten, beenden.
  • Mit Hilfe des automatischen Installers das Update starten.
    • Das Verzeichnis des bestehenden PLANTA-Servers (39.4) darf nicht als Zielverzeichnis für den neuen Server angegeben werden.

stop Stopp

  • Stellen Sie sicher, dass die Datenbankverbindung dem vorhandenen System entspricht. Der Installer prüft momentan die Datenbankverbindung nicht, bevor er mit dem Update beginnt, das bedeutet, dass das Update fehlschlägt, wenn eine falsche Datenbankverbindung eingetragen ist, ohne dass explizit darauf hingewiesen wird.
  • Im installierten Server-Verzeichnis finden sich unter /sql/migration/ im Ordner für die jeweilige Datenbank eine Anzahl von SQL-Files, die während der Installation automatisch ausgeführt werden. Diese Skripte dürfen nicht manuell (etwa in SqlPlus) ausgeführt werden!

warning Hinweise

  • Bei dem Update wird das Customizing automatisch auf 39.4 angehoben. Dies geschieht durch Ausführen von Migrationsskripten sowie durch Migrationspakete.
  • Nach der Serverinstallation sollen die Logfiles auf mögliche Fehler geprüft werden, bevor mit dem Schritt 3 (Bereitstellen der individuellen Python-Dateien) begonnen wird.

Schritt 3: Durchführen der Migration

more Vorgehensweise
  • Um den PLANTA-Server-Dienst zu starten, führen Sie entweder die Datei yajsw\bat\startService.bat (Windows) oder yajsw\bat\startDaemon.sh (Linux) aus.
    • Nun werden die von PLANTA mitgelieferten Migrationspakete mit der Einstellung Bei Systemstart = checked automatisch ausgeführt. Welche Migrationspakete für die entsprechende Server-Version ausgeführt werden, finden Sie hier.
    • Sie können durch Aufrufen von yajsw\bat\queryService.bat oder yajsw\bat\queryDaemon.sh abfragen, ob der Migrationslauf beendet wurde. Dies ist der Fall, wenn die Eigenschaft Running = false.
  • Nachdem der Server alle Pakete ausgeführt hat, wird der PLANTA-Server-Dienst automatisch beendet. Navigieren Sie anschließend in das Verzeichnis /config/. In der Datei globals.conf muss der Parameter migrate von true auf false geändert werden. Damit wird der Server vom Migrationsmodus wieder in den normalen Zustand versetzt.

Schritt 3: Bereitstellen der individuellen Python-Dateien

info Information
  • Im Server-Verzeichnis findet sich unter dem Ordner /py/ nun die neue Ordnerstruktur von 39.5.

more Vorgehensweise

  • Dateien, die im bestehenden System mit Release 39.4 durch einen Customizer angepasst wurden, müssen nun in den Unterordner /py/customer/ verschoben werden.

Schritt 4: Starten des Server-Dienstes

more Vorgehensweise
  • Um den PLANTA-Server-Dienst zu starten, führen Sie entweder die Datei yajsw\bat\startService.bat (Windows) oder yajsw\bat\startDaemon.sh (Linux) aus.

Schritt 5: Überprüfen der Migrationsergebnisse

more Vorgehensweise
  • Nach dem Starten des Servers muss der Status der Migrationspakete, d.h. ob diese korrekt durchgelaufen sind, im Panel Migrationspakete geprüft werden.
    • Ist ein Paket nicht korrekt durchgelaufen, muss das Logfile des Migrationspakets geprüft und ggf. entsprechende Maßnahmen ergriffen werden. Weitere Informationen finden Sie im Topic Übersicht über alle bisherigen Läufe.
  • Zusätzlich können in diesem Modul Pakete, die in Schritt 2 nicht ausgeführt wurden, d.h. Migrationspakete mit der Einstellung Bei Systemstart = unchecked, ausgeführt werden.
  • Wurden individuelle Pythondateien im /py/customer/ Ordner angelegt, muss das Migrationspaket CreateFolderPacket im Panel Migrationspakete] aufgerufen und der PLANTA-Server-Dienst neugestartet werden, bevor diese verfügbar sind.

Schritt 6: Notwendige Schritte nach der Migration

info Information
  • Nach der Migration müssen die folgenden Schritte durchgeführt werden.

Entfernen von builtins aus Python-Code

info Informationen
  • Durch die Veränderungen am PLANTA-Server dürfen __builtins__ nicht mehr verwendet werden, da Änderungen eines Benutzers in einer Session sofort alle Sessions anderer Benutzer betreffen!
  • Damit globale Variablen in Python jeder Session zur Verfügung stehen, ist es notwendig, alle Verweise auf __builtins__ und mögliche andere, globale Python-Konstrukte im Python-Code (sowohl in externen .py-Files, als auch in internen PLANTA-Modulen) durch ppms.get_session_dict() zu ersetzen. Diese Funktion stellt ein session-spezifisches Dictionary zur Verfügung, in dem dann globale Variablen gespeichert werden können, die nur dieser Session gelten.
  • stop Die Verwendung von eigenen __builtins__ wurde bereits ab 39.4.3.0 (Hotfix 8) als obsolet definiert, die Entfernung ist nun aber zwingend notwendig.
  • Das Migrationspaket FindBuiltinsUsagePacket findet die Verwendung von __builtins__. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixBuiltins korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

Entfernen von cmp(x, y) aus Python-Code

info Informationen

  • Die Funktion cmp(x, y) existiert ab Python-Version 3.1 nicht mehr. Da ab S 39.5.0 Python v3.2.2 verwendet wird, muss diese Funktion aus dem Python-Code entfernt werden.
  • Das Migrationspaket FindCmpUsagePacket zeigt die Verwendung der Funktion auf. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixCmpPacket korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket ebenfalls fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

UUID-Spalten hinzufügen

info Information

  • Ab Release DB 39.5 muss jede Datenbanktabelle eine Spalte namens UUID vom Typ UUID besitzen. Diese Spalten dienen dazu, Datensätze eindeutig zu identifizieren. Standard-PLANTA-Tabellen besitzen dieses Feld bereits.

note Details

  • Sie müssen Ihren existierenden customer-spezifischen Tabellen diese Spalte hinzufügen. Führen Sie dazu bitte einmal das Migrationspaket CreateUUIDColumnsPacket aus, nachdem Sie alle Ihre Tabellen importiert haben. Danach sind Ihre Tabellen initialisiert und Ihre Datensätze besitzen gültige UUID-Werte.
warning Hinweis

Dateien aus Vorgänger-System übernehmen

Nach einem Update müssen die folgenden Dateien aus dem Vorgänger-System übernommen werden:
  • SAP dlls
  • Kerberos- und Stunnel-Konfigurationen

Ab DB 39.5.0

Allgemein

info Informationen
  • Das PLANTA-Server-Update von 39.4.4.0 auf S 39.5.x beinhaltet das Update des PLANTA-Servers inkl. der erforderlichen Anpassungen an der Datenbank mittels des neuen, in S 39.5.0 eingeführten Migrationsverfahrens.
warning Hinweise
  • Das Update beinhaltet keine Migration der fachlichen Daten. Bei Fragen hierzu wenden Sie sich bitte an Ihren PLANTA-Consultant.
  • Um den Aufwand für den Umstieg von 39.4.4.0 auf 39.5.x möglichst gering zu halten, wird ein möglichst früher Umstieg empfohlen.

Voraussetzungen

note Die folgenden Komponenten müssen auf dem Ziel-System installiert sein:

  • Java Version (JDK) 1.6.x 64-bit (sonst kann der PLANTA-Server nicht gestartet werden)
    • Auf Linux-Systemen müssen zudem die folgenden Umgebungsvariablen gesetzt sein:
      • JAVA_HOME (z.B. /usr/java/jdk1.6.0_21)
      • CLASSPATH (z.B. /usr/java/jdk1.6.0_21/bin)
      • PATH (z.B. /usr/java/jdk1.6.0_21/bin:/usr/java/jdk1.6.0_21/jre/bin:$PATH)
    • Für Java JDK außerdem erforderlich:
      • JRE_HOME (z.B. /usr/java/jdk1.6.0_21/jre)
      • JAVA_JAR (z.B. /usr/java/java_jar)
  • eine Oracle- oder MSSQL-Datenbank

warning Hinweis

  • Für den reibungslosen Ablauf der Installation muss der ausführende Benutzer Administrator-Rechte besitzen (in Windows) bzw. als root-User konfiguriert sein (Linux).

Vorgehensweise beim Update

info Information

Schritt 1: Neues Release herunterladen

Die aktuellen Releases stehen Kunden im Kundenbereich des PLANTA-Transfer-Servers zum Download zur Verfügung.

more Vorgehensweise

  • Laden Sie das gewünschte Release, auf das Sie updaten möchten, herunter.
  • Das heruntergeladene ZIP-Archiv muss auf dem System abgelegt und entpackt werden, auf dem der PLANTA-Server installiert ist und upgedatet werden soll.

Schritt 2: Installation des Servers

more Vorgehensweise
  • Den PLANTA-Server-Dienst des Systems, das Sie updaten möchten, beenden.
  • Mit Hilfe des automatischen Installers das Update starten.
    • Das Verzeichnis des bestehenden PLANTA-Servers (39.4) darf nicht als Zielverzeichnis für den neuen Server angegeben werden.

stop Stopp

  • Stellen Sie sicher, dass die Datenbankverbindung dem vorhandenen System entspricht. Der Installer prüft momentan die Datenbankverbindung nicht, bevor er mit dem Update beginnt, das bedeutet, dass das Update fehlschlägt, wenn eine falsche Datenbankverbindung eingetragen ist, ohne dass explizit darauf hingewiesen wird.
  • Im installierten Server-Verzeichnis finden sich unter /sql/migration/ im Ordner für die jeweilige Datenbank eine Anzahl von SQL-Files, die während der Installation automatisch ausgeführt werden. Diese Skripte dürfen nicht manuell (etwa in SqlPlus) ausgeführt werden!

warning Hinweise

  • Der Installer richtet den Server im Migrationsmodus ein.
  • Nach der Serverinstallation sollen die Logfiles auf mögliche Fehler geprüft werden, bevor mit dem Schritt 3 (Durchführen der Migration) begonnen wird.

Schritt 3: Durchführen der Migration

more Vorgehensweise
  • Um den PLANTA-Server-Dienst zu starten, führen Sie entweder die Datei yajsw\bat\startService.bat (Windows) oder yajsw\bat\startDaemon.sh (Linux) aus.
    • Nun werden die von PLANTA mitgelieferten Migrationspakete mit der Einstellung Bei Systemstart = checked automatisch ausgeführt. Welche Migrationspakete für die entsprechende Server-Version ausgeführt werden, finden Sie hier.
    • Sie können durch Aufrufen von yajsw\bat\queryService.bat oder yajsw\bat\queryDaemon.sh abfragen, ob der Migrationslauf beendet wurde. Dies ist der Fall, wenn die Eigenschaft Running = false.
  • Nachdem der Server alle Pakete ausgeführt hat, wird der PLANTA-Server-Dienst automatisch beendet. Navigieren Sie anschließend in das Verzeichnis /config/. In der Datei globals.conf muss der Parameter migrate von true auf false geändert werden. Damit wird der Server vom Migrationsmodus wieder in den normalen Zustand versetzt.

Schritt 4: Bereitstellen der individuellen Python-Dateien

info Information
  • Im Server-Verzeichnis findet sich unter dem Ordner /py/ nun die neue Ordnerstruktur von 39.5.

more Vorgehensweise

  • Dateien, die im bestehenden System mit Release 39.4 durch einen Customizer angepasst wurden, müssen nun in den Unterordner /py/customer/ verschoben werden.

Schritt 5: Starten des Server-Dienstes

more Vorgehensweise
  • Um den PLANTA-Server-Dienst zu starten, führen Sie entweder die Datei yajsw\bat\startService.bat (Windows) oder yajsw\bat\startDaemon.sh (Linux) aus.

Schritt 6: Überprüfen der Migrationsergebnisse

more Vorgehensweise
  • Nach dem Starten des Servers muss der Status der Migrationspakete, d.h. ob diese korrekt durchgelaufen sind, im Modul Migrationspakete geprüft werden.
    • Ist ein Paket nicht korrekt durchgelaufen, muss das Logfile des Migrationspakets geprüft und ggf. entsprechende Maßnahmen ergriffen werden. Weitere Informationen finden Sie hier.
  • Zusätzlich können in diesem Modul Pakete, die in Schritt 2 nicht ausgeführt wurden, d.h. Migrationspakete mit der Einstellung Bei Systemstart = unchecked, ausgeführt werden.
  • Wurden individuelle Pythondateien im /py/customer/ Ordner angelegt, muss das Migrationspaket CreateFolderPacket im Modul Migrationspakete aufgerufen und der Server-Dienst neugestartet werden, bevor diese verfügbar sind.

Schritt 7: Notwendige Schritte nach der Migration

info Information
  • Nach der Migration müssen die folgenden Schritte durchgeführt werden.

Entfernen von builtins aus Python-Code

  • Durch die Veränderungen am PLANTA-Server dürfen __builtins__ nicht mehr verwendet werden, da Änderungen eines Benutzers in einer Session sofort alle Sessions anderer Benutzer betreffen!
  • Damit globale Variablen in Python jeder Session zur Verfügung stehen, ist es notwendig, alle Verweise auf __builtins__ und mögliche andere, globale Python-Konstrukte im Python-Code (sowohl in externen .py-Files, als auch in internen PLANTA-Modulen) durch ppms.get_session_dict() zu ersetzen. Diese Funktion stellt ein session-spezifisches Dictionary zur Verfügung, in dem dann globale Variablen gespeichert werden können, die nur dieser Session gelten.
  • stop Die Verwendung von eigenen __builtins__ wurde bereits ab 39.4.3.0 (Hotfix 8) als obsolet definiert, die Entfernung ist nun aber zwingend notwendig.
  • Das Migrationspaket FindBuiltinsUsagePacket findet die Verwendung von __builtins__. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixBuiltins korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

Entfernen von cmp(x, y) aus Python-Code

info Informationen

  • Die Funktion cmp(x, y) existiert ab Python-Version 3.1 nicht mehr. Da ab S 39.5.0 Python v3.2.2 verwendet wird, muss diese Funktion aus dem Python-Code entfernt werden.
  • Das Migrationspaket FindCmpUsagePacket zeigt die Verwendung der Funktion auf. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixCmpPacket korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket ebenfalls fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

UUID-Spalten hinzufügen NewNEU" />

info Information

  • Ab Release DB 39.5 muss jede Datenbanktabelle eine Spalte namens UUID vom Typ UUID besitzen. Diese Spalten dienen dazu, Datensätze eindeutig zu identifizieren. Standard-PLANTA-Tabellen besitzen dieses Feld bereits.

note Details

  • Sie müssen Ihren existierenden customer-spezifischen Tabellen diese Spalte hinzufügen. Führen Sie dazu bitte einmal das Migrationspaket CreateUUIDColumnsPacket aus, nachdem Sie alle Ihre Tabellen importiert haben. Danach sind Ihre Tabellen initialisiert und Ihre Datensätze besitzen gültige UUID-Werte.
warning Hinweis

Dateien aus Vorgänger-System übernehmen

Nach einem Update müssen die folgenden Dateien aus dem Vorgänger-System übernommen werden:
  • SAP dlls
  • Kerberos- und Stunnel-Konfigurationen

Ab S 39.5.1

Allgemein

info Informationen
  • Das PLANTA-Server-Update von 39.4.4.0 auf S 39.5.x beinhaltet das Update des PLANTA-Servers inkl. der erforderlichen Anpassungen an der Datenbank mittels des neuen, in S 39.5.0 eingeführten Migrationsverfahrens.
warning Hinweise
  • Das Update beinhaltet keine Migration der fachlichen Daten. Bei Fragen hierzu wenden Sie sich bitte an Ihren PLANTA-Consultant.
  • Um den Aufwand für den Umstieg von 39.4.4.0 auf 39.5.x möglichst gering zu halten, wird ein möglichst früher Umstieg empfohlen.

Voraussetzungen

note Die folgenden Komponenten müssen auf dem Ziel-System installiert sein:

  • Java Version (JDK) 1.6.x 64-bit (sonst kann der PLANTA-Server nicht gestartet werden)
    • Auf Linux-Systemen müssen zudem die folgenden Umgebungsvariablen gesetzt sein:
      • JAVA_HOME (z.B. /usr/java/jdk1.6.0_21)
      • CLASSPATH (z.B. /usr/java/jdk1.6.0_21/bin)
      • PATH (z.B. /usr/java/jdk1.6.0_21/bin:/usr/java/jdk1.6.0_21/jre/bin:$PATH)
    • Für Java JDK außerdem erforderlich:
      • JRE_HOME (z.B. /usr/java/jdk1.6.0_21/jre)
      • JAVA_JAR (z.B. /usr/java/java_jar)
  • eine Oracle- oder MSSQL-Datenbank

warning Hinweis

  • Für den reibungslosen Ablauf der Installation muss der ausführende Benutzer Administrator-Rechte besitzen (in Windows) bzw. als root-User konfiguriert sein (Linux).

Vorgehensweise beim Update

info Information

Schritt 1: Neues Release herunterladen

Die aktuellen Releases stehen Kunden im Kundenbereich des PLANTA-Transfer-Servers zum Download zur Verfügung.

more Vorgehensweise

  • Laden Sie das gewünschte Release, auf das Sie updaten möchten, herunter.
  • Das heruntergeladene ZIP-Archiv muss auf dem System abgelegt und entpackt werden, auf dem der PLANTA-Server installiert ist und upgedatet werden soll.

Schritt 2: Installation des Servers

more Vorgehensweise
  • Den PLANTA-Server-Dienst des Systems, das Sie updaten möchten, beenden.
  • Mit Hilfe des automatischen Installers das Update starten.
    • Das Verzeichnis des bestehenden PLANTA-Servers (39.4) darf nicht als Zielverzeichnis für den neuen Server angegeben werden.

stop Stopp

  • Stellen Sie sicher, dass die Datenbankverbindung dem vorhandenen System entspricht. Der Installer prüft momentan die Datenbankverbindung nicht, bevor er mit dem Update beginnt, das bedeutet, dass das Update fehlschlägt, wenn eine falsche Datenbankverbindung eingetragen ist, ohne dass explizit darauf hingewiesen wird.
  • Im installierten Server-Verzeichnis finden sich unter /sql/migration/ im Ordner für die jeweilige Datenbank eine Anzahl von SQL-Files, die während der Installation automatisch ausgeführt werden. Diese Skripte dürfen nicht manuell (etwa in SqlPlus) ausgeführt werden!

warning Hinweise

  • Der Installer richtet den Server im Migrationsmodus ein.
  • Nach der Serverinstallation sollen die Logfiles auf mögliche Fehler geprüft werden, bevor mit dem Schritt 3 (Durchführen der Migration) begonnen wird.

Schritt 3: Vorbereitung der Datenbank

more Vorgehensweise
  • Im Verzeichnis des installierten Servers befinden sich im Pfad /sql/migration/ im Verzeichnis für die jeweilige Datenbank drei SQL-Dateien, die in der angegebenen Reihenfolge in der Datenbank für den entsprechenden Datenbankbenutzer ausgeführt werden müssen.
  • Für Oracle:
    • 1_EarthToVenus.minimal.Q1B_Q2B.Oracle.diff.sql
    • !2_EarthToVenus.history_objects.Oracle.diff.sql
    • !3_EarthToVenus.MissingDTEntries.Oracle.sql
  • Für MSSQL:
    • !1_EarthToVenus.minimal.Q1B&Q2B.MSSQL.diff.sql
    • !2_EarthToVenus.history_objects.MSSQL.diff.sql
    • !3_EarthToVenus.MissingDTEntries.MSSQL.sql

Schritt 3: Durchführen der Migration

more Vorgehensweise
  • Um den PLANTA-Server-Dienst zu starten, führen Sie entweder die Datei yajsw\bat\startService.bat (Windows) oder yajsw\bat\startDaemon.sh (Linux) aus.
    • Nun werden die von PLANTA mitgelieferten Migrationspakete mit der Einstellung Bei Systemstart = checked automatisch ausgeführt. Welche Migrationspakete für die entsprechende Server-Version ausgeführt werden, finden Sie hier.
    • Sie können durch Aufrufen von yajsw\bat\queryService.bat oder yajsw\bat\queryDaemon.sh abfragen, ob der Migrationslauf beendet wurde. Dies ist der Fall, wenn die Eigenschaft Running = false.
  • Nachdem der Server alle Pakete ausgeführt hat, wird der PLANTA-Server-Dienst automatisch beendet. Navigieren Sie anschließend in das Verzeichnis /config/. In der Datei globals.conf muss der Parameter migrate von true auf false geändert werden. Damit wird der Server vom Migrationsmodus wieder in den normalen Zustand versetzt.

Schritt 4: Bereitstellen der individuellen Python-Dateien

info Information
  • Im Server-Verzeichnis findet sich unter dem Ordner /py/ nun die neue Ordnerstruktur von 39.5.

more Vorgehensweise

  • Dateien, die im bestehenden System mit Release 39.4 durch einen Customizer angepasst wurden, müssen nun in den Unterordner /py/customer/ verschoben werden.

Schritt 5: Starten des Server-Dienstes

more Vorgehensweise
  • Um den PLANTA-Server-Dienst zu starten, führen Sie entweder die Datei yajsw\bat\startService.bat (Windows) oder yajsw\bat\startDaemon.sh (Linux) aus.

Schritt 6: Überprüfen der Migrationsergebnisse

more Vorgehensweise
  • Nach dem Starten des Servers muss der Status der Migrationspakete, d.h. ob diese korrekt durchgelaufen sind, im Modul Übersicht der Migrationspakete geprüft werden.
    • Ist ein Paket nicht korrekt durchgelaufen, muss das Logfile des Migrationspakets geprüft und ggf. entsprechende Maßnahmen ergriffen werden. Weitere Informationen finden Sie hier.
  • Zusätzlich können in diesem Modul Pakete, die in Schritt 2 nicht ausgeführt wurden, d.h. Migrationspakete mit der Einstellung Bei Systemstart = unchecked, ausgeführt werden.
  • Wurden individuelle Pythondateien im /py/customer/ Ordner angelegt, muss das Migrationspaket CreateFolderPacket im Modul Übersicht der Migrationspakete aufgerufen und der Server-Dienst neugestartet werden, bevor diese verfügbar sind.

Schritt 7: Notwendige Schritte nach der Migration

info Information
  • Nach der Migration müssen die folgenden Schritte durchgeführt werden.

Entfernen von builtins aus Python-Code

  • Durch die Veränderungen am PLANTA-Server dürfen __builtins__ nicht mehr verwendet werden, da Änderungen eines Benutzers in einer Session sofort alle Sessions anderer Benutzer betreffen!
  • Damit globale Variablen in Python jeder Session zur Verfügung stehen, ist es notwendig, alle Verweise auf __builtins__ und mögliche andere, globale Python-Konstrukte im Python-Code (sowohl in externen .py-Files, als auch in internen PLANTA-Modulen) durch ppms.get_session_dict() zu ersetzen. Diese Funktion stellt ein session-spezifisches Dictionary zur Verfügung, in dem dann globale Variablen gespeichert werden können, die nur dieser Session gelten.
  • stop Die Verwendung von eigenen __builtins__ wurde bereits ab 39.4.3.0 (Hotfix 8) als obsolet definiert, die Entfernung ist nun aber zwingend notwendig.
  • Das Migrationspaket FindBuiltinsUsagePacket findet die Verwendung von __builtins__. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixBuiltins korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

Entfernen von cmp(x, y) aus Python-Code

info Informationen

  • Die Funktion cmp(x, y) existiert ab Python-Version 3.1 nicht mehr. Da ab S 39.5.0 Python v3.2.2 verwendet wird, muss diese Funktion aus dem Python-Code entfernt werden.
  • Das Migrationspaket FindCmpUsagePacket zeigt die Verwendung der Funktion auf. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixCmpPacket korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket ebenfalls fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

Dateien aus Vorgänger-System übernehmen

Nach einem Update müssen die folgenden Dateien aus dem Vorgänger-System übernommen werden:
  • SAP dlls
  • Kerberos- und Stunnel-Konfigurationen

Neu ab S 39.5.0

Allgemein

info Informationen
  • Das PLANTA-Server-Update von 39.4.4.0 auf S 39.5.x beinhaltet das Update des PLANTA-Servers inkl. der erforderlichen Anpassungen an der Datenbank mittels des neuen, in S 39.5.0 eingeführten Migrationsverfahrens.
warning Hinweise
  • Das Update beinhaltet keine Migration der fachlichen Daten. Bei Fragen hierzu wenden Sie sich bitte an Ihren PLANTA-Consultant.
  • Um den Aufwand für den Umstieg von 39.4.4.0 auf 39.5.x möglichst gering zu halten, wird ein möglichst früher Umstieg empfohlen.

Voraussetzungen

note Die folgenden Komponenten müssen auf dem Ziel-System installiert sein:

  • Java Version (JDK) 1.6.x 64-bit (sonst kann der PLANTA-Server nicht gestartet werden)
    • Auf Linux-Systemen müssen zudem die folgenden Umgebungsvariablen gesetzt sein:
      • JAVA_HOME (z.B. /usr/java/jdk1.6.0_21)
      • CLASSPATH (z.B. /usr/java/jdk1.6.0_21/bin)
      • PATH (z.B. /usr/java/jdk1.6.0_21/bin:/usr/java/jdk1.6.0_21/jre/bin:$PATH)
    • Für Java JDK außerdem erforderlich:
      • JRE_HOME (z.B. /usr/java/jdk1.6.0_21/jre)
      • JAVA_JAR (z.B. /usr/java/java_jar)
  • eine Oracle- oder MSSQL-Datenbank

warning Hinweis

  • Für den reibungslosen Ablauf der Installation muss der ausführende Benutzer Administrator-Rechte besitzen (in Windows) bzw. als root-User konfiguriert sein (Linux).

Vorgehensweise beim Update

info Information

Schritt 1: Neues Release herunterladen

Die aktuellen Releases stehen Kunden im Kundenbereich des PLANTA-Transfer-Servers zum Download zur Verfügung.

more Vorgehensweise

  • Laden Sie das gewünschte Release, auf das Sie updaten möchten, herunter.
  • Das heruntergeladene ZIP-Archiv muss auf dem System abgelegt und entpackt werden, auf dem der PLANTA-Server installiert ist und upgedatet werden soll.

Schritt 2: Installation des Servers

more Vorgehensweise
  • Den PLANTA-Server-Dienst des Systems, das Sie updaten möchten, beenden.
  • Mit Hilfe des automatischen Installers das Update starten.
    • Das Verzeichnis des bestehenden PLANTA-Servers (39.4) darf nicht als Zielverzeichnis für den neuen Server angegeben werden.

stop Stopp

  • Stellen Sie sicher, dass die Datenbankverbindung dem vorhandenen System entspricht. Der Installer prüft momentan die Datenbankverbindung nicht, bevor er mit dem Update beginnt, das bedeutet, dass das Update fehlschlägt, wenn eine falsche Datenbankverbindung eingetragen ist, ohne dass explizit darauf hingewiesen wird.
  • Im installierten Server-Verzeichnis finden sich unter /sql/migration/ im Ordner für die jeweilige Datenbank eine Anzahl von SQL-Files, die während der Installation automatisch ausgeführt werden. Diese Skripte dürfen nicht manuell (etwa in SqlPlus) ausgeführt werden!

warning Hinweise

  • Der Installer richtet den Server im Migrationsmodus ein.
  • Nach der Serverinstallation sollen die Logfiles auf mögliche Fehler geprüft werden, bevor mit dem Schritt 3 (Vorbereitung der Datenbank) begonnen wird.

Schritt 3: Vorbereitung der Datenbank

more Vorgehensweise
  • Im Verzeichnis des installierten Servers befinden sich im Pfad /sql/migration/ im Verzeichnis für die jeweilige Datenbank drei SQL-Dateien, die in der angegebenen Reihenfolge in der Datenbank für den entsprechenden Datenbankbenutzer ausgeführt werden müssen.
  • Für Oracle:
    • 1_EarthToVenus.minimal.Q1B_Q2B.Oracle.diff.sql
    • 2_EarthToVenus.history_objects.Oracle.diff.sql
    • 3_EarthToVenus.MissingDTEntries.Oracle.sql
  • Für MSSQL:
    • 1_EarthToVenus.minimal.Q1B&Q2B.MSSQL.diff.sql
    • 2_EarthToVenus.history_objects.MSSQL.diff.sql
    • 3_EarthToVenus.MissingDTEntries.MSSQL.sql

Schritt 4: Durchführen der Migration

more Vorgehensweise
  • Um den PLANTA-Server-Dienst zu starten, führen Sie entweder die Datei yajsw\bat\startService.bat (Windows) oder yajsw\bat\startDaemon.sh (Linux) aus.
    • Nun werden die von PLANTA mitgelieferten Migrationspakete mit der Einstellung Bei Systemstart = checked automatisch ausgeführt. Welche Migrationspakete für die entsprechende Server-Version ausgeführt werden, finden Sie hier.
    • Sie können durch Aufrufen von yajsw\bat\queryService.bat oder yajsw\bat\queryDaemon.sh abfragen, ob der Migrationslauf beendet wurde. Dies ist der Fall, wenn die Eigenschaft Running = false.
  • Nachdem der Server alle Pakete ausgeführt hat, wird der PLANTA-Server-Dienst automatisch beendet. Navigieren Sie anschließend in das Verzeichnis /config/. In der Datei globals.conf muss der Parameter migrate von true auf false geändert werden. Damit wird der Server vom Migrationsmodus wieder in den normalen Zustand versetzt.

Schritt 5: Bereitstellen der individuellen Python-Dateien

info Information
  • Im Server-Verzeichnis findet sich unter dem Ordner /py/ nun die neue Ordnerstruktur von 39.5.

more Vorgehensweise

  • Dateien, die im bestehenden System mit Release 39.4 durch einen Customizer angepasst wurden, müssen nun in den Unterordner /py/customer/ verschoben werden.

Schritt 6: Starten des Server-Dienstes

more Vorgehensweise
  • Um den PLANTA-Server-Dienst zu starten, führen Sie entweder die Datei yajsw\bat\startService.bat (Windows) oder yajsw\bat\startDaemon.sh (Linux) aus.

Schritt 7: Überprüfen der Migrationsergebnisse

more Vorgehensweise
  • Nach dem Starten des Servers muss der Status der Migrationspakete, d.h. ob diese korrekt durchgelaufen sind, im Modul Übersicht der Migrationspakete geprüft werden.
    • Ist ein Paket nicht korrekt durchgelaufen, muss das Logfile des Migrationspakets geprüft und ggf. entsprechende Maßnahmen ergriffen werden. Weitere Informationen finden Sie hier.
  • Zusätzlich können in diesem Modul Pakete, die in Schritt 2 nicht ausgeführt wurden, d.h. Migrationspakete mit der Einstellung Bei Systemstart = unchecked, ausgeführt werden.
  • Wurden individuelle Pythondateien im /py/customer/ Ordner angelegt, muss das Migrationspaket CreateFolderPacket im Modul Übersicht der Migrationspakete aufgerufen und der Server-Dienst neugestartet werden, bevor diese verfügbar sind.

Schritt 7: Notwendige Schritte nach der Migration

info Information
  • Nach der Migration müssen die folgenden Schritte durchgeführt werden.

Entfernen von builtins aus Python-Code

  • Durch die Veränderungen am PLANTA-Server dürfen __builtins__ nicht mehr verwendet werden, da Änderungen eines Benutzers in einer Session sofort alle Sessions anderer Benutzer betreffen!
  • Damit globale Variablen in Python jeder Session zur Verfügung stehen, ist es notwendig, alle Verweise auf __builtins__ und mögliche andere, globale Python-Konstrukte im Python-Code (sowohl in externen .py-Files, als auch in internen PLANTA-Modulen) durch ppms.get_session_dict() zu ersetzen. Diese Funktion stellt ein session-spezifisches Dictionary zur Verfügung, in dem dann globale Variablen gespeichert werden können, die nur dieser Session gelten.
  • stop Die Verwendung von eigenen __builtins__ wurde bereits ab 39.4.3.0 (Hotfix 8) als obsolet definiert, die Entfernung ist nun aber zwingend notwendig.
  • Das Migrationspaket FindBuiltinsUsagePacket findet die Verwendung von __builtins__. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixBuiltins korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

Entfernen von cmp(x, y) aus Python-Code

info Informationen

  • Die Funktion cmp(x, y) existiert ab Python-Version 3.1 nicht mehr. Da ab S 39.5.0 Python v3.2.2 verwendet wird, muss diese Funktion aus dem Python-Code entfernt werden.
  • Das Migrationspaket FindCmpUsagePacket zeigt die Verwendung der Funktion auf. Alle im Logfile gemeldeten Stellen müssen manuell korrigiert werden.

warning Hinweis

  • Das Migrationspaket FixCmpPacket korrigiert das Standard-Customizing. Wurde am entsprechenden Standard-Customizing etwas geändert, schlägt dieses Paket ebenfalls fehl. Die nicht geänderten Standardobjekte werden im Logfile des Migrationspakets aufgeführt.

Dateien aus Vorgänger-System übernehmen

Nach einem Update müssen die folgenden Dateien aus dem Vorgänger-System übernommen werden:
  • SAP dlls
  • Kerberos- und Stunnel-Konfigurationen

Topic revision: r81 - 2018-12-19 - 09:07:27 - IrinaZieger
Current.UpdateServer394Auf395 moved from Current.Update394Auf395 on 2013-10-25 - 12:27 by IrinaZieger - put it back








 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten