Multiple afterloadermethods / AfterEDRloader

[JM_12529808]

Version: Windchill 12.1

Use Case: Rename representation files with revision, iteration, lifecycle state and copying the representation file to attachments (so we can get the files out when creating packages) 

Description:

We have set up the additional files (CS81396) - and would like to do multiple things with the files in the representations. 

Namely: Rename with revision, iteration CS349681 , lifecycle state CS252900 and copying the representation file to attachments (so we can get the files out when creating packages ) CS348848 

Is it possible to have these files running separately, or do I need to write the functions we need together for a single AfterEDRloader file?

As far as I can tell there is only a single publish.afterloadermethod that can be set

[mmeadows-3]

It isn't clear from your description.  What exactly are you renaming, the Creo View visuals or the additional files (STEP, IGES, DXF, etc.)?  I'm assuming the additional files.

I don't know this for certain, but Since AfterLoader is an individual property, most likely it can only be called once.  I would combine the content of all three examples to get the combined results.

A non-programmatic approach is to use GENIUS TOOLS Model Processor Worker to generate the additional files content, rename to include state and version.  The generated output files are uploaded as additional files by the WVS publishing process.

Uploading additional files as attachments doesn't require an AfterLoader hook: (CS353471) or WWGM (CS148494)

[JM_12529808 · Accepted solution]

Hi

Thanks for taking the time to respond. I wanted to rename both the file in the representation and set is as an attachment afterwards. 

The Answer to the  original question though seems to be that it is not possible to have multiple AfterLoader scripts, but that the desired functions must be programmed into a single file.

Regarding your note on WWGM, that works if the attachement files are generated by the user / on the user side. In our specific case they are auto generated by a worker, and does not have anything to do with the workgroup manager.