Testimony playback sequencing

In order to be able to perform a playback in less time than it took to record the data, Testimony doesn’t necessarily play back in the strict sequence of recorded events, except in certain specific cases:

• Batch jobs are always played back in strict sequence, so if Testimony recorded Job A, followed by Job B, followed by Job C, then the playback will play these jobs back in the order A, B, C.
• Transactions within a user session are always played back in strict sequence. If a user logged on and then executed transactions VA01, VA02 and VA01 again in that order, then Testimony will play back that user’s session in the order VA01, VA02, VA01.
• “Dynamic ID” dependencies are always maintained. Testimony has functionality which can generate “Dynamic IDs” between transactions, batch jobs, RFCs, etc., and these are always enforced. For example, if UserA creates order 1234, and then UserB changes order 1234, and then UserC displays order 1234, then Testimony will ensure that these transactions are played back in the correct order.
  • A further piece of functionality related to Dynamic IDs handles what happens when, for example, the order creation fails. So in our example above if the creation of order 1234 fails, then Testimony can use the Dynamic ID for this order, and its link to other transactions, to recognise that there is no point in trying to either change or display this order as it doesn’t exist in the playback system. Testimony will therefore cancel the dependent change and display transactions.
  • Dynamic ID also handles the possibility of differences in document numbers between the recording and the playback. For example, let’s say that document 1234 was created during the recording and then it was changed later on. Now, when we come to play back this transaction, we may find that the document created in the playback system actually has the number 1233. (This might be because a previous document creation failed, meaning that the document number range has not been incremented.) Testimony knows that the change document transaction for the original document 1234 is dependent on this create document transaction. Since we now have a different document number (1233) Testimony will change the “change document” script to use this document number rather than the original.

This enables Testimony to “compress” the time taken to perform the playback to sometimes much less that the recording time. For example, if two batch jobs are executed 30 minutes apart, then Testimony is likely to start one as soon as the previous one has finished. Likewise, if a user executes VA01 and then, 10 minutes later, executes VA02, then Testimony is likely to start VA02 as soon as VA01 has finished.

An example of where Testimony might not play back in strict sequence might be where a batch job changes the status of a record, which is later acted upon by a dialog transaction. For example, TransactionA creates a new order; BatchJobB processes this order and updates its status (to, for example, “ready for shipping”); and TransactionC performs the shipping of this order.

In this case, we have a mixture of dependent and independent processes happening: TransactionC is dependent on TransactionA (because of the Dynamic ID link for the order), but BatchJobB is independent of either. It is therefore possible in this example that instead of the recording sequence:
TransactionA —> BatchJobB —> TransactionC
We instead play back in the following sequence:
TransactionA —> TransactionC —> BatchJobB
Or:
BatchJobB —> TransactionA —> TransactionC

In the first example of an “incorrect” sequence, we would expect TransactionC to fail, as the order created by TransactionA is not in the correct status for shipping (as BatchJobB has not yet run). In the second example, we might expect TransactionC to fail for the same reason as before, but we may also see that BatchJobB fails because it doesn’t have a record to process (as TransactionA has not yet created the order), leading to a different output for the job.