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

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

• All requirements described in the System Requirements topic must be met, including the PLANTA project user rights for Oracle databases described in there.
• On Linux systems, rsync should be available.
• An Oracle or MSSQL database must be available before installation.
• The executing user must have profound knowledge in the required special fields and be logged on to the server as administrator (Windows) or root (Linux). On Windows, the installation can also be started by using the Run as administrator context menu.

Update Procedure

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

Step 1: Download New Release

PLANTA transfer server

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: Steps required before installation

Create Log-On Trigger (only for Oracle)

Information

• Please check whether there is a trigger named 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 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> is to be replaced by the name of the DB user.

Step 3: Install the Server

• Terminate the PLANTA server service of the system you want to update.
• Start the update using the PLANTA installer:
  • Select the following options in the installer:
    • server.install = "yes" (GUI: select server installation)
    • db.install = "yes" (GUI: select database installation)
    • Please note that despite this setting no proper DB-update will be carried out. This setting is required in order to enable the execution of particular customizing-specific migration packets during server update.
    • planta.update_type = "r94" (GUI: update type: Update from Release 39.4.4.0 to Release 39.5.x (with DB 39.4))
  • Please edit further settings in the installer. Please refer to the complete description of the parameters in the installer topic.
  • The directory of the existing PLANTA server must not be specified as a 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.

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.5. 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 4: 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 Upon system start = 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 5: Necessary steps after migration

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

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

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

Insert 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. PLANTA Standard 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

• All requirements described in the System Requirements topic must be met, including the PLANTA project user rights for Oracle databases described in there.
• On Linux systems, rsync should be available.
• An Oracle or MSSQL database must be available before installation.
• The executing user must have profound knowledge in the required special fields and be logged on to the server as administrator (Windows) or root (Linux). On Windows, the installation can also be started by using the Run as administrator context menu.

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: Install 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 Run migration? parameter whether the migration packets with the Upon system start parameter = setting delivered by PLANTA are to be run automatically in the update of the PLANTA server. 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 run, the PLANTA server service that was started to execute the migration packets is shut down again.
    • The migration packets with the Upon system start = can also be executed 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: Make the Individual Python Files Available

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

Procedure

• NEW 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: Start Server Service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or the 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 Upon system start = that were not run automatically in step 2 due to their setting, can be run manually in this module.
• NEW 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.

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

Delete 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. PLANTA Standard 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

• All requirements described in the System Requirements topic must be met, including the PLANTA project user rights for Oracle databases described in there.
• On Linux systems, rsync should be available.
• An Oracle or MSSQL database must be available before installation.
• The executing user must have profound knowledge in the required special fields and be logged on to the server as administrator (Windows) or root (Linux). On Windows, the installation can also be started by using the Run as administrator context menu.

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: Install 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 executed 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: Make 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 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: Start Server Service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or the 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.

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

Delete 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. PLANTA Standard 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

• All requirements described in the System Requirements topic must be met, including the PLANTA project user rights for Oracle databases described in there.
• On Linux systems, rsync should be available.
• An Oracle or MSSQL database must be available before installation.
• The executing user must have profound knowledge in the required special fields and be logged on to the server as administrator (Windows) or root (Linux). On Windows, the installation can also be started by using the Run as administrator context menu.

Update Procedure

• The update includes the migration process with 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: Install 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 the yajsw\bat\startDaemon.sh (Linux) file.
  • Now, the server is started automatically and the migration packets delivered by PLANTA with Upon system start = are executed 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: Make 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 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: Start Server Service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or the 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.

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

Delete 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 NEW

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. PLANTA Standard 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

• All requirements described in the System Requirements topic must be met, including the PLANTA project user rights for Oracle databases described in there.
• On Linux systems, rsync should be available.
• An Oracle or MSSQL database must be available before installation.
• The executing user must have profound knowledge in the required special fields and be logged on to the server as administrator (Windows) or root (Linux). On Windows, the installation can also be started by using the Run as administrator context menu.

Update Procedure

• The update includes the migration process with 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: Install 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 the yajsw\bat\startDaemon.sh (Linux) file.
  • Now, the server is started automatically and the migration packets delivered by PLANTA with Upon system start = are executed 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: Make 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 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: Start Server Service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or the 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.

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

Delete 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

The following components must be installed on the target system:

• Java Version (JDK) 1.6.x 64-bit (otherwise, the PLANTA Server cannot be started)
  • On Linux systems, the following environment variables must be set in addition:
    • JAVA_HOME (e.g. /usr/java/jdk1.6.0_21)
    • CLASSPATH (e.g. /usr/java/jdk1.6.0_21/bin)
    • PATH (e.g. /usr/java/jdk1.6.0_21/bin:/usr/java/jdk1.6.0_21/jre/bin:$PATH)
  • Also required for Java JDK:
    • JRE_HOME (e.g. /usr/java/jdk1.6.0_21/jre)
    • JAVA_JAR (e.g. /usr/java/java_jar)
• an Oracle or MSSQL database.

Note

• For the installation to run smoothly, the executing user must possess administrator rights (in Windows) or must be configured as a root user (Linux).

Update Procedure

• The update includes the migration process with 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: Install 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 the yajsw\bat\startDaemon.sh (Linux) file.
  • Now, the server is started automatically and the migration packets delivered by PLANTA with Upon system start = are executed 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: Make 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 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: Start Server Service

• In order to start the PLANTA server service, please either run the yajsw\bat\startService.bat (Windows) or the 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.

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

Delete 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