Getting Started with DPM > Upgrading DPM > Upgrading DPM on a Customer-Owned System or Cloud > Upgrading DPM from 1.1.0 to 1.2.0 Using Solution Central
Upgrading DPM from 1.1.0 to 1.2.0 Using Solution Central
To upgrade DPM 1.1.0 to DPM 1.2.0 using Solution Central, complete the steps in the following sections:
* 
PTC recommends that you upgrade on a test system first, before moving to production.
Solution Central is the recommended tool for moving your deployment and customizations between ThingWorx environments, for example from a test environment to a production environment. For more information, see the ThingWorx Solution Central Help Center.
Before Beginning the Upgrade Process
Before you begin the upgrade process, review the following information:
• ThingWorx 9.3 System Requirements in the ThingWorx Help Center.
• Upgrading ThingWorx in the ThingWorx Help Center.
• Customizations to DPM are impacted by the upgrade process. For more information, see Customization and Upgrade.
Before Upgrading ThingWorx
Before upgrading ThingWorx, complete the following steps:
• 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
Complete the following steps:
1. Upgrade your ThingWorx installation. For more information, see Upgrading ThingWorx in the ThingWorx Help Center.
For ThingWorx releases that are compatible with DPM 1.2.0, see DPM System Requirements.
2. Restart the ThingWorx server.
Before Upgrading DPM
Before upgrading DPM, review the following information and perform any necessary actions:
• DPM will be unavailable during the upgrade process, meaning that production data cannot be entered during that time. PTC recommends that you upgrade on a test system first, before upgrading your production system. This will help you determine how long your production system will be unavailable.
• Increase the duration of the script timeout setting before performing the upgrade. This setting can be returned to its previous value after the upgrade is complete. To update the script timeout setting, a ThingWorx administrator must complete the following steps:
1. On the ThingWorx server, navigate to the ThingWorxPlatform folder.
2. Open the platform-settings.json file in a text editor.
3. Find and update the ScriptTimeout setting to 12000.
4. Save and close the platform-settings.json file.
5. Restart the ThingWorx server.
* 
If a message similar to the following appears in your script log, repeat the steps above to further increase the ScriptTimeout setting:
[message: Execution of Script terminated after : 12000 seconds. Timeout configured for 12000 seconds.]
For more information, see platform-settings.json Configuration Details in the ThingWorx Help Center.
Upgrading DPM
To upgrade DPM, complete the following steps:
1. Deploy the new version of DPM using Solution Central.
* 
If you are deploying DPM on a ThingWorx HA system, it is recommended to take the cluster down to a single instance, install the extensions, and then scale the cluster back up. This will be more performant and will prevent eventual consistency issues since the new extensions will be loaded by each server as they start. For more information, see Managing ThingWorx Extensions in ThingWorx HA in the ThingWorx Help Center.
To deploy the DPM solution to your ThingWorx instance using Solution Central, a ThingWorx administrator must complete the following steps:
a. Ensure that your license is installed in ThingWorx Composer. For more information, see this Technical Support Article in the PTC Knowledge Base.
b. Set up Solution Central. For more information, see Getting Started with Using Solution Central in the Solution Central Help Center.
c. Register your ThingWorx instance in Solution Central. For more information, see Registering Your ThingWorx Instance in the Solution Central Help Center.
d. In ThingWorx Composer, navigate to Manage > Solution Central > PTC Solutions.
e. Select the checkbox next to Digital Performance Management and click One-Click Deploy. A window opens listing all of the extensions to be deployed as part of the DPM solution.
f. Click Deploy All.
The extensions are downloaded and installed. This may take several minutes. You will be notified when the process completes.
For more information, see the ThingWorx Solution Central Help Center.
2. Restart the ThingWorx server.
3. 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
},
"overrideComponentDeploymentState": {
"types": [
"BOOLEAN"
],
"description": "If true, the current component deployment state is ignored and the DeployComponent service will be rerun.",
"optional": true
},
"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 DPM database.
▪ databaseThing—The default database Thing (PTC.DBConnection.SQLThingDatabase).
▪ overrideComponentDeploymentState—This value should false.
▪ 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",
"overrideComponentDeploymentState": false,
“automatedMigration”: true
}
4. Run the UpgradeSolution service, using the edited JSON from step 3.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. If an error is encountered while the service processes a building block, the service stops. 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 that the database credentials that are 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.
c. If any building blocks still have an Error or Not Processed status in the service output, update the JSON to include the following, and execute the UpgradeSolution service:
"overrideComponentDeploymentState": true
5. If the MigrateSolution service was not automatically executed by the UpgradeSolution service, execute the MigrateSolution service. This service does not have any required input parameters.
The service output, statuses, and troubleshooting steps for the MigrateSolution service are the same as those for the UpgradeSolution service, showing in step 4. Repeat the troubleshooting steps until all building blocks have a Successful status.
* 
The upgrade is not complete until the MigrateSolution service has been successfully executed. The upgraded system cannot be used until the data has been migrated.
Post-Upgrade Activities
After DPM has been successfully upgraded, and before making the updated system available to users, complete the following steps:
1. Aggregate the events in the database. Complete the following steps:
a. In ThingWorx Composer, navigate to PTC.OperationKPIImpl.EventsAggregationScheduler.
b. Under Services, execute the AggregateEvents service. This service may take some time to complete.
The service has successfully completed when the No results message displays in the output pane.
If the service encounters an error, address the error, then execute the service again.
2. If you have customized DPM, refer to Customization and Upgrade to address any impact to your customizations resulting from the upgrade.
3. Import any customized localization tables that you exported from ThingWorx Composer before upgrading ThingWorx.
4. If you increased the script timeout setting before upgrading DPM, return it to its previous setting.
5. Review the initial administration activities, and perform any activities needed for new functionality. For more information, see Initial DPM Administration Activities.
6. Update material names and the sites they belong to, as needed.
In DPM 1.1.0, individual materials could belong to only one site, and material names were required to be unique within each site. This means that there could be multiple materials with the same name, each belonging to a different site. In DPM 1.2, materials can now belong to one, many, or all sites, and material names must be unique across the enterprise. The data migration services handle materials with duplicate names as follows:
◦ The first material with a particular name that is encountered is migrated as-is.
◦ Subsequent materials with that same name have the site they belong to appended to their name during migration, in the format MaterialName_SiteName.
After the migration is complete, you can easily find these migrated duplicate materials by sorting or filtering the Materials table. You can edit the materials to change their names and add them to additional sites as needed. Any duplicate materials that you do not want to use can be disabled.
For example, in DPM 1.1.0, there are three materials named Material1 belonging to the Boston, London, and Berlin sites, respectively. The table below shows the material name and site for each in DPM 1.1.0, and the material name and site for each after the migration to DPM 1.2.0. In this example, the data migration services encounter Material1 belonging to the Boston site first.
Material Name and Site in DPM 1.1.0
Material Name and Site after Migration to DPM 1.2.0
Material1, Boston
Material1, Boston
Material1, London
Material1_London, London
Material1, Berlin
Material1_Berlin, Berlin
In the Materials table, you can filter for "Material1" to find all instances of these materials. If you want to use a single material named Material1 that belongs to all three sites, you can edit Material1 to add the London and Berlin sites, and disable Material1_London and Material1_Berlin.
7. If you will be using the Time Loss Analytics functionality within DPM, complete the following steps:
a. Run the SetAnalyticsServerPrefix service to connect the Time Loss Analytics functionality in DPM with the ThingWorx Analytics Server.
a. In ThingWorx Composer, navigate to the PTC.TimeLossImpl.Manager Thing.
b. Under Services, find and execute the SetAnalyticsServerPrefix service.
c. For the analyticsServerPrefix input parameter, enter the name of the Analytics Server Thing that was created during the Analytics Server installation. This is the Thing which implements the AnalyticsGateway Thing Template.
d. Click Execute.
b. Set the locale.token.prefix environment variable for the localization of the Time Loss Analytics functionality in DPM.
a. In the installation directory where your ThingWorx Analytics Server is installed, navigate to the config folder and open the system-environment-variables.properties file with any text editor.
b. Add the following line to the file:
locale.token.prefix=PTC.TimeLossAnalysis.
* 
system-environment-variables.properties
The period at the end of TimeLossAnalysis. must be included.
c. Save and close the system-environment-variables.properties file.
d. Restart your ThingWorx Analytics Server.
c. Add the PTC.TimeLoss.ModelLogic_TS Thing Shape as an implemented shape on the area Thing Template.
a. In ThingWorx Composer, navigate to the PTC.MfgModel.DefaultArea_TT Thing Template.
b. For the Implemented Shapes field, search for and add PTC.TimeLoss.ModelLogic_TS.
c. Click Save.
8. Recommend that users clear the browser cache on any client machines.
Was this helpful?