nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Intercept the abort of a workflow

dorfi

Is there any way to define some operations to be done after the job is aborted?

Find more posts tagged with

Comments

Adam Stoller

Is there any way to define some operations to be done after the job is aborted?

Perhaps - it depends on what you mean by 'aborted'.

If you mean you provide a transition option within the workflow to cancel a job, then yes - you can transition to some task(s) to do cleanup and/or notification about the canceling of the job.

If you mean that someone is using the UI's "End Job" and/or the iwrmjob CLT - then you might be able to trigger an iwat script -- you'd have to look at the events that get logged in such a situation and ensure that they are distinct from those that get logged when a job ends "normally" -- not sure that it does.

You might be able to handle the UI issue differently through UI customizations if you can find a means of removing the OOTB menu options for ending the job and providing your own custom options in its place - but that won't do anything if someone uses the iwrmjob CLT.

dorfi

I mean that someone is using the UI's "End Job"

Adam Stoller

I mean that someone is using the UI's "End Job"

Well, this is more of a training and workflow design issue (training people not to use that option unless it's a last-resort; designing transitions that allow people to gracefully terminate a job from within the context of the process flow).

That being said, you could look at what events are being thrown and perhaps play with the option in iw.cfg (delete_jobs_on_completion) such that an iwat trigger script might be able to do "something" after the job has been killed. You'd have to code the script to be able to look for something within the job details (e.g.: iwgetwfobj or via TeamSite::WFworkflow / TeamSite::WFtask or their CSSDK equivalents) that will allow it to quickly determine whether the job was or was not killed prematurely - if it wasn't, just exit. If it was - do what you need to do.

Keep in mind that the event (presumably "WorkflowInactivate") will probably fire for both graceful and non-graceful job termination - but if you have an End Task named "End" (for instance) you should be able to verify whether that task, for that job, was ever activated. If it was - the job terminated gracefully; If it wasn't - the job was terminated by force.

I'm not sure what one does to truly clean out the job history if you have delete_jobs_on_completion set to false - but you'll need to figure that out (and please post the details if you do) because otherwise it is possible your workflow store may bloat to the point where you'll have to remove it completely and let the server re-create it.

dorfi

Thanks ghoti, my goal was in fact to understand if there is any point that allowed to catch the "non-graceful" job end , before going to define other transitions for the same purpose.

I will have a look at log files to better understand

Performance gadget not displayed.jpg