Query related to SessionId in conversations .
The sessionId datatype received previously is Guid but right now the value returned is not guid for cobrowse. It is returning a alphanumeric value.
My query is why there is datatype change and only specific to cobrowse.
Could someone look into this issue.
It's not a datatype change from their perspective.
It's always been a string, it just happened to be a string that contained a GUID-like-id until now.
This is unfortunately common in the platform.
If you refer to the diagram here session id was viewed a char(73) even years ago.
In the WFM module their exceptions are GUIds, except for the built in exception types, which are raw numbers so you have craziness like this;
And have to treat the whole thing as a string.
In the session portion of a Conversation the field protocolCallId is another one where it's a GUID until it isn't, cause both;
00003583-7e5b-40f4-88cc-33a1d31c244d
and
0gQAAC8WAAACBAAALxYAAMZa28IZuPcLjuura+HrWh66J5MeNs8D+BI+oaoTtm2HyQeEb/6a9rkgiHRQJhaOQg@65.xxx.34.142
are valid values for it.
Anything the API says is a string should be treated as anything else at your own peril, even if it says it's a "unique identifier" and most unique identifiers appear as GUIDs;
I appreciate for your quick response, do we have any repo for er diagrams similar to the conversation model
Unfortunately that is the only one I've ever seen.
Thank you @Eos_Rios , no problem
What is the datatype you used for protocolCallId and column length.Related to protocolCallId it was not mentioned in the blue prints as well.
I was thinking of discussing about some other issues as well but when i tried to send a message to you it is telling user is not accepting messages.
I want to discuss about In ApiException object Error code is returning 0 which is not valid Http Status code.
We are expereriencing this error intermittently for few days.