Contents

Classification Installation:................................................................................................................. 2
Prerequisites: ............................................................................................................................. 2
Install step by step ..................................................................................................................... 9
AppendixRevision History ...................................................................................................... 34
Classification Installation:
This manual will assist you when installing Routing Standard parts to TC classification in
Teamcenter Engineering TC9.1 and above. Though the primary use of this tool is to assist in
classifying routing catalog parts, it is more generic in nature and can be used to classify any
Standard catalog part (NX part family template part) as well.

Note: Read through the entire document first before starting the installation.

Prerequisites:

Setup needed
Valid TC server/portal installation - TC 9.1 and above.
Valid NX installation NX9.0 and above 64 Bit.
OS Win 7, Win XP supported.
RAM 4GB and above at least (not mandatory, but for good performance)
Make sure that your TC server is running before beginning the installation process.
Ensure that you are able to launch NX from the location specified in the
Classification-Installation_tc9.1.bat file. See details below in step 3.

NX and TC must be installed on the machine or via a mapped network drive.

A path like --- (\\servername\folder1) is supported
A network path like --- (\\servername\driveA\folder1) is not supported.

You may copy the classification_tool folder found under \UGII_BASE_DIR\ugroute_mech

to a location from where you would like to run the installation (typically where the TC server is
installed).
Assumptions and unknowns

The time taken for the installation of a given set of routing catalog parts to TC classification
depends on the number of template parts and family members each one contains.
The default naming rule for an Item inside TC database should match the naming rule used for the
members of each NX part family template part.

Types of Inputs Supported

The current tool accepts either of the below mentioned input methods for classifying the routing
standard parts to TC classification

Nested folder structure of routing standard parts and/or ptb files which needs to be
correctly created by the user.

Standard Routing PLV files For routing specific parts based on a valid routing PLV file.
 A generic xml file format. User needs to make sure that the xml file he provides as
an input is a valid xml file. An example xml file is provided for users to modify and
create their input files for installation purposes.

An already existing TC folder structure of standard parts. This is for users who have
non-classified catalog parts already existing in TC database and would like to use this
tool to classify them.

For the nested folder structure option, the user needs to create an appropriate nested folder
structure of the library parts and place the corresponding master template NX parts and the PTB
files in those folders. The top level folder which holds all the information of the parts and ptb files
is referred to as the Root folder. This folder structure needs to be preferably maintained for
subsequent upgrades of the existing installs. Log files and the PLMXML file which records the
install information will be saved in this root folder if its not read only, otherwise it will be saved
to C:\Temp.

Below is a picture which shows an example nested folder structure of the mechanical routing
library:

The NX template part and corresponding PTB file will be put under subfolders, for example,
Elbows, Caps and so on. One subfolder should contain one ptb and the corresponding NX part
family template part; otherwise the ICOs from different ptb files will get added to the same
CLASS in classification. An example nested folder structure that is routing_parts is provided
along with this tool for reference purpose. If a folder does not contain any part or ptb file it will
become an Abstract Class. All folders which contain a part and/or ptb file will become a
Storage Class in TC classification. Note that a folder can contain just an NX part family
template part (in this case all the ICO attributes are created based on the entries in the columns in
the internal part family spreadsheet) or just a ptb file also (for example, in the case of Overstocks
-- since they dont have an NX part file definition ). For Overstocks it is necessary that the PTB
files have a PART_NAME attribute defined in it. The name of a folder in this nested folder
structure would be the CLASS_ID of the Abstract or Storage class in TC classification.

From NX 9.0.2 the classification tool will support the addition of APPLIED attributes from the
routing PTB files to the ICOs as well.

The APPLIED characteristics section at the top of a routing part table (PTB) allows users to
specify a column to add to every row in the table. These are attributes which are supposed to be
applied to every member of the PTB file. Two examples are shown below.

Example 1
APPLIED
NAME CONNECTION_TYPE
FORMAT BUTT_WELD
END_OF_APPLIED

In the above example an attribute with name CONNECTION_TYPE and whose value is
BUTT_WELD is added to each and every ICO in classification as part of the installation.

