Hello,
I am trying to perform a use case where two different agent id's are trying to login on the same station.
I have agent1 2009 and agent2 2101 trying to login on station 1010 with HuntGroup Extension 5500.
First agent 2009 got logged in successfully and can be seen on JTAPI exerciser's log and Communication Manager.
When I tried to login second agent 2101, JTAPI Exerciser shown 2101 is logged in but Communication Manager only shows 2009 is logged in.
Also tried to fetch all the logged in agents on termnial 1010, it shown 2009 and 2101 with NOT_READY state.

I perform the same usecase without HuntGroup then for second login i.e. for 2101 I received below message.
Request: t_1010.addAgent(a_1010, [null], NOT_READY, null, 0, 2101, 1234)
TerminalFrame.addAgent(): caught PlatformException
Message: There is already an Agent logged on at the station.

AES Version: 8.1.3.5.0.8-0
JTAPI Version: 8.1.3.6.0.8

I also tested the same with JTAPI Version jtapi-sdk-8.1.3.5.0.6 and faced same issues but somehow did not get complete jtapitrace logs. But still I have attached JTAPIExerciser logs for reference.

I think behavior is correct. If you try to login agent on a station where some agent is already logged-in you will get error message that someone is already logged-in on provided station.
What do you want?

Thanks & Regards
Umesh

Behavior is correct when no huntgroup extension is passed while adding agent (i.e. login).
But when I try to login two agents with huntgroup extension (same or different) on same station then there is no message like Message: There is already an Agent logged on at the station.
JTAPI Exerciser shown both the agents are logged in but Communication Manager only shows first agent as logged in.

can you be more specific about what you mean by the JTAPI Exerciser showing both agents are logged in.

The JTAPI Exerciser is an application built using the JTAPI Client. Are you able to write sample code using the JTAPI Client and test the same. .. THere should have been an error thrown back to the second agent login attempt. My guess is that the JTAPI Exerciser logic did not handle that situation right. You could also check this (to an extent) by looking at the csta-trace on AE Services when TSAPI logging is enabled.

If you are working with a CC Elite deployment, you need not include the hunt group extension in you agent login requests.

Thanks JohnBiggs,
can you be more specific about what you mean by the JTAPI Exerciser showing both agents are logged in.
>>JTAPI Exerciser mean JTAPI Sample Client provided by Avaya.

Below are the log snippet from huntgroup extension (added a listener on it)

21:43:31 Event received by AddressListener:[com.avaya.jtapi.tsapi.impl.events.addr.ACDAddressEventImpl]

Event.getAddress() 	=>5500

Event.getID()      	=>ACDAddressNotReadyEvent

Event.getCause()   	=>CAUSE_NORMAL

AddressEvent.getAddress()				=>a_5500

ACDAddressEvent.getAgent().getAgentID()		=>2009

ACDAddressEvent.getAgent().getState()		=>NOT_READY

ACDAddressEvent.getAgent().getACDAddress()		=>5500

ACDAddressEvent.getAgent().getAgentTerminal()	=>1010

TsapiAgent.getPendingState()		=>Other: 0

TsapiAgent.getPendingReasonCode()		=>0



21:44:2 Event received by AddressListener:[com.avaya.jtapi.tsapi.impl.events.addr.ACDAddressEventImpl]

Event.getAddress() 	=>5500

Event.getID()      	=>ACDAddressNotReadyEvent

Event.getCause()   	=>CAUSE_NORMAL

AddressEvent.getAddress()				=>a_5500

ACDAddressEvent.getAgent().getAgentID()		=>2101

ACDAddressEvent.getAgent().getState()		=>NOT_READY

ACDAddressEvent.getAgent().getACDAddress()		=>5500

ACDAddressEvent.getAgent().getAgentTerminal()	=>1010

TsapiAgent.getPendingState()		=>Other: 0

TsapiAgent.getPendingReasonCode()		=>0

If you see the log statements its shows agent 2009 and 2101 are logged in with NOT_READY state.
Also when called getAgents() API on terminal it returned

Request: t_1010.getAgents()

=>t_1010.getAgents() returned:

	Agent[0] Ag_2009_1010_5500 (NOT_READY)

	Agent[1] Ag_2101_1010_5500 (NOT_READY)

But on Communication Manager it shows only agent 2009 is logged in.
If huntgroup extension is passed then JTAPI lib does not throws any exception or error; but if huntgroup extension is not passed then JTAPI lib throw an exception with below message while adding (login) an agent.

