Customer Customizing Deployment

Info

• The customizing delivery procedure serves to roll out the customizing, e.g. from a development system at the customer's facility to his/her productive system. As a result, the customizing in the target system is completely replaced by an export from the source system using the Database Export/Import function.

Requirements

• Source and target system must be congruent, i.e.
  • the program status of both systems must be identical and all migration packets must have the same status
  • the database schema of the target system must have the same status as the source system

A customizing deployment generally consists of the following elements:

• SQL files (Example: sql_planta_1_1.sql)
• Python directory of the server (example: py.zip)
• Customizing deployment files (Example: cu_deployment_2015_02_04.zip)

Export Procedure

The export step is necessary if you carry out the deployment internally yourself. If you have any questions, please get in contact with your PLANTA consultant.

Information

• For the export, there are 2 versions of a parameter file which provides all necessary files.
  • These two files are located in the server installation directory under config/export/customizing_deployment_*.par.
  • The config/export/customizing_deployment_venus.par file is used for systems with DB 39.5.x.
  • The config/export/customizing_deployment_voe.par file is used for systems with DB 39.4.4.0.

Example of Export

./planta_export.sh --output-file /tmp/cu_deployment_2015_02_04.zip @config/export/customizing_deployment_venus.par

Import Procedure

Information

• The import procedure comprises several steps.
• The associated parameter files are located in the config/import/customizing_deployment subdirectory.

Step 1: Steps to be taken before deployment

• Stop the PLANTA service.

Step 2: Executing the SQL files

• Start SQL plus and connect to the database user of the PLANTA application

  sqlplus DB user/password@DB-SID

  CODE

• Execute delivered SQL file(s)

  @ sql_planta_1_1.sql

  CODE

Step 3: Importing delivered customizing deployment files

• PLANTA delivers a zip archive including the customizing deployment files (example: cu_deployment_2015_02_04.zip).
  • This zip archive does not need to be unpacked. The archive is automatically unpacked during the import procedure.
• Store the zip archive at an arbitrary position on the application server (example: /tmp/)
• Switch to the PLANTA application server directory (example: /planta/app/Lief).
• Carry out the following import commands in this exact order:

Example:

./planta_import.sh --input-file /tmp/cu_deployment_2015_02_04.zip @config/import/customizing_deployment/01_replace_q1b_q2b.par

./planta_import.sh --input-file /tmp/cu_deployment_2015_02_04.zip @config/import/customizing_deployment/02a_replace_module_variants.par

./planta_import.sh --input-file /tmp/cu_deployment_2015_02_04.zip @config/import/customizing_deployment/02b_add_module_variant_itexts.par

# Hier nur die der Datenbank entsprechende Datei nehmen
./planta_import.sh --input-file /tmp/cu_deployment_2015_02_04.zip @config/import/customizing_deployment/03_replace_interfaces_venus.par
./planta_import.sh --input-file /tmp/cu_deployment_2015_02_04.zip @config/import/customizing_deployment/03_replace_interfaces_voe.par

./planta_import.sh --input-file /tmp/cu_deployment_2015_02_04.zip @config/import/customizing_deployment/04_replace_process_models.par

Step 4: Import new files to the Python directory of the server

• Save the database and the Python directory of the server (e.g. rename "py" to "py_alt")
• Unzip the zip-archive which contains the Python directory.
• All subdirectories of the new "py" directory are to be copied to the "py" directory of the server.
  • The directory structure has changed with server 39.5.18 and the files of a former release cannot simply be copied. Instead they must be allocated to the correct directories. See also: DirectoryStructure

Step 5: Steps to be taken after deployment

• Start the PLANTA service.
  • The target directory will be regenerated with current POJO classes.

Note

• If the contents of the data table that possess an automatic number are transferred but their counter values are not, the counter values must be adjusted manually afterwards.
• If history data tables (_HIS_) are copied during import, the HIBERNATE_SEQUENCE must be set to the highest level of the data available in the history tables.
• If interface data is exchanged, the archived interface configurations will be lost.
  • This includes all logging files, parameters, as well as all pool records!
• The PLANTA import does not delete any interface mappings, but only imports new or updates existing mappings. The mappings in question must be deleted manually after the import.
• If import errors occur due to data corruption, the Database Consistency Check module can be used to check or correct the data.