This chapter provides a general specification for Workflow Manager type network service. It contains these sections:·
...
...
...
...
· Session Resource
...
...
...
Service Overview
An Interaction Processor A Workflow Manager 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 messagestracking session, agent, and interaction states and delivering the resulting view state to the MediaBar for display. As the underlying state changes, various capabilities (buttons) are enable and disabled based on that state. When changes to the capabilities are detected, those changes are delivered as events to the MediaBar.
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.
{
The Workflow Manager service only provides “vendor” and “version” information.
| Code Block | ||
|---|---|---|
| ||
{ "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 The Workflow Manager service does not expose any service level requests. Session resources are created internally by Interaction Processor services. A reference to the Workflow Session resource is provided to the MediaBar as part of the session creation process of the Interaction Processor. The MediaBar then binds directly to the Workflow Session resource.
Service Events
The Workflow Session type service does not generate service events. However, particular implementations may do so.
Session Resource
A session resource represents the session, agent, and interaction states of an active agent session with the underlying CTI platform. It is a dynamic resource created as the result of a successful prepareSession service request to an Interaction Processor service. 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:The Workflow Session resource does not expose any resource level requests.
Session Resource Events
State Updated Event
The state updated event is sent each time there is a change to the current view state based on the underlying CTI state. Not all CTI state changes result in a view state change. In those cases this event will not be triggered. The event itself will always contain the entire view state for the target object and not just the view state items that changed. This helps reduce the number of events that must be generated as some CTI state changes can have broad impacts on the overall view state.
| Code Block | ||
|---|---|---|
| ||
{
"messageType": "stateEvent",
"target": "<target_information>",
"name": "state.updated",
"context":
{
},
"data":
[
{
"name": "<capability_name>",
"type": "enabled" | "disabled"
},
...
]
} |