Package wt.epm

See:
Description

Interface Summary

EPMConstructorListener	This interface provides the capability of performing client-side checking during object creation of EPMObjects.
EPMContentDelegate	Handle name/number changing for EPM objects Supported API: false Extendable: false
EPMContextManager	This serves to manage the context for an EPM session.
EPMDocumentManager	Supported API: true Extendable: false
EPMObject	This interface is used by all objects that want to allow for application-based vetoing of modifications.
EPMVetoableChangeListener	This interface provides the capability of performing client-side vetoing of set() operations.

Class Summary

AllTests
AuthoringAppVersionHelper
AuthoringAppVersionLink	Use the newAuthoringAppVersionLink static factory method(s), not the AuthoringAppVersionLink constructor, to construct instances of this class.
CADNamespaceManager	CADNamespaceManager is a class that handles all related functions for EPMCADNamespace class.
ContentTransactionListener	ContentTransactionListener updates the content item's stale state of EPMDocument within a given transaction.
EPMApplicationType	An enumerated type listing the valid owning applications for an EPMObject.
EPMAuthAppVersionRef	Use the newEPMAuthAppVersionRef static factory method(s), not the EPMAuthAppVersionRef constructor, to construct instances of this class.
EPMAuthoringAppType	An enumerated type listing the valid authoring applications for an EPMObject.
EPMAuthoringAppVersion	Use the newEPMAuthoringAppVersion static factory method(s), not the EPMAuthoringAppVersion constructor, to construct instances of this class.
EPMBoxExtents	The EPMBoxExtents represent a box around the CAD model associated to the EPMDocument .
EPMCADNameHelper	The EPMCADNameHelper class provides set of static methods related to CADNameOperations.
EPMCADNamespace	EPMCADNamespace is to restrict a unique CAD name in the context of a project or PDM.
EPMCADReferenceControl	Use the newEPMCADReferenceControl static factory method(s), not the EPMCADReferenceControl constructor, to construct instances of this class.
EPMContextHelper	Supported API: true Extendable: false
EPMContextManagerFwd	This serves to manage the context for an EPM session.
EPMDefaultContentDelegate	Implements full renumberIteration, default versions of renumberContents and checkContents.
EPMDocConfigSpec	The config spec for use by EPMDocs.
EPMDocContentDelegate	Content Delegate for EPMDocuments Supported API: false Extendable: false
EPMDocGetConfigSpecForDelegate	Supported API: false Extendable: false
EPMDocSubType	EPMDocSubType is an enumeration that defines the subtypes of EPMDocuments that the system can store.
EPMDocument	Use the newEPMDocument static factory method(s), not the EPMDocument constructor, to construct instances of this class.
EPMDocumentHelper	Supported API: true Extendable: false
EPMDocumentManagerEvent	Supported API: true Extendable: false
EPMDocumentManagerFwd	Supported API: false Extendable: false
EPMDocumentMaster	The Master of an EPMDocument.
EPMDocumentMasterIdentity	The uniqueness constraint of number on the master.
EPMDocumentMasterKey	The EPM Document Key table ensures that all EPM Document Masters are unique.
EPMDocumentType	EPMDocumentType is an enumeration that defines the types of EPMDocuments that the system can store.
EPMFamily	EPMFamily holds a set of instances that belong to a given family table.
EPMFamily.FamilyTableQueryByFamilyTable
EPMFamily.FamilyTableQueryByMember
EPMFamily.FamilyTableSnapshot
EPMFamily.LocalLinkProxy
EPMListenerFactory	The EPMListenerFactory uses the wt.properties file to instantiate the EPMConstructorListener and EPMVetoableChangeListener objects.
EPMRenameContentFactory	Used to generically call methods to handle content of EPMObjects for rename/numbering.
EPMSequence	Sequence used by auto number generation Supported API: false Extendable: false
EPMStandardContextManager	Use the newEPMStandardContextManager static factory method(s), not the EPMStandardContextManager constructor, to construct instances of this class.
EPMStandardDocumentManager	Use the newEPMStandardDocumentManager static factory method(s), not the EPMStandardDocumentManager constructor, to construct instances of this class.
EPMTypeDefinitionEventsHandler
FamilyOptions	Holds a set of properties to assign to newly created versions.
LoadAuthoringAppVersion
MasterIteration	Use the newMasterIteration static factory method(s), not the MasterIteration constructor, to construct instances of this class.
NamespaceMaster	The master reference identifies how the CAD name is added to a given namespace.
OccurrenceTable	Use the newOccurrenceTable static factory method(s), not the OccurrenceTable constructor, to construct instances of this class.
ReviseManagerUtility
ReviseOptions	Holds a set of properties to assign to newly created versions.
ReviseOptions.ObjectOptions	Holds a set of properties to assign to newly created versions.
TheEPMCADNamespaceProject	Use the newTheEPMCADNamespaceProject static factory method(s), not the TheEPMCADNamespaceProject constructor, to construct instances of this class.