TsapiAgent.getPendingReasonCode()		=>0

Request: t_1010.addAgent(a_1010, [null], NOT_READY, null, 0, 2101, 1234)

TerminalFrame.addAgent(): caught PlatformException

Message: There is already an Agent logged on at the station

There is no issue if huntgroup extension is not passed.

Thanks for the clarifications.
What does the corresponding csta-trace show for the second agent login attempt?
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/tsapi/index.gsp?tab=general&accordion=faq-10

Also I suspect your query on getAgents() is on the hunt group extension (5500?) you are using in the agent login request.

Communication Manager can be configured for Expert Agent Selection (EAS) mode or not.
With EAS comes agents, skills, VDNs and vectors. In this context a huntgroup is not needed, and should be getting ignored in the code.

if EAS is disabled, then you log into a single hunt group and the parameter is needed.

The model changes between EAS and non-EAS environments, and the application need to change with it. I am of the view that what you are seeing is some issue with the JTAPI Exerciser and what happens when you pass in non-EAS parameters but Communication Manager is configured as a EAS deployment. It sounds like CM is doing what it should, and perhaps AES is as well, and the problem is with the Exerciser itself.

I would be curious in the csta trace of the getAgents() as well to see if something at a higher level is confused or if the problem is in the JTAPI Client or the Exerciser code.

I was able to reproduce the issue. When the Exerciser attempts to log the second agent in while specifying the hunt group, I see an error returned in the AES server logs (csta_out & g3trace), as well as the JTAPI client logs. Therefore, I believe this is an issue with the Exerciser/application. I have informed the product team for them to consider including an updated version of the Exerciser in a future release to handle this scenario correctly. However, for anyone developing their own application, I expect the application to receive the correct events.

Best Regards.

Thanks JohnBiggs and MichaelHerman2 for your prompt replies.
I again rechecked JTAPI Trace logs and there I can see a generic exception thrown by AES, but this exception is not propagated to custom client application (developed using ecsjtapi.jar file).
I can see following login request in JTAPI Trace log file.

2023-05-31 11:59:11,131 [AWT-EventQueue-0] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - Sent InvokeID 29 for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - CSTASetAgentState ::=

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - {

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   device "1002"

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   agentMode 0 < AM_LOG_IN >

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   agentID "2101"

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   agentGroup "5500"

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   agentPassword "1234"

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - }

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - TsapiPrivate ::=

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - {

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   vendor "ECS"

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   data 2 0 57 0 30 6 a 1 1 2 1 0 

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   tsType 89

2023-05-31 11:59:11,131 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - }

CSTAUniversalFailure response in jtapi trace logs but it did not send to client application.

2023-05-31 11:59:11,420 [GetEventThread] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - Received invokeID 29 for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,420 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - CSTAUniversalFailureConfEvent ::=

2023-05-31 11:59:11,420 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - {

2023-05-31 11:59:11,420 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   error 1 < GENERIC_OPERATION >

2023-05-31 11:59:11,420 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - }

