Loadrunner Parameters in Blocks not updating?

I’ve encountered an issue recently where in a loadrunner script, I wanted to execute a number of requests of one type, followed by a number of requests of another type, followed by a number of requests of a third, and subsequently fourth and final type.

The whole thing is four blocks looping in sequence inside an outer loop of iterations in Loadrunner Vugen.

It looks like this:

One of the requirements is that the data table for each request is common, so the first element used in block 0 is also the first element in block 1, 2 and 3.

Each action is creating an xml file – the data between each file is common in some areas.

Originally, the whole thing ran in sequence without blocks but there is a pair of processes in the application under test which is consuming these files, it operates on a schedule and its logic dictates that the files are sent in order. The issue here being that it is theoretically possible to find the gap between the schedules and to process a 900 request before a 600 request – resulting in data which is no longer usable in the system.

Inserting think time between each block solved that problem but also reduced throughput to an unacceptable level, requiring vUsers far in excess of what the license would allow.

My solution then was to create the block design above and that seemed fine until we tried to validate the output.

It turns out that the iterations counter in loadrunner only applies to the outer loop of processing – and that the parameters will not update as expected as a result.

My First thought was to make the data iterate on every occurrence but the data is used multiple times throughout the xml requests so that didn’t seem viable either.

If I created a temporary parameter to store the value for use whist limiting the occurences of the master parameter, then I couldn’t share the value appropriately through the blocks – I couldn’t keep the data in sync for block 0, block 1, block 2 etc.

My second thought was to build an array on the fly in the first block, and to use independent counters in each block to access the data in that array in all the actions from there.

And that seems to work – but it looks crazy.

All parameters are set to use same row as Order_ID_TEMP which is set to sequential – Once, since we’re advancing it in code rather than letting vugen handle it.

There are parts of this that aren’t strictly necessary – The entire first block creating temporary parameters could go – all of those lr_save_strings are not needed if I reused the variables in the second section building the array.

The array building is neat though and I re-used szParamName1 for all of that to reduce the variables in scope.

The buffer sprintfs create a variable with a counter as an index. The lr_save_strings assign a value to that variable.

The final series of sprintfs and lr_save_strings consume from the array and assign the variable to a parameter which is named in the xml declaration.

i400 is the index used in this action

Subsequent requests only require that last section to repopulate the parameters with the variable data based on a local iteration counter. Essentially each block is it’s own for loop (without actually declaring a for loop).

This is how I developed a method to send synchronised data between blocks iteratively and it may not be the best solution but I’m really rather proud of it. Not least because I came up with the solution in the bar of an Edinburgh hotel and spent maybe 3 hours on it (which in Loadrunner terms is a mere moment in time).

You can leave a response, or trackback from your own site.

Leave a Reply

Powered by WordPress and ThemeMag