Update Server 39.4.4.0 (Earth) auf 39.5.x (Venus)

Allgemein

• 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.

• 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

• Sämtliche im Topic Systemvoraussetzungen beschriebenen Voraussetzungen müssen erfüllt sein, z.B. die dort beschriebenen PLANTA project-User-Rechte für die Oracle-Datenbank.
• In Linux-Systemen muss rsync vorhanden sein.
• Eine Oracle- oder MSSQL-Datenbank muss vorhanden sein.
• Der ausführende Benutzer muss fundierte Kenntnisse in den erforderlichen Fachbereichen aufweisen und als Administrator (Windows) bzw. root (Linux) am Server angemeldet sein. Unter Windows kann die Installation auch über das Kontextmenü Als Administrator ausführen gestartet werden.

Vorgehensweise beim Update

• Das Update wird inkl. dem Migrationsverfahren mit dem PLANTA-Installer durchgeführt.

Schritt 1: Neues Release herunterladen

PLANTA-Transfer-Server

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 Installation

Logon-Trigger erstellen (nur für Oracle)

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; 

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

Schritt 3: Installation des Servers

• Beenden Sie den PLANTA-Server-Dienst des Systems, das Sie updaten möchten.
• Starten Sie das Update mit Hilfe des PLANTA-Installers:
  • Dabei wählen Sie im Installer folgende Optionen:
    • server.install = "yes" (GUI: Server-Installation auswählen)
    • db.install = "yes" (GUI: Datenbank-Installation auswählen)
    • Bitte beachten Sie, dass trotz dieser Einstellung kein richtiges DB-Update durchgeführt wird. Die Einstellung ist notwendig, damit beim Server-Update bestimmte customizingspezifische Migrationspakete ausgeführt werden können.
    • planta.update_type = "r94" (GUI: Updateart = Update von Release 39.4.4.0 auf Release 39.5.x (mit DB 39.4)).
  • Bitte weitere Einstellungen im Installer bearbeiten. Hierzu sehen Sie die vollständige Beschreibung der Parameter im Installer-Topic.
  • 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.

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!

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

• 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 = 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

• 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.
• 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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

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.

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.

• Weitere Informationen zu UUID-Spalten finden Sie im Topic Universally Unique Identifiers.

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

Allgemein

• 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.

• 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

• Sämtliche im Topic Systemvoraussetzungen beschriebenen Voraussetzungen müssen erfüllt sein, z.B. die dort beschriebenen PLANTA project-User-Rechte für die Oracle-Datenbank.
• In Linux-Systemen muss rsync vorhanden sein.
• Eine Oracle- oder MSSQL-Datenbank muss vorhanden sein.
• Der ausführende Benutzer muss fundierte Kenntnisse in den erforderlichen Fachbereichen aufweisen und als Administrator (Windows) bzw. root (Linux) am Server angemeldet sein. Unter Windows kann die Installation auch über das Kontextmenü Als Administrator ausführen gestartet werden.

Vorgehensweise beim Update

• Das Update wird inkl. dem Migrationsverfahren mit dem automatischen Installer durchgeführt.

Schritt 1: Neues Release herunterladen

Kundenbereich

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

• 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 = 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.
    • Die Migrationspakete mit der Einstellung Bei Systemstart = können auch manuell durch Ausführen des Skripts planta_migration.bat bzw. planta_migration.sh ausgeführt werden.

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!

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

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

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

• 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

• 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 = 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

• 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.
• 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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

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.

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.

• Weitere Informationen zu UUID-Spalten finden Sie im Topic Universally Unique Identifiers.

Dateien aus Vorgänger-System übernehmen

• SAP dlls
• Kerberos- und Stunnel-Konfigurationen

Allgemein

• 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.

• 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

