WVS AfterLoader deleting secondary content

[khimani_mohiki]

Hi all, we recently implemented the Afterloader as per CS216668 following option 2, its working as expected and copying our additional pdf files to the secondary content of the Drawing. We left the files types as "pdf stp igs dwg"

So midway through the day I start getting calls from people telling me that their step files manually attached as secondary content to an EPMDocument were being deleted after checkin. We have a process whereby we create step files in Creo and save it directly to the EPMDocument, we save them with the naming convention <partnumber>_<version> (we dont publish step files as we often need to select different co-ordinate systems to export)

So it looks like the AfterLoader code is deleting any secondary content which contains the same string of characters in the name as the EPMDocument, for example I have a CAD Part called 1234567.prt and it has secondary content, manually attached, called 1234567_V1.stp, after check in that step file attachment is gone. If I create a step file attachment called 1234567V1.stp, it will not be removed on checkin.

I have the same thing happening with igs and pdf files attached as secondary content with the same number as the EPMDocument.

Has anyone ever experienced this before with the Afterloader and does anyone know what I could modify in the code to alter the behaviour to check if there are actually any additional files to copy to attachments before deleting the existing attachments?

The AfterLoader is great and exactly what our purchasing department wanted as a step imporvement to download drawings, but in its current form it seems I cant have any other attachements without changing their naming convention so they dont get deleted

Thanks

[MikeLockwood]

Take a look at code in attached screen capture. We experienced this also.  See PTC Article CS32811.

it's also possible though that you have a listener involved.

[d_graham]

Khimani,

You mentioned you set publish.afterloadermethod.copyToEPM.Filext=pdf dwg igs stp

If this is true then this is likely what is causing the unwanted delete.

You mentioned your users are manually attaching some file types. Therefore you do NOT want these file types extensions included in the value of publish.afterloadermethod.copyToEPM.Filext

Here's the thing. The publish.afterloadermethod.copyToEPM.Filext value is read by the OOTB AfterERDLoader method you are calling, copyToEPM. Each extension in the value gets processed by the method (deleted and then copied (attached)). Look at the AfterERDLoader.java source code and you'll see exactly what is happening.

Reset publish.afterloadermethod.copyToEPM.Filext correctly based on your requirements (don’t included any file extensions that the users attach manually) and all should work the way you want it to.

BTW, AfterERDLoader class is a very good starting point but it is just a starting point. For example suppose different users (for whatever reason) need different behavior from the AfterEDRLoader, then what do you do? Answer: Edit the source code to get that behavior. Or write your own class and point publish.afterloadermethod to it.

Hope this helps,

David

[khimani_mohiki]

Hi David, I knew you would know what was going on, thing is our data architecture, at the moment requires some pdfs to be manually attached to the Drawing EPMDoc, of course these pdfs have a file name which includes the drawing number leading to them being deleted by the AfterLoader even if the afterloader has no published pdfs to attach. so what I need to do is modify the code to only delete pdfs matching the naming string that the afterloader creates and not all pdfs witht he drawing number in the filename. But I dont kno where to start, any ideas?

[d_graham]

The solution required editing the OOTB AfterEDRLoader.java file.

In short, we needed to delete the pdf files but only if they had been attached from publishing jobs done to prior iterations. We can't just do a blanket delete of all pdf files because the users might have attached a PDF that's needed.

So, we looked at the syntax the AfterEDRLoader uses to attach as secondary the published pdf.

For example 12345.DRW B.24 will have a pdf filename of 12345_B.24.pdf

So, we edited the AfterEDRLoader to check a few things before it does the delete.

Filename as EXACTLY two "."

and

Filename ends with ".pdf"

and

Filename starts with EPMDoc's CAD name less the extension plus "_"

and

The characters between the two "." be converted to an integer

and

If the characters between the two “.” can be converted to an integer they are NOT equal to the current EPMDoc's iteration.

If all of that is true delete the pdf.

Another way I thought of which is probably more bombproof is to:

Query all iteration of the master.

Generate a temp filename by passing each iteration (except the current one, skip that one) to the AfterEDRLoader method getcopyToEPMFileName.  This method will return a String that is used to set the filename for the attached pdf.

If the currently attached filename equals temp filename it needs to go, delete the content.

Any other ideas? I'd be very interested in hearing them.

David

[SYang]

HI David,

My ideas is to delete only "Image" in the attachment as the afterloader creates them with this category using the following java code, 

appDataNew.setCategory("IMAGE");

We can also set it with other category that the user do not use.