Jump to: navigation, search

Implementation Changes in 8.5

In this page, you will learn about the major differences between the 8.1 and 8.5 versions of the Context Services API. In addition to architecture changes, some features were deprecated and other were improved to increase the API usability and performance results.

A New Architecture

In 8.5, Context Services is available on top of Genesys Mobile Services (GMS). This means that your application no longer needs a connection to the Universal Contact Server (UCS) to manage services, states, and tasks. Data related to customer management (contact information, profiles, interactions) are still available for backward compatibility in UCS. See Architecture for details.

So, if you are upgrading from a version anterior to 8.5, you must read the migration instructions.

Multi-Tenancy

You will find instructions in the User's Guide to configure your Context Services application in a multi-tenant environment. Then, you just add two headers to handle the Tenant information in your queries (click here for details).

If you do not need multi-tenancy, you don't have anything to change in your application.

API URL

Context Services is now available on top of GMS. You should access the context services through the /genesys/1/cs/ base URL, as for example:

POST http://localhost:8080/genesys/1/cs/services/start

You can still access Customer Profiles in UCS. To simplify your deployment, you should deploy your UCS application with the cview/base_url option set to /genesys/1/cs as detailed in the migration page.

Customer Profile API

Customer Profiles includes Contact Profiles and Interactions APIs. This UCS API is not available in the new Context Services API developed on top of GMS. It remains in UCS, either exposed as HTTP or ESP protocol, as detailed in the new architecture page.

This feature is optional. You no longer need the Customer Profile API and a connection to UCS to use Context Services. See the migration page for further details.

This API is not concerned with major changes such as universal unique identifiers or new JSON extensions. The management of this API did not change in 8.5 and does not differ from the former latest 8.1 version, except for a few deprecated queries (see the list here). For a detailed list of resources and queries, refer to the Context Services API Reference.

Resource Identifiers

Services, States, Tasks resources use Universal Unique Identifiers(UUIDs), instead of former legacy numbers (64bit or 32bit).

Important
This change does not concern the Customer Profile API.

Extensions Metadata and Schema Management

Extensions are now JSON key-value pairs in the Services API. You no longer have to manage extension schemas for objects of type service, state, and task. The JSON value of an extension ensures the backward compatibility for reading and writing service resources.

  • You can no longer remove a set of service, states, or task extension data associated with a specific schema in a single request.
  • Your application is responsible for managing any strong typing approach, for instance, to define which data is mandatory or not.
  • Your application is responsible for maintaining extension uniqueness across the database.
  • Your application can no longer use queries which include the "by unique" criteria.

You can get a list of deprecated queries here.

Exporting Capabilities

Context Services now includes exporting capabilities, available through new Services API operations. You can either export a list of service IDs (retrieved as a JSON object), or retrieve service data in a .CVS file. Additionally, the new operations include filters to refine your export action.

For further details, refer to the Export features page.

Purging Capabilities

In 8.5, Context Services provides purging capabilities based on the Time to Live (TTL) criteria and assigns an expiration date to any data added to the Cassandra database. You can perform purging tasks through the Purge Service query or schedule tasks in the Configuration Server, as detailed in the user guide.

Role-Based Access Control

The role-based access control is simplified. You need Administrator or Supervisor privileges to handle services, states, and tasks. Click here to get more information about these privileges.

Important
Role-based access control did not change between 8.1 and 8.5 for any customer profile management.

Business Attributes Mapping

You will now use enumerated names, available from the CME/GAX enumerator instead of numbers. Context Services automatically validates enumerated names, then converts these names into DBIDs for further storage.

Additionally, the Context Services can transform from/to and Long/String properties during the serialization and de-serialization process.

Important
In a single-tenant environment, this configuration is also compatible with UCS/CS.

Event Submissions

Your application now deals with Start, End, Transition, and Associate for Service, State, Task events. These events include the following properties, in addition to optional attached key-value pairs:

  • contact_key
  • customer_id
  • service_id
  • state_id
  • task_id
  • service_type or state_type or task_type
  • previous_state_id
  • est_duration
  • disposition
  • disposition_desc
  • status (which indicates if the complete action occurred)
Important
The other fields of the start/completed events are stored as part of ActivityEvent events.

Deprecated Queries

The following queries are no longer available, due to architecture or data changes (read the previous sections for further details.)

PUT /services/${service id}/extensions/${ext name}/by/unique
PUT /services/${service id}/extensions/${ext name}/delete/by/unique
PUT /services/${service id}/state/${state id}extensions/${ext name}/by/unique
PUT /services/${service id}/states/${state id}/extensions/${ext name}/delete/by/unique
PUT /services/${service id}/task/${task id}extensions/${ext name}/by/unique
PUT /services/${service id}/task/${task id}/extensions/${ext name}/delete/by/unique
POST /metadata/services/extensions
GET /metadata/services/extensions
POST /metadata/states/extensions
GET /metadata/states/extensions
POST /metadata/tasks/extensions
GET /metadata/tasks/extensions
DELETE /metadata/services/extensions/${extension-name}}
DELETE /metadata/states/extensions/${extension-name}
DELETE /metadata/tasks/extensions/${extension-name}


New Interfaces

Thanks to the new architecture, we implemented two additional interfaces for you in the GMS Service Management Interface:

These tools are intended for developers and administrators. (Tell me why.)

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on 26 April 2018, at 20:44.