Enterprise Administration > Windchill Data Loading > Loading Product Objects and Parts: Windchill PDMLink Example > Creating Product Containers
  
Creating Product Containers
Currently, you can create a product container in one step. However, in this example, the customer had already prepared a load file for products based on an earlier Windchill load process.
For general administrative information about containers, see Contexts Overview.
Following is that process flow:
1. To use the proper data from the customer, the data file was converted to XML using the CSV2XML utility. See the following example:
<?xml version="1.0" ?><!DOCTYPE NmLoader SYSTEM "standardX20.dtd">
<NmLoader>
<csvProductContainer handler="wt.part.LoadPart.createProductContainer">
<csvuser>productcreator</csvuser>
<csvname>TestLoad3</csvname>
<csvpnumber>TestLoad3</csvnumber>
<csvsharedTeamName>Shared Team 2</csvsharedTeamName>
<csvcontainerExtendable>true</csvcontainerExtendable>
<csvdescription>Test</csvdescription>
<csvview></csvview>
<csvsource></csvsource>
<csvdefaultUnit></csvdefaultUnit>
<csvtype></csvtype>
<csvcontainerTemplate>General Product</csvcontainerTemplate>
</csvProductContainer>
</NmLoader>
<csvsharedTeamName>Shared Team 2</csvsharedTeamName> and <csvcontainerExtendable>true</csvcontainerExtendable> are optional. Include these only when you want to include a shared team in your load data.
2. After the data was updated, it was processed using a custom built XSL stylesheet. See the following example:
<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output
method="xml"
indent="yes"
encoding="iso-8859-1"
doctype-system="standardX20.dtd"
/>
<xsl:template match="/">
<NmLoader>
<xsl:for-each select="//csvProduct">
<csvProductContainer handler="wt.part.LoadPart.createProduct
Container" >
<csvname><xsl:value-of select="csvpartNumber"/></csvname>
<csvnumber><xsl:value-of select="csvpartNumber"/></csvnumber>
<csvsharedTeamName>Shared Team 2</csvsharedTeamName>
<csvcontainerExtendable>true</csvcontainerExtendable>
<csvdescription><xsl:value-of select="csvpartName"/></csv
description>
<csvview></csvview>
<csvsource></csvsource>
<csvdefaultUnit></csvdefaultUnit>
<csvtype></csvtype>
<csvcontainerTemplate>General Product</csvcontainerTemplate>
</csvProductContainer>
</xsl:for-each>
</NmLoader>
</xsl:template>
</xsl:stylesheet>
<csvsharedTeamName>Shared Team 2</csvsharedTeamName> and <csvcontainerExtendable>true</csvcontainerExtendable> are optional. Include these only when you want to include a shared team in your load data.
* 
Although not illustrated in this example, XML code can be developed to test data and validate it. For example, if a value is empty but is required, a default value could be substituted.
3. After using the XML code above, a load-ready file is produced. Product containers belong to an organization, so when calling the load utility, the proper organization should be specified.
When running the load utility for product containers, a user must be specified. It is a requirement that this user be a Product Creator for the specified organization. In addition, they should belong to the Administrator group. This is usually done manually.
* 
Do not use the default administrator account to create a product container or add the default administrator account as a team member of the container. For details, see Loading Product Objects and Parts: Before You Begin.
Multiple product containers can exist in one load file.
Following is an example of a command:
windchill wt.load.LoadFromFile -d product_container.xml -u productcreator
-p productcreator -CONT_PATH \"/wt.inf.container.OrgContainer=My Organization\"
* 
When calling wt.load.LoadFromFile in UNIX and the container has a space in the name, place quotes around the container. In addition, be sure to escape the quotes with a backslash.
* 
To specify alternate default values, adjust the product (end item) initialization rules from the Site context within Windchill.
Example
Following is an example of a batch file:
echo *************************************************
echo ** Variable Setup
echo *************************************************
set tmp_org="/wt.inf.container.OrgContainer=My Organization"
echo *************************************************
echo ** Legacy Products Containers
echo *************************************************
windchill wt.load.LoadFromFile -d product_container.xml -u
productcreator -p productcreator -CONT_PATH \%tmp_org%
Creating Assemblies
Creating assemblies is necessary for creating products that use parts which may be common to other products, or may exist independently in other libraries.
The <csvAssemblyAddLoad> tag can be used only with existing parts. In other words, it can only be used to create new assemblies using existing parts. The <csvAssemblyAddLoad> tag cannot be used to create a brand new part.
For that purpose, the following file:
<csvBeginWTPart handler="wt.part.LoadPart.beginCreateWTPart">?
must first be used to create the part and then add constituent parts.
After the tag descriptions, you will find examples of two approaches.
Tag Descriptions
The <csvAssemblyAddLoad> tag has the following tags:
assemblyPartNumber—The part number of the assembly. A value is required.
constituentPartNumber—The part number of the constituent part. A value is required.
constituentPartQty—The number of parts. A value is required.
constituentPartUnit—The part unit, such as ea. A value is required.
assemblyPartVersion—The part version. If no value is specified, the latest version is used.
assemblyPartIteration—The part iteration. If no value is specified, the latest iteration is used.
assemblyPartView—The name of the part structure view of the assembly part, such as Design or Manufacturing. If part structure views are being used, you should specify a view to identify the view version of the assembly part. If part structure views are not being used, leave this attribute blank.
organizationName—The name of the organization that owns the assembly part. This is the name of the organization that owns the part, and not the name of the organization container. If organization ownership is not being used (if you are not able to choose an owning organization when renaming a part), leave this attribute blank.
organizationID—Another way to specify the organization that owns the assembly part. If organization ownership is not being used (if you are not able to choose an owning organization when renaming a part), leave this attribute blank. If you specify this attribute, use the following format:
<coding-system>$<org-id>
The dollar sign ($) acts as a separating character. The coding system is one of the following:
0141 or CAGE
0060 or DUNS
0026 or ISO65233
Org-ID is the org ID as specified in the Participant Administrator or the WTOrg info page.
For example, CAGE$1234 identifies an organization that uses the CAGE code coding system and whose CAGE code is 1234.
* 
You should specify either an organizationName and organizationID; there is no need to specify both. If you choose to specify both, they must refer to the same organization.
componentID—An ID associated with the usage link. It is unique for each parent part-child master pair. In other words, each usage link with the parent part has a different ID.
inclusionOption (available for configurable parts)—Specifies whether the link (the child part) is included in the structure. If set to true, the link is included. If set to false, the link is not included.
quantityOption—Works with InclusionOption to control the quantity of a child part in a variant. If the quantity is a fixed value (such as 5), that quantity is set on that child in the variant. If the quantity is a parameter, then the value of that parameter is used to set the quantity of the child in the variant. If the quantity is set to 0 or less, the child part is not included.
reference ID—Indicates an alias given to a child configurable part that is needed if you want to refer to parameters in that child part or in any of its descendants. For example, if a parent part has a parameter A, child part has a parameter B, and the usage link between parts has the reference DOOR, then you can establish the equivalence between the parameters as follows: A == DOOR.B.
Adding Existing Parts to Another Existing Part in a Product
This example assumes the following:
Part-1 exists in the product MyProduct-1. This part may have been loaded previously or added through the user interface.
ExistingPart-1 and ExistingPart-2 reside in some other product or library.
MyProduct-1 exists in the organization, MyOrg.
The XML data resides in the file DataFile.xml.
Given these assumptions, the load can be performed using the following command:
windchill wt.load.LoadFromFile -d DataFile.xml -u wcadmin
-p wcadmin -CONT_PATH /wt.inf.container.OrgContainer=MyOrg
/wt.pdmlink.PDMLinkProduct=MyProduct-1
Example
The following is an example data file:
<?xml version="1.0"?>
<!DOCTYPE NmLoader SYSTEM "standardX20.dtd">
<NmLoader>
<csvAssemblyAddLoad handler="wt.part.LoadPart.addPartToAssemblyLoad">
<csvassemblyPartNumber>0000000022</csvassemblyPartNumber>
<csvconstituentPartNumber>0000000002</csvconstituentPartNumber>
<csvconstituentPartQty>1</csvconstituentPartQty>
<csvconstituentPartUnit>ea</csvconstituentPartUnit>
<csvassemblyPartVersion>D</csvassemblyPartVersion>
<csvassemblyPartIteration>1</csvassemblyPartIteration>
<csvassemblyPartView>Manufacturing</csvassemblyPartView>
<csvorganizationName></csvorganizationName>
<csvorganizationID></csvorganizationID>
</csvAssemblyAddLoad>
</NmLoader>
Creating a New Part Called LoadedAssm-1 and Adding Existing Parts as Constituent Parts
This example assumes the following:
ExistingPart-1 resides in some other product or library.
MyProduct-1 exists in the organization, MyOrg.
The XML data resides in the file DataFile.xml.
Given these assumptions, the load can be performed using the following command:
windchill wt.load.LoadFromFile -d DataFile.xml -u wcadmin
-p wcadmin -CONT_PATH /wt.inf.container.OrgContainer=MyOrg
/wt.pdmlink.PDMLinkProduct=MyProduct-1
Example
The following is an example data file:
<?xml version="1.0"?>
<!DOCTYPE NmLoader SYSTEM "standardX20.dtd">
<NmLoader>
<csvBeginWTPart handler="wt.part.LoadPart.beginCreateWTPart" >
<csvuser></csvuser>
<csvpartName>LoadedAssm-1</csvpartName>
<csvpartNumber>LoadedAssm-1</csvpartNumber>
<csvtype>separable</csvtype>
<csvsource>make</csvsource>
<csvfolder>/Default</csvfolder>
<csvlifecycle>Default</csvlifecycle>
<csvview></csvview>
<csvteamTemplate>System.TestTeamForLoads</csvteamTemplate>
<csvlifecyclestate>INWORK</csvlifecyclestate>
<csvtypedef></csvtypedef>
<csvversion></csvversion>
<csviteration></csviteration>
<csvparentContainerPath></csvparentContainerPath>
</csvBeginWTPart>
<csvEndWTPart handler="wt.part.LoadPart.endCreateWTPart" >
<csvpublishFlag></csvpublishFlag>
<csvparentContainerPath></csvparentContainerPath>
</csvEndWTPart>
<csvAssemblyAddLoad handler="wt.part.LoadPart.addPartToAssemblyLoad" >
<csvassemblyPartNumber>LoadedAssm-1</csvassemblyPartNumber>
<csvconstituentPartNumber>ExistingPart-1</csvconstituentPartNumber>
<csvconstituentPartQty>1</csvconstituentPartQty>
<csvconstituentPartUnit>ea</csvconstituentPartUnit>
</csvAssemblyAddLoad>
</NmLoader>
Tag Descriptions
Following are descriptions of the tags for the <csvBeginWTPart> tag:
user—The name of the user to assign as the creator of the part.
partName—The name of the part. A value is required.
partNumber—The number of the part. A value is required.
type—Identifies whether the part is an assembly or component. A value is required when you create a new part, and it can be updated. Values include:
Separable—The part is an assembly that can be disassembled without destroying it. For example, a mechanical assembly put together with removable fasteners such as screws.
Inseparable—The part is an assembly that, once built, cannot be disassembled without destroying it. For example, a welded metal assembly.
Component—A part with no child parts.
source—Where the part is acquired. The following options are available:
Make—The new part is made internally.
Buy—The new part is purchased externally.
Buy—Single Source—The new part is purchased externally from a single source.
folder—The location of the part in the container, such as /Default.
lifecycle—The life cycle of the part.
view—The view of the part.
teamTemplate—The team template, such as System.TestTeamForLoads.
lifecyclestate—The life cycle state of the part, such as INWORK.
typedef—The type definition for creating soft part. For example, com.ptc.ptcnet.SoftPart1.
version—The version of the part. If no value is specified, the first version defined in the object initialization rules (OIR) is used.
iteration—The iteration of the part. If no value is specified, the first iteration defined in the object initialization rules (OIR) is used.
parentContainerPath—The context where the parent part is located.