Cisco DevNet is Cisco's developer program to help developers and IT professionals who want to write applications and develop integrations with Cisco products, platforms, and APIs. Cisco DevNet includes Cisco's products in software-defined networking, security, cloud, data center, internet of things, collaboration, and open-source software development. The Webex Teams Innovation Fund is a $150M endeavor by Cisco to unlock great ideas for people like you.
Discover how Webex Teams (formerly Cisco Spark) APIs can help you automate room creations, create bots, or embed the Webex Teams User Experience into existing apps. This module is not tied to a particular programming language: learning labs leverage the Webex for Developers interactive documentation and Postman. Teams are groups of people with a set of rooms that are visible to all members of that team. This API is used to manage the teams themselves. Teams are created and deleted with this API. You can also update a team to change its name, for example. To manage people in a team see the Team Memberships API. To manage team rooms see the Rooms API.
Read previous blogs in Adam’s Cisco DNA Center series
Find out about network issues before your users do!
Cisco DNA center has a powerful issue correlation engine for enterprise wired and wireless networks. Taking real time feeds of network telemetry it is able to identify issues and provide context for resolution. The next question is what to do with the events? Some customers would like to send them to an email system, where as others would like to create a message in an instant messaging system.
Fortunately, there is a webhook based notification that can be used to process and handle issue notifications. This blog post provides a simple python script to send a notification to a Webex Teams room, or email server. Version 1.3.1 of Cisco DNA Center provides native email integration, so I will focus on the Webex Teams integration.
Getting Started
As with all of my examples, the sample code is posted on github.
The first step is to download the code and create a python virtual environment (the virtual environment is optional). You need to change directory into the WebHookServer directory.
Webex Teams Developer Api
The next step is to install the required python libraries
You will also need to edit the configuration file config/dummy_spark_config.py and add a Webex Teams roomId and provide a valid Webex Teams token. To get a token and find the API call to discover the roomID go to developer.webex.com .
You need to run the server and it will listen on port 9000. This can be changed if required.
Testing out the issue notifications
The next challenge is to generate an issue. Fortunately, I have provided a sample script to generate some “dummy” issues.
The client directory contains some “fake issues” that can be sent to the server for testing.
If you run the client.py program will no arguments, a list of valid issues is provided.
The schema for issues changed between 1.3.0 and 1.3.1. There are examples for both old and new versions. New versions has prefix “new.” The new_flap_eg is an example of a new issue. I am going to send the new format example.
The server will display the JSON payload, as well as sending it to the Webex Teams room.
If you want to take a look at the payloads, you can look at the source of the issues in the github directory:
Cisco DNAC configuration
I am going to focus on the 1.3.1 configuration. This has changed a lot from earlier releases and is now real time (vs 15min delay).
The first step is to go to Assurance->Manage->Issue Settings
Then click top right “Manage Subscriptions.” A tip is to make sure you click “show more” a few times so all 53 issues can be selected. Only the first 10 are shown by default.
You can then click top left “subscribe,” and then “Create a new subscription.” You will see the screen below.
Select the “created a new endpoint option.” For this example, we need the IP address of the server and the port (9000 was the default). Note that this needs to be https. You also need to select the HTTP Method (POST).
For the simple example, there is no authentication, but this is easy to add. Click “subscribe” and the subscription will be created for the selected events.
Congratulations, you now have a working integration between your DNA Center and the python webhook server into webex teams.
What Next?
It would be simple to extend this simple example to create a new room for handling P1 cases, automatically adding people to the room.
There are a number of other blogs in this series on Cisco DNA Center. You can find them here.
In the meantime, if you would like to learn more about Cisco DNA Center, you could visit Cisco DevNet. DevNet has further explanations about other Cisco DNA Center topics.
Thanks for reading.
Enabling Integration via Webex Teams and Cisco DNA, SD-Wan, Intersight, Thousand Eyes via Cloud API Gateway
I was really excited to have a unique opportunity to put together a team of my fellow engineers to work on a Collaboration hacking contest within Cisco. This annual event is usually in-person for a day or two in San Jose, making it out of reach for my nomadic desert comrades located in Arizona. This year, however, remote is the new normal. This unique situation made it possible for my ragtag band of misfits to participate in events regardless of our geography. So we embarked on a mission to enable webhook integration for Webex teams, so that our products can send notifications into Teams, just as they can into email.
A cloud native yet cloud agnostic solution
In order to do this we decided to make sure this wasn’t only able to support diverse products, but also, diverse clouds. A cloud native, yet cloud agnostic solution based upon serverless infrastructure supporting standard webhooks and HTTPS Post messages. We decided on Google Cloud platform and Amazon Web Services for our multi cloud endeavor.
The initial idea was actually for a separate use case – I have esp8266 modules integrated with Teams for the use case of being notified when my garage door is opened/closed, my bearded dragon’s cage is hot, etc. As these scale in number, if I ever were to change my security bot token or room ID, I would have to go re-flash all of my IoT Sensors to match. So, it creates an operational problem for leveraging Teams as a IoT device receiver or third party integrator.
Enable cloud as an API gateway
The idea was to enable cloud as an API gateway to accept requests, do advanced security checks, and decouple the Webex Teams security and context information from what is flashed onto the sensors to better manage the lifecycle. But extending this to webbooks was a natural evolution that seemed to have the most immediate impact to customers. When Demo’ing some of our cloud technologies (Intersight, Meraki), customers saw that notifications can go to webhook or email, and naturally inquired about their Webex Teams integration.
By enabling the webhook capability, we immediately added support for all of our product sets that support webhooks to integrate with Webex Teams. And do so without requiring any change on either the product, or Webex Teams. We did want to have native “handlers” in the code to handle differences in webhook formatting between different products. For our project we created handlers for Cisco DNA Center and Meraki. We had started work on Thousand Eyes but didn’t have the lab instance able to send webhooks at the time we finished the project. The amount of effort to create and modify a handler is as simple as 20 minutes worth of effort ensuring that the JSON fields that you care about, are included in what is sent to Teams.
The code is available on Github
Of note, while the code should have been very consistent between solutions, there is a difference in how Google integrates their API with their cloud functions compared to AWS. The API gateway on GCP has been out for a while, but right now integration of the API gateway on Google for cloud functions is in Beta and does require a bit more lift to setup. I expect this will normalize as it is brought to market. I also want to caveat that by noting I was seeking a functional product, closer integration with GCP teams probably would have helped with how I managed some error handling in Cloud Functions to make it integrate with API GW.
Related resources
Webex Developer Api
