Overview

Syndeia 3.7.1 brings significant improvements to Windchill integration in the Syndeia Clients (Cameo plugin and Rhapsody plugin). In addition to an improved Windchill tree view and related capabilities in the Syndeia Clients, there are two key structural changes as presented below.

First, the Windchill integration on Syndeia Client supports custom mappings for bi-directional model transformations and synchronization, and now works similarly to the recent integrations, e.g., Codebeamer, Polarion, SOLIDWORKS PDM, and Azure DevOps. Refer to the revised Windchill tutorials for 3.7.1 here: Part 4 - SysML-Windchill Capabilities.

Second, the Windchill integration on the Syndeia Client does not require the Windchill InfoEngine jar files that were assembled in the libWC folder and copied over to the Syndeia Client (Cameo plugin or Rhapsody plugin) install folders - see Using Syndeia with Windchill. This step is no longer needed and greatly simplifies the use of Windchill integration in Syndeia Clients. Starting with 3.7.1, Syndeia Client directly communicates with Syndeia Cloud Windchill service that uses Windchill’s REST API.

New and existing users of Windchill integration on the Syndeia Client can directly leverage this new capability.

However, existing users who have been using the old Windchill integration (until the 3.7 release) may have created relations/connections between SysML and Windchill artifacts in a digital thread project. Those relations will need to be migrated to the new relations to support custom mappings. On this page, we present a Windchill Relations Migration utility available with the Syndeia 3.7.1 release to upgrade existing relations created in Syndeia Client until the 3.7 release to the new relations that can support custom mappings and can work with the Syndeia Cloud and Windchill REST API. Note that the subject of this discussion is the inter-model relations between SysML and Windchill artifacts that are managed in Syndeia, and not the intra-model relations in a SysML model (e.g., Part Property or Dependency) or for a Windchill part (e.g., Uses and Occurrences).

Specifically, the Windchill Relations Migration utility will migrate any relations in a digital thread project of the following types: REFERENCE_CONNECTION and BLOCK_WC_PART_MODEL_TRANSFORM_CONNECTION, created using Syndeia Clients (Cameo / Rhapsody plugin) to relations of corresponding newer types: RELATION and GENERIC_MODEL_TRANSFORM_CONNECTION, respectively. Once the migration is complete, Syndeia users will be able to use custom mappings on the migrated SysML-Windchill relations.

This action is irreversible.

Prerequisites

1. Deployment server:

   1. The user performing this can SSH into the machine where Syndeia Cloud is deployed.

   2. If you have enabled HTTPS, please ensure you have updated the web-gateway URL in the lagom.services section of the devops' conf/application.conf file beforehand (see Securing Syndeia Cloud for more details)

2. Syndeia Cloud:

   1. The Syndeia Cloud user used for migration must be super.user and must have the following permissions on the Digital Thread Project for which the migration is being performed (To know how to assign a user permissions on a Digital Thread Project, check Users for a Digital Thread Project):

      1. READ

      2. RELATION_WRITE

   2. A Syndeia Cloud user with BASELINE_WRITE permission on the Digital Thread Project for which the migration is being performed. (Note that this is NOT required to run the action itself, but for two optional, though recommended, pre- and post-action steps.)

3. Windchill:

   1. For each Windchill repository involved in the migration, the following must be in place:

      1. A valid Windchill user with read access to the repository.

      2. The credentials for that repository's authentication type (Basic or OAuth) must be known.

Migrating Windchill Relations

Context

This action runs in the context of a Digital Thread Project and should therefore be run for each Digital Thread Project that may contain Windchill relations requiring migration. For more information, see Windchill Relations Migration (Syndeia 3.7.1).

Pre-action step (Optional, though recommended)

Before running this action for a given Digital Thread Project, it is recommended to create a Baseline so the results can be compared before and after the migration. To check how to create a Baseline and compare Baselines for a Digital Thread Project, see Baselines - Digital Thread Dashboard

Action steps

