| || |
Re: Recorder bug? Global vs. local Tcpip handles hWeb0,hWeb1,...
The way that the TCP API works is rather basic as it does not maintain any state between post (unlike the WEB API). This means that everytime you want to POST or GET you will have to initiate a open connection with the server.
Therefore any variables or values will need to be stored gloabaly.
Performer does this to mimic TCP as close to real life as possible....
If you are using a browser then I would not use the TCP API as its a bit harder work with than the web API (this managages your connections far better)
Hope this helps
Select Red Ltd
Recorder bug? Global vs. local Tcpip handles hWeb0,hWeb1,...
I am running SilkPerformer 4.5 on Windows NT. When I record a script for a Web application, it uses WebTcpip calls (Connect, Send, Shutdown, etc.) to record the activity. I also frequently define new transactions while recording.
When I play back such a script, it often gets errors. Looking at the error file, I found that many of them occurred when one transaction tried to do a WebTcpipSend using a handle that had been opened by a previous transaction. (I run transactions sequentially; i.e., "Choose transactions randomly" is unchecked in the Settings.).
Then, I noticed that each transaction had its own local definitions of the Web handle variables (hWeb0, hWeb1, etc.) When I replaced these with a single global definition of each one, the errors went away. Alternatively, for a single instance, I could define a new, global variable (gWeb0) and insert "gWeb0:=hWeb0" at the end of one transaction, and "hWeb0:=gWeb0" at the start of the next to pass the local value on.
Could there be a bug in the way the Recorder is generating these variable definitions?