PureEngage On-Premises

Hi,

We are reviewing our implementation for Chat API Version 2 integration via CometD. After looking in much detail it looks like the interface is lacking compared to the regular REST interface. The major issue we are experiencing is that it seems impossible to correlate our commands with the responses; in the CometD version the commands are sent asynchronously, and we receive responses through a listener. There is no correlationID. We can only guess what responses are related to what commands. This in contrast to the REST interface where there is an inherent request-response mechanism.

A specific use case where this becomes clear is if we receive a CometD message with response status 1. The documentation says we can retry the operation. However there is no deterministic way to identify which command to retry in CometD context. We can only guess based on timings.

We are at a point that we consider reimplementing the integration in REST. Would you agree this is the only way? Can we combine REST and CometD so we can still receive transcript messages streaming?

Thank you

The nature of CometD operations is asynchronous, and so the only way to find how the request succeeded is to process its status code (it makes sense to send requests sequnetially - not in pralallel under these circumstances). The push notification through CometD may contain other events (not only the event that corresponds to the latest request submitted).

For sure, no mixture of REST API and CometD must be used - it could lead to unpredictable behavior of the solution (especially in HA/failover situations).

REST API is completely fine to use - you can read PROS and CONS on https://docs.genesys.com/Documentation/ESChat/latest/Admin/DeployAsyncReg (perfomance benchmarks section)

If your web chat application communicates with GMS through a mid-layer (i.e. your web service) - you may consider implementing https://docs.genesys.com/Documentation/ESChat/latest/Admin/ACHATPUSH - it provides notifications about new events in transcript and so you do not need to do short polling constantly - only upon notification (or once in a while just in case if something missed). 

Hi,

Thank you for your detailed answer. 

So when saying sequentially, you mean to wait for a status code after each command before sending the next? Or keeping a queue of continuations for commands sent and associating the responses in order? I'm a bit hesitant to do that since CometD documentation states that it does not guarantee message delivery or order (there are extensions for this though). I still don't see a fault proof solution without a correlation ID or leveraging CometD Service channels for request/response patterns. It's fine that events are grouped and fully asynchronous, but response status codes should have a deterministic way to associate with the request.