cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
830
Views
20
Helpful
6
Replies

How to, count the number of played prompt "as global ccx variable"

Hello

         I need a way to make a global counter variable that counts a number "played prompt for ex. or any other step" and this variable value always counter and does not reset if self when the application end.

I searched questions in the community of this same purpose but non ended by solved.

simple variable "intiger or float" that i can increment or decrement within an application and the value if not resetted when the application ended.

TIA 

6 Replies 6

Konstantin Vaksin
Cisco Employee
Cisco Employee
Hello.

You can try to use external DB or HTTP Request to external server, where this will be calculated.

I am not aware about any possibility of using internal UCCX tools

Kostia

Hi Mohammad,

In the beginning, I want to say that this is an interesting problem that you have. There are 2 questions that you will need to answer before you can find a good solution:

  • where to write the counter results?
  • how to write this data?

Let's start with the first one.

I think that there are 2 options that you need to consider

  • Internal resource - it may be a file with XML or JSON Document or maybe a flat-file that will store the value. \
  • External resource - as @Konstantin Vaksin has proposed it may be a DB or external resource

The decision is up to you based on the infrastructure that you have and can use for this solution. What is important when creating the mechanism, is the fact that at the same time there can be multiple requests to update the value as the IVR sessions can run simultaneously. The writing mechanism should queue all the requests and process them one by one.

 

Let's look at the second question

When we consider when tow write, I think that we need to keep in mind 2 scenarios:

  1. Update the value every time the prompt is played - this option should give you real-time data in the file but will cause an increase in the number of steps that will be needed to on the IVR. In my opinion, this can also generate a high load on the UCCX servers based on the selection of the place to write.
  2. Update the value once the call leaves the IVR - in this case, you use an internal variable that you need to update in the script whenever the prompt is played. Once the call leaves the IVR the value should be written to an external source. So the question is when the call can leave the IVR. 
    1. The call was routed to agent - as far as I remember you can put some actions on Queue Step in the  connected event
    2. The call can be transferred to number - same treatment  as above
    3. The call can be disconnected by a client - this event can be captured using ContactInactiveException  - here is a document that you can use: Detection of a Disconnected Call in an IPCC Express Script

Please treat my questions and answers as a concept of the solution that might work for you. There are some things that I haven't tested in real life.

Marek
Web: https://gaman-gt.com

Anthony Holloway
Cisco Employee
Cisco Employee
Sometimes people forget to ask "why?" So, here goes: Why do you need this? What's the problem you are trying to solve?

Not a problem but it's all about a specific meaningfull step in my script that I need to know how many times it has been hit by clients.
for example, an excuse of a specific service in the service list is terp. suspended. I know the times which will help me clients need for this sprcific service in the service list.

I see now.  So, in a way, the "meaningful step" is your counter step.

 

Unless, you can figure out how to make the actual "meaningful step" execute your counter for you.

 

E.g., 

Play Prompt (--Triggering Contact--, P[myfile.wav])
Increment myfile_counter

VS

Play Prompt (--Triggering Contact--, { myfile_counter++; return P[myfile.txt]; })

Then, like @Marek (gaman-gt.com)  mentioned, you could catch all exceptions and use the script's ending to write the value one time at the end.  This should work most of the time, but, if for example the Engine crashed, you would not be able to write the values you've been collecting for the duration of the call.  If this concerns you, then you'd need to write immediately to secure the data from this scenario.

 

Did you already have a place you wanted to write the information to?  This will determine how you consume the results too.

Solved by counting the hits and storing it in a new tsql able created for this purpose.

for easy reset too.

 

Thank you all so much   :)