Contributions
Re: Project that works in SoapUi 4.6.1 fails in SoapUi
Yes, thank you very much. I suspected it had something to do with a different version of WSS4J, but I would not have been able to quickly pin it down to that jar. I replaced xmlsec-1.4.5.jar with xmlsec-1.5.8.jar in the SoapUi installation lib folder, and that solved the problem as you described. I appreciate the help very much. Regards -- Andy3.1KViews0likes1CommentProject that works in SoapUi 4.6.1 fails in SoapUi
I have a SoapUi project from 4.6.1 that uses WS-Security to connect to a Apache CXF 2.3.1/JBoss6 SOAP web service. The SSL global preferences are set with a certificate that gets through our proxy, then the WS-Security configuration references a keystore containing the same SSL certificate and a truststore with the public key of the server. The requests must be timestamped and signed. The responses are timestamped, signed (the timestamp Content and the Body element), and encrypted (Body content). In SoapUi 5.2, when I load this project and submit a request, I get back an 200 response and then an error message that says "Error getting response for ... ;null" In the http log I see the headers of the response and then what looks like the entire response encrypted. I see no errors in the "error log". For grins, I went into the WS-Security "incoming" configuration and flipped the values for the decrypt and signature keystores around, my client.jks and client-truststore.jks, respectively. When I did that, I no longer got a "null" response, I see the Soap envelope, but the soap:Body contains a <xenc: EncryptedData" element. I also get a WSSecurityException in the error log saying that "The signature or decyrption was invalid". The root cause is: Caused by: org.apache.ws.security.WSSecurityException: The keystore is null at org.apache.ws.security.components.crypto.Merlin.getPrivateKey(Merlin.java:639) at org.apache.ws.security.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:141) So, obviously, something has changed in the way I should be configuring SoapUi. The last go around with SoapUi 4.6.1, it seemed to take forever before I settled on a WS-Security configuration that worked. Any suggestions? Thanks.Solved3.1KViews0likes3CommentsRe: [Resolved] How can I modularize/do this better?
Another Followup: But, inexplicably (to me), the same SoapUi tests will NOT work properly when I try to incorporate them into a JUnit test, so they work in the SoapUi, but do not work when I try to run them using SoapUiTestRunner. Which pretty much scuttles the whole idea of doing them this way and using them in integrated test cases.999Views0likes0CommentsWS-Security worked in 4.6.1 does NOT work in 5.0.0
So, I have a series of SOAP web service projects that use WS-Security to timestamp and sign the request, then decrypt the response. These work in 4.6.1. Today, I downloaded Soap x64 5.0 and the same projects fail. I see the request hit the server, I see the response generated, I see the encrypted response in the HTTP log. However, the test request says "Error getting response; null". So, I have tried deleting the project and reimporting it, I have tried editing the WS-Security configuration, same results. What could have changed? I go to the SoapUi web site to the page that announces the new release. I click on the link to "read more", which takes me to an article which essentially lists the same three features and a link to "read more". When I click on that, I get a 404 that flashes up in the top of the screen, but I am on the same first page I was at, just going in a loop. I search the forums for "WS-Security" and apparently that phrase has never appeared in any of the forums, which isn't true of course.795Views0likes0CommentsRe: Does Sourceforge accurately show the status of old bugs?
This forum, right? Besides the sourceforge defect at http://sourceforge.net/p/soapui/bugs/493/ it appears like it has been reported a couple of times in this forum already: http://forum.soapui.org/viewtopic.php?t=7681 A similar bug was reported fixed in 2009. The problem is occurring with the list of object inside the payload complex type: <xs:complexType name="payLoad"> <xs:sequence> <xs:element minOccurs="0" name="responseInfo" type="tns:wsResponseInfo"/> <xs:element minOccurs="0" name="payLoadList"> <xs:complexType> <xs:sequence> <xs:element form="qualified" maxOccurs="unbounded" minOccurs="0" name="payLoadObject" type="xs:anyType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> There is no problem if the list contains one of the complex types defined in my target namespace. The problem occurs when I try to return a String. In the response, it looks like this: <ns2:payLoadObject xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">Test of the WS-VTA Web Service</ns2:payLoadObject> and this fails schema validation with the error: "Invalid xsi:type qname 'xs:string' in element payLoadList". If I edit the response to delete the xs and xsi namespace declaration attributes from the payLoadList element, it succeeds.10 years agoPlace ReadyAPI QuestionsReadyAPI Questions896Views0likes0CommentsDoes Sourceforge accurately show the status of old bugs?
Because, this one seems to match exactly a problem that I am encountering (copied and pasted from Sourceforge) 493 schema compliance xsi:type="xs:string" None open 2009-09-29 2009-09-29 5 Which is that I am failing schema validation in SoapUi when I try to return a String in a list of anyType. If I edit the response and remove the xmlns declaration attributes for xs and xsi, it validates successfully.10 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.8KViews0likes2CommentsRe: Dynamic Schema Compliance Assertions?
Ok, so I noticed that the "default" properties for the test steps in my "modular" test case are set to a specific WSDL operation: the one that I used when I initially created them, before I "modularized" it. I see that this "Operation" parameter cannot be edited directly in the "Properties" pane, like many of the other default properties. From the "Navigator" pane, I can select the "Change Operation" command from the context menu. So, I am guessing this is why my Schema Compliance assertion is validating the response against the wrong WSDL operation. Is there a way to change the "Operation" default property of a test step programmatically?874Views0likes0CommentsDynamic Schema Compliance Assertions?
So, I have a test case that I original created step by step. On the steps that send requests, I originally added some Schema compliance assertions. This is my "modular" test case. Once I had the thing set up the way I wanted, I then added some test case properties to "parameterize" the test case passing in the names of the operations I want to invoke. I then call this test case from another using the "Run TestCase" test step. My modular test case setup script then rebuilds the request to hit the operations I passed in. The schema compliance assertions fail because it is looking for message parts for the request that I used when I was originally creating them; i.e., it does not look at the modified request that was actually sent and validate the response against that. It validates against the hard coded request I used when I was originally creating this "modular" test case. What's weird is that, even if I pull that test step up, delete the schema compliance assertion, and re-add it, it still wants to use the original value, even though the request has already been changed. Thinking that perhaps this is because it's working off something cached (which has bitten me more times than I care to list), I even save the project, close it, open it back up, and try to delete/re-add the schema compliance assertion. But it still fails, looking for the response to the original operation. I don't get it. I see nothing to configure on these "Schema Compliance" assertions, other than the URL of the WSDL to validate against. But, obviously, they retain some other information from the time when they were created. Is it possible to do this dynamically?1.3KViews0likes1CommentRe: [Resolved] How can I modularize/do this better?
Not that I expect any replies, but I thought I would share my progress on this in case it might help someone else: I copied those ten steps described previously to a separate test case. I then added two test case level properties, one to define the operation to be invoked for the extract and one for the fetch. Initially, I tried expanding these properties in the requests. However, I ran into a peculiarity: anywhere else in a groovy script where I used an XmlHolder and tried modifying the requests I would then get an error when the "$" character was encountered. Consequently, I was forced to eliminate all property expansions and do everything with Groovy scripts. I do wonder if this is a known limitation: when you have properties in a request, e.g., ${myProperty}, you will always encounter this error, or is there something I'm not doing correctly? So, now I have a startup script that uses DOM to delete all existing nodes under the <body> tag of the request and then rebuild it using the operations specified in the properties. The original test case now contains a "Run TestCase" step where it sets up the properties, and then runs the new test case to initiate the extract, poll it until done, find out how many chunks are available, and then iterate through them fetching all chunks. One other problem is that my original "Schema Compliance" assertions are failing because it expects the response for the operation I used when I create them initially. So, I disabled them, and next I will have to see if they can be dynamically created when the module is invoked with a particular set of operations. But, the goal of not replicating all these steps for every pair of extract/fetch operations has been accomplished. All I have to do is add similar "Run TestCase" steps for each web service operation that follows this pattern.999Views0likes0Comments[Resolved] How can I modularize/do this better?
I have a bunch of web service operations that follow a similar pattern. A request is made to one operation to initiate an asynchronous extract. It returns immediately with a "requestId" assigned. Every operation, regardless of the data it is extracting, follows this same pattern, returns the same status info. Then, we call another operation using that requestId as a parameter. We also can include a "chunkNumber" parameter, which is to identify which "chunk" of the results is to be returned. For example, if we have a total of 95 records extracted, and the chunkSize is 10, then there would be 10 "chunks" available for download, 1 through 10, with the last chunk containing only 5 records. If we pass in a chunkNumber that is 0, then we do not return any of the results extracted, we simply return the status metadata about the request: whether it is pending, completed, inprogress, etc., the number of rows extracted if it is completed, the number of chunks available, the chunkSize, etc. So, to setup a SoapUi test suite for one of these operations, I have the following test steps: (1) RequestData (2) Xfr Requestid from (1) to steps (3) and (8) (3) GetData for chunk 0 for the request. (4) Delay (5) Conditional: Repeat until NOT PENDING or INPROGRESS (check the status returned in 3, go back to 3 if it is not completed or in error) (6) Groovy Script: dumps out the status info and does a goto step (10) if there are no results (7) "initChunkNumber" Properties Step: define "chunkNumber" property set to 1 (8) GetData for chunk ${"initChunkNumber#chunkNumber} (9) Groovy Script: gets the chunkRequested in (8) and if < chunkCount increment the chunkNumber, update the property in (7), GOTO (8) (10) Print out a "Finished Message" So, I'm pretty sure that all of this could be condensed into a single Groovy Script test step. I would like to know how to do that, but I am having problems with how to iterate a test step varying some request parameter, all in script. Seems like it should be a common use case, so if someone can point me at an example, I'd appreciate it. Ideally, instead of having to do this for every pair of request/get operations, I would like to be able to modularize this so that I could pass in a requestId, maybe pass in either a test step, or the operation to perform, and have this same functionality of hitting it until it is done, then iterating through all of the chunks to be retrieved. Is that possible?1.4KViews0likes3Comments