Services, States, and Tasks
|
Purpose: Gives guidelines for managing Service information with Context Services. |
Contents
In versions 8.1.000.10 and higher, you need to check the privileges set according to roles prior to using the operations described on this page. See Role-Based Access Control for additional details.
About the Service, State, and Task Resources
Services are customer commitments defined by the business application (IVR, Orchestration, Agent Desktop, etc.) which interacts with the customer. Each service potentially spans multiple interactions over a variety of media channels and should link to a Customer Profile as soon as it is created or retrieved through identification operations (read Profiles and Identification.) The Context Services REST API uses Service, State, and Task resources to manage and store the context information of your application. Basically, the Service resource is equivalent a top-level container associated with an overall commitment, which can be divided into a set of States to transition from one to another. These additional states can be divided into tasks.
Consider, for instance, an application that is a web-based interface, and that includes several online services, such as 'Booking a hotel reservation'. The service 'Booking a hotel reservation' is in charge of collecting information for the reservation.
- State 1: Collect Hotel Search Information
- Task 1: Collect Time Information (arrival, departure)
- Task 2: Collect Localisation Information
- Task 3: Collect Hotel Criteria
- State 2: Get Proposals
- Task 1: Search offers in the database
- Task 2: Propose offers
- Task 3: Get Detailed Information about the offer
- State 3: Validate Proposal
- Task 1: Get customer approval
- Task 2: Make payment
- Task 3: Validate reservation in the system
- Task 4: Send bills and additional details by e-mail
- Task 5: Collect customer feedback
- And so on.
If a customer starts interacting with the service, the application creates a new service resource to manage the service's context data, and then nested state and task resources to manage further states and tasks' context data.
Services, States, and Tasks contents
The standard content of these resources is formal core information, as described in the related Service, State, Task pages, to determine:
- When the given service, state, or task started;
- Whether it is active or completed;
- Which interactions or customer are related to the given instance.
For each type of resources, the Context Services provide you with a set of operations which manage this basic data. For instance, in the case of a service, standard use cases imply that your application should:
- Start the service,
- Associate the service with a customer ID-see Anonymous Service for further details;
- Start and complete similarly states and tasks-see List of State Operations and List of Task Operations;
- Complete the service once all the nested state and tasks are completed.
Note that your application is fully responsible for managing the status changes for the nested states and tasks. In other words, if you want to complete a given service, you must also complete the nested states and tasks.
Active Resources
A service, state, or task is active if a customer is still interacting with it. In that case, the service, state, or task is started, but not complete. Once the resource is completed, it is no longer part of the active list, but part of the completed list.
Extensions
The Context Services enable your application to record additional data related to the management of services, states, or tasks. In our introduction sample of 'Booking a hotel reservation', this would represent all the information collected through the service. If at any time the customer is disconnected and reconnects, your application is able to recover all this information with the Context Services. In this case, your application can define a set of Extension Schema, and then add extension records which contain this information. As for profile extensions, extension records can be either "single-valued" or "multi-valued" (see profile attribute values for example).
Preliminary Steps to Using Services
Creating Extension Schemas
The creation of service, state, and task extensions is optional. However, if your application needs to extend the information of the service, state and task resources, you must create an extension schema to define the new extension content prior to any use.
- Use Create Service Extension Schema to provide extensions at the service level.
- Use Create State Extension Schema to provide extensions at the state level.
- Use Create Task Extension Schema to provide extensions at the task level.
The following sample create an Extension Schema which defines the Content of the Feedback extension:
POST /metadata/services/extensions
{
"attributes":
[
{"name":"FeedbackType","type":"string","length":"10","mandatory":"true"},
{"name":"rating","type":"integer","mandatory":"true"},
{"name":"notes","type":"string","length":256,"mandatory":"false"}
],
"name":"Feedback",
"type":"single-valued"
}
Basic Service, State, and Tasks Management
Operations and resources in this section are part of Service Operations and its subcategories.
Start the Service
- Start Service: first step in your service management. Your application creates a service instance each time that a new information context needs to be created. (In our example, each time a customer enters in the Booking reservation service, UCS creates the core service information, including a service ID returned as a result of this operation.)
- If you have no information to create or identify the customer, your service is anonymous. In that case, use a contact key.
- When you start the service, you pass in the operation's body the Service Start Event which describes the start information.
- Associate Service: To use later, once you have a customer ID to associate with your service. To get a customer ID, you need to retrieve profile information (see List of Profile Operations).
The following operation starts a new service with a contact key:
POST /services/start
{
"timestamp": "2009-05-12T12:05:12.145Z",
"interaction_id": "123ABCAADFJ1259ACF",
"application_type":400,
"application_id":40,
"est_duration":60,
"contact_key":"42",
"service_type":100,
"media_type": 1,
"resource_id": 5005,
"resource_type": 2,
"disposition": 10,
"coupon": {
"coupon_name": "DISCOUNTCODE15"
},
"satisfaction": {
"score": 85,
"agentID": 2025
},
"relatedOffers": [
{
"offer_name":"VIP credit card black ed.",
"type":9,
"comments":"proposed to all client"
},
{
"offer_name":"3 times payment GOLD",
"type":4,
"comments":"limited offer"
}
,{
"offer_name":"life insurance",
"type":3,
"comments":"healt check to be done before approval"
}
]
}
Manage States or Tasks for a given Service
Your application can use both States and Tasks, or Tasks only.
- Start State or Start Task: In the corresponding Start Event, you must specify to which service the state or task belongs by filling the 'service_id' parameter.
- Perform State Transition: if your service contains several states, you can perform state transition instead of completing a state and starting a new state.
- The state transition does not complete the tasks which belong to the completed state. Your application must complete them before performing this operation.
The following example shows a state transition:
POST /services/735692/states/transition
{
"timestamp": "2009-05-07T12:05:20.157",
"session_id": "11000ABC-80236C1A-1010",
"interaction_id": "123ABC908ABFFD8080",
"from": {
"state_id": 1001,
"disposition": 1,
"disposition_desc": "SUCCESS",
"Feedback":
{ "FeedbackType":"survey","rating":7,
"notes":"warm welcome at frontdesk, thanks for the nice trip"
},
"Satisfaction": [
{
"rating":2,
"pertinence":8,
"usefull":true,
"place":"Terranova mexico resort"
},
{
"rating":8,
"pertinence":4,
"usefull":false,
"place":"Fancy resort Paris"
}
]
},
"to": {
"state_type": 8,
"est_duration": 500,
"Sponsoring": { "Rank":"first","expire":7,
"notes":"give customer free meal" }
}
}
Query the Services/States/Tasks for a Given Profile
In Query Services, Query States, and Query Tasks operations, you can query lists of active or completed resources, by filtering in the URL the active or completed status of the resources. For instance, in Query Services:
- Active Services: GET /customers/${customer_id}/services/active
- Completed Services: GET /customers/${customer_id}/services/completed
In addition, the Query Services and Query States operations enable to retrieve the nested states and/or tasks, within the results. For instance, the following query operation returns the active services within their active states associated with the customer profile ABC1234. Operation
GET /customers/ABC1234/services/active?active_states=true
Response
[ // returned in an array
{ "customer_id": "ABC1234",
"service_id": 4692834,
"est_duration": 86400,
"started": {
"timestamp": "2009-05-07T12:05:20.157",
// additional Start Event fields
},
"active_states":
[// included given specification of "results" attribute
{ // array of one or more State objects
"state_id": 5005,
"state_type": 8, // service delivery
"started": {
"timestamp": "2009-05-07T12:08:53.298",
// additional Start Event fields
}
}
]
}]
Complete Service/State/Task
When your customer stops interacting with the given service, state, or task, you must complete this resource and mark it as terminated in the UCS database. This enables you to filter the result of query operations based on the resource status (as described in the Active Resources section).
- You are responsible for performing the Complete Service, Complete State, Complete Task operations for any service, state, or task that you started.
- These operations apply only to the resource specified in the operation's parameter and they do not modify the status of the nested states and tasks, if any.
The only case which does not force you to explicitly complete a state with the Complete State operation, is Perform State Transition, which completes the given state then starts a new state.