Forum Discussion
19 Replies
- joshcachoOccasional ContributorHi. I originally entered this issue and they emailed me yesterday indicating the problem was fixed in the nightly build. I haven't had time to try it yet but that is what I will be doing today. Hope this helps. I just rolled back to the previous version, 1.7 in the meantime.
- AntonESmartBear Alumni (Retired)
Yes, we got back to how things were in 1.7: both Request and RawRequest properties contain request body, Request with property expansion expressions and RawRequest with already expanded values, exactly as it was sent. Please, download the nightly build if you had issues with them.
- AMANew Contributor
It seems to be working again, thanks!
- TanyaYatskovskaSmartBear Alumni (Retired)
Hi MicrobBO,
Sad to hear this. Could you please contact our Customer Care Team and send them your project (or at least an XPath expression you use)? They will investigate this behavior. You can reach out to them here:
http://support.smartbear.com/product-list/
- joshcachoOccasional Contributor
Hi All,
I have the same problem. Some of my input SOAP requests were input with RawRequest everywhere after updating to 1.8 and my Property Transfers which use Raw request as the "From" can't get transferred to the "To." Keep getting this dam Unexpected Element: CDATA. Everything was working before nicely but after I updated everything went to crap honestly.
Please fix this or let us know if we can roll back to a previous version. I tried rolling back to a previous version and it still didn't work.
Thanks,
Josh
- joshcachoOccasional Contributor
I have the same problem but also even more severe. Property Transfers not working for Raw requests anymore. So bad. Hoping for solution quickly. Being down or having no way to rollback to previous version is not working either.....
- TanyaYatskovskaSmartBear Alumni (Retired)
Hi All,
In Ready! API 1.8, we have improved the RawRequest property - now, it includes a request header. So, I suggest that you check XPath expressions you are using. As a new node for a header is added to a request, perhaps, your XPath became invalid. Please check this.
Refer to the following article to learn about the changes in Ready! API 1.8:
http://readyapi.smartbear.com/about/release_notes/latest/start
- microbBONew Contributor
Hi Tanya, in my case header doesn’t impact my request because I work with request body only. And this improvement doesn’t explain why when I try to create XPath expression through “Get Data” function by RawRequest property “Select Xpath Math” window didn’t open and expression like ${requestname#RawRequest} set
- lermimouOccasional Contributor
Hi,
I my requests, i have thousands of parameters like
<urn:transactionId>${#Project#transactionId}</urn:transactionId>
So i can't use the request to retrieve the parameter.
I needed to use the rawRequest to have the parameter filled.
It's not possible to me to switch all parameters like
<urn:transactionId>${#Project#transactionId}</urn:transactionId> to a propertyTransfer in the request.
Please, how can I do?
- lermimouOccasional Contributor
For Example, this is my request.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="http://urn:MEWSUserPref">
<soapenv:Header/>
<soapenv:Body>
<urn:HelloWorld>
<urn:in0>hello${#Project#timestamp}@test.fr</urn:in0>
</urn:HelloWorld>
</soapenv:Body>
</soapenv:Envelope>In the assertion, i compare a parameter to the in0 request parameter
declare namespace ns1='http://urn:MEWSUserPref';
//detail[1]/ns1:MEServiceException[1]/ns1:in0[1]${myTestCase#Request#declare namespace urn='http://urn:MEWSUserPref'; //urn:setFilterSettings[1]/urn:in0[1]}
With this method, everytime i launch the assertion, a new timestamp is generated, due to the dynamic parameter.
I need to check the parameter sent in the request so i used the RawRequest
${myTestCase#RawRequest#declare namespace urn='http://urn:MEWSUserPref'; //urn:setFilterSettings[1]/urn:in0[1]}
In this case, the parameter is always the same in the assertion.
The same problem appears with propertyTransfer steps. The Request option transfers the ${#Project#timestamp} instead of the timestamp generated in the request.
How can i check these cases without the rawRequest?
- AntonESmartBear Alumni (Retired)
Thank you for clarification, now I see the problem. I think this is a bug and Request property should have the value of the property, not a property expansion string, but we need to discuss this with the team.
However, I tried to use Request property in XPath and Groovy assertions and it seems to be expanded automatically, so assertions pass. I used property expansion string as an expected value, but assertions definitely expand it - you can check, just use wrong expected value and check the actual value in the error message). What type of assertion do you use? Where do you generate timestamp property?
- AMANew Contributor
- lermimouOccasional Contributor
Hi,
Thanks for your answer.
I defined my property in the project custom property with this value :
${=new java.text.SimpleDateFormat("yyyyMMddHHmmssSSS").format(new Date())}
So everytime i used this property, a new timestamp is generated.
I aggre with you, the property expansion expand the property in the assertions but a new value.
I hope this bug will be fixed asap.
- AntonESmartBear Alumni (Retired)
And what do you use as an expected value in the assertion? Property expansion will get a new value every time assertion is checked, no matter how actual value is formed.
- lermimouOccasional Contributor
the expected value is the value of the request parameter filled the dynamic property filled
example:
<urn:in0>hello20160726113826130@test.fr</urn:in0>
That's why i need the real value sent in the request (actually, only accessible through the rawRequest)