Building Cisco Webex Teams bots and integrations that need access to behind-the-firewall resources is a challenge that regularly faces developers building Webex applications for internal use. Webex API events are delivered with an HTTP push model that requires your bot to be hosted on a web server that’s available on the public internet, but not all IT infrastructure allows for public web servers. To make this easier, we've worked with PubNub to create a reference architecture that allows enterprise applications to use PubNub's infrastructure to deploy bots and integrations behind the firewall. PubNub is a publish and subscribe service that makes it easy to deliver events to applications in real-time, across a wide variety of network configurations. If the application can reach the internet, it can receive PubNub events. Today we're publishing a reference architecture, helper applications, and sample code that allow you to use PubNub as a transport to get your Webex Teams events delivered behind the firewall, to mobile clients, or wherever you need them to go. This reference architecture uses PubNub as your webhook URL, and PubNub will publish all webhooks to a PubNub channel. Your application subscribes to this channel, receiving all webhooks over this channel in real time. Minimal changes are required to your application, often only requiring a few lines of code to be added. We've published a GitHub repository containing sample code, instructions for implementation, and helper applications. The repository also contains a plugin for Howdy Botkit that makes any Botkit application use PubNub. Sign up for PubNub's free developer trial and download the sample code to get started. If you're at Cisco Live in Orlando this week, stop by the PubNub booth in the Investment Village inside the World of Solutions to talk about this reference architecture and many other ways you can build real-time applications with PubNub. And stop at the theater near the Investment Village at 2:50pm on Monday June 11 to hear Webex Evangelist Phil Bellanti and PubNub CEO Todd Greene talk about this architecture. ... View more

A few months ago we added the ability to retrieve a person’s status from the People API. The available status options are expanding to include a few more in addition to active and inactive . People can now also be Out of Office ( OutOfOffice ) or Do Not Disturb ( DoNotDisturb ): Out of Office ( OutOfOffice ) is available to organizations who have Calendar Integration enabled. Ask your organization administrator for details about your organization’s calendar integration settings. Do Not Disturb ( DoNotDisturb ) is a temporary status set by the user via the Spark desktop, mobile, or web clients. The Spark status field is read-only; Spark determines the appropriate status for the person automatically. With the new additions, a person can now be active , inactive , OutOfOffice , or DoNotDisturb . We focus on providing you the best features and experience. If you have any questions, feel free to reach out to us at devsupport@ciscospark.com or join the DevSupport Spark room. Follow us on Twitter to stay updated. ... View more

Since we introduced Administration APIs this past October, you have asked how you can build and test with these APIs without being an administrator in your organization. To help with this, we have created a Administrator Sandbox organization that we can make you an administrator of. Then, using this new organization, you can develop and test your integration. There’s a few rules and things you need to know about using this Sandbox organization, so read the documentation for details. ... View more

