Genesys Engage on-premises

 View Only
Discussion Thread View
  • 1.  Chat API Version 2 via CometD

    Posted 03-22-2023 11:49

    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


    #Integrations
    #Unsure/Other

    ------------------------------
    Francis Reynders
    Stefanini NV
    ------------------------------


  • 2.  RE: Chat API Version 2 via CometD

    GENESYS
    Posted 03-24-2023 00:31

    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). 



    ------------------------------
    Aleksey Kovalenko
    Genesys - Employees
    ------------------------------



  • 3.  RE: Chat API Version 2 via CometD

    Posted 03-29-2023 13:38

    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.



    ------------------------------
    Francis Reynders
    Stefanini NV
    ------------------------------



Need Help finding something?

Check out the Genesys Knowledge Network - your all-in-one access point for Genesys resources