soapui parameter equivalent to curl parameter

[tech321]

Hi, here is my curl command that generates data in excel sheet. 

curl --header "Content-Type: application/octet-stream" http://ipAddress:port/export --output myExcel.xlsx

I am trying to do the same in Soapui, and I do not know what to do with the "--output". Is there any equivalent to it in Soapui? Looking forward to an answer.

[richie]

Hey @tech321,

Your response is base64 encoded....is that still correct? Cos that will impact how you handle your responses.

Forum members are going to struggle to be able to answer your question properly because we arent going to know the info that is required. We would need more info as to the rest requests details.

Add "--verbose" to your curl request. This will return all the request and reaponse headers/raw data that will then steer the forum members and you in answering your query.

What happened with thr base64 encode from your previous post on the forum? Without knowing anything i'd suggest that you wouldnt need to do anything cos the output flagmerely indicates your response payload is .xlsx, so you dont need to do anything, however your Content-Type is for a binary file (so not just an .xlsx) and so im leaning towards the output being base64 encoded.

Rich

[tech321]

Thank you . please se those attachments. 

1- the encoded string that I need to decode

2- the groovy code I use

3- the generated excel file by the groovy code

4- the curl command with --verbose

[richie]

@tech321,

Ok...so what is the logged response for response2 in your groovy?
I suspect there might be problems because readyapi! isn't recognising your response as .xml.....the screenshot of the response you provided typically is generated when it hasnt been parsed by xml or json cos it isnt recognised as either of those. If the xml parser isnt recognising the response payload then xpath wont work.
Can you click RAW and XML tabs....can you provide screenshots please?

Also...im trying to remember...where did you get the requirement for xls?

Is it just a convenient form of output to your requests?

Can you do me a favour. Grab the base64 encode from your response and plug it into https://www.base64decode.org and run the decode? We need to know what the encoded data is actually. I assumed from your previous posts that the encode was of xls data, but that doesn't make sense to me.

Ta

Rich

[tech321]

I have attached screen shots as answers for your questions.

The logget response for response2 is just to strip the decoded string from tags as you can see in the scerrenshot.

I am not sure about your question regarding the requirement for xls. I want the output at an excel file, exactly the same way I, when I use curl. 

[richie]

@tech321,

The decode didnt work....you wouldnt expect a load of escaped nonsense in the decoded content if it had worked.

I was asking about thr spreadsheet cos i wondered if the encoded value included the .xlsx container or not.

You keep saying "i want it like i get it with curl cos its easy and straightforward" but what you need to appreciate is that readyapi!/soapui will do almost whatever you need for api testing as a consequence of its rich functionality, it enables the user to exercise so many different types of api, this means setup can be a lot more complicated in readyapi!/soapui.
[Disclaimer: no i don't work for Smartbear!]

On the decode webpage it says something like "for documents and binaries use the option further down the page" your stuff is of binary type (according to your Content-Type header).
As an aside. I think this is probably why your decode is failing!

Once youve run the decode successfully can you please take screenshot of the decoded binary?

I know this is tedious, but each time you give the forum more info, it answers a certain facet of your issue.

Nice one

Rich

[tech321]

I have attached a screenshot to be sure of what you are asking about. 

I have tried to save the decode file as xslx and then uploaded it and then decode it, and the result is a bin file which is still useless. 

My question here is, what is the expected format of the file name is? 

[richie]

Ok....we're not being efficient here and we're not making progress.

I'll describe what im trying to get at and hopefully then we'll progress.

Do you not have an api spec/interface design spec/requirements document that defines your REST request? This would tell us everything you need rather than this repeated back and forth we've got going at the moment.

Anyway, you raised another post on this forum and you mentioned base64 encoding.
The Content-Type header of your response indicates its a binary file (so thats consistent with some sort of encoding)
Where did you get the idea the contents are base64 encoded? because the online decoder shouldve worked (the first time around, i was thinking the "file option" on the decoder was for when the encode included the file container....which isnt correct). Is it using another encoding scheme instead of base64...md5? Base32? Base128?, base16? Etc., etc.

So! The curl request you specify to output into a spreadsheet....is that correct? Am i understanding correctly that when running your curl command the encoded string is decoded into the spreadsheet?
What is the decoded value?

I wouldn't know what the expected filetype of the encoded value is...this is something that is defined in the requirements at your end.

Cheers,

Rich

[tech321]

I will try to find spec/design requiremnets from developers.

Yes, when I run the curl command with

curl http//ip:port/export  --output myexcel.xslx 

then I get the excel shett with the expected data. The data in the excel sheet is about eg. person insurance info etc. 

I am not 100% sure about the base64 encoded. It looks like other base64 encoded contents I have worked with earlier. 

[richie]

Hi @tech321,

Yeah base16, 32, 64 etc. all looks the same but i suspect this is the reason the original groovy i pointed you to isnt working, otherwise the online decode would've worked.

This is a blocker until the encoding type is confirmed. The only other option is to publish the encoded value and let the forum members try and work out the correct encoding type (it wouldn't be too difficult), but if its live data rather than test/anonymised/obfuscted then you cant publish the encoded string anyway

Nice one

Rich