A number of new parameters have been added in this release of Testimony:
| Parameter Name | Area | Description |
|---|---|---|
| BOT_MEM_THRESHOLD | Bot agent | During the playback, the bot will consume memory as it executes various transactions. Other measures have been put in place in v2.21 in order to stabilise the bot during playback, but this parameter controls at what point the bot should clean up all unused windows and if still below this threshold, force the execution queue into a “paused” state. For the operator, this is an opportunity to add more bots into the playback if deemed necessary. This value should not exceed 1Gb (1000) and should not be below 500Mb (500) |
| DRONE_REFRESH_TIME | Bot agent | During the playback, various monitoring information is obtained from the bots to support the most optimal performance. On a regular basis, the bots are polled to gather information such as memory consumption and number of SAP GUI windows they have open. This parameter controls how regularly this is done and must be traded off with network latency when making a call to the bot to retrieve this information. |
| INV_SCR_VER | Playback | A new version of the investigate screen is now available within v2.21. It is activated by default. This parameter allows you to revert back to the previous version of the investigate screen if required. |
| BATCH_EVALUATION | Playback | During the playback of batch jobs in testimony, the job logs from the recording are compared to the job logs from the playback. This is a very strict comparison and the same messages must be output in the same sequence and if not, a failure is output. However, often batch jobs work upon different datasets in the playback than in the recording. This can lead to failures that are false negatives. This parameter controls options on performing this comparison in a more intelligent manner. |
| BATCH_USER_TYPE | Playback | When batch jobs are submitted during the playback, issues have arisen in the past where the original batch job schedluer no longer exists in the system. The job can run under a different user, which is why this is not seen as an issue in the production system. This parameter controls how Testimony handles this scenario. |
| ROOT_CAUSE | Playback | This parameter controls whether the new “Root Cause Analysis” functionality is active or not. The default for this parameter is deactivated, hence if you would like to use the new root cause analysis functionality you must first activate this parameter (after appropriate pre-requisites are met). |
| SCREEN_RES_HEIGHT | Playback | When setting up the bots for use in the playback, the screen resolutions must be sufficient to support the users in the recording. Lower resolutions mean that the correct resizing of the screen may not be possible by the bot and thus the screens may behave differently during the playback. The minimum recommended screen resolution height is 1080. This parameter can be increased if deemed necessary. It is used in the playback check step of the bot cofiguration and outputs a warning if any bots have a resolution height less than this parameter. |
| SCREEN_RES_WIDTH | Playback | This parameter works in conjunction with the previously described parameter SCREEN_RES_HEIGHT. |
| CLOSE_SES_THRESHOLD | Playback | This parameter is one of the most critical delivered in v2.21 of Testimony. In order to keep the bots participating in the playback stable, they must ensure their RAM usage is kept as low as possible for the duration of the playback. They achieve this in v2.21 by closing down windows as often as possible. The trade-off is that users need to be logged back on and this has a slight performance impact. To keep this impact as minimal as possible, this parameter is the “number of steps” that are analyzed ahead in the playback to see if the same user has another script coming up. If they do, then the bot is instructed to keep the window open rather than logging off the user and then having to log them back on. If your number of bots are at a minimum, then you should keep this parameter as low as possible and ideally set to 0. Thus, all transactions will require a login, an execution of a script/transaction and then a logoff, thus keeping memory consumption on the bots to a minimum. |
| PLAYBACK_CHK_IDOC_SG | Playback | An early version of both inbound and outbound IDoc capture and replay is introduced in v2.21. Testimony can be activated to capture all IDoc’s created during the recording and then during the playback, compare that the same IDoc’s are also generated. Certain fields upon the IDoc control records are compared but the data segment comparison can be controlled via this parameter. Since IDoc segments may contain data that differs during the playback (e.g. time fields, GUID’s or unique identifiers. Turn this off to not perform the data comparison or use the new configuration table in IDoc data comparisons to exclude the fields which will typically always be different between recording and playback. |
| PLAYBACK_CHK_SSF_OTF | Playback | An early version of SAP Script form capture and replay is introduced in v2.21. Testimony can be activated to capture all SAP Script Forms that are generated during the recording and then during the playback, compare that the same forms are also generated. The form headers are compared during the playback, however, it is also possible to compare the underlying OTF data that is generated in the form. This data is unstructured (mostly) and therefore may contain fields that will almost always be different in the playback compared to the recording (e.g. times, unique identifiers). Hence, this parameter can be used to deactivate this OTF data comparison if desired. Note that you can now also configure the “windows” for exclusion in the OTF data comparison to ensure unique fields are not compared in the playback. |
| PLAYBACK_GET_SPOOL | Playback | Version 2.21 of Testimony now allows you to capture the spool request output during both the recording and the playback phases of Testimony. This parameter controls whether this data is retrieved or not during both the recording and playback phases. |
| SPOOL_RETENTION_PER | Archiving | Version 2.21 now retrieves the spool output from batch jobs that are captured in both the recording and the playback. This parameter controls how long those spool outputs are retained for as the spool data is copied from the source and target systems into the central system. The default value is ‘9’ which means to retain them indefinitely. A value from 1-8 is also possible which specifies that the spools should only be kept for that many days. |
| SPOOL_OUTPUT_DEVICE | Archiving | This parameter controls which spool output device should be specified when the spool is copied from the source (or target) system into the central system. This is required because the output devices configured on the central system may differ from those on the source or target. If blank is specified here, then the original value from the remote system will be used when creating the spool in the central system. This will fail if the output device does not exist. |
Post your comment on this topic.