Hi,
I had a similar issue in one of my projects way back, I think you have a couple of choices - go with a groovy script choice to build the request you need dynamically and then publish the request (@nmrao developed a script to enable me to do this)
OR - you can use the OTB functionality - this isn't the best option for a number of reasons.
If you could set the URI's QueryParameters to 'PLAIN' in the SoapUI tab - this would be perfect - but you can't do this unfortunately - if you could do this, this would've saved me a lot of hassle - I've just created a feature request for this exact functionality (link)
Also - you'll see the OTB functionality option is quite awkard because there's a known issue where if you have multiple query parameters in the same 'Resource' level request - you can only have a single request.
i.e. if you have multiple requests like the following:
/api/{version}/{whatevs}?name=value
/api/{version}/{whatevs}?cbe_number=value
/api/{version}/{whatevs}?country=value
/api/{version}/{whatevs}?municipality=value
/api/{version}/{whatevs}?neighbours=value
/api/{version}/{whatevs}?street=value
/api/{version}/{whatevs}?housenumber=value
/api/{version}/{whatevs}?po_box=value
you won't be able to use these all in the same REST Service as separate resources because you'll create them fine, then go into the SoapUI tab and try and grab one of the requests, but when it gets created as a 'REST Request' test step, it'll just display the QueryParm of the first one created - even though you can see the individual resources with those different query parms and you selected a different one.
You also have the added complication that I'm guessing you won't just have single query parameters in your URI's query string - at worst case - you can have the full 8 query parms in your URI's query string.
This is NOT a great answer - but it does get the job done, because it was what I did.
I created a separate Service level item in the Projects level for each different request - so you have 8 single query parms, and then you'll have combinations 8x8 = 64 - so you'll have 64 Service level records (each with a single resource) created in the Projects tab
That's a lot of work! - by using the OTB functionality this is the only way I've found to do it.
Your other option is groovy - I recently needed to create a request where there are many, many different QueryParms in my request - maybe 500 different values as QueryParameter names. This, I'm sure isn't the only groovy way of doing this - but it's definitely one way.
@nmrao developed the following script - it builds the content of the request (in the format of /api/1/{namespace}/{dataset}?QueryParmName1......................QueryParmName500) from values set in a Properties step
//Script developed by Rao
//import decs
import wslite.rest.*
def serviceHost = context.expand ('${#Project#TestEndpoint}') //'https://whatevs.azurewebsites.net'
//Below to handle template parameter, additional $ required before
def getNamespaceDatasetPath = '''/api/1/${namespace}/${dataset}'''
//define all template param values as shown below
def binding = [namespace : context.expand( '${#TestCase#namespace}') , dataset : context.expand('${#TestCase#dataset}')]
//def binding = [namespace : 'certification-nomenclature', dataset : 'certification-nomenclature']
def template = new groovy.text.SimpleTemplateEngine().createTemplate(getNamespaceDatasetPath)
def queryParams = [:]
//Get the properties of Property Test step
context.testCase.testSteps["Properties"].properties.each {
queryParams[it.key] = it.value.value
}
def client = new RESTClient(serviceHost)
def response = client.get(path: template.make(binding) as String,
accept: ContentType.JSON,
query : queryParams
)
assert response.statusCode == 200
log.info groovy.json.JsonOutput.prettyPrint(response.text)
SO - the above won't allow you to omit certain query parms in your request - but it allows you to build the request's parameters as you need them.
Cheers,
richie
if this helped answer the post, could you please mark it as 'solved'? Also if you consider whether the title of your post is relevant? Perhaps if the post is solved, it might make sense to update the Subject header field of the post to something more descriptive? This will help people when searching for problems. Ta
