OpenMessage - need to either disable input, or inform agent message didn't go through

Platform API
1

I have an OpenMessage integration with a 3rd party chat service. When the agent receives the first message, there is a handshaking happening with the 3rd party service which may take a few seconds. During that delay, the agent could send a message but the message would not be received by the customer because of the on-going handshake.

Is there a way to return an error to the webhook request that would inform the agent that particular message wasn't received? I tried returning back some non-200 codes but it caused the entire chat to fail instead of just the attempted messages.

Or is there a way to disable the agent input from the API until the handshake is done?

2

HI @alex7, you should be able to use delivery receipts for this situation. As you saw there, you would need to accept the outbound message request from Genesys there (2xx response). You can then do with it whatever you need in your service. Then just inbound a receipt for that message, to inform the agent of it's status (failed for instance). outbound-receipts using this api post-api-v2-conversations-messages--integrationId--inbound-open-receipt

3

Thanks. I assume the id is the ID of the message?

I haven't been sending receipts all this time, obviously. If I don't send back 'Delivered' or 'Sent', it still should work correctly. Right? Or is it best to always send a receipt, success or not?

4

the id has this documentation in the api already.

The original unique message Id generated by the messaging platform, that this receipt message is referencing.

Is there confusing wording there? inboundReceiptMessages this page might help too.

You can use receipts or not, it depends on what you want to do. If you want agents to receive updated information on the message once it gets to your open service (outside Genesys platform) or after that, then I would consider using them for both success and failures. Without them, agents will only know the message was "sent" out from Genesys platform.

5

It wasn't exactly clear. What I did was basically take the messageId from the OpenMessage received and used it for the corresponding receipt.

6

Does the 'reason' have any significance to the agent or to Genesys's behavior? The reason message doesn't seem to be conveyed to the agent. Is it only used internally?

Is there a reason code where Genesys will retry?

7

Yes the reason will be on the Conversation (errorInfo using get /api/v2/conversations/messages/{conversationId}) and Message details (normalizedReceipts using get /api/v2/conversations/messages/{messageId}/details). The Agent UI might not expose this today, but certainly could in the future. I wouldn't base your decision on not using it, just because the UI doesn't show it today. If for nothing else it might help you keep track of things later.
Genesys is not going to automatically retry those messages for you, due to you sending any receipt type. It's just a mechanism for you to inform Genesys/Conversation of what happened with it once it went out from Genesys Cloud's control.

8

@alex7 One other option I thought of. You could do something like this in your open middleware

//Accept message from Genesys and return 2xx response
boolean handshakeComplete = false;
WaitUntil(() -> {
//Checks for Handshake completed
handshakeComplete = true;
}
if (handshakeComplete) {
  //Send message on, and send a receipt back to Genesys with  "status": "Delivered" with "isFinalReceipt": true 
} else {
  //Send Failed receipt back to Genesys
}

Just pseudo code of course, and might not be useful in your situation. But essentially just queue the message on your side for X time, and do whatever you need. Once the agent gets delivered or failure receipt (which are both available via the Agent UI today. Sent shows 1 checkmark, Delivered shows 2 checkmarks in UI) then they know the message was delivered or not at least.

1 Like
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.