Using MS Flow to Power a Spark Bot

February 16, 2018 Cloud Webex

In my last blog I used MS Flow to power an email to Spark bot.  It allowed me to get the same type functionality that would have otherwise took a lot of STMP programing.  I was pretty impressed with MS Flow and I think most of that functionality given time could be accomplished without the Azure function natively in Flow, maybe.

But Flow was so cool I figured I’d dedicate a post to just working with Flow and what’s needed to build a Spark bot without having to program.  You don’t need to know any particular programing language to use Flow, but you do need to understand programing logic, and when working with Spark understand JSON and REST API to be able to piece everything together.  The syntax is all drag and drop within Flow.  If I need an IF statement and just click the IF button, create the condition and then complete the TRUE/FALSE bit.

This is a simple bot that listens for 1:1 messages and echos back what was said to the same Spark space and then sends you an email.  With the base lines of how to call and process the Spark REST API info you can expand as needed.  Flow also has pre-built triggers into all sorts of MS tools and some third-party apps.  So you could use it as an easy point to pull a Twitter feed to Spark or the other way, or upload documents to sharepoint by mentioning a bot, etc etc.

Building the Bot

After we’ve created out bot we need to register a webhook on receiving a new message.  We’ll add a filter so it only works on 1:1 rooms.  This webhook is what will trigger the Flow.  In the o365 portal we will create a new flow and the trigger point will be and “HTTP Request.”  We won’t know the URL until we save the flow so we need to save building the actual Spark webhook until later. We do want to set the request method to “POST” since that is what we are expecting.

Flow can automatically build out the JSON parser based on what is expected to be received in the webhook alert so either open that option and paste in the expected output, or you can use the following JSON Schema

{
    “type”: “object”,
    “properties”: {
        “id”: {“type”: “string”},
        “name”: {“type”: “string”},
        “resource”: {“type”: “string”},
        “event”: {“type”: “string”},
        “filter”: {“type”: “string”},
        “orgId”: {“type”: “string”},
        “createdBy”: {“type”: “string”},
        “appId”: {“type”: “string”},
        “ownedBy”: {“type”: “string”},
        “status”: {“type”: “string”},
        “actorId”: {“type”: “string”},
        “data”: {“type”: “object”,
            “properties”: {
                “id”: {“type”: “string”},
                “roomId”: {“type”: “string”},
                “personId”: {“type”: “string”},
                “personEmail”: {“type”: “string”},
                “created”: {“type”: “string”}
                }
            }
       }
}
Next we will write our standard condition to keep the bot from echoing itself.  We can just leave the “If no” option blank so the Flow will die.
Now comes the fun part of processing the message once we’ve gotten notification of it.
First we need to find out what the message actually was.  The webhook is send us the message ID and we can then do a GET request back to Spark for more details, like the text.  We want to send the request to https://api.ciscospark.com/v1/message/{id}.  The ID part is a bit tricky because of the way Flow sorted our webhook we have 2 variables called “id”.  Take your pick and if it doesn’t work, try and figure out which one is the correct one.  It took a me a few tries.  We need to Authenticate all of our Spark requests so add a header for Authorization and set the value to “Bearer <sparkToken>”
The response will be the JSON formatted info from Spark so we need to parse that out using a “Data Operations” step to “Parse JSON”.  This step is similar to what we did with the initial webhook.  We paste in the response we are expecting back and it will go through the trouble of mapping out the variables for us.  For the content we will reference the “Body” of the previous HTTP Request.
Now we can build another HTTP Request to echo back the message in the same Spark space.  Here we set the method to POST and use the same URI.  We need to add a header to set the “Content-type” to “application/json” and then we will build the message body in the JSON style referencing the variables from our previous steps.
Next we want to echo back that same text to the users email so we build a step “Send an email.”  We reference the “personEmail” from the Spark message, make up a subject and then set the email body to the “text” from the spark message.
That’s it for the MS Flow side.  Now we just need to build the webhook.  Once you’ve saved the Flow you will get a trigger URL.  We will use Postman to register the webhook. Remember to add your Token to the auth header here.
Now you have a fully functional Echo Bot and can expand and add more logic as needed.  Flow is a great way to pull Spark into distribution lists and notification emails.  You just have to build the right logic for room tracking.

email2spark bot using O365, MS Flow and Azure Functions

Solving the 7 Digit Problem in Globalized Dial Plans