An Open IP PBX Platform Using IceLib

Building on my last post on Session Manager, this post will cover the next logical layer in our N-tier architecture as we move out toward the clients.  That layer is IceLib.    IceLib stands for Interaction Center Extension Library and is both an internal and 3rd party API used to communicate with Session Manager.  IceLib is a .Net API and exposes a wide range of features of the Interaction Center Platform.  It typically runs in process with the client application, service, or web server that hosts the application or integration being deployed.   Below is a basic diagram of where IceLib sits in the n-tier architecture.  

IceLib n-Tier

Now to keep myself from getting into trouble with my coworkers, I need to mention that IceLib is more than just a public API.  With 5300 pages of documentation, 10 example applications and redistributable MSI’s IceLib is our first API worthy of being called a complete SDK. What’s more is that IceLib is currently used by 8 of our client applications keeping in line with the "eat your own dog food" mantra.   

The next important thing to know about IceLib is that, like Session Manager, it too is a caching layer designed to provide scalable communications.    By caching data client side, applications can be more responsive, use less bandwidth, and allow server components to scale higher.  

From a systems level, there isn’t a lot more to say about IceLib, but being a programmer at heart, I’m sympathetic to the plights of the profession so if you are looking to write an integration and happen to stumble on this post first, let me do you a favor with some important tips before starting your work. 

Tip #1:   Think of IceLib as a cache, not as a transactional API where a request is made and a result is returned.   In many cases you will not be able to use IceLib that way.    Usually you have to tell IceLib to cache something before you can request it.   The way this is typically done is to start a "watch" on the thing you want.   You also need to stop the watch when you are done so that IceLib can stop caching the data.    For Example, if I want to get the all the calls durations in my support queue then I would "start watching" the support queue specifying the duration as data I am interested in.  I would then get the contents (interactions) of the queue, and finally interrogate the interactions for duration.  I would also need to stop the watch when I am done.   If you were to request data that you did not explicitly ask IceLib to cache (say DNIS for the interaction) you would get a "NotCached" exception.   Icelib wants to restrict you from asking Session Manager or Interaction Center for the same data many times when the request could have been made just once.  This can be a bit more onerous in some environments like a web application where the requests are more transactional and stateless.  Unfortunately in this scenario you still have to cache and will also have to make provisions for recycling of your app pool, losing your web session, etc…   All in the name of scalability.

Tip #2:  IceLib is designed to be Multi-threaded.    It offers Asynchronous versions for all of its API’s.   Early on it was debated whether to even offer the Synchronous versions in order to encourage best practices in our own development, but in the end, we decided to include them both.  Also, IceLib uses events to notify applications of changes.  These events can be triggered on different threads.   Simply keeping this in mind as you develop your integration will likely save you many headaches later.  If you are new to multi-threaded applications you will want to research this area before getting too seriously involved with IceLib.

Tip #3:  Exceptions.   IceLib is not bashful about using them.  If you are not used to using exceptions then you will need to bone up a bit.   I already mentioned the NotCachedException, but there are many others such as: ArgumentNullException, OperationNotSupportedException (when connecting to older servers), IceLibLicenseException (for unlicensed features), InvalidOperationException,  and many others.    It’s just something to be aware of if you are not religious about handling these types of errors. IceLib choose to expose the vast majority of error conditions in exceptions as opposed to return values or simply tracing or failing silently.  The documentation lists the exceptions that can be thrown by each API.

Well, another post out the door.  I realize my posts are a bit different than most of the others on this blog.  They are more specific to the technologies of Interactive Intelligence and intended to help you learn something new about the Interaction Center architecture.   If you have suggestions about other posts or content you would like to hear or learn more about please comment.   I may not be the expert on the topic, but might be able to find someone who is.