cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X

Translate the entire conversation x

How to Create a new Change Request Type using XML Editor

AA_8740810
5-Regular Member

How to Create a new Change Request Type using XML Editor

Version: Windchill 11.1

 

Use Case: We are looking to Create a new Change Request Type from an existing that carries over all the Attributes, Layouts, and Cascading Attributes from the cloned type.


Description:

We are looking for assistance on step two from article - CS60168

 

2. Create an export definition file using an XML Editor and save it locally on the source server; See below for an example

  • This will export the Change Notice type's attributes to a file(s) under the location C:\temp
  • Here user can edit the property vaules as per the requirement, such as destination folder and file name in the <csvtoLocation>, <cstoFileName xml tags respectively.

 

Where is the definition file created from? Is it exported from Type and Attributes Management or within the Site Utility? We would like to create a Change Request with the same Attributes, Layouts, and Cascading Attributes from the existing Change Request Type.

ACCEPTED SOLUTION

Accepted Solutions
mwaite
13-Aquamarine
(To:AA_8740810)

In summary, the process is to export the existing object type definition to a set of xml files, Edit the xml files to change the internal name of the object type and then import the new definition. 

 

I routinely export our type definitions just in case someone accidentally changes something.

It's handy to move object definition changes from dev to test to prod.

I like to keep the exports in a folder hierarchy that matches the object hierarchy in Windchill.

 

I use two bat files and one exporter.xml file per object type.

I keep each type in a unique folder.

 

The bats just run the LoadFromFile command in the correct direction.

The exporter.xml file tells what to export and how to export it.

Pay attention to the <csvExportAncestorTypes>false</csvExportAncestorTypes> tag.  If left true, it will export the whole object tree down to the object you are working on.  When you import, you run the risk of overwriting an ancestor if you leave it set to true.

 

I'm attaching example files.  

 

I would export my existing object to a folder.  Make a copy of the folder.  Name the folder the per the name of the object type. Edit the files in the new folder.  Import the files in the new folder.

 

What do you need to edit?  It depends on the object you export.  I will typically use a tool like notepadd++ to search all the export files for the object_type of the source object and replace it with the object_type of the new object.  Simple objects will export to one xml file.  Complex objects with enumeration lists, and icons, and attribute constraints will export a folder structure and several xml files.

 

 

View solution in original post

2 REPLIES 2
mwaite
13-Aquamarine
(To:AA_8740810)

In summary, the process is to export the existing object type definition to a set of xml files, Edit the xml files to change the internal name of the object type and then import the new definition. 

 

I routinely export our type definitions just in case someone accidentally changes something.

It's handy to move object definition changes from dev to test to prod.

I like to keep the exports in a folder hierarchy that matches the object hierarchy in Windchill.

 

I use two bat files and one exporter.xml file per object type.

I keep each type in a unique folder.

 

The bats just run the LoadFromFile command in the correct direction.

The exporter.xml file tells what to export and how to export it.

Pay attention to the <csvExportAncestorTypes>false</csvExportAncestorTypes> tag.  If left true, it will export the whole object tree down to the object you are working on.  When you import, you run the risk of overwriting an ancestor if you leave it set to true.

 

I'm attaching example files.  

 

I would export my existing object to a folder.  Make a copy of the folder.  Name the folder the per the name of the object type. Edit the files in the new folder.  Import the files in the new folder.

 

What do you need to edit?  It depends on the object you export.  I will typically use a tool like notepadd++ to search all the export files for the object_type of the source object and replace it with the object_type of the new object.  Simple objects will export to one xml file.  Complex objects with enumeration lists, and icons, and attribute constraints will export a folder structure and several xml files.

 

 

Hi @AA_8740810,

I wanted to see if you got the help you needed.

If so, please mark the appropriate reply as the Accepted Solution or please feel free to detail in a reply what has helped you and mark it as the Accepted Solution. It will help other members who may have the same question.
Please note that industry experts also review the replies and may eventually accept one of them as solution on your behalf.

Of course, if you have more to share on your issue, please pursue the conversation.

Thanks,

Catalina
PTC Community Moderator
Announcements

Top Tags