2023-05-31 11:59:11,421 [GetEventThread] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TsapiEventQueue - Putting event CSTAEvent[CSTAUniversalFailureConfEvent]@6aa3aa95. EVENT Q SIZE = 1 MAX Q SIZE = 1 for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,421 [DistributeCSTAEvent] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TsapiEventQueue - Getting event CSTAEvent[CSTAUniversalFailureConfEvent]@6aa3aa95 for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,421 [DistributeCSTAEvent] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TSInvokeID - Handling INVOKE ID 29 for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,421 [DistributeCSTAEvent] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TSInvokeID - DONE handling INVOKE ID 29 for TSProvider[#1]@585e8cf4

Further logs shows agent is in NOT_READY state

023-05-31 11:59:11,421 [AWT-EventQueue-0] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - Sent InvokeID 30 for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,421 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - CSTAQueryAgentState ::=

2023-05-31 11:59:11,421 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - {

2023-05-31 11:59:11,421 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   device "1002"

2023-05-31 11:59:11,421 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - }

2023-05-31 11:59:11,421 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - TsapiPrivate ::=

2023-05-31 11:59:11,421 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - {

2023-05-31 11:59:11,421 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   vendor "ECS"

2023-05-31 11:59:11,422 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   data 2 0 10 0 30 6 16 4 35 35 30 30 

2023-05-31 11:59:11,422 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   tsType 89

2023-05-31 11:59:11,422 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - }

2023-05-31 11:59:11,807 [GetEventThread] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - Received invokeID 30 for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,807 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - CSTAQueryAgentStateConfEvent ::=

2023-05-31 11:59:11,807 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - {

2023-05-31 11:59:11,807 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   agentState 0 < AG_NOT_READY >

2023-05-31 11:59:11,807 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - }

2023-05-31 11:59:11,807 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - TsapiPrivate ::=

2023-05-31 11:59:11,807 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - {

2023-05-31 11:59:11,807 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   vendor "ECS"

2023-05-31 11:59:11,808 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   data 2 0 68 0 30 f a 1 1 a 1 1 2 1 0 a 1 ff 2 1 0 

2023-05-31 11:59:11,808 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession -   tsType 34

2023-05-31 11:59:11,808 [GetEventThread] DEBUG com.avaya.jtapi.tsapi.tsapiInterface.TsapiSession - }

2023-05-31 11:59:11,808 [GetEventThread] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TsapiEventQueue - Putting event CSTAEvent[CSTAQueryAgentStateConfEvent]@583359d3. EVENT Q SIZE = 1 MAX Q SIZE = 1 for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,808 [DistributeCSTAEvent] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TsapiEventQueue - Getting event CSTAEvent[CSTAQueryAgentStateConfEvent]@583359d3 for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,808 [DistributeCSTAEvent] DEBUG com.avaya.jtapi.tsapi.csta1.LucentPrivateData - LucentV6QueryAgentStateConfEvent ::=

2023-05-31 11:59:11,808 [DistributeCSTAEvent] DEBUG com.avaya.jtapi.tsapi.csta1.LucentPrivateData - {

2023-05-31 11:59:11,808 [DistributeCSTAEvent] DEBUG com.avaya.jtapi.tsapi.csta1.LucentPrivateData -   workMode 1 < WM_AUX_WORK >

2023-05-31 11:59:11,809 [DistributeCSTAEvent] DEBUG com.avaya.jtapi.tsapi.csta1.LucentPrivateData -   talkState 1 < TS_IDLE >

2023-05-31 11:59:11,809 [DistributeCSTAEvent] DEBUG com.avaya.jtapi.tsapi.csta1.LucentPrivateData -   reasonCode 0

2023-05-31 11:59:11,809 [DistributeCSTAEvent] DEBUG com.avaya.jtapi.tsapi.csta1.LucentPrivateData -   pendingWorkMode -1 < WM_NONE >

2023-05-31 11:59:11,809 [DistributeCSTAEvent] DEBUG com.avaya.jtapi.tsapi.csta1.LucentPrivateData -   pendingReasonCode 0

2023-05-31 11:59:11,809 [DistributeCSTAEvent] DEBUG com.avaya.jtapi.tsapi.csta1.LucentPrivateData - }

2023-05-31 11:59:11,809 [DistributeCSTAEvent] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TSInvokeID - Handling INVOKE ID 30 for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,809 [DistributeCSTAEvent] INFO  com.avaya.jtapi.tsapi.tsapiInterface.TSInvokeID - DONE handling INVOKE ID 30 for TSProvider[#1]@585e8cf4

And finally jtapi sent below events

2023-05-31 11:59:11,809 [AWT-EventQueue-0] INFO  com.avaya.jtapi.tsapi.impl.core.TSAgent - constructing TSAgent with agentKey=TSAgentKey(1002,5500,2101) for TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,809 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.impl.core.TSProviderImpl - Before creating TSDevice again for device TSDevice[1002]@1c228911 check for IsExternal : false

2023-05-31 11:59:11,809 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.impl.core.TSProviderImpl - Before creating TSDevice again for device TSDevice[5500]@701dec7c check for IsExternal : false

2023-05-31 11:59:11,809 [AWT-EventQueue-0] INFO  com.avaya.jtapi.tsapi.impl.core.TSAgent - ParentAgent Object TSAgentKey(1002,null,2101) being created for provider TSProvider[#1]@585e8cf4

2023-05-31 11:59:11,809 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.impl.monitor.TsapiAddressMonitor - Getting TsapiAddressMonitor lock to deliver events for listener jtapiex.MyAddressListener@2fa14b41

2023-05-31 11:59:11,809 [AWT-EventQueue-0] TRACE com.avaya.jtapi.tsapi.impl.LucentV7AgentImpl - com.avaya.jtapi.tsapi.impl.LucentV7AgentImpl@3ad632f7 constructed.

2023-05-31 11:59:11,809 [AWT-EventQueue-0] TRACE com.avaya.jtapi.tsapi.impl.LucentACDAddressImpl - com.avaya.jtapi.tsapi.impl.LucentACDAddressImpl@701dec7c constructed.

2023-05-31 11:59:11,809 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.impl.monitor.TsapiAddressMonitor - ADDRESSNOTREADYEVENT for TSAgent[TSAgentKey(1002,5500,2101)]@3ad632f7 for listener jtapiex.MyAddressListener@2fa14b41

2023-05-31 11:59:11,809 [AWT-EventQueue-0] TRACE com.avaya.jtapi.tsapi.impl.LucentV7AgentImpl - com.avaya.jtapi.tsapi.impl.LucentV7AgentImpl@3ad632f7 constructed.

2023-05-31 11:59:11,809 [AWT-EventQueue-0] TRACE com.avaya.jtapi.tsapi.impl.LucentACDAddressImpl - com.avaya.jtapi.tsapi.impl.LucentACDAddressImpl@701dec7c constructed.

2023-05-31 11:59:11,810 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.impl.monitor.TsapiTerminalMonitor - Getting TsapiTerminalMonitor lock to deliver events for listener jtapiex.MyTerminalListener@2cea850e

2023-05-31 11:59:11,810 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.impl.monitor.TsapiTerminalMonitor - meta event BEGIN: cause (100)  for jtapiex.MyTerminalListener@2cea850e

2023-05-31 11:59:11,810 [AWT-EventQueue-0] TRACE com.avaya.jtapi.tsapi.impl.LucentV7AgentImpl - com.avaya.jtapi.tsapi.impl.LucentV7AgentImpl@3ad632f7 constructed.

2023-05-31 11:59:11,810 [AWT-EventQueue-0] TRACE com.avaya.jtapi.tsapi.impl.LucentV5TerminalExImpl - com.avaya.jtapi.tsapi.impl.LucentV5TerminalExImpl@1c228911 constructed.

2023-05-31 11:59:11,810 [AWT-EventQueue-0] TRACE com.avaya.jtapi.tsapi.impl.LucentV7AgentImpl - com.avaya.jtapi.tsapi.impl.LucentV7AgentImpl@3ad632f7 constructed.

2023-05-31 11:59:11,810 [AWT-EventQueue-0] TRACE com.avaya.jtapi.tsapi.impl.LucentV5TerminalExImpl - com.avaya.jtapi.tsapi.impl.LucentV5TerminalExImpl@1c228911 constructed.

2023-05-31 11:59:11,810 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.impl.monitor.TsapiTerminalMonitor - TERMINALNOTREADYEVENT for TSAgent[TSAgentKey(1002,5500,2101)]@3ad632f7 for listener jtapiex.MyTerminalListener@2cea850e

2023-05-31 11:59:11,810 [AWT-EventQueue-0] DEBUG com.avaya.jtapi.tsapi.impl.monitor.TsapiTerminalMonitor - meta event END for jtapiex.MyTerminalListener@2cea850e eventList size=1

2023-05-31 11:59:11,810 [AWT-EventQueue-0] TRACE com.avaya.jtapi.tsapi.impl.LucentV7AgentImpl - com.avaya.jtapi.tsapi.impl.LucentV7AgentImpl@3ad632f7 constructed.

2023-05-31 11:59:11,810 [pool-2-thread-8] TRACE com.avaya.jtapi.tsapi.impl.monitor.TsapiAddressMonitor - --> run[]: com.avaya.jtapi.tsapi.impl.monitor.TsapiAddressMonitor@2959d104

2023-05-31 11:59:11,810 [AWT-EventQueue-0] TRACE com.avaya.jtapi.tsapi.impl.LucentV5TerminalExImpl - <-- addAgent[LucentAddress agentAddress, ACDAddress acdAddress, int initialState, int workMode, int reasonCode, String agentID, String password]: com.avaya.jtapi.tsapi.impl.LucentV5TerminalExImpl@1c228911

In our application we used addAgent api which throws TsapiInvalidArgumentException, TsapiInvalidStateException exceptions. Application has handled these exception along with InvalidArgumentException and generic Exception.

My question is if JTAPI is receiving CSTAUniversalFailureConfEvent then why it is not forwading it to client application.

I have included your question in the issue I raised with the product team. In the meantime, assuming you're operating in an EAS environment, I would suggest that your application does not provide a hunt group value. The hunt group parameter is not needed for EAS environments, and that parameter "should" be ignored, but providing a value is apparently impacting the behavior as noted in this thread.