Upgrading DPM from 1.2.0 to 1.2.1 Using the PTC Software Downloads Page
 |
If you are upgrading from DPM 1.1.0, you must first upgrade to DPM 1.2.0 before upgrading to DPM 1.2.1. Direct upgrade from DPM 1.1.0 to DPM 1.2.1 is not supported.
|
To upgrade from DPM 1.2.0 to DPM 1.2.1 using the PTC Software Downloads page, complete the steps in the following sections:
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.1, 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
1. Download the new version of DPM from the PTC Software Downloads page. Complete the following steps:
a. Navigate to the PTC Software Download page at the following URL: https://support.ptc.com/appserver/auth/it/esd/index.jsp.
b. Select ThingWorx Foundation.
c. Expand the following folders: > .
d. Download the DPM-1-2-1 extension package ZIP file.
2. Import the DPM solution. To import the DPM solution, 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. In ThingWorx Composer, navigate to > .
c. On the Import window, select Extension from the Import Option list.
d. Under File name, click Browse. Navigate to and select the extension package ZIP file that you downloaded in the previous section.
e. Click Import. When the import finishes, click Close.
f. View the DPM solution extensions after import by navigating to > .
3. Restart the ThingWorx server.
4. 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
}
}
"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
}
"databaseUser": "DPMadmin",
"databasePassword": "945DaTaBase!39525",
"databaseJDBCString": "jdbc:sqlserver://localhost:1433;databaseName=dpmdb",
"databaseThing": "PTC.DBConnection.SQLThingDatabase",
"overrideComponentDeploymentState": false,
“automatedMigration”: true
}
5. 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
6. 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.
|
7. If you have customized DPM, refer to Customization and Upgrade to address any impact to your customizations resulting from the upgrade.
8. If you increased the script timeout setting before upgrading DPM, return it to its previous setting.
9. Review the initial administration activities, and perform any activities needed for new functionality. For more information, see Initial DPM Administration Activities.
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.
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. If you will be using the Time Loss Analytics functionality within DPM, complete the following steps:
a. If you did not already do so on your DPM 1.2.0 system, 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. If you did not already do so on your DPM 1.2.0 system, 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. Ensure that the PTC.TimeLoss.ModelLogic_TS Thing Shape is added 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.
7. Recommend that users clear the browser cache on any client machines.