Contributions
Re: Exclude Certain Steps from LoadTest Statistical Calculation in SoapUI Pro
I understand that if one to disable JDBC steps, the TPS values would correctly represent the service requests' throughput. However, the "err" columns then would lid up as all the assertions that match values between JDBC returned rows and Soap response fail which is not something I would like to show in the reports. I tried to run all the steps, then disable the JDBC steps and execute the load test, hoping that the records retrieved through this "manual"run would persist, and can be used in the load test. But, alas, the load test simply ignores them. P.S. JDBC steps have been marked distinctively, so identifying and disabling them is of no issue.9 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.6KViews0likes0CommentsRe: Exclude Certain Steps from LoadTest Statistical Calculation in SoapUI Pro
No, we are running the load test in SoapUI Pro. And, yes, we can temporarily disable JDBC steps and run the services, but there are two issues with that approach: There are a few dozen JDBC steps for some of these test cases. Enabling and disabling them is a daunting process which should be avoided. There are a few hundred assertions that depend on responses coming back from JDBC steps. Disabling the latter steps would result in stream of these failed assertions. I just need the load test calculation to ignore certain steps if possible and not to take them into consideration.9 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.6KViews0likes3CommentsExclude Certain Steps from LoadTest Statistical Calculation in SoapUI Pro
We have a mix of JDBC and service request steps in our test cases. I was wondering if we can have the statistical numbers only include the service requests so it won't affect TPS (transaction per second), and have JDBC steps excluded? We would still wish to run the JDBC to validate the assertions in the service request steps but just not include them as a part of the statistical calculation. Is there a way to accomplish this?9 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.7KViews0likes5CommentsRe: Authentications Were Removed While Migrating from SoapUI Pro to SoapUI NG Pro!
Tanya, After several conversations with some of the reps, this seems to be a known internal bug to the development team which has not been resolved in Ready! API 1.5. If you attempt to create multiple username outgoing-WSS entries, and have the requests set the authorization/authentication manually or via Auth Manager (new in Ready! API but not in SoapUI Pro), it always selects the first one from the list after the project is saved and reopened/reloaded (basically, it does not retain the appropriate Authorization entry for the test suite, test case (via inheritance), or request level). We have no other choice at this point to fall back to SoapUI Pro versions.9 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.3KViews0likes0CommentsRe: Authentications Were Removed While Migrating from SoapUI Pro to SoapUI NG Pro!
Hi Tanya, I created a new project and set a request's Auth, but upon saving, closing and reopening the project, Auth information is not retained. This lack of retainment of information only applies to Auth. I can create enviornment entries and perform other additions which do get saved. P.S. As I mentioned, no maintenence build or application can be installed at this point (client environment). I was just wondering if anyone else has run into this issue.9 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.4KViews0likes2CommentsRe: Authentications Were Removed While Migrating from SoapUI Pro to SoapUI NG Pro!
I just created a new project in SoapUI NG Pro, set Authorization to Basic with wssOutgoing for a request, executed the request, got an expected SOAP response, saved the project, reloaded/removed/reimported, and the Auth information does not get retained. Is this a known bug?9 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.4KViews0likes4CommentsRe: Authentications Were Removed While Migrating from SoapUI Pro to SoapUI NG Pro!
Unfortunately, client had to deactivate SoapUI Pro licenses in order to install SoapUI NG Pro on a new server, therefore, we are unable to create any SoapUI Pro specific project for comparison. (the servers are locked so no application can be installed, including a trial version in case if you are wondering) We are seeing that when we set the Auth manually, they are not retained when the project is saved and reopened. If we set the basic authentication, the requests work in the current session until project is closed and reopened, in which case, they do not retain Auth information! This is very troubling.9 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.4KViews0likes0CommentsAuthentications Were Removed While Migrating from SoapUI Pro to SoapUI NG Pro!
Our client has recently bought SoapUI NG Pro licenses and is trying to migrate our test scripts which were developed with SoapUI Pro to SoapUI NG Pro. However, when we attempt to import these projects into SoapUI NG Pro, all the Auth information are removed. If we open the raw XML project file, we still can see BasicAuthenticationTypes, outgoingWss="username", etc. for all the requests. Nonetheless, they are not being registered with SoapUI NG Pro. We have several thousands of these requests, and it would be a duanting task to set basic authentication for such volume of requests, specially that there are dozens of authentication aliases that need to be specifically set for each request. Is this a known problem, and is there a solution for it out there? Another issue that we are encountering is that, even if we set these Auth's manually and save the project, they do NOT persist!!! What is going on? Sincerely9 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.4KViews0likes7CommentsWS-I Tool Does Not Support Soap 1.2
Hi, I am trying to validate whether our WSDL's are WS-I compliance, but the tool bundled with SoapUI (and respectively SoapUI Pro) is from 2005 when protocol Soap 1.2 had not been introduced. This causes several assertions to fail in the generate report. If the Soap protocol version namespace is switched back to 1.1, the WS-I reports no error (we are not using any Soap 1.2 feature -- simply going by the requirements). The WS-I.org website offers a newer addition for the tool's profile, but it seems like it is simply an XSLT with no instruction as to how they need to be run (no Java run time jar). My question is, has anyone, or the SoapUI support team, gotten a WSDL WS-I validated when Soap 1.2 is used? Thanks.1.3KViews0likes2Comments