Understanding JSMCAPI Classes

This sections gives an overview of all the JSMCAPI classes.

The following class diagrams explain all the classes, fields, and the methods.

Image: Class diagram part 1

The following class diagram explains the classes, fields, and methods of JSMCAPI (diagram 1 of 4).

Class diagram part 1

Image: Class diagram part 2

The following class diagram explains the classes, fields, and methods of JSMCAPI (diagram 2of 4).

Class diagram part 2

Image: Class diagram part 3

The following class diagram explains the classes, fields, and methods of JSMCAPI (diagram 3 of 4).

Class diagram part 3

Image: Class diagram part 4

The following class diagram explains the classes, fields, and methods of JSMCAPI (diagram 4 of 4).

Class diagram part 4

PSMC is the base class that an application accesses to start an instance of JSMCAPI. The application can access all JSMCAPI functionality through this object. A session object is created from this class.

Image: PSMC base class part 1

The following diagram explains the relationship of PSMC with all other classes (diagram 1 of 2).

PSMC base class part 1

Image: PSMC base class part 2

The following diagram explains the relationship of PSMC with all other classes (diagram 2 of 2).

PSMC base class part 2

The Server class refers to the routing server and can execute events for specific server states. Three types of servers are available: CTI, queue server, and MultiChannel server. The constants are CTI, UQ and MCS, respectively.

The RENServer cluster is represented in the RENServer class. It provides the URL and the server status (active or shutdown).

Sessions are set for users registering with the server. Addresses, buddies, and groups are registered for the user with the session. The connection between the server and JSMCAPI is a session. There is only one session object per PSMC object.

The _Address class identifies the user with a unique ID. The ID identifies the user to the routing system and is unique for each channel or media type.

The subclasses of _Address class are:

  • Extension

  • _UQAddress

  • A2AchatAddress

Further delineation of address by media type is provided by:

  • ChatAddress

  • EmailAddress

  • GenericAddress

ChatAddress, EmailAddress, and GenericAddress classes extend _UQAddress.

Line class describes the line of the extension for a call task. This version supports one extension with two lines and two extensions with one line in each.

Tasks are routed to agents through a connection. Email, chat and generic have a dedicated connection class, like EmailConnection, ChatConnection, and GenericConnection. These connections provide task-specific manipulation functions.

The group class defines the group or queue information. Each session can have one or more group objects.

This abstract base class defines a unit of work. The classes that extend task per media type are:

  • Call

  • Email

  • Chat

  • A2AChat

  • GenericTask

_User is a base class. The subclasses are User and Buddy. These classes define the properties that pertain to the user such as the addresses, languages, or presence. _User is a virtual class and should not be instantiated.

This class defines the media that an agent can handle.

The Reason class defines the message or error message that accompanies an event or request. Globalization of the messages is implemented. Furthermore, extra data can be passed in this object for providing a detailed message.

Statistics are provided by the routing server for agent, call, task, group, and user. The following classes describe the statistics for each component:

  • AgentStatistics

  • CallStatistics

  • TaskStatistics

  • GroupStatistics

  • GroupStatistics1

  • GroupStatistics2

  • UserStatistics1

  • UserStatistics2

When a task is introduced to the system, data pertaining to the task is defined in the following classes:

  • CallData

  • EmailData

  • ChatData

  • GenericData

Application-specific data is provided for tasks via the AppData class. Similarly, user data is defined in UserData.

This class defines functions that are used universally.

Events passed to the application handler are defined by MCEvent.

Capabilities (Caps) define the ability or allowed actions for a component. The following classes define specific capabilities:

  • ChatConnectionCaps

  • EmailConnectionCaps

  • GenericConnectionCaps

  • ExtensionCaps

  • LineCaps

  • ChatConnectionCaps

  • EmaiConnectionCaps

  • GenericConnectionCaps

  • UserCaps

ForwardMode describes various forward modes that can be used while setting the forwarding mode for an Address.