In my last blog post Productivity Enhancements on Windows Explorer Integration for Windchill Desktop Integration 10.2, Part I I discussed the possibilities and enhancements around the Windchill Documents system folder in the Windows Explorer.
This blog will show you how easy it is to display Windchill Meta data information in the Windows Explorer Integration.
I will also discuss the integrated Windchill search and how leverage the Windchill Index Search functionality.
View Windchill Information
Windchill metadata information of your documents can be displayed in the Windows Explorer without opening a browser to access the Windchill web application. Even applying filters is possible.
To do so, you have to navigate from the Windchill Documents node to the context that you are interested. On the right hand pane you will see the stored documents.
You may add or remove attributes by right-clicking a Windows Explorer column heading to see a drop down menu of additional columns available.
Is the attribute still not available in the out of the box list?
No problem, since Windchill 10.2 F000 you can select Windchill folder views to add columns that appear in the list. With Windchill 10.2 M010 even the filters on these views will affect the data displayed in the object list.
This allows you to configure which documents will be show in the folder. E.g. if you only want to display the latest document version, then apply filter settings on the Windchill table view (in the Set Filter step select Revision and Version attributes and set them to Latest).
Folder Search for Windows Explorer
All the features that I showed until now required that you exactly know where the documents are located in your Windchill system but this unfortunately is not always the case. While manual navigating through the folder structure is cumbersome and annoying to find a document, there is a simpler way to find your documents.
Starting in Windchill PDM Link 10.2 F000 you can search for any Windchill document using the Windchill Search action. This is a quick and easy way to search for your documents inside of the Windows Explorer Integration without the need to open the Windchill web application.
The search can be initiated from context, container or folder level within the Windchill Documents node. This will allow you to search by Name or Number on this context level and all sub-contexts.
Please note that the search is case-insensitive and wildcards are allowed. Add asterisk (*) as a wildcard character to indicate that one or more characters can appear in that position.
For Windchill systems with Index Search enabled, even document content will be taken into account when calculating the results if the option “Include search within content (only if index search is enabled)” is selected.
The native Windows Explorer search field (in the top right corner of the Windows Explorer) can also be used to perform a search but this will yield slightly different results. The search will only be performed on the current folder / context and not on any sub-context.
In case you are also interested in the location of document in the folder structure, you can use the right mouse button menu to select “Open File Location”. This will open the Windchill context or folder in which the object is stored.
Conclusion
This was the last part of my post about productivity enhancements on Windows Explorer Integration.
I hope that you liked this brief tour on the Windows Explorer Integration if you are interested in more details, you’ll find further information in the Windchill Help Center.
Thank you also for your many comments on part I.
As always let me and the community here about your thoughts and questions:
-
What do you like about the Windows Explorer Integration and what do you think is missing?
-
In which scenarios you are using the Windchill Explorer Integration?
-
…
Bjorn,
One of the main reasons for this article is to provide a solution to publish from a list of objects. The ability to publish the defaults as shown in the picture below should remain in tact as additional options. (these don't work for us!)
I'm hoping the process Gary has outlined can be an option for every company that is trying to generate lightweight images. Basic steps:
- Search for the objects or utilize the power of a queryreport.
- Take this list of objects found and send them to the publisher for generation of lightweight images.
Don't worry Tom,
I've cited the wrong person 
I noticed today that John Deere has already developed the ability to publish from a CSV. See page 15 from their PTC Live Global 2013 presentation.
Maybe someone on the community who knows John Deere can see if they might be willing to share this code.
One more note...is it possible to have an "included" list of Contexts instead of an "excluded"? We have over 500 contexts. Maybe it's as easy as changing the text from excluded to included.
wvs.jobs.publishFilter.excludedContextNameForPublication=PRODUCT3,LIBRARY1
Bill Ryan wrote:
Gary, may need some clarification on these two lines from the document:
Line 1) - by forcing the republishing for existing default representations, or not
Line 2) - Note: The Publish_EPMDoc_WithCSVFile schedule method deletes the existing Representation (along with any Annotation Sets) before publishing a new Representation
What happens if I'm NOT forcing the republishing of existing default representations and using the publish_epmdoc_withcsvfile function? I don't want to lose annotation sets on assemblies that are already published with a default representation. Do I need to make sure assemlbies with a default representation are not inlcuded in the CSV file for this scenario?
This is YSH's response:
Publish_EPMDoc_WithCSVFile UI scheduler method only use wvs.jobs.publishFilter.withCSV parameter and do not get any other parameter value in additionalEPMDocJobs.properties. It is hard-corded in AdditionalEPMDocJobs.java source as below.
AdditionalEPMDocJobs.java source 794 ~ 814 lines:
----------------------------------------------------------------------------------------------8<-----------------------------------------------------------------------------------------------------------------------------
/**
* Attempts to publish a Representable generating a Representation
*
* @param viewableLink If true and the data has already been published, the viewable data will be passed back to allow access by getViewableLink
* @param forceRepublish Overwrites an existing representation should one already exist
* @param objectReference Reference of the Representable to be published
* @param configReference Reference of the EPM Config Spec, if null, latest is used.
* @param partConfigReference Reference of the Part Config Spec, if null, latest is used.
* @param defaultRep Should the created representation be the default or not. The first representation in always default.
* @param repName Name of The representation to be created
* @param repDescription Description of the representation to be created
* @param structureType The type of structure walk to be performed
* @param actionString string representation of the action XML file contents
* @param jobSource int of source that submitted the job, 0=unknown, 1=manual, 2=checkin, 3=schedule
*
* @return boolean true if successful
*
public boolean doPublish(boolean viewableLink, boolean forceRepublish, String objectReference, String configReference, String partConfigReference,
boolean defaultRep, String repName, String repDescription, int structureType, String actionString, int jobSource)
**/
result = pub.doPublish(false, true, objRef, (ConfigSpec) null, (ConfigSpec) null, true, null, null,
Publisher.EPM, null, 3);
----------------------------------------------------------------------------------------------8<-----------------------------------------------------------------------------------------------------------------------------
Publish_EPMDoc_WithCSVFile UI scheduler method is hard-coded with below values:
viewableLink : false
forceRepublish : true
objectReference: Retrieved from CVS file
configReference: null
partConfigReference: null
defaultRep: true
repName: null
repDescription : null
structureType: Publisher.EPM
jobSource: 3
And,
Publish_EPMDoc_WithCSVFile schedule method will delete the existing Representation (along with any Annotation Sets) before publishing a new Representation. It will remove previously published Representation and it’s annotation. Both Representation and it’s Annotation should be removed together.
If customer comments out below lines in AdditionalEPMDocJobs.java source (787 ~ 791 lines). Then, the Publish_EPMDoc_WithCSVFile schedule method will force republish the CAD model and will not remove previously created Representation and its annotation set. i.e. Customer will see 2 Representation in the CAD Document.
Comment out these line in AdditionalEPMDocJobs.java source (787 ~ 791 lines):
/**
try {
deleteRepresentation(epm);
} catch (WTException e) {
throw e;
}
**/
Force to republish Result: 2 Representations
Answering some of my own questions...
Apparently the steps I listed in question #2 were sufficient. Those are the only things I did and the PublishUtilreadCSV.bat is working just fine. Also, I only included the ORs in the text file, so apparently that answers question #3 as well.
One thing you might want to ask the developer. This script appears to delete the existing representation first, then submits the job for publishing. On the other hand, if you resubmit a job from the WVS Job Monitor, it does not delete (or replace) the existing representation unless it is successfully republished. Is there a way to have this script behave that way so that if there's some problem with publishing the existing representations aren't lost? Probably not a big deal, just curious.
991 jobs were just submitted flawlessly.
Thanks again for this!!!
Just did my second run on production. The script processed 4,225 items in 44 minutes, so 1.6 objects per second or 96 objects per minute.
In some ways this seems a little slow, but I guess it's not a big deal since I can only publish around 20 objects per minute anyway. 
Loving this!
