Are default working hours dymanic? Is the start rule date absolute?

  • 30 September 2009
  • 7 replies
  • 0 views
D
Badge +3

If one changes the default working hours, will processes already active use the new definition of default hours, or is a copy of default hours taken at the start of the process instance?


Also, in a start rule, if I use a date for the start (rather than a number of hours/days), if the server is down on that date, or the process was in error state due to a timeout in trying to contact a mail server, when the error is cleared will the activity start if the date specified is past. i.e. is it a greater than/equal to evaluation, or a equal to evaluation of the date.


I'm having some unexpected behaviour with start rules and would like to know how they should behave. 


Thanks

7 replies

D
Badge +8

I did a quick test and the Start Date of the Activity itself is set at the point when the Activity is instantiated. So, it should take the Working Hours when the Activity is started, not when the process is started. So you should still be able to change working hours up to the point where the Activity is started, once its started however, I don't believe that you can change it.

To answer the second question, the worker threads check the relevant table periodically doing a Greater or Equal comparison. So any Async items will still fire even if the exact date has been missed.

What are the  unexpected behaviour you are expecting?

D
Badge +3

Thanks dc.


I am having 2 problems:


1. The default working hours were changed from 24/7 to 8:30am-5pm weekdays, and then activities with a 1 day/24 hour delay were not starting - I think it is because these counters were now taking almost 3 days to get through the 24 hours. I just wanted to know whether changing it back would affect all processes already active. You have answered that for me.


2. Other activities have a start date. Many of these are "paused" even though the date is in the past. I think because of memory leak issues in our build, the process had crashed overnight a few times, and the triggering of these dates normally happens just after midnight (no time part set in the date). I am wondering why these don't fire now. Even a process stop-start don't kick it along. A Goto operation to the same activity seems to work. Just thought I shouldn't have to do that.


We are updating the k2server to the latest patches this weekend - perhaps that will help too.


Thanks again for your help.

D
Badge +8

Mmm, it seems strange the the Activities didn't start up. If you have a copy of the databases before the GoTo, you can check the start date if you know the Process Instance ID:

SELECT * FROM K2Server.._Async WHERE ProcInstID = %YourID%

The Date field is the date that has been scheduled. 

D
Badge +3

Should the records in this table only have future dates? Mine has ones up to a week old. And the Type column: does 1 = escalation rule,  2 = start rule ??


How often are these async record dates checked for ones that are due? Is there a way to force the K2 Server to recheck these?  


Thanks

D
Badge +8

Yeah, records that are that old generally indicates that something odd is going on. The worker threads threads checks a few times a second (depending on load) so it should not be that old. 

I would start to have a look at the K2 logs, see if there anything useful in there. Also check the status of the process that the item belongs to, make sure that it is running as expected.

D
Badge +3
Thanks for the help. I'll investigate further after the latest patches are in and see if this issue clears, or whether further action is needed. Cheers.
D
Badge +3

Just to complete the story...



  • The updates were done but didn't resolve the issue - although it helped the memory management
  • Problem was caused by an error in one instance of one activity's start rule - not sure what but was as yet explained "corruption" that the support guys are looking into. The problem reoccurred on same activity in a different instance too.
  • I started using fixed dates (stored in a data field and calculated in a server code event) for all start rules where possible to avoid the resetting of the delay when using the Goto opertion to attempt to clear a stuck process - one K2 support member even suggested putting the start rule on an empty activity before the activity you want to delay
  • Knowing about the _Async table and being able to check it is very helpful now. Thanks for the heads-up dc.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings