Server Update from 39.4.4.0 to S 39.5.x

General

• The PLANTA server update from S 39.4.4.0 to S 39.5.x contains the update of the PLANTA servers including the required adjustments to the database via the new migration process in S 39.5.0.

• The update does not contain a migration of functional data. If you have any questions, please consult your PLANTA consultant.
• In order to keep the effort for changing from 39.4.4.0 to 39.5.x at a minimum, we recommend that you switch as early as possible.

Requirements

Update Procedure

• The update is carried out including the migration process with the automatic installer.

Step 1: Download new release

customer area

Procedure

• Please download the required release to which you want to update.
• The downloaded ZIP archive must be stored and unpacked on the system on which the PLANTA server is to be installed and updated.

Step 2: Installing the Server

• Terminate the PLANTA server service of the system you want to update.
• Start the update using the automatic installer.
  • The directory of the existing PLANTA server must not be specified as target directory for the new server. Instead, you have to select a new directory for the server and specify the old directory as Existing server directory.
  • Please specify via the Carry out migration? parameter, whether the migration packets delivered by PLANTA that have Upon system start = are to be carried out automatically or not. Which migration packets have to be run for the respective update, is detected from your existing system by the migration process. After the migration packets have been carried out, the PLANTA server service that was started to carry out the migration packets shuts down again.
    • The migration packets with the Upon system start = can also be carried out manually by running the planta_migration.bat or planta_migration.sh script.

Stop

• Make sure that the database connection corresponds to the existing system. Currently, the installer does not check the database connection before starting the update, i.e., the installation fails automatically if an incorrect database connection is entered without pointing it out explicitly.
• You can find a number of SQL files that are carried out automatically during the installation in the folder of the respective database under /sql/migration/ in the installed server directory. These scripts must not be run manually (e.g. in SqlPlus)!

Notes

• In the update, the customizing is automatically upgraded to 39.4. This is done by running migration scripts and migration packets.
• After the server installation, log files are to be checked for possible errors before starting step 3 (providing individual Python files).

Step 3: Making the Individual Python Files Available

• In the server directory, you find the new directory structure of 39.5 in the /py/ folder now.

Procedure

• Files that were adjusted by a customizer in the existing system with release 39.4, must now be moved to the /py/api/ppms/wrapper/customer subfolder.

Step 4: Starting the server service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or yajsw\bat\startDaemon.sh (Linux) file.

Step 5: Checking the Migration Results

• After starting the PLANTA server service, the status of the migration packets, i.e. whether they ran correctly, must be checked in the Migration packets panel.
  • If a packet has not been run correctly, you must check the log file of the migration packet and take appropriate measures. For further information, please go to the Overview of All Previous Runs topic.
• Additionally, migration packets with the Upon system start setting = that were not run automatically in step 2 due to their setting can be run manually in this module.
• If individual Python files were created in the /py/api/ppms/wrapper/customer directory, the CreateFolderPacket miration packet must be opened in the Migration packets panel and the PLANTA server service must be restarted before the individual Python files are available.

Step 6: Necessary steps after migration

• After migration, the following steps must be carried out.

Creating Logon Trigger (for Oracle only)

• Please check whether you have a trigger called ON_LOGON_PLANTA_<DB_USER> in your Oracle database.
• If not, please create such a trigger:

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

<DB_USER> is to be replaced with the name of the DB user.

Deleting builtins from Python Code

• Due to the changes made to the PLANTA server, __builtins__ must not be used anymore, since changes a user makes in a session immediately affect all sessions of other users!
• In order for global variables to be available in each Python session, it is necessary to replace all references to __builtins__ and other existing global Python constructs in the Python code (both, external .py files and internal PLANTA modules) by ppms.get_session_dict(). This function provides a session specific dictionary in which global variables that only apply to this session can be saved.
• The use of own __builtins__ has already been defined as obsolete from 39.4.3.0 (Hotfix 8) but is absolutely necessary now.
• The FindBuiltinsUsagePacket migration packet is used as __builtins__. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixBuiltins migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet will fail. Standard objects that have not been changed are run in the logfile of the migration packet.

Deleting cmp(x, y) from Python Code

