Forum Discussion

chuddy12345's avatar
chuddy12345
New Contributor
11 years ago

How to log requests in a mock service

Hi there,

I have created a mock REST web service which will listen for requests.

I am using SoapUI 5.0.0.

When I open up the mock service I start it and can see the "knight Rider" progress bar thing which goes back and forth to say that the service is running...

I have also checked the "Enable" box so I can see the time, date and response time for each request that hits the mock service.

In older versions of SoapUI there use to be an option to actually audit the actual content of the request that comes in.

I could double click on one of the log entries and a box would open up with the content of the request.

Nothing happens when I double click this in 5.0.0... any ideas how this can be switched back on?

Thanks for help!

Chuddy12345
  • It's possible to log request by using "OnRequest Script" option in Mock Service Editor (I am using version 5.2.1)

     

    Put following code in above option and the request content should be visible in "Script Log"

     

    log.info(mockRequest.getRequestContent())
  • atulb's avatar
    atulb
    New Contributor

    It's possible to log request by using "OnRequest Script" option in Mock Service Editor (I am using version 5.2.1)

     

    Put following code in above option and the request content should be visible in "Script Log"

     

    log.info(mockRequest.getRequestContent())
    • jamescollett's avatar
      jamescollett
      Contributor

      This is exactly the problem I have and the same version of SoapUI that I am running (5.2.1). I was overjoyed to find this post, but I cannot get the solution to work for me.

       

      When I slavishly added the line

       

      log.info(mockRequest.getRequestContent())

       

      to the "OnRequest Script" box in my REST MockService editor, first of all it seemed to object to the syntax by highlighting one of the brackets. So I added a semi-colon at the end to make it read as follows:-

       

      log.info(mockRequest.getRequestContent());

       

      The highlighting disappeared, so I figured that was a good move.

       

      When I ran my mock service and threw a request at it, still I was unable to inspect the request contents wit the double-click on the entry in the Message Log.

       

      Am I being daft here? Is the word "mockRequest" a key word or do I have to replace it with the specific name of my request (in which case which name would that be)?


      Also, I have a "Message Log" exposed in my running mock service; where is the "Script Log" which you mention? If you mean the "script log" button at the foot of the SoapUI IDE, this just shows entries which look like this:-

       

      Fri Feb 16 17:39:28 GMT 2018:INFO:null

       

      The "http log" appears to record, in a very raw form, the incoming request; but it does this whether or not I include this recommended line of script code above.

       

      So I am still baffled.

       

       

  • JHunt's avatar
    JHunt
    Community Hero

    There seems to be no 'message log' for REST like there is for SOAP - I don't know why that is.

     

    Regarding this workaround, all it does is to put the message body into your script log.

     

    It's only the message body, so that could easily be 'null' for things like GET requests, which usually don't have any message body. If you need to see more, such as the headers, you can log those too:

     

     

    log.info "--Headers--"
    mockRequest.requestHeaders.each {log.info it}
    log.info "--Body--"
    log.info mockRequest.requestContent

     

     

    You should also be aware that there is an issue with other request types, like PUT and DELETE, where for some reason the request body is not available by the above method, and you will always get null. If I recall from when I looked into it, this was a bug with the Jetty webserver, not in the SoapUI code... but there is a workaround for this... (my version is based on kjdivya's post  here: https://community.smartbear.com/t5/SoapUI-Pro/Mock-Service-mockRequest-requestContent-is-NULL-HTTP-PUT/td-p/42138):

     

    import com.eviware.soapui.impl.rest.RestRequestInterface.HttpMethod
    void fixIfPutOrDelete ( mockRequest ) {
    	if ((mockRequest.method == HttpMethod.PUT) || (mockRequest.method == HttpMethod.DELETE)) {
    		InputStream is = mockRequest.request.inputStream
    		BufferedReader br = new BufferedReader(new InputStreamReader(is, "UTF-8"));
    		StringBuilder sb = new StringBuilder()
    		while ((s=br.readLine()) != null) {
    			sb.append(s)
    		}
    		mockRequest.requestContent = sb.toString()
    	}
    }

    See the attached screenshot for how I put the two together to see the incoming requests.

     

     

     

    • jamescollett's avatar
      jamescollett
      Contributor

      Thanks to JHunt for that. This is such weird syntax. It gets me a bit closer to seeing the request, although it's the query string that I was hoping to expose.

       

      I see that two slightly different function calls have been suggested for the same thing (by different posters), namely:-

       

       

      log.info(mockRequest.getRequestContent())

       

      and 

       

      log.info mockRequest.requestContent

       

      Why the different syntax? Is one of them wrong or are they equivalent?

       

      Thanks.

       

  • JHunt's avatar
    JHunt
    Community Hero

    They are the same. It's groovy syntax.

     

    If a method name starts with 'get' and takes no parameters, then you can reference that method as if it were a property:

     

     

    this.getThing() == this.thing
    
    this.getThing(a)
    
    // this.thing(a) -- not allowed...
    -- ... but this.things[a] is possible with some classes

     

     

    Parentheses can be omitted for parameters when calling at the top level:

     

     

    log.info("Hello world")
    
    log.info "Hello world"
    
    log.info getThing(a)
    
    getThing a

    getThing(a,b)

    getThing a, b //log.info getThing a -- doesn't work