ContributionsMost RecentMost LikesSolutionsRe: How to add custom headers at parent level Hi Richie, Some globallevel elements certainly can be set, but I do that in the settings/preferencesdialogue. Unfortunately they will apply to all projects. One example is to use my own custom User-Agent header when I want to bypass the request and use my own curl from groovy. So in the preferences under HTTP for "User-Agent header: I type curl/7.27.0. Other preferences apply globally too. I suspect this is not what the OP wants if the OP has multiple projects. I have not found how to do that in a groovy script. I also turn off compression "Request Compression" - choose None. The request parameters - resources, can be done in groovy as well using perhaps json, and I've done that. I don't know about matrix or template parms as I don't use them. I prefer proper nomenclature too: Global: Across all projects, Events or Project: Affects all test suites, Test Suite - affects all test cases, etc. regards Bill Re: How to add custom headers at parent level You can do this at the parent level (by that I am guessing so that all requests use the same headers is what you want) - by doing so in an event handler. So that in the RequestFilter.filterRequest event handler if you want to add "Content-Type: application/x-www-form-urlencoded" as a header you can do it the following way: def headers = request.requestHeaders // I clear out all request content, but you might not want to do this: context.setProperty("requestContent", '') request.requestContent = '' // add the header headers.put( "Content-Type", "application/x-www-form-urlencoded") request.requestHeaders = headers Now every request will have the "application/x-www-form-urlencoded" Content-Type. Bill Re: rerun a test case in ready api using tear down script I have only been able to rerun a request - you know, a request test step, but not as a test case. A test case can be made up of many test steps, several of which can be requests. In your code, the "FAIL" should be "FAILED" right? But by the time teardown happens the status will likely be "FINISHED" As a long shot, if you use a command line script and you can figure how to output the result from testrunner, then your script can repeat the call to testrunner. So you'd run it out of a shell rather than from within the ReadyAPI IDE. I loaded the REST Sample Project in my ReadyAPI 2.2.0 and I added my own groovy script after the test step "Submit Account Details." There is an earlier test step "View Form." Suppose you have a similar test case. Maybe you'd have a Groovy script to check the status of all request steps. def responseHeaders = testRunner.getTestCase().getTestStepByName("Submit Account Details").testRequest.response.getResponseHeaders() int retryAttempts = 3 log.info "here 0" //while (retryAttempts > 1) { while ((retryAttempts > 1) && (['HTTP/1.1 200 OK'] != responseHeaders['#status#'])) { retryAttempts = retryAttempts-1 log.info "decrement retry attempts-" + retryAttempts testRunner.runTestStepByName(testRunner.getTestCase().getTestStepByName("Submit Account Details").toString()) // edit May 29 (update responseHeaders responseHeaders = testRunner.getTestCase().getTestStepByName("Submit Account Details").testRequest.response.getResponseHeaders() log.info "just ran" } log.info "here 1" Like the above script can follow "Submit Account Details" request and repeat it if necessary. I guess since I want to rerun a step using groovy if it failed, I should not use the request step assertion. Instead I would allow the request to run as many times to the limit you want and then have your own assertion script following the groovy script. You can add an assertion script and check messageExchange.responseHeaders for the #status" to equate to HTTP /1.1 200 OK in an assert statement. def responseHeaders = messageExchange.getResponseHeaders() log.info "here 0" //while (retryAttempts > 1) { assert ['HTTP/1.1 200 OK'] == responseHeaders['#status#'] log.info "here 1" attachedis an image of my modified REST Sample Project shown in ReadyAPI with the above two scripts added inside the "account creation TestCase" In summary, I have not been able to give you a way to run a test case in its entirety if it fails. However I used the above scripts to rerun a request step at the test step level. Bill Re: rerun a test case in ready api using tear down script I will look into it. Bill Re: rerun a test case in ready api using tear down script It seems intuitive that the teardown script is intended to do cleanup work for the test case or test suite after it executes. Have you tried this code in other scripts - like a requestFilter.afterRequest event handler or a groovy step? Maybe by the time teardown occurs a rerun of the test might have unpredictable results. I think of scripts running in this order 1. Test Suite (setup script if it exists ) 2. requestFilter.filterRequest (if the event handler exists) 3. Test Case (setup script if it exists) 4. Groovy Step (groovy script if it exists) 5. requestFilter.AfterRequst (if the event handler exists) 6.. Test Case closure (Assertion Script -if it exists) 7.. Test Case (teardown script if it exists) 8. Test Suite (teardown script if it exists) Of course there are other event handler scripts but I normally work with the request filter events. I have been able to use the afterRequest and access the response and rerun a request. Bill Re: Unsupported File Format using Data Source - File Option I'm not sure if this will help but there are spaces in the folder path. You might try quotes. Or if this is on a windows system how about the short name for the file? Re: How to associate the response with the expected result (in data source) please? Shivani, You might want to start a new thread andrepost your question because the OP has been marked with an "accepted solution" Bill Re: Passing values for Media Type and Content-Type "application/x-www-form-urlencoded" We need more details on what you are attempting. Do you have a screen shot of your request editor showing the method, parameters, and request form? And an error log would be helpful. I assume your method is POST or PUT. Bill Re: how can you tell an endpoint is valid - client sent me WSDL but said do not use endpoint in WSDL, us I was doing some looking. Perhaps the version of TLS is 1.0 on one and and 1.2 on the other. see for examplehttps://community.smartbear.com/t5/SoapUI-Open-Source/Solved-SSL-Handshake-exception-calling-a-secure-webservice/m-p/103595#M18090 Re: how can you tell an endpoint is valid - client sent me WSDL but said do not use endpoint in WSDL, us I can see how they could make use of your info. I think I am getting into a topic I hope I will not regret. The SSL.exception threw me off because apparently you received that exception. When I got that exception it was from not having the certificate and key that the server side must provide me in order for me to test their REST API. Otherwise I notify the people involved and twiddle my thumbs. I suspect the WSDL is when you are making yourself a web service - a server, and the endpoint is possibly a client in the client/server sense after all. That would make sense that you need to send your credentials to the client. But the SSL.Exception threw me off. I think this exception might be possible if you are a web service. I have not tried the WSDL examples that ReadyAPI gave me. Seems that both you and I are missing some information. Hopefully someone else from the SoapUI community can be of better help. Bill