0

Problem The JSR223 shifts its processing. On the first ForEach iteration I expect the JSR223 to produce a given value, but I see that expected value on the debug postprocessor of the following interation instead. Why is this happening?

Scenario I have a set of companies (thread group). Each company has a set of Stores (ForEach #1). Each store has a set of "location groups" (ForEach #2). Each location group has its own type.

Scenario outline

The location group type is a numeric value, from 1 to 12. Let's say the ForEach controller iterating these location groups produce this sequence of types: 6, 9, 5, 11, 7, 12, 10 and JSR223's code is as follows:

if (vars.get("locationGroupType") == "6"){
    log.info("Store:" + vars.get("anUnit"))
    log.info("location group ID:" + vars.get("aLocationGroupId"))
    vars.put("aux", "SIX")
    log.info("location group type:" + vars.get("locationGroupType"))
 }
 if (vars.get("locationGroupType") == "9"){
    log.info("Store:" + vars.get("anUnit"))
    log.info("location group ID:" + vars.get("aLocationGroupId"))
    vars.put("aux", "NINE")
    log.info("location group type:" + vars.get("locationGroupType"))
 }

I would expect aux to be SIX on the first iteration, then NINE on the second.

Output This is JSR223's output to console: Console output You can see the store 292 has a location group id of 3803 which has a type value 6. But this information is NOT correct.

Request output for location group id 3803, which has a type value of 9: location group 3803 response Debug postprocessor dump where I can see 'aux' set to SIX: debug postprocessor

Oddly enough, the previous request to 3803 is the one that has the type value 6, and this is where I expect aux to be SIX: Response for 3635 where the type value 6 is found And the debug postprocessor for 3635 showing 'aux' to be empty: enter image description here

leansoli
  • 1
  • 2

2 Answers2

0

If you plan to use all these values: 6, 9, 5, 11, 7, 12, 10 it's better to go for switch statement instead of multiple if's.

Isn't it a copy-paste issue and shouldn't your code look like:

switch (vars.get(('locationGroupType'))) {
    case '6':
        log.info("Store:" + vars.get("anUnit"))
        log.info("location group ID:" + vars.get("aLocationGroupId"))
        vars.put("aux", "SIX")
        log.info("location group type:" + vars.get("locationGroupType"))
        break
    case '9':
        log.info("Store:" + vars.get("anUnit"))
        log.info("location group ID:" + vars.get("aLocationGroupId"))
        vars.put("aux", "NINE")
        log.info("location group type:" + vars.get("locationGroupType"))
        break
    default:
        log.info('default branch')
        break
}

Otherwise I can think of the following reasons:

  • JMeter Post-Processor placement matters, i.e. if your have Debug Post-Processor before the JSR223 Post-Processor you won't see the variables generated in the JSR223 Post-Processor until next iteration
  • JSR223 PreProcessor is executed after each Sampler in its scope so make sure that it's placed correctly and fired only where it's supposed to fire.

More information on Groovy scripting in JMeter: Apache Groovy: What Is Groovy Used For?

Dmitri T
  • 159,985
  • 5
  • 83
  • 133
  • The code in the JSR223 is more complex than what I mention in my post. The code in the post is only meant to show my problem with the shifting I describe. The nesting of the elements is properly done. ForEach with HTTP Request and JSR223. The HTTP Request has a Regex which is the variable used in the JSR223. JSR223 and HTTP Request are at the same level, HTTP Request comes first. Thanks for your answer though, I appreciate the time spent in understanding my problem. – leansoli Feb 01 '23 at 16:48
  • I also have debugs before and after JSR223 and I'm positive I'm looking at them correctly. – leansoli Feb 01 '23 at 16:56
0

Ok, what I describe in my thread was a Jmeter issue. I just tried the same exact script in Jmeter 5.5 and the shifting problem has been resolved.

leansoli
  • 1
  • 2