IceLib Overview

IceLib interfaces with SessionManager, the CIC subsystem that brokers connections between client applications and a given CIC server. Custom IceLib applications fully leverage SessionManager, just like internally developed CIC applications. For example, Interaction Fax and Interaction VoiceMail both use IceLib and take advantage of its SessionManager capability. IceLib is feature-license based, not per-seat or per-session. Client sessions require client licenses, of course.

Generally speaking, IceLib provides the means to work with Interactions, Directories, People, Interaction Tracker, and Unified Messaging. It manages connections with the CIC server, specifies authentication and station settings, watches for connection state-change events, and performs actions relative to the connected Session user.

IceLib gives applications the ability to monitor interactions and queues. An interaction in a given queue can be watched for attribute changes. Applications can receive notifications when interactions are added or removed from a queue. Monitoring can be scoped to a given interaction, or to all interactions within a queue. Chats, Emails, and conferences can be monitored, along with telephone calls and other interaction types. In IceLib, objects and object watches contain only the data that the developer requests.

Change notification is implemented using events that follow the common Object/EventArgs pattern. This allows multiple notification recipients to be registered. It also allows recipients granular control over which notifications they receive. Developers should name the custom delegate for an event FooEventHandler. Foo does not have to match the name of the event if FooEventHandler is generally useful for multiple events in the system. FooEventHandler's first parameter should be object sender and the second parameter should either be EventArgs e (and set to EventArgs.Empty) if no arguments are needed, or if a custom FooEventArgs class that inherits from EventArgs (or CancelEventArgs).

IceLib follows the direction that Microsoft has taken with public APIs. It conforms with Microsoft's design guidance and best practices for public APIs and framework development. It utilizes familiar style and naming conventions and it is based on Microsoft's .Net 2.0 technology framework.

For example, IceLib is object-based, rather than interface-based. This reflects the direction that Microsoft and the .NET technologies have taken to go beyond COM, in accordance with the .NET Framework Design Guidelines.

IceLib conforms with the Common Language Specification (CLS), a standard that defines naming restrictions, data types, and rules to which assemblies must conform if they are to be used across programming languages. This means that IceLib is compatible with C#, VB.Net, and all other .Net languages.

IceLib is a strongly typed API. Common attributes are accessible as properties, enumerations, or constants. IceLib supports generics, events, asynchronous patterns, and nullable types. Properties are used instead of public fields. This helps make the API future-proof, since changes can be made to a property get/set without affecting existing third-party application usage.

IceLib provides a consistent set of stable interfaces that expose Interaction Desktop feature sets to third-party applications. It provides a stable foundation for application development. IceLib's internal consistency promotes intuitive use, and its adherence with .Net eases understanding, reduces ramp-up time, and speeds development.

Note:
Customer Interaction Center (CIC) supports two interaction management client applications: Interaction Connect and Interaction Desktop.

This documentation uses the term CIC client to refer to either Interaction Connect or Interaction Desktop. For more information about CIC clients, see CIC Client Comparison in the PureConnect Documentation Library.

Consistent API design promotes intuitive use by application developers. Further, it can reduce the number of bugs when correct usage patterns have previously been learned. The ease of use improvements gained through design consistency are sometimes termed The Power of Sameness. This is beneficial to customers since it can reduce application development costs.

IceLib provides synchronous (blocking) and asynchronous (non-blocking) versions of most methods, especially those methods that make a server call. This convention allows the developer the convenience of choosing which programming model to use. It also allows him to switch back and forth between the two models where appropriate within the same application.

In IceLib, errors are reported via exceptions rather than by returning or querying error codes. Methods are designed to fail fast, by evaluating parameters early and to throw meaningful argument exceptions. This helps developers to identify issues with code more quickly and easily.

IceLib ships with full-featured sample applications in several languages (C#, VB.NET, ASP.NET). Each application is commented and designed to illustrate best practices of a real implementation. The examples cover key topic areas, such as:

• Interactions, Queues, and Voicemail (C#)

• Workgroups, Users, and Statuses (VB.NET)

• User Rights, Access, Status Messages, Workgroups, etc. (C#)

• Directories and Statuses (ASP.NET)

• Directories Metadata & Paged Views (C#)

• More Directories (C#)

• Tracker Types Information (C#)

• Tracker Queries (C#)