wt.part
Class LoadPart

java.lang.Object
  wt.part.LoadPart

public class LoadPart
extends Object

Creates and persists part objects based on input from a comma seperated value (csv) file. Method names and parameters are defined in csvmapfile.txt. wt.load.StandardLoadService.load reads records from a .csv file and passes the fields in a hashtable to methods defined in this class.

The load methods use a wt.load.StandardLoadService cache to cache part masters and part version objects to improve performance of creating assemblies and updating attrbiutes. The load methods use wt.doc.LoadDoc to retrieve documents, taking advantage of its internal caching.

Supported API: true

Extendable: false

See Also:

StandardLoadService, LoadValue, LoadDoc

Method Summary

static boolean	beginCreateWTPart(Hashtable nv, Hashtable cmd_line, Vector return_objects) Processes the "csvBeginWTPart" directive in the XML load file.
static boolean	createPart(Hashtable nv, Hashtable cmd_line, Vector return_objects) Processes the "csvPart" directive in the XML load file.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Method Detail

createPart

public static boolean createPart(Hashtable nv,
                                 Hashtable cmd_line,
                                 Vector return_objects)

Processes the "csvPart" directive in the XML load file. Creates a part object, persists it in the database, checks it out, applies the default attribute values associated with the specified type definition, persists the part, checks it back in, and caches it in the loader's memory.

Establishes the part as the CURRENT_CONTENT_HOLDER for use by "ContentFile" lines.

This format cannot add Soft Attributes(IBA). For that see beginCreateWTPart.

When using @see wt.load.LoadFromFile to load parts, end items and serial numbered parts, use the following XML format:

XML Format

<csvPart handler="wt.part.LoadPart.createPart" >
	<csvuser>	created by user	</csvuser>
	<csvpartName>	part name	</csvpartName>
	<csvpartNumber>	part number	</csvpartNumber>
	<csvtype>	assembly mode	</csvtype>
	<csvsource>	source	</csvsource>
	<csvfolder>	folder	</csvfolder>
	<csvlifecycle>	lifecycle	</csvlifecycle>
	<csvview>	view	</csvview>
	<csvteamTemplate>	team template	</csvteamTemplate>
	<csvlifecyclestate>	lifecycle state	</csvlifecyclestate>
	<csvtypedef>	typedef	</csvtypedef>
	<csvversion>	version	</csvversion>
	<csviteration>	iteration	</csviteration>
	<csvparentContainerPath>	parent container path	</csvparentContainerPath>
</csvPart>

Tag Definitions

created by user	This tag allows a user other than the user loading the file to be used as the creator of this part.
part name	Name of the part.
part number	Number of the part.
assembly mode	The assembly mode for the part. Choose one of the following: separable inseparable component
source	The source of the part. i.e. make, buy
folder	The full path to the folder. i.e. /Default/Design
lifecycle	The lifecycle that the part will be created under. i.e. Basic
view	The view that the part will be created under. i.e. Design, Manufacturing This value is optional. Leave this value blank for serial numbered parts.
team template	The team template that the part will be created under. This value is optional.
lifecycle state	The lifecycle state that the part will be created under. This value is optional.
typedef	This contains the identifier string of a @see com.ptc.core.meta.common.TypeIdentifier . i.e. wt.part.WTPart|com.mycompany.SoftPart2 This would create a soft typed part. This currently supports the following modeled types: wt.part.WTPart This currently does not handle custom modeled types. If there is a need for one of these, then a custom loader needs to be created.
version	The version of the part. This value is optional.
iteration	The version of the part. This value is optional.
parent container path	The parent container path that the part will be created under. This value is optional.

Versions and Iterations

Supports versioning which allows a part to be created at a specified version and iteration. Multiple part versions imply an "order". I.E. subsequent bulk load runs can "fill in the gaps", but it does so by attaching to the latest iteration of the previous version. If a newer iteration is added to the previous version, the new version will attached to the new latest iteration. For example: Load set 1 (E.1, A.1, C.2) will result in (A.1, C.2, E.1). The predecssors of: C.2 is A.1, E.1 is C.2. Load set 2 (B.1, A.2., C.1, C.3) will result in (A.1, A.2, B.1, C.1, C.2, C.3, E.1). The predecessors of: B.1 is A.2, C.1 is B.1, E.1 is C.3. Any new version/iterations added will continue to change the predessor links to the new latest iteration of the previous version.

