Bot work-load distribution

With previous versions of Testimony, the work-load distributed to the bot farm was often skewed dependent upon the content of the recording itself.

So for example, if there were 10 bots and every 10th transaction was a SAP GUI dialog transaction (whilst the other 9 transactions were something else such as RFC’s or batch jobs), then the playback algorithm would overload a particular bot.

As is described in the “Bot stability” section of this document, overloading bots with SAP GUI sessions can cause the bot to become unstable. This means that too much work would be given to a particular bot and it is then going to become unstable during the playback – requiring restarting and thus losing the transactions that are currently in-flight upon that bot. Further work would also then need to be distributed to less bots and the cycle repeats.

Testimony v2.20 introduces a new workload distribution algorithm that much more evenly distributes the SAP GUI work across the bots that are participating within the playback. This leads to significantly more stable bots and thus significantly more stable and error free playbacks.

*Note: You can see the more even distribution of the SAP GUI workload across the bot farm by using the new “Bot monitoring” functionality in v2.20. This is visible in the “SAP GUI Windows” column of the bot monitoring UI.

!Important: When a playback first starts, the SAP GUI work-load distribution may be skewed to a particular 1 or 2 bots. Do no panic when you see this because it is working as designed. By giving it more time you’ll see it evenly distribute itself out over time.