There are a number of paths you can take. First question to ask is which comes first, the part or the doc. It appears you would like to create a WTDocument and have a corresponding WTPart be created from it and associated. Or are you creating the WTPart first and want that checkbox similar to CAD docs?
All options I can think of involve some level of UI customization. You can create custom actions to make a 1 button click create which takes the default attributes and say makes the part. This can work in either direction. One option we did many years ago was to add a step to the document create and edit wizard (hidden step). This keys of a special soft-type we created call "General Drawing". If a user creates a WTDocument of type "General Drawing" or a sub-type of that, a WTPart is created and associated. If the part exists, it links to it. It does as you describe, takes the number, name, CAGE Code and Version from the WTDocument to build the part.
Over the years, I have had to make some improvements and add complexity such as what if I wanted the numbers to be different? This involve more rules to not just recreate that same Part all over again if I changed the Part number.
Also consider loading via spreadsheet to backfill any existing objects and links that might have been missed through OOTB means.
I don’t think you even need the spreadsheet to do the bulk Part creation.
If the WTDocs exist the code can:
This is Bhushan from PTC Customization Technical Support Team.
Based on your requirement, @avillanueva has given some insights on how one can proceed with such type of customizations.
If users create WTDocument first and populate the information required to be propagated on WTPart while working on document then finally proceeding with WTPart creation, it would be a good idea to develop a custom Wizard on WTDocument which can be enabled only when there is no WTPart related to WTDocument.
The wizard can be invoked to populate the pre-filled information in custom Create Part steps, once user validates information is correct Form Processor can be used to create and link the WTDocument with WTPart using the link type preferred.
If you need any assistance developing the customization, you can reach out to PTC Partners, PTC Professional Services.
Thanks for your reply avillanueva.
Typically we found that our users create the document first as they'll receive data and create a document to store the file/s and relevant metadata. We want to reduce the amount of rework required to create the Part object that will be described by said document. Users will be more likely to create document and part pairs if it is easier for them to create the part using the information from the document already.
What you have described sounds similar to what we already have for CAD Documents while creating Parts but for Parts while creating a new document. So when users select "General Drawing" as a document type and select finish, Windchill creates a Part with similar metadata and with the document already set as the describing document? That would work for our needs as well.
Yes, the additional step to the wizard (for create and edit jsp files)
<%-- process if matches drawings as documents --%> <jca:wizardStep action="process_drw_docs" type="document" />
relates to the custom-actions.xml entry:
<objecttype name="document" class="wt.doc.WTDocument" resourceBundle="com.ptc.windchill.enterprise.doc.documentResource"> <action name="process_drw_docs" preloadWizardPage="false" hidden="true"> <command class="customization.electrical.DrawingDocumentProcessorDelegate" windowType="no_content"/> </action> </objecttype>
It calls a postProcess method of my custom class above and once in code, you can do what you please. If this is the right path, please accept as solution.
If you wish to create WTPart directly from WTDocument wizard, the best way to do this would be extending Out-Of-The-Box Create Document Form Processor, you can either override doOperation() method and add your logic after running super.doOperation() or postProcess() method and add logic after super.postProcess() in your custom Form Processor which will create the WTPart by deriving values from WTDocument.
Also, you can always check the Document Type selected while creating WTDocument so that code only runs on specific subtype.
In this case you only need to update action with custom form processor, no need to add new steps and develop delegate.
I hope this helps in your journey to decide best suited solution.
PTC Technical Support
We had a very similar need.
We solved the problem by running code in workflow that would create/revise the part and link part to doc and pass attribute values as well including version.
If the part already existed (based on doc number) the code would find the part and make sure it was linked properly and that attribute values were correct.
So, let’s say you are revising doc to rev D, if necessary, the code would create or revise the part to rev D, make sure attribute values are correct and that all links are correct.
The Rev D part was then checked to make sure no iteration of it was linked to revisions other than D. If links to revisions other than D were found on any iteration of part D these links would be deleted (without iterating the part).
Fully automating this prevented a lot of headaches.
This could be done with a listener too but we felt doing it in our workflow was the best way for us as we only cared about this if the doc was to be released.