suggestions for passing arguments from one test plan to the next?

[Spencer Haney]

hi all - 

I have an existing JMeter approach that works for my scenario, but I am curious if it's possible to solve with the jmeter-maven-plugin.

The main challenge is having a set of JDBC connection configs that need their credentials set dynamically (due to company policy I am not allowed to store any credentials outside of our secure data vault).  Coupled with this is the challenge of JDBC connection configs getting initialized prior to any PreProcessor, which prevents me from retrieving the credentials as part of a PreProcessor step.

The solution I have works as follows

1. init test plan (A)
   a. retrieve credentials from data vault
   b. call the main test plan (B) using an OS Process Sampler, and include the credentials from (a) as command line arguments (ex:  -Jpassword=xxxxxx)
   
   
   
2. main test plan (B)
   a.  JDBC connection configs are defined in a setUp thread and set values from properties, ex:  ${__P(password,)}
   b.  run main thread group   

This works but I would like to get a similar solution using the plugin if possible.  However I am not clear on how output from one test plan can be used by another.   I don't think my existing solution will work as the target path of the plugin's jmeter instance is dynamic (target/<dynamic>/jmeter/bin) and I'm not sure how to identify it in the OS Process Sampler.

Is it possible for test plan (A) to update <propertiesUser> dynamically so that in turn, test plan (B) would be able to leverage them?

Any other thoughts/suggestions?

thanks!!!!

-Spencer

[Ardesco]

Not really.  

the plugin uses maven phases, so you could configure two separate executions (e.g. https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/blob/master/src/it/multiple-execution-blocks-with-custom-config/pom.xml), but the configure goal always runs in the compile phase.

This means that both instances of JMeter will be created in the compile phase, and then each one will be run in the integration-test phase.  At this point it's too late to run another compile phase to prep up the next instance.  You could try and chain the runs maybe?