Exception Summary

EPMDocumentException

Supported API: true Extendable: false

Package wt.epm Description

Engineering Factor Services

The EPM classes implement a programming model designed to perform the following activities:

· Allow the loading of CAD models (including information about family tables) into a Windchill database

· Relate the CAD models to parts in the enterprise

· Support the propagation of changes made to the models into the enterprise parts

EPM provides Windchill knower and doer classes that allow the engineer to express the structure of a CAD model and to load the CAD files into the Windchill database. EPM also provides background services that ensure data consistency in the database.

Windchill supports the concept of a build operation, which allows a graph of dependencies in one set of objects (called target objects) to be maintained automatically as a by-product of changes to another set of objects (called source objects). EPM implements a build operation specific to creating part objects from describing CAD documents.

Handling CAD Models

CAD models are represented in EPM by EPMDocument objects. EPMDocuments are also known as CAD Documents. If the CAD model has an associated family table, an EPMDocument represents each instance in the family table. This section describes EPMDocuments and its associated links in more detail.

EPMDocument Model

An EPMDocument can represent a component or an assembly, using other EPMDocuments as components. (This concept is described further in the section on Handling Model Structure later in this section.)

As shown in the following model, EPMDocument implements a number of Windchill interfaces that allow it to be used in various Windchill services:

