Why is my EventUser not being delivered correctly?

[periscala]

Hi,

I am using Genesys SDK to connect to T-Server and exchange messages between agents using RequestUserEvent.
I see EventUserData but it is not being propagated to the client. Why, god, why?

10:56:18.075 Trc 04541 RequestDistributeUserEvent received from [440] (00000007  121.21.65.158:2973)

message RequestDistributeUserEvent

AttributeReferenceID 23

AttributeThisDN '3447'

AttributeUserData [23] 00 01 00 00..

'TestKey' 'TestValue'

AttributeCommunicationDN '3447'

10:56:18.075 Int 04543 Interaction message "RequestDistributeUserEvent" received from 440 ("")

@10:56:18.0750 [0] 7.5.009.00 send_to_client: message EventACK

AttributeEventSequenceNumber 000000000000009a

AttributeTimeinuSecs 75000

AttributeTimeinSecs 1214445378 (10:56:18)

AttributeReferenceID 23

AttributeThisDN '3447'

AttributeUserEvent RequestDistributeUserEvent

10:56:18.075 Trc 04542 EventACK sent to [440] (00000007  121.21.65.158:2973)

@10:56:18.0750 [0] 7.5.009.00 distribute_user_event: message EventUserEvent

AttributeEventSequenceNumber 000000000000009b

AttributeTimeinuSecs 75000

AttributeTimeinSecs 1214445378 (10:56:18)

AttributeUserEvent EventUserEvent

AttributeUserData [23] 00 01 00 00..

'TestKey' 'TestValue'

AttributeThisDN '3447'

AttributeReferenceID 23

10:56:18.075 Trc 04542 EventUserEvent sent to [404] (00000004 StatServer 121.21.65.160:3743)

10:56:18.075 Trc 04542 EventUserEvent sent to [392] (00000003 RoutingStatServer 121.21.65.160:3742)

10:56:18.075 Trc 04542 EventUserEvent sent to [372] (00000002 OCS 121.21.65.160:3741)

Where is sent to [XXX (My Client))?

And yes, I have registered 3447:

16:47:20.527 Trc 04541 RequestRegisterAddress received from [440] (0000003e  121.21.65.158:2973)

message RequestRegisterAddress

AttributeThisDN '3447'

AttributeRegisterMode 0

AttributeControlMode 0

AttributeAddressType 1 (DN)

AttributeReferenceID 9

(tservice_proc) ControlMode set to 1 for 3105

@16:47:20.5270 [gctmi] Distributing request RequestRegisterAddress

@16:47:20.5270 [tsgctm] Address [3447,tDN,sIDLE] reqRegisterAddress

@16:47:20.5270 [gctmi] request RequestRegisterAddress removed from reqMgr

@16:47:20.5270 [0] 7.5.009.00 send_to_client: message EventRegistered

AttributeEventSequenceNumber 00000000000010fe

AttributeTimeinuSecs 527000

AttributeTimeinSecs 1214293640 (16:47:20)

AttributeExtensions [144] 00 07 01 00..

'AgentStatus' 3

'queue-1' '4871'

'AgentStatusTimestamp' 1214293278

'AgentLoginTimestamp' 1214293278

'AgentWorkMode' 4

'mwl' 0

'status' 0

AttributeAgentID '5173'

AttributeAddressType 1 (DN)

AttributeThisDN '3447'

AttributeReferenceID 9

16:47:20.527 Trc 04542 EventRegistered sent to [440] (0000003e  121.21.65.158:2973)

[victor]

Ok,

first of all, it seems like both of your clients use the same connection to T-Server:

16:47:20.527 Trc 04542 EventRegistered sent to [440] (0000003e  121.21.65.158:2973).

Are you by any chance using our GAS Server? Looking through the log, it seems like our GAS Server framework based on platform SDK. Am I right? If so, you cannot get the event back, because both of your clients are behind GAS, thus
Genesys T-Server would not return Event to it, because that connection is seen as originator of the request, thus only Ack would be returned to it.

I wonder if there is a different way to do it. Let me see what is going on.

[periscala]

Hi, Vic,

you are right, we are using STAR's GAS 1.0 with Platform SDK. I wanted to modify the functionality so we would get the messages that agents send to each other inside tserver logs, by modify userEvent to issue RequestDistributeUserEvent.

PP

[victor]

Hey,

I actually know who you are

Well, it would not work; however, it should be fine, because GAS would not only issue a message to T-Server but actually if it determines that the other user is on the same GAS　server, it will also forward the event directly to that user as well. I like your concept of adding RequestDistributeUserEvent because it means you could then exchange messages between two separate GAS servers. I think we should add it as default. Very nice thinking!