we are developing a screen pop application, when a call arrived to an agent, we need to find the agent id, we followed the code described here.

https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/jtapi/programming.gsp#280

We obtained a VDN from the systme and add TerminalConnectionListener to the VDN

so every call come to the VDN will have listener. when the agent answered the call, the method terminalConnectionCreated will be notified.

we are trying to retrieve the agent ID from here.

TerminalConnection tc = evt.getTerminalConnection()

 Terminal	terminal = tc.getTerminal()

 if(terminal instanceof AgentTerminal)

 {

	AgentTerminal agentTerminal= (AgentTerminal)terminal;

	Agent[]	agents = agentTerminal.getAgents();

 }

the problem happen at agentTerminal.getAgents();

sometimes it returns agent ID who logged on the station 2 days ago, it keep an array of history agents.

sometimes, it return empty, (there is actually an agent logged on).

We don't use the 'addAgent' / removeAgent on the Terminal. (agent logon to the station manually dial the FAC code on the phone)

The agentTerminal.getAgents() should always return one agent currently logged on to the station.


Can anyone help to understand the problem ?

try monitoring the stations that the agents are logged into and see if the SDK behaves as you expect.

I suspect that the JTAPI client caches agent information the first time it queries it. Subsequent queries returns the same information unless the application itself was used to change the agent state. I have seen similar behaviour for at least one other type of request.

As this application is for a screen pop, I presume there are many instances of it running, each on an agent's PC. In this case, I would expect agents to exit the application when they logout and start it when they login. This way, the cache would be deleted and you would not get this problem.

For a centralized application, where there is a single server connected to AE Services, you could monitor the skill(s) for Agent Login/Logout events. This would allow the application and JTAPI client to keep up-to-date.

Martin

thank you.

this is server side (centralized )application, the applicaiton monitors 100+ VDN, (monitoring a VDN doesn't consume a TSAPI license), that is why we didn't monitor the station.

(abount 600 agents).

for every call arrived on a VDN, we add a TerminalConnectionListener, which will invoke terminalConnectionCreated when agent answer the call.

We obtain the terminal from TerminalConnectionEvent, then try to get the agent id, once we know the agent id, we send HTTP request to a customer service (agent id, calling number), the customer web service will push the agent's PC CRM system to do a screen pop.

right now, if the terminal.getAgents() return one agent, then that is work fine, if the terminal.getAgents() return multiple agents, we always use the last agent id from the array, 95% of the times it works. however, sometimes the termina.getAgents() return empty, that cause a problem.

(if terminal.getAgents return array of agents, it includes agents who logged on the terminal 2,3days ago, has alreadylogged out)

e.g we have an agent received a call at 11am on a terminal, everything works fine, then a new call arrive on the terminal at 11:45am, the terminal.getAgents() method return empty, however, 1 hours later it back to normal. this terminal.getAgents() randomly return incorrect data

i found out another thread discussed this issue in AES 4.1.1 (we are using AES 6) https://www.devconnectprogram.com/forums/posts/list/9203.page

we prefer not to monitor the skill for listen login/logout event, the CM admin could add new skill or delete skills from CM anytime, then the application may requires to reconfigure /restart to add the new skill or remove listening on skill.

it seems the JTAPI is caching the agent id when call the terminal.getAgents(), but we didn't configure tsDevicePerformanceOptimization in the TSAP.pro file, it should not cache the agent id/ device.