Hi!
I am building an integration to Superoffice on behalf of a customer (in python).
Specifically, the client wants to use third party chat/messaging software for customer to agent interactions, and then store those conversations as ChatSessions.
I am trying to store these conversations as ChatSessions using rest POST /api/v1/ChatSession for creating the chatsession with initial data, and then POST /api/v1/ChatSession/Messages for storing the actual messages.
My issue is that the timestamps I provide when creating the chat session gets rejected/neglected. The other data in the payload is correctly stored in SO, however the timestamps does not appear in Superoffice nor are they reflected in the response from the request.
A minimal payload:
payload = {
"TopicId": 2,
"CustomerAlias": customer_data['Kontaktnamn'],
"CustomerEmail": customer_data['Email'],
'WhenEnded': '2023-08-23T16:07:42.2383759+02:00',
'WhenFetched': '2023-08-23T16:07:42.2383759+02:00',
'WhenIdle': '2023-08-23T16:07:40.2383759+02:00',
'WhenRequested': '2023-08-23T16:06:40.2383759+02:00',
'WhenStarted': '2023-08-23T16:06:52.2383759+02:00',
"Status": 9,
"User": {'AssociateId': 518}
}My expectation, based on the documentation found here, is that WhenEnded, WhenFetched, WhenIdle, WhenRequested and WhenStarted should be posted with the values supplied when doing POST /api/v1/ChatSession, and reflected in SuperOffice
The response I get from API looks like this;
Where WhenEnded seems to be automatically set when I also set status=9 in the payload. The other timestamps are incorrect.
In superoffice, the duration of chat is showing the following:
And the other times are not showing at all (when started is empty, for example).
In order to reproduce the same problem, I think do POST /api/v1/ChatSession using rest-api with the minimal payload supplied should suffice, changing the user id and topic values to something corresponding.
The problem might be the format of the timestamp in the payload (should be string), and I have tried multiple ways of formatting it. The same issue carries over to storing messages on POST /api/v1/ChatSession/Messages, where the time is saved as the time of the request and not necessarily the time(s) supplied in the payload.
My other sneaking suspicion is that there is some other, hidden dependency related to the timestamps that makes the endpoint ignore those parts of the payload.
All Replies (4)
Hi Michael,
When we did a investigation into the chat api's for possibily connecting a third pary chat program we hit the same issues. The chat module within SuperOffice is actually build with-in the Service module part (the backend part then, front-end is SCIL). Due to this the API's that are available through NetServer (REST API) are pretty lackluster since SuperOffice doens't actually use these within the chat module. (The chatsession/chatmessage saving is actually done within service).
My guess would be that the WhenFetched/WhenIdle/WhenRequested/WhenStarted are only saved when you go through the actual logic/steps of a chat session, not when creating it.
A workaround would be to create a CRMScript which uses the SearchEngine class to update the fields directly on database level, which you then execute through the API.
Sample CRMScript:
#setLanguageLevel 4;
// supply this as parameterss when executing the script
Integer chatSessionId = decodeDBValue(getCgiVariable("chatSessionId"));
DateTime whenRequested = decodeDBValue(getCgiVariable("whenRequested")).toDateTime();
// etc..
SearchEngine seChatSession;
seChatSession.addData("chat_session.when_requested", whenRequested.toString());
// etc..
seChatSession.addCriteria("chat_session.id", "OperatorEquals", chatSessionId.toString());
seChatSession.update();Thank you! Given that CRMscript is not available by default, would this solution require me to register a new application?