Classes
The figure below shows the Windchill ESI Document Renderer classes.
ESIAbstractDocumentsRenderer
This is an abstract class that extends BasicESIRenderer. It serves as the base class for ESIEPMDocumentRenderer and provides APIs for navigating and rendering a document structure. It makes use of the services of a TreeNavigator instance for navigating a document structure.
Refer to the Windchill release specific Java documentation for more details on available methods in the class
ESIDocumentsRendererInterface
This interface resides in the package wt.esi.doc and should be implemented by any of the ESI document renderers.
It invokes the getXXX() API that is appropriate for the given document renderer that implements this interface. For e.g., the implementation in class ESIEPMDocumentRenderer invokes the getEPMDocument() method.
Refer to the Windchill release specific Java documentation for more details on available methods in the class
ESIEPMDocumentRenderer
It extends ESIAbstractDocuments Renderer and implements the interface wt.esi.doc.ESIDocumentsRendererInterface. The class provides APIs for navigating and rendering a CAD document structure. While inheriting most of the logic for navigating and rendering a document structure from its parent, this class has added code for processing associations and attributes that are specific to a CAD document structure. For e.g., the class provides APIs for fetching CAD document representations and for rendering them as appropriate.
 | A CAD document structure may be published either as a standalone object, or in association with a change notice or a promotion request. |