Information

• The cmp(x, y) function no longer exists from Python version 3.1. Since from S 39.5.0 Python v3.2.2 is used, this function must be deleted from the Python code.
• The FindCmpUsagePacket migration packet shows the use of the function. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixCmpPacket migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet will fail. Standard objects that have not been changed are run in the logfile of the migration packet.

Inserting UUID Columns

Information

• From Release DB 39.5, each database table must have a column named UUID of the UUID type. These columns serve to uniquely identify records. Standard PLANTA tables already contain this field.

Details

• You have to add this column to your customized tables. To do so, please run the CreateUUIDColumnsPacket migration packet once after you have imported all of your tables. As a result, your tables will be initialized and your records will have valid UUID values.

• For further information on UUID columns, see the Universally Unique Identifiers topic.

Files from the predecessor system

• After an update, the following files must be copied from the predecessor system.
  • SAP dlls
  • Kerberos and stunnel configurations

General

• The PLANTA server update from S 39.4.4.0 to S 39.5.x contains the update of the PLANTA servers including the required adjustments to the database via the new migration process in S 39.5.0.

• The update does not contain a migration of functional data. If you have any questions, please consult your PLANTA consultant.
• In order to keep the effort for changing from 39.4.4.0 to 39.5.x at a minimum, we recommend that you switch as early as possible.

Requirements

Update Procedure

• The update is carried out including the migration process with the automatic installer.

Step 1: Download new release

customer area

Procedure

• Please download the required release to which you want to update.
• The downloaded ZIP archive must be stored and unpacked on the system on which the PLANTA server is to be installed and updated.

Step 2: Installing the Server

• Terminate the PLANTA server service of the system you want to update.
• Start the update using the automatic installer.
  • The directory of the existing PLANTA server must not be specified as target directory for the new server. Instead, you have to select a new directory for the server and specify the old directory as Existing server directory.
  • Please specify whether the migration packets delivered by PLANTA that have Upon system start = are to be carried out automatically or not using the Carry out migration? parameter. Which migration packets have to be run for the respective update, is detected from your existing system by the migration process. After the migration packets have been carried out, the PLANTA server service that was started to carry out the migration packets shuts down again.
    • The migration packets with the Upon system start = can also be carried out manually by running the planta_migration.bat or planta_migration.sh script.

Stop

• Make sure that the database connection corresponds to the existing system. Currently, the installer does not check the database connection before starting the update, i.e., the installation fails automatically if an incorrect database connection is entered without pointing it out explicitly.
• You can find a number of SQL files that are carried out automatically during the installation in the folder of the respective database under /sql/migration/ in the installed server directory. These scripts must not be run manually (e.g. in SqlPlus)!

Notes

• In the update, the customizing is automatically upgraded to 39.4. This is done by running migration scripts and migration packets.
• After the server installation, log files are to be checked for possible errors before starting step 3 (providing individual Python files).

Step 3: Making the Individual Python Files Available

• In the server directory, you find the new folder structure of 39.5 in the /py/ folder now.

Procedure

• Files that have been adjusted by a customizer in the existing system with release 39.4 must now be moved to the /py/api/ppms/wrapper/customer subfolder.

Step 4: Starting the server service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or yajsw\bat\startDaemon.sh (Linux) file.

Step 5: Checking the Migration Results

• After starting the PLANTA server service, the status of the migration packets, i.e. whether they ran correctly, must be checked in the Migration packets panel.
  • If a packet has not been run correctly, you must check the log file of the migration packet and take appropriate measures. For further information, please go to the Overview of All Previous Runs topic.
• Additionally, migration packets with the Upon system start setting = that were not run automatically in step 2 due to their setting can be run manually in this module.
• If individual Python files were created in the /py/api/ppms/wrapper/customer directory, the CreateFolderPacket migration packet in the Migration packets panel must be opened and the PLANTA Server service must be restarted before the individual Python files are available.

Step 6: Necessary steps after migration

• After migration, the following steps must be carried out.

Deleting builtins from Python Code

