Response XML tab encoding
Hi, Ive got some troubles with readyAPI not correctly encoding responses in XML tab. Dont know if its some setting I have, but on similar requests Im getting different results in response XML tab. First of all I cloned whole SOAP test case (old one) and replaced old services with new ones. Here is one example of what Im dealing with. In old test case Im still getting same result in response xml tab (no matter how I run it): <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Client</faultcode> <faultstring> APP-002 : Chyba při zpracování, duplicitní údaj v požadavku (AgendaZadostId='b1e43723-54f7-447e-8d62-ed1ab98d24d7'). <!--ISZRZadostId=b1e43723-54f7-447e-8d62-ed1ab98d24d7--> </faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> <!--SERVER: TP-ISZR1APPO101--> <!--CERTIFICATEID: [3b:c6:01:57:00:02:00:00:0e:3b]--> <!--UUID: [78004a1c-6a38-1416-9628-1af38a530000], RAW:[1C4A0078386A161496281AF38A530000]--> <!--TotalTime: 00:00:00.0781195, in ms: 78.1195--> <!--DbTime (all in ms) - total: 46.8883, external: 46.8883, internal: 0, extCommit 0, intCommit 0, CWeb = 15, CWin = 0--> <!--WinService (all in ms) - total: 0, ZR: 0--> <!--Remoting: DIFF: 0 ; total: 0, winservice: 0--> <!--CodeTime: 31.2312 ; celkem: 78.1195, Proc: 39.9787505040355--> <!--OMO: 15.6112--> If I run my cloned test case with new services in test runner I get: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Client</faultcode> <faultstring>APP-002 : Chyba při zpracování, duplicitní údaj v požadavku (AgendaZadostId='02de5978-035e-4d5f-b89e-da520085aba9').<!--ISZRZadostId=c125d058-6a2f-1416-9927-173b688b1000--> </faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> <!-- SERVER: TP-ISZR1APPO101 --><!-- CERTIFICATEID: [3b:c6:01:57:00:02:00:00:0e:3b] --><!-- UUID: [4ab6460c-6a32-1416-9927-1cc57fd37000], RAW:[0C46B64A326A161499271CC57FD37000] --><!-- TotalTime: 00:00:00.0468721, in ms: 46.8721 --><!-- DbTime (all in ms) - total: 31.2513, external: 31.2513, internal: 0, extCommit 0, intCommit 0, CWeb = 15, CWin = 0 --><!-- WinService (all in ms) - total: 0, ZR: 0 --><!-- Remoting: DIFF: 0 ; total: 0, winservice: 0 --><!-- CodeTime: 15.6208 ; celkem: 46.8721, Proc: 33.3264351287866 --><!-- OMO: 0 --> And if I run this specific test step individually I also get correct response (as the old one): <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Client</faultcode> <faultstring> APP-002 : Chyba při zpracování, duplicitní údaj v požadavku (AgendaZadostId='02de5978-035e-4d5f-b89e-da520085aba9'). <!--ISZRZadostId=c125d058-6a2f-1416-9927-173b688b1000--> </faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> <!--SERVER: TP-ISZR1APPO101--> <!--CERTIFICATEID: [3b:c6:01:57:00:02:00:00:0e:3b]--> <!--UUID: [5798b974-6a5d-1416-9461-1780ea3fd000], RAW:[74B998575D6A161494611780EA3FD000]--> <!--TotalTime: 00:00:00.2499951, in ms: 249.9951--> <!--DbTime (all in ms) - total: 109.3706, external: 109.3706, internal: 0, extCommit 0, intCommit 0, CWeb = 15, CWin = 0--> <!--WinService (all in ms) - total: 0, ZR: 0--> <!--Remoting: DIFF: 0 ; total: 0, winservice: 0--> <!--CodeTime: 140.6245 ; celkem: 249.9951, Proc: 56.2509025176893--> <!--OMO: 124.9964--> Any ideas where could be the problem? As you can see the response isn't formatted as well - when I do format it after test run, everything fixes. But I don't want to do that manually, because I also need to export these responses for customer reports. Thanks for your help, M
Have anyone tried soapui 5.6.0 with xmlbeans 5.0.3
The soapui 5.6.0 is dependent on xmlbeans "3.1.1-sb-fixed" which appears a customized xmlbeans version. In a unique situation where our web application would also use another library that needs xmlbeans 5.0.3. But the problem is obvious and we can't have two versions of xmlbeans in the classpath or we have runtime issues finding the appropriate binaries. If we carefully modify the soapui src to use xmlbeans 5.0.3 would we be OK? Trying to see if someone else ventured this route. Thanks Kalyan
Support for java 17 using SoapUI-maven-plugin.
Hi! Can you please tell me how could it be possible to use SoapUI-maven-plugin with java 17? I would like to use it on Jenkins, and I cannot install java 16 in Jenkins... because it runs on AWS and all my other tests (Selenium) are running on Java 17. While I tried in maven to use maven-compiler-plugin with release version 16, it throws an error that a groovy script cannot be run because of unsupported class file major version 61. On my local SoapUI works as expected with java 17, but the soap plugin no.
How do i fix the CVE-2019-12180?
I need to know if CVE-2019-12180 has been fixed in the latest versions of SoapUI. All the sources I have searched explain that the CVE is reported in version 5.5 of SoapUI, but none of them clearly state whether the vulnerability has been fixed in version 5.7.x. If it is not officially fixed, how could I mitigate this vulnerability? CVE-2019-12180 : An issue was discovered in SmartBear ReadyAPI through 2.8.2 and 3.0.0 and SoapUI through 5.5. When opening a project, th (cvedetails.com)Webinar - Invest in your Testing: Evaluating Open Source vs. Commercial Solutions
Webinar - 12 June 10:00 EST & 13 June 14:00 AEST Invest in your Testing: Evaluating Open Source vs. Commercial Solutions This webinar will help you make an informed decision about your API testing strategy by exploring the true total cost of ownership (TCO) for both open source and commercial testing solutions, using SoapUI and ReadyAPI as an example use case. The session is designed to equip stakeholders invested in the success of their API testing initiatives with the knowledge to make an informed choice that aligns with business goals and technical requirements. Sign me up!