Example 2
APPLIED
NAME DESCRIPTION
FORMAT Concentric Reducer []x[]x[] DIN 2616
COLUMNS D1 D2 S1
END_OF_APPLIED

For the above example if the PTB file has a member as shown below

!MEMBER_NAME NPS NPS_BRANCH D1 D2 S1 l WEIGHT

! FITTING_MATERIAL PART_NUMBER RKL PART_NAME
!
"RK_27_21_2" 20 15 26.9 21.3 2.3 38 0.2
"ST37-2" "RK_27_21_2" "ALL" "pipe_din_reducer_concentric_mm"
then the tool will add an attribute with name DESCRIPTION and whose value is Concentric
Reducer 26.9x21.1x2.3 DIN 2616 for the member RK_27_21_2 and so on for the remaining
members.
For more details regarding applied attributes formatting refer to NX Routing documentation.
Note that each of the APPLIED characteristic attribute will be added as STRING type and
HIDDEN status.

While giving a Standard Routing PLV file as input, the NX parts and ptb files will be obtained
from UGII_BASE_DIR\UGROUTE_MECH\metric\parts and UGII_BASE_DIR\
UGROUTE_MECH\metric\tables respectively.
Note that the out of the box provided routing PLV file (ugroute_mech_metric.plv) found in the
UGII_BASE_DIR\ UGROUTE_MECH\appview folder cannot be used as it is, since there may be
some nodes in the plv file for which parts/ptb files may be missing. Hence a sample of a smaller
version of a routing PLV file is provided as an example for reference. You need to make sure that
there are NX part and ptb files available in the above folders for the nodes referenced in the PLV
file before using this as the input option. If you intend to use the provided example PLV file for
installation then you need to copy the six provided NX part and PTB files from the
Option_PLV\metric folder to the corresponding folders as mentioned above in your NX
installation. If files already exist in your NX installation with the same name then first backup the
original files.

While giving generic xml format as input, it is assumed that the installation tool is run at least
once and has done both tasks that is; imported the NX template part in TC and also classified at
least one or some members in TC classification. Hence, this is a case of an upgrade for the user to
add additional members to the already existing template parts available in TC, and then classify
the new members in TC classification. In the TC database, the existing NX template items may
contain one or few members. In TC classification, the existing class may contain attributes and
few ICOs initially. It is also possible that the existing NX template items were not actually
installed by the tool but done manually by the user. In this situation also, the tool will also be able
to identify the template items and perform the upgrade of the additional members. For this, the
CLASS under which the members for the template part will get classified must also be present in
TC classification.

While giving an existing TC folder structure as input, all the Part Items (that is the NX part family
template parts) will be obtained from all existing folders under it. The information required for the
process of installing these to TC classification will be obtained from the internal part family
spreadsheet data of the NX Part family template parts in TC database. The root folder should
contain subfolders, but not Part Items (that is the NX part family template parts) directly under it.
This is because if such a situation is created then it will be created as a Group in TC classification,
and the Part Items cannot be classified under a Group.

The below picture shows how the user needs to arrange his NX template items under the root
folder in TC:
The left picture shows that the Part Item whose Item ID is 001389 and Item name is
pipe_din_stock_cunife_mm is correctly placed under a folder called DIN_CuniFE in TC.
Here DIN_CuniFe will become a Storage Class in TC classification.
The right picture shows that the Part Item whose Item ID is 001439 and Item name is
DIN2401,Axial_Compensator is placed directly under the root folder which is Routing parts
which is incorrect.
 Picture 1 Right folder structure in TC Picture 2 Wrong part location

Note that only the nested folder structure and the routing PLV file input options refer to a native
path as an input, while the generic xml input option can refer to a native path or a dataset in TC.

NX Part types supported by the tool:-

The tool will be able to classify any catalog part in NX, not only limited to routing parts. The
following are the supported part types:

o Single NX part family template

o NX assembly part family template

If the user gives this type of part as the input, then the component NX parts should also be put
in the same folder as assembly NX part. The PTB file if present will only be available for the
assembly part

