Using XML Files to Control a Contact Center Express (CCX) CRS Script

The best way to dicuss using XML documents with CRS is by providing an example.  One common example that you can find floating around Cisco NetPro and in the example scripts provided by Cisco is a function to support time of day routing.  Specifically, using an XML file containing dates that are official holidays for your organization.  This example is fairly well documented.  You can search for “Contact Center Express Script Repository” on Cisco’s web site to download a zip file containing multiple examples.  Check out HolidayApp and HolidayChecker.

Another example is using XML documents to allow callers to enable ad-hoc prompts.  This is the example we will dissect further.

Background

So, one of the scripts that we like to build into all of our deployments is a prompt recording application.  It allows us and our customers to record multiple prompts which can be uploaded (or written directly) to the CRS server prompt cache.  Sometimes we find that folks would also like to have dynamic prompts which they can record and turn on/off at will.  For example, someone may want to have the ability to play an “outage prompt” for contacts calling a help desk application.  Another example is a marketing message for promotions in a sales contact center.

Documents

The mechanism we are using is the Document repository on UCCX.  Specifically, we are creating/managing an XML document using the PromptRecorder script.  This XML document is read by the App1 script to determine whether it should play a dynamic prompt or not.

To keep it simple, lets say we have a custom prompt document (customprompt.xml) that looks like the following:

Scripts

For our example, we will consider two scripts.  The first script is the one that is used to manage the prompts (PromptRecorder) and the second is the application (App1) that customers/end users call which will play out the dynamic prompt.

The following are excerpts from a functioning script that show the steps needed to complete our task.

Prompt Recorder:

The PromptRecorder script will first handle the contact.  In our script, we play a welcome greeting and then authenticate the user using their CUCM user ID and PIN.  Once authenticated, we can give them a menu of options with one option which allows the caller to record an outage prompt.

The first thing we need to do is read the existing XML document to identify the current status of the outage prompt.  This is done using document variables and various document steps:

docDownTime = Create File Document (strMyXMLDoc)
docXMLParser = Create XML Document (docDownTime)

So, we have to document variables which are declared and are null (initially).  We also have a string variable which has the path for the customprompt.xml file.  Next, we need to use a XSL query to find out what our current value is for the outage prompt:

blnOutageEnabled = Get XML Document Data (docXMLParser, “//outage”)

At this point we now have a boolean variable which will either be true (an outage prompt is already active) or false (the outage prompt is not active).  If the current value is true, we can then inform the user that a prompt is already enabled and allow them to review, re-record, or disable the prompt.  If the current value is false, we can simply ask them to record the prompt.

Let’s assume that the original value was false and the user wants to record a new prompt.  We also can assume that they have recorded the new prompt, reviewed it, and elected to save the prompt.  We need to now reset the boolean variable:

blnOutageEnabled=true

In addition to recording and uploading the prompt in the CRS script so that the prompt file has audio, we also need to edit the customprompt.xml file so that App1 knows it should play the new prompt.  To do this we need to recreate the XML content and write it to the file:

It is a little ugly for sure but we use the Expression Editor to create the string strXMLDump. The reason is that we want/need to use the escape character () (e.g for carriage return and new line).  You will also notice that we take the blnOutageEnabled variable and convert the boolean value to a string value (e.g. “true”).

Now, we use another Document variable to hold the new XML file output:

Set docWriteXML = strXMLDump

All that we need to do now is save the file:

Write Document (docWriteXML to strMyXMLDoc)

App1:

So, how do we get App1 to read the XML document and play out (or ignore) the prompt.  This is quite simple, we start off the same way we did with the PromptRecorder application:

docDownTime = Create File Document (strMyXMLDoc)
docXMLParser = Create XML Document (docDownTime)

So, we have to document variables which are declared and are null (initially).  We also have a string variable which has the path for the customprompt.xml file.  Next, we need to use a XSL query to find out what our current value is for the outage prompt:

blnOutageEnabled = Get XML Document Data (docXMLParser, “//outage”)

Now, we have a boolean value based on what was in the XML document.  All that is needed is a simple if…then..else action to determine what we should do:

if (blnOutageEnabled) Then
True
Play Prompt (–Triggering Contact–,P[MyOutagePrompt.wav])
False
/*do nothing here*/

Summary:

This example is a relatively simple one that demonstrates how to pass control information from one script to another.  This methodology can be extended to actually have more complicated XML data that a CRS can query to retrieve and use other data.  For example, one could store messages that are displayed in screen pops to agents or a supervisor can “open” or “close” a call center.  If you wanted to get real fancy, you could have an XML enabled IP phone service URL programmed in CUCM that allows someone to hit a single button to “close” a call center.  Well, maybe that isn’t such a good idea after all.  Too much power for one little finger…