Jump to: navigation, search

The Callback Service

The callback service is the ICallbackService interface defined in thecom.genesyslab.ail.ws.callback namespace. It covers the management of callback records.


The callback service is a feature that depends on the Genesys voice callback server. If your call-center includes a callback server, customers can request a callback as soon as possible or at a specific calendar time. The voice callback server records the request and puts it in an appropriate queue.
The callback service deals with the records—customers’ callback requests—managed by the voice callback server. Each record contains the information required to call back the customer.
If an available agent using your application is logged in, he cans receive a callback record event and an interaction event. The agent can accept the record and process the callback with a voice interaction.
The callback service is designed to let your application perform the following agent actions on records:

  • Accept or reject a record.
  • Mark a record as processed when the callback is done.
  • Reject or reschedule a record.
  • Access a record’s information.

The callback service cannot be used independently from:

  • The agent service—This service lets your application log an agent in on a voice media (DN) to process the record.
  • The voice interaction service—This service deals with the voice interactions that process the records.
  • The event service—This service required to receive voice and record events.

The following sections details the callback service.

Callback Essentials

  The callback service of your agent application processes callback records from the point of view of a calling agent. Therefore, it manages callback records as data attached to a voice interaction.
When an agent gets a callback record from the OCS (Outbound Contact Server), he also gets a voice interaction to dial the callback. An agent can either accept or reject a callback record. An agent processes a callback as a normal phone call with this voice interaction. The management of this voice interaction does not differ from the management described in Voice Interactions.
The data of a callback record includes the ID of the corresponding voice interaction. Once the call is terminated, the agent can mark the callback record as processed.
The management of a callback voice interaction correlates to the management of its callback outbound record. Your application should use the voice interaction service to deal with all voice-specific aspects of a callback voice interaction.
The following figure shows how your application should integrate the callback service to handle records.

Callback Integration Example

Login an agent on a voice media.

  1. Record and interaction events for a callback to process.
  2. The logged-in agent accepts the record.
  3. Receiving a record event for the record status change.
  4. Actions on the voice interaction to process the callback.
  5. Receiving record and interaction events due to 5.
  6. Marking the record as processed when call is IDLE.
  7. Receiving record event due to 7.

The Callback Integration Example shows the general callback service handling in an application that lets an agent accept and process records. The ICallbackService interface exposes methods and pertinent attributes that your application uses to manage record’s callback data, such as marking a call as processed or rescheduling a call.
The IInteractionVoiceService interface manages actions that are restricted to a voice interaction used to process a callback record (for example, dialing a call, releasing a call, or marking a call as done). For any particular state of an callback treatment, the callback service permits use of only a small subset of its possible actions (available to your application as method calls).
Actions of the callback and voice interaction services may modify these states. The event service receives both InteractionEvent and CallbackRecordEvent events that carry identifiers along with a variety of attributes reflecting new state and other data. To receive those events, your application must subscribe to them.
For each CallbackRecordEvent incoming event, as well as for InteractionEvent event, your application should test various attributes of the ICallbackService interface.
The following sections present the details behind the above general description of the callback service. For voice management, see Voice Interactions.

Record Attributes

The callback.record domain of the the ICallbackService interface defines a callback record’s characteristic data. The following list of data attributes is representative (but not exhaustive):

  • Attributes for informative purposes:
    • callback.record:contactInfo—Contact information needed to perform a callback (for example, a contact phone number).
    • callback.record:customFields—Collected data useful to an agent calling the customer back.
    • callback.record:scheduleDateTime—Date and time scheduled for processing a callback record (in the format: mmddyyyyhhmm).
  • Attributes for management purposes:
    • callback.record:recordId—Unique system ID of a record.
    • callback.record:interactionId—Unique system identifier of an interaction used to process a callback record.
    • callback.record:reason—Current reason for the callback record’s status.
    • callback.record:actionsPossible—Possible callback actions that can be performed on a callback record.

Depending on attribute properties, your application can read the attributes of this domain with the ICallbackService.getRecordsDTO() method, and can modify them with the ICallbackService.setRecordsDTO() method. From the agent’s point of view, a callback record does not exist independently from a voice interaction. Therefore, your application can use either a callback record ID or an interaction ID to access and manage records’ attribute values with those get and set methods. This choice is specified with a boolean parameter in those methods’calls.
The ICallbackService.getRecordsDTO() and ICallbackService.setRecordsDTO() methods use RecordDTO objects. The RecordDTO class associates a record ID with a key-value list of attributes. For further information, see DTOs Handling.

Record Actions

The RecordAction enumeration defines callback actions on records. Constants each correspond to one ICallbackService.*Record() method. For example, the RESCHEDULE constant corresponds to the ICallbackService.rescheduleRecord() method. The actions apply to all records.
From an agent’s point of view, a record does not exist independently from a voice interaction. Therefore, your application can use either an interaction ID or a record ID to perform callback record actions. This choice is specified with a boolean parameter in those methods’calls.
To determine which callback record actions are possible at a certain time, read the callback.record:actionsPossible attribute of the ICallbackService interface.When changes occur on possible actions, this attribute is published in CallbackRecordEvent events only. See Record Events.

Record Status

The RecordStatus enumeration lists the possible statuses for a callback record. The purpose of a callback record status is to determine if a certain callback record is previewed, opened, processed, or closed. Your application can display this status. Changes are propagated in a CallbackRecordEvent.

Record Events

When changes occur on a callback record, the event service of your application can receive CallbackRecordEvent events for the agent handling the callback.
CallbackRecordEvent events can propagate any published attribute, that is, attributes of the callback.record domain that have the event property. To properly take into account callback events, the published callback.record:eventReason attribute value indicates the reason for an event. The RecordReason enumeration lists the possible reasons for an occurring CallbackRecordEvent event. Most of the time, it points out a status change as presented in Record Event Reasons.

Record Event Reasons





callback.record:status callback.record:possibleActions

Record canceled.


callback.record:status callback.record:possibleActions

Record processed.


callback.record:estimatedWaitTimedate callback.record:estimatedWaitTime

Record rescheduled.


callback.record:status callback.record:possibleActions

Record rejected.



Unknown event.

The following code snippet subscribes to both CallbackRecordEvent and InteractionEvent.

/// Defining two TopicsService
TopicsService[] myTopicsServices = new TopicsService[2] ;
/// Defining a Topic Service for the callback service
myTopicsServices[0] = new TopicsService() ;
myTopicsServices[0].serviceName = "CallbackService" ;
/// Defining a topic event
myTopicsServices[0].topicsEvents = new TopicsEvent[1] ;
myTopicsServices[0].topicsEvents[0] = new TopicsEvent() ;
/// the targeted events are CallbackRecordEvent
myTopicsServices[0].topicsEvents[0].eventName = "CallbackRecordEvent" ;
/// all the event attributes values are propagated in event objects
myTopicsServices[0].topicsEvents[0].attributes = new String[]{ "callback.record:*"};
/// Triggering CallbackRecordEvent for agent0
myTopicsServices[0].topicsEvents[0].triggers = new Topic[1];
myTopicsServices[0].topicsEvents[0].triggers[0] = new Topic();
myTopicsServices[0].topicsEvents[0].triggers[0].key = "AGENT";
myTopicsServices[0].topicsEvents[0].triggers[0].value = "agent0";
/// Defining a Topic Service for the interaction service
myTopicsServices[1] = new TopicsService() ;
myTopicsServices[1].serviceName = "InteractionService" ;
myTopicsServices[1].topicsEvents = new TopicsEvent[1] ;
myTopicsServices[1].topicsEvents[0] = new TopicsEvent() ;
/// the targeted events are InteractionEvent
myTopicsServices[1].topicsEvents[0].eventName = "InteractionEvent" ;
/// in case of a voice interaction, the interaction, and 
/// voice interaction attributes values are propagated in the
/// Event object
myTopicsServices[1].topicsEvents[0].attributes = new String[]{ "interaction:*", "interaction.voice:*"};
/// Triggering CallbackRecordEvent for agent0
myTopicsServices[1].topicsEvents[0].triggers = new Topic[1];
myTopicsServices[1].topicsEvents[0].triggers[0] = new Topic();
myTopicsServices[1].topicsEvents[0].triggers[0].key = "AGENT";
myTopicsServices[1].topicsEvents[0].triggers[0].value = "agent0";

For further information about events, see The Event Service.

Records Management

The following table presents actions of the callback service which provides your application with callback management.

Callback Record Actions and Methods


ICallbackService Method




Agree to process a callback record.



Cancel a callback record.



Reject a callback record



Reschedule a callback record.



Mark a callback record as processed.

When an agent has to process a callback, your event service receives both an InteractionEvent and a CallbackRecordEvent event. An agent can either accept or reject processing of the callback.
If the agent has accepted a callback, your application uses the IInteractionVoiceService features to process the phone call, and uses the ICallbackService to manage the corresponding callback record.
A CallbackRecordEvent event propagates status changes for a callback record, which is identified by the callback.record:recordId attribute. Your application should test the callback.record:actionsPossible attribute to determine which actions are currently possible on this record.
The following sections detail the corresponding calls to methods of the callback service.

Accepting a Record

To accept a callback record, call the ICallbackService.acceptRecord() method. Your application can process the callback action with either the callback record ID or the companion voice interaction ID (represented by the callback.record:interactionId attribute).
Once the agent using your application has accepted the record, your application can provide him or her with management of the corresponding voice interaction.
The following code snippet shows a callback record accepted by its record ID for the agent0:

false, // the call is not performed with the Interaction ID 
myRecordId); // Id of the callback record accepted by agent0

Rejecting a Record

When an agent does not want to process a record, he or she can reject the record, so that the callback record returns in a queue and another agent processes the callback record.
Use the ICallbackService.rejectRecord() method to reject the record, as shown in the following code snippet:

false, // the call is not performed with the Interaction ID
myRecordId); // Id of the callback record accepted by agent0

Canceling a Record

When an agent cancels a callback record, the callback record is removed from the queue and will not be processed further.
Use the ICallbackService.cancelRecord() method to cancel the record, as shown in the following code snippet:

false, // the call is not performed with the Interaction ID 
myRecordId); // Id of the callback record accepted by agent0

Rescheduling a Record

A customer might ask an agent to reschedule the call. Once the callback is rescheduled, it takes its place in the appropriate queue. A new companion voice interaction is created according to the scheduled date and time.
Use the ICallbackService.rescheduleRecord() method to reschedule the record, as shown in the following code snippet:

false, // the call is not performed with the Interaction ID 
myRecordId, // ID of the callback record accepted by agent0.
myDate); // long date in second, UTC

Marking a Record as Processed

When a callback record has been processed, an agent must mark the record as processed.
Use the ICallbackService.processedRecord() method to mark the record as processed, as shown in the following code snippet:

  false, // the call is not performed with the Interaction ID 
   myRecordId); // ID of the callback record accepted by agent0.


Comment on this article:

blog comments powered by Disqus
This page was last modified on 8 January 2014, at 09:25.