Virtual Table Server

I think that many readers are actively using LoadRunner. So I’ve got a question for you – where do you take the test data from? The first option is to parametrize everything and save the dataset in .dat-files. It’s a good solution, but what if there are many scripts with common parameters in the use case? The second option is to use a database. It’s already better, because the common parameters can be shared, but the configuration for some databases can be a nightmare for a newbie. I’ve got one more option that is both simple and effective.

Our topic will be a LoadRunner component – Virtual Table Server (VTS). To begin with, let’s sort out, what it is and what to do with it. Its last versions have a js-node server on the back-end and its architecture reminds a database. But it just seems so on the first glance. Actually, I’d rather compare VTS with a simple table, because we can access practically any cell, row or column using the column name or the row number. We can read, delete and add data, as well as empty the table – all of it without leaving LR. The details can be found below. First let’s discuss, where to find it and how to install it.

Installation

Habitation area is the folder \Additional Components\Virtual Table Server or MicroFocus site (registration required to download the files). There shouldn’t be any difficulties during the installation. First the temp folder should be selected, then the main installer will run. During the installation there will be an option to change the program folder, as well as an option to choose a server management port. It’s recommended to keep the default value: 4000 (of course, if the port is not already in use). For those, who are lazy or value their time, there is an opportunity to automatically start the VTS. We activate the check-box, and after the install the browser with the application web-interface will open.

Don’t forget to switch on the script connection to the server through “Access from Script” on the right top menu.

Data input

We’ve got several options: send the data from the database, import it from a csv-file or using a script, do everything manually in the browser In my opinion the optimal version is to import data from a csv-file or using a script. I’m going to explain these two approaches. In case you are interested in the database import, take a look here.

CSV import

To begin with, we’ve got a csv – a regular text file with comma separators is enough. The first option is to use Import ->Import from CSV file in the web-interface. Then we just need to choose the file, whisper the incantation and olè – your data has already been pasted in the table. The second option is to use a script that will do the job for you You’ll need the file \VTS\web\vtscmd.js.

It works like that: 

node vtscmd /import samples/Customers.csv /port 8888

The script can also carry out other useful tasks, such as empty a table:

node vtscmd /delete_data /port 8888

Or create another one:

node vtscmd /start /port 2000 /name table_one

The full command list: 

and parameters:

The only problem with it is that it doesn’t work with a remote host. For this purpose we have to write scripts of our own. On the project we are using a java-utility that empties a table and imports a csv. The data is sent via a POST query, here are several examples:adding the data to a cell:

emptying a table:

finally here’s the most precious – csv import. The file path can be full or relative, but @ sign is necessary. Command run example from the folder with the file:

This requests are not working with the main table that is created by default. It’s needed to create one more table on a separate port and work with it.

Generally, if one expects that tables contain different sized columns, I recommend to create several tables in such a way that the data is comparable by size. For example, we create the first table with parameters with one value, the second table with parameters for 10 values and so on. Of course, all of this should be used without exaggerations. A bit later I’m going to show the LR functions – they are very useful to receive the whole parameter set, so it’s worth thinking about the data management.The queries can be turned into a full-fledged application and simply used from the Jenkins script.

LoadRunner Script

Another option to add data is a VUGen script. For this purpose a simple script is enough. To begin with let’s prepare the data: it needs to be saved in VTS as regular parameters. Then we write in the script the following:

I recommend to check the data and/or the return value to prevent invalidated data or script failures. It’s especially important during the data reception – I received in some cases an empty line instead of the required value.

Finally, don’t forget to close the connection after finishing working with the table:

Data communication

I’m going to explain several functions that I’m using in my work: lrvtc_query_row ( int index ) – it retrieves for the table all parameters that are located in the index row. Each column corresponds to a parameter with the same name that is saved as string. If there are no data in some cell, then NULL is written to the parameter.

It’s recommended to use indexes in order to optimize and speed up search for unique values in tables with many lines.

Known problems

On one hand, the ease of configuration and communication with LR are a big plus. On the other hand, there are a couple of things that I don’t quite like. First, spaces appear in the table in some cases. We’ve observed that while using rotate_xxx function. It seems that the server has got problems with processing concurrent queries from virtual users.Another issue is that there is no satisfactory API for initial data input and data deletion from the tables. I hope that there will be such functions in the next versions, but at the present we have to invent our own bicycles.

I recommend the described approach to everyone who still keeps a lot of same parameters in different scripts. Just don’t forget to check the received values.