Last week, we introduced a bot that allows you to play the classic text adventure game Zork in Cisco Spark rooms or over SMS through Tropo. Here’s how the bot works (links to the source code repo are at the end of this post). First, a little history. Back in the 1980s, Infocom created a virtual machine called a Z-machine that Zork would run on. Writing new games was a matter of creating a game file that the virtual machine could read. This made porting the game to various computer platforms simpler, as they’d only have to port the virtual machine, not the entire library of games. Once Infocom closed down and had their assets absorbed into Activision, game enthusiasts reverse engineered the Z-machine internals by studying the game files and ultimately created replacement Z-machines. One of these, Frotz, is the Z-machine driving this bot. Eventually, Infocom’s owner made Zork 1-3 available for free download, and the Zork 1 game file is installed in the bot. Frotz runs as a Linux command-line process, and has a mode where you can pipe game commands on stdin and get the results on stdout. The zmachine-api project, created by some engineers at OpenDNS, uses node.js to wrap a REST API around this project and manages starting and stopping the Frotz processes as needed. The Spark bot uses this API. The Spark bot relies on two Webhooks. One on message creation, is set up without a roomId filter, so all messages that @mention the bot or are in a direct conversation with the bot are delivered to this webhook. The second is a memberships created webhook, also without any filters, so that the bot is notified any time it is added to a Spark room. When the bot is notified by the Memberships webhook that it’s been added to a room, it immediately posts to the room, introducing itself. It explains what it is, and reminds room participants that they need to @mention the bot if they want to play. This small on boarding mechanism can help room participants understand why a bot was just added to a room and what it can do. This exact on boarding method isn’t appropriate for all bots, but when you are creating a bot, you should think about what a bot should do when it first becomes alive in a room. Each Spark room is a separate instance of the game. Move around the Zork world in one room, and then go to a different room, and you’ll find your Zork game there is still in the same place it was when you left it. Another bit of Membership webhook magic is used when the bot is added to a room that already has a game running. If you started playing, remove the bot, and then add it back in again, the game should pick up right where you left off. But the bot should still introduce itself, and also remind the players where they are in the game. Zork has a command called “look” that causes it to tell you what your current surroundings are. So when the bot is added to a room and sees there’s already a game for that room ID, it issues the Look command and shows the players what is going on. The messages Webhook is how the bot gets the commands from players in the game. When the bot is mentioned, or when someone speaks to it in a one-on-one room, the bot takes the exact input from the player and sends it to Zork.  The Webhook triggers the bot, the bot uses the message ID from the webhook to fetch the message content, and then that message content is sent to the game. One thing that isn’t immediately obvious when creating a Spark bot is how to strip the bot’s name from messages when it’s mentioned. For many bots, this can be as simple as a string match on the bot name and strip that string out. But because this bot has a two word name (“Text Adventure”), the mechanics of Spark mentions means that other people in the room could affect how the mention appears in a message. Spark puts the person’s first name in the message when you mention them, unless there are several people in the room with the same first name. Then to avoid ambiguity, Spark puts the full name in. For a bot like Text Adventure, the presence of another bot in the room called “Text Mom” could mean that sometimes the @mentioned name is “Text” and sometimes it’s “Text Adventure”. To handle this issue, when the bot server first starts, the bot gets /people/me to find out who it is. It then stores its own personID and uses that to remove mentions by running a regular expression on the HTML markup that wraps a mention. if (message.html) {   // strip the mention & HTML from the message   var pattern = new RegExp(']*data-object-id="' + sparkbotself + '"[^>]*>[^');   action = message.html.replace(pattern,'');   action = action.replace(/]*>/g,''); } else {   action = message.text; } Another thing the bot needs to do when processing the message webhook is ignore its own messages. A bot’s message to a room will trigger the webhook from Spark, and you don’t want the bot getting caught in a loop where it is answering its own message, with each answer triggering a new message. When the message webhook arrives, the bot compares the personId that sent the message to its own personId and ignores it if they match. To keep different instances of the game separate, zmachine-api uses a “label” to tag a Frotz process and later find the process ID that a command should be sent to.  Each label becomes a different instance of the game. The bot uses the Spark room ID as the label, regardless if you’re playing in a direct or group room. Because we’re starting lots of games, in order to keep from having thousands of idle Frotz processes running, the bot starts a new process for every in-game command, then saves the game and shuts down the process when the command is completed. This also ensures that if the server is restarted, all of the games can pick up where they left off. This has the side effect of the “moves” counter in the game appearing to increment by two on every in-game move, since Zork considers saving the game to be a move. Here’s a flowchart of the bot’s logic. Spark-specific bits are in green, Tropo-specific operations for SMS are in blue, and interactions with the Zork engine and zmachine-api are in orange. And finally, the code behind the Zork bot is available for your own use. Grab it from my GitHub repository. It’s all written for Node.js, using the Express framework. Included in the repository is a Dockerfile for spinning up a container with the game, and a docker-compose example that will start up multiple containers with the game and all its dependencies. ... View more

You can now play Zork in Cisco Spark. Add adventure@sparkbot.io to a Spark room, or start a direct conversation with it, and you’ll be invited to play the classic text adventure game Zork: The Great Underground Empire - Part I. Each room you add the bot to is a different game of Zork. All the participants of the room can play the game together. The bot also has SMS support through Tropo. If you’re in the US, you can play Zork over text message by texting something to +1-844-373-9675. Outside the US, try +1-541-936-9675, but this has a lower capacity and may not work as well during busy times. In either case, your carrier's normal text or data rates apply. Next week, we’ll explain how the bot works, show some code, and walk through some of the helpful user interface things you can do in your own bot. ... View more

Earlier this week, a new feature was added to Spark to tell you if a person is available or not. Based on your usage, we determine if you're actively using Spark and then in the client, help people understand if you're online or not by saying something like "Active 10 minutes ago" next to your name. Now the Spark APIs have this same information available to you. The People API has two new fields, lastActivity and status that help your integration or bot determine if a Person is active or not. The lastActivity field gives you the date and time that Spark last saw the person doing something - writing a message or having a call, for example. The status field tells you if the person is "active" or "inactive". These fields are read-only; there's no way to set a person's status through the API. Spark determines their status automatically, with no input needed from your side. In the future, as Spark gets more presence options, the status field will gain those same options. So while you'll only see "active" and "inactive" today, you'll want to make sure your application doesn't break or behave oddly if you get a different status entirely. ... View more

Last week, we put a bunch of Cisco Spark and Tropo developer mentors on buses around the country and watched as teams of “buspreneurs” created products and companies as they trekked to Boulder, CO over four days from six points around North America. This crazy idea is called Startup Bus, and it’s sort of an extreme hackathon for people who want to build a real company. Cisco was proud to sponsor the Startup Bus along their journey, and to provide mentorship, product, and financial support during the grueling trip. Teams organized and communicated amongst themselves and with the other buses using Cisco Spark and many built products on the Cisco Tropo API. A few of the standouts using Tropo APIs were GlassTable which alerts local farmers to distribution opportunities while they’re out in the field, Squad which helps people organize travel for group activities, and UBR Guides which helps you find a local tour guide to show you around town. Each bus ended their travels at Boulder Startup Week where they pitched their newly-created products in an all-day semifinal competition. The teams that made it through this round then spent the next 24 hours honing their pitches and their products to present in front of a panel of TechStars judges for the chance to win the grand prize. The finals competition was held at Spark Haus, a takeover of the Startup Week basecamp where you can learn from mentors, experience Cisco products, take part in various Startup Week events, like a startup hiring fair and Ignite Boulder. The overall winner of the Startup Bus, and the winner of both the Cisco and Uber sponsored prizes, was TuB - a product designed to bring you curated content from your social and reading feeds, targeted to the amount of time you have to view it. Hop in an Uber and get a text message via Tropo or Facebook Messenger offering you some things to read or watch that will take up just the amount of time of your Uber trip. They’ve won mentoring from Startup Bus alumni, a trip to San Francisco to pitch the Spark Innovation Fund and have dinner with some Cisco execs, $1000 in Tropo credit, $800 in Uber credit, and a mentoring session with Uber developer experts. It’s impressive to see how much can be built on a cross-country roadtrip with a bunch of coders, designers, and business minds. We had a fantastic time spending the week with the buspreneurs, showing them how Cisco Spark and Tropo can be used to spark innovation. StartupBus North America from Cisco Spark for Developers on Vimeo. ... View more