If you have arrived at this page directly, please go through this post and then this post first. It explains some basics, defining HTTP protocol configurations, headers, feeders and HTTP requests which will be used while building the scenario being discussed here.

Step 5: Define scenario A scenario can be defined as a Scala variable or Scala function. The following scenario is defined as a Scala function which takes a step, pacing, and duration as arguments.

def ApiLoad (step: Int, pacing: Int, duration: Int) =
	scenario(s"API Scenario $step").during(duration seconds){ //1
		pace(pacing seconds) //2
		.exec(
			exitBlockOnFail { //3
				exec(session => {
					session.set("custId", customerId) //4
				})
				.randomSwitch( //5
				  50.0 -> exec(session => {session.set("url", testURLPrimary)}),
				  50.0 -> exec(session => {session.set("url", testURLSecondary)})
				)
				.feed(correlationIdFeeder)
				.exec(requestOne) //6
				.feed(someIdFeeder)
				.exec(requestTwo)
				.pause(2) //7
				.feed(anotherFeeder)
				.exec(requestThree)
			}
		)
	}

1. Run whatever is in the during block for duration seconds. i.e. when scenario execution starts, iterations of this block will be executed continuously until duration. Round brackets contain scenario name and it should be unique. That’s why I have $step there. More on that later.
2. Each iteration executes with an inter-iteration gap of pacing seconds. The usage here is similar to pacing in Loadrunner
3. Exit the block if any request in the block fails, and start next iteration.
4. A Session is actually the messages that are passed along a scenario workflow and this is how you can pass session attributes into the simulation. In this case, customerId is accessed using ${custId} in the request body. More on this at the end of this post.
5. randomSwitch allows to chain between testURLPrimary and testURLSecondary randomly (i.e. each getting 50% requests in this case). Note that the sum can’t exceed 100%. If it’s less than 100%, users that won’t fall into one of the chains will simply exit the switch and continue.
6. requestOne, requestTwo and requestThree are REST API requests which are executed in sequential order. Each time a feeder is encountered, a new value is popped out and used. Feeders and HTTP request definitions are explained in step 3 and step 4 in this post.
7. Pause for 2 seconds before executing next request. Similar to think time in Loadrunner

Now that we have defined the scenario, next we will set up the simulation where we define how we want to inject this load on the server. See here. But before that,

Let’s see how we can perform operations on session attributes

...
.feed(correlationIdFeeder)
.feed(someIdFeeder)
.exec(session => {//1
		session.set("url", testURLPrimary)
})
.exec(session => {//2
	session.set("url", testURLPrimary).set("randomId", Random.nextDouble)
})
.exec(session => {//3
	session.set("url", testURLPrimary)
	session.set("randomId", Random.nextDouble)
})
.exec(session => {//4
	val rs = session.get("responseString").as[String]
	val derivedrs = com.test.calculateMe(rs)
	println("rs: "+rs+" derivedrc: " + derivedrs)
	session.set("newrs", derivedrs)
	session
})
.exec(session => {//5
	session.set("searchDate", searchDate).set("NextNumber", session.get("NextNumber").as[Int] + 1 )
})
.exec(requestOne)
.exec(requestTwo)
.exec(requestThree)
...

1. sets attribute URL to the value of testURLPrimary.  Attribute value can be accessed using ${url}
2. If you want to set values of two or more attributes, do it this way.
3. This is a wrong usage. The first session.set is just discarded. Use above approach.
4. Retrieving an attribute from the session, then use it to derive another value, set it in the session and then return the session (return keyword is optional)
5. increment an integer attribute on the fly in a session. Note: Session instances are immutable! It will actually return a new instance of NextNumber

Next load injection patterns