PSDK monitor Chat Queue

[roman.smirnov]

Hi,

we have a Genesys Engage and a small application using Platform-SDK to access it.

There is a chat support in the system and two queues where the chat interactions are placed by the routing:
- Chat1: here comes the new chat interactions, to be taken by agents working with WDE.
- Chat2: here comes already handled interactions, after closing and routing-based post processing.

In my application I need to monitor both these queues. To get notified if a new interaction comes to/leaves the queue. And to get a list of interactions currently waiting in the queue. I need not only the numbers, but either the interaction ids.

I suppose it should be the Interaction Server to work with. And respectively this package:
com.genesyslab.platform.openmedia.protocol.interactionserver

But I cannot find anything related to my needs in documentation coming with PSDK or on your site here:
https://docs.genesys.com/Documentation/PSDK/latest/Developer/InteractionServer

Would you please suggest my the request I'm looking for?
Thank you in advance.

Regards,
Roman

[roman.smirnov]

Please not all at once!

[CTIGuy]

?You need this in realtime?
Because if you could read the InxDB, you can see the current interactions so fast.

You can monitor with the StatServer. If you need the number of chat OnQueue, see some StatServer Stats.
but, if you need monitor you routing chats in realtime.. mabe you need monitor the Virtual Queue of the Target in you Bussiness strategy. I really don't recommend this.

[roman.smirnov]

Yes, we need this in realtime.

The chats should be automatically deleted from the system because of data protection restrictions. But previously their texts should be handled in some special way (stats, keywords and so on).

Therefore I need the interaction ids.

It could be probably possible to implement a InxDB polling with checks for all the new interactions whether they of chat kind or not. But besides of the polling itself, it will rely on low-level Genesys implementation aspects. We don't even realy need the PSDK for that. From my point of view I see this as a hack. And would prefer to try something else.

The StatServer could only act as trigger for polling in already mentioned possible implementation, since it doesn't provide the Inx-IDs.

Could please give some more information about the monitoring the Virtual Queue of the Target in the Bussiness strategy? It sounds exactly like what I'm looking for.

Thank you!

[Kubig]

Why do not you just stop/terminate the interaction within the routing strategy? Is there any special reason or need which leads to PSDK integration?

[roman.smirnov]

Thank you for your answer.

As I already wrote, we need to do a special handling of the chat transcript and then to delete it entirely.

This probably can be achived with an inhuman way of direct editing of the [gen_ucs].[dbo].[Interaction] DB table, but we want to be noble and gentle in our genesys intercourse and therefore doing it with PSDK on.

[Kubig]

Direct DB access and change is the worst option you can think about. I thought you can use ESP and call it correctly from routing strategy hence it does not require any PSDK development nor external app achieving the same. I would achieve it using in-build functions and possibilities instead of developing something which is not necessary and not long-term useful

[roman.smirnov]

Thank you for your answer.

Could you please describe a bit more detailed what exactly you are suggesting?

[CTIGuy]

[i]I need to monitor both these queues. To get notified if a new interaction comes to/leaves the queue. [/i]
Try to monitor the Virtual Queue Attached to the routing target.
If you only need to monitor READ ONLY..  look into the [gen_inx].[dbo].[Interactions] Check the status bit and the Queue

[i]And to get a list of interactions currently waiting in the queue. I need not only the numbers, but either the interaction ids.[/i]
look into the [gen_inx].[dbo].[Interactions] Check the status bit. All the finished interactions are deleted from this table.

[i]we need to do a special handling of the chat transcript [/i]
[i]and then to delete it entirely. [/i]
Provide more details on when you need to delete the record completely.


important: never delete a record in the UCS or INX DB
I remember a ticket where support indicated that it could create a major problem in the system.
The correct procedure to delete is from the strategy in URS
If you need to do something after the agent conversation, I think you should do it directly in the strategy, after the representative.

If you need edit UCS DB, maybe you could edit the JSON with the transcript. Under knowledge that the system may crash. But again.. use URS for edit the transcript.
Open a ticket in support.

[roman.smirnov]

Thank you for you reply.

We need to:

1. Find all the interactions staying in some queue. They are placed there by the routing after the chat is over. It's a read-only operation.
  Probably this can be implemented via InteractionServer + either RequestFindInteractions or RequestTakeSnapshot PSDK request.
  This information is actually the answer to my initial question.

2. Process the chat interaction content. It's the same as saving the chat text elsewhere. It's a read-only operation.
  UCS+RequestGetInteractionContent.

3. Move interaction into some other queue. Read-write.
  Ixn+RequestPlaceInQueue.

4. Clean everything about the chat, including it's time, content and the participants from the ContactServer. Read-write. Consists of:
  a. UCS+RequestDeleteInteraction
  b. UCS+RequestDelete

Now. What are you suggesting to change here or to substitute with a Routing Strategy?

[cavagnaro]

Why PSDK and not just the strategy already controlling interactions? Your definitions are quite vague, and therefore the best way would be to handle via strategy.

Enviado de meu SM-S918B usando o Tapatalk

[roman.smirnov]

[quote author=cavagnaro link=topic=12542.msg55653#msg55653 date=1713465758]
Why PSDK and not just the strategy already controlling interactions? Your definitions are quite vague, and therefore the best way would be to handle via strategy.
[/quote]

Because afaik the strategy cannot save the text of a chat intercation into a file. And in my case it should be not just saved, but transmitted to a 3d party system:

[quote]
2. Process the chat interaction content. It's the same as saving the chat text elsewhere. It's a read-only operation.
[/quote]