Contributions
Re: Accessing Project Properties from a Groovy script (NOT Custom Properties)
Aha! Found it in another community post... def myPath=testRunner.getTestCase().getTestSuite().getProject().getPath() works. Source:https://community.smartbear.com/t5/SoapUI-Pro/How-to-get-the-name-of-the-soapui-project-file/td-p/1294684.9KViews0likes0CommentsAccessing Project Properties from a Groovy script (NOT Custom Properties)
Hi all, How can I read in the value of a non-Custom Project Property from within a TestCase-level Groovy script? Specifically, I need to get hold of the value of the read-only 'File' property which contains the location of a soapUI project file. E.g. for a soapUI project called 'mySoapServiceTests'... I guess the solution might look similar to this which works fine for getting Custom Properties (but not Project Properties): def projFilePath = testRunner.testCase.testSuite.project.getPropertyValue("File") I've trawled through the class doc and various posts and blogs etc. but they all seem to only cover getting and setting Custom Properties. I also don't need to put this value into a SOAP or other request using ${#Project#xxx#} or similar, I just need to get the value into a variable in my Groovy script. Kudos to whoever can first tell me how to do this :smileyhappy:Solved5KViews0likes2CommentsRe: Using 'any' types in WSDL seem to confuse the MTOM mechanism
The problem is also in version 4.6.4, so still no fix. I'm not sure that this forum is an effective way to get in touch with SMARTBEAR support (without any kind of paid agreement in place). Our workaround still seems to be the only option for each of the 'any' schemas which we now have. Manually modifying the WSDL every time for each different 'any' isn't really what we want though, also because it's forcing us to split up the test cases when we'd prefer to keep them together.10 years agoPlace ReadyAPI QuestionsReadyAPI Questions1KViews0likes0CommentsUsing 'any' types in WSDL seem to confuse the MTOM mechanism
Hi We see this problem in both of: - soapUI 4.5.1 - soapUI 3.6.1 under Windows7 SP1. We want to test a SOAP over HTTPS service which expects MTOM attachments in one WSDL field, either a TIF or an XML file. It's a repeatable field so there can be multiple TIF and XML attachments in the final request. Elsewhere in the WSDL there is an 'any' field. This lets us insert a data structure of another complex type, we have one called OrderData which has levels of structure such as Person, Address, OrderInformation etc. Fields under those levels are mostly simple string fields such as firstName, name, street and city. There are also non-string fields, e.g. a Person/birthday has type date. Essentially this: <OrderRequest> <Header> ... </Header> <Body> <Content> (any) </Content> <Documents> <Document> <docId>cid:file.tif</docId> <docType>...</docType> ... </Document> </Documents> </Body> </OrderRequest> with these straightforward string fields included in 'Content': <OrderData> <Person> <firstName>Sherlock</firstName> <name>Holmes</name> <!--birthday>1854-01-06T02:21:02</birthday--> </Person> <Address> <houseNr>221b</houseNr> <street>Baker Street</street> ... </Address> ... </OrderData> The expected MTOM attachments get generated ok but the problem is that EVERY field used inside the 'any' structure somehow also seems to get treated as an MTOM reference, even though they just contain normal stuff such as "Sherlock", "Holmes" and nothing like 'cid:xxx' supposedly linked to an actual attachment. We see separate MIME attachments for each firstName, name, street, etc! Every filled OrderData field is affected. Worse, at the receiving side, each field's content has been changed to base64 binary, so all of our OrderData values are no longer human-readable. Non-string fields also get converted: if we try to fill the dateOfBirth date field with a valid date, the receiving service throws an exception as it can't parse the new mangled base64 binary content against the WSDL schema. This is what we see under the 'Raw' tab after sending the request: <typ:Content> <ns1:OrderData xmlns:ns1="http://www.xxx.com/2013/xxxxxxx/Order/DataTypes"> <ns1:Customer> <ns1:Person> <ns1:FirstName><inc:Include href="cid:http://www.soapui.org/271853968957230" xmlns:inc="http://www.w3.org/2004/08/xop/include"/></ns1:FirstName> <ns1:Name><inc:Include href="cid:http://www.soapui.org/271853969235906" xmlns:inc="http://www.w3.org/2004/08/xop/include"/></ns1:Name> </ns1:Person> ... <ns1:Customer> ... and this is what arrives at the service which receives the request: <ns1:OrderData xmlns:ns1="http://www.xxx.com/2013/xxxxxxx/Order/DataTypes"> <ns1:Customer> <ns1:Person> <ns1:FirstName>U2hlcmxvY2s=</ns1:FirstName> <ns1:Name>SG9sbWVz</ns1:Name> </ns1:Person> <ns1:Address> <ns1:HouseNr>MjIxYg==</ns1:HouseNr> <ns1:Street>QmFrZXIgU3RyZWV0</ns1:Street> ... </ns1:Address> ... <ns1:Customer> </ns1:OrderData> All other fields which were not inside the 'any' arrive ok, i.e. those in 'Header' or 'Document' all have their original unchanged content. Setting the 'enable MTOM' property to 'false' fixes the 'any' fields but then we can't attach our MTOM TIFs and XMLs to our test request in soapUI. Is there some property we should be setting to stop this from happening? As a workaround so that we can keep on testing our service, I'll change the soapUI concrete WSDL to have the OrderData structure in-line without the 'any', this should work but it means that we're not testing the actual service WSDL (which we're not able to change). It also means we'll have to create a new in-line workaround WSDL each time a new 'any' structure is introduced. There will be many of these, so it's not a viable longer term solution. I've played around with the properties but couldn't find anything to fix this. Any help in resolving this appreciated, thanks!11 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.5KViews0likes2Comments