Unified Typing Migration Tool Basics

Before you begin using this tool, you need to know the key concepts and capabilities
described in related guides.

In this section:

 Related Guides

 About the Unified Typing Migration Tool

Related Guides
Before using this tool, you need to understand the basic concepts and capabilities of
the 3DEXPERIENCE platform.

Walks you step-by-step, and component by component, through a full,

3DEXPERIENCE
on-premises installation and deployment of the 3DEXPERIENCE
platform Installation Roadmap
platform.

About the Unified Typing Migration Tool

Unified Typing is the default typing mode as of R2014x and it is the only mode supported
starting R2018x. If you had previously created data in former typing mode, it is recommended
that you migrate this data to have your data consistent with the typing mode you operate. It is
not mandatory to do so but it is highly recommended. You can also migrate the old data when
you are ready to do so. To help you with this migration, a JPO (Java Programming Object) was
developed.
This page discusses:
 Migration Principles

 Recommendations

Migration Principles
The migration process is broken down into four main phases:
Customer Files Generation Phase

Generates CSV files that can be modified by customers to set target types and
attributes mapping. It is triggered using the –GenFiles or the –GenAllFiles option.
The migration process cannot be performed if this phase is not executed.

1
 The –GenFiles option must be run each time new objects to migrated are added to
the database. If the database is not populated with new objects, it is not necessary
to run this option again, even if the database is restored.
Migration Phase

The migration phase is made up of five steps:

Triggered
Steps Comment
by

Step_
-step 1 Adds object migration extensions to the objects attributes to migrate.
1

Step_ Changes the object type, updates semantic relations (paths) and
-step 2
2 exchange status objects.

Step_ Adds customer and applicative extensions. Customer extensions to add

-step 3
3 are read from CSV files.

Step_ Does attributes mapping from customer extensions and applicative

-step 4
4 extensions.

Step_
-step 5 Removes migration extensions.
5

Note: All the steps of this second phase can be performed in a single execution
using the -step All option and can be explicitly committed using the –
commit option.

Path Update Phase

In single process mode, paths were updated at step 2. In multi-process mode, paths
are no longer updated on the fly at step_2. They are logged in a ".ntmpath" file
created in the NTMPathFiles folder.
Note: The NTMPathFiles folder is located in the given migration directory (use the -
dir option).

Each second step (step_2) of a migration loop generates a “.ntmpath” file that may
be empty if there is no path to update. You must therefore update the paths
launching the tool using the "-updateImpacted <N>" option, after migrating all data.
Cleaning Phase

Updates exchange status objects, updates and cleans migration information related
to the migrated objects. It is triggered using the –Clean option and can be explicitly
committed using the –commit option.

Tips:
 In guide mode, you can limit the number of types to manage. It is useful to

2
 test a migration for some types. You can also limit the number of objects
to migrate. It can be useful if you want to test the migration on a reduced
number of objects.

 The tool does not migrate all the objects in a single transaction, the
migration is performed in several transactions. The number of objects per
transaction can be controlled using the appropriate option.

 By default the changes are not committed, it works as a simulator. The

simulation mode can be used to check if the mapping between V1 and V2
is correct. The result of the simulation is MQL files. The -commit option
is to be used with -Step and -Clean only.

 When simulating the migration, the transactions are not committed: the
memory consumption increases and the tool can fail. In simulation mode,
it is recommended that you limit the number of objects.

 The generated MQL scripts shall not be run manually by the administrator. It
would break the migration. They can be used and archived to keep a trace
of the migration process.

Note: Before beginning the migration, it is highly recommended that you back up the database
and shut down the application server.

Recommendations
This section provides you with recommendations related to the migration itself.

Before the Unified Typing Migration

 Deactivate the unique keys created by the user in Model Customization.

 Run all usual migrations.

 VPLMDataMigration

 DMC migration (if it exists on the previous level) OR

 baseline behavior Parameterization (if it exists on the previous level).

 Prepare your data as described in Prepare the Data.

 Always make a backup of your database before launching the Unified Typing Migration
using emxNewTypingMigrationProgram.

 Make sure the database is optimized.

 Validate the indexes (MQL).

3
  If possible, monitor the database and, if needed, add SQL indexes when possible.

 Never add any line to the CSV sheets.

Validations and Checks Before the Full Unified Typing Migration

It is recommended that you validate the use of the Unified Typing Migration Tool using sample
data before migrating the complete database:

 Always run the –GenFiles option first.

 In CSE cases, the modification of CSV sheets must be performed at this stage. Save the
new updated CSV files at the GenFiles directory location. Never modify CSV files after
the migration steps are started ( step -1-5, step -all).

Note: Data are migrated when migration step #5 has been executed using the -commit option.

 Run some tests using the -Types and -limit options for objects of given types.

 If you do not use the -commit option, use -limit with a small number to prevent the

computer from running out of memory during the validation stage.

 Use the -Step <x> option where x=1 to 5 for tests purposes only.

 Check the subset of migrated data in 3DEXPERIENCE native apps.

 Once you are done with the tests, restore the database to perform the full migration.

During Full Unified Typing Migration

 Use the -Step All option to run the migration along with the -commit option. Do not run it
step by step.

 When the migration is started, including -GenFiles, do not add new data to the database.

 Break down the migration into several runs according to the number of objects for each
type using the -Types option.

 Run the -Clean option only at the very end of the process. Do not run this option after