Versioning does support gaps in the ordering.

Examples of valid versioning are: (A.1,A.3,B.2,B.5,E.4,E.5)

NOTE TO USERS OF THE SOURCE CODE: The ability to load part versions out of order is implemented by using the VersionControlHelper.service.insertNode() method. Calls to this method must not be removed from the code. To turn off this behavior, you should instead set the insert_on_latest_iteration flag to false in the constructPart() method.

When loading versions out of sequence and loading relationships to those parts there are a few things that you should understand while ordering your data.

1. Relationships are copied forward from what is identified as the predecessor to the new version. So in an ordered case if you create part 1 A.1 that has references or a describe relationship to doc 2. Then you revise to get part 1 B.1, it will have the relationships of A.1 copied to it so it will have the relationship to doc 2 as well.

2. Relationships are not copied forward if they are created after the new version has already been created. For example if part 1 A.1 and B.1 are created and then part A.1 has a relationship created to doc 2, part 1 B.1 will not have the relationship to doc 2 copied to it. You must explicitely create that relationship if you want it created.

3. Relationships from predecessors are not cumulative. This is really just a further clarification of the first point. Relationships are only copied from the one identified predecessor and not the accumulation of predecessors. So if you create part 1 B.1 that is related to doc 2, create part 1 A.1 that is related to doc 3 and then create part 1 C.1 it will inherit the relationship to doc 2 only.

These are just a few pointers to loading versions and relationships out of sequence. There are other scenarios given these basic rules that can also be imagined. So order the creation of versions/iterations and relationship very carefully to get the results that you intend.

Supported API: true

Extendable: false

Parameters:

nv - Name/Value pairs of part attributes.

cmd_line - command line argument that can contain supplemental load data

return_objects - Vector of the object(s) created by this method. Used by wt.load.StandardLoadService for accurate user feedback messages.

Returns:

true	success
false	failure

beginCreateWTPart

public static boolean beginCreateWTPart(Hashtable nv,
                                        Hashtable cmd_line,
                                        Vector return_objects)

Processes the "csvBeginWTPart" directive in the XML load file. Creates a part object, persists it in the database, checks it out, applies the default attribute values associated with the specified type definition, persists the part, checks it back in, and caches it in the loader's memory.

Establishes the part as the CURRENT_CONTENT_HOLDER for use by "ContentFile" lines.

When using @see wt.load.LoadFromFile to load parts, end items and serial numbered parts, use the following XML format:

XML Format

<csvBeginWTPart handler="wt.part.LoadPart.beginCreateWTPart" >
	<csvuser>	created by user	</csvuser>
	<csvpartName>	part name	</csvpartName>
	<csvpartNumber>	part number	</csvpartNumber>
	<csvtype>	assembly mode	</csvtype>
	<csvsource>	source	</csvsource>
	<csvfolder>	folder	</csvfolder>
	<csvlifecycle>	lifecycle	</csvlifecycle>
	<csvview>	view	</csvview>
	<csvteamTemplate>	team template	</csvteamTemplate>
	<csvlifecyclestate>	lifecycle state	</csvlifecyclestate>
	<csvtypedef>	typedef	</csvtypedef>
	<csvversion>	version	</csvversion>
	<csviteration>	iteration	</csviteration>
	<csvparentContainerPath>	parent container path	</csvparentContainerPath>
</csvBeginWTPart >
<csvIBAValue handler="wt.iba.value.service.LoadValue.createIBAValue" >
	...
</csvIBAValue >
<csvIBAValue handler="wt.iba.value.service.LoadValue.createIBAValue" >
	...
</csvIBAValue >
<csvIBAValue handler="wt.iba.value.service.LoadValue.createIBAValue" >
	...
</csvIBAValue >
<csvIBAValue handler="wt.iba.value.service.LoadValue.createIBAValue" >
	...
</csvIBAValue >
<csvEndWTPart handler="wt.part.LoadPart.endCreateWTPart" >
	...
</csvEndWTPart >

Tag Definitions

created by user	This tag allows a user other than the user loading the file to be used as the creator of this part.
part name	Name of the part.
part number	Number of the part.
assembly mode	The assembly mode for the part. Choose one of the following: separable inseparable component
source	The source of the part. i.e. make, buy
folder	The full path to the folder. i.e. /Default/Design
lifecycle	The lifecycle that the part will be created under. i.e. Basic
view	The view that the part will be created under. i.e. Design, Manufacturing This value is optional. Leave this value blank for serial numbered parts.
team template	The team template that the part will be created under. This value is optional.
lifecycle state	The lifecycle state that the part will be created under. This value is optional.
typedef	This contains the identifier string of a @see com.ptc.core.meta.common.TypeIdentifier . i.e. wt.part.WTPart|com.mycompany.SoftPart2 This would create a soft typed part. This currently supports the following modeled types: wt.part.WTPart This currently does not handle custom modeled types. If there is a need for one of these, then a custom loader needs to be created.
version	The version of the part. This value is optional.
iteration	The version of the part. This value is optional.
parent container path	The parent container path that the part will be created under. This value is optional.

Versions and Iterations

Supports versioning which allows a part to be created at a specified version and iteration. Multiple part versions imply an "order". I.E. subsequent bulk load runs can "fill in the gaps", but it does so by attaching to the latest iteration of the previous version. If a newer iteration is added to the previous version, the new version will attached to the new latest iteration. For example: Load set 1 (E.1, A.1, C.2) will result in (A.1, C.2, E.1). The predecssors of: C.2 is A.1, E.1 is C.2. Load set 2 (B.1, A.2., C.1, C.3) will result in (A.1, A.2, B.1, C.1, C.2, C.3, E.1). The predecessors of: B.1 is A.2, C.1 is B.1, E.1 is C.3. Any new version/iterations added will continue to change the predessor links to the new latest iteration of the previous version.

Versioning does support gaps in the ordering.

Examples of valid versioning are: (A.1,A.3,B.2,B.5,E.4,E.5)

NOTE TO USERS OF THE SOURCE CODE: The ability to load part versions out of order is implemented by using the VersionControlHelper.service.insertNode() method. Calls to this method must not be removed from the code. To turn off this behavior, you should instead set the insert_on_latest_iteration flag to false in the constructPart() method.

When loading versions out of sequence and loading relationships to those parts there are a few things that you should understand while ordering your data.

1. Relationships are copied forward from what is identified as the predecessor to the new version. So in an ordered case if you create part 1 A.1 that has references or a describe relationship to doc 2. Then you revise to get part 1 B.1, it will have the relationships of A.1 copied to it so it will have the relationship to doc 2 as well.

2. Relationships are not copied forward if they are created after the new version has already been created. For example if part 1 A.1 and B.1 are created and then part A.1 has a relationship created to doc 2, part 1 B.1 will not have the relationship to doc 2 copied to it. You must explicitely create that relationship if you want it created.

3. Relationships from predecessors are not cumulative. This is really just a further clarification of the first point. Relationships are only copied from the one identified predecessor and not the accumulation of predecessors. So if you create part 1 B.1 that is related to doc 2, create part 1 A.1 that is related to doc 3 and then create part 1 C.1 it will inherit the relationship to doc 2 only.

These are just a few pointers to loading versions and relationships out of sequence. There are other scenarios given these basic rules that can also be imagined. So order the creation of versions/iterations and relationship very carefully to get the results that you intend.

Supported API: true

Extendable: false

Parameters:

nv - Name/Value pairs of part attributes.

cmd_line - command line argument that can contain supplemental load data

return_objects - Vector of the object(s) created by this method. Used by wt.load.StandardLoadService for accurate user feedback messages.

Returns:

true	success
false	failure