Contributions
Re: ServiceV Pro: Default response unexpectedly replacing the scripted one
AlexKaras Hi and welcome back, hope you enjoyed your vacation!:smileyhappy: I'd like to ask you to think for a moment to the semantics of the following paths: 1. /subject/{subject_nr}/mandate/{creditor_id} >>> path featuring 2 template params: when filled in, it validly represents a possible URI 2. /subject//mandate/{creditor_id} >>> path featuring 2 template params, where the 1st one is missing, it does NOT validly represent a possible URI 3. /subject/mandate/{creditor_id} >>> path featuring 1 template param: when filled in, it validly represents a possible URI 4. /subject/mandate// >>> path featuring 1 missing template param: it might validly represent a possible URI only if you drop the last forward slash 5. /subject/mandate/ >>> path featuring 0 template params: it validly represents a possible URI 6. /subject/mandate >>> path featuring 0 template params: it validly represents a possible URI Consequently, in case of paths 4, 5 and 6, it's reasonable to expect a status code 404 Not found, if you didn't take care of implementing support for path 6 in your service. Hope this helps!:smileywink:6 years agoPlace ReadyAPI QuestionsReadyAPI Questions3KViews0likes2CommentsRe: ServiceV Pro: Default response unexpectedly replacing the scripted one
AlexKaras Hi Alex, I believe your understanding as described in your post is correct. From my side, I just want to addsome additionaldetails, which my conclusions are based upon. If you test the following URLs in Chrome or Firefox, you'll be seeing the following behaviour in their address bar: https://www.google.nl => https://www.google.nl https://www.google.nl/ => https://www.google.nl <<< Forward slash is stripped out https://www.google.nl// => https://www.google.nl// <<< Forward slashes are not stripped out The reason of this behaviour is that a double forward slash represents a path segment, and apparently it doesn't matter if its value is an empty string or not, as long as the part of the URL preceeding it is a valid URI. The test paths I have provided in my previous posts have been designed with this consideration in mind. For all those paths where the second argument is missing, it's up to us to provide suitable fallback resources, in order to be able to handle them correctly and eventually dispatch a custom response. Please let me know if this helps clarifying the matter even further.:smileyhappy:6 years agoPlace ReadyAPI QuestionsReadyAPI Questions3KViews0likes4CommentsRe: ServiceV Pro: Default response unexpectedly replacing the scripted one
Ok, I finally have come to a working way of dealing with scenarios where a TEMPLATE argument at the end of the path is expected but not provided (as in the following paths): 5. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/0303200001/mandate// <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 6. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/0303200001/mandate/ <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 7. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/0303200001/mandate <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 8. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject//mandate// <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 9. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/mandate// <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 10. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/mandate/ <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 11. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/mandate <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT To be able to dispatch your own custom response, and avoid the default 404 ServiceV (bodyless) response, you'll have first to create a separate resource for the path you wish to mock, in my case: /urds/wrd/api/aicm/v1/subject/mandate Then, in your script, you'll be checking the path and react accordingly: def path = mockRequest.getPath() log.info("HTTP request path: ${path}") if (path.endsWith("mandate") || path.endsWith("mandate/") || path.endsWith("mandate//")) { log.info("mandate TEMPLATE argument: missing") // return the name of the response you want to dispatch //---------------------------------------------------------------------------------------------- return = "GET 400 Missing mandate ID" } Hope this will help you eventually!:smileyhappy:6 years agoPlace ReadyAPI QuestionsReadyAPI Questions5.4KViews2likes7CommentsRe: ServiceV Pro: Default response unexpectedly replacing the scripted one
AlexKaras QUOTE: "While the functionality of Parameter dispatch seem to be enough for my current attempt, I clearly see the cases when it may be not enough and when I will need the currently absent 'RegEx Not Match' option." Glad to see you totally got my point, dear colleague!:smileyvery-happy:6 years agoPlace ReadyAPI QuestionsReadyAPI Questions5.4KViews1like2CommentsRe: ServiceV Pro: Default response unexpectedly replacing the scripted one
For completeness' sake, this is the full list of paths I've been testing the behavior so far, with their associated test results: 1. Expected: Custom HTTP 200: /urds/wrd/api/aicm/v1/subject/0303200001/mandate/AB51TST405365330000/ <<< Custom 200 OK 2. Expected: Custom HTTP 200: /urds/wrd/api/aicm/v1/subject/0303200001/mandate/AB51TST405365330000 <<< Custom 200 OK 3. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject//mandate/AB51TST405365330000 <<< Custom 400 Bad Request 4. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/mandate/AB51TST405365330000 <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 5. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/0303200001/mandate// <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 6. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/0303200001/mandate/ <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 7. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/0303200001/mandate <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 8. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject//mandate// <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 9. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/mandate// <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 10. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/mandate/ <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT 11. Expected: Custom HTTP 400: /urds/wrd/api/aicm/v1/subject/mandate <<< ServiceV 404 Not Found own bodyless response: INCONSISTENT s6 years agoPlace ReadyAPI QuestionsReadyAPI Questions5.5KViews0likes14CommentsRe: ServiceV Pro: Default response unexpectedly replacing the scripted one
AlexKaras Hi Alex, Going for the Parameter dispatch style was indeed the first attempt I used for my implementation, given my path uses two TEMPLATE parameters.:smileywink: Unfortunately, one of the inbound values (the {creditor_id}) passed as argument to the parameter in the request is very complex to validate, in order to select the suitable mock response to dispatch (for the validation I use regular expressions) and I found that the visual facilities provided by ServiceV were not up to the task, to be honest. That aside, one of my main goals with ServiceV is to build up a script library for our testers to re-use, so... hence my decision to opt in for the Script dispatch style. I have of course contacted support too, and the private discussion is still open with them, since their argumentations insofar don't really fully convince me.:smileyindifferent: I'll keep posting the info here for the rest of the community too, of course. Cheers, MeT6 years agoPlace ReadyAPI QuestionsReadyAPI Questions5.4KViews0likes4CommentsServiceV Pro: Default response unexpectedly replacing the scripted one
First thing first: I'm new to the ServiceV product, just got it few days ago. I'm creating a virt api where the following path is being used: /api/aicm/v1/subject/{subject_nr}/mandate/{creditor_id} where subject_nr and creditor_id represent the required TEMPLATE parameters. Beside the main success scenario (GET: -> HTTP 200 OK), where both arguments are made available in the URI, I'm trying to handle the following alternative scenarios in my virt api: a) GET: {subject_nr} is empty -> HTTP 400 Bad Request b) GET: {creditor_id} is empty -> HTTP 400 Bad Request c) GET: both {subject_nr} and {creditor_id} are empty -> HTTP 400 Bad Request The test paths associated with the four scenarios (1 main + 3 alts) are: 1. HTTP 200: /urds/wrd/api/aicm/v1/subject/0303200001/mandate/AB51TST405365330000 2. HTTP 400: /urds/wrd/api/aicm/v1/subject//mandate/AB51TST405365330000 3. HTTP 400: /urds/wrd/api/aicm/v1/subject/0303200001/mandate/ 4. HTTP 400: /urds/wrd/api/aicm/v1/subject//mandate/ I use the "Dispatch Strategy: Script" with default response returning HTTP 404 Not Found, and the following validation script to check the path arguments and return the appropriate response: assert log log.info("Executing dispatch script...") assert requestContext def props = requestContext.getProperties() assert props log.info("Request arguments: ${props}") def subNr = props["subject_nr"] def credId = props["creditor_id"] if (subNr.empty || credId.empty) { // return HTTP 400 return "GET 400 Bad Request" } log.info("subject_nr: ${subNr}") log.info("creditor_id: ${credId}") def isSubNrMatching = subNr ==~ /^\d{10}$/ log.info("subject_nr RegEx match is: ${isSubNrMatching}") def isCredIdMatching = credId ==~ /^(ab|AB)(\d{2})([a-zA-Z]{3})(\d{8})(0{4})$/ log.info("creditor_id RegEx match is: ${isCredIdMatching}") def areReqArgsValidated = isSubNrMatching && isCredIdMatching if (!areReqArgsValidated) { // return HTTP 400 return "GET 400 Bad Request" } log.info("Request arguments validated: ${areReqArgsValidated}") // return HTTP 200 return "GET 200 OK" Now, the problem is: Main success scenario and alternative scenario a) work just fine (meaning: in both cases I get the expected response dispatched by the script). With the remaining scenarios b) and c), a response with HTTP status code 404 is dispatched instead of the scripted one (400). This response is apparently not the default 404 response I created andselected in the "Default Response" drop-down list (which features a JSON payload in the body), for its body is empty. Additionally, no log output shows up in the script (or error) log tab, showing clearly thatthe dispatch strategy script is not executed. Any clue about why is this happening? Am I missing something fundamental, due to my lack of product knowledge?Solved6 years agoPlace ReadyAPI QuestionsReadyAPI Questions6.4KViews0likes16Comments