each type migration.

 If possible, monitor the database in real time and, if needed, add SQL indexes when
possible.

After the Migration

 Reactivate the unique keys you may have deactivated before running the migration.

Note: You may not be able to reactivate the unique keys depending on the user's
specifications.

4
About the Unified Typing Migration Tool

Unified Typing is the default typing mode as of R2014x and it is the only mode supported
starting R2018x. If you had previously created data in former typing mode, it is recommended
that you migrate this data to have your data consistent with the typing mode you operate. It is
not mandatory to do so but it is highly recommended. You can also migrate the old data when
you are ready to do so. To help you with this migration, a JPO (Java Programming Object) was
developed.
This page discusses:
 Migration Principles

 Recommendations

Migration Principles
The migration process is broken down into four main phases:
Customer Files Generation Phase

Generates CSV files that can be modified by customers to set target types and
attributes mapping. It is triggered using the –GenFiles or the –GenAllFiles option.
The migration process cannot be performed if this phase is not executed.

The –GenFiles option must be run each time new objects to migrated are added to
the database. If the database is not populated with new objects, it is not necessary
to run this option again, even if the database is restored.
Migration Phase

The migration phase is made up of five steps:

Triggered
Steps Comment
by

Step_
-step 1 Adds object migration extensions to the objects attributes to migrate.
1

Step_ Changes the object type, updates semantic relations (paths) and
-step 2
2 exchange status objects.

Step_ Adds customer and applicative extensions. Customer extensions to add

-step 3
3 are read from CSV files.

Step_ Does attributes mapping from customer extensions and applicative

-step 4
4 extensions.

5
 Triggered
Steps Comment
by

Step_
-step 5 Removes migration extensions.
5

Note: All the steps of this second phase can be performed in a single execution
using the -step All option and can be explicitly committed using the –
commit option.

Path Update Phase

In single process mode, paths were updated at step 2. In multi-process mode, paths
are no longer updated on the fly at step_2. They are logged in a ".ntmpath" file
created in the NTMPathFiles folder.
Note: The NTMPathFiles folder is located in the given migration directory (use the -
dir option).

Each second step (step_2) of a migration loop generates a “.ntmpath” file that may
be empty if there is no path to update. You must therefore update the paths
launching the tool using the "-updateImpacted <N>" option, after migrating all data.
Cleaning Phase

Updates exchange status objects, updates and cleans migration information related
to the migrated objects. It is triggered using the –Clean option and can be explicitly
committed using the –commit option.

Tips:
 In guide mode, you can limit the number of types to manage. It is useful to
test a migration for some types. You can also limit the number of objects
to migrate. It can be useful if you want to test the migration on a reduced
number of objects.

 The tool does not migrate all the objects in a single transaction, the
migration is performed in several transactions. The number of objects per
transaction can be controlled using the appropriate option.

 By default the changes are not committed, it works as a simulator. The

simulation mode can be used to check if the mapping between V1 and V2
is correct. The result of the simulation is MQL files. The -commit option
is to be used with -Step and -Clean only.

 When simulating the migration, the transactions are not committed: the
memory consumption increases and the tool can fail. In simulation mode,
it is recommended that you limit the number of objects.

 The generated MQL scripts shall not be run manually by the administrator. It
would break the migration. They can be used and archived to keep a trace

6
 of the migration process.

Note: Before beginning the migration, it is highly recommended that you back up the database
and shut down the application server.

Recommendations
This section provides you with recommendations related to the migration itself.

Before the Unified Typing Migration

 Deactivate the unique keys created by the user in Model Customization.

 Run all usual migrations.

 VPLMDataMigration

 DMC migration (if it exists on the previous level) OR

 baseline behavior Parameterization (if it exists on the previous level).

 Prepare your data as described in Prepare the Data.

 Always make a backup of your database before launching the Unified Typing Migration
using emxNewTypingMigrationProgram.

 Make sure the database is optimized.

 Validate the indexes (MQL).

 If possible, monitor the database and, if needed, add SQL indexes when possible.

 Never add any line to the CSV sheets.

Validations and Checks Before the Full Unified Typing Migration

It is recommended that you validate the use of the Unified Typing Migration Tool using sample
data before migrating the complete database:

 Always run the –GenFiles option first.

 In CSE cases, the modification of CSV sheets must be performed at this stage. Save the
new updated CSV files at the GenFiles directory location. Never modify CSV files after
the migration steps are started ( step -1-5, step -all).

Note: Data are migrated when migration step #5 has been executed using the -commit option.

 Run some tests using the -Types and -limit options for objects of given types.

 If you do not use the -commit option, use -limit with a small number to prevent the

computer from running out of memory during the validation stage.

7
  Use the -Step <x> option where x=1 to 5 for tests purposes only.

 Check the subset of migrated data in 3DEXPERIENCE native apps.

 Once you are done with the tests, restore the database to perform the full migration.

During Full Unified Typing Migration

 Use the -Step All option to run the migration along with the -commit option. Do not run it
step by step.

 When the migration is started, including -GenFiles, do not add new data to the database.

 Break down the migration into several runs according to the number of objects for each
type using the -Types option.

 Run the -Clean option only at the very end of the process. Do not run this option after
each type migration.

 If possible, monitor the database in real time and, if needed, add SQL indexes when
possible.

After the Migration

 Reactivate the unique keys you may have deactivated before running the migration.

Note: You may not be able to reactivate the unique keys depending on the user's
specifications.