[Working Time Model] New options to improve performance when "Working Time Model" functionality is activated

I Introduction

II New Features

III Additional Notes

I Introduction (Back to Table of Contents)

To actively work with "Working Time Models" and "Time Accounts" in Coresuite Time, the flag for "Enable Working Time Model" (Administration->Add-ons->coresuite time->General Configuration=>Miscellaneous tab) needs to be set.
This setting ensures that "target times" are automatically recorded in the Database. Automatic "target times" processing applies to any (open) resource with a currently valid "Working Time Model" assigned.
Every day, the "Target Working Time Model processing" kicks off upon the very first user connecting with Coresuite Time. The system starts with a check that for each resource all records have been written historically and then adds the new record(s). In addition, this process is triggered again by every further Coresuite Time user that logs on after the "Target time lock interval" has passed. This process can be quite CPU expensive predominantly depending on the number of open resources and the period since a "Working Time Model" has been assigned to them.
With the release of Coresuite Time, Version 7.50 we have introduced a new feature to improve this process.

II New Features (Back to Table of Contents)

We added a new option to accelerate the "Target Working Time Model processing". Below the "Enable Working Time Model" tick box, there is now a choice between "No Acceleration" (default setting!) and "Accelerated Working Time Processing". In addition, there is a new button labelled "Custom WTM processing".

• No Acceleration
  This is the default setting.
  For new installations or Coresuite Time upgrades, this option is automatically set. An upgrade does NOT automatically change the current behaviour.
  The system continues to check all historical Target times entries for each resource (marked as open and with a currently valid "Working Time Model" assigned!), adds any potentially missing historical Target times entries and also adds the new Target times entry/entries up to and including the current date.
• Accelerated Working Time Processing
  This is the new option.
  This option is NEVER set automatically. After installation or upgrade, you need to select this option to avail of the "Accelerated Working Time Processing". The system only checks the date of the latest (newest) Target times entry for each resource (marked as open and with a currently valid "Working Time Model" assigned!) and adds the new Target entry/entries up to and including the current date.
• Custom WTM processing
  This new feature can be used to ensure the consistency of historical Target time entries for each resource (marked as open and with a currently valid "Working Time Model" assigned!) for any specified period.
  The system checks the historical Target time entries for each resource (marked as open and with a currently valid "Working Time Model" assigned!) for the selected period, adds any potentially missing historical Target times entries and also adds the new Target times entries up to and including the current date.
  This feature has been added to replace the automatic checking of all historical Target times entries for each resource (marked as open and with a currently valid "Working Time Model" assigned!) which by default is part of the standard (now called "No Acceleration") "Target Working Time Model processing".
  Since the "Target Working Time Model processing" with the "Accelerated Working Time Processing" option has proven to be far less CPU expensive which results in quicker processing times, there should be no need to check the consistency of the written Target times as much any more in the first place. But to give you peace of mind, we added the "Custom WTM processing" feature to be run manually at any time.
  At present, a button labelled "Custom WTM processing" has been added in this position, but there will soon be an additional menu entry under the "Time Recording" for easier access.

III Additional Notes (Back to Table of Contents)

As explained in the Introduction, the "Target Working Time Model processing" process can be quite CPU expensive. On one hand, you want to make sure that there is a process in place that ensure that all respective Target time entries are created daily, on the other hand, you do not want the checking process to run/re-start again for every single Coresuite Time user that logs on.
To control this, a rather hidden feature ("Target time lock interval") had been introduced to Coresuite Time with version 4.15:

The "Target time lock interval" ensures that the checking process DOES NOT run/re-start again for each and every single Coresuite Time user that logs on, but only for users that log on after the specified period has elapsed.

By default, this period is set to 60 mins. This means when the first user logs on at 07:50 and the process starts for the first time, the process would not run/re-start again for any user logging in the period until 08:51. So, even if 20 users log on between 07:50 and 08:50, only one process is running; only for any user that logs on afterwards, the process will run/re-start again. And again, the system tracks when the runs/re-start has commenced again and prevents it from running/re-starting until the next 60 minutes have passed.
As this is a hidden feature and had never been included in the official "Coresuite Time Manual", we would assume that the default 60 minutes setting is unchanged in the majority of Databases. 
We recommend checking this when encountering CPU/performance issues and altering the value as necessary. If the value is set to "0", it means the process will run/re-start for each and every user logging on to the system. Depending on your individual situation/environment this could easily lead the system to crash. We recommend either using the 60 minutes interval or any interval that fits your individual situation/environment.

(Back to Table of Contents)