I have a process which is going to be using the K2Mng.dll to call the GotoActivity() method & make my process jump to a specified activity, no matter where it currently is in the process.
Instead of having to pass the K2 Server name & Port number in to the process, i'd just like to pick up whatever the current server & configured port number is. But, i can't seem to find it via the ServerEventContext object that i have access to.
Is there another way to find it?
thanks,
Wes
Find server name & port used from ServerEventContext
+4
+8This 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?
+4NeilM:
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 :)
+11- Nintex Employee
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
+3Yes I confirm this point, ALL active Activieties will be expired and ONLY the new Activity will be instantiated.
Aude
Aude
+4yes 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.
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.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.