cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5189
Views
10
Helpful
27
Replies

Using REST step in scripts

mr_cisco_cisco
Level 1
Level 1

A common requirement in contact centers is to allow a supervisor to manually close the queue.  The typical approach I see is to create an XML file that stores the state of the queue.  When someone calls the contact center, the script reads the XML file for the state of the queue. 

 

I'm wondering if it's possible to do this without xml files and instead use a REST API.  The idea is you have a boolean value in the script called say, state, and make it a parameter.  Then use a configuration API to set this value to TRUE or FALSE. 

 

I'm referring to the API here:

https://developer.cisco.com/docs/contact-center-express/#introduction/supported-operations

 

Has anyone tried this?  Any pitfalls to be aware of?

1 Accepted Solution

Accepted Solutions

I said it was dangerous, because of the assumption the API is making, that any information missing, is information that needs to be deleted. This is not a good API design, in my opinion. I would rather be able to just send the updated information in a PUT request, and not have to handle all of the other data.

For a example, if I need to update an app with 30 parameters, to adjust a single Boolean, it doesn't make sense that I would have to receive all 30 parameters, parse them, make my single change, then package it all back up, and submit it. The data payload overhead alone is enough to know this is bad (submitting 30 params to update 1), let alone the danger of messing up the request. If UCCX cannot correctly parse my XML/JSON it will delete all of my parameters.

View solution in original post

27 Replies 27

Anthony Holloway
Cisco Employee
Cisco Employee

I could have read your statement wrong, but it sounds like you wanted to move the boolean for state into the Application Parameters, and then read its value via the Make REST Call step.  Is that right?

 

Or were you thinking that the actual value would be somewhere else, like on a different server in your company?

 

Also, what is the goal of your adventure?  I.e., Do you just want to get rid of the XML?  Do you want to get rid of logging into UCCX to make the change?  Both?  Something else?

Yes move the boolean state to the application parameter.  But I want to set this value with the REST step.

 

The goal is to get rid of XML files.  The goal is also set the state of the queue without logging into UCCX, and instead by literally calling in to UCCX. 

Ah ok.  So you wouldn't need Application Parameters, nor the Make REST Call to do that, but you might still use XML, or possibly CSV, JSON, plain text, etc.

 

Do you have any requirements for moving the data off of UCCX, or do you like the idea of keeping the data on box?

I like to keep all data on-box.

Sorry, I did forget about this. Uhm, if you're keeping it all on UCCX, then I recommend sticking with the XML document approach. The UCCX Admin API is not where it needs to be today, in order for the benefit of switching over to it, to be there.

For example, you cannot straight up take the output from a GET for your Application and use the Create XML Document step. It will fail. Then, you have to send back 100% of the data for every request, else it thinks you want to erase the configuration for anything that's missing. That's dangerous and stupid to have to submit all the data back again.

Just my opinion.

Makes sense. Thanks for your input.

Thinking of this further, why is it dangerous?  The UCCX server is sending a REST request to itself. 

I said it was dangerous, because of the assumption the API is making, that any information missing, is information that needs to be deleted. This is not a good API design, in my opinion. I would rather be able to just send the updated information in a PUT request, and not have to handle all of the other data.

For a example, if I need to update an app with 30 parameters, to adjust a single Boolean, it doesn't make sense that I would have to receive all 30 parameters, parse them, make my single change, then package it all back up, and submit it. The data payload overhead alone is enough to know this is bad (submitting 30 params to update 1), let alone the danger of messing up the request. If UCCX cannot correctly parse my XML/JSON it will delete all of my parameters.

I see.  Agreed not good API design.

Hi Anthory, 

This is a great thread, 
I'm having some similar requirement like this, I have an XML file in UCCX, let's get a simple one, 

 

<?xml version="1.0"?>
  <Call>
    <ID>100</ID>
    <ACK>Yes</ACK>
  </Call>

 

this XML file is stored in "document/en" I need to update the ID and ACK using a REST API, any idea how we can do this, I tried with the postman and getting errors. 

 

Regds
$Sasith

 

You cannot update the contents of a file in the Document repository from the REST API. The best you can do is:

1) download the file
2) modify it locally
3) upload the file

Are you accessing the API from within a UCCX Script, or from like Python?

Hi Anthony 

 

Thanks for your response, I'm accessing the XML from UCCX Script as well as Another system, My requirement is needed to update document from another system via API, seems to be this is not possible. 

 

Regds

Sasith 

 

Well, you should be able to, but you'll just have to use the API to download the file to the other system first, modify the file on the other system second, and then use the API to upload the file to UCCX third.

You cannot use the CCX API to download a document, you can download a prompt or a script.

You can upload a document but downloading is a step too far.

Graham