There are situations where recording application using protocol Web (HTTP/HTML) encounters problem such as (1) not recording events, (2) not launching or (3) crashing. The context may deviate however the below list aims to provide a quick-and-dirty resolution to the problems. Obviously, the quick-and-dirty may work/not work in different environment and situations, however it will help you scope down the problem in a sequential and logical manner.
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)
Ok, let’s move to the details on the rationals and steps
Our Requirement is to get your HTTP application record!
[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.
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)
Ok, let’s move to the details on the rationals and steps
Our Requirement is to get your HTTP application record!
[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.