Upgrading from ThingWorx Apps 8.5.2 to 9.0.0
To upgrade from ThingWorx Apps 8.5.x to ThingWorx Apps 9.0.0, complete the steps in the following sections:
Before Beginning the Upgrade Process
Before you begin upgrading, review the following information:
• ThingWorx 9.0 system requirements. For more information, see the 9.0 System Requirements in the ThingWorx Help Center.
• Customizations to ThingWorx Apps are impacted by the upgrade process. For more information, see Upgrade and Customizations.
Before Upgrading ThingWorx
Complete the following steps before upgrading ThingWorx to 9.0:
1. If you have customized any localization tables, export the customized localization tables before performing the upgrade. Localization tables are overwritten during an 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.
2. Restart the ThingWorx server.
Upgrading ThingWorx Apps
Complete the following steps to upgrade ThingWorx Apps to 9.0:
1. Ensure that you are logged in as the Administrator user. Using a different user from the Administrator user group to perform the upgrade results in import failures.
2. Import the ThingWorx Apps extensions, as described in steps 2 through 4 of Import the
Extension Files. Your data and connections are automatically preserved.
 |
Do not update the ThingWorx Remote Access Extension (RAE) at this time.
|
3. Import any optional extensions as described in Import Optional Extensions.
|
|
• The optional ThingWorx-Apps-<version>-extension-factory-demo extension that is new for 9.0 cannot be imported until after the ThingWorx server has been restarted.
• The optional ThingWorx-Rockwell-FT-MES-8-5-0-Extension-Bundle is supported with ThingWorx Apps 9.0. If this extension was already present on your 8.5.x system, it does not need to be imported again after upgrading to 9.0.
|
4. Restart the ThingWorx server.
5. Update the ThingWorx Remote Access Extension (RAE) present in ThingWorx by importing the supported version for the 9.0.0 release. You can find the compatible version of the ThingWorx Remote Access Extension in the "ThingWorx Extensions" section of the release matrix in Release Advisor for your installed version of ThingWorx.
6. Restart the ThingWorx server.
7. Clear your browser cache.
8. Complete steps 1 through 6 of the post import database configuration steps as described in Post Import
Database Configurations.
9. Migrate your data.
a. In ThingWorx Composer, open the PTC.SCA.SCO.OAMigrator Thing.
b. Under Services, execute the MigrateFrom_8_5_2_To_9_0_0 service. The service has completed successfully when "No results" displays in the service output pane.
10. If you have equipment with properties that are bound to KEPServerEX tags using the previous local-to-local binding implementation, and you want to take advantage of the new remote binding implementation, complete the following steps. This updates the property bindings to use the new remote binding implementation on all equipment for which these steps are performed.
For more information about the implementation change for binding properties to KEPServerEX tags, see ThingWorx Apps 9.0.0 Release Notes.
a. Ensure that any equipment which has properties bound to KEPServerEX tags implements the IndustrialThingShape, either directly on the equipment Thing itself, in the Thing Template for the equipment type, or in a Thing Template inherited by the equipment type. Once the IndustrialThingShape is added to a Thing or Thing Template, it cannot be removed. Equipment implementing the IndustrialThingShape can remotely bind properties only to KEPServerEX tags.
Before adding IndustrialThingShape to the Thing Template for an equipment type, consider whether all equipment of that type binds properties to KEPServerEX tags. If this is the case, then IndustrialThingShape can be added to the Thing Template. If some equipment must remotely bind properties to a non-KEPServerEX data source, such as to Edge MicroServer (EMS) devices, consider creating a separate equipment type to use for that equipment, or add IndustrialThingShape only to the individual equipment Things which bind properties to KEPServerEX tags.
Update the appropriate equipment Things or Thing Templates to implement the Thing Shape.
|
|
Equipment using the PTC-provided Asset equipment type should only have the IndustrialThingShape added if that equipment does not need to bind properties to Edge MicroServer (EMS) devices. For more information, see Connecting Assets to Edge MicroServer (EMS).
|
b. Ensure that the Thing Templates for any custom equipment types which have properties bound to KEPServerEX tags inherit one of the following Thing Templates: RemoteThing, RemoteThingWithFileTransfer, RemoteThingWithTunnels, or RemoteThingWithTunnelsAndFileTransfer. For more information, see Creating Custom Thing Templates for Equipment Types.
c. In ThingWorx Composer, open the PTC.SCA.SCO.MigrationUtility Thing.
d. Under Services, execute the MigrateLocalKepServerBindingsToRemoteBindings service. This service migrates the local-to-local property bindings on equipment Things to remote property bindings for all equipment of the specified equipment types which implement the IndustrialThingShape. Properties inherited by the equipment Things from Thing Templates or Thing Shapes, which are locally bound to KEPServerEX tags on the Thing Templates or Thing Shapes, continue to be locally bound, and are not impacted by the migration service. Status expressions, trends, and alerts which use KEPServerEX tags continue to be locally bound, and are not impacted by the migration service.
In the equipmentType input table for the service, add each equipment type for which you want to migrate the property bindings. The value entered must match EquipmentType value for the equipment type as it appears in the EquipmentTypeSettings configuration table on the PTC.Factory.C_LaunchPointConfigurationThing_[ReleaseVersion] Thing. The optional overrideKepServerThingName field for each equipment type replaces the KEPServerEX connection that is used for the bound properties.
Consider the following guidelines for when to set the overrideKepServerThingName field for an equipment type:
▪ If you use a single KEPServerEX connection for all equipment of an equipment type, leave the overrideKepServerThingName field blank.
▪ If you have multiple KEPServerEX connections, but each piece of equipment has properties bound only to a single KEPServerEX connection, leave the overrideKepServerThingName field blank.
▪ If you have multiple KEPServerEX connections, and any equipment has properties bound to more than one KEPServerEX connection, determine the KEPServerEX connection to which you want to bind the equipment of each such equipment type. Select the name of that KEPServerEX connection from the overrideKepServerThingName field. A piece of equipment can have properties bound to tags on only one KEPServerEX connection. Ensure that the tags from the other KEPServerEX connections are present on the chosen KEPServerEX connection.
The service has completed successfully when "No results" displays in the service output pane.
11. Prepare to add foreign keys to the database by finding and cleaning up any bad data. Bad data is existing data that would violate referential integrity once foreign keys are added to the database.
a. In ThingWorx Composer, open the PTC.SCA.SCO.DatabaseManager Thing.
b. Under Services, execute the ForeignKeyDataIntegrityReport service. The output of this service is an infotable listing each Data Shape name and referencing field that need to be addressed.
If there is no bad data found, the service output is empty. Proceed to step 12.
c. Execute the GetFailedDataForForeignKey service, providing as input a Data Shape and referencing field returned by the ForeignKeyDataIntegrityReport service. The output of this service is an infotable listing up to 500 database records with bad data.
d. Address each bad data instance as appropriate for your system: delete the record, set the referencing field value to null (if allowed), or update the record so that the referencing field has a valid value for the foreign key.
|
|
For advanced database administrators, the GetDataShapeSqlQuery service on the PTC.SCA.SCO.DatabaseManager Thing returns an SQL query that can be used in direct database queries.
|
e. Repeat steps c and d until no further bad data is found.
12. Add foreign keys to the database.
a. In ThingWorx Composer, open the PTC.SCA.SCO.OAMigrator Thing.
b. Under Services, execute the following services, in the order listed:
▪ MigrateDropIndexes
▪ MigrateAddForeignKeys
▪ MigrateAddIndexs
Each service has completed successfully when "No results" displays in the service output pane.
13. The MPMLink OData Connector Thing (PTC.SCA.SCO.MPMLink_ODataConnector) has been updated for 9.0, and it is no longer necessary to make a duplicate Thing on which to perform your configurations. If you use Operator Advisor to convert process plans from Windchill MPMLink, configure and use the MPMLink OData Connector Thing that is provided with ThingWorx Apps 9.0, rather than retaining a configured duplicate from a past release. For more information, see Configuring a Connection to Windchill for Process Plan Conversion.
14. The process for mapping Windchill attributes to Operator Advisor properties for process plan conversion has changed in 9.0. If you had overridden the TranslateODataBOPToWDJson service to specify mapping of custom Windchill attributes in ThingWorx Apps 8.5.x, those mappings must be re-done after upgrading to ThingWorx Apps 9.0, following the new mapping process. For more information, see Supporting Windchill Custom Attributes.
15. If you customized your ThingWorx Apps, refer to Upgrade and Customizations to address any impact to your customizations resulting from the upgrade.