It is suggested that the user should only put one assembly part and its component parts under a
folder. If there are other parts or ptb files (not belonging to the assembly), then the user can
put them under any other new folder of the Nested folder structure that is being created as
an input to the tool.

o NX part without part family

In this case, the part attributes present in the NX part would be used to define the class
attributes in classification. This case will only be supported while the user gives the Folder
structure as input (native nested folder structure or TC folder). In this case, if there is more
than one NX part in a folder, then those parts should have Shared User defined Part Attributes
on them. But even if the folder has just one part file the installation will still work. Only those
attributes which have some value attached to them will be processed.

A use case example for this could be a situation where user has 10 pumps (which means 10
NX part files). Each of them is not part of a part family (which means they are independent
part files with geometry in them) as the geometries are vastly different but their functional
definition is similar. All of them have common part attributes like Pressure, Flow rate, Rating,
etc. All of these 10 pump NX part files can be placed in a single folder and will be classified
 correctly provided they have shared attributes.

There could be a specific case where a folder contains one ptb file and many part files in it but
it is not the case of an assembly part family. Also the part files do not have any part attributes
defined on them. But the ptb file has all the shared attributes for these parts. This case will be
supported in the nested folder structure as well as the routing PLV file input options. The
user needs to ensure that that PART_NAME attribute is present in the ptb file.

It is suggested that the user should put the parts with shared attributes together. If the parts
have no shared attributes, they should be put into different folders.

The below table provides the mapping of the kind of NX part type supported for each input type:

No NX Part Type Nested Routing PLV Generic Existing TC

Folder file xml file folder
structure format structure
1 NX part family Yes Yes Yes Yes
template
2 NX assembly part Yes Yes No Yes
family template
3 NX part without part Yes Yes No Yes
family

Format of the generic XML file:-

The xml file should contain enough information since the tool needs to locate the NX template
parts that need to be upgraded in TC; even if the template parts are not initially classified by the
installation tool.

The xml file would contain entries for the geometric, part, or engineering attributes for each
member of a given family of catalog parts. It would contain references of MEMBER_NAME,
PART_NUMBER. In any case, the names must be unique and should not conflict with an
existing Item ID in TC. The xml file would also need to contain attributes like
TEMPLATE_ITEM_ID and CLASS_ID for each member to locate the NX template parts for the
purpose of adding more members to it.
An example portion of the generic xml file provided is as shown below:

The above picture shows the entry in the xml file for the PIPE_GROUP. In the top header as
shown below
<PIPE_GROUP NUMBER_OF_PIPEPARTS="17" CLASS_ID="DIN_BW_Pipe" TEMPLATE_ITEM_ID="BW_Steel_Pipe_stock" PIPE_MATERIAL="Q235B"

PIPE_STANDARD="DIN 2458">

The value of CLASS_ID should correspond to the ID of the Storage class under which these
members for the Pipe need to be classified and TEMPLATE_ITEM_ID corresponds to the name
of the NX template part name ( TEMPLATE_ITEM_ID) in TC to which these members need to be
added. Also the header can contain attributes like PIPE_MATERIAL and PIPE_STANDARD
whose values will be same for all the members.
The next set of lines highlighted in the picture above shows the names of the member items
(which are PART_NUMBER and MEMBER_NAME) and for each member it is mandatory to
provide the values of the attributes and expressions which are part of the part family spreadsheet
of the NX part family template. These values define the geometry of the part. In the above case
these are NPS, OD1 and t1.

When giving xml file as input, all attribute values of the ICO will be read from this file. The
following cases are possible:
i) If an attribute is available in the NX part family internal spreadsheet and not available in the
xml file or has an empty value (e.g. ), then the tool will assume the values for a particular
member based on the value of the previous member in the part family spreadsheet. Hence to
prevent incorrect geometry for the members from being created make sure that the values for the
mandatory attributes/expressions are not missing and are correct.

ii) If an attribute is available in the xml file but not available in the NX part family internal
spreadsheet then the tool should add those additional attributes to the class. Since the xml file does
not have information of the type for the attributes they may all be added as String attributes.
There could be two situations:
 a) The Storage class has existing attributes but no ICOS

