Video Screencast Help

Process / Task Termination

Created: 25 Feb 2013 | 6 comments

What is the correct way to terminate a specific process and any associated task?

Operating Systems:

Comments 6 CommentsJump to latest comment

rhamner's picture

It depends on your task source and what you expect to happen. In publishing options of a project there's an allow workflow abortions property. This exposes an AbortWorkflowProcess method on your service which kills the workflow but doesn't do anything with tasks. So, if you use Process Manager task source your tasks are still active but they'll blow up when you try to work it.

The proper way to handle this IMO so that tasks are closed and you can log what happens is to use the Message Listener on the Dialog Workflow component (or any workflow component). This allows you to use the Send Complete Workflow Message component from any other process and it will resume the workflow on the path defined in Message Responses (see screen-shot below). On that path you can do any necessary logic and then go to an end component. The example below is simple but the same concept should work with more complex workflows. 

* In Send Complete Workflow Message component specify the service id of the project that contains the task you are trying to terminate. Otherwise, all running projects will try to process this message and its less efficient. Also, by default it sends a blank message but you can pass a variable to the message listener.

A sample project is attached.

WorkflowProject1.package 146.96 KB
Aryanos's picture

Are tasks supposed to be removed from the tasks table when the workflow is completed or aborted? I thought it always stays in the table no matter what.

I like my beats fast and my bass down low

rhamner's picture

They're not removed either way. The important thing is whether or not they are completed. If you simply abort a process that has active tasks then those tasks will still show in the task list. In the example above the tasks are actually completed and the process finishes.

If you wanted to about a workflow and completely remove all trace of it then you'd need to call abort then delete all the tasks and reporting data. 

AnaMan's picture

This exposes an AbortWorkflowProcess method on your service which kills the workflow but doesn't do anything with tasks

Are you sure rhamner?
What about the ClearWorkflow method called at the end of the AbortWorkflowProcess??
Most of implementations of IWorkQueue have in this method removal of work queue items.
Moreover the same method is called to clear the process when flow reaches an end component in top level model.

rhamner's picture

Nice reflecting smiley

By tasks I mean TaskSource tasks, i.e. Process Manager tasks. WorkQueue is the 'persistence' tasks and is basically a higher level than TaskSource. You may or may not have a PM task for a WorkQueue task. So, ClearWorkflow only clears things out of messages table and doesn't touch PM tasks. However, you've uncovered a bug. AbortWorkflowProcess does complete the TaskSource tasks, however it's not being called by the project's AbortWorkflowProcess method. That's calling ClearWorkflow and therefore only closing WorkQueue items. I just assumed this as by design, though not ideal. I've created a bug for this to get it fixed. Thanks.

AnaMan's picture

I know what you mean. But my sight is a bit different - we're using our own TaskSource.

But still, I think, we have the same problem. A separation a TaskSource service (RemoveAssignment) from an exchange message service (RemoveWorkQueueItems) causes that in case of an exception (during assginement service or a fininsh event processing) an "orphan" task messages remains in queue. Such tasks still can be processed, for instance by time-out, and can unexpectedly continue the process flow. We call them "zombie". wink

A whole task service should be bind in transaction but I'm aware that's a problem - a two different data structures in two different phases of integration (an exchange and a task management).