Refer to the Windchill release specific Java documentation for more details on available methods in the class
TreeNavigator
This interface resides in the package com.ptc.windchill.esi.treenavigation and provides APIs for navigating a structure.
Refer to the Windchill release specific Java documentation for more details on available methods in the class
AbstractTreeNavigatorImpl
This is an abstract implementation of the TreeNavigator interface and resides in the package com.ptc.windchill.esi.treenavigation. It provides APIs for navigating a structure besides concrete implementations of the interface’s methods. It makes use of the services of a TreeNavigationRequestBuilder and a DependencyHelper instance to perform the navigation.
Refer to the Windchill release specific Java documentation for more details on available methods in the class
For other supported APIs of this class and other classes and interfaces in the com.ptc.windchill.esi.treenavigation package (and their methods), refer to the Javadoc.
TreeNavigatorImpl
This is the default implementation of the TreeNavigator interface for a CAD document structure. It resides in the package com.ptc.windchill.esi.treenavigation and extends the abstract class com.ptc.windchill.esi.treenavigation.AbstractTreeNavigatorImpl. A customizer may extend this class to override the APIs defined by this and by the abstract class. See section AbstractTreeNavigatorImpl for a description of the abstract implementation of the TreeNavigator interface.
The only available method of this class is filterNodes(assemblyNodes : Collection<Persistable>, leafNodes : Collection<Persistable>). The method does nothing, but a custom extension of this class can override the method to perform any filtering of the assembly and leaf nodes as appropriate.
TreeNavigationRequestBuilder
This interface resides in the package com.ptc.windchill.esi.treenavigation and provides methods for getting a TreeNavigationRequest object for a given collection of objects, depth of navigation and navigation criteria.
Refer to the Windchill release specific Java documentation for more details on available methods in the class
EPMDocTreeNavigationReqBuilder
It is the default implementation of the interface com.ptc.windchill.esi.treenavigation.TreeNavigationRequestBuilder for a CAD document structure and resides in the package com.ptc.windchill.esi.esidoc. It provides methods for building a TreeNavigationRequest object, which in turn is used for navigating a CAD document structure.
Refer to the Windchill release specific Java documentation for more details on available methods in the class
ESIDocumentsRenderer
It implements the interface wt.esi.doc.ESIDocumentsRendererInterface and provides APIs for rendering:
• a WTDocument or a CAD document that is associated to a part (or to any other RevisionControlled object)
• a WTDocument that is not associated to a RevisionControlled object.
| | Although Windchill allows associating a WTDocument to other WTDocuments in a structure, ESI services do not support processing such a structure. |
The ESI part renderer (ESIWTPartRenderer) uses the ESI renderer factory to obtain an instance of ESIDocumentsRenderer, which is used to render documents associated with a part.
| | Other renderers that make use of ESIDocumentsRenderer are ESIWTChangeOrder2Renderer, ESIPromotionRequestRenderer, ESIProcessPlanRenderer, ESISequenceRenderer, ESIOperationRenderer, ESIToolingRenderer, ESIProcessMaterialRenderer and ESISkillRenderer. |
Refer to the Windchill release specific Java documentation for more details on available methods in the class
ESIDocUtility
ESIDocUtility is the public interface to the com.ptc.windchill.esi.esidoc package. It provides methods that are used by the Windchill ESI document processing logic. The public methods are available for use by customizers, but the class may not be extended nor modified by customizers.
Refer to the Windchill release specific Java documentation for more details on available methods in the class
PartDocInfo
See the Document Attachment Differences section of this document.
The figure above shows the classes that get called to create the sub elements in the Response schema for the documents. The following is the sequence of events:
1. ESIWTPartRenderer invokes getRenderer() on ESIRendererFactory to obtain an ESIDocumentsRenderer instance. It then invokes getESIDoc() on the renderer, passing collections of (i) associations to distribution targets from previously published part iterations, (ii) part iterations that are currently being published, and (iii) the targets themselves, among other things.
2. getESIDoc() invokes setData() to initialize the document renderer instance appropriately and then calls render() – this is done for each part iteration that is currently being published. The VdbBuilder instance that was passed in by ESIWTPartRenderer is passed to the render() method.
3. The render() method calls setBuilder() (which sets the attribute builder to the passed VdbBuilder instance), validate() (which makes sure the attributes currentPartIteration and targets exist) and buildGroups() (which calls the overloaded version of buildGroups() that takes the current and previous part iterations and the collection of distribution targets as its arguments).
4. The overloaded version of buildGroups() calls getPartDocInfo(). If the part being published is an unchanged one and no new iteration was created, the argument passed in for the current part iteration is itself passed for the arguments current and previous when calling getPartDocInfo(). On the other hand, if the part was changed or a new iteration was created, the current and previous iterations that were passed in from buildGroups() are passed to getPartDocInfo().
5. If a null was passed to getPartDocInfo() for the previous part iteration, it invokes the method retrievePartDocInformation() on ESIDocUtility. Otherwise, it invokes retrievePartDocDifferences() on ESIDocUtility. Using the returned array of collections of PartDocInfo objects, Maps of document and documentlink elements are built using calls to getDocElements() and getDocLinkElements() respectively.
6. The collections in the array returned by getPartDocInfo() are traversed - if the collection contains PartDocInfo objects representing added or deleted document link information, buildDocumentLink() is invoked. Otherwise, buildUnchangedLink() is invoked.
7. The attributes on the document links are mapped using calls to mapDocumentLink() and the resulting I*E elements are added to the VdbBuilder instance using calls to VdbBuilder.addElement().
8. The associated documents are fetched using calls to getDocument() on the PartDocInfo objects obtained from step 5. For each document, the relevant attributes are mapped using calls to mapDocument() and the resulting I*E elements are added to the VdbBuilder instance using calls to VdbBuilder.addElement().
Documents and document links that have been previously published or that have a pending release status are not considered for publication. The release status is determined by finding whether or not an appropriate ReleaseActivity is associated to the document or document link.
In the default implementation of Windchill ESI, the XML sub-element <DeletedDocuments> in the response schema is not used. It is only the <AddedDocuments>, <ChangedDocuments> and the <UnchangedDocuments> elements that get populated.
| | 1. The above described steps are relevant not just to WTPart iterations but to any of the previously mentioned RevisionControlled objects viz., MPMProcessPlan, MPMSequence, MPMOperation, MPMTooling, MPMProcessMaterial and MPMSkill iterations that may have associated documents. 2. Only documents associated to parts, operations, tooling and process materials will be published to SAP. As for documents associated with process plans and sequences, these will be accounted for while generating the ESI response, but will be ignored by the middleware business logic. Refer to the section of the guide that describes the relevant EAI software components for more information. 3. If the Windchill ESI preference Publish ERP Material Information has a value Yes, documents associated to the ERPMaterial object (that represents the given part) will be published as well. An ERPMaterial object will be automatically created for a part, if the Windchill MPMLink preference Soft Types for Automatic ERP Material Creation has “wt.part.WTPart” as one of the tokens in its value. 4. If the Windchill ESI preference Publish Only Incremental Changes to Document Associations has a value No, document associations of a Revision Controlled object will be sent as added ones in the ESI response, regardless of whether those associations were previously published or not. 5. Steps 1 through 8 described above occur as part of an ESITransaction and will be repeated for every distribution target in a given ERP instance (or destination). Since a single distribution target will be processed at a given time, the collection of distribution targets referred to in steps (1) and (3) is actually a singleton one. 6. See the description for buildGroups() for the sequence of events that occur while publishing a standalone document. |