1. SSH into the server where Syndeia Cloud is installed.

2. Edit the application.conf file for DevOps:

   1. Navigate to the directory $SC_HOME/devops-3.7.1/conf

   2. Make the following changes in the application.conf file and save it:

      1. Add Mapping ID syndeia.migrate.windchill.model-transform.mapping-id to be used for Model Transform relations (Reference: L13 in the below snippet)

      2. Add credentials for all the participating Windchill repositories under the syndeia.migrate.windchill.repos section (Reference: L20-34 in the below snippet). To know participating Windchill repositories, see Reports - Digital Thread Project

         syndeia { migrate { schema = ${?syndeia.migrate.schema} windchill { # Digital Thread Project Key dtp.key = ${?syndeia.migrate.windchill.dtp.key} # Model Transform attributes model-transform.mapping-id = ${?syndeia.migrate.windchill.model-transform.mapping-id} # Add details for all participating Windchill repositories # If any repository configuration is missing, the utility will list the missing repositories # Supported auth types = [ basic, oauth ] # URL keys must be quoted repos { # Repository 1 "https://test.org.com/Windchill" { authType = "basic" username = "value" password = "value" } # Repository 2 "https://test2.org.com/Windchill" { authType = "oauth" } # add configuration for more windchill repositories here ... } } } }

3. Run the migrate-windchill-relations action:

   1. Navigate to the directory $SC_HOME/devops-3.7.1/bin (e.g.. /opt/icx/syndeia-cloud-current/devops-3.7.1/bin)

   2. Run the following command to start the sequential migration of Windchill relations in a Digital Thread Project:

      ./devops \ -Dsyndeia.client.action=migrate-windchill-relations \ -Dsyndeia.migrate.windchill.dtp.key=<digital_thread_project_sKey> \ -Dsyndeia.client.username=<username> \ -Dsyndeia.client.password=<password> \ -Dconfig.file=/opt/icx/syndeia-cloud-current/devops-$SC_snapshot_version/conf/application.conf

      … where,

      1. digital_thread_project_sKey: the Syndeia key (sKey) of the Digital Thread Project that you want to perform this migration for (e.g, DT1, DT2, DT3, etc.)

      2. username: Syndeia Cloud user’s username (must always be super.user for this action)

      3. password: Syndeia Cloud user’s password for the provided username

5. Once the command is run, the Syndeia DevOps client will systematically start migrating the relations.

   1. On a successful run of the command,

      1. The following message will be seen at the end of execution in the console:

         [...] 07:10:34.449 [info] com.intercax.syndeia.migrate.WindchillRelationMigrate [] - Total number of relations = 10 07:10:34.450 [info] com.intercax.syndeia.migrate.WindchillRelationMigrate [] - Number of relations migrated successfully = 10 07:10:34.450 [info] com.intercax.syndeia.migrate.WindchillRelationMigrate [] - Number of relations that failed to migrate = 0 07:10:34.451 [info] com.intercax.syndeia.migrate.WindchillRelationMigrate [] - Total time taken for migration = 86 seconds 07:10:34.508 [info] akka.actor.CoordinatedShutdown - Running CoordinatedShutdown with reason [ClientStoppedReason] 07:10:34.541 [info] com.intercax.syndeia.cli.SyndeiaCli [] - Action ran successfully (with a return code: 0).

      2. Complete sample output of a successful run is availble at the end of this section.

   2. If the run encounters any error:

      1. Any errors encountered during the process will be printed along with detailed error messages to assist with debugging.

      2. If “Number of relations that failed to migrate“ shows a value greater than 0, it will also show the keys of the relations for which the migration failed. In such cases, you can run the action again, and it will attempt to migrate the relations that failed before.

Post-action step (Optional, though recommended)

After running this action for a given Digital Thread Project, it is recommended to create a Baseline and compare the results with the baseline created before the migration. To check how to create a Baseline and compare Baselines for a Digital Thread Project, see Baselines - Digital Thread Dashboard

Open