So what’s the difference between the two in LoadRunner context? And what does it mean by setting the recording level in Port Mapping of the Recording Options and replay for RTS (Runtime Settings)?

By configuring Vugen record at WinINet level, simply means to instruct Vugen to record using the WinINet API. Vice versa, by configuring the Socket level, you are instructing Vugen to record using the proprietary API. By default, it is Socket level.

When the recording level is configured to record at WinINet API, LoadRunner records traffic that is generated by the application which uses the WinINet API to communicate to the servers; meaning it attempts to capture traffice at the WinINet level. For Socket, LoadRunner, attempts to capture the traffic on the socket-level at a specified port, bypassing any WinINet API (if there is any).

For replay, the principle applies where WinINet will be replaying using WinINet API else it will be replaying via the default Socket level API; meaning defining the WinINet replay, instructs Vugen to replay the script passing through the WinINet API while the default Socket replay will be bypasing the WinINet API. There is a small description of Document ID 10735 – What is “WinINet instead of Sockets” for at the support website that reiterates the above but worth taking a look. A valid account will be required to login to access the article.

So, when do you configure WinINet or Socket-level? Sometimes web applications maybe designed in WinINet while at times it does not require WinINet as often and Socket level will be sufficient. How do we know which option to choose then? This will be a little tricky here but it will most probably end up in a series of trial-and-error. When an application fail in recording and replaying you can try by switching between the two modes which was also documented as part of the recording solution in “Quick-and-Dirty Recording Techniques for Web (HTTP/HTML)”.

Lastly, a point to note that Internet Explorer browser’s API may change over time due to version upgrades (e.g. IE 6 to IE 7) which may inherently cause the replay to be successful or fail. As mentioned, try switching the modes (after getting the necessary patches for IE7 if applicable) when you encountered problems in recording or replaying.

Hope all the above are sufficient for you to understand the WinINet and Socket-level recording and replaying in LoadRunner context.

1. Use another machine to record
2. Use web_custom_request
3. Configure Port Mappings using “WinInetlevel data” or “Socket level and WinInet level data”. And if necessary, define the port and certs.
4. Use Older Recording Engine
5. Use LoadRunner as Proxy Server on port 7777 for Recording (For Older Recording Engine)
6. Determine OS Support Status and application type
7. Determine the actual protocol and port number using Winsock protocol or network sniffing tools (WireShark Network Analyzer)

I’m leaving out the details at this juncture so that you can have an overview steps of what to do when Vugen is not recording any HTTP events emitting from your HTTP application. I will detailed the steps and reason in the subsequent post; so stay tuned!

Ok, let’s move to the details on the rationals and steps required to get your HTTP application recorded!

[1] Use another machine to record

Install VuGen on another machine and proceed with recording. What we are doing here, is to differ a problematic machine to a working one (at a machine-level troubleshooting). The existing machine may have problems due to a clone image, restricted privileges or previous installation of programs (unless you are pretty sure that your machine is fully workable with Vugen).

[2] Use web_custom_request

Use the basic web request methods for communicating to the server. This is needed when Vugen (sometimes) is unable to recognise the HTTP traffic and compose into web_submit_data APIs. Therefore, by instructing VuGen to record using web_custom_request only, this will detect all unknown communications been used in a HTTP mode to be recorded but in a more unreadable or unfriendly web_custom_request script.

1.1 Create a new Multi-Protocol Web (HTTP/HTML) script; do not create a Single Protocol script.

1.2 In the recording options, select recording to be URL-based script (not HTML mode) and select “Use web_custom_request only”. Proceed with the recording.

[3] Configure Port Mapping

Some applications may use ports that are different from the browser. The default HTTP port is 80 by most application but this may not be used by the application that you are recording against. In such situation, you may need to configure Vugento capture the HTTP traffic by mapping the ports to the service type. The service type other than HTTP are FTP, Socket, etc depending on your application needs. In this way, Vugen will become a proxy and capture traffic on the defined port.

1.1 In Recording Options ensure that you are already using web_custom_request only as stated in the previously.

