Missing Parameterization Example

This page shows an example procedure to troubleshoot a script defect.

Starting Point: Error during Replay

The beginning of this troubleshooting sequence is that you observe an error message during a script replay. One common error message related to missing parameterization is Too few occasions of Search, could not define variables .... If you observe multiple errors, focus on the first message that fails, since other errors may be consequences of the first problem.

In the screenshot we see that message 166 fails with the error message Too few occasions of Search ....

Diagnosis: What is Different from Recording?

The general question when troubleshooting replays is: What is different between recording and replay? One evident approach to answer this question is to use the compare functionality built into the EEM Editor. There are several options to launch a comparison in the EEM editor, e.g. compare a complete script replay with the recording, compare different replays, compare completely different scripts. In our case, we want to start by just looking at message 166. For this purpose, just right-click on message 166 in the editor and select Compare Recording with Replay. Before the comparison is displayed you are prompted to choose whether you want to hide expected differences. For the first attempt, click Yes. A new tab with title Compare and some comparison details opens in the main editor area. Click the individual message details (request header, response header, request body, response body) to get the comparison.

The screenshot shows the comparison of the response bodies for recording and replay of message 166. There is evidently a difference in the responses. From the URL of the message we can guess that the message refers to session termination (DSM). In the replay no session was terminated (0 request), as opposed to the recording (1 request).

Taking a deeper look at the response bodies we can also see that the recorded response bodies contained assignments for AckTstamp and sap-ext-sid. These are not contained in the replay response body. This difference is evidently the reason for the error message Too few occasions of Search...: Searching the response body for a variable delimited by AckTstamp (on the left side) was not successful during replay.

Find the Reason for the Difference

Now that we know that there is a difference we have to find out

1. What is the reason for the difference?
2. Is this difference expected, maybe normal application behavior?
3. Does the difference mean that our script has a defect, or can it be ignored?

Again, there are multiple reasons for a differnce between recording and replay, e.g.,

1. Application has changed between recording and replay time
2. Script contains some IDs from recording that must be replaced by new IDs generated during replay (missing parameterization)

If there is not too much elapsed time between recording and replay then missing parameterization is probably the reason. A missing parameter can be discovered

• by comparing request bodies and request headers of the affected message (and the messages before)
• by only looking at the request headers / bodies and searching for strings that "look like unique / automatically generated IDs"

Let's compare the request bodies of message 166:

The above screenshot shows that there is evidently a difference in the request bodies, but looking at the message definition in detail, there is also already a variable introduced for this difference, such that it should be handled correctly:

But a second look at message parameters and comparison also shows that there is still something like a unique id left, something like 1301640880157.

Let us search the script for this ID. it must be defined by some preceding response. The context where this id shows up in a response may reveal whether we are on the right track. Search the complete replay for this ID via the search / add text check function. The screenshot shows the result:

So response 133 contains this ID as well. To see more context of this ID, we review the complete response for message 133:

So the id 1301640880157 is directly related to DSM. It might be something like a Java timestamp (System.currentTimeMillis()).

Parameterization 1: Search a Message Response and Save the Result to a Variable

Let us extract this id into a variable by adding a search to message 133:

Parameterization 2: Replace Constant by Variable in Request Data

And change the request parameter of message 166 to use the new variable instead of the constant 1301640880157.

Result

Finally, save the script and start another replay. In this case, this change fixed the script and the replay was successful.

Let's compare the new replay result for message 166 with the recording:

The response body now almost contains the same text for recording and replay:

The request body indeed contains a different value instead of the constant 1301640880157.

Additional hints

• The file variables.xml in the replay folder contains a list of all variables that were active during a replay. Use Open Windows Explorer from the execution history to open the folder in the Windows Explorer. For each variable, the value, definition, and all uses are documented.
• The file variables.xml in the script directory (or in the recording.meta folder, depending on the EEM release, contains all variables identified during automatic parameterization.
• Once the mechanism of a unique id is understood the manual parameterization can be automated by adding a new rule to AutoParams.xml: See Parameterization.