This is not the answer you asked for, but if you are executing this redirection within the same process instance that you want to redirect, why not just use K2.GotoActivity("ActivityName") instead of going to all the trouble of using the K2MNG?

---

NeilM:

This is not the answer you asked for, but if you are executing this redirection within the same process instance that you want to redirect, why not just use K2.GotoActivity("ActivityName") instead of going to all the trouble of using the K2MNG?

the purpose of this is to basically be able to cancel an entire process in one go, i.e. wherever the current activity is within the process & no matter how many activities are concurrently running in parallel etc focus will just move to the activity specified. The method you mentioned would be used for redirecting each of the active activities to a different activity, i.e. still having multiple activities running.

it's basically copying what the K2 Service Manager allows you to do when you search for process instances & then redirect them

thanks anyway

---

The method you mentioned would be used for redirecting each of the active activities to a different activity, i.e. still having multiple activities running.

No, as far as I can remember, even if you have multiple Activities running in parallel, as soon as you use 'GotoActivity(...)' from anywhere (K2Mng, K2ROM, ServerEventContext, EscalationActionContext), ALL active Activieties will be expired and ONLY the new Activity will be instantiated.

It's been a while since I've worked with this 'GotoActivity' logic, so please test it first.

Regards,
Ockert

---

Yes I confirm this point, ALL active Activieties will be expired and ONLY the new Activity will be instantiated.


Aude

---

yes we've just found this out :(

according to the help documentation this only applies to the EscalationActionContext:

Use the GotoActivity method to force the process to a specific Activity contained by the same Process by passing in a valid Activity Name as the required parameter

The ServerEventContext version of GotoActivity is as follows:

Force K2.net 2003 Server to expire the current ActivityInstance and "GoTo" to another Activity within the same ProcessInstance

And the WorklistItem version of GotoActivity is as follows:

The GoToActivity method is called to force the associated instance of the WorklistItem to go to a specific activity within the process.
Force the Process to expire the current Activity and start the specified Activity

Therefore, is EscalationActionContext the only one that forces all active activities into the newly specified activity and is there a reason for this? This basically means that we cannot have parallel activities having their own escalations that use GotoActivity.

We have a workaround now which is to set a process datafield to true in the escalation action & then expire the activity. Then, the line rule to the activity that is to be done if the escalation occurs, only evaluates if the process datafield is true.

---