OK - From what I can gather, you will be able to obtain a LOGINID and an indication of a LOGIN or LOGOUT, as well as a Timestamp from the LOGIN table and various other Configuration References.
I have tested a few scenarios and the TServer accepts all relevant EVENTS from the attached Switch/PBX (Avaya) then as long as the CME environment lists/registers all LOGINID’s (DN’s) for both CTI and non-CTI Hard Phone/turret Extensions. For some clarity - if you add an IServer to the Connections of the StatServer, it can extract all of the associated LOGIN/LOGOUT EVENTS from the GAD, too.
For this to work, I need to make an assumption that the Extensions/DN’s themselves are identifiable as “CTI” and “non-CTI”. The results Table (LOGIN) can be extracted and queried on the basis of the Extension/LOGINID, Timestamp (Time Range) and Status (1 = LOGIN, 0 = LOGOUT)
Further to this, the following information is available on the LOGIN Table;
SWITCHDBID, DBDBID, QUEUEDBID, AGENTDBID, PLACEDBID, STATUS, TIME and LOGINID.
It follows that it would be possible to create a LOOKUP Query from this information, to determine which LOGINID’s (or PLACEDBID’s) are logged in - and when they logged out. Of course, if the Agent simply closes GAD without logging out, you’d need to find a clever way of determining a “time-out” period of inactivity, to emulate a LOG OUT for those types of instances.
I’m sayng it can work when using the LOGIN Table - with a bit of development!
For some clarity - if you add an IServer to the Connections of the StatServer, it can extract all of the associated LOGIN/LOGOUT EVENTS from the GAD, too.
Tony, could you explain me why you need IServer for GAD? GAD is application based on Genesys AIL (Agent Interaction Layer) and communicates directly with TServer (on server side of course). IServer is virtual application used by IVR TServer. I don’t see any connection between these two apps…
If StatServer monitors particular DN then login/logout events occurring on that DN (place) will be saved to LOGIN table. StatServer only need one connection for that - connection to TServer.
The issue is from what I understood, that the same extension is used by both types of agents. Agents who uses GAD for whole time of their session (except when agent is lazy to use softphone for log out or some component just crash down) and Agents who does not use GAD at all. As the extension is monitored by TServer, Stat Server is getting all events no matter if Agents are using GAD or not. How are you going to separate those two agents using data from LOGIN table? Or did I understand the core problem whatsoever?
The suggestion is that, if you have a blended environment, you may want to connect to the TServer for Voice and also an IServer (based on the TServer template) for Interactions information. I tried to explain that it was not an IVR TServer, but an MCR IServer - which is, in essence, a TServer too…!
Understood - I mentioned that the LOGIN Table also contains a Field called “PLACEDBID”. Any entries on the LOGIN Table with a PLACEDBID = CTI/Genesys, without a PLACEDBID = non-CTI/Genesys…
I tried to explain that it was not an IVR TServer, but an MCR IServer - which is, in essence, a TServer too...!
OK. Now it’s clear to me. Thank for the explanation Tony
Personally, I’m using the abbreviation IxnServer for Interaction Server to avoid confusiong with IVR IServer
Understood - I mentioned that the LOGIN Table also contains a Field called "PLACEDBID". Any entries on the LOGIN Table with a PLACEDBID = CTI/Genesys, without a PLACEDBID = non-CTI/Genesys...
Have you tested that? I would say that PLACEDBID will be filled even for non-CTI logins as StatServer uses place as the primary object internally.
OK - I have found that an AGENTDBID is not appended to the entry in the LOGIN Table, when a hard phone/turret is used to LOGIN or LOGOUT - but the entry is valid in all other respects (SWITCHDBID, DBDBID, QUEUEDBID, PLACEDBID, STATUS, TIME and LOGINID are all populated.)
This would mean that you can differentiate between CTI and non-CTI LOGIN’s and LOGOUT’s using the LOGIN Table Option of the StatServer. How you do that is (and report from it) is the next problem…