• Due to the changes made to the PLANTA server, __builtins__ must not be used anymore, since changes a user makes in a session immediately affect all sessions of other users!
• In order for global variables to be available in each Python session, it is necessary to replace all references to __builtins__ and other existing global Python constructs in the Python code (both, external .py files and internal PLANTA modules) by ppms.get_session_dict(). This function provides a session specific dictionary in which global variables that only apply to this session can be saved.
• The use of own __builtins__ has already been defined as obsolete from 39.4.3.0 (Hotfix 8) but is absolutely necessary now.
• The FindBuiltinsUsagePacket migration packet is used as __builtins__. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixBuiltins migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet will fail. Standard objects that have not been changed are run in the logfile of the migration packet.

Deleting cmp(x, y) from Python Code

Information

• The cmp(x, y) function no longer exists from Python version 3.1. Since from S 39.5.0 Python v3.2.2 is used, this function must be deleted from the Python code.
• The FindCmpUsagePacket migration packet shows the use of the function. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixCmpPacket migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet will fail. Standard objects that have not been changed are run in the logfile of the migration packet.

Add UUID Columns

Information

• From Release DB 39.5, each database table must have a column named UUID of the UUID type. These columns serve to uniquely identify records. Standard PLANTA tables already contain this field.

Details

• You have to add this column to your customized tables. To do so, please run the CreateUUIDColumnsPacket migration packet once after you have imported all of your tables. As a result, your tables will be initialized and your records will have valid UUID values.

• For further information on UUID columns, see the Universally Unique Identifiers topic.

Transfer Files from the Predecessor System

• SAP dlls
• Kerberos and stunnel configurations

General

• The PLANTA server update from S 39.4.4.0 to S 39.5.x contains the update of the PLANTA servers including the required adjustments to the database via the new migration process in S 39.5.0.

• The update does not contain a migration of functional data. If you have any questions, please consult your PLANTA consultant.
• In order to keep the effort for changing from 39.4.4.0 to 39.5.x at a minimum, we recommend that you switch as early as possible.

Requirements

Update Procedure

• The update is carried out including the migration process with the automatic installer.

Step 1: Download new release

customer area

Procedure

• Please download the required release to which you want to update.
• The downloaded ZIP archive must be stored and unpacked on the system on which the PLANTA server is to be installed and updated.

Step 2: Installing the Server

• Terminate the PLANTA server service of the system you want to update.
• Start the update using the automatic installer.
  • The directory of the existing PLANTA server (39.4) may not be specified as target directory for the new server.

Stop

• Make sure that the database connection corresponds to the existing system. Currently, the installer does not check the database connection before starting the update, i.e., the installation fails automatically if an incorrect database connection is entered without pointing it out explicitly.
• You can find a number of SQL files that are carried out automatically during the installation in the folder of the respective database under /sql/migration/ in the installed server directory. These scripts must not be run manually (e.g. in SqlPlus)!

Notes

• In the update, the customizing is automatically upgraded to 39.4. This is done by running migration scripts and migration packets.
• After the server installation, log files are to be checked for possible errors before starting step 3 (providing individual Python files).

Step 3: Carry out the migration

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or yajsw\bat\startDaemon.sh (Linux) file.
  • Now, the server is started automatically and the migration packets delivered by PLANTA with Upon system start = are carried out automatically. Which migration packets are run for the corresponding server version can be checked here.
  • By opening yajsw\bat\queryService.bat or yajsw\bat\queryDaemon.sh, you can enquire whether the migration run has finished. This is the case if the Running property is set to false.
• After the server has run all packets, the PLANTA server service is automatically terminated. Navigate to the /config/ directory subsequently. In the globals.conf file, the migrate parameter must be set from true to false. This way, the server is set from migration mode back to normal mode.

Step 3: Making the Individual Python Files Available

• In the server directory, you find the new folder structure of 39.5 in the /py/ folder now.

Procedure

• Files that have been adjusted by a customizer in the existing system with Release 39.4, have to be moved to the /py/customer/ subdirectory now.

Step 4: Starting the server service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or yajsw\bat\startDaemon.sh (Linux) file.

Step 5: Checking the Migration Results

• After starting the server, the status of the migration packets, i.e. whether they ran correctly, must be checked in the Migration packets panel.
  • If a packet has not been run correctly, you must check the log file of the migration packet and take appropriate measures. For further information, please go to the Overview of All Previous Runs topic.
• Additionally, packets that have not been run in step 2, i.e. migration packets with Upon system start = can be run in this module.
• If individual Python files have been created in the /py/customer/ directory, the CreateFolderPacket migration packet in the Migration packets panel must be opened and the server service must be restarted before they are available.

Step 6: Necessary steps after migration

• After migration, the following steps must be carried out.

Deleting builtins from Python Code

• Due to the changes made to the PLANTA server, __builtins__ must not be used anymore, since changes a user makes in a session immediately affect all sessions of other users!
• In order for global variables to be available in each Python session, it is necessary to replace all references to __builtins__ and other existing global Python constructs in the Python code (both, external .py files and internal PLANTA modules) by ppms.get_session_dict(). This function provides a session specific dictionary in which global variables that only apply to this session can be saved.
• The use of own __builtins__ has already been defined as obsolete from 39.4.3.0 (Hotfix 8) but is absolutely necessary now.
• The FindBuiltinsUsagePacket migration packet is used as __builtins__. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixBuiltins migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet will fail. Standard objects that have not been changed are run in the logfile of the migration packet.

Deleting cmp(x, y) from Python Code

Information

• The cmp(x, y) function no longer exists from Python version 3.1. Since from S 39.5.0 Python v3.2.2 is used, this function must be deleted from the Python code.
• The FindCmpUsagePacket migration packet shows the use of the function. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixCmpPacket migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet fails as well. Standard objects that have not been changed are run in the logfile of the migration packet.

Add UUID Columns

Information

• From Release DB 39.5, each database table must have a column named UUID of the UUID type. These columns serve to uniquely identify records. Standard PLANTA tables already contain this field.

Details

• You have to add this column to your customized tables. To do so, please run the CreateUUIDColumnsPacket migration packet once after you have imported all of your tables. As a result, your tables will be initialized and your records will have valid UUID values.

• For further information on UUID columns, see the Universally Unique Identifiers topic.

Copying files from the predecessor system

• SAP dlls
• Kerberos and stunnel configurations

General

• The PLANTA server update from S 39.4.4.0 to S 39.5.x contains the update of the PLANTA servers including the required adjustments to the database via the new migration process in S 39.5.0.

• The update does not contain a migration of functional data. If you have any questions, please consult your PLANTA consultant.
• In order to keep the effort for changing from 39.4.4.0 to 39.5.x at a minimum, we recommend that you switch as early as possible.

Requirements

Update Procedure

• The update is carried out including the migration process with the automatic installer .

Step 1: Download new release

customer area

Procedure

• Please download the required release to which you want to update.
• The downloaded ZIP archive must be stored and unpacked on the system on which the PLANTA server is to be installed and updated.

Step 2: Installing the Server

• Terminate the PLANTA server service of the system you want to update.
• Start the update with the help of the automatic installer .
  • The directory of the existing PLANTA server (39.4) may not be specified as target directory for the new server.

Stop

• Make sure that the database connection corresponds to the existing system. Currently, the installer does not check the database connection before starting the update, i.e., the installation fails automatically if an incorrect database connection is entered without pointing it out explicitly.
• You can find a number of SQL files that are carried out automatically during the installation in the folder of the respective database under /sql/migration/ in the installed server directory. These scripts must not be run manually (e.g. in SqlPlus)!

Notes

• The installer configures the server in migration mode .
• After the server installation, log files are to be checked for possible errors before continuing with step 3 (running the migration).

Step 3: Carrying out the migration

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or yajsw\bat\startDaemon.sh (Linux) file.
  • Now, the server is started automatically and the migration packets delivered by PLANTA with Upon system start = are carried out automatically. Which migration packets are run for the corresponding server version can be checked here.
  • By opening yajsw\bat\queryService.bat or yajsw\bat\queryDaemon.sh, you can enquire whether the migration run has finished. This is the case if the Running property is set to false.
