Skip to main content

It might work but I haven't tried/tested it.

Instead of drawing another line to bypass an activity, can I have a server event first that checks for condition, then uses k2.gotoactivity to bypass the ClientEvent that follows the ServerEvent?   (I know about GotoActivity eliminating other parallel activities.)

 ACT#1

----------

Server Event w/GotoActivity to ACT#2

Client Event

 

ACT#2

----------

Yes I believe you could.  However, it is normally a good practice to keep the server event separate from the client event.  Client events might create multiple slots, causing your server event code to execute multiple times.  The other issue is that using GotoActivity calls doesn't reflect the flow in the ViewFlow component.

Thanks,  my activity has "Limit the number of slots to 1", but it does assign to multiple destinations.


If I recall correctly, for K2.net 2003 the server event would fire based on the number of destinations (unless you were using the destination queue optimization feature).  This was independant of the slot configuration as multiple activity instances would be created.


 This changed in K2 blackpearl for performance reasons.

My experiment did not work, it ended up creating a parallel activity when the server event's gotoactivity did not expire the current activity.  

I don't know if that's a bug or undocumented feature.

ACT #1 and ACT #2 are both active...

I'd like to chime in on the dangers of over-using the GotoActivity.  If you put your conditional logic in code events and use GotoActivity instead of using line rules, you run the risk the someone in the future will not understand the logic of your process is accomplished using Goto.  A good reason for using line rules is they serve as a kind of documentation about how the business logic is supposed to flow.  For the same reason GOTO is discouraged in VB, COBOL and every other language, I would discourage their use in workflow processes.

I would agree with David on how dangerous the GOTO activity can be, however, some business rules are unacheivable without this method.


The GOTO activity only helpful when you want to escalate/expire another activity that is not accessable from where the process is sitting right now.

That doesn't sound right.  The GotoActivity should expire the activities before doing the Goto.  Do you have a copy of your process file that we can have a look at?

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings