Cisco Cisco Computer Telephony Integration Option 9.0 Reference Guide
Chapter 3 Customization
Siebel Customization Basics
3-2
CTI Driver for Siebel 7 Reference Guide for Cisco ICM/IPCC Enterprise & Hosted Editions, Release 7.0(0)
Siebel Customization Basics
When the Cisco Driver receives call and agent state change events, it creates a
corresponding Siebel event. This triggers a set of actions defined within the Siebel
database, such as a screen pop performed on an incoming call.
corresponding Siebel event. This triggers a set of actions defined within the Siebel
database, such as a screen pop performed on an incoming call.
The Siebel application is highly customizable. You can use the Siebel Visual
Basic-like or Java-like scripting language for additional customization. The
customizable Siebel database tables can be imported or exported to plain text DEF
files. An example of a DEF file is shown in
Basic-like or Java-like scripting language for additional customization. The
customizable Siebel database tables can be imported or exported to plain text DEF
files. An example of a DEF file is shown in
A Siebel event consists of a Siebel event name followed by one or more
parameters. These parameters can be used in conjunction with the customization
code to determine what action to take on any event.
parameters. These parameters can be used in conjunction with the customization
code to determine what action to take on any event.
maps the Cisco
Driver for Siebel 7 events to Siebel event names. The parameters passed with
every call event are listed in
every call event are listed in
.
Typical arguments passed with an event, for example, OnCallEstablished (the
equivalent Siebel event is EventAnswer), would include ANI, DNIS, CallStatus,
Call Variables, and more.
equivalent Siebel event is EventAnswer), would include ANI, DNIS, CallStatus,
Call Variables, and more.
In order to understand the Siebel customization process better, consider the issues
involved when a call arrives and is answered by an agent. For this example (see
involved when a call arrives and is answered by an agent. For this example (see
), assume screen pop uses the customer account number passed in
CallVariable1:
•
If an inbound call is received on the primary agent’s extension, a screen pop
should be performed using the customer account number, passed in this
example in CallVariable1.
should be performed using the customer account number, passed in this
example in CallVariable1.
•
If the call does not have an account number, a new customer form should
screen pop. (Some fields might automatically be pre-populated with
information from other call variables.)
screen pop. (Some fields might automatically be pre-populated with
information from other call variables.)
•
If the call is a transfer from another agent, the agent should go to the
NotReady state and receive a transfer of the current agent’s screen context,
that is, the forms that the agent had been using in handling this call. They
might already contain pre-populated information with the customer’s name,
address, preferences, and order history.
NotReady state and receive a transfer of the current agent’s screen context,
that is, the forms that the agent had been using in handling this call. They
might already contain pre-populated information with the customer’s name,
address, preferences, and order history.