If you are not familiar with Octoblu; it is an IoT messaging system, a protocol translation system, and a message transformer for IoT all rolled into one product.
Since last year I have been spending quite a bit of my time with their systems and platform.
Everything in their system is a device, your user account, a software agent that we demonstrated on the Synergy 2015 stage day 2 keynote, each node that you see in the designer, even that running workflow. They are all devices and they all have messages bouncing around between them.
One thing that I have come to rely on are their workflows. I use the flows as a message router / message translator.
By that I mean that I formulate a JSON message and send that to some endpoint (I frequently send a REST message to a trigger using PowerShell). And the flow will do something with that message - it might change it, filter it, route it to one or many other devices (seen in the flow designer as 'nodes').
All that said, I will probably post about sending and transposing messages later. It is actually one of the fundamental things that any device does in the IoT world.
I am pretty loose with the concept of what a 'device' is: it can be the Arduino that I have on my desk that runs Microblu, it can be a Node.js application that I run on my workstation, it can be a personal interface to Github (the Github node in Octoblu). A device is anything that can either send or receive a message.
Back to the title of this post.
I just finished running a long duration test against a 'device' and during this test I wanted to ensure that my workflow remained running.
When you begin to rely on workflows you realize that it is a cloud service and things happen. Sometimes flows get knocked offline.
Over time I have dreamed up a couple approaches to evaluating flows from a 'health' perspective. One of them (my v1) I am using as my base for this post.
This is a really simple approach; make an API call that determines if s flow is running.
If it isn't running, I start it. Simple as that.
The complexity comes with two different APIs being involved; as there are two different systems of the service at play.
There is the Octoblu API - this is the Octoblu designer and the GUI and those pretty things that you visually interact with.
And there is the Meshblu API - this guy is the messaging meat of the infrastructure. He handles routing, security, and devices. When a flow is run for the first time it becomes instantiated over on Meshblu and becomes a device of the ecosystem.
The code is in my Github Octoblu PowerShell repo here: https://github.com/brianehlert/OctoPosh
The particular script behind this post is: "FlowWatcher.ps1"
Though I have comments in my script allow me to describe a bit more of what is happening.
Invoke-RestMethod -URI ("http://meshblu.octoblu.com/devices/" + $flowId) -Headers $meAuthHeader -Method Get
This is a Meshblu API call to fetch the properties of an individual device. Note the $flowId GUID string in the URI path. Leave that GUID out and you get back an array of all of the devices that you 'own'.
Invoke-RestMethod -URI ("https://app.octoblu.com/api/flows/" + $flowId) -Headers $meAuthHeader -Method Get
This is an Octoblu API call to fetch an individual flow / workflow. Just as happens if you open one in the designer, you get all of its properties.
Invoke-RestMethod -URI ("https://app.octoblu.com/api/flows/" + $flowId + "/instance") -Headers $meAuthHeader -Method Post
This is another Octoblu API call to start a flow. What happens is that a flow device instance gets instantiated in Meshblu (this way it can receive messages). This is why I call the Meshblu API to see if it is 'running'.
Invoke-RestMethod -URI ("https://app.octoblu.com/api/flows/" + $flowId + "/instance") -Headers $meAuthHeader -Method Delete
This is a Meshblu API call to stop flow. What it does is delete the running instance of the device. If you query this particular device in Meshblu (after you have run it once) you will find it in Meshblu, but it may not be running. If it is running, it is a little process within the infrastructure, when not running it is still defined as a device.
I hope you find the script and this little API tutorial to be useful.
No comments:
Post a Comment