As the services lead for Cireson I’m always looking for new ways to facilitate communication among my team. We have many brilliant people here and increasing the efficiency of our communication is a part of what separates us from the pack. We have a mantra here at Cireson that says when we tackle an engagement we ‘bring the team’ and that is more true today than it ever has been, and It’s my job to make sure that gets better and better.
In that regard we’ve started testing a new communications tool called Slack. I won’t go into the details of Slack or it’s capabilities here, other than to say that is is a Web 2.0 IRC like chat client and more. It has dramatically increased our real-time communication within the team and improved our knowledge and solution retention, but for this article I’ll focus on a feature called ‘slash commands’.
In essence a Slash Command is a user configurable API call to an outside web interface using a JSON formatted payload. At a higher level it’s a command that sends out a request to another website for information or to post information. Here is an example:
In this example I can type a simple command:
Now, this is just one example. We’ve also integrated Incident retrieval, knowledge article search, daily new knowledge article and new announcement notifications, and soon we will include a notification for new incidents that have been created.
All of this provides us with easy access to the things we use most often within a single interface. It also works via the mobile Slack application and brings the needed information directly into the conversation within the context of the request. It’s even searchable later and the answer (KB) is displayed right inline with the question or discussion.
I know, this all sounds great, but how does it work!? At a high level it works like this:
- We setup a Slash command for each function in the Slack admin settings and point it to our custom web service
- Each time the Slash command is run it sends the requested information to our custom web service that pulls required information out of the payload
- The web service then utilizes the Cireson Portal API to retreive the required information, translate it into a format that works with Slack and then posts it back into the channel in which the request originated
- For the scheduled tasks and notifications we use a simple Azure webjob that runs on a schedule, hits the web service and performs that same operations depending on the task
All of this is made possible thanks to the Cireson Portal API, where we can use an authentication token to perform JSON calls and retrieve data from Service Manager easily in order to put that data anywhere and in any format we could want.
In later blogs I’ll go into further detail on the Cireson Portal API, how it’s used and the internals of the custom web service we’ve created to utilize it.