This is a guest post from Fred Nielsen. Nielsen is a long time convergence and collaboration architect working for ePlus, focused on delivering solutions that mesh seamlessly with customers' existing business environments. ePlus is actively developing solutions that integrate the innovate functionality provided by the Spark platform into existing business processes and technology. Contact Nielsen through Twitter at @fredless or by email at email@example.com
For those of us who have been working with Cisco’s collaboration product offerings for any significant period of time, the emergence of the Cisco Spark product within the portfolio represented something of a brave new world. Spark extended the reach of a powerful offering into new territory, and showcased Cisco’s distinctly cloud-first posture in bringing additional capabilities to market.
Cisco took us several steps further into this bright new future last December with their preview release of a new web API allowing anyone with a Spark account to weave their tools and solutions into the Cisco Spark platform. Rather than an off-the-shelf product that those of us who are consultants or partners could install and configure within our end-customers’ environments, the API gives us powerful building blocks to go out and create our own unique new solutions. These solutions can be very deeply embedded into existing workflows, or be used to create a completely standalone solution with unique new capabilities. Being in a position to create solutions from the ground up is something of a new challenge for many of us – including myself. I wrote this article to demonstrate how simple it is to get started leveraging these new capabilities, and how one simple idea can be implemented into a powerful use case.
As I started exploring the various functions documented here, I could immediately see what types of things the API allowed me to do. I began to have lots of ideas, but wasn’t sure I had the necessary skillset needed to implement them. Along the way I had heard a little about Cisco’s partnership with several iPaaS providers; including IFTTT, Zapier and Built.io’s Flow product – so began fiddling with the capabilities those offered next. Each are unique, but all feature simple interfaces that allow users to quickly create Spark test apps. What these products also have in common is that they make it simple to interconnect different apps – a message in your Office 365 mailbox can be used as a trigger to take some sort of action in Cisco Spark for example. More lightbulbs went off and I was on my way. What follows is an overview of one of those lightbulbs that I was able to implement in about 15 minutes – without a single line of code.
Anyone who has watched a few episodes of Star Trek has no doubt seen a crew member employ the Universal Translator – a magical device which somehow translates any language, known or unknown, into perfect Starfleet English. I’m a fan of the free browser based translation tools we have at our disposal today – but they offer a mostly manual solution to an old problem. I had the idea: what about a function that could monitor a Spark room, and if it detected a foreign language message, simply translate it? The obvious use case: allow participants with differing language fluencies to communicate more effectively.
After looking around at different translation providers offering web service APIs, I eventually found that Microsoft Translator could do what I needed with an OAuth token and single simple HTTP GET request, for example:
Translator attempts to automatically detect the source language and simply outputs back translated text in requested language as XML like so:
Now, how could I implement my idea into a workable solution? Zapier and IFTTT are both hard to beat tools for quickly building action\reaction workflows, but I needed to a few more steps and some conditional logic in my process to accomplish want I had in mind. This type of situation is where Built.io’s Flow shines. Flow offers a GUI interface in which multiple “Activities” can be connected together, with output from one activity feeding into subsequent steps. You can specify sophisticated conditional logic and incorporate just about anything you might need into your workflow.
I quickly assembled a new flow and dragged in the following Activities from the toolbar, connecting them together:
After enabling the flow to accept webhooks in the Flow UI, and creating a new webhook event using Spark’s API, here is our end result:
Success! Now this is only a simple example, there is certainly more that could and should be done before we could call this production ready. Some of which might even involve some minor coding, but Built.io’s product offers lots more options than I’ve shown here. You can even construct your own Node.js code snippets and drop them anywhere into your process to tackle some of the hard stuff. It’s a surprisingly effective solution that sits squarely in between more simplistic drag-drop offers and custom web service development – bringing some of the best of both together.
I hope this opens your perspective on how very easy it is to get started developing applications with the Spark API, even for a non-developer. Come up with an idea and try it to work it out for yourself with the many tools we now have at our disposal. Everything I leveraged above is available free of charge for development. Most of Microsoft’s web APIs are free to use within certain monthly limits, and Built.io and Zapier both offer time-limited trial accounts allowing you to kick the tires. Hopefully we will see some of those vendors also introduce partner developer programs to make it even easier for us to continue learning, leveraging and advocating these types of solutions to our own end-customers in the future.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.