Cisco Video Endpoint ServiceNow Integration

Ever wanted a way to allow users to create a ServiceNow ticket straight from the video room endpoint? Well you can. Using Macros and the new HTTP Post capabilities in CE9.7+, integrating to ServiceNow to raise a incident report is pretty straight forward. It has to be as I did it on my own endpoint!

In this post I am going to step through the UI and the macro in the order that stuff happens so hopefully it will explain how this all works together. Sometimes it is difficult to understand how code, UI interactions and the backend all work together. This should help layout exactly how it all works together to give a custom process flow to create a new ServiceNow Incident ticket.

Stepping through the UI, Macro and ServiceNow


The macro work has largely been done for us. This sample macro posted on DevNet's Github repository is a great starting point to build the process you want users to follow. The Touch 10 panel that gets created in the UI creation tool is nothing more than a simple button. Most of the actual work that gets done is by the macro. The macro is providing the logic for the screen/panel that is presented next in the flow based on the users selection. Finally the Macro posts the ticket number created by ServiceNow on conclusion of the process and presents the user with the incident number. Let's take a look at some of the more important sections of the macro to get a sense of what is happening.

Our process starts with the Touch 10 panel. The Report Issue button is nothing more than a button in the UI configuration tool.

Below is the In-Room Configuration tool view of the button. The button Id is "reportissue" which our Macro will use to identify which button was pressed.


Let us step through how it all works.

Step 1. The "Report Issue" button is pressed.


This step in turn generates an event by the codec we have subscribed to using the code below. In line 2 we identify the correct panel using the panel Id 'reportissue'. This goes on to launch the next UI element to the user.
--Script--
--Script--
Below is the multichoice menu our user is presented with based on the "UserInterface Message Prompt Display" options.


Step 2. Multichoice option selected.


Assuming our user has selected cleanliness as the issue, the feedbackId generated by that event is 1. The macro using the "UserInterface Message TextInput Display" command on line 6 after matching case '1' in the switch command generates the next step.

--Script--

--Script--

The user is given the option to add more details and submit the incident.


Step 3. Post Incident Ticket to ServiceNow on Submit.


When the user hits the "Submit" button the raiseTicket function is called which in turn calls the getSericeNowIncidentIdFromUrl function which is used to retrieve the ticket ID to post back to the user. Both of these functions rely on the new HTTP GET and POST features in CE 9.7+.

--Script--
--Script--
The users view of the ticket number. Although this is a practical way to show the user the ticket was indeed placed, the user now has to write this sucker down. An improvement on this script is to somehow automate getting this ticket number to the user, Webex Teams perhaps!


Here is our new incident ticket in the ServiceNow portal. So proud.


While running this as a Macro is pretty neato, running this as a server based application may provide more opportunities to add additional functions like emailing the user after they submit the ticket. In the macro above we are also using insecure https. This might be frowned upon by some security folks so using a server based version of this might help with additional security features like more secure https perhaps.

Something else to consider is what data you collect before you raise the ticket. Below is a snippet to grab the call details of the last call made. Once you have this you can add it to the ticket on the initial post. Other details like CE version, system name, IP address might also be worthy of collecting for the ticket to lower the amount of time someone has to spend manually collecting that data.

--Script--
--Script--

If your interested in building a server version of this project, I have a starter project you can check out at https://github.com/voipnorm/CESeNow. This project is a bit of a combo project as it has some additional code for pulling people presence and other data from an endpoint but all the code required to do this integration is incorporated. If you just want to take a look at the code the endpoint.js file is doing all the work.

For ServiceNow developer instance setup head to: https://developer.servicenow.com/app.do#!/home. Your developer instance is available for 10 days with no activity. Just be aware if it goes to sleep that reinitiating the instance may produce a different URL that you will need to update and may require a password update. Your password username combo has to be base 64 encoded so this will need to be updated as well.

This is a interesting project to put together and best of all it doesn't cost a dime. ServiceNow developer instances are free, you just need to sign up to their developer portal.

VoIPNorm

