Usage of requestIds

[mark.rennie1]

Hi,

One issue we're discussing with our application's implementation of Finesse is how to correlate requests with responses.  This is particularly important for handling error scenarios in our application.

E.g. If we get a Finesse response API error when the agent attempts to go ready then there will be nothing to tell us that the notification is in response to an attempt to go ready.  We need to be able to match the notification back to the appropriate Rest API call so we can post the correct event in our application to tell the agent their ready request was unsuccessful. 

Without this we may get a API error notification like CF_RESOURCE_UNAVAILABLE but will not know what operation we were attempting when we get this failure.

From reading through the docs I was thinking we can use the requestId field to tie these together.  However I have a few questions about use of requestIds as I don't think the documentation is fully clear on this.

• Are we expected to set the requestId header on all Rest API requests ourselves?
  • The documentation appeared to suggest this for User API requests.  However it suggests the Dialog API (as of v11) will return a unique requestId - is that without requiring us to have set this initially?

• Is it required that this field is a unique string?  Or could we just use it to represent the request type e.g. "GO_READY", "GO_NOT_READY", "ANSWER_CALL" etc. 
  • We could then check the requestId on the API error response and we will know what failure operation event to post in our application as we would know what we were attempting to do (e.g. Login failure, Answer call failure etc).

Thanks,
Mark

[dekwan · Accepted solution]

Hi Mark,

You are correct that the requestId is the way to go to solve your problem. After reviewing the documentation again, you are right that the documentation isn't very clear on this topic.

• Are we expected to set the requestId header on all Rest API requests ourselves?
• The documentation appeared to suggest this for User API requests.  However it suggests the Dialog API (as of v11) will return a unique requestId - is that without requiring us to have set this initially?

Yes, for every request that you make, you need to set the requestId in the header yourself. This applies to both User and Dialog REST APIs.

• Is it required that this field is a unique string?  Or could we just use it to represent the request type e.g. "GO_READY", "GO_NOT_READY", "ANSWER_CALL" etc.
• We could then check the requestId on the API error response and we will know what failure operation event to post in our application as we would know what we were attempting to do (e.g. Login failure, Answer call failure etc).

I don't think that the API will be rejected if it isn't a unique string, but you may come across some issues with the request/responses being correlated correctly, so I would suggest using a unique string.

Thanx,

Denise

[mark.rennie1]

Thanks Denise.

Do you know how reliable the requestId functionality was back in v9.0 for User requests?  We are currently developing against a v9.0 lab while we await getting a v11.0 lab configured to use instead.

We're now setting the requestId on our User request headers and we mostly see this coming through correctly and can use it as described.  An exception is when we make the following type of request:

          User - Change Agent State With Reason Code

Depending on what reason code we are setting the agent state to we find that the requestId does not always come through on the notification.  (i.e. It does for one of our reason codes but not for the other).  Just in case this is a known issue, or there is maybe config that might be impacting?

Cheers,
Mark

[dekwan]

Hi Mark,

To be honest, I don't know how reliable the requestId functionality was in v9.0. You are probably right that everything works except changing state with reason codes. It is definitely not a config thing.

The requestId functionality was improved in the later versions of Finesse and it finally got added to dialogs in v11.0.

Thanx,

Denise

[mark.rennie1]

Thanks!

Just wanted to add for clarity that I have now been able to verify the behaviour of requestIds on a v11.0 dCloud Finesse environment and the above scenario now works as expected.  (i.e. request ids are now properly set each time when changing state with reason codes).

Cheers,
Mark