Hi,
The easiest method to achieve this would be to design the cancel into your process. This normally is done by having two paths the workflow follows at the start. The normal path and the cancel path. The cancel path contains a client event that assigns a task to a user or group who can then choose to action the workflow to cause a cancel to occur.
The cancel is achieved by using an API call in the workflow called "GoToActivity" what this does is when it is invoked with the proper settings, cancels all other activities in the process. So if a user invokes this from cancel it kills off the other branch effectively canceling the flow.
The workflow would look like this:
If you will notice, both paths to to the Go To End activity which contains the one line of code. This is so which ever path finishes first, kills off the other path. So if cancel happens it kills normal, if normal happens it kills cancel and the workflow ends in both cases.
The code you will use (Using Visual Studio) will look like this:
K2.GotoActivity("END", true);In this example, END is the name of the activity I want to go to. It could be End, complete, StarLord whatever you named the activity. Just has to be a valid name and the activity you intend. The true option is telling the API you want to expire all. (ie kill off the other branch of the workflow).
The event in the workflow is very unassuming and looks like below. In Visual Studio, you just right click on the server event and choose "VIew Code".
Some may be saying "You can just stop the process from the workspace" and that is a true statement, that also requires elevated permissions. To expose that functionality in a Smart Form would require custom service broker work.
What I like about this approach is that you are not only meeting a requirement with out of the box functionality, you are also making the cancel functionality something that is traceable as it is part of the workflow's natural execution so K2 reporting will keep track of who canceled when. You could even collect a comment as to why it canceled. You've moved the cancel functionality from being an administrative override to being a part of the nature business that the workflow is conducting with all the bells and whistled that comes with it. You can even have your process notify the originator that the workflow was canceled.
Hope this helps.
S.
After re-reading your original post, for the cancel step you could just use the originator as the destinaiton user for the cancel activity so it puts a task back on the person making the request thereby enabling them to cancel the request themselves.
S.
Thanks Scott. I'll try and find time this week to add this step and see how I get on.
I'll update this thread once I have tried, thanks again, Dan.
