cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1776
Views
0
Helpful
6
Replies

Script Editor Empty Exception Popup on Make REST Call

ruth.brown
Level 1
Level 1

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!

1 Accepted Solution

Accepted Solutions

Anthony Holloway
Cisco Employee
Cisco Employee

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:

 

https://community.cisco.com/t5/contact-center/make-rest-call-ccx-10-6-1/m-p/3341335/highlight/true#M104111

View solution in original post

6 Replies 6

david.macias
VIP Alumni
VIP Alumni

If you upload the script to CCX and set it to reactive do you get the same thing?

 

david

OP: "...I've tried it in a reactive debug as well..."
=D

Anthony Holloway
Cisco Employee
Cisco Employee

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:

 

https://community.cisco.com/t5/contact-center/make-rest-call-ccx-10-6-1/m-p/3341335/highlight/true#M104111

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.

The more I use the Make REST Call step, the more I desire for it to be better, but I am glad we have it. Why is Content-Type a required header on a GET? Makes no sense to me.

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!