Loading

Subscribe to this Blog

Your email:

Are you preparing for an implementation or upgrade?

Kronos Implementation Strategy

Download the WFM Implementation Strategy White Paper

About Bryan

Resume Pic of Bryan deSilvaMusician & Yin Style Bagua practitioner. Over twenty years of software implementations and upgrades, project management, systems and applications development experience with a current focus on ADP eTime & Kronos Timekeeper/HR systems implementation. 

Topics

The "Kronos Guy" Blog

Current Articles | RSS Feed RSS Feed

Kronos Timekeeper Tips and Techniques December 11 Follow-up

Posted by Bryan deSilva on Mon, Dec 22, 2008
  
  
  
  
  
  
Add to delicious  delicious  
  
  
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.


Tags: ,

Comments

As of WFC 5.2, there is no callable totalizer process per se. The CT and its pool of instances existed originally because the CT (like the BGP) was as Smalltalk application that communicated with WFC through TCP/IP sockets. As of 5.2 the CT and BGP are purely implemented in Java. So, there is no socket interface--every timecard editing session in the WFC application server can call the CT logic directly. 
 
The Java implementation is faster than the Smalltalk implementation, probably because the latter had to squeeze timecard data across a TCP/IP socket. Even though the CT Smalltalk image ran on the same machine as the WFC server, large amounts of CPU time were spent serializing (marshalling) data between the CT and the WFC timecard editing session. None of this is necessary, now. 
 
On the other hand, having a fixed-size pool of available CT sockets set a natural limit on the number of CT callers. As of 5.2, there is nothing (that I am aware of) that limits the number of active timecard editing sessions in WFC; therefore, there is nothing that limits the number of concurrent totalizations; and, since totalization can be CPU intensive, one imagines that in some cases (e.g., employee hasn't been signed off for 12 months, and the holiday credit rules are complicated) the WFC application server can get overloaded. 
 
Another potential down side to the 5.2 implementation is that the CT and the WFC application server now share the same JBoss JVM memory space. Prior to 5.2, the JVM didn't contain any of the CT, BGP, or totalizer stuff--those things were in separate, executing Smalltalk images. 
 
The difference between 5.1 and 5.2 for the background processor (BGP) deserves perhaps a separate comment or BLOG article.
Posted @ Friday, March 06, 2009 9:57 PM by David Goldhirsch
David, 
 
Thanks for the clarification. I must admit I'm beginning to wonder about the ability of JBoss to handle so much. It certainly can more easily get 'stressed' in 5.2. What about in 6.1 when the DCM is also in there? I think we might want to partner on a 6.1 article which talks about how one decides it's time to add another appserver and how they might get setup.
Posted @ Saturday, March 07, 2009 9:05 AM by Bryan deSilva
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics