Undocumented LoadRunner Series: Using Micexec to record from multiple sources

[textile]

That LoadRunner's recording engine hooks into browsers is a fact known to all those who've worked with the tool. What's not known is that the recording engine can also hook into non-browser applications at the same time it is hooked into a browser. As a result, the generated LR script will contain calls made by one browser and one external application.

Why is this of interest ?

Perhaps you have some VB/JScript code running in your browser that invokes a local DCOM server. This DCOM server in turn, makes some HTTP calls and you'd like that to be part of the generated script as well. But how do you trap that HTTP traffic in addition to what you're already doing?

I agree, this is a bit contrived as a situation and you probably will not encounter anything as complex as this. But it's an interesting peek into what LR is capable of.

Again, I must warn you before proceeding. This is all undocumented information and cannot be guaranteed to work in another version of the product. As of now, I'm using LR 8.0 and the recording hook MICEXEC.EXE has been shipping with versions 7.6 onwards. Since I have no access to versions before that, I don't quite know if it has been an integral part of the product since inception or not.

But first, a gentle introduction to the recording process:

1. The user selects a web script, presumably HTTP/S URL-mode recording.
2. The user sets the recording options to recording from the default browser, most likely IE.
3. Clicks Record.
4. In the background, our recording engine hooks into the browser and changes the settings.
5. The Settings are now changed to hit a proxy, which is the LR engine.
6. Going to the browser settings/Connections/Proxy server, reveals the proxy as running on localhost on port 7777.
7. Going to the cmdline and typing netstat -a reveals this on my computer:

_Active Connections_

|*Proto*|*Local Address*|*Foreign Address*|*State*|
(dark). |TCP|PUN03473:epmap|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:microsoft-ds|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:1025|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:1051|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:2701|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:2702|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:3135|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:3824|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:3842|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:3863|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:5000|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:5101|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:7777|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:7970|PUN03473.gheuntak.org:0|LISTENING|
(dark). |TCP|PUN03473:8081|PUN03473.gheuntak.org:0|LISTENING|


Quite obviously, port 7777 is being used by our proxy ie. LoadRunner's recording engine.

But that is only HTTP traffic going through the browser. Other HTTP calls emanating from other applications on the machine are not going to be trapped by the recording engine.

So now, what happens when we have a DCOM server (hypothetically) invoked by our browser. It will not initialise as a child process of the browser and being a DCOM server, there is no guarantee that it may even be running in the same user context as our browser. So is there no way to make the recording engine hook into it to get that HTTP traffic into our script?

Cut to our hero, MICEXEC.EXE, who leads a low profile life in the LoadRunner bin directory. He will come to the rescue, much like Govinda springing to the aid of Karishma in Raja Babu - (For the uninitiated - Raja Babu is an extremely forgettable Hindi movie)!

For purposes of demonstration, I selected DAP.EXE (Download Accelerator from SpeedBit.com) as the external application running in its own process context. We will pretend it is a DCOM server. DAP served the purpose since it is an adware-supported application to leech files from file servers. To serve ad banners, it connects to a server (ad4.speedbit.com) using HTTP requests which is exactly what we need.

Now for the real *masala* - how to invoke and record it.

1. Create a dual protocol Web/Winsock script. For some reason, even though all calls made were HTTP, this only works when there is a Web/Winsock combo. Don't ask - it's undocumented as it is and you are looking the proverbial gift horse in the mouth.

2. Start the recording process and start recording browser calls. I navigated to the Google page.

3. Go to the command line and execute

*__MICEXEC DAP.EXE__*

I'm assuming that both \LoadRunner\bin and the directory where DAP is installed is in your PATH environment variable. If not, do it.

4. Let DAP do it's thing and finally conclude the recording.

The script takes slightly longer to generate. At the end, however, you will have something that looks like the code below.


*Action*()
{

*web_add_cookie*("PREF=ID=f33adc036c518213:TB=2:LD=en:TM=1106211825:LM=1107169289:S=sbYlWCfjgZj65n-O; DOMAIN=www.google.co.in");

*web_url*("www.google.com",
"URL=http://www.google.com/",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t1.inf",
"Mode=HTML",
EXTRARES,
"Url=http://ads5.speedbit.com/cgi-bin/ads9.dll?R=0&DAUI=162796324&V=7.1.0.1&NR=0&SI=0&XML=1&NOB=1", "Referer=", ENDITEM,
LAST);

*web_url*("ads9.dll",
"URL=http://ad4.speedbit.com/cgi-bin/ads9.dll?HTML=1&DAUI=N&INC=0&DL=MAIN&CX=1042&CY=94&IIA=&IIG=&IIP=&III=&V=7.1.0.1",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t2.inf",
"Mode=HTML",
EXTRARES,
"Url=http://images.speedbit.com/728X90_Mac.swf", "Referer=", ENDITEM,
"Url=http://ads5.speedbit.com/cgi-bin/ads9.dll?R=0&DAUI=162796324&V=7.1.0.1&NR=1&SI=0&XML=1&ET=1&OT=12&KA=1&NOB=1", "Referer=", ENDITEM,
LAST);

return 0;
}


The first web_url() is what the IE browser made. The second web_url() is the one that DAP made! Both in the same script too.

Aha moment there, eh, mon ami?! :D
[/textile]