Check Out the Latest News About SmartBear Connect
New Idea
0 Kudos

Responce Time in log

Status: Selected for Development
by Chowdhary on ‎04-19-2016 01:40 PM

Now in soapui NG

2016-04-11 14:27:55                   response time: 227ms (833 bytes)



Feature to be added in SOAP Ui Ng


We want the responce as perfect in milli seconds, so that the reponce time will be exact.


2016-04-11 14:27:55:785           response time: 227ms (833 bytes)

0 Kudos

Improvements for property scoping

Status: New Idea
by dpasotti on ‎05-10-2017 06:43 AM

I just discovered here the source of my frustration and confusion over why my tests weren't passing: property scoping. I was trying to access a property defined in 'TestCase1' from 'TestCase2.' I understand why this should not be done and why this property should be stored or transferred at the parent TestSuite level, but I have several suggestions for improvement here:


1.) The main reason I used properties in this manner is that they were available to me using the "Get Data" feature. If properties are outside the scope of the current test step/case/suite, I would suggest adding some logic to the Get Data feature to make them unavailable for selection by the user.


2.) In the UI, this type of scoping rule is NOT enforced. This means that I can build my tests in SoapUI NG using this type of property reference across scope boundaries, and the tests pass. I then move these same tests to the Maven plugin and they fail, leaving me very confused. I would suggest making these types of "illegal" property references fail in the UI like they should according to the link above. That way a test developer knows upfront something is wrong before moving the tests to Maven or whatever the next phase may be.



David P.

Share APIs between projects

Status: Accepted for Discussion
by marcl on ‎11-23-2015 06:15 AM

We currently have around a dozen composite projects, which all use the same set of API. The reason we use so much projects instead of a single big one is for performance reasons.

When an API change (adding a new method, adding a parameter, etc) we thus have to update the API of each of the projects manually. We currently work around that by using symlinks, but this solution is clunky at best.


To prevent that, we would like some way to "share" the API definitions between multiple projects, having the API described in a single place and useable by all other projects.


The choosen solution should be compatible with version-control systems (e.g. something we can submit / check out), so any employee with a fresh computer can simply check-out the project(s) and start working without any extra configuration.

Status: Accepted for Discussion



this is an interesting idea, however I want to avoid having references across projects.

You write that one reason is performance, what number of APIs are we talking about?

I want to find out if there can be another way to solve this.


Best regards,

Matti Hjelm

Intellisense on custom groovy library

Status: New Idea
by runzTH on ‎01-29-2016 03:24 PM

Can we, and if so how, use something like intellisense on a custom groovy library?


So if we have created some utility functions and keep them in a script folder, or library, can we then reference those scripts and their methods intelligently from a groovy test step?

0 Kudos

Refactor Refactoring

Status: New Idea
by edweerdt on ‎05-02-2017 02:28 AM

The refactoring options tends to be rather messy:
soap refactor.JPG


It would be helpful when items/endpoints can be rearranged by hand. This would make it a much better tool and experience. 

0 Kudos

When selecting the statistics for a graphs view in LoanUI NG

I would like to specify also the color for each statistict

so that I can generate consistent reports

Actually if I rename test case in SoapUI (Ready API) then file name keep his name by creating.

And it is not possible to rename file name after creating, because filename will be saved in xml too.

Please fix this problem urgnet, because this leads to absolutly chaos in file structure.


Swagger: use body model when importing

Status: New Idea
by marcl on ‎09-07-2016 01:27 AM

When importing a swagger file which contains some body model, it would be good if R!API could use it to generate the corresponding REST request.


Basically, let's say I have a swagger "operation" with the following:

