Chat History in an Incident...With a Little Help from Ajax....

[slabodnick]

I'll admit it, I've been lazy with giving back to the ServiceNow Community, but after a brief conversation with John Roberts a few weeks ago, I definitely feel motivated to get off my tuches and get back to writing. To begin, I wanted to outline my solution for expanding on Chat Actions and the use of Ajax, specifically to solve the obvious problem that creating an incident from chat does not include the chat history.

Before continuing I do need to state that I'm assuming you've already turned on the Chat plugin and are familiar with creating Chat Actions. If you don't know about Chat Actions, take a look at this wiki article http://wiki.servicenow.com/index.php?title=Adding_Actions_to_the_Chat_Window_Menu. Once you've read the wiki and are ready to go, continue reading (don't cheat and continue if you haven't read the Wiki, I'll know)...

When it comes extending Chat, specifically pulling the chat history, you need to know a little bit about the chat tables. "chat_queue_entry" is a table that houses information for the chat queues. "chat_room" contains information on the status of available rooms and references "chat_queue_entry." "chat_message" is the table that houses chat message information and reference the "chat_room" table by the field of "Chat channel." The reason I'm listing these tables is because to find chat history, each of these three tables need to be queried. Another important thing to note is that users with the ITIL role do not have access to read from these tables. To get this method to work, I had to add in ACL's to at least make the tables readable. Another thing to keep in mind is once users can read from these tables, chat history technically isn't private. I believe in 100% transparency, but not everyone may agree with that philosophy and additional security may be required to try and be selective on what people can and can't read.

Alright, getting into more code. Since the chat runs from the client it's best practice to build the action using Ajax with a script include (make sure you also check out the Ajax wiki article http://wiki.servicenow.com/index.php?title=GlideAjax). I'll admit that my first instinct for this solution was NOT to use Ajax, so once again I need to give credit to Tyler Jones for pointing me in the right direction. I've been getting more into script includes and I have to say, Ajax is the way to go to prevent the browser from freezing and causing problems. My first step was to build a script include called ExtendedChatFunctions (I think I intended to add more to the script include, but for right now it only works to include chat history). This script include does all the work on the back-end that basically follows this sequence:

1. Find the corresponding chat queue in "chat_queue_entry" table. This is done by matching the short_description and sys_created_by fields from the g_chat.getProperty('short_description') and g_chat.getChatQueueUser() methods, and ordering by sys_created_on to take the latest record from the table (which should be the entry from the current chat session).
2. Once the chat_queue_entry record is found, using that record to query "chat_room."
3. Once chat_room has been found, using that record entry to search "chat_message" and order the messages as they would show in the history. Also, the query on chat_message filters out any system messages to automated responses aren't included.

Awesome, you now have the chat messages. What now? Obviously, they need to be inserted into the incident record. But with Ajax, it can be tricky with returning data to the client that called the Ajax script include (I know, I have dents in my wall from figuring this out). This also plays out that Ajax is meant to be asynchronous (obviously), yet the data needs to be returned in order to run the "g_chat.fire(LiveEvents.WINDOW_CREATE_DOCUMENT..." function that ultimately creates the incident, and waiting for data to be returned from the Ajax call defeats the purpose of using Ajax. This is where things get a little funky.

After digging through some of the javascript source code, I found more information from the WINDOW_CREATE_DOCUMENT function. So, instead of using the Live.Events.WINDOW_CREATE_DOCUMENT, I had to rebuild part of the function from within the chat function. The reason for this is because from within the chat action, I passed the Ajax call into a function. Once the scripting goes to that function, LiveEvents doesn't seem to "exist" to the script anymore and errors out. I'm not sure if it's the best approach for such a function, especially if ServiceNow changes the method and can potentially break this customization, but (so far) it's been the only way I could find in order to actually pass the chat history into the incident.

Now that the general code is figured out, the sky is almost the limit for what you can pull from ServiceNow and place into the incident. For example, I also can run a query on the sys_user table to include user information into the incident record. On the horizon I would also like to expand chat actions to include an "update history" action that could take any chat history created since the incident was created, and update the incident with the "new" history.