Helping a LoadRunner User speak Gatling --- Parameterization

Confession: I am not only a Gatling noob but apparently so LoadRunner-corrupted that I have trouble even getting my brain around Gatling.

So, trying to stay open minded, off we go.

I have built my very first Gatling script of an HTTPS Okta-protected (SSO) web site. The user story is simply to access the target URL and login.

I built the script by using Chrome to build a HAR file, and imported it into the Gatling recorder.

It seems to work, though I actually have some trouble telling if it really does, which is why I am moving on to parameterization.

I need to read Employee id’s from a CSV data file and pass an id randomly into the parts of the SCALA script where it is needed.

This is a cinch in LoadRunner, but apparently a little more complex (at least for me) in Gatling.

Here is what I have:

I have a 200 row CSV file stored in C:\Gatling\user-file\resources





In the SCALA script I have added a feeder statement to pull the CSV file into memory (assuming I understand how that works):

class DealerPath extends Simulation {

val feeder = csv(“R4-Dealers.csv”).eager.random

val httpProtocol = http



In the script location where the manually entered Employee ID is found I replaced the value with ${Employee}:

.get(uri20 + “/b/ss/deerejddealerpathdev/1/JS-1.6.4-D7QN/s22257548961079?AQB=1&ndh=1&pf=1&t=20%2F1%2F2020%2013%3A49%3A27%204%20360&D=D%3D&mid=77887682783998080434584462396683909568&aamlh=7&ce=UTF-8&pageName=r4%3Amydealerpath%20home&${Employee}&c21=D%3Dv21&v21=en_US&s=1680x1050&c=24&j=1.6&v=N&k=Y&bw=1680&bh=528&-g=9&AQE=1”)

Immediately before the above .get step in the script, I placed a .feed(feeder) call:

.get(uri13 + “/wps/contenthandler/dpath/!ut/p/digest!CfC_sxRf5skScA7XMP9B0g/dav/fs-type1/themes/dealerpaththeme/css/default/lib/images/ui-bg_flat_75_ffffff_40x100.png”),



.get(uri20 + “/b/ss/deerejddealerpathdev/1/JS-1.6.4-D7QN/s29046673639337?AQB=1&ndh=1&pf=1&t=20%2F1%2F2020%2013%3A49%3A40%204%20360&D=D%3D&mid=77887682783998080434584462396683909568&aamlh=7&ce=UTF-8&pageName=r4%3Am%26a%3Aeleader%20%28the%20leader%29&${Employee}&c21=D%3Dv21&v21=en_US&s=1680x1050&c=24&j=1.6&v=N&k=Y&bw=1680&bh=528&-g=c&AQE=1”)

When I try to run the script, it blows up during the compile.

11:55:53.320 [ERROR] i.g.c.ZincCompiler$ - C:\Gatling\user-files\simulations\DealerPath.scala:612:5: value feed is not a member of io.gatling.http.request.builder.Http

possible cause: maybe a semicolon is missing before `value feed’?



11:55:53.367 [ERROR] i.g.c.ZincCompiler$ - one error found

11:55:53.382 [ERROR] i.g.c.ZincCompiler$ - Compilation crashed null

I have read and read about feeders, and I have tried to read quite a few past posts, but I am so green to Scala/Akka and even Java, that it is Greek to me.

I also know that once I figure out this part of the script parameterization I will need to figure out how to paramaterize the SAML activity. That, itself, will for me be an even bigger step up.

All I need to do is login 8000 users in an hour to a web portal. It should not be rocket science.

I am trying to “shift left” performance testing by having Product/Delivery Teams do their own testing instead of relying on a central, shared service testing group. However, I am finding it hard to “teach a man to fish”, since I am apparently so specialized in LoadRunner, that I need to totally revamp my brain.


Hi Randy,

Try to keep .feed(feeder) out of the .exec(). Let me know if that works.


Thank you for the response, Prithav.

Though I still do not quite understand the concept of a “chain”, I moved the .feeder call up higher, and it seems to now work. Or at least I am not getting a total failure.

How can I tell if it really is reading the file and using the parameters? I looked at the application using AppDynamics, and there was no activity. This tells me that I only have the illusion of a working script. Should I post this question as a separate thread?

By the way, so far you Gatling guys make the Mercury/HP/MicroFocus Support group look silly. I always suspected that using an Open Source tool would easily out pace the expensive LoadRunner tool.


Please have a look at the logback.xml file and uncomment lines to debug your tests and check if you’re properly sending the payloads.
Gatling verifies that response status is 20X or 304 so except if your application is poorly implemented and responds with a successful HTTP status while the request failed, your request was likely to be successful.