This chapter provides a general specification for Workflow Manager type network service. It contains these sections:
Service Overview
A Workflow Manager type service is responsible for tracking 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 Workflow Manager service only provides “vendor” and “version” information.
{
"vendor", "[vendor-name]",
"version", "[current-version]"
}Service Requests and Responses
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.
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.
Session Resource Requests and Responses
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.
{
"messageType": "stateEvent",
"target": "<target_information>",
"name": "state.updated",
"context":
{
},
"data":
[
{
"name": "<capability_name>",
"type": "enabled" | "disabled"
},
...
]
}