08-04-2020 09:02 PM
I am attempting to call a REST service over http via the Make REST Call step. I've tried it in a reactive debug as well as a standalone debug (removed the call-specific steps to see if I could step through it). Either way, I just get a blank Exception popup and the script fails. Is there any way to find out what exception is causing this? Some type of log to check? Or does anyone know the root cause of a symptom like this?
I'm using UCCX Editor 12.0(1.00).
I've attached a pic of the Make REST Call step as well as the blank Exception box.
Thanks!
Solved! Go to Solution.
08-05-2020 09:20 AM
Quick question, why are you using the Do step and all that Java to parse the JSON data as opposed to the Get JSON Document Data step using JSONPath?
If you want to catch the exception, you can use the On Exception Goto step set to WFExecutionException, which catches any and all exceptions (in theory), and then you can try to store the exception and inspect it. Though, since the pop up is blank, I'm going to wager the inspection wont turn up anything useful either.
Alternatively, you can check the MIVR (CCX Engine) logs an the exception should be printed there as well.
Lastly, looking at your REST step, the only thing which looks odd to me, is that you're using null as your values for username, password and body. This is not something I've ever done before, I usually just pass empty Strings for unwanted input fields, and junk variables for unwanted output fields.
In fact, I just went and tried it myself and guess what? I got a blank exception pop up. Yup. Technically, it only happened in the user/pass fields, the body could be null, however, I would just make them all valid. You can follow this REST array approach to avoid using 8 variables:
08-05-2020 04:07 AM
08-05-2020 09:03 AM
08-05-2020 09:20 AM
Quick question, why are you using the Do step and all that Java to parse the JSON data as opposed to the Get JSON Document Data step using JSONPath?
If you want to catch the exception, you can use the On Exception Goto step set to WFExecutionException, which catches any and all exceptions (in theory), and then you can try to store the exception and inspect it. Though, since the pop up is blank, I'm going to wager the inspection wont turn up anything useful either.
Alternatively, you can check the MIVR (CCX Engine) logs an the exception should be printed there as well.
Lastly, looking at your REST step, the only thing which looks odd to me, is that you're using null as your values for username, password and body. This is not something I've ever done before, I usually just pass empty Strings for unwanted input fields, and junk variables for unwanted output fields.
In fact, I just went and tried it myself and guess what? I got a blank exception pop up. Yup. Technically, it only happened in the user/pass fields, the body could be null, however, I would just make them all valid. You can follow this REST array approach to avoid using 8 variables:
08-10-2020 03:32 PM
The REST step is extremely poorly implemented (why is Status Code a string?), the validators are all messed up.
Why on earth would it be a literal or expression?! neither are valid inputs and It's not even a string on the internals.... 🤦♂️ I digress..
IMO you're better off doing it in Java..
You should look at the MIVR logs as mentioned to find the actual error, as well as better insight into the data the step is getting. You may need to up your trace levels.
If there are no logs for this step, but it's almost always an issue with the variables being passed.
08-10-2020 05:11 PM
08-11-2020 08:47 PM
I just wanted to update that the null vs "" was the right answer! I also updated the body to "" and apparently had an invalid value inadvertently in one of the GET parameters. So, with all those, I was able to get it to work!
Thanks!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide