Skip to main content

Octoblu Part 2

created by Greg Roll

Welcome to part two of my Octoblu series. In my previous post I detailed how I used the power of Citrix Octoblu to deliver a treat from your retweet. If you missed it you can find it here.

In this post I am going to delve in to the Octoblu Flow that was used to bring the Retweet Tweet Lego machine to life.

As you may recall our Octoblu solution consisted of six main components:

  • Twitter Steaming

  • XenDesktop

  • Gateblu

  • .Net Frontend Display Program

  • Octoblu

  • Lego Mindstorm

This post will focus on three of those components:

  • Octoblu
    Octoblu is the main brains of the demo. It brings together the “Internet of Things” to produce great workflows with disparate devices and services. Octoblu consists of many “Things”.

  • Gateblu
    Gateblu allows you to connect smart devices, motors, servos, sensors, and additional protocols to Octoblu.

  • Twitter Steaming
    One of the many “Things” that Octoblu has is the Twitter Streaming “Thing”. Twitter Streaming allows real time updates of tweets that match a certain criteria.

If you haven’t already now is a good time to sign up for the Octoblu Beta for free. Visit https://www.octoblu.com and click ‘Get Started’. Once signed up you will have a demo flow that you can play with.

Once you have an Octoblu account you can import the flow we used for our demo. Just click this link https://app.octoblu.com/design/import/fc82841a-50e6-49e8-b3c0-7d84563b401f then the import button. This is the flow that I will be detailing in this post.

After our flow is imported you should see a flow that looks something like this.

If you look horizontally across the page you will see there are four distinct lines. Each of these is a workflow that serves a different purpose and is triggered to start in a different way. These workflows are:

  • Dispense Lolly (Manual Trigger)

  • Stop Twitter Streaming (Manual Trigger)

  • On Start (Automatically starts on Flow start)

  • Monitor Trays (Manual Trigger)

Before I discuss each workflow it is important to understand the two different ways to start a flow.

The first is a Manual Trigger. A Manual Trigger is exactly that, it is triggered when you perform a manual action against it. A manual trigger can be initiated by either clicking on the play button next to the trigger, the Blu Android and iOS mobile application, an email or a HTTP POST.

The second is an On Start Trigger. An On Start Trigger is triggered when you start the main flow by clicking play in the top right hand corner of the Octoblu designer.

Both of these Triggers can be added to your Flow from the Tools section on the right hand side of the Octoblu designer.

Now you understand what Triggers and Flows are let’s take a look at two of the workflows. The first workflow that we will look at is the Dispense Lolly Trigger. This workflow enabled me to dispense a lolly by clicking the blue play button on the trigger or by using the mobile Blu application.

From left to right this workflow contains the following nodes:

  • Trigger (Dispense Lolly)

  • Function (Generate HTTP Post (Dispense Lolly))

  • HTTP Connector (HTTP Connector)

  • Debug (Debug)

Each grey line represents information flow. So in this example data will travel from the Trigger all the way to the Debug node. It is important to note data only moves from one node to another once the first node has processed and completed its’ task.

The Trigger node (Dispense Lolly) serves a single purpose and that is to start the workflow. When it’s triggered it will notify the Function Node to begin processing.

If you single click on the Function node you will see the top right corner of the Octoblu Designer changes to reveal details about the selected node in the “Thing Inspector”.

Function nodes contain JavaScript. In this example I am returning a JSON object which will be passed on to the HTTP Connector node.

On completion of the Function node the HTTP Connector node will receive payload. In order for the HTTP Connector to consume the payload the Use Incoming Message must be enabled. This is set in the “Thing Inspector” after single clicking the HTTP Connector node.

After receiving the incoming payload on the HTTP Connector node Octoblu will send a command to the HTTP Connector running on Gateblu. The Gateblu HTTP Connector will then perform the HTTP action that was specified in the Function Node. In this case the JSON object specified POST.

Figuring out exactly what some nodes expect as incoming data can be challenging. Nodes accept the incoming message as payload which is generally referenced by {msg.payload}. If you visit https://github.com/octoblu/ you can search for the Thing you are trying to use to find its’ schema. For example to understand how the HTTP Connector thing works visit https://github.com/octoblu/meshblu-http-connector where you can see the schema is detailed as:

{
"options": {
"method": "GET",
"url": "http://192.168.0.5/status"
}
}
If we were to take their schema example then we would use:

return {
payload: {
options: {
method: 'GET',
url: 'http://192.168.0.5/status'
}
}
}
The next workflow I wanted to describe was the On Start workflow. This is the main workflow that it automatically run when you start the Octoblu flow.

This flow completed the following tasks when someone retweeted our @oobeaus account:

  • Twitter would notify the Twitter Streaming thing running on Gateblu a new retweet had been received based on our search criteria

  • Gateblu would notify Octoblu of the tweet and twitter handle details

  • Octoblu would then send a HTTP post message to the Display Application via Gateblu. This post message contained all the details from twitter

  • The Display Application would then display the persons twitter handle on screen and dispense a lolly from the Lego Mindstorm

  • The Display Application would then return a success response to Octoblu

  • Octoblu would then send a direct twitter message to the person to say thanks for visiting our booth

From left to right this workflow contains the following nodes:

  • On Start Trigger (On Start)

  • Twitter Streaming node (Twitter Streaming)

  • Debug node (Debug)

  • Function (Generate HTTP Post (New Tweet))

  • HTTP Connector (HTTP Connector)

  • Debug node (Debug)

  • Equal node (Respond with Tweets?)

  • Send Tweet node (Send Reply)

  • Debug node (Debug)

To start an Octoblu flow and trigger the On Start node click the Play symbol in the top right corner.

Since you are now familiar with the On Start node let’s move on to the Twitter Streaming node.

The Twitter Streaming node uses Twitters’ stream API and runs via Gateblu. You can find more about the API here https://dev.twitter.com/streaming/overview. In my next post I will go in to more details about setting up nodes on Gateblu.

The Twitter API will send the Gateblu Twitter Streaming thing an event any time a criteria is met. In our case we searched for a particular hash tag. Each time this event was received Gateblu would trigger the Twitter Streaming thing. The Twitter Streaming thing would then pass details about the tweet for the Generate HTTP Post (New Tweet) Function Node.

Now to help determine what data is sent on from a node we have two choices:

  • Enable debugging on the node – This is done by selecting the node and enabling debug in the “Thing Inspector”

  • Link the node with a Debug thing

If you enable debug on the node then the debug tab (Bottom right hand corner of the designer) will show the debug event. If you do this for many nodes it may be confusing as to which node did what. I prefer linking a debug node to a node because you can then click on the debug node and it will only show the output from that node in the debug tab.

The next two nodes are very similar to the first example. There is a function node and a HTTP Connector node. The function node takes the tweet data and sends it on to my custom .Net Display Application.

The function looks like this:

return {
payload: {
options: {
method: 'POST',
url: 'http://localhost:8080/api/v1/Octoblu/sendtwitterdata',
json: true,
body: msg.tweet
}
}
}
The HTTP Connector is configured in the same way as the first example. It is set to Use Incoming Message.

My .Net Display Application would then dispense a lolly, display the twitter handle on screen and then respond with a HTTP 200 response to Octoblu. The HTTP Response would contain a JSON object that looked like this:

{
respondWithTweet: true,
replyTwitterID: 12345678
replyTweet: 'Thanks for visiting the oobe booth'
}
Octoblu would then pass this on to the Equal node.

The Equal node has the following condition:

{{msg.payload.body.respondWithTweet}} = True
The Equal node will only pass payload data on if the condition is true. So in my case Octoblu would pass the payload data on to the Send Reply (Twitter) node.

The Twitter node would read the incoming payload message and send a reply tweet. The Send Reply node looks like this:

As you can see the Send Reply node uses the information from the incoming payload to determine the User ID {{msg.payload.body.replyTwitterID}} and Text {{msg.payload.body.replyTweet}}.

One thing I should point out here; Use Incoming Message was not selected. This is because I would have had to generate a JSON response from my .Net Display Application that included all the information that the Send Reply node required such as Endpoint (New Direct Message).

Now you are more familiar with Octoblu flows take some time to have a look at the other workflows; Stop Twitter and Monitor Trays.

In a future post I will detail the installation of Gateblu on Windows and how to setup some Gateblu things so stay tuned!

To stay up to date with oobe follow us on twitter @oobeaus. You can also follow me @oobegreg.

Back