Run Custom Job Once When Assembly Promoted to Released State

[con_smith]

Is there a way to run a custom job once when an assembly is promoted to a released lifecycle state? 

Basically, when an assembly is promoted to a released state, I want to run Custom Job X one time that creates a folder structure then adds the path to a file flag, and then Custom Job Y successively for each part / subassembly in the assembly being released so files are dumped into the folder path added to the file flag. 

[Nick_Hall]

Hi

The trouble with custom jobs is that they will be submitted for every file that uses the lifecycle. Your first problem is to decide which files should be processed.

One option is to put the files you want to run Custom Job X on into their own category & lifecycle. This could be a bit painful to implement, especially if you already have a lot of files in your vault. That way you can set Custom Job X to run for every file in that lifecycle

Another option, which I've used, is toi add a boolean property to the files, which you would default to FALSE, and change it to TRUE for the files you want to run Custom Job X on. Then, in Custom Job X, you put code at the start to look for the property, and to exit the job with a success if it is missing or FALSE.

The main bulk of Custom Job X would create your folder structure , add its path to the file flag, then "walk the assembly tree" adding Custom Job Y to the queue for each file in the tree, passing in the ID of the file as a parameter. You could also pass the path of your new folder to Custom Job Y as a parameter so that it is immediately available when you copy the files there.

Custom Job Y would read the File ID parameter, use that to get the vault file object, and copy the relevant files to the folder specified in the other parameter.

Hope that helps

Nick

[con_smith]

Hi Nick, 

That does help, and it gives me a few more ideas -  thanks for that. Perhaps the proposed method still might cause issues. The series of events I am after are as follows:

1. Change State of assembly to released. 

2. Run Custom Job X one time to create the folder structure, and run this first before moving on...

3. Run Custom Job Y to export the the files to the created folder structure (using the path to the directory from Custom Job X, passing as a parameter perhaps) for every part/subassembly in the released assembly. (Essentially, just do what you normally do after you run Custom Job X once).

There's more to the program than that, but that's the only part I am having troubles with. 

If no matter what, Custom Job X will be submitted for every file that uses that lifecycle, then it sounds like I will be creating the folder structure and "walking the assembly tree" a number of times = the number of files changing state to released. So, I'll get (in some instances), 10x or more folder structures, which is the problem. All I need is one folder structure for that specific release. 

If there's no way to specify to run Custom Job X once (and first in the queue), then it might be better just to create another button that creates the folder structure and adds the path to the file flag, and then Custom Job Y just reads the path over and over. Not as automated as I'd like (it leaves room for human error in that people may forget to click the button before releasing the assembly), but its enough for this job, maybe. Unless, there are other suggestions to help streamline this... I'm all ears!

[Nick_Hall · Accepted solution]

Hi

• If no matter what, Custom Job X will be submitted for every file that uses that lifecycle
  
  That's correct
  
  
• If there's no way to specify to run Custom Job X once (and first in the queue), then it might be better just to create another button that creates the folder structure and adds the path to the file flag, and then Custom Job Y just reads the path over and over.
  
  I would still try to completely automate it as you originally planned.
  Althought the jobs will all run, the key thing will be to make sure that the ones don't need to run complete as quickly as possible

Based on that I would use the following logic for Custom Job X, assuming that you only want it to run for the top-level assembly

if (fileExtn is not "iam") {
  JobService.UpdateJobSuccess(jobId)
}
fileAssocs = DocumentService.GetFileAssociationsByIds(whichever parameters are required to return the file's direct parents only)
if (any of fileAssocs are "iam") {
  JobService.UpdateJobSuccess(jobId)
}

If it fails either test, it will be quick, and not take up too much processing time

If it passes through those checks, it will be the top-level file that needs processing, and you can make the folders & add the Custom Job Ys.

Hope that gives you a bit more food for thought

Nick

[con_smith]

Thanks, Nick. I gave it a try - the subassemblies were triggering the Job X on the simple test assembly I made. 

I think I will try to add a context menu extension button that adds the job and passes the file context to the job processor instead of having the job trigger on a lifecycle transition. Then, it will run the code one time in one big job. If I can manage that, it works out nicely from the perspective that people could opt out of the 'big job' if they so choose (which I can see being a nice-to-have in some cases). 

Thanks again for all the tips/help!