There are a few enhancements I would like to recommend when set up GET REST VALUEs.
1) It would be nice to manage how the rest connections are set up by setting the variables name right next to the json path. It would be nice to not be required to put them in a single variable in a comma delimited list as this makes it very difficult to manage especially as the variable numbers increase.
2) Another option would be a way to group the variables that get outputted from this rest connection in the right-hand panel. Because the current way doesn't allow us to even reorganize these Json paths with drag and drop unless we re type all of our Json paths. This is extremely time consuming and makes it difficult to look up variables and so forth.
3) When rest connections time out, Sub7 should allow us to navigate this situation instead of failing the complete script. This has been causing issues and allows us to ineffectively run scripts when we are attempting to create/retrieve data via these rest connections.
Hi Zach,
Thank you for sharing your request with us. We appreciate your input and enthusiasm for our product.
Could you please clarify point number 3? Specifically, what do you mean by “navigate this situation instead of failing the complete script”?
Regards,
Subject7 Team
3) I apologize Firas as that is on me for putting such a vague response regarding this feature.
What I meant was if the API times out and let's say the server closed the connection, we should be able to restore that result into the step without causing that 'timeout' to just FAIL the entire script. In this case, we are looking for very specific data for our Warehouse Management System that has to meet specific requirements to be used as part of testing various processes. If our parameters we are passing through are too broad and there is a lot of data that matches the criteria it could definitely time out, but if it were to time out it would be nice if we had an option to rerun it again with a different parameter or something.
I am envisioning possibly that when an API fails, that value is stored as some sort of result, then the end user can choose to do what they want it.
However, I do know we can change the step itself to Continue on Failure, and maybe just verify that one of the variables we are looking for does not equal @system.empty. I haven't tried this yet because I can't get one of my APIs to time out of course with whatever I try haha. I am open for any ideas to try as well, just brainstorming ideas here. :)
Hi Zach,
Thank you for elaborating on this. For the part about restoring the result into step in case of timeouts, If the test does not fail during timeouts and gets some values assigned into different variables, the other variables will become undefined. During the rest of execution, the test may fail at a completely different step which makes maintenance difficult because it's not easy to pin-point where the data went missing.
I will create an internal request for evaluating the first two points you mentioned in your initial feature submission.
I would expect that if a timeout occurs, no variables beyond the status would be generated. In many cases, simply adjusting the parameters passed into the API resolves the issue without any problems. That’s why it feels unnecessarily restrictive to fail the entire script—especially when alternative approaches, like calling a different API to create the data before retrieving it, could have worked just fine. There are several flexible ways we could handle this.
Hi Zach,
Hi Firas, this makes sense to me! I just assume that everyone builds in error handling at this point haha, probably a bad assumption on my behalf. :) Many of our rest calls verify that the vars so IF xyz equals @system.empty / @system.null the script breaks immediately or performs the proper actions.
Please sign in to leave a comment.