Issues with Types, Attributes & Layouts Export and Import in 10.1

[RajuPulavarthi]

All,
We are in the process of migrating from PDMLink 9.1 M050 to 10.1 M010. We are able to resolve many of the issues so far. However we are encountering few issues with the soft attributes / Layouts and transferring them to different environments.


1. We started out with the copy of the Production database, migrated to 10.1 and manually updated the Layout Groups, Layouts (Create, Edit & View) of over 100 types/ sub types of our interest so that we can have them in the desired order with the required data utilities in some cases.

a. We had an issue earlier where updates made to one branch was causing lost attributes in the layouts, but that got better with a PTC supplied class file.

2. Once layouts are configured manually in the initial Development environment, we wanted to export and import into the more formal QA/UAT environment.

3. Found out many issues during this process

a. Attributes from the top most parent (Ex: WTDocument) may show up but attributes from the interim parents (Ex: Reference Document) may be lost.

b. The visibility updates done (ex: Read Only in Edit screens) in source system were not carried forward

c. Updates to the OOTB attributes display names (ex: theCategory) are lost.

d. When updating the layouts in the cluster environment, some of the nodes are not reflecting the change requiring the system restart (Seen this couple of times. Need to explore further).


We tried both ways of exporting. In both case we used Default import method as explained in the documentation

1. Export all required leaf nodes with the flag 'csvExportAncestorTypes' set to true which would export all the parents.

2. Export all the types of interest with the flag 'csvExportAncestorTypes' set to false.

The second approach of export and Import seems to get little better results.

My questions to you all are

1. Have you encountered any of these issues in the system?

2. What did you have to do to make it work?

3. What Export / Import approach seems to work better.

Thanks all in advance. I am really hoping to avoid many manual hours to fix these layouts in all of our environments.
Raju

Raju Pulavarthi
Sr. Systems Analyst - Windchill Team
Global Information Technology

St. Jude Medical
5050 Nathan Lane North
Minneapolis, MN 55442


This communication, including any attachments, may contain information that is proprietary, privileged, confidential or legally exempt from disclosure. If you are not a named addressee, you are hereby notified that you are not authorized to read, print, retain a copy of or disseminate any portion of this communication without the consent of the sender and that doing so may be unlawful. If you have received this communication in error, please immediately notify the sender via return e-mail and delete it from your system.

[VenkataKotra]

Hi Raju,

When we've migrated from 9.1 M050 to 10.0 M030 we didn't face any issues..
Just used PTC Upgrade tool and it did everything required..No manual process at all.

I heard that in Windchill 10 Export/Import process is different and its easy too..To migrate types/attributes to Different environments
Within Windchill 10 you can use below process.

Regards
regards
Venkata Kotra║Sr.Analyst, Engg Systems ║IS, HHI
[cid:image001.png@01CDAC7D.9A2A5F10]

Exporting and Importing Types
The type information in your system can be exported, and previously exported type information can be imported using the Windchill load framework. This can be useful both in your initial deployment, as well as when disruptive changes are needed in your production environment.
For your initial deployment, the recommended strategy is:
1. Configure and verify your types, attributes, and attribute layouts in a test environment.
2. Export the type information from the test environment.
3. Import the type information into your production environment.
When disruptive changes are needed in your production environment, the recommended strategy is:
1. Export the type information from your production environment.
2. Import the type information into a test environment.
3. Reconfigure and verify your types, attributes, and attribute layouts in the test environment.
4. Export the updated type information from the test environment.
5. Import the type information into your production environment.
Related Links
Type and Attribute Management<">http://tow-d-wndcl01/Windchill-WHC/TypeAttrChp_Intro.html#TypeAttrChp_Intro_TypeAttrChp_Intro209_54>
Domain Prefixes in Type Names
When a type internal name is prefixed with the domain name of the site, the type internal name is exported with no domain prefix in the exported load file.
On import, any type internal name in the load file that does not include a domain prefix is automatically prefixed with the specified context domain, if any, from the import load file. If no context domain is specified, then the site domain name of the target system is assumed.
Exporting Types
To export type information, use the following procedure:
1. Create an export definition file on your source system, using an XML editor. The details of the export definition file are described in the following section. The XML of the export definition file is validated when the LoadFromFile command is run.
2. Run the following command from within a windchill shell:
windchill wt.load.LoadFromFile -d <filepath>/DefinitionExporter.xml -u <userid> -p <password>
where <filepath> is the file path to the location where the export definition file is located, and <userid> and <password> are the user name and password of a site administrator.
Creating an Export Definition File
To perform an export, you must first create an export definition file named DefinitionExporter.xml. The format for the DefinitionExporter.xml file is shown in the following example:


