When using queues on workitems, delay of 1 minute before able to edit workitem
Paul_Bosch
Partner IT Monkey ✭
Hi, ive also raised an incident for this.
When using queues on workitems in SCSM, this causes a delay in user/analysts being able to edit the workitem in the portal. It is being displayed in the my requests but not in active work (which corresponds with the workflow intevals). Afther approximately 1 minute it shows up in the active work list and only then are analysts able to edit the item. This is quite frustrating when duplicating or creating an item/issue which they are working on.
We managed to speed up the workflow from the SCSM side of things using a registry key on the MS server and now we would like to set the workflow of the cireson portal to a lower value (to test things). Unfortunately the interval in de cachebuilder windows service config file limits the value to be set in minutes.
Is someone able to tell me/us how to set this to a lower value than 1 minute?
Kind regards,
Paul
When using queues on workitems in SCSM, this causes a delay in user/analysts being able to edit the workitem in the portal. It is being displayed in the my requests but not in active work (which corresponds with the workflow intevals). Afther approximately 1 minute it shows up in the active work list and only then are analysts able to edit the item. This is quite frustrating when duplicating or creating an item/issue which they are working on.
We managed to speed up the workflow from the SCSM side of things using a registry key on the MS server and now we would like to set the workflow of the cireson portal to a lower value (to test things). Unfortunately the interval in de cachebuilder windows service config file limits the value to be set in minutes.
Is someone able to tell me/us how to set this to a lower value than 1 minute?
Kind regards,
Paul
1
Answers
Currently you cannot set that interval to less than 1 minute, however you may be able to get around the issue by adjusting the Admin Setting Item "LastModifiedAdjustmentInMilliseconds" to be equal to 300000 (which equals 5 minutes).
This would catch any workitems that were updated in the past 5 minutes everytime the interval runs.
Thanks for your quick answer.
We've already set this to a low value but this does not 'speed up' the interval.
Or should it be a higher value (the 5 minutes you are referring to) to solve this issue and be able to edit the workitem more quickly.
Kind regards,
Paul
Please try setting this to a higher value as this number is deducted from the last time the interval ran and then the product is used in the queries to determine what has changed since that time.
As an administrator (with no queue limiting my view) i do see it appearing asap and it's editable.
As an analyst with no queue on the workitem, on the same workitem type i experience a short glitch (getting an error first when trying to edit, refreshing it and editing again provides me with no errors)
As an analyst with a queue on this type of workitem results in the problem specified.
We've set the regkey hklm\software\microsoft\system center\2010\common\GroupCalcPollingIntervalMiliseconds to 10000 (decimal) -for SCSM- and noticed, after setting this value that the scoped user would see it a lot faster. Now its limited to approx 1 min before its shown and is editable.
thx again,
Paul
<cacheCommand name="WorkItems" threadName="WORK" refreshInterval=".5" batchSize="500" />
Please give this a try.
Ive changed the setting in the "C:\inetpub\CiresonPortal\bin\Cireson.CacheBuilder.WindowsService.exe.config" file with the decimal number. Although i cannot see any improvement when repeating the process (creating the workitem), is there a way i can monitor the interval from triggering? Should i set the cb log to debug to get this information?
Thanks,
Paul
Yes the only way to see how often it is running would be to enable logging.