CA2318287A1 - System integrated framework - Google Patents
System integrated framework Download PDFInfo
- Publication number
- CA2318287A1 CA2318287A1 CA002318287A CA2318287A CA2318287A1 CA 2318287 A1 CA2318287 A1 CA 2318287A1 CA 002318287 A CA002318287 A CA 002318287A CA 2318287 A CA2318287 A CA 2318287A CA 2318287 A1 CA2318287 A1 CA 2318287A1
- Authority
- CA
- Canada
- Prior art keywords
- argon
- adapter
- client
- server
- agent
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
Description
White Paper Argon, Version 1.0 Document History:
Created - June 22, 2000 Revised -Revised -Finalized -S O L U T I O N 5 1 N C.
C T ~ I V R ~ I N T E R N E T
July 29, 2000, 11:59 AM Page 1 of 20 Argon White Paper Table of Contents 1. ABOUT THIS
DOCUMENT.......................................................................
........................................ 3 1.1 PURPOSE AND
SCOPE..........................................................................
............................................. 3 I .2 AUDIENCE
...............................................................................
........................................................ 3
Created - June 22, 2000 Revised -Revised -Finalized -S O L U T I O N 5 1 N C.
C T ~ I V R ~ I N T E R N E T
July 29, 2000, 11:59 AM Page 1 of 20 Argon White Paper Table of Contents 1. ABOUT THIS
DOCUMENT.......................................................................
........................................ 3 1.1 PURPOSE AND
SCOPE..........................................................................
............................................. 3 I .2 AUDIENCE
...............................................................................
........................................................ 3
2. WHAT IS ARGON.
...............................................................................
.............................................. 4
...............................................................................
.............................................. 4
3. WHY
ARGON..........................................................................
................................................................ 5 3.1 THE
MOTIVATION.....................................................................
............................................................. 5 3.2 ANATOMY OF A CTI PROJECT
...............................................................................
................................ 5 3.2.1 Programming the IVR............................................................................
........................................ .5 3.2.2 Programming the Interaction Router ...............................................................................
............. .5 3.2.3 Developing and Deploying the Desktop Client Application.......................................................... 6 3.2.4 Designing and Implementing Interaction Reports........................................................................
. 6 3.3 PROBLEMS WITH THE TRADITIONAL DESKTOP CLIENT APPLICATION
................................................... 7 3. 3. I A Lack of Separation ...............................................................................
...................................... 7 3.3.2 Ubiguitous Deployment Issues ...............................................................................
....................... 7 3.4 TRADITIONAL DESKTOP CLIENT APPLICATIONS RESIST CHANGE
......................................................... 7
ARGON..........................................................................
................................................................ 5 3.1 THE
MOTIVATION.....................................................................
............................................................. 5 3.2 ANATOMY OF A CTI PROJECT
...............................................................................
................................ 5 3.2.1 Programming the IVR............................................................................
........................................ .5 3.2.2 Programming the Interaction Router ...............................................................................
............. .5 3.2.3 Developing and Deploying the Desktop Client Application.......................................................... 6 3.2.4 Designing and Implementing Interaction Reports........................................................................
. 6 3.3 PROBLEMS WITH THE TRADITIONAL DESKTOP CLIENT APPLICATION
................................................... 7 3. 3. I A Lack of Separation ...............................................................................
...................................... 7 3.3.2 Ubiguitous Deployment Issues ...............................................................................
....................... 7 3.4 TRADITIONAL DESKTOP CLIENT APPLICATIONS RESIST CHANGE
......................................................... 7
4. WELCOME TO
ARGON..........................................................................
.............................................. 9
ARGON..........................................................................
.............................................. 9
5. THE ARGON FRAMEWORK
...............................................................................
............................. 10 S.1 THE ENGINE ADAPTER MODEL
...............................................................................
............................ 1 O
5.2 ENGINE CONFIGURATION
...............................................................................
..................................... 1 O
5.3 ARGON CTI CLIENT
APPLICATION....................................................................
.................................. 1 1 5.4 ARGON AGENT MODEL
...............................................................................
........................................ 12 5.5 PORTAL AGENT
...............................................................................
.................................................... 12 5.6 DEPLOYMENT.....................................................................
................................................................. 13
...............................................................................
............................. 10 S.1 THE ENGINE ADAPTER MODEL
...............................................................................
............................ 1 O
5.2 ENGINE CONFIGURATION
...............................................................................
..................................... 1 O
5.3 ARGON CTI CLIENT
APPLICATION....................................................................
.................................. 1 1 5.4 ARGON AGENT MODEL
...............................................................................
........................................ 12 5.5 PORTAL AGENT
...............................................................................
.................................................... 12 5.6 DEPLOYMENT.....................................................................
................................................................. 13
6. ARGON
MESSAGING......................................................................
.................................................... 16 6.1 ARGON MESSAGE
TYPES..........................................................................
...........................................
Figure 7 - Argon Message Types..........................................................................
............................................
I
G
6.1.1 Event Message........................................................................
.....................................................
6.1.2 Reguest Message........................................................................
..................................................
6.1.3 Response Message........................................................................
...............................................
6.2 ARGON MESSAGE
CATEGORIES.....................................................................
......................................
6.2. I Management Messages.......................................................................
.........................................
6.2.2 Configuration Messages.......................................................................
.......................................
6.2.3 Generic Messages.......................................................................
.................................................
MESSAGING......................................................................
.................................................... 16 6.1 ARGON MESSAGE
TYPES..........................................................................
...........................................
Figure 7 - Argon Message Types..........................................................................
............................................
I
G
6.1.1 Event Message........................................................................
.....................................................
6.1.2 Reguest Message........................................................................
..................................................
6.1.3 Response Message........................................................................
...............................................
6.2 ARGON MESSAGE
CATEGORIES.....................................................................
......................................
6.2. I Management Messages.......................................................................
.........................................
6.2.2 Configuration Messages.......................................................................
.......................................
6.2.3 Generic Messages.......................................................................
.................................................
7.0 CUSTOMIZATION..................................................................
............................................................
7.1 CUSTOMIZING THE PORTAL (ARGON WEB CLIENT~
............................................................................
7.2 CUSTOM ADAPTER
SERVERS........................................................................
.......................................
Figure 8 - Custom Adapter Classes........................................................................
...........................................
7.3 WINDOWS CLIENT
SERVICES.......................................................................
.........................................
7.4 CUSTOM CONFIGURATION SCRIPTS
...............................................................................
.......................
Page 2 of 20 Argon White Paper 1. About this Document 1.1 Purpose and Scope This document describes the motivation behind the development of Argon and presents a brief overview of the Argon framework.
9.2 Audience This document is written for software developers, information services persomlel, and other technical people who are considering using Argon to streamline the development and maintenance of a contact center solution.
Page 3 of 20 Argon White Paper 2. What is Argon?
Argon is a collection of pre-built software components that can be used to dramatically reduce the amount of effort required to develop, deploy, and maintain contact center solutions.
Page 4 of 20 Argon White Paper 3. Why Argon 3.1 The Motivation Much of the motivation behind the development of Argon has been to solve the addressable problems that the engineers at Aria Solutions Inc. continuously encounter while working on computer telephony integration (CTI) projects. It was observed that, although each project had certain aspects that were unique, there was a great deal of effort being expended solving the same problems over and over. In addition, it was becoming clear that certain Internet technologies were maturing rapidly and could be used to simplify various tasks or even remove them altogether.
3.2 Anatomy of a CTI Project A CTI project involves making your telephone network talk to your computer network in such a way that allows you to better serve your customers, make more sales, and make more money. A CTI project typically involves the following tasks.
3.2.1 Programming the IVR
When a customer calls your customer service line the call is answered by a computer and an automated voice asks her to enter her account number on her touch tone phone. This is the IVR. Typically, the IVR asks you to enter some kind of identification number. The IVR associates the identification number with the call. This is how your computers know, to whom you are speaking on the phone. Usually, the IVR provides a self service menu to the caller. Typically the self service menu allows to perform tasks that she can efficiently do for herself such as check her account balance, change her address, or pay a bill. The self service menu is typically available twenty four hours a day, seven days a week (24x7), giving the caller access to your business even during those times when your office is closed.
The IVR must be programmed so that it knows how to respond to touch-tones and what messages to play. Messages are recorded and an IVR script is written that defines the behavior of the IVR.
3.2.2 Programming the Interaction Router Of course, some interactions require a real live human being on the other end of the line.
Typically the IVR allows the user to press a digit, usually zero, to speak to a customer care representative. This is where call routing comes in. When the caller presses zero to speak to a customer care representative, focus shifts to routing the call to the real live human being who is best equipped to handle it. Call routing is usually based on where the caller was in the IVR menu structure when they pressed zero and the set of information identified by the caller's identification number. This set of information is often called the Page 5 of 20 Argon White Paper customer profile. The people who take the calls, the customer care representatives or contact center agents can be set up with skills that have specific scores. An example of a skill might be the ability to speak French. If the caller's customer profile indicates that they speak French the call will be routed the available agent that has the highest score in the French skill. If none of the available contact center agents speak French, the call waits in a call queue until a French-speaking agent becomes available. While the call is waiting in the queue, every so often a message is played to the caller indicating how important her call is and so on. In addition, the caller may have purchased a certain level of service.
This service level is recorded in the caller's customer profile and can be used to prioritize her call among all the other calls that are waiting to be serviced.
Routing is handled by a piece of software called an interaction router. The interaction router must be programmed to retrieve the customer profile from a database so that it can be checked against agent skills. The interaction router may also associate customer profile information with the call so that it can be displayed by an application running on the target agent's desktop computer. Typically, the programming is embedded in a routing script that defines how calls are to be routed.
Note that the piece of software that routes the calls is called an interaction router rather than a call router because it can route other interactions besides calls.
Typically, skill-based routing can also be applied to emails and chat sessions.
3.2.3 Developing and Deploying the Desktop Client Application After the call has been routed to the appropriate agent's phone, the focus shifts to getting the information that is associated with the caller to the agent that receives the call.
Usually this information is associated with the call by the interaction router and is displayed in an application window that makes itself visible when the target agent's phone rings. Typically, this desktop application also includes a set of controls called the soft phone that allow the agent to perform telephony operations such as answer, hang up, transfer, conference, hold, and retrieve from his computer. Often, a contact center agent that is equipped with a headset and a desktop client application can handle calls using their computer without having to touch the physical phone. A piece of software called a telephony server talks to the phone switch and makes phone switch events and requests available to the computer network so that the client application knows when a particular agent's phone rings and can submit requests to control the call.
The desktop application is usually custom written in a programming language such as Microsoft Visual Basic, Java, or C++ and must be deployed each agent's desktop.
3.2.4 Designing and Implementing Interaction Reports Interaction reports are designed so that you can track the performance of your contact center. These reports allow you to identify how long customers are kept waiting in queues, how many customers abandon the call before it reaches an agent, how long on average agents spend handling calls, etc. For example, you might find that at certain Page 6 of 20 Argon White Paper times the contact center gets a flood of calls and customers end up waiting too long in call queues. This may indicate that you should plan to deploy more agents at these times.
Often, the desktop client application provides a mechanism by which an agent can associate wrap-up codes with an interaction. Wrap-up codes indicate what a call was regarding. Some examples of wrap-up are purchase, complaint, billing, personal information change, general inquiry, etc...
Interaction reports that involve wrap-up codes give you insight into your business. For example, if you suddenly get a flood of calls about billing, this may indicate there is a problem with your billing process or perhaps the bill that you are sending to customers is unclear.
In any case, the reports that are required to illuminate these important patterns of call center interactions have to be designed and implemented.
3.3 Problems with the Traditional Desktop Client Application It was determined that the many of the addressable problems associated with computer telephony integration surround the desktop client application. 'This is because the development of the desktop client application requires the bulk of the custom programming. In addition, the desktop client application, unlike the routing and IVR
scripts, have to be deployed on each agent's desktop.
It was observed that most of the problems surrounding the desktop client application result from the following:
3.3.1 A Lack of Separation Business and CTI logic is often intertwined in the desktop client applications. This meant that a new client application would have to be developed for each customer even though the CTI logic was essentially the same. In addition, even simple changes to business content required expensive computer telephony expertise to avoid breaking existing CTI
logic.
3.3.2 Ubiquitous Deployment Issues Deployment of the client applications on even a small number of desktops posed significant problems. There would often be conflicts with other applications.
Sometimes, there would be a lack of resources on the desktops. Often, customers would insist that the deployment of the desktop client application be performed by an already over-burdened information services staff, resulting in delays.
3.4 Traditional Desktop Client Applications Resist Change Traditional desktop client applications are simply not dynamic enough to keep up with the changing needs of most businesses. Once the desktop client application has been Page 7 of 20 Argon White Paper deployed it becomes difficult to change it. Firstly, because the CTI and business logic is not sufficiently separated, making changes to the desktop client application requires an experienced CTI programmer. Experienced CTI programmers are uncommon and expensive. Secondly, because the benefit of each change is weighed against the substantial effort that is required to deploy that change on all agent desktops, many changes do not get deployed.
In business it is important to be able to capitalize on opportunities. The desktop client performs a very important function in your contact center. It delivers the information that an agent needs to service a customer at the exact moment of contact. When a customer or potential customer contacts your organization, this presents an opportunity.
An opportunity to build a relationship, make more contacts, make another sale.
The desktop client delivers the information that the contact center agent needs to capitalize on these opportunities. As time races on at Internet speed, opportunities change, sometimes overnight. To allow contact center agents to fully capitalize on new opportunities as they arise, the desktop client has to be dynamic. The desktop client has to deliver the appropriate information for each new opportunity.
Page 8 of 20 Argon White Paper 4. Welcome to Argon Argon gives you the power to capitalize on opportunities by giving control over information delivery to the person that knows your business, you.
With Argon the desktop client application is deployed as a set of web pages that are downloaded and executed in a web browser. To start the Argon Web Client the agent simply navigates their browser to the designated universal resource locator (URL) and Iogs in. As long as a compatible browser exists no client-side installation is required.
The Argon Web Client appears as a separate window that is divided into frames.
There is a soft phone frame that provides buttons such as answer, hang up, transfer, etc. that allows the agent to control phone calls. There is a short cuts frame that gives the agent quick ways to deal with a call such as, transfer to sales, and transfer to collections. It is up to you to define what short cuts appear. Finally, there is a large frame called the content frame. Although, typically, information such as the customer profile appears in the content frame when the agent's phone rings, the information that appears in the content frame is completely up to you.
Navigate your browser to another UItL and the Argon Administration Client appears.
The Argon Administration Client allows you to define the behavior of the Argon Web Client. With a few mouse clicks you can specify what UIZL you would like to appear in the content frame when a particular telephony event occurs. With a few more mouse clicks you can also specify what information you would like to appear in the request to that URL. In most cases you would at least specify that the caller's identification number be passed along. Similarly, you can define what short cuts should appear in the short cuts frame, when a particular event occurs. Any changes that you make using the Argon Administration Client will take affect when the next contact center agent logs in to a web client.
This short description illustrates how Argon solves the problems associated with traditional CTI client development.
Business logic and CTI logic are separate. The task of creating the server-side script that displays business content in the Argon web client can be given to a web developer without that web developer having to know anything about CTI. All the web developer needs to know is that at the appropriate time the server-side script will be invoked, with the customer identification number as a parameter. The server-side script can be written and tested independently of CTI activities.
Argon inherits none of the deployment problems encountered with traditional CTI client applications, because client-side deployment is virtually non-existent.
Page 9 of 20 Argon White Paper 5. The Argon Framework 5.1 The Engine Adapter Model At the heart of the Argon framework lies the engine-adapter model. The general engine-adapter model is depicted with a UML object diagram in figure 1.
Communicates with Ada er1 Communicates with Communicates with Communicates with Ada er4 ~ ~ Engine ~ Communicates with ~ Ada er2 Communicates with I Communicates with Ada era ~ Communicates with Figure 1 - General Engine-Adapter Model The behavior of Argon clients such as the Argon Web Client is controlled by an object called an engine. The purpose of the engine is to distribute Argon messages among adapter objects according to the rules that are specified in the engine's configuration.
Adapter objects are responsible for communicating with systems that are external to Argon. Each adapter objects translates between the Argon messaging protocol (AMP) and whatever protocols or interfaces are supported by the associated external system.
5.2 Engine Configuration Engines are configured by a configuration object, depicted below in figure 2.
Page 10 of 20 Argon White Paper Configures Figure 2 - Engine Configuration When the engine is created it is given the URL of a server-side script that produces the configuration. The engine creates a configuration object and passes the URL to it. The configuration object connects to the URL and receives a stream of XML.
Contained within the XML are the rules that define how the engine distributes messages among the associated adapters.
The server-side script generates the XML by querying the Argon configuration database.
This is the database that you are modifying when you make changes with the Argon administration client. You can get a good idea of what the configuration XML
will look like when you click on an application's XML link in the Argon Administration Client.
5.3 Argon CTI Client Application The Argon CTI client application is a specialization of the general engine-adapter model is depicted with a UML object diagram in figure 3.
~unicates with Page 11 of 20 Argon White Paper Figure 3 - Argon CTI Client Application In the case of the CTI client application, there are two external systems, the telephony server and the web browser.
The CTI adapter translates between calls to the telephony server interface and Argon messages. For example, when the agent's phone rings the CTI adapter is notified and sends an Argon event message to the engine. If the engine sends a request to the CTI
adapter to answer a call, the CTI adapter makes the appropriate call through the telephony serverinterface.
The portal adapter translates between calls to the browser interface and Argon messages.
For example, when an agent clicks the answer button on the web client soft phone, the portal adapter is notified and sends an Argon event message to the engine. If the engine sends a request to navigate the web client content pane to a specific URL, the portal adapter makes the appropriate call to the browser interface.
5.4 Argon Agent Model The portal adapter is somewhat more sophisticated than other adapters like the CTI
adapter because it employs an object called an agent. The general Argon agent model is depicted in a UML object diagram in figure 4.
Communicates with Communicates wth En ine ass Throu h Ad a Aaent Communicates wth xternal S~ stem Figure 4 - General Argon Agent Model An agent is an object that is paired with a special kind of adapter called a pass through adapter. The adapter is called a pass through adapter because most of its work involves distributing messages to and from the agent. It is the agent that actually does the work of converting between the Argon messaging protocol and whatever protocol is supported by the associated external system. This means that the Argon messaging protocol is used between the engine and the pass through adapter as well as between the pass through adapter and the agent.
5.5 Portal Agent The portal agent is depicted with a UML object diagram in figure 5. Note that the pass through adapter, portal agent and the portal applet together are thought of as the portal adapter.
Page 12 of 20 Argon White Paper ~unicates with a The Argon Web Client includes an invisible frame that contains an applet called the Argon portal applet. This applet is loaded into the frame and executed when a contact center agent logs in. The portal agent is created as part the portal applet when the portal applet is executed. When the portal agent is created, it establishes a connection to the associated pass through adapter, essentially making the web client visible to the rest of the Argon framework. The web pages that are loaded into the web browser send and receive Argon messages by making calls (scripting) the portal applet which forwards those calls on to the portal agent. This is how the web browses knows, as an example, when the agent's phone rings.
5.6 Deployment Argon is written in Java, and is, therefore, largely platform independent.
Argon adapters, engines, and configuration objects are instantiated by server objects that run inside an Argon run-time environment. An Argon run-time environment is a class that executes in a single Java virtual machine. The Argon run time environment houses one or more Argon servers, and provides services such as logging. When an Argon run-time environment is deployed, it is associated with an XML file, which specifies attributes of the Argon run-time environment such as how to perform logging, as well as, which Argon server to run, and for each Argon server what arguments are required.
Because the server objects communicate with sockets, they can be deployed in a variety of ways. Server objects can be deployed on a single machine in a single Java virtual machine, on a single machine in separate Java virtual machines, or on multiple networked machines in separate Java virtual machines.
Page 13 of 20 Figure 5 - Portal Agent Argon White Paper The capacity of the Argon system is increased, by deploying additional Argon servers on new machines. You have the choice of, static load balancing by assigning certain agents or applications to particular servers, or having the Argon framework perform round-robin load balancing as engines and adapters are created.
Figure 6 is a UML deployment diagram that depicts a fully distributed Argon system where only the basic server types exist.
Database Server Machine 1 .._~.w..a~~_ Confiaurartion Server Machine 1 ~~ «HTTP (HML > DBMS 1 r..
Confiauration Server 1 1 -«AMP>r 1 -«ODBC»
1 I -«AMPn> ' ~-T Portal Adaater Server 1 ter Server Ma'bhi a 1 Teleohonv Server Machine 1 rt TCP»
Teleohonv Server CTI Adapter Server 1 1 -a<TCP~n Phone Switch AaeM Workstation 1 1 - Web Browser Figure 6 - A Fully Distributed Argon System In addition to the Argon servers, the following servers are required:
~ ODBC Compliant Database Server An Argon system requires an ODBC compliant database server to store Argon configuration information ~ Web Server °
Page 14 of 20 Argon White Paper An Argon system requires at least one web server to serve the web pages belonging to the Argon Web Client and Argon Administration Client.
~ Telephony Server This Argon system require a telephony server from a supported CTI vendor, so that the Argon CTI adapter can invoke the functionality of the phone switch.
Note that the portal adapter server is deployed on the web server. This is because, generally, applets can only make connections back to the web server that served them.
Page 15 of 20 Argon White Paper 6. Argon Messaging 6.1 Argon Message Types Argon messages fall into the three types that are depicted with a UML class association diagram in figure 7. All Argon messages are derivations of the following three message types.
Figure 7 - Argon Message Types 6.1.1 Event Message The event message is an unsolicited message that is sent from some object to indicate that some event has occurred.
6.1.2 Request Message The request message is a message that is sent to invoke some functionality in the destination object. A request message generates a unique transaction identifier that is used to match the request with the associated response.
6.1.3 Response Message The response message is a message that conveys the result of a particular request.
The response message maintains the unique transaction identifier of the associated request, so that the response and request can be matched.
6.2 Argon Message Categories In addition, Argon messages also fall into the following categories:
Page 16 of 20 Argon White Paper 6.2.1 Management Messages These are messages that Argon servers send to one another to manage Argon objects, such as requests to create and destroy adapter, engine, and configuration obj ects.
6.2.2 Configuration Messages These are the messages that a configuration object sends to an engine to define that engine's behavior, such as requests to add adapters, actions, and conditions.
6.2.3 Generic Messages These are the messages that are distributed among engines and adapters that result in or result from interactions with in external systems such as the telephony server or the Argon Web Client.
Generic messages are different from other messages in that the Argon engine does not know what the message means. Imagine that you create an action using the Argon Administration Client to send the pop request to the portal adapter when a ringing event arrives from the CTI adapter. When a ringing event arrives, the engine doesn't know that you are displaying a web page. All that the engine knows is that when an event called EventRinging arrives from adapter called the CTI adapter, it has to send a generic request called Portal.RequestPop to an adapter called the Portal Adapter. The engine also knows that a generic Argon event has a tree of key value pairs embedded within it. When you specify that you want key url.parameter.acctNum in the request to equal userData.ACCT_NB in the event. The engine copies the value at userData.ACCT_NB in the data tree of the EventRinging event into url.parameter.acctNum in the data tree of the Portal.RequestPop request. The engine has no idea that this value is an account number.
The Argon adapters know the business of interacting with non-Argon systems.
The CTI adapter understands that when a ringing event arrives from the telephony server it has to create a generic generic Argon event called EventRinging, generate an Argon data tree from the data that the telephony server has sent v~~ith the event, and send it to the engine. Similarly the portal adapter understands that when it gets a generic request called Portal.RequesPop, it should take the url.name, url.parameters, and targetFrame values out of the request data tree, construct a URL, and load it into the target frame.
Adapter requests, events, and data trees are defined in an adapter schema that is imported into the Argon configuration database. The Argon administration client queries adapter schemas in order to populate choice lists when you are building configurations.
Page 17 of 20 Argon White Paper 7.0 Customization The Argon framework has been designed to allow a great deal of customization.
The following sections enumerate all the ways in which an Argon system can be customized.
7.1 Customizing the Portal (Argon Web Client) You can change the functionality that the portal exposes to Argon by adding to the JavaScript code that is included in the applet and soft phone frames of the Argon web client. Any functionality that you add can be made available to the Argon administration client by changing the portal adapter schema.
You can also change any part of the web client's user interface. The soft phone and short cuts user interface is dynamic html rather than applets so you are free to change the look and feel however you like.
7.2 Custom Adapter Servers If you would like to integrate one or more external systems that make up your business into the Argon framework, you can do it by creating a custom adapter server.
Argon comes with a Java class library that allows you to create your own custom adapter servers. You will have to know something about object-oriented programming to do it.
Depicted below in figure 8 is a UML class association diagram that shows the classes that are involved.
Page 18 of 20 Argon White Paper 0..1 ~ -createAdapter ~u~om Adapter -executeRequest 0..1 I -create Adapter Serv r Custom 0..1 -generateEvent ~interfacex Adapter 0..1 IAdapterFacto +createA dapter( +generateEvenl() ~~~1 ue.mhmiFt7ar.nnne.efl -submilResponse Figure 8 - Custom Adapter Classes The Argon framework is designed so that when you create a custom adapter server, you can concentrate on exposing the functionality provided by some external system, instead of worrying about the plumbing. In the diagram in figure 7, you implement the classes that have "custom" in the name. Of course, you are free to give them whatever name you like. In any case, you will need to implement a custom adapter, a custom adapter factory, and a custom adapter server.
Your custom adapter class extends the base adapter class. To add custom request-handling functionality to your adapter, override the executeRequest method.
This is the method that the Argon framework will call to notify your adapter that a request has arrived. It is important that your custom adapter's executeRequest method not do anything that will block your adapter server. Argon adapter servers are single threaded which means that any adapter requests that arrive, must wait in a queue until the adapter server has finished processing any previous requests. To generate events and submit responses call the generateEvent and submitResponse methods on the adapter base class.
Don't forget to include the transaction ID of the associated requests, when you submit responses. The Argon framework will take care of sending the appropriate generic message to the associated engine.
Your custom adapter server class extends the base adapter server class. In its constructor, your custom adapter server will need to call the constructor of the adapter server base Page 19 of 20 Argon White Paper class with a reference to your custom adapter factory. The Argon framework uses the supplied adapter factory to create instances of your custom adapter as required.
When you get it running don't forget to import the schema for the your custom adapter into the Argon configuration database so that the Argon Administration Client see it.
7.3 Windows Client Services If you have Windows client application that already exists on your contact center desktops, you can create an Argon client service application that allows you to expose interactions with that client to the Argon framework. An Argon client service is a Windows application that typically runs minimized on each client desktop, something like a PC Anywhere host.
To integrate with a Windows client application, you simply embed a client service control into your client service application. The client service control accepts connections from client service adapters. Argon comes with a client service adapter server that hosts the client service adapters. The client service control exposes an executeRequest event, a sendEvent method and a sendResponse method that can be used to communicate with the Argon framework.
Because you decide what requests and events your client service exposes, you are responsible for creating the adapter schema for your client service adapter.
Don't forget to import the schema for your client service into the Argon configuration database so that the Argon Administration Client can see it.
7.4 Custom Configuration Scripts The server-side script that generates the XML that is used to configure Argon engines can be modified or completely replaced as long as the Argon configuration objects see a valid XML stream.
Page 20 of 20
............................................................
7.1 CUSTOMIZING THE PORTAL (ARGON WEB CLIENT~
............................................................................
7.2 CUSTOM ADAPTER
SERVERS........................................................................
.......................................
Figure 8 - Custom Adapter Classes........................................................................
...........................................
7.3 WINDOWS CLIENT
SERVICES.......................................................................
.........................................
7.4 CUSTOM CONFIGURATION SCRIPTS
...............................................................................
.......................
Page 2 of 20 Argon White Paper 1. About this Document 1.1 Purpose and Scope This document describes the motivation behind the development of Argon and presents a brief overview of the Argon framework.
9.2 Audience This document is written for software developers, information services persomlel, and other technical people who are considering using Argon to streamline the development and maintenance of a contact center solution.
Page 3 of 20 Argon White Paper 2. What is Argon?
Argon is a collection of pre-built software components that can be used to dramatically reduce the amount of effort required to develop, deploy, and maintain contact center solutions.
Page 4 of 20 Argon White Paper 3. Why Argon 3.1 The Motivation Much of the motivation behind the development of Argon has been to solve the addressable problems that the engineers at Aria Solutions Inc. continuously encounter while working on computer telephony integration (CTI) projects. It was observed that, although each project had certain aspects that were unique, there was a great deal of effort being expended solving the same problems over and over. In addition, it was becoming clear that certain Internet technologies were maturing rapidly and could be used to simplify various tasks or even remove them altogether.
3.2 Anatomy of a CTI Project A CTI project involves making your telephone network talk to your computer network in such a way that allows you to better serve your customers, make more sales, and make more money. A CTI project typically involves the following tasks.
3.2.1 Programming the IVR
When a customer calls your customer service line the call is answered by a computer and an automated voice asks her to enter her account number on her touch tone phone. This is the IVR. Typically, the IVR asks you to enter some kind of identification number. The IVR associates the identification number with the call. This is how your computers know, to whom you are speaking on the phone. Usually, the IVR provides a self service menu to the caller. Typically the self service menu allows to perform tasks that she can efficiently do for herself such as check her account balance, change her address, or pay a bill. The self service menu is typically available twenty four hours a day, seven days a week (24x7), giving the caller access to your business even during those times when your office is closed.
The IVR must be programmed so that it knows how to respond to touch-tones and what messages to play. Messages are recorded and an IVR script is written that defines the behavior of the IVR.
3.2.2 Programming the Interaction Router Of course, some interactions require a real live human being on the other end of the line.
Typically the IVR allows the user to press a digit, usually zero, to speak to a customer care representative. This is where call routing comes in. When the caller presses zero to speak to a customer care representative, focus shifts to routing the call to the real live human being who is best equipped to handle it. Call routing is usually based on where the caller was in the IVR menu structure when they pressed zero and the set of information identified by the caller's identification number. This set of information is often called the Page 5 of 20 Argon White Paper customer profile. The people who take the calls, the customer care representatives or contact center agents can be set up with skills that have specific scores. An example of a skill might be the ability to speak French. If the caller's customer profile indicates that they speak French the call will be routed the available agent that has the highest score in the French skill. If none of the available contact center agents speak French, the call waits in a call queue until a French-speaking agent becomes available. While the call is waiting in the queue, every so often a message is played to the caller indicating how important her call is and so on. In addition, the caller may have purchased a certain level of service.
This service level is recorded in the caller's customer profile and can be used to prioritize her call among all the other calls that are waiting to be serviced.
Routing is handled by a piece of software called an interaction router. The interaction router must be programmed to retrieve the customer profile from a database so that it can be checked against agent skills. The interaction router may also associate customer profile information with the call so that it can be displayed by an application running on the target agent's desktop computer. Typically, the programming is embedded in a routing script that defines how calls are to be routed.
Note that the piece of software that routes the calls is called an interaction router rather than a call router because it can route other interactions besides calls.
Typically, skill-based routing can also be applied to emails and chat sessions.
3.2.3 Developing and Deploying the Desktop Client Application After the call has been routed to the appropriate agent's phone, the focus shifts to getting the information that is associated with the caller to the agent that receives the call.
Usually this information is associated with the call by the interaction router and is displayed in an application window that makes itself visible when the target agent's phone rings. Typically, this desktop application also includes a set of controls called the soft phone that allow the agent to perform telephony operations such as answer, hang up, transfer, conference, hold, and retrieve from his computer. Often, a contact center agent that is equipped with a headset and a desktop client application can handle calls using their computer without having to touch the physical phone. A piece of software called a telephony server talks to the phone switch and makes phone switch events and requests available to the computer network so that the client application knows when a particular agent's phone rings and can submit requests to control the call.
The desktop application is usually custom written in a programming language such as Microsoft Visual Basic, Java, or C++ and must be deployed each agent's desktop.
3.2.4 Designing and Implementing Interaction Reports Interaction reports are designed so that you can track the performance of your contact center. These reports allow you to identify how long customers are kept waiting in queues, how many customers abandon the call before it reaches an agent, how long on average agents spend handling calls, etc. For example, you might find that at certain Page 6 of 20 Argon White Paper times the contact center gets a flood of calls and customers end up waiting too long in call queues. This may indicate that you should plan to deploy more agents at these times.
Often, the desktop client application provides a mechanism by which an agent can associate wrap-up codes with an interaction. Wrap-up codes indicate what a call was regarding. Some examples of wrap-up are purchase, complaint, billing, personal information change, general inquiry, etc...
Interaction reports that involve wrap-up codes give you insight into your business. For example, if you suddenly get a flood of calls about billing, this may indicate there is a problem with your billing process or perhaps the bill that you are sending to customers is unclear.
In any case, the reports that are required to illuminate these important patterns of call center interactions have to be designed and implemented.
3.3 Problems with the Traditional Desktop Client Application It was determined that the many of the addressable problems associated with computer telephony integration surround the desktop client application. 'This is because the development of the desktop client application requires the bulk of the custom programming. In addition, the desktop client application, unlike the routing and IVR
scripts, have to be deployed on each agent's desktop.
It was observed that most of the problems surrounding the desktop client application result from the following:
3.3.1 A Lack of Separation Business and CTI logic is often intertwined in the desktop client applications. This meant that a new client application would have to be developed for each customer even though the CTI logic was essentially the same. In addition, even simple changes to business content required expensive computer telephony expertise to avoid breaking existing CTI
logic.
3.3.2 Ubiquitous Deployment Issues Deployment of the client applications on even a small number of desktops posed significant problems. There would often be conflicts with other applications.
Sometimes, there would be a lack of resources on the desktops. Often, customers would insist that the deployment of the desktop client application be performed by an already over-burdened information services staff, resulting in delays.
3.4 Traditional Desktop Client Applications Resist Change Traditional desktop client applications are simply not dynamic enough to keep up with the changing needs of most businesses. Once the desktop client application has been Page 7 of 20 Argon White Paper deployed it becomes difficult to change it. Firstly, because the CTI and business logic is not sufficiently separated, making changes to the desktop client application requires an experienced CTI programmer. Experienced CTI programmers are uncommon and expensive. Secondly, because the benefit of each change is weighed against the substantial effort that is required to deploy that change on all agent desktops, many changes do not get deployed.
In business it is important to be able to capitalize on opportunities. The desktop client performs a very important function in your contact center. It delivers the information that an agent needs to service a customer at the exact moment of contact. When a customer or potential customer contacts your organization, this presents an opportunity.
An opportunity to build a relationship, make more contacts, make another sale.
The desktop client delivers the information that the contact center agent needs to capitalize on these opportunities. As time races on at Internet speed, opportunities change, sometimes overnight. To allow contact center agents to fully capitalize on new opportunities as they arise, the desktop client has to be dynamic. The desktop client has to deliver the appropriate information for each new opportunity.
Page 8 of 20 Argon White Paper 4. Welcome to Argon Argon gives you the power to capitalize on opportunities by giving control over information delivery to the person that knows your business, you.
With Argon the desktop client application is deployed as a set of web pages that are downloaded and executed in a web browser. To start the Argon Web Client the agent simply navigates their browser to the designated universal resource locator (URL) and Iogs in. As long as a compatible browser exists no client-side installation is required.
The Argon Web Client appears as a separate window that is divided into frames.
There is a soft phone frame that provides buttons such as answer, hang up, transfer, etc. that allows the agent to control phone calls. There is a short cuts frame that gives the agent quick ways to deal with a call such as, transfer to sales, and transfer to collections. It is up to you to define what short cuts appear. Finally, there is a large frame called the content frame. Although, typically, information such as the customer profile appears in the content frame when the agent's phone rings, the information that appears in the content frame is completely up to you.
Navigate your browser to another UItL and the Argon Administration Client appears.
The Argon Administration Client allows you to define the behavior of the Argon Web Client. With a few mouse clicks you can specify what UIZL you would like to appear in the content frame when a particular telephony event occurs. With a few more mouse clicks you can also specify what information you would like to appear in the request to that URL. In most cases you would at least specify that the caller's identification number be passed along. Similarly, you can define what short cuts should appear in the short cuts frame, when a particular event occurs. Any changes that you make using the Argon Administration Client will take affect when the next contact center agent logs in to a web client.
This short description illustrates how Argon solves the problems associated with traditional CTI client development.
Business logic and CTI logic are separate. The task of creating the server-side script that displays business content in the Argon web client can be given to a web developer without that web developer having to know anything about CTI. All the web developer needs to know is that at the appropriate time the server-side script will be invoked, with the customer identification number as a parameter. The server-side script can be written and tested independently of CTI activities.
Argon inherits none of the deployment problems encountered with traditional CTI client applications, because client-side deployment is virtually non-existent.
Page 9 of 20 Argon White Paper 5. The Argon Framework 5.1 The Engine Adapter Model At the heart of the Argon framework lies the engine-adapter model. The general engine-adapter model is depicted with a UML object diagram in figure 1.
Communicates with Ada er1 Communicates with Communicates with Communicates with Ada er4 ~ ~ Engine ~ Communicates with ~ Ada er2 Communicates with I Communicates with Ada era ~ Communicates with Figure 1 - General Engine-Adapter Model The behavior of Argon clients such as the Argon Web Client is controlled by an object called an engine. The purpose of the engine is to distribute Argon messages among adapter objects according to the rules that are specified in the engine's configuration.
Adapter objects are responsible for communicating with systems that are external to Argon. Each adapter objects translates between the Argon messaging protocol (AMP) and whatever protocols or interfaces are supported by the associated external system.
5.2 Engine Configuration Engines are configured by a configuration object, depicted below in figure 2.
Page 10 of 20 Argon White Paper Configures Figure 2 - Engine Configuration When the engine is created it is given the URL of a server-side script that produces the configuration. The engine creates a configuration object and passes the URL to it. The configuration object connects to the URL and receives a stream of XML.
Contained within the XML are the rules that define how the engine distributes messages among the associated adapters.
The server-side script generates the XML by querying the Argon configuration database.
This is the database that you are modifying when you make changes with the Argon administration client. You can get a good idea of what the configuration XML
will look like when you click on an application's XML link in the Argon Administration Client.
5.3 Argon CTI Client Application The Argon CTI client application is a specialization of the general engine-adapter model is depicted with a UML object diagram in figure 3.
~unicates with Page 11 of 20 Argon White Paper Figure 3 - Argon CTI Client Application In the case of the CTI client application, there are two external systems, the telephony server and the web browser.
The CTI adapter translates between calls to the telephony server interface and Argon messages. For example, when the agent's phone rings the CTI adapter is notified and sends an Argon event message to the engine. If the engine sends a request to the CTI
adapter to answer a call, the CTI adapter makes the appropriate call through the telephony serverinterface.
The portal adapter translates between calls to the browser interface and Argon messages.
For example, when an agent clicks the answer button on the web client soft phone, the portal adapter is notified and sends an Argon event message to the engine. If the engine sends a request to navigate the web client content pane to a specific URL, the portal adapter makes the appropriate call to the browser interface.
5.4 Argon Agent Model The portal adapter is somewhat more sophisticated than other adapters like the CTI
adapter because it employs an object called an agent. The general Argon agent model is depicted in a UML object diagram in figure 4.
Communicates with Communicates wth En ine ass Throu h Ad a Aaent Communicates wth xternal S~ stem Figure 4 - General Argon Agent Model An agent is an object that is paired with a special kind of adapter called a pass through adapter. The adapter is called a pass through adapter because most of its work involves distributing messages to and from the agent. It is the agent that actually does the work of converting between the Argon messaging protocol and whatever protocol is supported by the associated external system. This means that the Argon messaging protocol is used between the engine and the pass through adapter as well as between the pass through adapter and the agent.
5.5 Portal Agent The portal agent is depicted with a UML object diagram in figure 5. Note that the pass through adapter, portal agent and the portal applet together are thought of as the portal adapter.
Page 12 of 20 Argon White Paper ~unicates with a The Argon Web Client includes an invisible frame that contains an applet called the Argon portal applet. This applet is loaded into the frame and executed when a contact center agent logs in. The portal agent is created as part the portal applet when the portal applet is executed. When the portal agent is created, it establishes a connection to the associated pass through adapter, essentially making the web client visible to the rest of the Argon framework. The web pages that are loaded into the web browser send and receive Argon messages by making calls (scripting) the portal applet which forwards those calls on to the portal agent. This is how the web browses knows, as an example, when the agent's phone rings.
5.6 Deployment Argon is written in Java, and is, therefore, largely platform independent.
Argon adapters, engines, and configuration objects are instantiated by server objects that run inside an Argon run-time environment. An Argon run-time environment is a class that executes in a single Java virtual machine. The Argon run time environment houses one or more Argon servers, and provides services such as logging. When an Argon run-time environment is deployed, it is associated with an XML file, which specifies attributes of the Argon run-time environment such as how to perform logging, as well as, which Argon server to run, and for each Argon server what arguments are required.
Because the server objects communicate with sockets, they can be deployed in a variety of ways. Server objects can be deployed on a single machine in a single Java virtual machine, on a single machine in separate Java virtual machines, or on multiple networked machines in separate Java virtual machines.
Page 13 of 20 Figure 5 - Portal Agent Argon White Paper The capacity of the Argon system is increased, by deploying additional Argon servers on new machines. You have the choice of, static load balancing by assigning certain agents or applications to particular servers, or having the Argon framework perform round-robin load balancing as engines and adapters are created.
Figure 6 is a UML deployment diagram that depicts a fully distributed Argon system where only the basic server types exist.
Database Server Machine 1 .._~.w..a~~_ Confiaurartion Server Machine 1 ~~ «HTTP (HML > DBMS 1 r..
Confiauration Server 1 1 -«AMP>r 1 -«ODBC»
1 I -«AMPn> ' ~-T Portal Adaater Server 1 ter Server Ma'bhi a 1 Teleohonv Server Machine 1 rt TCP»
Teleohonv Server CTI Adapter Server 1 1 -a<TCP~n Phone Switch AaeM Workstation 1 1 - Web Browser Figure 6 - A Fully Distributed Argon System In addition to the Argon servers, the following servers are required:
~ ODBC Compliant Database Server An Argon system requires an ODBC compliant database server to store Argon configuration information ~ Web Server °
Page 14 of 20 Argon White Paper An Argon system requires at least one web server to serve the web pages belonging to the Argon Web Client and Argon Administration Client.
~ Telephony Server This Argon system require a telephony server from a supported CTI vendor, so that the Argon CTI adapter can invoke the functionality of the phone switch.
Note that the portal adapter server is deployed on the web server. This is because, generally, applets can only make connections back to the web server that served them.
Page 15 of 20 Argon White Paper 6. Argon Messaging 6.1 Argon Message Types Argon messages fall into the three types that are depicted with a UML class association diagram in figure 7. All Argon messages are derivations of the following three message types.
Figure 7 - Argon Message Types 6.1.1 Event Message The event message is an unsolicited message that is sent from some object to indicate that some event has occurred.
6.1.2 Request Message The request message is a message that is sent to invoke some functionality in the destination object. A request message generates a unique transaction identifier that is used to match the request with the associated response.
6.1.3 Response Message The response message is a message that conveys the result of a particular request.
The response message maintains the unique transaction identifier of the associated request, so that the response and request can be matched.
6.2 Argon Message Categories In addition, Argon messages also fall into the following categories:
Page 16 of 20 Argon White Paper 6.2.1 Management Messages These are messages that Argon servers send to one another to manage Argon objects, such as requests to create and destroy adapter, engine, and configuration obj ects.
6.2.2 Configuration Messages These are the messages that a configuration object sends to an engine to define that engine's behavior, such as requests to add adapters, actions, and conditions.
6.2.3 Generic Messages These are the messages that are distributed among engines and adapters that result in or result from interactions with in external systems such as the telephony server or the Argon Web Client.
Generic messages are different from other messages in that the Argon engine does not know what the message means. Imagine that you create an action using the Argon Administration Client to send the pop request to the portal adapter when a ringing event arrives from the CTI adapter. When a ringing event arrives, the engine doesn't know that you are displaying a web page. All that the engine knows is that when an event called EventRinging arrives from adapter called the CTI adapter, it has to send a generic request called Portal.RequestPop to an adapter called the Portal Adapter. The engine also knows that a generic Argon event has a tree of key value pairs embedded within it. When you specify that you want key url.parameter.acctNum in the request to equal userData.ACCT_NB in the event. The engine copies the value at userData.ACCT_NB in the data tree of the EventRinging event into url.parameter.acctNum in the data tree of the Portal.RequestPop request. The engine has no idea that this value is an account number.
The Argon adapters know the business of interacting with non-Argon systems.
The CTI adapter understands that when a ringing event arrives from the telephony server it has to create a generic generic Argon event called EventRinging, generate an Argon data tree from the data that the telephony server has sent v~~ith the event, and send it to the engine. Similarly the portal adapter understands that when it gets a generic request called Portal.RequesPop, it should take the url.name, url.parameters, and targetFrame values out of the request data tree, construct a URL, and load it into the target frame.
Adapter requests, events, and data trees are defined in an adapter schema that is imported into the Argon configuration database. The Argon administration client queries adapter schemas in order to populate choice lists when you are building configurations.
Page 17 of 20 Argon White Paper 7.0 Customization The Argon framework has been designed to allow a great deal of customization.
The following sections enumerate all the ways in which an Argon system can be customized.
7.1 Customizing the Portal (Argon Web Client) You can change the functionality that the portal exposes to Argon by adding to the JavaScript code that is included in the applet and soft phone frames of the Argon web client. Any functionality that you add can be made available to the Argon administration client by changing the portal adapter schema.
You can also change any part of the web client's user interface. The soft phone and short cuts user interface is dynamic html rather than applets so you are free to change the look and feel however you like.
7.2 Custom Adapter Servers If you would like to integrate one or more external systems that make up your business into the Argon framework, you can do it by creating a custom adapter server.
Argon comes with a Java class library that allows you to create your own custom adapter servers. You will have to know something about object-oriented programming to do it.
Depicted below in figure 8 is a UML class association diagram that shows the classes that are involved.
Page 18 of 20 Argon White Paper 0..1 ~ -createAdapter ~u~om Adapter -executeRequest 0..1 I -create Adapter Serv r Custom 0..1 -generateEvent ~interfacex Adapter 0..1 IAdapterFacto +createA dapter( +generateEvenl() ~~~1 ue.mhmiFt7ar.nnne.efl -submilResponse Figure 8 - Custom Adapter Classes The Argon framework is designed so that when you create a custom adapter server, you can concentrate on exposing the functionality provided by some external system, instead of worrying about the plumbing. In the diagram in figure 7, you implement the classes that have "custom" in the name. Of course, you are free to give them whatever name you like. In any case, you will need to implement a custom adapter, a custom adapter factory, and a custom adapter server.
Your custom adapter class extends the base adapter class. To add custom request-handling functionality to your adapter, override the executeRequest method.
This is the method that the Argon framework will call to notify your adapter that a request has arrived. It is important that your custom adapter's executeRequest method not do anything that will block your adapter server. Argon adapter servers are single threaded which means that any adapter requests that arrive, must wait in a queue until the adapter server has finished processing any previous requests. To generate events and submit responses call the generateEvent and submitResponse methods on the adapter base class.
Don't forget to include the transaction ID of the associated requests, when you submit responses. The Argon framework will take care of sending the appropriate generic message to the associated engine.
Your custom adapter server class extends the base adapter server class. In its constructor, your custom adapter server will need to call the constructor of the adapter server base Page 19 of 20 Argon White Paper class with a reference to your custom adapter factory. The Argon framework uses the supplied adapter factory to create instances of your custom adapter as required.
When you get it running don't forget to import the schema for the your custom adapter into the Argon configuration database so that the Argon Administration Client see it.
7.3 Windows Client Services If you have Windows client application that already exists on your contact center desktops, you can create an Argon client service application that allows you to expose interactions with that client to the Argon framework. An Argon client service is a Windows application that typically runs minimized on each client desktop, something like a PC Anywhere host.
To integrate with a Windows client application, you simply embed a client service control into your client service application. The client service control accepts connections from client service adapters. Argon comes with a client service adapter server that hosts the client service adapters. The client service control exposes an executeRequest event, a sendEvent method and a sendResponse method that can be used to communicate with the Argon framework.
Because you decide what requests and events your client service exposes, you are responsible for creating the adapter schema for your client service adapter.
Don't forget to import the schema for your client service into the Argon configuration database so that the Argon Administration Client can see it.
7.4 Custom Configuration Scripts The server-side script that generates the XML that is used to configure Argon engines can be modified or completely replaced as long as the Argon configuration objects see a valid XML stream.
Page 20 of 20
Claims
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002318287A CA2318287A1 (en) | 2000-08-30 | 2000-08-30 | System integrated framework |
| US09/682,416 US20020038309A1 (en) | 2000-08-30 | 2001-08-30 | System integration framework |
| CA002356781A CA2356781A1 (en) | 2000-08-30 | 2001-08-30 | System integration framework |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002318287A CA2318287A1 (en) | 2000-08-30 | 2000-08-30 | System integrated framework |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2318287A1 true CA2318287A1 (en) | 2002-02-28 |
Family
ID=4167090
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002318287A Abandoned CA2318287A1 (en) | 2000-08-30 | 2000-08-30 | System integrated framework |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20020038309A1 (en) |
| CA (1) | CA2318287A1 (en) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7428531B2 (en) * | 2002-02-06 | 2008-09-23 | Jpmorgan Chase Bank, N.A. | Customer information management system and method |
| US7315980B2 (en) * | 2002-03-21 | 2008-01-01 | International Business Machines Corporation | Method and apparatus for generating electronic document definitions |
| AU2003210326A1 (en) * | 2002-03-29 | 2003-10-13 | Koninklijke Kpn N.V. | Telecommunication system comprising platform for activation and control of telephony services |
| US20050027573A1 (en) * | 2003-07-28 | 2005-02-03 | Assaf Silberstein | System architecture and a method for customer flow management |
| US20050259653A1 (en) * | 2003-07-28 | 2005-11-24 | Q-Nomy Inc. | System architecture and method for customer flow management |
| US7889859B1 (en) * | 2004-03-29 | 2011-02-15 | Avaya Inc. | Voice recognition for servicing calls by a call center agent |
| US20060037031A1 (en) * | 2004-08-13 | 2006-02-16 | Renzo Colle | Enabling communication between a service and an application program |
| US7707432B2 (en) * | 2004-08-13 | 2010-04-27 | Sap Ag | Enabling communication between an application program and services used by the application program |
| US20060200565A1 (en) * | 2005-03-04 | 2006-09-07 | Lucent Technologies, Inc. | Methods and apparatus for flexible and transparent mediation of communication between software applications |
| US8885812B2 (en) | 2005-05-17 | 2014-11-11 | Oracle International Corporation | Dynamic customer satisfaction routing |
| US8583466B2 (en) * | 2005-08-09 | 2013-11-12 | Oracle International Corporation | System and method for routing workflow items based on workflow templates in a call center |
| IL173222A0 (en) * | 2006-01-18 | 2006-06-11 | Clip In Touch Internat Ltd | Apparatus and method for creating and transmitting unique dynamically personalized multimedia messages |
| US20080016248A1 (en) * | 2006-07-14 | 2008-01-17 | George Tsirtsis | Method and apparatus for time synchronization of parameters |
| US7729368B2 (en) * | 2007-01-19 | 2010-06-01 | Hewlett-Packard Development Company, L.P. | Network buffer caching |
| US20090320092A1 (en) * | 2008-06-24 | 2009-12-24 | Microsoft Corporation | User interface for managing access to a health-record |
| US8332870B2 (en) * | 2008-09-30 | 2012-12-11 | Accenture Global Services Limited | Adapter services |
| US9454736B2 (en) * | 2009-03-30 | 2016-09-27 | Q-Nomy Inc. | System and method for queue management |
| US8923489B1 (en) * | 2013-04-24 | 2014-12-30 | West Corporation | Applying user preferences, behavioral patterns and environmental factors to an automated customer support application |
| EP3080973B1 (en) * | 2013-12-11 | 2017-07-05 | Telefonaktiebolaget LM Ericsson (publ) | Proxy interception |
| US10135700B2 (en) | 2014-03-10 | 2018-11-20 | Softphone SRL | Enterprise application integration on client computing devices |
| US9888118B2 (en) | 2014-03-10 | 2018-02-06 | Softphone SRL | Enterprise application integration on client computing devices |
| US9325584B2 (en) | 2014-03-10 | 2016-04-26 | Softphone S.R.L. | Enterprise application integration on client computing devices |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6130933A (en) * | 1996-02-02 | 2000-10-10 | Genesys Telecommunications Laboratories, Inc. | Apparatus and methods for coordinating telephone and data communications |
| US5946387A (en) * | 1997-02-10 | 1999-08-31 | Genesys Telecommunications Laboratories, Inc, | Agent-level network call routing |
| US6286033B1 (en) * | 2000-04-28 | 2001-09-04 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for distributing computer integrated telephony (CTI) scripts using extensible mark-up language (XML) for mixed platform distribution and third party manipulation |
| JPH113307A (en) * | 1997-06-13 | 1999-01-06 | Canon Inc | Information processor and its method |
| US6266701B1 (en) * | 1997-07-02 | 2001-07-24 | Sitara Networks, Inc. | Apparatus and method for improving throughput on a data network |
| US6108711A (en) * | 1998-09-11 | 2000-08-22 | Genesys Telecommunications Laboratories, Inc. | Operating system having external media layer, workflow layer, internal media layer, and knowledge base for routing media events between transactions |
| US6201805B1 (en) * | 1997-10-21 | 2001-03-13 | Dialogic Corporation | Apparatus and method for computer telephone integration in packet switched telephone networks |
| US6260186B1 (en) * | 1997-11-13 | 2001-07-10 | Nortel Networks Limited | Universal state machine for use with a concurrent state machine space in a telecommunications network |
| US6188762B1 (en) * | 1997-12-01 | 2001-02-13 | Stephen Shooster | Web call center/PSTN to TCPIP internet network |
| US6418146B1 (en) * | 1999-12-10 | 2002-07-09 | Genesys Telecommunications Laboratories, Inc. | Integrated communication center functionality for WAP devices |
| US6269473B1 (en) * | 1998-03-23 | 2001-07-31 | Evolve Software, Inc. | Method and apparatus for the development of dynamically configurable software systems |
| US6011844A (en) * | 1998-06-19 | 2000-01-04 | Callnet Communications | Point-of-presence call center management system |
| US6801928B2 (en) * | 1998-11-12 | 2004-10-05 | Genesys Telecommunications Laboratories, Inc. | Dynamic translation between data network-based protocol in a data-packet-network and interactive voice response functions of a telephony network |
| US6549937B1 (en) * | 1999-07-21 | 2003-04-15 | Microsoft Corporation | System and method for multi-protocol communication in a computer network |
-
2000
- 2000-08-30 CA CA002318287A patent/CA2318287A1/en not_active Abandoned
-
2001
- 2001-08-30 US US09/682,416 patent/US20020038309A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20020038309A1 (en) | 2002-03-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2318287A1 (en) | System integrated framework | |
| EP1393188B1 (en) | Media-independent communication server | |
| EP1559004B1 (en) | Session coupling | |
| US7602766B2 (en) | Method and apparatus for automatic network connection between a small business and a client | |
| US7730204B2 (en) | Extensible interface for inter-module communication | |
| US6141724A (en) | Remote application design | |
| US6654815B1 (en) | Contact server for call center | |
| US8601492B2 (en) | User interface for multi-channel communication | |
| US7315616B2 (en) | System and method for maintaining real-time agent information for multi-channel communication queuing | |
| US7581230B2 (en) | Adaptive communication application programming interface | |
| US20090252320A1 (en) | System and Method for Multi-Channel Communication Queuing | |
| KR20000035004A (en) | Communicating method, method of accessing a server, communication system, and storage medium for storing program codes for instructing to acess a server | |
| US6400820B1 (en) | Java enabled groupware | |
| Cisco | Product Offering Descriptions | |
| Cisco | Product Offering Descriptions | |
| CA2356781A1 (en) | System integration framework | |
| Telephony | Java Programmer’s Guide and Reference | |
| GB2436181A (en) | A call-back call connection system | |
| Kowarsky | Customer Relationship Management in the Internet Age | |
| GB2346718A (en) | Client server system supporting collaboration |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |