An Introduction to the Avaya Context Store Snap-in

Last week, I introduced you to Avaya’s contribution to the world of WebRTC – the WebRTC client API and Snap-in. I wrote about a number of the piece parts and even presented you with some JavaScript that demonstrated just how easy Avaya makes WebRTC solutions.

---

In case you missed it, you may want to read An Introduction to Avaya’s WebRTC Snap-in before going any further.

---

As exciting as Avaya’s WebRTC Snap-in is for writing easy, yet powerful WebRTC applications, I am almost as thrilled about their Context Store Snap-in. Like the WebRTC Snap-in, the Context Store Snap-in runs on Avaya’s Collaboration Environment 3.0. This means that the Snap-in is a Java servlet that runs in a WebSphere Application Server. Don’t let that scare you, though.   Nerdy details like that are completely hidden from the developer and application user.

The Context Store Snap-in provides developers with a way to store and retrieve communications related data. For example, a WebRTC developer may want to attach a reference to the page that launched the WebRTC call. This allows a contact center agent to have a better idea as to what the request is all about. “Good morning, Mr. Smith. Do you have a question about our refund policy?”

The unit of Contact Store storage is called a context entry. A context entry has the following structure:

ContextID. This is a unique identifier for the context.

Data. The data field is an abstract map with multiple key/value pairs. For example, a key value of “City” might contain the value “Scottsdale.”

GroupID. A GroupID creates a logical group of related context entries. GroupID is optional.

How an application uses context entries is completely dependent upon the application’s needs.   However, Avaya recommends the following.

1. Keep context size to a minimum.
2. When possible, use pointers instead of the actual data. In other words, Context Store should be used to store information and not data. For example, instead of storing a user’s picture, store the location to the picture.

Four Services

The Context Store Snap-in offers four essential services:

1.  Context Store Manager: The CSManager service is responsible for the storage of the context data. The data can be stored locally on the Avaya system, or if desired, an external, customer provided database can be used. At present, PostgresSQL 9.1 or later, Oracle 11g or later, and Microsoft SQL Server 2008 or later are the supported databases.

2.  Context Store REST: The CSRest service implements a RESTful web services interface for adding, updating, retrieving, and deleting context data.  This is where a developer will spend most of his or her time.

The supported interfaces include:

• Add a context entry
• Update a context entry
• Update a context value
• Get a context entry
• Get a context value
• Get all context entries that belong to the same group
• Delete a context entry
• Delete a context value

Digging through the Avaya Context Store documents, I found two request examples. Note that all CSRest requests are submitted through CLUSTER_IP. This assures that the requests are load balanced across all servers in a cluster.

Also, notice how the data is referenced by contextID.  In this example, the text field of “contextID” is used.  In a real application, this value would be something a little more clever since context IDs must be unique.

Request Name	URL	HTTP Request Type	Content
Create a new Context object	https://CUSTER_IP/services/CSRest/cs/contexts/	POST	{“contextID”:”sampleContext”,”data”:{“key1”:”value1”,”key2”:”value2”,”key3”:”value3”}}
Retrieve an existing Context object	https://CUSTER_IP/services/CSRest/cs/contexts/sampleContext	GET

3.  Context Store Screen Pop: CSScreenPop is an optional service used to view the data stored in Context Store. The data can be retrieved in the following formats: HTML, XML, JSON, URL, REDIRECT, and MAILTO.

CSScreenPop also provides a rules engine that can be used to manipulate the view of the context data stored in Context Store. This includes changing the output form and filtering the results based on keys in the context.

4.  Context Store Notifications: CSNotifications is an optional service used to receive notifications of any change in a context entry. The CSNotifications service uses the CSRest service to send an event trigger to up to five registered subscribers.

Application Development

For Java developers, Avaya provides a Java SDK (Software Development Kit) to facilitate access to the Context Store services. Underneath the covers, the SDK will use the RESTful services defined above, but those details are hidden from the programmer. An application can use the SDK interfaces to create new context entries and to store, update, retrieve, and delete data.

To prevent unauthorized access, the SDK requires client authentication.   Authentication is provided by security certificates.

Of course, the RESTful services are always available if the developer chooses to go that route.

You may be wondering something? How do you prevent the context store from growing too large over time? Avaya thought that same thing so they assigned a lease time to a context entry. At the end its lease, a context entry is released. This frees up any space it consumed.

While context data is in use, an application can renew its lease. This prevents data from unexpectedly disappearing.

Putting it all Together

The opportunities to use Context Store are limitless. I mentioned WebRTC, but Context Store is by no means limited to web calls.   It can be used with communications of any type. Additionally, a Data Connector exists for Avaya Experience Portal to use Context Store within an IVR (Interactive Voice Response) application.

The goal is for Context Store to be used when you require a scalable, highly available, and easy to use platform for associating data of any type to communications of any type and from what I can tell, it does all that and more.

Tags: Avaya, Context Store