• After the server has run all packets, the PLANTA server service is automatically terminated. Navigate to the /config/ directory subsequently. In the globals.conf file, the migrate parameter must be set from true to false. This way, the server is set from migration mode back to normal mode.

Step 4: Making the Individual Python Files Available

• In the server directory, you find the new folder structure of 39.5 in the /py/ folder now.

Procedure

• Files that have been adjusted by a customizer in the existing system with Release 39.4, have to be moved to the /py/customer/ subdirectory now.

Step 5: Starting the server service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or yajsw\bat\startDaemon.sh (Linux) file.

Step 6: Checking the Migration Results

• After starting the server, the status of the migration packets, i.e. whether they ran correctly, must be checked in the Migration Packets module.
  • If a packet has not been run correctly, you must check the log file of the migration packet and take appropriate measures. For further information, click here .
• Additionally, packets that have not been run in step 2, i.e. migration packets with Upon system start = can be run in this module.
• If individual Python files have been created in the /py/customer/ folder, the CreateFolderPacket migration packet in the Migration Packets module must be opened and the server service must be restarted before they are available.

Step 7: Necessary steps after migration

• After migration, the following steps must be carried out.

Deleting builtins from Python Code

• Due to the changes made to the PLANTA server, __builtins__ must not be used anymore, since changes a user makes in a session immediately affect all sessions of other users!
• In order for global variables to be available in each Python session, it is necessary to replace all references to __builtins__ and other existing global Python constructs in the Python code (both, external .py files and internal PLANTA modules) by ppms.get_session_dict(). This function provides a session specific dictionary in which global variables that only apply to this session can be saved.
• The use of own __builtins__ has already been defined as obsolete from 39.4.3.0 (Hotfix 8) but is absolutely necessary now.
• The FindBuiltinsUsagePacket migration packet is used as __builtins__. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixBuiltins migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet will fail. Standard objects that have not been changed are run in the logfile of the migration packet.

Deleting cmp(x, y) from Python Code

Information

• The cmp(x, y) function no longer exists from Python version 3.1. Since from S 39.5.0 Python v3.2.2 is used, this function must be deleted from the Python code.
• The FindCmpUsagePacket migration packet shows the use of the function. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixCmpPacket migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet fails as well. Standard objects that have not been changed are run in the logfile of the migration packet.

Add UUID Columns

Information

• From Release DB 39.5, each database table must have a column named UUID of the UUID type. These columns serve to uniquely identify records. Standard PLANTA tables already contain this field.

Details

• You have to add this column to your customized tables. To do so, please run the CreateUUIDColumnsPacket migration packet once after you have imported all of your tables. As a result, your tables will be initialized and your records will have valid UUID values.

• For further information on UUID columns, see the Universally Unique Identifiers topic.

Copying files from the predecessor system

• SAP dlls
• Kerberos and stunnel configurations

General

• The PLANTA server update from S 39.4.4.0 to S 39.5.x contains the update of the PLANTA servers including the required adjustments to the database via the new migration process in S 39.5.0.

• The update does not contain a migration of functional data. If you have any questions, please consult your PLANTA consultant.
• In order to keep the effort for changing from 39.4.4.0 to 39.5.x at a minimum, we recommend that you switch as early as possible.

Requirements

Update Procedure

• The update is carried out including the migration process with the automatic installer .

Step 1: Download new release

customer area

Procedure

• Please download the required release to which you want to update.
• The downloaded ZIP archive must be stored and unpacked on the system on which the PLANTA server is to be installed and updated.

Step 2: Installing the Server

• Terminate the PLANTA server service of the system you want to update.
• Start the update with the help of the automatic installer .
  • The directory of the existing PLANTA server (39.4) may not be specified as target directory for the new server.

Stop

• Make sure that the database connection corresponds to the existing system. Currently, the installer does not check the database connection before starting the update, i.e., the installation fails automatically if an incorrect database connection is entered without pointing it out explicitly.
• You can find a number of SQL files that are carried out automatically during the installation in the folder of the respective database under /sql/migration/ in the installed server directory. These scripts must not be run manually (e.g. in SqlPlus)!

Notes

• The installer configures the server in migration mode .
• After the server installation, log files are to be checked for possible errors before continuing with step 3 (running the migration).

Step 3: Preparing the database

• In the directory of the installed server there are three SQL files in the /sql/migration/ path in the directory for the respective database that must be run in the specified sequence in the database for the respective database user.
• For 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

Step 3: Carrying out the migration

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or yajsw\bat\startDaemon.sh (Linux) file.
  • Now, the server is started automatically and the migration packets delivered by PLANTA with Upon system start = are carried out automatically. Which migration packets are run for the corresponding server version can be checked here.
  • By opening yajsw\bat\queryService.bat or yajsw\bat\queryDaemon.sh, you can enquire whether the migration run has finished. This is the case if the Running property is set to false.
• After the server has run all packets, the PLANTA server service is automatically terminated. Navigate to the /config/ directory subsequently. In the globals.conf file, the migrate parameter must be set from true to false. This way, the server is set from migration mode back to normal mode.

Step 4: Making the Individual Python Files Available

• In the server directory, you find the new folder structure of 39.5 in the /py/ folder now.

Procedure

• Files that have been adjusted by a customizer in the existing system with Release 39.4, have to be moved to the /py/customer/ subdirectory now.

Step 5: Starting the server service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or yajsw\bat\startDaemon.sh (Linux) file.

Step 6: Checking the Migration Results

• After starting the server, the migration packet status (i.e. whether they have run correctly), must be checked in the Overview of the Migration Packets module.
  • If a packet has not been run correctly, you must check the log file of the migration packet and take appropriate measures. For further information, click here .
• Additionally, packets that have not been run in step 2, i.e. migration packets with Upon system start = can be run in this module.
• If individual Python files have been created in the /py/customer/ directory, the CreateDirectoryPacket migration packet in the Overview of the Migration Packets module must be opened and the server service must be restarted before they are available.

Step 7: Necessary steps after migration

• After migration, the following steps must be carried out.

Deleting builtins from Python Code

• Due to the changes made to the PLANTA server, __builtins__ must not be used anymore, since changes a user makes in a session immediately affect all sessions of other users!
• In order for global variables to be available in each Python session, it is necessary to replace all references to __builtins__ and other existing global Python constructs in the Python code (both, external .py files and internal PLANTA modules) by ppms.get_session_dict(). This function provides a session specific dictionary in which global variables that only apply to this session can be saved.
• The use of own __builtins__ has already been defined as obsolete from 39.4.3.0 (Hotfix 8) but is absolutely necessary now.
• The FindBuiltinsUsagePacket migration packet is used as __builtins__. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixBuiltins migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet will fail. Standard objects that have not been changed are run in the logfile of the migration packet.

Deleting cmp(x, y) from Python Code

Information

• The cmp(x, y) function no longer exists from Python version 3.1. Since from S 39.5.0 Python v3.2.2 is used, this function must be deleted from the Python code.
• The FindCmpUsagePacket migration packet shows the use of the function. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixCmpPacket migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet fails as well. Standard objects that have not been changed are run in the logfile of the migration packet.

Copying files from the predecessor system

• SAP dlls
• Kerberos and stunnel configurations

General

• The PLANTA server update from S 39.4.4.0 to S 39.5.x contains the update of the PLANTA servers including the required adjustments to the database via the new migration process in S 39.5.0.

• The update does not contain a migration of functional data. If you have any questions, please consult your PLANTA consultant.
• In order to keep the effort for changing from 39.4.4.0 to 39.5.x at a minimum, we recommend that you switch as early as possible.

Requirements

Update Procedure

• The update is carried out including the migration process with the automatic installer .

Step 1: Download new release

customer area

Procedure

• Please download the required release to which you want to update.
• The downloaded ZIP archive must be stored and unpacked on the system on which the PLANTA server is to be installed and updated.

Step 2: Installing the Server

• Terminate the PLANTA server service of the system you want to update.
• Start the update with the help of the automatic installer .
  • The directory of the existing PLANTA server (39.4) may not be specified as target directory for the new server.

Stop

