Why is my EventUser not being delivered correctly?

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)

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.

2 Likes

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

Hey,

I actually know who you are :slight_smile:

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!

1 Like