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.
1 Like
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;
1 Like
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.
Hi @Eos_Rios
Could you answer below queries
1).What is the datatype you used for protocolCallId and column length.Related to protocolCallId it was not mentioned in the blue prints as well.
2). Regarding ApiException object Error code is returning 0 which is not valid Http Status code.
We are expereriencing this error intermittently for few days. Did you experience this error?
The forum discourages continuing topics marked as resolved.
-
varchar 1024
-
no
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.