• Sämtliche im Topic Systemvoraussetzungen beschriebenen Voraussetzungen müssen erfüllt sein, z.B. die dort beschriebenen PLANTA project-User-Rechte für die Oracle-Datenbank.
• In Linux-Systemen muss rsync vorhanden sein.
• Eine Oracle- oder MSSQL-Datenbank muss vorhanden sein.
• Der ausführende Benutzer muss fundierte Kenntnisse in den erforderlichen Fachbereichen aufweisen und als Administrator (Windows) bzw. root (Linux) am Server angemeldet sein. Unter Windows kann die Installation auch über das Kontextmenü Als Administrator ausführen gestartet werden.

Vorgehensweise beim Update

• Das Update wird inkl. dem Migrationsverfahren mit dem automatischen Installer durchgeführt.

Schritt 1: Neues Release herunterladen

Kundenbereich

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

• 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.

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!

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

• 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 = 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

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

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

• 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

• 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 = , 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

• 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.
• 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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

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.

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.

• Weitere Informationen zu UUID-Spalten finden Sie im Topic Universally Unique Identifiers.

Dateien aus Vorgänger-System übernehmen

• SAP dlls
• Kerberos- und Stunnel-Konfigurationen

Allgemein

• 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.

• 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

• Sämtliche im Topic Systemvoraussetzungen beschriebenen Voraussetzungen müssen erfüllt sein, z.B. die dort beschriebenen PLANTA project-User-Rechte für die Oracle-Datenbank.
• In Linux-Systemen muss rsync vorhanden sein.
• Eine Oracle- oder MSSQL-Datenbank muss vorhanden sein.
• Der ausführende Benutzer muss fundierte Kenntnisse in den erforderlichen Fachbereichen aufweisen und als Administrator (Windows) bzw. root (Linux) am Server angemeldet sein. Unter Windows kann die Installation auch über das Kontextmenü Als Administrator ausführen gestartet werden.

Vorgehensweise beim Update

• Das Update wird inkl. dem Migrationsverfahren mit dem automatischen Installer durchgeführt.

Schritt 1: Neues Release herunterladen

Kundenbereich

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

• 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.

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!

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

• 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 = 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

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

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

• 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

• 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 = , 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

• 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.
• 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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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 NEU

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.

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.

• Weitere Informationen zu UUID-Spalten finden Sie im Topic Universally Unique Identifiers.

Dateien aus Vorgänger-System übernehmen

• SAP dlls
• Kerberos- und Stunnel-Konfigurationen

Allgemein

• 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.

• 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

• Sämtliche im Topic Systemvoraussetzungen beschriebenen Voraussetzungen müssen erfüllt sein, z.B. die dort beschriebenen PLANTA project-User-Rechte für die Oracle-Datenbank.
• In Linux-Systemen muss rsync vorhanden sein.
• Eine Oracle- oder MSSQL-Datenbank muss vorhanden sein.
• Der ausführende Benutzer muss fundierte Kenntnisse in den erforderlichen Fachbereichen aufweisen und als Administrator (Windows) bzw. root (Linux) am Server angemeldet sein. Unter Windows kann die Installation auch über das Kontextmenü Als Administrator ausführen gestartet werden.

Vorgehensweise beim Update

• Das Update wird inkl. dem Migrationsverfahren mit dem automatischen Installer durchgeführt.

Schritt 1: Neues Release herunterladen

Kundenbereich

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

• 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.

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!

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

• 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

• 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 = 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

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

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

• 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

• 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 = , 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

• 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.
• 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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

• SAP dlls
• Kerberos- und Stunnel-Konfigurationen

Allgemein

• 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.

• 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

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

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

• Das Update wird inkl. dem Migrationsverfahren mit dem automatischen Installer durchgeführt.

Schritt 1: Neues Release herunterladen

Kundenbereich

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

• 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.

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!

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

• 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

• 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 = 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

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

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

• 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

• 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 = , 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

• 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.
• 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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

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.
  • Das Logfile kann über den Link im Feld Logfile im Modul Übersicht über alle bisherigen Läufe geöffnet werden.

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

• SAP dlls
• Kerberos- und Stunnel-Konfigurationen