Cloudy CE Deploy Update

Just a quick update on Cloudy CE-Deploy. 

One thing I noticed missing from the original CE-Deploy application was the ability to guide the user through the settings and not giving any feedback. This time around I am adding some new features that help admins work out what fields are needed to deploy. Basic UI features like tool tips, alerts and notifications. The cool part is that many of these features are easily enabled and controlled with Electron. I have come to appreciate what Electron and Bootstrap have available to make better applications. 

Features to date:
  • Oauth Webex Integration
  • Deploying a command or status via cloud xAPI
  • Use CSV of device ID's, individual Org ID, Tag or device ID to deploy to either lots of devices or just one
  • UI updates to include future supported features like Macro upload
  • Alerting user to missing information
  • OS notifications on deployment completion
  • Message console display to provide deployment information in progress versus having to refer to logs after the fact.
As the application gets closer to completion I will post up on Github as a public repository. This time around its based on the Electron Boilerplate. This has all the tools already built in to get a Electron project moving. Unfortuniatly some of the features I wanted to include like deploying a macro will not be available on first release due to API limitations but in time will come.

If you want to know more about this application come and join the conversation on Webex Teams here:


Video: CE Macro Timer

If you haven't seen the Youtube Webex Channel you really should. Richard Bayes, who appears in the video below, posts regular content on CE related topics. It's well worth a look. This week Richard is covering a timer Macro which can be handy in all sorts of situations.

I have been busy this week creating Cloudy CE-Deploy but will post an update on progress next week. UI is nearly done.


Cloudy CE-Deploy, Still Cloudy!

Cloud, cloud, cloud, it's all I hear about these days. Well, I thought it was time to join the ranks. Below is a screenshot of some of the work I am doing on a Cloudy CE-Deploy that will take advantage of the new Webex devices cloud XAPI. While I could incorporate this into CE-Deploy, I thought it a great time to do some clean up and investigate a better Electron boilerplate than I had been using. This is after all my second Electron app. Initially Cloudy will allow personal token use but Webex integrations with oauth support as the final goal.

Raw XAPI command processing is the main feature right now but open to other suggestions. Comment below.

Not familiar with CE-Deploy check this out.


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.
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.



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+.

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.


If your interested in building a server version of this project, I have a starter project you can check out at 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:!/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.