<nmloader>
<csvexportdefinition handler="com.ptc.core.lwc.server.&lt;br"/> TypeDefinitionExporter.beginExportDefinition">
<csvtolocation>D:\temp</csvtolocation>
<csvtofilename>changeorder.xml</csvtofilename>
<csvexportdefclass>com.ptc.core.lwc.server.LWCTypeDefinition</csvexportdefclass>
<csvexportnames>wt.change2.WTChangeOrder2</csvexportnames>
<csvmode>1</csvmode>
<csvexportancestortypes>true</csvexportancestortypes>
</csvexportdefinition>
</nmloader>
The above example will export the metadata of the wt.change2.WTChangeOrder2 type to D:\temp\changeorder_#.xml file.
The following elements can be nested within the <csvexportdefinition> element in the DefinitionExporter.xml file:
Element

Description

<csvtolocation>

Specifies where type load file is generated. This element is required.

<csvtofilename>

Specifies the name of the type load file.
Note
Depending on your data, there could be several files generated. These files will have a number suffix appended at the end of the file name, for example: TypeLoadFile_3.xml. The file with the largest appended number suffix is the file containing the type definition.
This element is required.

<csvexportnames>

Specifies the names of the types to be exported in the type load file. Use the internal names of the types as seen in the Type and Attribute Management utility. This element is required.

<csvmode>

Specifies the mode that the export is run with. Possible values are:

* 0-All localized values will be exported as part of the XML file. This is the default.
* 1-All localized values will be exported into rbInfo files.
This element is optional.

<csvexportancestortypes>

Specifies whether or not the ancestor type or types should be exported along with the requested type definition. The default value for this element is true, meaning that the full hierarchy tree for the type will be exported, including ancestors.
If false is specified, then only the partial hierarchy tree will be exported.
This element is optional.

Importing Types
To import type information, run the following command from the windchill shell on your target system:
windchill wt.loadFromFile -d <loadfile> -u <userid> -p <password>
where <loadfile> is the import load file generated when you performed your export, and <userid> and <password> are the user name and password of a site administrator. If multiple files were created when the export was performed, each file must be imported in numerical order.
Normal and Additive Import Modes
In normal import mode (the default mode), the import action does the following:
· Any new information (types, attributes, constraints, property values, and so on) in the load file is added to the system.
· Any information existing in the system that is also in the load file is updated.
· Any information existing in the system, but that is not in the load file, is deleted from the system (except for types and attributes).
· All attribute layout related information is completely deleted from the system and rebuilt based on the contents of the load file.
· Any types and attributes existing in the system, but not in the load file, are not deleted. Instead, delete load directives are created in secondary load files for each type and attribute that is in the system, but not in the load file. Each type with attributes that could be deleted will have a secondary load file created containing delete load directives for each of those attributes. Another secondary load file will be created containing delete load directives for all types that could be deleted.
These secondary load files, if any, are found in the following location after the import is complete:
<windchill>/temp/LWCTypeImpExp
View the delete load directives in the secondary load files. If you want those deletions to be performed, rerun the LoadFromFile command, this time targeting the desired secondary load file.
In additive import mode:
· Any new type and attribute information in the load file is added to the system.
· Any existing type and attribute information that is also in the load file is updated.
· Any type and attribute information present in the target system but not in the load file is ignored.
· Any attribute layout information in the load file is ignored.
· If a new attribute is created, it is automatically added to the default group of any existing attribute layouts.
To run the import in additive mode, you must edit the import load file by adding the following elements, nested inside the header and footer elements, surrounding the load file contents:
<csvbegintypeloadmodes handler="com.ptc.core.lwc.server.&lt;br"/> TypeDefinitionLoader.beginTypeLoadModes">
<csvaddmode>true</csvaddmode>
</csvbegintypeloadmodes>
...
# load file contents
...
<csvendtypeloadmodes handler="com.ptc.core.lwc.server.&lt;br"/> TypeDefinitionLoader.endTypeLoadModes"/>

[PreetiGupta]

Hi Raju,

I have tried export/import of the layout on 10.0 M010 test upgrade and it worked ok. Somehow we are not successful yet to import/export on 10.1 M010 test system. We have modified layouts for child subtype but left the parent node alone. It will eliminate our UI customization.
I agree that it needs to import flawlessly on production system otherwise admin will end up fixing/recreating layouts post upgrade.

Thanks,
Preeti Gupta
Sr Engineer(Windchill Specialist)

15800 Alton Pkwy, Irvine,92618 USA
T +1 949-727-7516

[cid:image001.gif@01CDAC84.C6473B70]