Overview
When you start a playback, Testimony will submit a number of background processes on the central system. It is important that enough background work processes are available on the central system to accommodate the Testimony requirements, as well as leaving enough background work processes available for normal operation. (This is especially true if your central system is also a productive Solution Manager system.) The normal requirement is one background job for each bot plus an extra background job to manage the playback. The details on how this operates and is managed by Testimony is as below.
Detailed Information
When a playback is first executed an orchestrator job will start. The orchestrator job manages the whole playback process, and one of its functions is, firstly, to split the playback into blocks. Once the playback blocks have been built, the orchestrator will then start a number of worker jobs. The number of worker jobs that will be started is governed by the Testimony general parameter PLAYBACK_MAX_BLOCKS. The number of worker jobs (and hence the value of the parameter PLAYBACK_MAX_BLOCKS) should be set to the number of bots that you are using.
Once these jobs have been started, the orchestrator will allocate blocks for processing to the worker jobs. Each worker job will then work through the scripts in its block, allocating them to bots for playback. Both the orchestrator job and the worker jobs will remain active for the whole of the playback.
This means, therefore, that the total number of jobs required on the central system by Testimony for a playback is 1 + PLAYBACK_MAX_BLOCKS.
The jobs can be seen in SM37 as below.
The orchestrator job is called /BTI/AUT_EXEC_QUEUE_PLAY, and the worker jobs are given a dynamically-generated name.
Post your comment on this topic.