Section II – Functional Modules > Interaction Interface Bottom of Page
| Genesys 8.0 SCXML Technical Reference
< Queue Interface Voice Interaction Interface >

## Interaction Interface

The primary model for a media channel is the interaction model. This model is the core functionality of our products today. It is the main model that interacts with and is used by the orchestration logic.

This model will not be changed from what it is today, but the orchestration platform will have a model interface to expose its functionality to the orchestration logic.

The following defines what the interaction model is and its relationships and interactions with the orchestration model.

Definition | An interaction represents the various types of communications between a resource and a customer: Conversation-based communication between a customer and given contact center or enterprise resources using a single logic media (certain media may support more than one media type over an interaction (voice and video) (for example, a voice call or a chat session). This type of interaction involves a series of information being communicated back and forth. Message-based communication with a customer (for example, an incoming e-mail or sms or an outgoing e-mail or sms). Web-based communication with a customer (for example, web page activity).
Model | The interaction model is an event-driven state machine model.
Layers | An interaction has two layers. The number of layers depends on the media type. Control layer — This layer provides the functionality to control the state of the interaction and the resources involved in the interaction. Media Stream layer — This layer provides the functionality to control the execution of dialog applications and media in order to communicate with the customer.
Lifecycle | The different interaction types have their own lifecycle and control characteristics. The following are the characteristics of the different media types of interactions: Voice or Phone — Conversation-based The voice interaction begins when a customer initiates a call with a resource or when a resource initiates a call with a customer. The voice interaction ends when the resources (transferring party) currently associated with the interaction leave the call, but the session can be moved to new resources (transferred to parties), or when the customer leaves the interaction. Follows the lifecycle definition of T-Server calls (connIDs). Chat — Conversation-based The interaction begins when a customer initiates the chat session with a resource. The interaction ends when the resource disconnects from the chat session or when the customer leaves the chat session. Follows the lifecycle definition of Interaction Server interactions. E-mail or Fax — Message-based The e-mail interaction begins when a resource receives the e-mail. The e-mail interaction ends when a resource has read it and processed it. This model blurs the line between interactions and orchestration applications, but the interaction is needed to control and track the movement of the e-mail media from resource to resource. Follows the lifecycle definition of Interaction Server interactions. SMS — Message-based or conversation-based depending on how the system is implemented. Message-based implementation will have the same characteristics as e-mail. Conversation-based implementation will have the same characteristics as chat. Web activity — Web-based The Web activity interaction begins when a person starts using a known web page. The Web activity interaction ends when the person is not using known web pages for a period of time (configured) or the person has take an action which indicates that they have left (logged out of the website, selected and is part of another interaction (voice or chat), and so on).
Properties | The following types of properties are maintained with an interaction: Interaction state information (state, reason for the state, and so on). Customer ID — It will be the link to the associated customer view information. Application attached data. Media-specific customer identification data. Media-specific characteristic data (media type, bandwidth, current dialog application being executed, and media resources being used (for example, TTS engine)). Resources and media devices involved in the interaction.
Characteristics | The different interaction types have their own characteristics. The following are the characteristics of the different media interaction types: Voice or Phone — Conversation-based One person can speak at one point in time. More than one person can hear that. The customer can be on hold for some time. The resource can be on after-call work time, but this is not part of the interaction. It is part of the orchestration logic, because the interactions have ended. The resource can either be ready or not ready to take a call. More than one subject or service can be discussed on the phone. Chat — Conversation-based The resource can either be ready or not ready to take a chat. The resource can be on after-call work time, but this is not part of the interaction. It is part of the orchestration logic, because the interactions have ended. One chat session equals one voice interaction. More than one subject or service can be discussed on a chat. E-mail or Fax — Message-based The resource can either be ready or not ready to work on an e-mail. More than one real subject or service can be within one e-mail. The e-mail interaction is equivalent to a one-way voice call (voice mail, voice proactive notification, with no interaction needed). An incoming e-mail and the resulting reply e-mail are two separate e-mail interactions. SMS — Message-based or conversation-based depending on how the system is implemented. Message-based implementation will have the same characteristics as e-mail. Conversation-based implementation will have the same characteristics as chat. Web activity — Web-based The Web activity interaction begins when a person starts using a known web page. The Web activity interaction ends when the person is not using known web pages for a period of time (configured) or the person has taken an action which indicates that they have left (logged out of the website, selected and is part of another interaction (voice or chat), and so on). The resource can either be ready or not ready to work on an web activity More than one real subject or service can be within one web activity.
Relationships | An interaction has relationships with the following: Resources and Media Channels — Resources and the corresponding media channels or devices are connected to the interaction to help drive the communications with the customer. Dialog application — An interaction, in conjunction with the resource's device, executes a dialog application at the request of some other form of logic (for example, an interaction process). The dialog application uses the capabilities of the interaction, its media stream, and the resource-associated device to deliver and collect the needed information from the customer or potentially the resources on behalf of the customer. Orchestration logic — Orchestration logic uses the interaction to do the following: Execute specific dialog applications Initiate new interactions to the customer or to other resources Control the interaction to meet the needs of the specific logic (for example, redirect the interaction to a new resource, add a new resource)
Today's Equivalent | The following are the equivalents today and will not likely change as a result of adding the orchestration parts of the model. T-Server — Call and connections (AIL and GIM define them as interactions). Interaction Server — Interaction for chat, e-mail and open media. For message-based interactions, there is a blurred line between interactions and orchestration applications, but both are needed and represented.

Relationship of Interaction Model to Orchestration

Due to the complexity of this model, there will actually be a two-tier hierarchy for the Interaction model interface. The first tier will define all the common capabilities of an interaction. This will have its own model interface. The second tier will define the common capabilities for a specific media type (voice, e-mail, and so on). Each media type will also have its own model interface.

Two-Tier Hierarchy for Interaction Model Interface

An Interaction Provider Module (implementation) provides the capabilities of the appropriate set of interaction model interfaces to support the media channel it is representing.

The model is proprietary, but we are considering using CCXML instead.

Section II – Functional Modules > Interaction Interface Top of Page
| Genesys 8.0 SCXML Technical Reference
< Queue Interface Voice Interaction Interface >