• Make sure that the database connection corresponds to the existing system. Currently, the installer does not check the database connection before starting the update, i.e., the installation fails automatically if an incorrect database connection is entered without pointing it out explicitly.
• You can find a number of SQL files that are carried out automatically during the installation in the folder of the respective database under /sql/migration/ in the installed server directory. These scripts must not be run manually (e.g. in SqlPlus)!

Notes

• The installer configures the server in migration mode .
• After the server installation, log files are to be checked for possible errors before continuing with step 3 (database preparation).

Step 3: Preparing the database

• In the directory of the installed server there are three SQL files in the /sql/migration/ path in the directory for the respective database that must be run in the specified sequence in the database for the respective database user.
• For Oracle:
  • 1_EarthToVenus.minimal.Q1B_Q2B.Oracle.diff.sql
  • 2_EarthToVenus.history_objects.Oracle.diff.sql
  • 3_EarthToVenus.MissingDTEntries.Oracle.sql
• For MSSQL:
  • 1_EarthToVenus.minimal.Q1B&Q2B.MSSQL.diff.sql
  • 2_EarthToVenus.history_objects.MSSQL.diff.sql
  • 3_EarthToVenus.MissingDTEntries.MSSQL.sql

Step 4: Carrying out the migration

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or yajsw\bat\startDaemon.sh (Linux) file.
  • Now, the server is started automatically and the migration packets delivered by PLANTA with Upon system start = are carried out automatically. Which migration packets are run for the corresponding server version can be checked here.
  • By opening yajsw\bat\queryService.bat or yajsw\bat\queryDaemon.sh, you can enquire whether the migration run has finished. This is the case if the Running property is set to false.
• After the server has run all packets, the PLANTA server service is automatically terminated. Navigate to the /config/ directory subsequently. In the globals.conf file, the migrate parameter must be set from true to false. This way, the server is set from migration mode back to normal mode.

Step 5: Making the Individual Python Files Available

• In the server directory, you find the new folder structure of 39.5 in the /py/ folder now.

Procedure

• Files that have been adjusted by a customizer in the existing system with Release 39.4, have to be moved to the /py/customer/ subdirectory now.

Step 6: Starting the server service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or yajsw\bat\startDaemon.sh (Linux) file.

Step 7: Checking the Migration Results

• After starting the server, the migration packet status (i.e. whether they have run correctly), must be checked in the Overview of the Migration Packets module.
  • If a packet has not been run correctly, you must check the log file of the migration packet and take appropriate measures. For further information, click here .
• Additionally, packets that have not been run in step 2, i.e. migration packets with Upon system start = can be run in this module.
• If individual Python files have been created in the /py/customer/ directory, the CreateDirectoryPacket migration packet in the Overview of the Migration Packets module must be opened and the server service must be restarted before they are available.

Step 7: Necessary steps after migration

• After migration, the following steps must be carried out.

Deleting builtins from Python Code

• Due to the changes made to the PLANTA server, __builtins__ must not be used anymore, since changes a user makes in a session immediately affect all sessions of other users!
• In order for global variables to be available in each Python session, it is necessary to replace all references to __builtins__ and other existing global Python constructs in the Python code (both, external .py files and internal PLANTA modules) by ppms.get_session_dict(). This function provides a session specific dictionary in which global variables that only apply to this session can be saved.
• The use of own __builtins__ has already been defined as obsolete from 39.4.3.0 (Hotfix 8) but is absolutely necessary now.
• The FindBuiltinsUsagePacket migration packet is used as __builtins__. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixBuiltins migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet will fail. Standard objects that have not been changed are run in the logfile of the migration packet.

Deleting cmp(x, y) from Python Code

Information

• The cmp(x, y) function no longer exists from Python version 3.1. Since from S 39.5.0 Python v3.2.2 is used, this function must be deleted from the Python code.
• The FindCmpUsagePacket migration packet shows the use of the function. All positions reported in the logfile must be corrected manually.
  • The logfile can be opened via the link in the logfile field in the Overview of All Previous Runs module.

Note

• The FixCmpPacket migration packet corrects the standard customizing. If changes have been made to the respective standard customizing, this packet fails as well. Standard objects that have not been changed are run in the logfile of the migration packet.

Copying files from the predecessor system

• SAP dlls
• Kerberos and stunnel configurations