Genesys Agent Desktop

[ahdeshpande]

I am trying to understand GAD from architecture perspective, as i am looking for a diagram which shall help me to understand the communication between GAD (Client machine) with T-Server.
1. How does the communication happen - VIA Webserver? How are softphone components embedded in GAD?
I had heard, about GAD to be a DUMB Client, to which Webserver just pushes the data but GAD cannot respond back to Webserver.
Then in this case, how does Agent Controls - Accept Call, End Call, Fwd/Transfer call work?

I am sorry, if i am repeating the question then please redirect me to the correct forum.

Regards
Ashutosh
ashutoshhdeshpande@gmail.com

[cavagnaro]

Again from support site support.genesyslab.com download the guides and read them. It is well explained there. Also in there search for tutorials and see those videos.

[René]

Ashutosh,

You can find information about architecture in the documents available on Genesys Technical Support website (as suggested by Cavagnaro). But don't expect to find detailed information how GDesktop works and what mechanisms/technologies are used for client -> server communication. That is Genesys know-how...

Briefly - GDesktop is web-based client so it means that all business logic and communication with Genesys servers like TServer is controlled on server-side. Only HTML code and JavaScript is used on client-side for presentation purposes and for communication with GDesktop server = client can communicate with server.

R.

[ahdeshpande]

Thanks for information. I will surely have a look at the support site...

Ashutosh

[barleycorn]

If you have an account on the tech support site, then there are two "Tech Tutorials" you can download about Genesys Desktop. The most recent from a week or two ago explains quite a bit about the architecture, particularly in reference to setting up GAD in a load-balanced environment.
Essentially, GAD is a JSP application hosted in a servlet container (default is Apache Tomcat). This means zero footprint on the agent desktop, as all that is required to use it is a web browser. State is maintained on the server level, so if your browser crashes then it's normally possible to restore the same state by loading up your browser again. Unsolicited events such as an eventRinging, etc., are handled by the browser opening a request to the server with a very long (infinite?) timeout; during this request any events are queued and returned to the browser, where the process begins again.

Hope this helps, let me know if you need any further explanation.