Workflow Manager Service

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" }, ... ] }

 

This document may contain confidential and/or privileged information belonging to OpenMethods. If you are not the intended recipient (or have received this document in error) please notify the sender immediately and destroy this document. Any unauthorized copying, disclosure, or distribution of the material in this document is strictly forbidden.