Existing Load Methods
The best way to see what methods are available on your system to load with is to look at the loadFiles.csvmapfile.txt file. The following is a brief directory of the methods available for loading data in the system. Full method paths are provided to enable you to look them up in the JavaDoc.
• wt.doc.LoadDoc.createGeneral—Loads general documents; adds one content file and caches the general created for additional content additions.
|
|
Legacy method to support existing systems.
|
• wt.doc.LoadDoc.createSpec—Loads specification documents; adds one content file and caches the specification created for additional content additions.
|
|
Legacy method to support existing systems.
|
• wt.doc.LoadDoc.beginCreateWTDocument—Loads WTDocuments, subtypes, and global attributes. Supports versioning to allow a document to be created at a specified version and iteration. For more information, see the section More About wt.doc.LoadDoc.beginCreateWTDocument.
• wt.load.LoadContent.createContentURL—Adds a content URL to a cached content holder.
• wt.load.LoadContent.createContentFile—Adds a content file to a cached content holder.
• wt.load.LoadContent.setDefaultDirectory—Sets a default directory where content can be found. It is in effect until the next setDefaultDirectory or the end of the data file.
• wt.load.LoadContent.setDefaultURL—Sets a default portion of the URL where content can be found. It is in effect until the next setDefaultURL or the end of the data file.
• wt.folder.LoadFolder.createCabinet—Creates a cabinet. It is used mainly for initializing the system. User cabinets are created automatically when a user is created.
• wt.folder.LoadFolder.createSubFolder—Creates a subfolder.
• wt.folder.LoadFolder.createFolderShortcut—Creates a folder shortcut.
• wt.load.LoadUser.createUser—Creates a new user.
• wt.load.LoadUser.createGroup—Creates a new group.
• wt.load.LoadUser.createUserGroup—Adds a user to a group.
• wt.load.LoadUser.createDomain—Creates a new domain.
• wt.load.LoadUser.createAccessRule—Adds an access rule.
• wt.part.LoadPart.createPart—Creates a part.
• wt.part.LoadPart.createPartDocDescribes—Associates a WTPart with a WTDocument by creating a WTPartDescribeLink.
• wt.part.LoadPart.createPartDocLink—Creates a link (either a WTPartDescribeLink or a WTPartReferenceLink) between a part and a document. The type of association that is created depends on the subtype of the document.
• wt.part.LoadPart.addPartToAssembly—Adds a part to an assembly in a uses relationship.
• wt.part.LoadPart.createPartDocReference—Creates a references relationship between a part and an existing document.
• wt.part.LoadPart.beginCreateWTPart—Loads WTParts, subtypes and global attributes. Supports versioning to allows a part to be created at a specified version and iteration. For more information, see the section More About wt.part.LoadPart.beginCreateWTPart.
• wt.index.LoadIndexRule.createIndexRule—Creates index rules for searches.
• wt.lifecycle.LoadLifeCycle.createLifeCycleTemplate—Creates a life cycle template.
• wt.project.LoadProject.createIndirectRoleHolder—Creates a role-to-role mapping.
• wt.project.LoadProject.createRoleHolder—Creates a role-to-participant mapping.
• wt.project.LoadProject.createActorRoleHolder—Creates a role-to-actor role mapping. Actor roles are derived users, such as Creator.
• wt.lifecycle.LoadLifeCycle.createCriterion—Creates permission criterion for life cycle phase.
• wt.lifecycle.LoadLifeCycle.createPhaseTemplateBegin and wt.lifecycle.LoadLifeCycle.createPhaseTemplateEnd—Creates a phase.
• wt.project.LoadProject.createProjectBegin and wt.project.LoadProject.createProjectEnd—Creates a project.
|
|
Do not use the default administrator account to create a project context. Instead, use an account that is a project creator for the organization where you are creating the context. Additionally, do not add the default administrator account as a team member of the context. For details, see Before You Begin. |
• wt.lifecycle.LoadLifeCycle.createWTAclEntry—Creates ad hoc access control for a life cycle phase.
• wt.content.LoadDataFormat.createDataFormat—Adds data formats used in load content files.
• wt.effectivity.LoadEffectivity.createConfigurationItem—Loads a configuration item. A configuration item is necessary for lot number effectivity and serial number effectivity, but is optional for date effectivity.
• wt.effectivity.LoadEffectivity.createWTDatedEffectivity—Loads a date effectivity. The effectivity will be associated with the WTPart object that was loaded last.
• wt.effectivity.LoadEffectivity.createWTSerialNumberedEffectivity—Loads a serial number effectivity. The effectivity will be associated with the WTPart object that was loaded last.
• wt.effectivity.WTLotEffectivity.createWTLotEffectivity—Loads a lot effectivity. The effectivity will be associated with the WTPart object that was loaded last.
• wt.inf.team.ix.LoadSharedTeam—Loads a shared team. Shared teams can be loaded into an organization context and are used as a way to centralize team administration across an organization. For more information, see the section More About wt.inf.team.ix.LoadSharedTeam.
• wt.org.LoadUserPicture.update—Loads and associates pictures to the profiles of users in the system. For more information, see the section More About wt.org.LoadUserPicture.update.
More About wt.doc.LoadDoc.beginCreateWTDocument
The method wt.doc.LoadDoc.beginCreateWTDocument supports versioning to allow a document to be created at a specified version and iteration. Multiple document versions imply a sequence. For example, subsequent bulk load runs can fill in the gaps, but they do so by attaching to the latest iteration of the previous version.
If a newer iteration is added to the previous version, the new version is attached to the new latest iteration. For example:
Load set 1 (E.1, A.1, C.2) results in (A.1, C.2, E.1).
The predecessors of: C.2 is A.1, E.1 is C.2.
Load set 2 (B.1, A.2, C.1, C.3) results 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.
The iteration history of B.1 shows both A.2 and A.1
The iteration history of C.1 shows B.1, A.2 and A.1
The iteration history of E.1 shows C.3, C.2, C.1, B.1, A.2 and A.1
Any new versions or iterations that are added continue to change the predecessor links to the new latest iteration of the previous version.
|
|
Versioning supports gaps in the ordering.
|
Examples of valid versioning are: (A.1,A.3,B.2,B.5,E.4,E.5)
More About wt.part.LoadPart.beginCreateWTPart
The method wt.part.LoadPart.beginCreateWTPart supports versioning. This allows a part to be created at a specified version and iteration. Multiple part versions imply a sequence. For example, subsequent bulk load runs can fill in the gaps, but they do so by attaching to the latest iteration of the previous version. If a newer iteration is added to the previous version, the new version is attached to the new latest iteration.
For example: Load set 1 (E.1, A.1, C.2) results in (A.1, C.2, E.1).
The predecessors of: C.2 is A.1, E.1 is C.2. Load set 2 (B.1, A.2, C.1, C.3) results 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.
The iteration history of B.1 shows both A.2 and A.1
The iteration history of C.1 shows B.1, A.2 and A.1
The iteration history of E.1 shows C.3, C.2, C.1, B.1, A.2 and A.1
Any new versions or iterations that are added continue to change the predecessor links to the new latest iteration of the previous version.
|
|
Versioning supports gaps in the ordering.
|
Examples of valid versioning are: (A.1,A.3,B.2,B.5,E.4,E.5)
When you load versions out of sequence and load relationships to those parts, there are a few things that you should understand about ordering your data:
• Relationships are copied forward from what is identified as the predecessor to the new version. For example, in an ordered case, you create part 1 A.1 with references or a describe relationship to doc 2. When you revise to get part 1 B.1, the relationships of A.1 are copied to it, so it has the relationship to doc 2 as well.
• 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 automatically have the relationship to doc 2 copied to it. If you want that relationship to be created, you must explicitly create it.
• Relationships from predecessors are not cumulative. (This point further clarifies the first point in this list.) Relationships are only copied from the one identified predecessor, and not the accumulation of predecessors. If you create part 1 B.1 that is related to doc 2 and part 1 A.1 that is related to doc 3, part 1 C.1 inherits only the relationship to doc 2.
Given these basic rules, you can imagine other scenarios. When sequencing the creation of versions or iterations and their relationships, consider your plan very carefully to ensure that you obtain the results that you intend.
More About wt.inf.team.ix.LoadSharedTeam
The load file must contain a set of tags that defines the team. For example, assume you want to import a shared team with the following information:
• Shared team name: Design Team
• Description: Corporate team members responsible for designs
• Owner: User performing the load. By default, the user performing the load becomes the owner. If you want to set a different owner, include the UID of the user in the csvsharedTeamOwner tag.
• Invitation: Welcome to the Design Team!
• The shared team is enabled and extendable
The content of the XML file you use to perform the load is as follows:
<?xml version="1.0"?>
<!DOCTYPE NmLoader SYSTEM "standardX20.dtd">
<NmLoader>
<csvCreateSharedTeam handler="wt.inf.team.ix.LoadSharedTeam.create
SharedTeam">
<csvsharedTeamName>Design Team</csvsharedTeamName>
<csvsharedTeamDescription>Corporate team members responsible for
designs</csvsharedTeamDescription>
<csvsharedTeamOwner></csvsharedTeamOwner>
<csvsharedTeamInvitation>Welcome to the Design Team!</csvshared
TeamInvitation>
<csvsharedTeamEnabled>true</csvsharedTeamEnabled>
<csvsharedTeamExtendable>true</csvsharedTeamExtendable>
</csvCreateSharedTeam>
</NmLoader>
Shared teams must be loaded into an existing organization context. For more information about shared teams, see
About Shared Teams.
More About wt.org.LoadUserPicture.update
To bulk load and associate pictures to the profiles of existing users, here is an example of the content of the XML file you use to perform the load:
<?xml version="1.0"?>
<!DOCTYPE NmLoader SYSTEM "standardX20.dtd">
<NmLoader>
<csvUserPicture handler="wt.org.LoadUserPicture.update">
<csvuserName>User1</csvuserName>
<csvpath>c:\User1.jpeg</csvpath>
</csvUserPicture>
<csvUserPicture handler="wt.org.LoadUserPicture.update">
<csvuserName>User2</csvuserName>
<csvpath>c:\User1.jpeg</csvpath>
</csvUserPicture>
</NmLoader>
|
|
These users must already exist in the system. If a picture was previously associated with a user's profile, the system removes the old picture and creates a new one.
To simplify the load file preparation, use the wt.org.UserPictureLoaderXmlGenUtility command-line utility. This utility generates a default load file with placeholder picture filenames for all active users in the system. You can then modify the placeholder values to specify the correct filenames and load the picture data.
|
