Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current Restore this Version View Page History

Version 1 Current »

This chapter provides a general specification for Workflow Manager type network service.  It contains these sections:

·       Service Overview

·       Service Specific Information

·       Service Requests and Responses

·       Service Events

·       Session Resource

·       Session Resource Requests and Responses

·       Session Resource Events

Service Overview

An Interaction Processor type service is responsible for managing agent sessions and providing access to its underlying CTI for call control and possibly multimedia functionality.  All Interaction Processor services must support each request, response, and event detailed here unless otherwise marked optional.  However, they are free to expand on the structures of those messages as well as define new messages.

Service Specific Information

Each registered service has information specific to its service type, vendor, or instance.  This information is available through the getServices Core Request or as part of the events produced by the Service Monitor Service.

The "instance-domain" property is used to identify a group of interaction processors running within separate integration platforms that are working together to service the same pool of clients.  The set of clients will spread their connections across the platform instances hosting the correct domain.  The following information must be provided by all Interaction Processor type services.

{

"vendor", "[vendor-name]",

"version", "[current-version]",

"cti-vendor": "[cti-vendor-name]",

"cti-version": "[cti-version]",

"instance-domain": "[instance-domain]"

}

Service Requests and Responses

This section documents the requests that interaction processors must support and the responses that should be returned.

prepareSession

The prepareSession request is used by a client to initialize a new agent session on this interaction processor.  The client provides a set of credentials for the agent.  After validating the given credentials, the processor creates a new dynamic network resource to represent the agent's session.  The resource's unique identifier is included in the response so the client can easily bind to the resource.

The "model" property identifies which call model should be used for the agent session.  If this property is missing or blank, the default model will be used.  The "override" property determines what will happen if there is already a session underway for the given agent.  A value of false will generate a confirmation type response if a session exists.  A value of true will forcefully destroy the existing session and create a new one.

It is recommended that clients initially use a value of false for this property and allow the user to decide if they want to destroy the session.  If the user requests the session be removed, the client would send a second request with a value of true for the "override" property.

Request

{

"command": "prepareSession",

"data":

{

"model": "[name-of-call-model]",

"override": true | false,

"agent":

{

"id": "[agent-id]",

"password": "[agent-password]"

}

}

}

Confirmation Response

{

"command": "prepareSession",

"result": "confirm",

"message": "[confirmation-prompt-text]",

"original":

[Contains the original prepareSession request JSON structure]

}

Success Response

{

"command": "prepareSession",

"result": "success",

"resource":

{

"id": "[resource-id]",

"data":

[Contains the original data property of the request]

}

}

Failure Response

{

"command": "prepareSession",

"result": "failure",

"failure":

{

"code": "[error-code-for-failure]",

"message": "[error-message]",

"context": "[stack-trace-if-applicable]"

}

"original":

[Contains the original prepareSession request JSON structure]

}

Secondary Events

This request should not generate any secondary service events.

Service Events

The basic interaction processor type service does not generate service events.  However, particular implementations may do so.

Session Resource

A session resource represents an active agent session with the underlying CTI platform.  It is a dynamic resource created as the result of a successful prepareSession service request.  A session resource is designed to only allow a single client to bind to it; almost always the same client who called prepareSession.

Session Resource Requests and Responses

There are three categories of requests supported by a session resource: session management, telephony control, and multimedia control.  All implementations must support the session management requests.  However, the telephony and multimedia control categories are optional, with most implementations at least supporting telephony.  Not all implementations will include multimedia control, as the underlying CTI may not support multimedia functionality.

The "target" property of session requests, responses, and events represents the call object the message is directed at or is the source of the message.  The property contains a text value that follows '.' (dot) notation identifying the full object ownership.  The final segment of the value is the unique identifier for the target object, while each previous segment matches that object's parent.  The first segment is always the session id.

The "data" property carries any request specific information that is needed to perform the requested action.  The "context" property is optional for all messages and serves as a tool for debugging protocol implementations.  Under normal circumstances "context" should not be present.  Below is an example value that shows a telephony conversation: