Now, if you are proficient in LoadRunner, you may miss out on the details of how to go creating the start-stop transaction for the GUI Vuser script as the details are actually found in the QTP User Manual under the section, “Measuring Transaction” of HP Quick Test Professional User Guide – Volume 2 instead of LoadRunner manual.  In anyway, this is possible and only achievable via amending the scripts in QTP because Vugen will not be able open (read) QTP scripts.

Two ways you can insert a transaction.

• Via Keyword View – You can use Start Transaction icon > Insert Transaction at the step that you want the transaction to start measuring.   Subsequently, you will use Stop Transaction icon to stop the measurement.
• Via Expert View – You can use Services.StartTransaction “Transaction Name” and Services.EndTransaction “Transaction Name” to encapsulate where the start and end measurement.  “Transaction Name” is the name you give to defined for the transaction and this will appear when you run the GUI Vuser script in LoadRunner.

With the above information, you should be slightly more familiar with Quick Test Professional (QTP) integrating with LoadRunner.  However, again there may be more things that need to be considered and I may have left out.  Do feel free to feedback and experiences and anything that I missed out when using QTP in load testing!

• QTP scripts are developed in QTP not in LoadRunner Vugen – You won’t be able to record and replay a QTP script in Vugen.  All the recording and modification has to be done on QTP.  Once the modification of the QTP script is completed, it will be ported into LoadRunner Controller as GUI Vuser for load testing.
• QTP is required to install in the Load Generators (LG) – The load generators will be required to install QTP as they are used to run the scripts.
• Load Generators will be required to set the same resolution to the machine that developed the QTP script – As QTP is object sensitive, the resolution of the LG is required to be the same with the machine that was initially used to develop the QTP script to avoid any problems arising from missing objects (due to a different resolution)
• [1] GUI Vuser license is required for LoadRunner and QTP concurrent license is required for QTP – This is the 1^st setup approach and budgeting for your licenses.  The total amount of Vuser that you wanted to generate will be the same for both LoadRunner and QTP.  Meaning, if you want to run 50 concurrent users using GUI Vuser protocol, you will need 50 GUI Vuser license and 50 QTP Concurrent license.  In this setup, the LG will create 50 instances of QTP to run the GUI Vuser.  This is described in “What licenses are required to run a scenario with GUI Vusers” from HP Software Support.
• [2] GUI Vuser license is required for LoadRunner, QTP seat/concurrent license is required for QTP and Windows Terminal License is required for Windows – This is the 2^nd setup approach and budgeting for your licenses.   For a 50 concurrent user load test, you will need 50 GUI Vuser protocol, 50 Windows Terminal License and 1 QTP license.  In this setup, the QTP license is merely used to develop the script.  The LG will create 50 remote desktop connections and each of these connections will run 1 GUI Vuser.  This setup utilizes remote desktop functionality to emulate the virtual users.  I believed that HP Support does not really state about the licenses required from Windows Terminal and this is additional cost for you to factor if you are going though this mode.  Personally, I experimented using Windows Server 2003 (that is capable of 3 remote connections by default) with this approach and it works for me.  On the server, the remote connections are established and the QTP script launches the browser for testing.  (I wonder if this is permissible in the first place and like to know if anyone else is doing it.  If you got some input on this, please feel free to shout it here!)

With the above information, you should be slightly more familiar with Quick Test Professional (QTP) integrating with LoadRunner.  However, there may be more things that need to be considered and I may have left out.  Do feel free to feedback and experiences and anything that I missed out when using QTP in load testing!

Performance testing recording and execution for SAPGUI relies on the SAP Scripting API and ActiveX the SAP R/3 application server and on all SAP GUI clients that are participating in the load test. As of date of this article, LoadRunner documentation does not have updated details on configuring SAPGUI for scripting such as supported versions.  However, the configurations are somewhat similar to other performance testing product which in this article, we refered to IBM instead.

The basic requirements for LoadRunner (or performance testing tools) to record SAPGUI is on two things: (a) the client machines to have the entire SAPGUI Client installed and (b) the SAP server to have scripting enabled.  (c) Other than the configurations, you may have to take note of the ports used by the SAPGUI, namely, TCP32## where ## represent the System Number.  This is especially important if the environment you are in is tight on opening of ports.

[1] Ensure client scripting enabled

• To ensure that scripting is available on the client-end, check that there is a Scripting directory located in the SAP GUI installation directory.  If this directory does not exist, then the SAP Scripting API is not installed and you must reinstall SAP GUI with the SAP Scripting API option.

[2] Ensure server scripting enabled

• Logon to SAP with a user with administrator privileges.  Administrator privileges is required to enable scripting on the server.
• In SAP, run the transaction rz11, and enter parameter name sapgui/user_scripting.
• If the parameter is not found, ensure that you have the correct support package level from SAP and contact SAP should you require further guidance on this.
• If the parameter exists, enable the parameter with the Current value changed to TRUE.  Save it and scripting will be enabled the next time you log on.

(Source: IBM, Configuring SAP R/3 for performance testing)

[3] Ensure communication between SAPGUI with SAP servers

Ensure that you have connectivity on TCP32##.  This is the port number used by SAPGUI to communicate to the dispatcher.

Also, before starting the scripting, for newbies, you may like to gather the following information as they will be used for the scripting work.  The user account used in the scripting (accessing the SAP system) should have sufficient privileges to the transactions.

• SAP Client
• System Number
• Authorization User Name
• Authorization Password
• SAP Router String (Optional)

In summary,

• Ensure client scripting enabled
• Ensure server scripting enabled
• Ensure communication between SAPGUI with SAP servers

The fact is that it doesn’t really matter the type of language that was used to developed the application, but rather the type of communication method or protocol that the application is talking to the server. Previously, in “What’s LoadRunner?”, we mentioned that the tool captures network traffic while recording which is the core understanding that we must align when using this tool.

For example, an application can be developed using .NET 2.0 framework, is window-based (Win32). This application can be part of a N-Tier architecture that utilizes HTTP or HTTPS to communicate to the middle-tiers or a 2-Tier architecture that talks to the database directly using ODBC, ADO or JDBC-ODBC.

Similarly, an application can be developed using Java, but it talks to the middle-tier using RMI-Java or HTTP, or to its database using JDBC.

Despite the language or the type of of Applications (Java or Win32, etc.), the Load Tester must understand the communication method in order to determine the protocol to be used. This is done by consulting the development team of the application (which usually the Load Tester do not have such knowledge).

To understand the protocol used by the application (client to server), you can do the following.

1. The easiest way, check with the application team or vendor, particularly the software architects and the developers. They should be able to provide such information. If they don’t, it ’s time to doubt the experiences of the application team.

2. Use WireShark Network Analyzer to sniff the traffic communication when the application is running. More details of the usage can be found in the provider’s site. You should be able to see the protocols under the protocol column after you start capturing the traffic.

3. Use netstat -a to determine the protocol and port number. For example, the protocol is TCP and port number is 80, it could signifies HTTP. The caveat for this is that netstat -a only display protocol in IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6 (/? help for more information), which means you may need to guess the protocol according to the protocol (TCP) and port number.

4. Use Winsock protocol to determine the protocol via the data files. Winsock captures all traffic of any type at the socket level and writes it to the data file. From the data file, you will then find signatures of the protocol such as HTTP requests and responses in the context of HTTP.

Hopefully this methods are sufficient for you to determine the protocol used. Feel free to comment if you have a better method.

LoadRunner

It seemed that all is good with LR8.1 FP3. However, with the grouping feature of the protocols, and all monitors being available, there are no free meals, the costing have also increased.

Once you’ve upgraded to LR8.1 FP3 from a previous version, and you would like to uninstall FP3, there are no methods to rollback the upgrade other than uninstalling LR again and upgrade to the Feature Pack that you desired (e.g. FP2).

The license effectively constraints the Controller in the type of Vusers to run, the number of Vusers to run and the type of monitors entitled. As such, you can still install Vugen and Analysis to perform recording/replaying and analysis of the graphs without worrying about the license restrictions.

The license is usually bounded by a Host-ID (with exception on dongle based license) which generates the License Key for the machine. Take note that if you change system values like System Date, this will create a security violation to the license causing it to fail when you startup Controller. If such things arises, don’t do anything else, it’s not going to work; just contact Mercury/HP for an unlocking license to save you the troubleshooting time.

The Host-ID changes every time, however be assure that the license generated remains the same. This as described in Document ID 30252 is because the Host-ID is based on an algorithm to calculate the value out based on system values. That is the reason, changes such as the System Date may cause the Host-ID to be inconsistent with the License Key.

There are a couple of KBs in the support website that provides useful information on licenses. I’ve listed them down for your reference. Take note that you have to be a valid user of the support website in order to access the articles:

Document ID 3422 – How to determine the number of Vuser licenses
Document ID 9120 – Error: “You do not have a license for this Vuser type”
Document ID 10260 – How to get a LoadRunner license key
Document ID 10749 – How to generate a hostID without installing first
Document ID 11369 – How to enter a new license key for LoadRunner
Document ID 36169 – Error: “Loadrunner security Violation. Please reset the System Date”
Document ID 39992 – Where is the license key saved after it has been applied during LoadRunner installation

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!