ContributionsMost RecentMost LikesSolutionsRe: SOAPUI PRO: Using Add API throws "unable to read location" error For reference, I sent the file to support and they could recreate the error. The problem is that the specification needs to be fixed before I can import it. Seems that the .net framework version we're using has an older swagger version than the .net core version. Another point worth noting is that I could get more details on the errors if I changed the securityDefinition in the json file from this: "securityDefinitions":{ "Token":{ "type":"apiKey", "description":"Token Authentication", "name":"Token", "in":"Authentication" } } TO: "securityDefinitions":{ "Token":{ "type":"apiKey", "description":"Token Authentication", "name":"Token", "in":"header" }} So I would at least see a popup in soapUI with errors like the following instead of just the file location error: attribute paths.'/Health/Status'(get).responses.200.schema is unexpected attribute paths.'/Health/Status'(get).consumes is unexpected attribute paths.'/Health/Status'(get).produces is unexpected attribute Re: SOAPUI PRO: Using Add API throws "unable to read location" error Thank you Himanshu. I've opened Case #00439862. I will keep this open until I have more info from them and will share it here. Re: SOAPUI PRO: Using Add API throws "unable to read location" error Hi Himanshu, I've attached a dummy json file that I created that has the same error when adding the api to readyAPI. ERROR: unable to read location. I could not attach as json file so it is saved as txt for attachment purposes only. Hoping this helps shed light on the root issue. Re: SOAPUI PRO: Using Add API throws "unable to read location" error The only errors were the ones I mentioned: Wed Jun 10 16:36:39 EDT 2020: ERROR: unable to read location `C:/Program Files/SmartBear/ReadyAPI-3.2.5/memberstore.json` Wed Jun 10 16:36:39 EDT 2020: WARN: Item [null] submitted for display, but no module could display it Let me see if I can create a stripped down json file that causes the same issue and I will post it here. Re: SOAPUI PRO: Using Add API throws "unable to read location" error Thank you Himanshu. I've now tried that but it did not help the issue. I suspect the issue is in the structure of the json file. I have two files and both are swagger based. One works fine for one API, but the other file doesn't. The problem is I want to add the api of the file that isn't working for me. I also don't want to have to extensively edit it to 'make it work' as that is not sustainable for future updates. Attached are two screenshots from the json objects. I'm not sure if you can tell anything from this high level detail or not. I can provide a bit more detail if needed. Thank you so much for your ongoing assistance. SOAPUI PRO: Using Add API throws "unable to read location" error I am attempting to add an api through a json file into readyapi 3.2.5 so I can use it for test cases in soapui pro. But I keep getting this error below in the logs and the api doesn't get added. I've put the file in various locations (C: drive, 😧 drive, desktop) to no avail. What causes this error to occur and how can I resolve it? Wed Jun 10 16:36:39 EDT 2020: INFO: Importing swagger C:\Program Files\SmartBear\ReadyAPI-3.2.5\memberstore.json Wed Jun 10 16:36:39 EDT 2020: ERROR: unable to read location `C:/Program Files/SmartBear/ReadyAPI-3.2.5/memberstore.json` Wed Jun 10 16:36:39 EDT 2020: WARN: Item [null] submitted for display, but no module could display it Wed Jun 10 16:36:39 EDT 2020: WARN: Item [null] submitted for display, but no module could display it SolvedRe: SOAPUI Pro (within ReadyAPI 3.2.5) - old project test methods loading POSTs as GETs Hi, it is possible we were using the free version when they were created. Very hard to say. Is there a way to identify that in one of the files itself? Or would that be overwritten as soon as we opened it in Pro version in readyAPI 3.2.5? I think I will go ahead and close this issue though. It sounds like this is not something familiar to anyone at this point and no 'known workaround'. That is what I was trying to find out mainly. We will remap the methods manually instead. Thank you. Re: SOAPUI Pro (within ReadyAPI 3.2.5) - old project test methods loading POSTs as GETs Hi, I had typed a long response to your questions and submitted it, but its no longer showing up. I'm not sure why. So I guess you are saying that this has not been an issue that was reported before and you've not heard of anything similiar occurring. I have noticed that the API button loads up the first API method in the list all the time - as if its lost its connection to the original api. Any idea how that could happen? If the root API changed, could that cause this type of behaviour? I'm using readyapi version 3.2.5 and my colleague has 3.0 and we've both seen the issue. In my case, I'm newly working on the projects so this occurred when I first loaded them into my workspace. My colleague has not worked on that project in over a year so likely just loaded it again as well. Re: SOAPUI Pro (within ReadyAPI 3.2.5) - old project test methods loading POSTs as GETs My replies are below. So this sounds like something no one has encountered before as a known issue? Can you comment on the sequence of events of how you noticed this? Reply: The projects had note been opened in over a year, maybe 2 years even. I simply imported it to my workspace and tried to run the tests and they mostly failed. So as I was looking through them, noticed that the API methods referenced were now wrong. A colleague of mine has also noticed the same problem. Ehat i mean is, are you saying that this didn't occur with the previous version of ReadyAPI! you had installed (e.g. v3.2.0 for example) and once you opened your workspace in the latest version all of a sudden there appears some corruption in some of the projects? Reply: Correct. These projects were working fine, but it was a year or two ago that they were last run. So when we opened them in the newer ready API versions and these corruptions came up in a couple of projects (I'm using 3.2.5... my colleague is on 3.0). Were any of the projects removed from the workspace and were then re-added back into the workspace? Reply: I had never had them in my workspace at all and had never run them before. So I was loading them up fresh. Considering most POST requests include a payload, if the method has changed to GET, does this mean you've lost all your embedded payloads too, or are you using the Data Drive functionality to source your data? Reply: The entire referenced api was also incorrect, not just the fact it switched to GET. I have to click on the API Request button and repoint it to the proper method. And it then has the correct details from the method again. We are not using the data drive functionality. Is there any similarity/pattern you can identify across the projects this method/corruption has occurred for? Reply: When I look at the "link to API request" button, I notice that it appears to be always showing the first API method in the list instead of the correct one (screenshot attached). The endpoint and details look correct in my test step, but clearly the mapping to the API link is corrupted. Is there any similarity/pattern you can identify across the projects which havent displayed this sort of method/URI corruption? Reply: Nothing obvious yet. I'm trying to look at the xml data itself and compare guids or something that might help me identify the cause. SOAPUI Pro (within ReadyAPI 3.2.5) - old project test methods loading POSTs as GETs We are seeing an odd issue when opening some older SoapUI projects that we haven't run in a year or more. Many of the REST request test steps that were originally set up as POST methods are loading as GET methods and are pointing to the wrong API end points/resources. As a result, we are having to edit and fix all the API request links. What could have caused this to happen? We see it across multiple projects, but not all. This is very time consuming to fix so would love to know if this is a known issue and whether there is any other alternative way to fix this faster than manually fixing each test step. (screenshot attached ... sorry for messy text on it). Solved