Status: Cancelled

Sometimes during a playback, Testimony will decide that a script cannot or should not be executed. These are shown with a Status of Cancelled and a Result of No result.

There are various reasons why Testimony might decide to cancel a script. These are discussed below.

Predecessor script failed (LEAVE TO TRANSACTION)

This cancellation reason arises in certain cases where “chained transactions” are executed by a user. In many cases in SAP, the end of processing of a transaction (e.g., hitting the back button or pressing save) will take the user back to the initial screen for the transaction. This is implemented in ABAP via a LEAVE TO TRANSACTION command. When Testimony builds the execution queue for these chained transactions, only the first call of the transaction has a “Start Transaction” step. The remaining transactions in the chain, although treated as separate scripts by Testimony, do not have a separate Start Transaction step, as the context from the previous transaction gives Testimony all of the information it needs to execute the transaction again.

In the example above, we can see that a user has executed transaction LT03, but only the first script has a Start Transaction step (shown by the “Play” icon on the first step). In this case, the user started the transaction (first step); entered some data (second step); and then clicked on save (third step). Because of the LEAVE TO TRANSACTION command in the SAP code for this transaction, the user was then taken back to the initial screen of LT03. This spawned a new Testimony script, but without a Start Transaction step.

One effect of this method of handling chained transactions in Testimony is that if one of the scripts in the transaction fails or errors, then the remaining scripts in the chain must be cancelled, because these remaining scripts do not have a Start Transaction step.

This can be seen in the example below.

Here we can see that the first step of the first LT03 script had an error as a result of a connectivity. As usual, the remaining steps of this script were cancelled, but in addition the second script in the chain was also cancelled for the reasons given above.

Producer step failed (dynamic ID)

Testimony’s dynamic ID process ensures that where the execution of one transaction is dependent on the results of another transaction, that the two transactions are linked together. This might be because, for example, one script creates a document, and a subsequent script changes that document. The dynamic ID process ensures that:

1. The linked scripts are executed in the correct sequence, so that the document creation is always executed before the document change
2. If the document number that is generated when the document is created in the playback is different to the number that was generated in the recording, the subsequent change document transaction will use the new number rather than the old number (so that the correct document is being changed)
3. If the document creation script fails in the playback, then the subsequent change document script is cancelled, to avoid unnecessarily trying to change a document which Testimony knows doesn’t exist
   

In the 3rd case above, the change document transaction would be given a Status of Cancelled with a Sub-status of “Producer step failed (dynamic ID)” and a Result of No result.

In the example above, a VL02N transaction has been cancelled with the “Producer step failed (dynamic ID” sub-status.

We can check to see which producer step caused this by going into the investigate screen for the cancelled script.

The Script Linkages section at the bottom left of the screen shows any objects or scripts that have been linked to this script. Here we can see that there is a “Dynamic ID – Consumer” linkage, which shows that this script is the consumer of another script. If we click on this item in the linkages list, we can see details of (reading from top to bottom):

• The current script / step (“Consumer step – Step/Script details”)
• The producer, i.e., the script / step on which this step is dependent (“Producer Steps/Scripts”)
• Any other scripts that are dependent on this producer (“Other Consumers of Producers”)
  

So, in the example above, we can see that our VL02N script was cancelled because it was dependent on a previous VL01N transaction which had a Status of Error. Because this producer script failed, the VL02N transaction, as well as an LT03 and a VF01 transaction, were all cancelled.