apis": [
        "path": "/example",
        "operations": [
                "method": "POST",
                "nickname": "handlePost",
                "produces": [
                "consumes": [
                "parameters": [
                        "name": "data",
                        "paramType": "body",
                        "type": "InsertionData"

And the InsertionData model defined like that:


models": {
    "InsertionData": {
        "id": "InsertionData",
        "properties": {
            "id": {
                "type": "integer",
                "format": "int64",
                "required": "true"
            "address": {
                "type": "integer",
                "format": "int32",
                "required": "true"



When I import this using Swagger, R!API will create a blank POST request with an empty body:



I would expect it to create a default body like this to the request instead:


0 Kudos

LoadUI NG Statistic/Monitoring Page

by bthomas on ‎09-01-2015 12:17 PM - last edited on ‎09-02-2015 01:12 AM by Community Manager

Need teh capability to rename each monitor in the monitioring & statis page page rather than using the default.


The problem here is when you have multiple servers and each of them have the same monitors - you have no way of telling which monitor was for which server

Please make the left navigation panes remember their hidden/visible status between sessions.  Most applications remember these types of settings, and it is a shortcoming in Ready! API.


This should include settings for all items in the View menu.  Currently, none of them remember their settings between sessions.


It's more user friendly to have these panes remember this settings.  Otherwise, if someone wants View settings that are different from the default, they have to manually re-set them after ever restart of Ready! API.  (e.g. The new API Navigation pane--since it uses a lot of space and causes issues with pushing the Properties pane off the screen, so I have to repeatedly manually hide it now).

Hi There,


It would be great if we could apply the following assertions to requests:

  • JSON Schema Compliance
  • Swagger Compliance Assertion

The documentation around these assertions is a little conflicting as it states "Asserts that the request and response messages are compliant with a swagger definition" currently, however the implementation seems to be limited to responses only.


It's quite a normal expectation that the request body for operations like PUT, PATCH, POST could be validated for compliance. Sames goes for other operations, query parameters, headers etc.


We are using Service-V for API sand-boxing and ideally we should facilitate that we can act like the API provider and can easily validate requests and give appropriate responses as defined in the swagger definitions without having to script all the validations by hand.


Any thoughts on this? Can you consider this enhancement? I am convinced that any customer offering REST APIs levering Swagger / Open API etc would assume such capabilities are possible for requests as well as responses.


Kind regards,


Hi, it would be nice if Data Sources can be used for the whole project. Right now it is limited to the test case level.

Clear saved history, disable saved history

Status: New Idea
by mbheeke on ‎10-27-2015 08:01 AM

Ideally, an option where user could selectively clear history for specified test case(s) / suite(s) would be nice.  


Option to save (or not save) the history could be a checkmark on test case options ... that way you could proactively stop the collection of the history on a test case by test case basis. 

0 Kudos

Resizable request selector

Status: New Idea
by edweerdt on ‎02-17-2017 02:39 AM

When working with test cases I need to select different requests a lot of the time. Currently the request selector is very small and only shows a small part of a request name making it a guessing game. Both fields on the left and right resize with the screen. In my case creating unused whitespace.



Request selector.JPG

0 Kudos

Sort endpoint in alphabetical order

Status: New Idea
by ksmith_smc3 on ‎02-20-2017 09:32 AM

When going to manage endpoints to a test step, the endpoints are listed in alphabetical order. When pressing the "URL" button to set your active endpoint though, they are listed in a seemingly random order.


We have some projects with 50+ endpoints, and the random order makes it difficult to quickly find the endpoint for which you are looking. Having these sorted alphabetically would be wonderful.


FYI: I contributed a fix for this to the opensource SoapUI project on GitHub:

0 Kudos

Drop down for Report Type

Status: New Idea
by Staff on ‎03-20-2017 02:17 AM

Hi ,


Many customers have had issues creating reports for Secure Pro and this is mainly due to spacing.


Could we add drop downs for the Report Type and Format field to avoid such issues.


If they mistype the Rerport Type there is no errors sent to the screen and the report simply does not generate.


secure Pro screenshot.png



Laura Kennedy

Smartbear SE

Auto start Virt on VirtServer startup

Status: New Idea
by LoundesM on ‎03-04-2016 01:35 AM



Can we get a mechanism to auto start virts when a VirtServer starts up,

if you're using a Large VirtServer at capacity the task of manually starting each applicable virt in turn is going to be somewhat tedious



a setting within ServiceV alongside or in the general Virt 'Info' section with a checkbox for 'Auto start with VirtServer'

then if the flag is set and the virt is deployed if VirtServer is stopped and restarted (sys reboot for example) the Virt would not need human intervention to restart it


an overall view would also be highly beneficial especially if it could also configure the flag whilst deployed


within the VirtServer panel in ServiceV where we can view the active Virts and Metrics etc, a view of all deployed virts and their auto start flags with the ability to switch on/off the flags (in a similar way the rows of data in a datasource can be switched on or off)




0 Kudos

Currently test case run steps don't allow you to add assertions on the returns from those test steps, resulting in having to create separate extremely clunky 'Assertion' steps to assert that the data returned is what you expect when running flexible test cases.


eg. Say you want to run a test case to determine the status of something and the status is returned. That status may be different depending on the test case. You should be able to assert on the returned parameters INSIDE of that testcase run step.

0 Kudos

Automatic Environment Selection

Status: New Idea
by Debz on ‎05-03-2017 10:03 PM

Hi, it would be nice to have Automatic Environment Selection when running the test using Jenkins. I thought I was just missing on something (a setting maybe), but as @raiqee mentioned, this seems to be an open issue. There is no formal fix posted but a workaround she found is to save the project at SoapUI with the environment you want to run on Jenkins as the active one before running the test. Otherwise, you will encounter an Oracle Error (missing expression) when running the test via Jenkins but not when you run the test using SoapUI directly. Please see the following threads:

ReadyApi 2.0 - GetData resizeable

Status: New Idea
by kber on ‎05-10-2017 01:59 AM

With the release of ReadyApi 2.0 GetData behavior was changed and we are NOT impressed.


  1.  Font size is set and unchangeable
  2. Column width is set and unchangeable


This means that ANY TestSuite, TestCase etc. with names longer than 16 characters all look a like, making it impossible to be efficient as new functionality forces us to MouseOver to be able to find the correct TestCase name.


Please at least make the GetData Columns resiazeable, so we can see the names of our TestSuites and TestCases again!


See attached file.