Querying a calendar in a CCX script to get the closing time

[floatingpurr]

The Calendar Management allows users to define the business calendar hours, holidays, and special days. It's a very convenient way to schedule an application, since it can be exploited by the calendar step in a script.

However, I've not found a way to query the calendar in a real-time fashion to get the closing time of the current shift. Is there a way to do it?

[floatingpurr]

My very-very-unconvenient idea is the following.

You can always query the CCX API (e.g., https://<server>/adminapi/calendar/{id}) to get an XML-serialization (or a JSON) of a calendar. Then, you need to parse it. At this point, you can match it against the current weekday and time to get the interval you are running in, and then you can extract the relative endTime. Such a matching is not trivial. Indeed, you have to check also if the current date is not a specialDay shadowing the custom weekday with a different time schedule.

This seems quite cumbersome. However, let's expand this hypothesis. If you do not want to put other gears in the machinery, you can implement this control flow directly in a (sub-)script in the CCX. This looks like hours spent in low level string parsing and manipulation with CCX. Alternatively, you can set up your own API, that wraps the CCX API and does the job with modern libraries (Node, Python, etc...). In this case, your script depends on your API availability, so you should take care to keep it up & running.

That is what I've come up with so far. I'm pretty sure there's something way better out there.

Cheers!

[Elliot Dierksen]

You can store an XML file in the document store of CCX, so that is easy to access. It depends on how often you are changing the schedule. I rarely use the calendar step. It has been easier for me to have start and end times by day, and then parse either application variables, a database, or an XML file.

[floatingpurr]

Hi @Elliot Dierksen, thanx for your suggestion. According to me, the cumbersomness of this kind of processes lies in the string parsing that you need to do upon XML retrieval. This is necessary regardless of how you get the scheduling data (e.g., XML coming from API or document store, database resultset, etc...). I was wondering if there was a CCX scripting technique to do it with native steps. Probably, there's not.

[Elliot Dierksen]

All this is IMHO, of course. So much for the disclaimer. Other disclaimer: I am an engineer for a Cisco partner. I try to write my scripts so that customers can maintain them without having to get into the script editor. I usually do this by using application parameters. The schedule for a call center is one of the most frequently changed things, so I found it very important to have a fairly easy way to do that. I am more of a database person than an XML person, so that has always been my preference. Sometimes that was difficult from a cost perspective because that requires premium licensing. When I started writing scripts somewhere around version 3.5 of CCX, the builtin calendar scripts weren't very flexible, so I did this with 14 application parameters (open and close times for each day of the week). It is slightly tedious when you first write it, but it is easy to reuse after that. I generally put things like that into a sub-flow to avoid repeated code blocks in case I want to changes things in the future. I have seen various ways of doing this like the XML document, database calls (my favorite), and HTTP(S) calls to other servers. It depends on your willingness to code it, and what server/back end resources you have available. The builtin steps may be better these days, but I haven't had a compelling reason to reevaluate them since I have a working way to do it.

[floatingpurr]

Thank you for sharing your valuable experience.

I definitely agree with you. Customers are not supposed to work into the script editor. So they need something simple for the operations management.

I'm a huge fan of DBs and smart APIs. However, as you pointed out, sometimes they can't be integrated in the environment for many reasons (e.g., cost, policy,...). IMHO, if you need to stick only to the CCX, the built-in calendars are quite flexible now, and they are very powerful for managing the call flow respect to the schedule. However, it is not easy getting back the metadata of a calendar at script "runtime". The only way seems calling the CCX Calendar API with a REST step, and then parse the result.