OATS Enhancement: Verify the response contents of http requests which enclosed by begin/endconcurrent

Question

Recently I’m testing the Fluid UI with OATS 12.4.0.2.
In this test, since the browser get all tiles in current page simultaneously, I have to simulate this behavior in OpenScript/OLT.
Then I put all those http requests into a concurrent block ( marked by begin/endconcurrent statments) and it works fine.
But this bring in a limitation: so far, the OATS doesn’t support to verify the http response contents if those http requests resided inside the concurrent blocks.
So I did an enhancement for OpenScript to overcome this limitation. I think it might useful if you have similar test scenario.
How to use it:
Put the attached file ConcurrentHTTPService.java into your OpenScript project folder ( same folder as where your script.java living).
Replace the alias line for http in script.java, the below is after replacement:
//@ScriptService oracle.oats.scripting.modules.http.api.HTTPService http;
@ScriptService ConcurrentHTTPService http;
  3. Put your http.get inside concurrent block as usual:
http.beginConcurrent("Get_Tiles_Concurrently");
//The below IDs are useful for later. We use this ID to identified the http requests inside the concurrent block.
//If you dn’t have those IDs, it’s OK, we can use the full URL string (including all parameters)to do the same thing,
//but the full URL is very long, and I hate the screen were occupied by URLs…
http.get( 193, "http://Page1",...);
http.get( 194, "http://Page2",...);
http.endConcurrent("Get_Tiles_Concurrently");
  4. After endConcurrent statement, We can use the following methods to get the http response content by RecID or full URL:
//Those methods should be used after the endConcurrent statement
//Get the response contents:
//Please reference the http.getLastResponseContent method for the explain of parameters.
info("Resp 193/Page1:" + http.getLastResponseContentForConcurrent(193,Source.Html));
info("Resp 193/Page1:" + http.getLastResponseContentForConcurrent("http://Page1",Source.Html));
//Verify the response contents:
//Please reference the http.AssertText method for the explain of parameters.
http.AssertTextForConcurrent(193, "Text Match Name", "Key_word_should_appear_in_response_content_of_request_193/page1",
    Source.Html, TextPresence.PassIfPresent, MatchOption.Exact);
http.AssertTextForConcurrent(("http://Page1", "Text Match Name", "Key_word_should_appear_in_response_content_of_request_194/page2",
    Source.Html, TextPresence.PassIfPresent, MatchOption.Exact);
Done!
Thank glenn.s in this thread: How to test asynchronous web service.

Answer 1

I think I have the solution to your dynamic addressing problem, but I have a problem combining HTTP authentication with dynamic address resolution.
I've got an external service that requires basic authentication and I've handled it successfully by adding a <MustSupportBasicAuthentication> block to the WSDL, as described in the article "Basic Authentication in HTTP SOAP BC" (http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBasicAuthentication). This works perfectly, causing the HTTP BC to send credentials every time it accesses the external service.
Now I want to make the URL of this external service dynamic (i.e., read it at run time from a configuration mbean). I followed the example from the article "Using Dynamic Address feature" (http://wiki.open-esb.java.net/Wiki.jsp?page=UsingDynamicPartnerLinks), which shows you how to send an endpoint reference (EPR), in the form of an <EndpointReference> block. This also works fine.
(I believe this last technique is the solution to your dynamic addressing problem. I've used both with and without BPEL. To use it outside of BPEL, you make a DocumentFragment out of the XML tree that begins with <EndpointReference> and pass it as an argument to the resolveEndpointReference method of your component context. This causes the JBI container to contact the HTTP BC, which understands the EPR.)
My problem is this: once I've dynamically changed the target URL of the external service, the HTTP BC seems to forget that it requires authentication and no longer sends credentials.
Has anyone else experienced this behavior, and if so how did you work around it?