Determining Which Documents to Publish
By default, only information representing changes to a RevisionControlled object in terms of its associations with documents is published. Any information that has already been published to a distribution target is not republished.
The following examples show what is published to the target enterprise system. These make use of a WTPart iteration for the sake of illustration, but it could be an iteration of any of the RevisionControlled objects mentioned in the Note under section Part and Document Relationships.
The figure above shows Part 100 iteration A, assigned to distribution target 1, and with a document attached (DOC 1). If this part iteration and document iteration have never been published to distribution target 1 before, then when the part is published, the document and the document link is also published. The document appears in the sub-element
<AddedDocuments> and the document links appear in the sub-element
<AddedDocmentLinks>. See the Windchill Enterprise Systems Integration Open Application Programming Interface Guide for details on the XML structure of Windchill ESI RPC responses.
In this figure, Part 100 iteration A (with DOC 1 attached) is already published to distribution target 1. A second document (DOC2) is added to Part 100 iteration B and then published. If the document (DOC2) wasn’t previously published to distribution target 1, the document (DOC2) and the associated document link are published to distribution target 1. The document (DOC2) then appears in the XML element
<AddedDocuments> and the link appears in the XML element
<AddedDocumentLinks> in the ESI RPC response. If on the other hand, the document (DOC2) already exists in the target enterprise system, the documents link for the document is published but not the document (DOC2). The document (DOC2) then appears in the XML element <UnchangedDocuments> and the document link appears in the XML element <AddedDocumentLinks>.
In this figure Part 100 iteration A (With DOC 1 attached) has already been published to distribution target 1. If Part 200 iteration A is being published with the same document as Part 100 and the iteration for the document is the same then only the document link is published in the XML element <AddedDocumentLinks> for Part 200. If the document iterations are different, then the document is published as a change to the document in the XML element <ChangedDocuments> and the document link is published as an added document link in XML element <AddedDocumentLinks>.
In the figure above, Part 100 iteration A (with DOC 1 and DOC 2 attached) already has been published to target 1. Document 2 was removed from Part 100 iteration B and published. The only XML element that is created is <DeletedDocumentLinks>, which describes the link between the part and the document. The Document is not removed because the document might be associated with another part.
 | Again, the above use case scenarios apply not only to WTPart iterations but to iterations of any of the supported RevisionControlled objects. Also, the XML element names such as <AddedDocuments>, <ChangedDocuments>, <DeletedDocumentLinks> etc. are those that result from using the default ESI response meta information file. |
| | A document that is published for the first time appears in the <AddedDocuments> element in the ESI response. A new iteration of a previously published document gets sent either in the <ChangedDocuments> or in the <UnchangedDocuments> element, according as the Windchill ESI preference Check Iteration has a value Yes or No respectively. A new revision of a previously published document always gets sent in the <ChangedDocuments> element. A change to the lifecycle state of a document is considered a change to the document; thus, publishing a previously published document iteration after changing its lifecycle state causes the iteration to get sent in the <ChangedDocuments> element. All of these apply regardless of whether the document is sent with a RevisionControlled object or is published standalone. |