If this case, all the existing attributes will be replaced by the attributes in xml file. If the new
attribute also exists in NX part family sheet, then the attribute type will be obtained from NX part,
otherwise it will be added as String type.

b) The class has existing attributes and some ICOs already exist.
In this case, the existing attributes of class cant be changed. The tool will add the additional
attribute in xml file as String type.

Refer to the example pipeparts.xml file provided for more details. You can use this xml file to
add additional members to an existing installation. This example xml file will work if you have
already used the provided nested folder example structure for the initial installation since the
TEMPLATE_ITEM_ID and CLASS_IDs used in this xml file are based on the nested folder
structure example.

Install step by step

1. Edit the property file - [LibaryClassification-utilities.def]. to configure the limit of the total
members to be classified by the tool:

MEMBER_NUMBER_LIMIT 0

Currently the value of MEMBER_NUMBER_LIMIT is set to 0. Sometimes if you are not very
sure that the memory allocated by your machine for this installation will not be enough when you
are generating thousands of member parts, you can set this value to be say, for example, 400. This
means that the tool will classify all the member items in batches of 400 each automatically and
this will make sure that your machine does not run out of memory while installing a large number
of member parts. The user does not have to do anything interactively for this. If you are sure that
you have enough memory (RAM) then you may set this value to 0.

2. The default language set for the installation tool is English. If you dont need to change the
default language then you can skip this step. If you need to change the language to some other
language, for example, German, then perform the following steps.
Edit the property file to configure the install language: that is the lang.properties file found
under the configuration folder. Perform the following steps:

a. Open ...\configuration\lang.properties file, remove # before language:

For example: - Change ---- #German = de to German = de
b. Copy the text.xml file from \lang\en to \lang\de.
c. Translate all the English strings in file \lang\de\text.xml to German.
d. Set UGII_LANG=GERMAN in file: Classification-Installation_tc9.1.bat available in the
installation folder
e. In the Control panel, choose Clock, Language and Region->Region and Language, Set the
language format to German as shown below:

f. Once this is done and the installation tool is launched, there will be an option to select the
German language as shown below:

3. Before you start the installation > Edit the Classification-Installation_tc9.1.bat file

You need to modify the values of the below set parameters mentioned in bold based on your
installation. Others can be kept as it is

set TC_ROOT=C:\software\Siemens\Tc91
set TC_DATA=C:\software\Siemens\Tc91\tcdata
set FMS_HOME=%TC_ROOT%\tccs
set JAVA_HOME=%TC_ROOT%\portal\jre
set IPR=%TC_ROOT%\portal
set TPR=%TC_ROOT%\portal
set UGII_BASE_DIR=\\server\soft\Siemens\NX 9.0
set UGII_JAVA_HOME=C:\apps\Java\jre7x64
or set UGII_JAVA_HOME=%UGII_BASE_DIR%\NXJRE
Before you start the installation make sure that you can launch NX from the path specified above.
Note:- Generally if you are launching NX from a shared location (as shown in the path above) and
if while launching NX you get an error that some dlls are missing, for example, mfc100u.dll,
vcomp100.dll, then copy the dlls from the machine where NX is installed to the machine from
where you are running the installation tool (that is typically where your TC server is installed).
These dlls should be available under the \Windows\System32 folder.
For UGII_JAVA_HOME, you should specify the 64 Bit library location, and use version 1.7 or
above.
Alternatively you may choose to set UGII_JAVA_HOME to the NXJRE folder found in the
UGII_BASE_DIR.

Also note that at the end of the Classification-Installation_tc9.1.bat file there is a line

Java -Xms512m -Xmx1024m -XX:MaxPermSize=256m

com.ugs.krcontent.main.KRContentApplication

which controls Java virtual machine parameters.

In the case where the RAM of your machine is 8GB or less and you experience that the Dry run
step is taking a lot of time, remove this line from the batch file and start the installation again.

Now you are ready to start the installation process.

Remember that there are two modes of installation --- Fresh Install and Upgrade.
When you use the tool for the first time it is a case of a Fresh Install.
You can now start the installation process.

4. Double click Classification-Installation_tc9.1.bat to start the installation.