1.2 Go to Port Mappings, remove all registered Entry and add New Entry with the known information (such as port number and target server). Note that there should not be any duplicate port numbers.

1.3 If 1.2 didn’t resolve the problem, try using “WinInet Level data” for the Capture Level and record the application.

1.4 If 1.3 didn’t resolve the problem, try using “Socket level and WinInet level data” for the Capture Level and record the application.

1.5 If the above didn’t resolve the problem, edit the port mapping entry; change the “Record Type” to “Direct” and to “Proxy” if you using SSL. If you know the ciphers used and type, you can configure it here.

1.6 For SSL, either client-side or server-side, refer to “Configuring the Port Mappings” of the Vugen User Guide for the detailed information. You will have to provide the certificates in either Base64 or PEM format. PEM format can be converted with a tool called openssl.exe availablie with the installer as well as online search.

[4] Use Older Recording Engine

This is to utilize the old recording engine prior version 8.1. The old version records at the proxy level whereas the new engine records on the process level.

[5] Use LoadRunner as Proxy Server for Recording (For Older Recording Engine)

If [4], didn’t work out right, you have to specifically configure LoadRunner as a proxy to record all communication via port 7777. Take note that this is in the old recording engine.

1.1 In Recording Options, under Browser, set the application to launch manually with “Manually launch an application”

1.2 Under Recording Proxy, select “No Proxy”.

1.3 On a separate machine (e.g. Machine A), set the Proxy to the LoadRunner machine with port 7777. (NOTE: Proxy server can be configured on the LR machine itself).

1.4 Start recording on LoadRunner machine.

1.5 Invoke the application on Machine A.

1.6 You should be seeing events counted on the LoadRunner machine. It means the target application accesses the LR machine and LR is recording it.

[6] Determine OS Support Status and application type

At this point, you have tried almost everything (and have come to theend of the road/solutions). My recommendation is to check out with Mercury/HP support, on the support level of the target application. Also check them out if they had encountered such problems before.

[7] Use Winsock protocol or network sniffing tools

Using WinSock protocol, you can determine the actual communication method by the client to the server. With this evidence, you can bring forward a discussion with your client on the unknown communication method. Another good tool to use is the WireShark Network Analyzer (formerly known as Ethereal Network Analyzer) to identify the communication and port being used.

By default, when you are about to select the protocols from Multi-Protocol selection, you won’t be able to combine both of them together as illustrated below. (Click on image to enlarge).

However, there are means to do that! Basically, what you need to do is to enable the protocol to be displayed in the “New Multiple Protocol Script” list when creating a “New Virtual User”. Let’s go through the technical overview:

1. Go to {installation}\dat\protocols. By default, it’s C:\Program Files\LoadRunner\dat\protocols
2. Open the desired protocol file that has the.lrp file extension. (E.g. mms.lrp)
3. Amend parameter, Multi in the .lrp file from 0 to 1. E.g. Multi=0 to Multi=1
4. Open Vugen for a new vuser script and you should be able to see the enabled protocol in the list “New Multiple Protocol Script”.

You should be able to see the enabled protocol similar to the following screenshot. (Click on image to enlarge).

Click on the link if you need a sample of the files; You need to rename the file to mms.lrp and place it in {installation}\dat\protocols if you want to use it

• Original mms.lrp file
• Amended mms.lrp file
  

Note:

Having provided the above, you will still need a basic understanding on how the combined script will be executed. Both protocol will execute as it is of it’s own where (1) Web (HTTP/HTML) will still allow the HTTP sends and receives when the Web (HTTP/HTML) APIs are executed and (2) Media Player (MMS) will make a direct connection to the Media Server (or publishing point) that will stream the video down when executing the Media Player (MMS) APIs. HTTP communication will stop from there till the streaming completes. You can refer to a previous article, “Introducing Media Player (MMS) protocol in LoadRunner!“.

I’ve only tried with Web (HTTP/HTML) and Media Player (MMS). I’ve yet to try other combination of protocols. If you do have given a try before, it will be great to hear from too! As for the licensing, I’m not too sure if this is a breach in the license. Will be great to hear from the experts or vendor on this!