Start Rule - Start on Date then Date changes

  • 2 March 2009
  • 6 replies
  • 9 views

Badge +9

Can someone clarify what will happen in the following scenario:


1. In my process, there is an activity with a start rule, which starts the activity on the date contained in the field STARTDATE
2. Whilst the activity is waiting to start, the value of the field STARTDATE is changed to a different date


Will the activity start on the original date, or on the modified date?

Thanks in advance for any assistance!


6 replies

Badge +11

The original date.  The values in the start rule at the time it is evaluated are used to determine when it will start.

Badge +9
Thanks David - I appreciate the quick reply, even though I was hoping that wasn't the case!
Badge +4

Any way to work around this so that start date can be effectively modified in the running workflow?

Badge +8

You can do this, but you have to use a Server Code event.  General overview of the logic to do this:

 

1. Using the Activity Instance SmartObject, find all activities with a status of Waiting.  Add additional filters as appropriate (e.g. process instance ID, specific process names, etc.)

 

2. Use the K2.ExpireActivity() method to kill the activity that is waiting.

 

3. Use the K2.GoToActivity() method to force your process instance to go back to the same activity.  The important bit here is to pass false to the second parameter of this method (expireAll).  This will force your process back to the same activity (without expiring all other activities).  K2 will then re-evaluate your start rule for the activity with the new value of your date parameter.

 

We are actively using this method in several processes that are date driven.  It works very well.

Badge +4

So from what I gather this method will work if something within the same process modifies the start date, since K2.ExpireActivity and K2.GoToActivity use the context of the current running process. What if the start date is modified externally, say by a SmartForm calling a SmartObject?

Badge +8

The mechinsm gets more complicated, but the general process should still be the same.

 

You would need to register an event listener for the SmartObject that updates the particular field.  Within the event handler, you would need to use the SourceCode.Workflow.Management API to call the WorklistManagementServer.GoToActivity() method to accomplish the same task.

 

Note that we don't have to worry about this scenario in our processes, so this is brainstorming only. :)

Reply