My last post I talked about a new application that was released in SU4 called Interaction Center Business Manager and its use of our new client framework called Cafe’. In that post I mentioned two components called IceLib and Session Manager. For the most part I glossed over them, however, they are the two most critical components in the client architecture and this post is dedicated to giving a better understanding of Session Manager and its role in that architecture.
Session Manager is a server side subsystem that for most customers resides on the Interaction Center (IC) server. For very large IP Contact Center installations it is deployed off server and supports N+1 scalability and failover, however, for this post we will assume a single Session Manager server and I will save the N+1 considerations for a later post. Session Managers primary function is to provide an access layer for clients to connect and receive information and updates from the IC Server. This access layer includes Session Management, Security, Caching and Data Aggregation.
Back before the days of Session Manager, each client would connect to the Notifier subsystem on the IC server just like all other subsystems did. Today a client connects to the Session Manager subsystem which has its own port and may not necessarily share the same host as the IC server. Thus when entering the host name in the client log-in dialog you are really specifying the Session Manager server not the IC server (although the two are often hosted on the same machine). Session Manager handles the authentication and station settings (the SIP or handset device the user is logged into) . Session management also includes keeping track of which events a particular session is interested in and encrypting/decrypting the data passed to and from the clients.
Each user in the IC systems can be configured with a wide range of permissions. Examples are: specifying the types of calls a user can make, what type of call control the user is allowed perform and for which interactions, users and directories a person has access to. Previous to Session Manager it was up to the clients to enforce the security leaving obvious holes and allowing 3rd party integrations to skip security steps. Session Manager limits functions to users with insufficient privileges and restricts data to users without permissions to view that data.
One of the roles of Session Manager is to cache data commonly used by clients. This includes things like permissions, directories, status, and interactions (queues). By caching this type of information a client request often will not impact the IC server and can be serviced at least in part if not completely by Sessions Manager. This is especially useful for large deployments where Session Manager is deployed on its own server. Session Manager may cache data on start-up, when a client logs in, and when a client requests data. When the caching occurs depends on the type of data. For example the company directory is cached at startup, permissions are cached when the user logs-in, and status is cached when a client request it.
Just to drive these concepts home, let’s take a look at a simple example that involves two clients requesting a users status. Consider the following scenario:
- Client A requests Bob’s status represented by the green lines
- Client B requests Bob’s status represented by the blue lines
- Bob’s status changes represented by the red line.
The picture below attempts to illustrate the session management, security and caching roles of Session Manager with a data flow diagram using status as an example.
Client A Requests Bob’s Status (green line)
The first thing to note is that for many requests, Session Manager does not support a simple retrieval of data (e.g. get bobs current status). Instead Session Manager wants to know what information you are interested in so that it can cache that data to keep from having to go back to the IC server to get it. Session Manager wants to minimize the traffic to the IC server for performance and scalability reasons. Thus the way the status request occurs is to first start a watch on the status. This tells Session Manager to cache the users status and inform you of changes. Without the watch, a simple request will often result in a not cached exception or similar error. The data flow for this first request look like this.
1.) The client registers for a status watch on Bob.
2.) Session manager looks to see if the user has permissions for the data.
3.) Session manager requests a status watch from the IC server and caches the data.
4.) Session Manager returns the status value to the client.
Client B Requests Bob’s Status (blue line)
1.) Another client registers for a status watch on Bob.
2.) Session Manager looks to see if the user has permissions for the data.
3.) Session Manager already has Bob in the cache so it simply returns the value to the client .
Bob’s Status Changes (red line)
Now let’s assume some external factor changes Bob’s status (e.g. Bob receives a call) .
1.) The IC Server is informed of the status change.
2.) The IC server informs Session Manager.
3.) Session Manager informs all interested clients of the change.
You can see from the example above that data flowing out of Session Manager is much greater than that coming in from IC especially when there are many clients with common interests . This pattern is followed for many requests made to session manager.
That’s it for this post on Session Manager. There is much more that can be said about this subsystem but I think we’ve covered the basics and provided a foundation to build on in future posts. Next time I will talk about IceLib and from there we can build to talk about scalability or dive into some integration examples.