K2 Blackpearl: Goto Activity

When Goto doesn’t go when you want it to

When working with server side events I have found it common to reroute the workflow to a different activity within the workflow. Perhaps a user has decided to end the workflow and I want to send them to an End Workflow activity first. I would normally use the following code to do this:

K2.GotoActivity("NameOfActivity"); 

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }However to my surprise instead of the workflow moving to straight to that activity what actually happens is that the pointer linking the end of the current activity to the next changes to point to the activity entered in the GotoActivity code above. This means that if you have additional server events and potentially client events within the activity listed below the code containing the Goto they will still be processed leading to all sorts of errors further down the line.

The solution for me was to set a flag once the Goto had been called to skip out any further code execution. Messy but safer than allowing the code to execute. One to watch out for in your own code.