5. Select the language.

6. Agree to the Copyright Notice by checking the check box.

7. You can select one of the four options shown below. Based on what option you select, you
will be asked to select the Root node of the nested folder structure, a standard routing PLV
file, an xml file or just pick the Root node of an existing TC folder structure.

There is a check box at the bottom of this page to ask the user if this is a Routing specific
Installation or not. Keeping this toggle ON means that during the Validate step the
installation tool will validate if the input NX template parts are valid routing parts or not
(which means they have properly qualified routing ports etc.)

The 4 subsequent images show how the page will look like when each of the four input
options are specified by the user.
 The XML file in the above case can be available on native path or as a dataset in TC.

8. Click next, and then specify the TC portal install location. The tool will check if the path is
valid, and then next will be available.
9. Click next, then specify the user name and password, and select the database if there are
multiple ones available. You need to login in TC using an account which has DBA permission.
infodba login is the preferred login to perform the installation.
10. TC data location, specify the location of TC data
In case of the nested folder structure and the PLV input options, choose the library root folder, the
default path is:
<User>: [Home, Root folder name]
(The folder name will be obtained from the name of the Root folder or the folder of the
input PLV file.)

In the above image routing_parts is the name of the Root folder hence the Install Path would
look like as shown above.
If you had selected the Routing PLV file option then it would read --- infodba:[Home,
ugroute_mech_metric]
If you intend to select some other folder then click the browse button and select the required folder
in TC as shown below:

For the XML file input option, an existing xml dataset will be needed to be specified as the xml
file. In case the user chooses to select an xml file from the native system he needs to browse to the
location of the xml file on the native system and provide it as an input to the tool. But if the xml
file is a dataset in TC then the user needs to select the xml dataset from the TC database. The user
can define this xml dataset as any one of the three dataset types in TC:
XMLRenderingStylesheet, NXRouting, and NX Routing Pipe Part Data in the TC database.
Note that NXRouting and NX Routing Pipe Part Data are special types of datasets which are
also supported.

Note: - When the installation tool browses the TC Navigator tree for the xml dataset it will search
for the dataset only in a TC folder. If the dataset is available inside a TC Item Revision then it
needs to be copied to a TC folder for it to be accessible.

You can select any one of the following two icons as xml datasets. As shown below the Pipepart
folder in TC has two kinds of xml datasets in it. The first icon is standard
XMLRenderingStylesheet dataset in TC, whereas the second icon may be an NXRouting or
NX Routing Pipe Part Data type dataset defined in TC.
In the case of the existing TC folder option, choose the library root folder (that is the required TC
folder) and then the displayed path will be the existing library path.
The same TC folder structure is then replicated in TC classification as well after installation.

11. Item type and other settings:

You can specify the template Item type as shown below

You can specify the template Item type for the first two input library options. By default it is set to
Item. You can maintain the same during installation. If the toggle Routing Specific
Installation is ON, then the template item type is Item by default and the user cannot change
it since other types are not supported in the Routing Library.

Regarding naming of the Items -- The Template Item ID will be generated either by Teamcenter
naming rules or the user can choose to keep the same name as the OS File name. Note that the
option Generated by Teamcenter Naming Rule is toggled ON in the image below. Instead
Toggle ON the other option Same as OS File Name for the installation. Note that the OS file
names for the NX template parts need to be unique while using this toggle and they should not
match an existing TC Item ID. For the xml and Existing TC folder options, the template part
already exists in the Teamcenter database, so this pane is grayed out and cannot be changed.

You can choose to generate part family members (this is a consuming process). This toggle is ON
by default. If the user is not interested in generating the family members then this toggle can be
kept OFF. For now just proceed by keeping this toggle ON.

There is another toggle to allow the installation tool to be able to classify the part family member
Item or Item revision. It is ON by default, and you will see that there is a tip under the toggle to
show the usage. In the case of routing standard parts installation you need to keep this toggle ON.

The last toggle Attach part family template to the classification storage class on the panel can be
used to attach the NX part family template to classification storage class if it is kept ON. It is
kept ON by default. This toggle will not be available while using the third input option an
xml file format for installation of the library.

