6.5 Upgrade Platform Container

Follow the steps in this section to upgrade the Platform Container.

Desktop

Before starting the upgrade, please ensure that all desktop clients have been exited.

Before performing an upgrade, the database may require an upgrade by running certain patch scripts.
1. Run the following script for generating a *.tar file containing the patch script(s):
```
$ ./setup.sh prepare_db_upgrade
```
  Note!
  You must specify username, password, and database type. You can also specify them using command line.
  $ ./setup.sh prepare_db_upgrade -Dmz.username=mzadmin -Dmz.password=<password> -Dmz.databasetype=<database type: [oracle, postgresql, derby, saphana]>
  The file database-upgrade.tar containing the required patch scripts is generated.
  Derby Database
  
  For a Derby database, no tar file is generated. It is automatically upgraded during step 2, skipping steps b-d.
2. Copy the file to the database server. This is not applicable for Derby databases.
3. Extract the script(s):
```
$ tar xvf database-upgrade.tar
```
4. Run the commands specific to the database.
  1. For Oracle:
    $ sqlplus <Owner user>/<password> < database-upgrade.sql $ sqlplus <JDBC User>/<password> < database-upgrade-synonyms.sql
  2. For PostgreSQL:
    $ psql -d mz -U <Owner user> -f database-upgrade.sql
  3. For SAP HANA:
    $ hdbsql -d MZ -u <JDBC User> -p <password> -I database-upgrade.sql
Use the setup script setup.sh, which was extracted when unzipping the upgrade software, to upgrade the Platform Container.

$ ./setup.sh upgrade

Note!

Before running the upgrade, ensure that the install.xml file does not exist in your installation directory. The upgrade script will fail should it exists, so in case a copy of install.xml is present, you should move it to another directory or remove it in case it's no longer needed.

Hint!

The setup script verifies that the target filesystem has at least 5GB of free space. If the validation fails you will be prompted to continue or not. Choosing not to continue aborts the upgrade. You can disable this validation by adding a flag to the setup script.

$ ./setup.sh upgrade -DsilentMode=y

3. Enter user name and password at the prompt.

Hint!

You can also add the username and password properties to the setup.sh script.

$ ./setup.sh upgrade -Dmz.username=mzadmin -Dmz.password=<password>

4. Enter the URL for the Platform web interface at the prompt, e g http://platform1:9000, and the upgrade will start.

Hint!

You can also add the URL setup.sh script.

$ ./setup.sh upgrade -Dmz.platform=<URL>

When using the setup.sh upgrade command, three different log files will be created; generate<timestamp>.log, validate<timestamp>.log, and upgrade<timestamp>.log. By default, these log files will be placed in the same directory as setup.sh. If you want the log file to be placed in another directory, you can add the upgradelogdir property to the setup script.

Example - Extracting the upgrade software

$ ./setup.sh upgrade -Dmz.upgradelogdir=<directory path>

Hint!

It may be a good idea to open a new command line window in order to keep track of the log files.

A successful upgrade command will print out "Version successfully changed from <old_version> to <new_version>" at the end of the command output. A successful upgrade may also print out "The following things may require your manual attention" at the end of the command output, followed by a list of things that may need manual attention. In case the upgrade was unsuccessful, this will be indicated. Check the latest upgrade_<timestamp>.log foe for further details in order to analyze the result and see what may have caused the problem. If it is needed, a downgrade can be performed. For information about how to perform a downgrade, see 7. Standard Downgrade Procedure.

Note!

If the upgrade fails, you may want to perform a downgrade. In case this downgrade also fails, you can try to manually remove or rename the version folder that has been created in MZ_HOME/upgrade_history/<version> before you attempt to downgrade the system again. The version folder may be stored in a different directory if the property pico.upgrade_history has been set in common.xml.

Note!

If you are using SAP HANA as the Platform database, you will need to enable TLS/SSL on the SAP HANA database after you upgrade your Platform. Refer to Upgrade to 8.2 on the Release Documentation for the steps.

Hint!

If any configurations have become invalid due to the upgrade, these will be listed in the log file. Search for the string "Regenerating configs" in the log file to find information about any invalid configurations.

Example - Output in the upgrade_<timestamp>.log file with invalid configurations.

Mon Nov 19 10:52:10 CET 2013 Regenerating configs 
The following configurations changed status 
and may require manual attention: 
Workflow Test.WF1 became invalid, 
Workflow Test.WF2 became invalid, 
APL Code Test.apl_profile became invalid,

Next:

6.6 Upgrade Execution Container