cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5220
Views
15
Helpful
26
Replies

Debugging UCCX Rest call

Clifford McGlamry
Spotlight
Spotlight

I'm trying to sort out a REST call in a UCCX script.  It's failing, and I need to see what is actually being sent to the server.

I cannot find this in the MIVR log, and am unclear if specific traces need to be enabled in order to see this.

 

Can anyone provide some advice?  

1 Accepted Solution

Accepted Solutions

Ah ok, so it's not basic auth at all. Might have been a red herring in the postman testing then? or a false postive?

What is the type? Bearer Token?

In 11.6(2) you can omit the user ID and password fields by simply supplying empty quotes like this "", then add a custom Authorization header where the header name is Authorization and the value is the type and credentials. If you already built this in postman and in the coding language you used, then you should have access to the value as it hit the wire. You'll want to copy it verbatim, post any conversions which may or may not have happened. However, tokens usually are not converted and sent as is. To my knowledge, only Basic type is converted to base64 encoding before being sent.

View solution in original post

26 Replies 26

Anthony Holloway
Cisco Employee
Cisco Employee

I think most people are using something else for testing, like Postman, and then if it fails in UCCX only, it's likely just one of two things:
1) Source Address - This could impact reachability, as would be the case network routing or ACLs
2) Certificates - UCCX simply doesn't trust the server

Are you using HTTPS in your call?

Have you tried Postman?

What does the outcome of the step give you in the response status field? It should be a small error message with a response code I think.

And lastly, I don't know what debugging settings need to be on to debug the step itself, but I'll play with some setting and try and find out, in the meantime, while you answer the above.

 

EDIT: I turned on every debug possible (yes, I clicked that button, but it's a lab, so it's ok), and ran a simple make rest call to the adminapi to list the prompts and there was barely any valuable information in the MIVR traces:

 