CE-Deploy Update - Disable Webex Assistant

If your not familiar with the CE-Deploy, check this out first:

http://voipnorm.blogspot.com/2019/07/ce-deploy-for-cisco-collaboration.html

Now for the update.

Recently I had a customer that wanted to test the Webex Assistant on their endpoints but as you probably know by now, when you enable the assistant all endpoint are enabled. There is no way currently to selectively disable it in bulk. The only way is via the API or on the endpoint web admin portal. With this update to CE-Deploy you can now bulk disable the assistant on an endpoint but still leave the setting available on the Touch 10 to be enabled later. There is a setting to remove the Touch 10 setting altogether but that may be for something down the road.


If your interested in trying CE-Deploy please let me know in the comments below or PM me on Twitter @voipnorm.

VoIPNorm

Making an Online Meeting Button for Cisco Video Endpoints

If you have seen the latest update for Webex Room Kit you would have noticed the "Join Webex" button on the Touch 10 screen. It's a nice add and brings together Cisco endpoints and meetings even further. But if you are like the companies I work with this button has its limitations. Firstly, it only allows you to join scheduled meetings with a meeting ID, so PMR's won't work. Secondly its only for joining a Webex. For some companies I am sure this won't present a problem and those restrictions won't matter but for most it lessens the value of this button. I would go as far as to say most companies should probably hide this button as it only makes yet another method to join a meeting thats limited to just one use case. What we really need is something more universal.

So how do we make a join button that makes it easier for users? We cannot account for every variation and conferencing service out there but we can look at what users might join and try to predict the most likely use cases. We can also look at what happens when they get it wrong and how we can help users move forward dialing the right URI or number.

Lets say, your company has Webex, likes using PMR but also uses scheduled meetings. We know that most users only join their own company meetings but occasionally they will want to join another companies meetings possibly on another service like Zoom. We can therefore say with certainty the main use case we want to ensure works is joining your own company meetings. Secondly we want a way to ensure it worked, the user was happy and if it didn't let's give them some help.

The flow is something along the lines of (please excuse my lack of drawing talent, this is as good as it gets):





In the Touch 10 below I hide the Call button. This make just one path to dialing a online meeting. The green "Online Meeting" button. This does however remove access to address book lookups. Not sure about you but last time I tried a address book lookup on a video endpoint it was not easy. 99% of your users would struggle with it so lets get rid of the confusion. If you want a simple call button, I would suggest make your own and call it Audio Call with only a numeric keypad. Forget favorites and recents to, make it simple.

Once the online meeting button is pressed we present an input panel so users can input a alphanumeric or numeric meeting ID or a full URI. Some users may be comfortable entering a full URI so we don't want to ignore that they may do this.
Our acceptable formats are:
  • 9 digit number for a standard schedule Webex meeting. This appends "@webex.com" and the assumption is it could be destined for our site or another companies Webex site.
  • Alphanumerical for personal meeting room. This is appended with "@yoursite.webex.com". PMR URI's require a sitename in the domain but don't worry if it's another companies we can address it after rejection.
  • Full URI. Any standard URI format such as bob@bjn.com.



Once the user hits join the call with either go through or is rejected. If it's rejected its more than likely they are looking at the touch panel to see what went wrong or redial. On disconnect we can present the user with a survey style question and see what happened. If the meeting ID was rejected there are a few reasons why this might happen.
  • Meeting ID was an invalid Webex meeting ID
  • Meeting ID or URI was mistyped but the user has a valid ID/URI
  • The user is typing in a valid meeting ID for another service like Zoom but didn't enter the full URI just the meeting ID

We could adjust our macro to deal a little better with guessing the different conferencing services and append the right domain but we will always have some overlap. As an example, Webex uses a 9 digit scheduled meeting ID and BlueJeans can have a 9-18 digit ID. Zoom can also have a 9, 10 or 11-digit number. The 9-digit number is used for instant, scheduled or recurring meeting. The 10, or 11-digit number is used for Personal Meeting IDs. So we can attempt to guess what conferencing service a user is trying to get to but it will never be perfect. Our best scenario is pick what is used most often and try to accommodate it. If what we pick is not what they are trying to reach and the call is rejected we can guide them how to reach their meeting destination. 

