Getting Started with Building Blocks > Upgrading the Building Blocks > Upgrading the Building Blocks in the PTC Cloud
Upgrading the Building Blocks in the PTC Cloud
To upgrade the building blocks in a PTC Cloud deployment scenario, complete the steps in the following sections:
Pre-Upgrade Activities
Complete the following steps before beginning the upgrade:
If you have customized any of the building blocks, back up your customizations.
Localization tables are overwritten during an upgrade. If you have customized tokens in any localization tables, export the customized localization tables before performing the upgrade. The exported localization tables can be imported after the upgrade is complete to retain your modifications.
Upgrading ThingWorx and the Building Blocks
In a PTC Cloud deployment scenario, your database, ThingWorx Platform, and the building blocks are all upgraded for you by PTC in the PTC Cloud. For more information, see the PTC Cloud Engagement Guide.
Post-Upgrade Activities
After the building blocks have been successfully upgraded and before making the updated system available to users, complete the following steps:
1. If you have customized the building blocks, refer to Customization and Upgrade to address any impact to your customizations resulting from the upgrade.
2. Import any customized localization tables that you exported from ThingWorx Composer before upgrading.
3. Recommend that users clear the browser cache on any client machines.
Upgrading Custom Building Blocks
You can upgrade your custom building blocks after the PTC-provided building blocks have been upgraded.
* 
When code changes are made to custom building blocks, be sure to update the componentVersion property of the building block extension before creating the extension package. This property is found under Properties and Alerts on the entry point Thing for the building block in ThingWorx Composer.
This updated componentVersion property is required to successfully upgrade the custom building blocks.
To upgrade your custom building blocks, complete the following steps:
1. In ThingWorx Composer, import the new versions of your custom building block extensions.
2. Get the configuration parameters for the UpgradeSolution service.
a. In ThingWorx Composer, navigate to the PTC.Base.Manager Thing.
b. Under Services, find and execute the GetSolutionUpgradeConfigurationParameters service. The service output is a JSON containing the configuration parameters needed for the UpgradeSolution service, dynamically based on the set of building blocks that are present. The service output JSON is similar to the following:
{
"databaseUser": {
"types": [
"STRING"
],
"description": "Name of the database user used for DPM database Thing",
"optional": false
},
"automatedMigration": {
"types": [
"Boolean"
],
"description": "When TRUE, the MigrateSolution service is automatically called by the UpgradeSolution service after the upgrade action completes. When FALSE, the MigrateSolution service must be manually executed.",
"optional": false
},
"databasePassword": {
"types": [
"STRING"
],
"description": "Password of the database user used for DPM database Thing",
"optional": false
},
"databaseJDBCString": {
"types": [
"STRING"
],
"description": "JDBC Connection String for the DPM database Thing",
"optional": false
},
"databaseThing": {
"types": [
"STRING"
],
"description": "The default database thing (PTC.DBConnection.SQLThingDatabase)",
"optional": true
}
}
c. Copy the JSON returned in the service output and paste it into a text editor.
d. Edit the JSON, replacing the content between the braces for each configuration parameter with the value specific to your site.
databaseUser—The login name of the database user with system administration rights.
databasePassword—The login password for the database user with system administration rights.
databaseJDBCString—The JDBC connection string for the building blocks database.
databaseThing—The default database Thing (PTC.DBConnection.SQLThingDatabase).
automatedMigration—When this value is true, the MigrateSolution service is automatically executed, migrating all solution data to the updated database schema. This migration can take a long time, depending on the amount of data to be migrated. When this value is false, the MigrateSolution service is not automatically executed and must be manually executed at a later time.
The following is an example of the input JSON:
{
"databaseUser": "DPMadmin",
"databasePassword": "945DaTaBase!39525",
"databaseJDBCString": "jdbc:sqlserver://localhost:1433;databaseName=dpmdb",
"databaseThing": "PTC.DBConnection.SQLThingDatabase",
“automatedMigration”: true
}
3. Run the UpgradeSolution service, using the edited JSON from step 4.d as the config input parameter for the service.
When the service completes, the output displays an infotable listing the building blocks that were upgraded, deployed, and migrated (if the MigrateSolution service was automatically run), and their configuration status: Successful, Not Processed, or Error. The service stops if an error is encountered while the service processes a building block. That building block’s status is shown as Error, and the remaining building blocks have a Not Processed status.
If any building blocks have an Error or Not Processed status, complete the following troubleshooting steps:
a. Ensure the database credentials specified in the JSON are valid, then execute the UpgradeSolution service.
b. If any building blocks still have an Error or Not Processed status in the service output, review the ThingWorx Application and Script error logs and address any errors found there. Then execute the UpgradeSolution service.
Was this helpful?