• RevisionControlled - Allows the EPMDocument to be checked in and out
• OrganizationOwnedVersion – Allows the EPMDocument to be in an Organization
• WTContained – Allows the EPMDocument to be stored in a container
• Baselineable - Allows the EPMDocument to be stored in a baseline
• FormatContentHolder - Allows the EPMDocument to have content
• DocumentVersion - Allows the EPMDocument to be treated as a document by the Windchill Explorer
• BuildSource - Allows the EPMDocument to be used by the Windchill build mechanism to maintain a part structure
• SupportingDataHolder - Allows the EPMDocument to have EPMSupportingData. An EPMSupportingDataHolder can hold arbitrary Java objects, each tagged with a name and an owner application name. This allows an application to store application-specific data with the EPMDocument without having to extend the Windchill schema. Supporting data can also hold the authoring application version. (Please see javadoc for wt.epm.EPMAuthoringAppVersion.
• EffectivityManageable - Allows the EPMDocument to be assigned an effectivity.
• GraphicallyRepresentable - Allows the EPMDocument to have generated graphic representations that can be viewed and marked up in a view tool.
• Typed – Allows the EPMDocument to be have a soft type
• OneOffVersioned – Allows an EPMDocument to support one off versioning
• WorkspaceTrackable – Permits EPMDocuments to be downloaded to an EPMWorkspace and to be tracked by the workspace.
• Federatable – EPMDocuments can be Federated

Because the EPMDocument is RevisionControlled, a corresponding EPMDocumentMaster exists, which also implements Windchill interfaces:

• UniquelyIdentified - Allows the EPMDocument name to serve as a unique identifier
• DocumentMaster - Provides a version independent reference to an EPMDocument.
• Typed – Allows the master to have a soft type

Storing content on EPMDocument

EPMDocument is a Windchill ContentHolder (as shown in the figure above) and, thus can contain data files, URLs, or both. This allows the engineer to upload the actual Pro/ENGINEER model file (for example, the .asm file) and maintain it in the Windchill database.

An EPMDocument can contain a number of ContentItems. This allows EPM to store alternate representations of the CAD model in the same document. Content is maintained using the normal Windchill ContentService.

We recommend that the model file be stored as primary content.

Upload

EPMUploadManager is responsible for handling upload for EPMDocuments and family tables. Please refer to the javadoc in epm.upload for more details.

Creating an EPMDocument

An EPMDocument must be created via the factory method newEPMDocument:

EPMDocument doc = EPMDocument.newEPMDocument (<number>, <name>, <EPMAuthoringAppType authoring App>, <EPMDocumentType docType>, <CADName>);

The number of the document must be unique within the Windchill database. Please note that the number will be uppercase when stored, even if it is entered as mixed case. The ownerApplication is an EnumeratedType indicating the application that intends to manage changes to the document. The concept of owner application is set via a call to EPMContextHelper.setApplication (EPMApplicationType appType), where EPMApplicationType is an EnumeratedType. Set the "current application" for use by checking code. This value is cached on the client-side, but is also sent (via the EPMContextManager) to the server-side SessionContext.

Once setApplication () has been called, all objects created will be tagged with the specified application. A CADName needs to be specified. EPM Services ensure that CADName is unique within the enterprise or unique within a project in ProjectLink.

EPMDocuments can be typed. Please note that for EPMDocuments, IBA values cannot be added, unless the IBA belongs to the type.

Handling Family Instances

If the CAD model has an associated family table, a separate EPMDocument represents each line in the family table. As shown below, two types of links handle relations for family tables - EPMContainedIn and EPMVariantLink.

The EPM ContainedIn relation is an Object-to-Object link that associates two objects, where one holds an object that is physically contained in the other, such as a family instance and the family table object that holds the family table.

The family table file itself is stored in an EPMSepFamilyTable that is associated to any instances that are contained in it via the EPMContainedIn link.

EPM Variant Link is an Iteration to Master link that denotes that an EPM Document is a variant of another EPM Document. In other words, an instance is a variant of the generic.

The family table information can be externalized. Please refer to the javadoc in epm.familytable for more information.

Handling Model Structure

EPMDependencyLink

When an EPMDocument represents an assembly, it uses other EPMDocuments via EPMMemberLinks. It can also reference other EPMDocuments via EPMReferenceLinks; reference links are non-structural, but are used to include objects that provide scenery, or constraints.

Both EPMMemberLinks and EPMReferenceLinks are types of EPMDependencyLink (shown in the following figure), which is used to represent the concept of one EPMDocument depending on another.

The EPMDependencyLink represents a relation between two EPMDocuments.

EPMStructureService can be used to read the EPMDependencyLinks between EPMDocuments. A number of interfaces similar to the following are available:

public QueryResult navigateUses( EPMDocument document, QuerySpec querySpec ) throws WTException;

EPMMemberLink

The EPMMemberLink represents the use of one model by another. It includes data such as quantity and positioning, as shown in the following figure.

EPMReferenceLink

The EPMReferenceLink represents reference to an object by a model. While an EPMMemberLink can use only another EPMDocument, any Iterated object can be referred to (for example, a specification in Microsoft Word). The relationship between an EPMDocument containing a drawing and the EPMDocument containing the model is represented using an EPMReferenceLink. The direction of this link should be such that the drawing describes the model. The model never describes the drawing.

The Relationship Between CAD Models and WTParts

Please note that the Build Model will change in future releases. To prepare for this change, many of the classes and methods from the build package have been deprecated. These classes and methods will be replaced. Please refer to the javadoc to see the deprecated classes and methods. Windchill defines a build process, which is used to publish usage links and attributes (see the following figure).

You cannot associate an EPMBuildRule to an EPMDocument that has an effectivity assigned to it. To create an EPMBuildRule, you must first have created the WTPart and EPMDocument that you intend to relate. In addition, the WTPart, but not the EPMDocument, must be either checked out or in your personal folder.

Currently, only one subtype of EPMBuildRule is implemented — EPMBuildLinksRule. This rule allows for the publication of usage links to the part structure (see the following figure). Because this rule provides for the publication of usage links and IBAs, this type of association is called an active association.

To create the rule, you must use the factory method defined on the class:

EPMBuildLinksRule rule = EPMBuildLinksRule.newEPMBuildLinksRule (<document >,<part);

Once this has been done, you can use the Windchill build process to publish the document structure to the part structure. This can be done in either of two ways:

• By building the EPMDocument:

BuildHelper.service.buildTarget (<document >,<config spec >);

• By building the WTPart:

BuildHelper.service.buildTargetsForSource (<part >,<config spec >);

Please note that there are multi-object versions of these APIs.

If you are building a vaulted WTPart, the build process creates a new iteration of the WTPart. If the WTPart is either checked out or in your personal folder, no new iteration is created; instead, the usage links on the latest iteration are changed to reflect the results of the build.

Another type of association exists between EPMDocuments and WTParts. An EPMDescribeLink is used to denote that an EPMDocument describes a WTPart. This association is a passive association, as it does not allow for the publication of any data.

Workspaces

An EPMWorkspace has a name and is associated with a Windchill folder. It contains a set of objects being worked on (the EPMCheckpoint). Any object checked out to the folder is regarded as being in the workspace. Objects can also be added to the workspace without being being checked out to the workspace.

To work with EPM Documents, you must work in the context of an EPM Workspace. In other words, to manipulate EPMDocuments, you must check them out to a workspace. APIs to checkout to a workspace, checkin from a workspace, and to undo a checkout from a workspace are all available. Please refer to the EPMWorkspaceManager in wt.epm.workspaces for more details.