A much more complicated user experience would be to have a button on the touch panel for each different conferencing platform. That is apart from somewhat lazy complicated for the user. The average user will be easily confused with so many choices. A well educated user might be able to discern what button to use but most will not.

In the screenshot below the user has just input a 11 digit meeting ID. We reject it without dialing as it may be just a mistype or they may be looking for another service. Either way the corrective action is now ask the user to enter the full URI. Note the screenshot below shows a numeric keyboard but this would be better being the entire keyboard as now you require the full URI. The code has been adjusted to suit a full keyboard layout.


Below, our user has input a incorrect ID that was an accepted format so we attempted to dial but was rejected. So we give them a choice on disconnect. We could add a 3rd option here to get help as well. Another option here is to review disconnect cause codes and provide a menu based on what caused the disconnect. 


 In our case the user selects Meeting ID was rejected so we guide them to the right format to enter. Hopefully the user can recognise the URI in their meeting invite from the example on the touch screen.


Finally here is the macro to make this all happen.  Remember to build out the macro to match your most desired outcomes such as most relevant meeting service etc.

--Script--
--Script--

VoIPNorm


Project CE Cloud Lighting Part 3 - Touch 10 UI & Nodejs Code

We are starting to get serious now. We have our TP-Link light installed and setup on Kasa. Now we just need some Nodejs code and a Touch 10 UI to finish it off. Our Touch 10 interface looks something like this:


Our focused here is on the lights button. It's pretty simple with a panel pictured below:


I have yet to add the dimmer function in my Nodejs code but built the UI anyway. Seeing as I am the only user of this system, I think that's okay. The On/Off button is a slider which generates an event of 'on' or 'off'. Yep it's that simple.

For my slider I have given it the ID of "office". Now, whenever there is a event fired off the widgetId will be "office".




As with all of the projects involving CE building the UI typically takes less than 10 minutes but it's still fun to build and test them out. For Node code I took a previous project and have just made some adjustments and added some new code.

https://github.com/voipnorm/CEKasa

The CEKasa repo contains 3 files to make the project work. Our .env file to host are passwords and usernames, and the server and endpoint files. The endpoint file is an adaptation of the endpoint file  from https://github.com/voipnorm/CEbusyLightOmega/blob/master/endpoint.js.

What you will notice with the new endpoint file is some lines that are not required are commented out. This is because we will bring all our code together in a later post to build a room controller on our Pi. Now you get it:). I need more material to write about, that's right.

So what's the difference between the two projects you may ask? Well its below. The new monitorWidget function is looking for our Touch 10 events when you move the slider.


--Script--
--Script--

Once it has seen an event it emits its own event to the listener in the server.js file below which fires the light function turning on or off our lights.

--Script--
--Script--


Not a terribly complicated piece of code but it works.

There you have it folks, an inexpensive room light controller. In this project I am only controlling 1 light but this can be expanded to as many lights in the room as you like. I left the dimmer out for now. If you want to have a go, let me know your results in the comments below.

Final thoughts.


This was a fun project to put together. It's also pretty inexpensive with a bulb costing around $20. If you haven't realized already we are building what is a pretty inexpensive room controller using our Webex room system and a Raspberry Pi. A typical room controller system can cost anywhere from $2000 and up and to date we have spent less than $500 if you include the HDMI switcher from a previous project. While this does not include the cost of our room system of course which you would need anyway,  we are just taking full advantage of everything we can do with it combined with our Pi.

Hope your enjoying these project posts. It's a great way to get started programming with Pi, Webex Room devices and Nodejs.

VoIPNorm

Previous posts:

Intro to project:

https://voipnorm.blogspot.com/2019/09/project-ce-cloud-lighting-part-1.html

Working with Kasa cloud:

https://voipnorm.blogspot.com/2019/09/project-ce-cloud-lighting-part-2.html