Example 5: Double-clicking on a list item calls up a different document

This defect has been raised because a different screen was shown in the playback than was seen in the recording.

Looking at the Investigate Screen, we can see that instead of going to a “Decision step in workflow” screen, we went to a “Process PO Invoices” screen.

The screen that we saw in the playback looked like this.

If we look at the Input Parameters for this step, we can see that the user double-clicked on a field on the previous screen (as shown in the “Control event/action” parameter).

And looking at the screen shot from the previous screen, we can see that the user was working with a list of items from their Business Workplace inbox.

In order to figure out exactly what’s happened here, we’ll need to drill into the information in the Investigate Screen in a bit more detail (and gain a better understanding of Control processing). It is also helpful to be able to recreate this issue in the playback system.

The first thing we should try to do is work out which item in the list the user double-clicked on. We can do this by looking at the Control Properties on the Input Parameters for the failed step.

Here we can see the following information.
• Row 1 shows us that the user double-clicked on a cell in column 2 of the list
• Row 2 shows us that the user double-clicked on a cell in row 3 of the list
• Row 3 shows us that the cell the user double-clicked on had the text “Approval needed: PR No. 10043952 …”
We now need to compare this with the list we saw displayed in screen shot from the previous step:

The highlighted entry is the cell at column 2, row 3, and as you can see this has the text “Process document 000000279968”. It looks, therefore, as though the list from which we were working in the playback was different to the list the user was working from in the recording.

If we now look at the screen shot of the step that failed, we can see that we are actually working on document 279968.

We can therefore conclude that the playback bot was doing what it was being asked to do: double-click on the cell in column 2, row 3 in the list. It’s just that the entry in the list was not the one that we were expecting.

It’s now worthwhile doing some investigation in the playback system to try to pinpoint what went on. Looking again at the list displayed in the user’s SBWP inbox, we can see that all of the “Process document” messages were generated on the same date. Drilling down into the workflow logs for these entries on the playback system, we can see that they were all created (i.e., added to the user’s inbox) in a batch, with only a second or two between each entry. This suggests that a batch job has performed some processing to add these documents to the user’s inbox. Further investigation revealed that a workflow deadline monitoring job ran at the time these entries were added to the user’s inbox.

We therefore have a classic example of a data issue being caused by the way that Testimony sequences batch jobs and online transactions. This resulted in a list from which we were working not being the same in the playback as it was in the recording.