The "Kronos Guy" Blog

Kronos Totalization and the old Callable Totalizer continued...

OK. Per our Kronos Totalizer advisor and occasional blog poster DG, as of 5.2 there is no longer any such thing as a Callable Totalizer Engine. The so-called Callable Totalizer (CT) was an artifact of the Smalltalk implementation of the totalizer in 5.1 and earlier. From 5.2 onwards, all on-the-fly totalization goes through the same (multithreaded) totalizer servlet stuff.

The CT still exists, in the sense that it wraps core totalization with accruals and other secondary computations. That's why it's used by the accruals package as well as WAT. It's a focal point in the logic, rather than a throttling point for performance.

There are also a few errors that appear to be attributed to the CT such a:

• "WTK-032554 Callable Totalizer system error: Could not find item to delete", but this seems to be an Audit trail error rather than the fault of the remnants of the CT.
• In WFC.log "TotalizerProcessingException: Your connection to the Callable Totalizer has been lost. Please refresh your timecard." But this is a time zone error that the totalizer is freaking out about.

I KNOW there is more to say about this stuff. I'd love for you to add your 2 cents to the comments on this one.

Kronos Timekeeper Tips and Techniques December 11 Follow-up

I need to follow-up on this Improvisations eZine article about the Kronos Workforce Central Timekeeper "Callable Totalizer" settings. I had a couple of people quickly respond to me about that article asking about the settings as they were eager to give them a try. So I grabbed my notes (screenshot #1 from v5.0 click to enlarge) and sent off a response, promising to follow-up here. Well it looks like I've been caught...

It seems that Kronos pulled the Callable Totalizer (CT) into the main Totalizer program with the Background Processor (BGP) starting at v5.1 or 5.2. My CT notes were from v5.0. I don't have a 5.1 system to look at right now but I'll check and report back later if someone here doesn't beat me to it!

The only choice we have starting with 5.2 (screenshot #2 from 5.2, click to enlarge) is to set the number of threads in the BGP to more than one. I've spoken to a couple of people from Kronos about this and neither one said that much is to be gained by messing with that setting. It's better to run a second BGP. Doing a little more spelunking I find that the best practice has more to do with maximums than minimums.

If you have a combined Workforce Timekeeper App/BGP server and testing shows you that the BGP isn't keeping up, you might find a benefit to configure two BGP threads. (If you do try two you might also need to increase the maximum number of database connections above the default.) If you have a standalone BGP you can configure up to four processing threads. More than that provides diminishing returns and one should consider another instance of a BGP.