In the case where the user does not want to generate the part family members using this
classification tool, he can choose to keep the generate part family members toggle OFF and
keep the last toggle ON. In this situation part family members will not be generated after the
installation process. Later the user can use the Graphics Builder tab for a Storage class in TC
classification Admin to generate the part family member Items and connect the ICOs to the
Member Item or Item Revisions in TC classification.
To do this user needs to click on Create/update graphics from ICOs button in the table view of
the ICOs in TC classification as shown below

In the subsequent dialog you can select the NX template and choose to create the member Items
for a given ICO.

An example dialog is as shown below.

Only while performing an Upgrade for an existing install, there will be an additional toggle on the
UI to allow the user to choose if the upgrade involves the addition of new members to the
existing classified template parts as shown below. This toggle ---- Upgrade new member from
existing part is OFF by default.

The user needs to know if his upgrade involves the addition of new members to existing
template parts or just the addition of altogether new template parts. If user is going to only add
new template parts, then keeping this toggle OFF would reduce the time required for the upgrade,
otherwise if the toggle is ON then the tool needs to cycle through every NX template part
imported in TC and generate the additional family members wherever needed.
12. Specify the install path of NX (this tool calls some NX libraries to operate on the NX template
part data)

The version of NX installation available while running the tool should be higher than, or the same
as, the version of NX for the NX template parts that need to be installed. Again make sure that NX
can be successfully invoked from the below mentioned path. This is required because NX needs to
be invoked to generate the part family members.
13. Specify the largest attribute ID
To keep a track of the attribute IDs created by the installation tool the user can specify the Start
Attribute ID as an input to the tool during installation. Before he provides this input, the user
needs to find out the value of the largest attribute ID that already exists in TC.
To find the largest attribute ID:- The user can start the TC portal and enter the TC classification
Admin application. Then, the user can create a new attribute in the dictionary and Auto assign its
ID (do not save the new attribute). This way the user can get the highest ID already being used
before beginning the installation. Make a note of it and ensure that the value here is larger than
this value.
14. Review all configuration information. Validate the user inputs and do dry run of the whole
installation process.
You need to do a validation before starting the install, otherwise the Install button will be grayed
out. To perform the validation step toggle ON the option Validate the input information and
click on Execute. After this the validation results will be shown in a window and then added in
this window. This is a mandatory step.
Dry Run will be shown on this page for the user to check problems, if any, for the entire install
process. The user can choose to do dry run before installing the library. Currently this is an
optional step but it is advised that the user perform this step also prior to the installation. To
perform the dry run Toggle ON the Dry Run option and click on Execute. The dry run results
will be shown in a separate window. This step can take a few minutes depending on how large the
library to be installed is.

During Validation the tool will check

a) If the input xml file is a valid file
b) If the template part item (which is the TEMPLATE_ITEM_ID), which will be used to
upgrade additional member items, can be found in the TC database and if it can be loaded
successfully.
c) If the CLASS_ID in TC classification for population of additional members already exists
d) Input routing template parts are valid if performing a routing specific installation.

During Dry Run the tool will list the family member items that already exist in the database. The
tool will also list out any NX catalog parts that have already been classified

Examples of Validation and Dry Run results in the separate window are as shown below

Validation results
Dry Run results

The user needs to take corrective action at this stage if there are some issues noted as part of the
Validation and Dry run process.

Note: During the dry run step the tool will list any Part family member items or ICOs that are
already present in TC and TC classification. The tool makes use of these existing Items and does
not generate new ICOs if they exist during the installation process during a new install or an
upgrade. They will not be overwritten or a new Item revision for the member items will not be
created. But based on the revision rules set in TC, the NX Template part Item may have revisions
created every time more members are added during successive upgrades.

The Dry Run result will also list how many new members will be generated during the installation.
If you are not very sure that the memory allocated by your machine for this installation will not be
enough when you are generating this number of member parts, you can change value of
MEMBER_NUMBER_LIMIT in file LibaryClassification-utilities.def before starting the
installation.

15. Install process

Once the user is satisfied with the Validation step and Dry Run step results he can proceed with
the installation by clicking the Install button.
During the installation the following steps happen sequentially:
a. The provided folder structure is first created in the TC database
b. The NX template part items are imported to TC, the family members are generated and
two installation PLMXML files are created in the Root folder
Those are - routing_parts_WSO_admin.xml and routing_parts_WSO_user.xml
c. Preview images of the family members are uploaded
d. The tool will then import the PLMXML files to generate the required Classification
 Hierarchy and attributes in TC classification are generated, ICOs are created, and the
ICOs are connected to the corresponding Part family Member Items in TC.

Status of the progress of each step in the installation process will be printed on this page and
shown in the progress status bar as shown below. All success and failures of each process will be
reported on this page and saved in the log file.

Note:- The progress bar of the install is not a direct indicator of the time remaining for the
installation to complete. This means that if it takes, for example, 5 minutes to reach 80%
completion on the status bar, it does not mean that it would take less than 5 minutes for the
remaining installation to be completed.

The user can stop the installation by clicking the Cancel button. After this he can choose Yes
to stop, choose No or Cancel to continue the install.
If the install is aborted or killed by the user in the middle of the installation, the install.xml file
will record the completed process up to that point.

16. Install results:

A small portion of the example folder structure in Teamcenter after installation is shown below.
install.config and the Root folder_WSO_admin PLMXML file are the files created by the
installation tool ( as shown below) and are useful when the user upgrades the same installation
afterwards. So these two files and the folder structure should be maintained to have faster
successive upgrades.

This is how the folders get created in TC after the installation is complete. These folders will
contain the NX template part Item and its member Items.
Here is an example (showing the template Item and Family members) for one template part
(which is BW_Steel_Pipe_stock) after the install:
An example structure in TC classification with the Classes and ICOs is shown below:

After the installation process a number of xml, log and syslog files are created in the Root folder
as shown below:
If your installation process fails for some reason, please refer to the install.syslog to find the cause.
This log file records all of the install process, success or failure of every operation.

17. Setting up NX Routing to read classification information

Once the installation is complete, to have these nodes and parts show up in the Routing part
library inside the Mechanical Routing application the following needs to be done:
On the NX side of the setup, the Customer Default below needs to be set to point to the top
node of your hierarchy in TC classification. In the above example case it would be routing_parts
since this is the ID of the top node after performing the installation.

Tip To find a customer default, choose FileUtilitiesCustomer Defaults, and click Find Default
In the ugroute_mech_metric.xml file, found in the appview folder, modify the contents shown
below under the Piping discipline:

The Start_Fitting_Node, Start_Stock_Node and the Start_Overstock_Node must point to the Class
ID (not the name) of the Abstract class for each of those kinds of routing parts. Based on the
example of the nested folder structure provided along with the tool, the above nodes need to point
to Piping Parts, Pipes and Overstock respectively. Note that the Class ID of an Abstract class can
be viewed in the TC classification Admin application only.
Restart NX and switch to the Routing Mechanical application and ensure that the discipline is set
to Piping. You should now be able to see your routing parts in the Routing Part library node in
the Reuse library as shown below. These parts/stocks/overstocks can now be added using the Place
Part/Stock/Overstock command or using the Routing Reuse drag and drop functionality.
Note that a similar hierarchy would be visible under the Classification Root node in the Reuse
library. This node should not be used to add routing stock/parts/overstock in the Mechanical
routing application.

Note: - Two separate examples of a nested folder structure and a sample routing PLV file with
parts and ptb files are provided along with this tool for the purpose of initial testing of the tool in a
test environment.
Also an example of the generic xml file as an input to the tool is provided that is
pipeparts.xml. This can be used to upgrade the existing installation done using the Nested folder
structure option for installation successfully.

Users should try these example installs in a test environment to make sure they understand the
working of the tool before using it in a production environment.
Appendix

Revision History

Rev. # Date of change Description of Change

1.0 June, 2012 First release
2.0 Apr, 2013 Second release
3.0 Dec,2013 Third release Support for Applied Characteristics from routing
ptb files in classification.
4.0 June, 2014 Fourth release Support for attaching template parts to
classification storage class