Upgrading DPM from 1.1.0 to 1.2.0 in the PTC Cloud
To upgrade DPM from 1.1.0 to 1.2.0 in a PTC Cloud deployment scenario, complete the steps in the following sections:
 |
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.
|
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 DPM
In a PTC Cloud deployment scenario, your database, ThingWorx Platform, and DPM are all upgraded for you by PTC in the PTC Cloud. For more information, see the PTC Cloud Engagement Guide.
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.
4. Review the initial administration activities, and perform any activities needed for new functionality. For more information, see Initial DPM Administration Activities.
5. 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.0, 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.
6. Recommend that users clear the browser cache on any client machines.