14888190: May 14 16:35:02.629 CST %MIVR-ENG-7-UNK: [RMI TCP Connection(103983)-172.16.254.5] com.cisco.wfapi.impl.WFTracingLogImpl Execute step of Task 25000000058 : Make REST Call
14888191: May 14 16:35:02.629 CST %MIVR-STEP_REST-7-UNK: [RMI TCP Connection(103983)-172.16.254.5] com.cisco.wfapi.impl.WFTracingLogImpl Task: 25000000058 The parameters for the REST call are URL=https://localhost/adminapi/prompt, USERNAME=appadministrator CONTENT-TYPE=application/xml
14888192: May 14 16:35:02.629 CST %MIVR-STEP_REST-7-UNK: [RMI TCP Connection(103983)-172.16.254.5] com.cisco.wfapi.impl.WFTracingLogImpl Task: 25000000058 Method selected is GET
14888193: May 14 16:35:02.629 CST %MIVR-STEP_REST-7-UNK: [RMI TCP Connection(103983)-172.16.254.5] com.cisco.wfapi.impl.WFTracingLogImpl RestMethodCallStep Header map contains
14888216: May 14 16:35:02.705 CST %MIVR-EXPR_MGR-7-UNK: [RMI TCP Connection(103983)-172.16.254.5] com.cisco.expression.impl.IdentifierImpl evaluating identifier 'rest_client' (0) = [Ljava.lang.String;@a1abda
14888217: May 14 16:35:02.706 CST %MIVR-EXPR_MGR-7-UNK: [RMI TCP Connection(103983)-172.16.254.5] com.cisco.expression.impl.IdentifierImpl evaluating identifier 'rest_client' (0) = [Ljava.lang.String;@a1abda
14888218: May 14 16:35:02.706 CST %MIVR-EXPR_MGR-7-UNK: [RMI TCP Connection(103983)-172.16.254.5] com.cisco.expression.impl.IdentifierImpl evaluating identifier 'rest_client' (0) = [Ljava.lang.String;@a1abda
14888219: May 14 16:35:02.706 CST %MIVR-STEP_REST-7-UNK: [RMI TCP Connection(103983)-172.16.254.5] com.cisco.wfapi.impl.WFTracingLogImpl Task: 25000000058 Response from the rest call is: <?xml version="1.0" encoding="UTF-8"?>
<Files><Prompt><Folder><path>/</path><FolderName>default</FolderName><Details><size>0.83 KB</size><dateModified>05/01/2020 11:24:17 AM Central Standard Time</dateModified><modifiedBy>uccxadmin</modifiedBy></Details></Folder></Prompt></Files>

Now, could it be somewhere else?  Yeah, maybe, but it's a script step being executed by the engine, so I'm going to stop there with a check on MIVR logs for now, and let's see how you answer the previous questions/comments.

 

Fails in Postman as well....complains "Signature mismatch".

 

No idea what to do with that. 

Sounds like it is not a UCCX issue then. Would you agree?
I don't have any experience with the Signature Mismatch response, though a Google search shows it's talked about online by others. If you get it to work in Postman, I'm pretty sure it will work in UCCX....depending on your UCCX version. The Make REST Call step has had some significant advancements between when it was introduced and 12.5.

Got it working in Postman....but it isn't working in UCCX for some reason.  The journey continues.  

What can you share with us, so we can help you?

I'm using the same code as I have in Postman (that works), but it fails in UCCX with a 401 error saying no token provided.  

In Postman, I have the ability to set it to use Basic authentication (setting not visible to me in UCCX).  I tried adding the header in manually, but it forces me to have a username and password in the UCCX step (cannot leave them blank).  

 

I used your trick of turning on all the logs.  My message body is correct as far as formation, but I really need to see what it's putting together and sending out.  That's apparently not in the IVR logs....maybe in the Tomcat logs???

The username and password field is for Basic Authentication though. So, you wouldn't need to manually set the header. Have you tried supplying the username and password to the Make REST Call step yet, or did you jump straight to the Basic Auth header approach?

I've tried both.  And I've tried converting the username and password to Base64 encoding to see if that helped (it doesn't).

 

Postman has the ability to generate code in probably a dozen and a half languages.  None of them are particularly helpful, though I have looked through them.  

I'm fairly certain at this point the issue is with authorization, but I don't understand why.  

Yeah, you wouldn't encode it yourself, just let the step take care of crafting the headers.

The fact that it says "token" in the response, make me wonder, since that doesn't sound like basic auth. Can you paste the headers from postman? Feel free to protect your auth values, or send it to me in a private message.

Ok....more information....

So I backed up and dropped this into Visual Studio to see if I could get it working there.  With the collaboration of the support staff from the cloud provider and a few other folks, I was able to get it working in Visual Studio using VB.net, C# and RestSharp. 

 

I found that while both vb.net and C# have the ability to add a credential into the call, it doesn't work if you do it that way.  I had to add the credential as an Authorization header and encode the username and password as the value.  Not clear why, but that's what it took.

 

In attempting to do this same thing in UCCX, the REST call step, it appears that it's not possible because the Step Editor requires an entry for the username and password, and will not allow you to leave them off.  I'm not clear if this is a bug or not (I would think it is...not all REST calls need a username and password), but I have no idea how to get something like this reported/logged with Cisco.  Seems like this might be completely beyond what TAC would deal with. 

 

Ah ok, so it's not basic auth at all. Might have been a red herring in the postman testing then? or a false postive?

What is the type? Bearer Token?

In 11.6(2) you can omit the user ID and password fields by simply supplying empty quotes like this "", then add a custom Authorization header where the header name is Authorization and the value is the type and credentials. If you already built this in postman and in the coding language you used, then you should have access to the value as it hit the wire. You'll want to copy it verbatim, post any conversions which may or may not have happened. However, tokens usually are not converted and sent as is. To my knowledge, only Basic type is converted to base64 encoding before being sent.

I don't know Anthony.  What I can tell you is that I configure it as Basic Auth in postman, and put in the user id and password, and it works.  Postman hides a lot of what it does under the hood, but it does provide output translated to code in other languages that is close, but not exactly, correct (I used that as a starting point when doing it in RestSharp).


Using a credential and Basic Authentication DOESN'T work in Visual Studio or UCCX.  I have to put it in as a header in VS....cranking up my lab to attempt using the empty quotes to see if I can make it work that way.  I'll do some testing and follow back up on this.

<Drum roll>........

That worked!  The ability to not do basic authentication by using just a "" as an empty string in those two fields isn't documented in the step guide.  In most of the rest of the editor you can leave something blank if you don't want to use it, so that, combined with the lack of mention in the documentation kind of nailed me there. 

 

But the exercise was a useful one, and I certainly learned a great deal. 

 

Thanks for your help.  BTW, I want your job.  I'm not sure how you get to invest as much time here as you do, but that would be awesome to be able to do!

 

 

 

I suppose I just make the time. For instance, right now, I just finished dinner and mowing the lawn, it's 8:05pm, my kids are playing outside, my wife is at the garden, and I came inside to check for new replies. That's not a function of my job, rather, a life style choice. I'm happy you learned some things and also that you were able to solve your immediate challenge. I hope we run into each other again some time.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: