WVS: Afterloader hook method to rename files generated by CAD Worker from client side viewables?

[CarTorn92630]

For our Windchill Visualization Services, we are using Afterloader (AfterEDRloader3) hook method to rename visualization files to PartNumber_Revision based on attribute values.

This method is identified in: Article - CS252900 - Windchill PDMLink: An example Afterloader hook method to add the attribute value from the viewable files to the name of output Additional File Types

This works very well for EPM Docs pushed from Commonspace and message ""AfterEDRloader starts: Checking if object is EPMDoc: appears in WVS Job Monitor log file when method completes.

Now we want to leverage client side preprocessing of visualization files per: Article - CS21380 - How to edit Client-side Recipe configuration used by Creo Parametric and the Workgroup Manager clients during Windchill Custom Check-in of "Models and Viewables"

However, the Afterloader hook method fails to rename the visualization files when sent to WVS CAD Worker and message "AfterEDRloader: Return Code - Bypass" appears in WVS Job Monitor log file when method is called.

How do we get the AfterEDRloader method to also rename visualization files generated by CAD Worker from client side viewables?

[TomU]

That message is coming right out of the AfterEDRloader3.java file:

// getPropertyStringValue
String subdirectory = getTransferDir(edFileName);
File pvs = new File(subdirectory, edFileName);
if (pvs == null || !pvs.exists()) {
	ret[0] = "AfterEDRloader: Return Code - Bypass";
	return ret;
}

You'd have to add some extra debugging lines to be sure but I'm guessing something is different with the bundle of files based on how the representation is being created.  (From CS66824, "When the CAD Document is then published by WVS, the pre-converted viewables in the attached PVZ are used to create the Representation content, instead of publishing using a server-side CAD worker.")

More than likely edFileName (in the previous section) is never getting set:

// get the ed file Name for this representation
String edFileName = null;
Representation ch = (Representation)ContentHelper.service.getContents(rep);
appDatas = ContentHelper.getContentList(ch);
int num_of_files = appDatas.size();

for (int i = 0; i < appDatas.size(); i++) {
	appData = (ApplicationData)appDatas.get(i);
	if (appData.getRole() != null && appData.getRole().equals(ContentRoleType.PRODUCT_VIEW_ED)) {
		edFileName = appData.getFileName();
		break;
	}
}

I'm actually curious why you would want to switch to this method of viewable generation?  There are an awful lot of disadvantages.  (Again, see CS66824.)  If it's due to worker availability when publishing very large assemblies, there are ways around this where you can direct very large assemblies to certain cad workers and everything else to other workers.

[CarTorn92630]

Thanks, Tom.

One of our engineers found the issue and corrected it.

We are not switching to this method, merely lookign at using it to augment our existing WVS CAD Worker capabilities.

Our existing WVS utilizes dedicated CAD Workers for multi-language pdf, step, pvz and dwg generation.

This works well enough; however, in our time sliced VM environment we had release drawing pdf's that would consistently take 10-20 minutes or even up to an hour to generate a pdf.

With considerable performance tuning I was able to reduce this 25-40%; however, this was still not a good solution as it did not scale very well. For example, reducing the time from 20 mins to 12 mins looked good in powerpoint. However, in production I might have 10 of these 12 minutes jobs ahead of mine, so incrementally faster CAD Workers wasn't a very useful solution.

The beauty of client side viewables is that most of the processing occurs locally and the CAD Workers are only used to convert the attached client side viewable and bring it back into windchill as a viewable.

The conversion of client side viewable to release drawing pdf by CAD Worker is staying pretty consistent at 5 seconds no matter how many files in the source file or how many drawing sheets are generated.

To me, this is much more acceptable and very scalable and with a couple of our clever engineers figuring out how to rename the pdf to partnumber_revision witth AfterEDRloader3 prior to passing it back to Windchill, this may be automated performance we have been looking for.

[G_U]

HI, 

I also tried the article CS252900 but not working for me i deployed as it is the customization. and added two-property -

xconfmanager -s publish.afterloadermethod="com.ptc.wvs.util.AfterEDRloader3/renameAdditionalfiles" -t codebase/WEB-INF/conf/wvs.properties -p

xconfmanager -s

publish.afterloadermethod.propertyincludelist="epmdoc_Number,epmdoc_iterationDisplayIdentifier" -t codebase/WEB-INF/conf/wvs.properties -p

and tried to republish the one drawing but still pdf name is filename+Version.pdf.

Anyone, please help us.

Thanks, 

Gourav Upadhyay

[Ajit_Kulkarni]

Hello,

We have customization in place to achieve this. The customization is not limited to renaming but it does much more like pdf watermarking. I think it would be much more easier for you to do it through customization. Kindly let me know how it goes.

Regards

Ajit